Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

AWS CDKにテストは必要?試行錯誤したスクラム開発事例を紹介!/CdkConJp2023

AWS CDKにテストは必要?試行錯誤したスクラム開発事例を紹介!/CdkConJp2023

「AWS CDK Conference Japan 2023」での登壇資料です。
イベントURL:https://jawsug-cdk.connpass.com/event/278205/

More Decks by みずほリサーチ&テクノロジーズ株式会社 先端技術研究部

Other Decks in Technology

Transcript

  1. AWS CDK にテストは必要? 試行錯誤したスクラム開発事例を紹介! 2023.5.20 AWS CDK Conference Japan 2023

    Copyright (c) Mizuho Research & Technologies, Ltd. All Rights Reserved. (免責事項) 当資料は情報提供のみを目的として作成されたものであり、商品の勧誘を目的としたものではありません。 本資料は、当社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を 保証するものではありません。また、本資料に記載された内容は予告なしに変更されることもあります。
  2. 自己紹介  氏名: 松尾 優成(まつお ゆうせい)  所属: 先端技術研究部 兼

    プロジェクト推進部  主な役割: 社内共通 AWS プラットフォームの構築・運用  休日の過ごし方:  0歳児の娘と戯れる!  ビッグバンドでサックス演奏 (5/21, 池袋ジャズフェス2023に出演予定!)
  3. これまで主にやってきたこと 2015年~ 勘定系周辺の システム開発・保守 (管理・調整が主) 2019年~ CCoE 活動 予防的統制 (サービス認定)

    2020年~ 大型 AWS 案件の 設計・構築 (N/W・Security等) 2022年~現在 社内プラットフォーム 構築 (Platform as a Product) スクラム開発・ CDK(TypeScript)と 初めてのことだらけ!
  4. 本日話すこと • スクラム開発の取組概要 • AWS CDK の単体テスト • CDK におけるテスト駆動開発(TDD)

    • cdk-nag 導入 ※ドメインロジックに関するアプリケーションのテストは本発表の対象外
  5. 社内プラットフォーム 社内プラットフォームのプロダクト概要 “安心して AWS の有用性を発揮し、 ビジネス価値の創造に素早く着手・集中できるプラットフォームを提供” ※AWS Summit Tokyo 2023

    では、プラットフォームの他社事例が沢山出ていました AWS account A Control Tower ユーザー関連 セキュリティ AWS account B AWS account C 事前に整備された AWS アカウントを払い出し Azure AD
  6. CDK で作っているものを一部紹介  Security 関連の共通リソース • CIS ルール違反検知(メトリクスフィルタ・アラーム) • 通知設定(EventBridge・SNS)

    • CIS 不要ルールの無効化(Custom Resource) • 違反リソースの自動修復(SSM Automation) ※ AFT(Account Factory for Terraform)や CfCT で構築するのが主流かも?  プラットフォーム利用者向け静的サイト(WAF・CloudFront・S3 etc...)
  7. 開発体制・内部事情  2021年末頃から、スクラム開発で構築 (チーム全員がスクラム初心者で、殆どのメンバーがCDK・TypeScript 初挑戦)  Dev メンバーは流動的で、入替・人数の増減が激しい(2~8人)  全

    Dev メンバーは他業務と兼務で、1人あたり50%以下の工数を捻出 ※アンチパターンなので非推奨  プロダクトの足元整理などで、開発停止期間が相応にある CDK に触れるのは 貴重な楽しい時間!
  8. CDK の単体テストは、一般的に以下 3 種 No. 名称 概要 1 スナップショットテスト CDK

    で生成された CFn テンプレートの断面を保持し、 前回実行時との差分を確認する。 2 アサーションテスト CDK で生成された CFn テンプレートが想定通りの値か、 確認する。 3 バリデーションテスト Construct で、無効な入力値を受け取った際の挙動を確認する。 自作のカスタム Construct をチーム外へ 配布はすることは当分なさそうだし、 バリデーションテストは一旦見送る?
  9. スナップショットテスト・アサーションテストを取り入れることに (余談)2023年5月現在、開発者ガイドや CDK 実践勉強会には、バリデーションテストの紹介なし https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/testing.html No. 名称 概要 1 スナップショットテスト

    CDK で生成された CFn テンプレートの断面を保持し、 前回実行時との差分を確認する。 2 アサーションテスト CDK で生成された CFn テンプレートが想定通りの値か、 確認する。 3 バリデーションテスト Construct で、無効な入力値を受け取った際の挙動を確認する。
  10. スナップショットテストの気づき  特に有用だと感じたのは、他のテストが全くない状態のリファクタリング (L3 → L2 Construct に移行した際など、効果を実感)  CDK

    バージョンアップの変更点を確認しやすい (cdk diff は別途実行推奨)  一方、実装が設計通りかは確認できない
  11. どの粒度でアサーションテストを書くか悩む  設計通りになっているか確認する  一般論に沿って、1 つのテストケースで 1 項目を確認する https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/ testing.html#testing_tips

    失敗要因が明確(テスト名から何が失敗したか分かる) リソース単位で各ケースをまとめる方がテスト工数は少ない 一方、設計は見えづらくなるので、方針次第
  12. (余談) カスタム Construct とスタックのテストをどう分けるか テスト観点 (試行錯誤中・・・)  カスタム Construct (リソースのパターンや入出力に着目)

     リソース数  Interface による分岐・メンバ変数  各リソースの設定値  リソース間連携 etc...  スタック (デプロイ単位であることに着目)  スタック内の全リソース数  スタック固有リソースの設定値(命名規則など)  Construct 間連携  セキュリティ関連 etc... https://d1.awsstatic.com/webinars/jp/pdf/services/ 20200303_BlackBelt_CDK.pdf#page=46 ※『リソース』は AWS CDK 標準 Construct を指す(L1~L3)
  13. アサーションテストの気づき  テストコードにドキュメントとしての価値あり  リソース数のチェックで、設計外のリソースを認識できた (ハイレベル Construct が裏側で Lambda 関数を使っているパターンなど)

     変更容易性が高まり、MVP を拡張するスクラムとの相性がよい • リグレッションテストが容易で、追加実装が楽になった • スタックの分離や統合をする際も、テストが大きな支えとなった
  14. アサーションテストが不要だと感じるパターン  PoC などの検証  L1 Construct を宣言的に記述(繰り返し処理なし・単純な分岐のみ)  Step

    Functions など複雑な連携・フローを確認したいとき (後続の別テストで確認) テストコードに慣れるまでは どうしても工数が膨らむ・・・
  15. テスト駆動開発(TDD)を導入する Red テストと最低限の プロダクトコードで TEST FAIL Green 素早くコードを 修正し TEST

    PASS Refactor 重複除去など リファクタリング https://www.youtube.com/ watch?v=Q-FJ3XmFlT8 とても分かりやすい!
  16. CDK における TDD の効果②  重複除去により、『動作するきれいなコード』に近づいた  パターン化されている箇所が、カスタム Construct になっていった

    スタック SNS Topic ① Events Rule ① SNS Topic ② Events Rule ② 重複箇所を Construct 化 スタック カスタム Construct SNS Topic Events Rule カスタム Construct ① カスタム Construct ②
  17. CDK における TDD の効果③  ハイレベル Construct の特徴である抽象化をより活用するようになった 初めて使う L2

    Construct だけど 要件満たせるかな? L2 Construct 問題なさそう! テスト以外の項目は L2 Construct の デフォルト値に任せよう! 設計中 TDD 実践中
  18. CDK における TDD の悩みどころ  CFn テンプレートの出力が見えていないと厳しい (初めて触る AWS サービスなどは特に時間がかかる)

     ネストの深い CFn テンプレートのテストを先に書くのは難しい  CFn テンプレートのサジェストがないのもきつい → 最初から完璧なテストコードを目指さない! CFn テンプレートを生成し、先に構成をみてしまうのも手
  19. cdk-nag の気づき  お手軽に試せる!一方、AWS Solutions ルールパックはリッチすぎ?  基本ルールから独自ルールパックを作成し、設計漏れを抑制できた (社内ルールで、cdk-nag の基本ルールにハマらないものもでてきた)

     cdk-nag のカスタムルールを書くよりは、アサーションテストの方が楽そう (全社的にCDKを使っているわけではないので、 ルール化は気が重い ) → ルール外の細かいセキュリティ設定はアサーションテストで確認することに
  20. CDK における各テストの比較 No. 種類 主な恩恵 導入速度 難易度 1 スナップショットテスト ・手軽に差分確認

    ・いつでも始められる 速 低 2 cdk-nag ・違反リソース未然防止 ・設計漏れ抑制 速 中 3 アサーションテスト (実装→テスト) ・変更容易性が高い ・高信頼ドキュメント 中 中 4 アサーションテスト (TDD) ・上記恩恵 + YAGNI ・動作するきれいなコード 遅 高
  21. CDK デプロイ後の確認について  セキュリティ関連の構築がメインだが、デプロイ後環境をどこまで確認?  Config ルール(Control Tower 管理)でも設定不備を一部検知可 

    CFn ドリフトがなければアサーションテストの内容が担保されているはず  凝った自動テストは不要と判断し、手動テストを継続  IP 制限をしている静的サイトについては、CDK パイプラインで デプロイ後に curl 実行し、アクセス拒否されることを確認
  22. CDK リソースチェックをまとめてみた 設計 実装 ビルド (cdk synth) デプロイ (cdk deploy)

    リリース 運用 スナップショットテスト Control Tower Proactive Controls アサーションテスト (実装→テスト) cdk-nag (UT) アサーションテスト (TDD) Config ルール デプロイ後テスト cdk-nag
  23. 当チームで現在取り入れているのは太字箇所 設計 実装 ビルド (cdk synth) デプロイ (cdk deploy) リリース

    運用 スナップショットテスト Control Tower Proactive Controls アサーションテスト (実装→テスト) cdk-nag (UT) アサーションテスト (TDD) Config ルール デプロイ後テスト cdk-nag