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

JJUG CCC 2022 Fallの発表資料です。

関連資料
・変わりゆくAPI連携仕様との付き合い方
・新規プロダクトの開発速度と品質の両立を支える自動テスト

Transcript

1. ©2022 RAKUS Co., Ltd.
   脆弱性対応を支える技術
   JJUG CCC 2022 Fall - 2022.11.27
   梶紳之介
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

12. 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"]
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

19. ユニットテスト
    リグレッション観点では、以下の重要機能の動作を確認している
    ● 帳票PDF作成
    ○ 作成したPDFのレイアウトが崩れていないか確認する
    ○ Apache PDFBox で画像変換して新旧比較
    ● 外部API連携
    ○ 想定しているフロー／データのままで連携できるか確認する
    ○ 連携先でバッチ処理される（15分前後）までポーリングする
    19
    関連資料: 変わりゆくAPI連携仕様との付き合い方
    https://speakerdeck.com/nologyance/good-practice-of-using-api?slide=23
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

28. 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
    

    View Slide

29. まとめ
    29
    

    View Slide

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

    View Slide