脆弱性対応を支える技術/20221127_JJUG-CCC-2022-Fall

by skaji18

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 ● 梶紳之介 ● 株式会社ラクス ● 人事労務管理サービスの開発 ● Java、Vue.js、（PHP） 2 @s_kaji_18

Slide 3

Slide 3 text

脆弱性対応、うまくいってますか？ 3

Slide 4

Slide 4 text

例えばこんな課題、ありませんか？ 4

Slide 5

Slide 5 text

やらなきゃいけないけど... ● 自動テストがなく、手動テストが必要 ○ 😇 品質担保に時間がかかる ○ 😇 テストにかける人員／リソースを用意できない ● リリースにサービス停止が必要 ○ 😇 顧客影響が発生するため、ビジネスサイドから敬遠される 5 特に緊急リリースの場合

Slide 6

Slide 6 text

今日お話すること 6 私達の開発チームが実践している、脆弱性対応をより早く、より安全にリリースするためのポイントをご紹介しますキーワード ● 自動テスト ● 無停止リリース

Slide 7

Slide 7 text

目次 ● 前提 ○ 技術スタック概要 ● 脆弱性対応のポイント解説 ○ バージョンアップ環境の準備 ○ テストによる品質担保 ○ リリース ○ メンバーのローカル環境更新 ● まとめ 7

Slide 8

Slide 8 text

8 技術スタック概要 ※今日お話する内容に関連する技術のみ抜粋 ● アプリケーション構成 ○ Java ○ Spring Boot ● 実行環境 ○ コンテナ（Docker） on AWS

Slide 9

Slide 9 text

過去事例に沿ってポイント解説 9 ※事例として Javaのアップデートを扱います

Slide 10

Slide 10 text

● バージョンアップ環境の準備 ○ ● テストによる品質担保 ○ ● リリース ○ ● メンバーのローカル環境更新 ○ ・Oracle Critical Patch Updates の公開・脆弱性対応バージョンのリリース 10

Slide 11

Slide 11 text

11 ● バージョンアップ環境の準備 ○ ● テストによる品質担保 ○ ● リリース ○ ● メンバーのローカル環境更新 ○ ・Oracle Critical Patch Updates の公開・脆弱性対応バージョンのリリース

Slide 12

Slide 12 text

12 バージョンアップ環境の準備 Java を脆弱性対応バージョンにアップデートする ● 前提: コンテナ（Docker）を採用 ● → Dockerfile を1行更新するだけ - FROM amazoncorretto:17.0.3-alpine3.15 + FROM amazoncorretto:17.0.4-alpine3.15 ARG JAR_FILE=target/*.jar COPY ${JAR_FILE} app.jar ENTRYPOINT ["java","-jar","/app.jar"]

Slide 13

Slide 13 text

補足: 依存ライブラリの更新 ● 前提: Javaプログラムの依存関係は Gradle で管理 ● build.gradle の依存関係を更新するだけ 13 … plugins { - id 'org.springframework.boot' version '2.7.3' + id 'org.springframework.boot' version '2.7.4' } …

Slide 14

Slide 14 text

14 ● バージョンアップ環境の準備 ○ ● テストによる品質担保 ○ ● リリース ○ ● メンバーのローカル環境更新 ○ ・Oracle Critical Patch Updates の公開・脆弱性対応バージョンのリリース

Slide 15

Slide 15 text

自動テストで品質担保テストによる品質担保 15 テスト観点・指標カバレッジリグレッションテスト手法ユニットテスト E2Eテスト

Slide 16

Slide 16 text

Java プログラムのメソッドレベルの入出力が期待どおりの動作をしているかを確認する ● JUnit5 を採用 ● カバレッジは約85% ○ サービス開発当初から「テストは書くことが当たり前」の文化 ○ 特にユニットテストは開発ガイドラインとして定めているユニットテスト 16

Slide 17

Slide 17 text

17 ユニットテストリグレッション観点では、以下の重要機能の動作を確認している ● 帳票PDF作成 ○ ○ ● 外部API連携

Slide 18

Slide 18 text

ユニットテストリグレッション観点では、以下の重要機能の動作を確認している ● 帳票PDF作成 ○ 作成したPDFのレイアウトが崩れていないか確認する ○ Apache PDFBox で画像変換して新旧比較 ● 外部API連携 ○ 想定しているフロー／データのままで連携できるか確認する ○ 連携先でバッチ処理される（15分前後）までポーリングする 18

Slide 19

Slide 19 text

Slide 20

Slide 20 text

E2Eテストユーザと同じようにブラウザを操作し、システム全体を通して期待どおりの動作をしているかを確認する ● Puppeteer を採用 ● ハッピーパス（正常系の代表操作）の動作を担保 20 関連資料: 新規プロダクトの開発速度と品質の両立を支える自動テスト https://speakerdeck.com/noriharu3/automation-testing-supports-both-development-speed-and-quality-of-new-product?slide=23

Slide 21

Slide 21 text

21 ● バージョンアップ環境の準備 ○ ● テストによる品質担保 ○ ● リリース ○ ● メンバーのローカル環境更新 ○ ・Oracle Critical Patch Updates の公開・脆弱性対応バージョンのリリース

Slide 22

Slide 22 text

リリースモジュールの作成 ● Gitのタグを打つと自動で作成する ○ Java プログラムのビルド ○ Docker イメージのビルド〜プッシュ ※継続的デプロイには対応していない 22

Slide 23

Slide 23 text

リリース ● イメージをもとにコンテナを起動するだけ ○ 何台もあるサーバの1台1台にインストールしていくような作業は不要 23

Slide 24

Slide 24 text

リリース ● イメージをもとにコンテナを起動するだけ ○ 何台もあるサーバの1台1台にインストールしていくような作業は不要 ● 無停止でリリース可能 ○ AWS ECS の rolling update で実現 24

Slide 25

Slide 25 text

リリース ● イメージをもとにコンテナを起動するだけ ○ 何台もあるサーバの1台1台にインストールしていくような作業は不要 ● 無停止でリリース可能 ○ AWS ECS の rolling update で実現 ● 無停止 = 顧客への影響が出ない ○ 顧客への事前周知が不要 25

Slide 26

Slide 26 text

リリース ● イメージをもとにコンテナをきどうするだけ ○ 何台もあるサーバの1台1台にインストールしていくような作業は不要 ● 無停止でリリース可能 ○ AWS ECS の rolling update で実現 ● 無停止 = 顧客への影響が出ない ○ 顧客への事前周知が不要 → 開発／インフラチームの準備が整い次第リリースできる！！ 26

Slide 27

Slide 27 text

27 ● バージョンアップ環境の準備 ○ ● テストによる品質担保 ○ ● リリース ○ ● メンバーのローカル環境更新 ○ ・Oracle Critical Patch Updates の公開・脆弱性対応バージョンのリリース

Slide 28

Slide 28 text

Java のバージョン管理ツール（SDKMAN!）を採用 ● バージョンアップ担当者 ○ Git リポジトリの設定ファイル（.sdkmanrc）を更新 ● メンバー ○ SDKMAN! から Java のインストールを促されるので、そのコマンドを実行するだけ 28 メンバーのローカル環境更新 # Enable auto-env through the sdkman_auto_env config # Add key=value pairs of SDKs to use below - java=17.0.3-amzn + java=17.0.4-amzn

Slide 29

Slide 29 text

まとめ 29

Slide 30

Slide 30 text

まとめ ● コンテナやパッケージ管理ツールを採用 ○ バージョンアップ作業が簡単 ○ 本番環境への反映もコンテナを置き換えるだけ ● 自動テストで品質担保 ○ 品質担保にかかるリソースを削減 ○ テスト品質が実施者に依存せず、毎回一定水準を担保できる ● 無停止でリリース ○ 顧客影響が無いため、ビジネスサイドから理解を得やすい 30