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

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

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. スクラム開発の概要
6. 社内プラットフォーム 社内プラットフォームのプロダクト概要 “安心して AWS の有用性を発揮し、 ビジネス価値の創造に素早く着手・集中できるプラットフォームを提供” ※AWS Summit Tokyo 2023 では、プラットフォームの他社事例が沢山出ていました AWS account A Control Tower ユーザー関連 セキュリティ AWS account B AWS account C 事前に整備された AWS アカウントを払い出し Azure AD
7. CDK で作っているものを一部紹介  Security 関連の共通リソース • CIS ルール違反検知（メトリクスフィルタ・アラーム） • 通知設定（EventBridge・SNS） • CIS 不要ルールの無効化（Custom Resource） • 違反リソースの自動修復（SSM Automation） ※ AFT（Account Factory for Terraform）や CfCT で構築するのが主流かも？  プラットフォーム利用者向け静的サイト（WAF・CloudFront・S3 etc...）
8. 開発体制・内部事情  2021年末頃から、スクラム開発で構築 （チーム全員がスクラム初心者で、殆どのメンバーがCDK・TypeScript 初挑戦）  Dev メンバーは流動的で、入替・人数の増減が激しい（2～8人）  全 Dev メンバーは他業務と兼務で、1人あたり50%以下の工数を捻出 ※アンチパターンなので非推奨  プロダクトの足元整理などで、開発停止期間が相応にある CDK に触れるのは 貴重な楽しい時間！
9. 開発初期から CDK テスト導入までの経緯
10. 初期は、プロダクトコードのみを書いていたが・・・  プロダクトコードの検証では、デプロイ後の手動テストが主体  スプリントが空き、久しぶりにコードをみると思い出すのに時間がかかった  コーディングしたメンバーが離任し、用途不明なコード・コメントが残留
11. そんな中、以下イベントに出会う
12. 吉川さんの以下発表で、危機を感じる 単体テスト・ スナップショットテスト どちらも未実施…💦 https://winteryukky.github.io/slides-look-back-3rd-year-cdk
13. CDK ベストプラクティスで単体テストの話を思い出す https://aws.amazon.com/jp/blogs/news/best-practices-for-developing-cloud-applications-with-aws-cdk/
14. CDK に単体テスト導入を決意！
15. CDK ワークショップで復習し、ガイドや docs を読む https://cdkworkshop.com/ja/20-typescript/70-advanced- topics/100-construct-testing.html
16. CDK の単体テストは、一般的に以下 3 種 No. 名称 概要 1 スナップショットテスト CDK で生成された CFn テンプレートの断面を保持し、 前回実行時との差分を確認する。 2 アサーションテスト CDK で生成された CFn テンプレートが想定通りの値か、 確認する。 3 バリデーションテスト Construct で、無効な入力値を受け取った際の挙動を確認する。 自作のカスタム Construct をチーム外へ 配布はすることは当分なさそうだし、 バリデーションテストは一旦見送る？
17. スナップショットテスト・アサーションテストを取り入れることに （余談）2023年5月現在、開発者ガイドや CDK 実践勉強会には、バリデーションテストの紹介なし https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/testing.html No. 名称 概要 1 スナップショットテスト CDK で生成された CFn テンプレートの断面を保持し、 前回実行時との差分を確認する。 2 アサーションテスト CDK で生成された CFn テンプレートが想定通りの値か、 確認する。 3 バリデーションテスト Construct で、無効な入力値を受け取った際の挙動を確認する。
18. スナップショットテストを導入してみる
19. お手軽に CFn テンプレートの断面を保持できた！ https://qiita.com/y_matsuo_/items/3c12e4d745dbfe56d4ea 共通部を除くと 実質これだけ スナップショットの中身は 概ね CFn テンプレート
20. スナップショットテストの気づき  特に有用だと感じたのは、他のテストが全くない状態のリファクタリング （L3 → L2 Construct に移行した際など、効果を実感）  CDK バージョンアップの変更点を確認しやすい （cdk diff は別途実行推奨）  一方、実装が設計通りかは確認できない
21. アサーションテストを導入してみる 事例が少なく、苦戦・・・
22. アサーションテストのコードを書くのに、CFn の知識が必要  社内研修で CFn を学べることもあり、CFn に慣れたメンバーが多かった  とはいえ、ネストの深い CFn テンプレートは珍しくなく、序盤は苦戦した
23. どの粒度でアサーションテストを書くか悩む  設計通りになっているか確認する  一般論に沿って、1 つのテストケースで 1 項目を確認する https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/ testing.html#testing_tips 失敗要因が明確（テスト名から何が失敗したか分かる） リソース単位で各ケースをまとめる方がテスト工数は少ない 一方、設計は見えづらくなるので、方針次第
24. ワークショップ・べスプラでは Construct テストのみ紹介  CDK のデプロイ単位はスタックが該当 → 当チームでは、スタックのテストも実施 https://d1.awsstatic.com/webinars/jp/pdf/services/ 20200303_BlackBelt_CDK.pdf#page=46 カスタム Construct の確認が単体テストなら スタックの確認は結合テストと言えるかも？
25. (余談) カスタム 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）
26. アサーションテストの気づき  テストコードにドキュメントとしての価値あり  リソース数のチェックで、設計外のリソースを認識できた （ハイレベル Construct が裏側で Lambda 関数を使っているパターンなど）  変更容易性が高まり、MVP を拡張するスクラムとの相性がよい • リグレッションテストが容易で、追加実装が楽になった • スタックの分離や統合をする際も、テストが大きな支えとなった
27. アサーションテストが不要だと感じるパターン  PoC などの検証  L1 Construct を宣言的に記述（繰り返し処理なし・単純な分岐のみ）  Step Functions など複雑な連携・フローを確認したいとき （後続の別テストで確認） テストコードに慣れるまでは どうしても工数が膨らむ・・・
28. CDK アサーションテストの書き方を以下記事にまとめました https://qiita.com/y_matsuo_/items/bc27db7942179ffb5825
29. アサーションテストのカイゼン
30. プロダクトコード作成後にテストコードを書いていたが・・・  設計書にない項目まで実装・テストしていた  設計の実装漏れがデプロイ後に発覚する（特にセキュリティ関連）  テストコードの記述で消化試合感が否めない（モチベ・・・）  スプリントの進捗がカツカツの場合、テストコードが後回しにされがち ⇒ レトロスペクティブで Dev メンバー共通の課題となっていた セキュリティ機能を提供する側が セキュリティの考慮漏れ・・・
31. テスト駆動開発（TDD）を導入する Red テストと最低限の プロダクトコードで TEST FAIL Green 素早くコードを 修正し TEST PASS Refactor 重複除去など リファクタリング https://www.youtube.com/ watch?v=Q-FJ3XmFlT8 とても分かりやすい！
32. CDK における TDD の効果①  設計書作成後、すぐにテスト項目を洗い出すので、実装漏れがない → 設計にないことを過剰に実装・テストすることがなくなった（YAGNI） 要件 すり合わせ 設計書 作成 テスト ToDo 洗い出し 実装 例） 副次効果で精度向上
33. CDK における TDD の効果②  重複除去により、『動作するきれいなコード』に近づいた  パターン化されている箇所が、カスタム Construct になっていった スタック SNS Topic ① Events Rule ① SNS Topic ② Events Rule ② 重複箇所を Ｃonstruct 化 スタック カスタム Construct SNS Topic Events Rule カスタム Construct ① カスタム Construct ②
34. CDK における TDD の効果③  ハイレベル Construct の特徴である抽象化をより活用するようになった 初めて使う L2 Construct だけど 要件満たせるかな？ L2 Construct 問題なさそう！ テスト以外の項目は L2 Construct の デフォルト値に任せよう！ 設計中 TDD 実践中
35. CDK における TDD の悩みどころ  CFn テンプレートの出力が見えていないと厳しい （初めて触る AWS サービスなどは特に時間がかかる）  ネストの深い CFn テンプレートのテストを先に書くのは難しい  CFn テンプレートのサジェストがないのもきつい → 最初から完璧なテストコードを目指さない！ CFn テンプレートを生成し、先に構成をみてしまうのも手
36. 悩みどころは多いものの、 TDD は CDK のベストプラクティス https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices- cdk-typescript-iac/development-best-practices.html CFn に慣れているなら 試しやすいのでオススメかも？
37. デプロイ前チェックのカイゼン
38. CDK のテストは定着したが・・・  当社ガイドラインでは、共通のセキュリティ・コンプラ要件がある  そもそも設計から上記要件が抜け落ちていたら、デプロイ後まで気づけない  CDK の単体テストでは、スタックまでしかチェックしていない ⇒最上位の app レイヤーで、デプロイ資産を一括チェックしたい レトロスペクティブで 新たな取り組み目標ができた！
39. cdk-nag を導入する  cdk-nag とは、セキュリティ・コンプライアンスチェックできるツール （詳細は、過去の CDK 支部資料をご参照！）  デプロイ時に違反リソースがあれば、デプロイを停止してくれる （cdk synth でも同様に違反を教えてくれる） 設計 実装 ビルド (cdk synth) デプロイ (cdk deploy) リリース 運用 cdk-nag
40. cdk-nag の気づき  お手軽に試せる！一方、AWS Solutions ルールパックはリッチすぎ？  基本ルールから独自ルールパックを作成し、設計漏れを抑制できた (社内ルールで、cdk-nag の基本ルールにハマらないものもでてきた)  cdk-nag のカスタムルールを書くよりは、アサーションテストの方が楽そう （全社的にCDKを使っているわけではないので、 ルール化は気が重い ） → ルール外の細かいセキュリティ設定はアサーションテストで確認することに
41. CDK における各テストの比較 No. 種類 主な恩恵 導入速度 難易度 1 スナップショットテスト ・手軽に差分確認 ・いつでも始められる 速 低 2 cdk-nag ・違反リソース未然防止 ・設計漏れ抑制 速 中 3 アサーションテスト （実装→テスト） ・変更容易性が高い ・高信頼ドキュメント 中 中 4 アサーションテスト （TDD） ・上記恩恵 + YAGNI ・動作するきれいなコード 遅 高
42. テストコードで体力をかけずに 素早く構成チェックしたい場合はどうする？ CDK で細かいアサーションテストを 書くのは躊躇う・・・ （余談）※スクラム開発事例ではないです
43. 単体テストで cdk-nag を使うのがよさそう！  コーディングしながら、違反リソースに都度対応できる  cdk-nag のテストコードは、殆ど固定&短くて楽 https://aws.amazon.com/jp/blogs/news/manage-application-security-and-compliance-with-the-aws-cloud- development-kit-and-cdk-nag/
44. プロダクトコードを保存する度に cdk-nag が自動実行！  npm test -- --watch で、cdk-nag を実行した例
45. cdk-nag の単体テスト Tips を以下記事にまとめました https://qiita.com/y_matsuo_/items/6ef17964ff3c557f6d1e 単体テスト でcdk-nagを適用すれば アサーションテストとの重複チェックも抑えられそう
46. デプロイ後の確認はどうする？ （スクラム開発事例に戻ります）
47. CDK デプロイ後の確認について  セキュリティ関連の構築がメインだが、デプロイ後環境をどこまで確認？  Config ルール（Control Tower 管理）でも設定不備を一部検知可  CFn ドリフトがなければアサーションテストの内容が担保されているはず  凝った自動テストは不要と判断し、手動テストを継続  IP 制限をしている静的サイトについては、CDK パイプラインで デプロイ後に curl 実行し、アクセス拒否されることを確認
48. CDK リソースチェックをまとめてみた 設計 実装 ビルド (cdk synth) デプロイ (cdk deploy) リリース 運用 スナップショットテスト Control Tower Proactive Controls アサーションテスト (実装→テスト) cdk-nag (UT) アサーションテスト (TDD) Config ルール デプロイ後テスト cdk-nag
49. 当チームで現在取り入れているのは太字箇所 設計 実装 ビルド (cdk synth) デプロイ (cdk deploy) リリース 運用 スナップショットテスト Control Tower Proactive Controls アサーションテスト (実装→テスト) cdk-nag (UT) アサーションテスト (TDD) Config ルール デプロイ後テスト cdk-nag
50. テスト関連で今後やりたいこと・気になっていること  cdk-nag ルールパックのカイゼン  カイゼンした cdk-nag ルールパックを単体テストに導入  Control Tower Proactive Controls の検討  生成系 AI の活用
51. まとめ  スナップショットテスト・cdk-nag は手軽に始められるのでオススメ  CDK でアサーションテスト・TDD の導入は、ちょっと大変かも →とはいえ、スクラム開発に取り入れたら、テストがない世界には戻れない！  Pros & Cons を踏まえて、CDK のテスト導入を検討しよう