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

Slide 1

Slide 1 text

AWS CDK にテストは必要？試行錯誤したスクラム開発事例を紹介！ 2023.5.20 AWS CDK Conference Japan 2023 Copyright (c) Mizuho Research & Technologies, Ltd. All Rights Reserved. （免責事項）当資料は情報提供のみを目的として作成されたものであり、商品の勧誘を目的としたものではありません。本資料は、当社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を保証するものではありません。また、本資料に記載された内容は予告なしに変更されることもあります。

Slide 2

Slide 2 text

自己紹介  氏名：松尾優成（まつおゆうせい）  所属：先端技術研究部兼プロジェクト推進部  主な役割：社内共通 AWS プラットフォームの構築・運用  休日の過ごし方：  0歳児の娘と戯れる！  ビッグバンドでサックス演奏（5/21, 池袋ジャズフェス2023に出演予定！）

Slide 3

Slide 3 text

これまで主にやってきたこと 2015年～勘定系周辺のシステム開発・保守 (管理・調整が主) 2019年～ CCoE 活動予防的統制 (サービス認定) 2020年～大型 AWS 案件の設計・構築 (N/W・Security等) 2022年～現在社内プラットフォーム構築 (Platform as a Product) スクラム開発・ CDK(TypeScript)と初めてのことだらけ！

Slide 4

Slide 4 text

本日話すこと • スクラム開発の取組概要 • AWS CDK の単体テスト • CDK におけるテスト駆動開発（TDD） • cdk-nag 導入 ※ドメインロジックに関するアプリケーションのテストは本発表の対象外

Slide 5

Slide 5 text

スクラム開発の概要

Slide 6

Slide 6 text

社内プラットフォーム社内プラットフォームのプロダクト概要 “安心して AWS の有用性を発揮し、ビジネス価値の創造に素早く着手・集中できるプラットフォームを提供” ※AWS Summit Tokyo 2023 では、プラットフォームの他社事例が沢山出ていました AWS account A Control Tower ユーザー関連セキュリティ AWS account B AWS account C 事前に整備された AWS アカウントを払い出し Azure AD

Slide 7

Slide 7 text

CDK で作っているものを一部紹介  Security 関連の共通リソース • CIS ルール違反検知（メトリクスフィルタ・アラーム） • 通知設定（EventBridge・SNS） • CIS 不要ルールの無効化（Custom Resource） • 違反リソースの自動修復（SSM Automation） ※ AFT（Account Factory for Terraform）や CfCT で構築するのが主流かも？  プラットフォーム利用者向け静的サイト（WAF・CloudFront・S3 etc...）

Slide 8

Slide 8 text

開発体制・内部事情  2021年末頃から、スクラム開発で構築（チーム全員がスクラム初心者で、殆どのメンバーがCDK・TypeScript 初挑戦）  Dev メンバーは流動的で、入替・人数の増減が激しい（2～8人）  全 Dev メンバーは他業務と兼務で、1人あたり50%以下の工数を捻出 ※アンチパターンなので非推奨  プロダクトの足元整理などで、開発停止期間が相応にある CDK に触れるのは貴重な楽しい時間！

Slide 9

Slide 9 text

開発初期から CDK テスト導入までの経緯

Slide 10

Slide 10 text

初期は、プロダクトコードのみを書いていたが・・・  プロダクトコードの検証では、デプロイ後の手動テストが主体  スプリントが空き、久しぶりにコードをみると思い出すのに時間がかかった  コーディングしたメンバーが離任し、用途不明なコード・コメントが残留

Slide 11

Slide 11 text

そんな中、以下イベントに出会う

Slide 12

Slide 12 text

吉川さんの以下発表で、危機を感じる単体テスト・スナップショットテストどちらも未実施…💦 https://winteryukky.github.io/slides-look-back-3rd-year-cdk

Slide 13

Slide 13 text

CDK ベストプラクティスで単体テストの話を思い出す https://aws.amazon.com/jp/blogs/news/best-practices-for-developing-cloud-applications-with-aws-cdk/

Slide 14

Slide 14 text

CDK に単体テスト導入を決意！

Slide 15

Slide 15 text

CDK ワークショップで復習し、ガイドや docs を読む https://cdkworkshop.com/ja/20-typescript/70-advanced- topics/100-construct-testing.html

Slide 16

Slide 16 text

CDK の単体テストは、一般的に以下 3 種 No. 名称概要 1 スナップショットテスト CDK で生成された CFn テンプレートの断面を保持し、前回実行時との差分を確認する。 2 アサーションテスト CDK で生成された CFn テンプレートが想定通りの値か、確認する。 3 バリデーションテスト Construct で、無効な入力値を受け取った際の挙動を確認する。自作のカスタム Construct をチーム外へ配布はすることは当分なさそうだし、バリデーションテストは一旦見送る？

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

スナップショットテストを導入してみる

Slide 19

Slide 19 text

お手軽に CFn テンプレートの断面を保持できた！ https://qiita.com/y_matsuo_/items/3c12e4d745dbfe56d4ea 共通部を除くと実質これだけスナップショットの中身は概ね CFn テンプレート

Slide 20

Slide 20 text

スナップショットテストの気づき  特に有用だと感じたのは、他のテストが全くない状態のリファクタリング（L3 → L2 Construct に移行した際など、効果を実感）  CDK バージョンアップの変更点を確認しやすい（cdk diff は別途実行推奨）  一方、実装が設計通りかは確認できない

Slide 21

Slide 21 text

アサーションテストを導入してみる事例が少なく、苦戦・・・

Slide 22

Slide 22 text

アサーションテストのコードを書くのに、CFn の知識が必要  社内研修で CFn を学べることもあり、CFn に慣れたメンバーが多かった  とはいえ、ネストの深い CFn テンプレートは珍しくなく、序盤は苦戦した

Slide 23

Slide 23 text

どの粒度でアサーションテストを書くか悩む  設計通りになっているか確認する  一般論に沿って、1 つのテストケースで 1 項目を確認する https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/ testing.html#testing_tips 失敗要因が明確（テスト名から何が失敗したか分かる）リソース単位で各ケースをまとめる方がテスト工数は少ない一方、設計は見えづらくなるので、方針次第

Slide 24

Slide 24 text

ワークショップ・べスプラでは Construct テストのみ紹介  CDK のデプロイ単位はスタックが該当 → 当チームでは、スタックのテストも実施 https://d1.awsstatic.com/webinars/jp/pdf/services/ 20200303_BlackBelt_CDK.pdf#page=46 カスタム Construct の確認が単体テストならスタックの確認は結合テストと言えるかも？

Slide 25

Slide 25 text

(余談) カスタム 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）

Slide 26

Slide 26 text

アサーションテストの気づき  テストコードにドキュメントとしての価値あり  リソース数のチェックで、設計外のリソースを認識できた（ハイレベル Construct が裏側で Lambda 関数を使っているパターンなど）  変更容易性が高まり、MVP を拡張するスクラムとの相性がよい • リグレッションテストが容易で、追加実装が楽になった • スタックの分離や統合をする際も、テストが大きな支えとなった

Slide 27

Slide 27 text

アサーションテストが不要だと感じるパターン  PoC などの検証  L1 Construct を宣言的に記述（繰り返し処理なし・単純な分岐のみ）  Step Functions など複雑な連携・フローを確認したいとき（後続の別テストで確認）テストコードに慣れるまではどうしても工数が膨らむ・・・

Slide 28

Slide 28 text

CDK アサーションテストの書き方を以下記事にまとめました https://qiita.com/y_matsuo_/items/bc27db7942179ffb5825

Slide 29

Slide 29 text

アサーションテストのカイゼン

Slide 30

Slide 30 text

プロダクトコード作成後にテストコードを書いていたが・・・  設計書にない項目まで実装・テストしていた  設計の実装漏れがデプロイ後に発覚する（特にセキュリティ関連）  テストコードの記述で消化試合感が否めない（モチベ・・・）  スプリントの進捗がカツカツの場合、テストコードが後回しにされがち ⇒ レトロスペクティブで Dev メンバー共通の課題となっていたセキュリティ機能を提供する側がセキュリティの考慮漏れ・・・

Slide 31

Slide 31 text

テスト駆動開発（TDD）を導入する Red テストと最低限のプロダクトコードで TEST FAIL Green 素早くコードを修正し TEST PASS Refactor 重複除去などリファクタリング https://www.youtube.com/ watch?v=Q-FJ3XmFlT8 とても分かりやすい！

Slide 32

Slide 32 text

CDK における TDD の効果①  設計書作成後、すぐにテスト項目を洗い出すので、実装漏れがない → 設計にないことを過剰に実装・テストすることがなくなった（YAGNI）要件すり合わせ設計書作成テスト ToDo 洗い出し実装例）副次効果で精度向上

Slide 33

Slide 33 text

CDK における TDD の効果②  重複除去により、『動作するきれいなコード』に近づいた  パターン化されている箇所が、カスタム Construct になっていったスタック SNS Topic ① Events Rule ① SNS Topic ② Events Rule ② 重複箇所をＣonstruct 化スタックカスタム Construct SNS Topic Events Rule カスタム Construct ① カスタム Construct ②

Slide 34

Slide 34 text

CDK における TDD の効果③  ハイレベル Construct の特徴である抽象化をより活用するようになった初めて使う L2 Construct だけど要件満たせるかな？ L2 Construct 問題なさそう！テスト以外の項目は L2 Construct のデフォルト値に任せよう！設計中 TDD 実践中

Slide 35

Slide 35 text

CDK における TDD の悩みどころ  CFn テンプレートの出力が見えていないと厳しい（初めて触る AWS サービスなどは特に時間がかかる）  ネストの深い CFn テンプレートのテストを先に書くのは難しい  CFn テンプレートのサジェストがないのもきつい → 最初から完璧なテストコードを目指さない！ CFn テンプレートを生成し、先に構成をみてしまうのも手

Slide 36

Slide 36 text

悩みどころは多いものの、 TDD は CDK のベストプラクティス https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices- cdk-typescript-iac/development-best-practices.html CFn に慣れているなら試しやすいのでオススメかも？

Slide 37

Slide 37 text

デプロイ前チェックのカイゼン

Slide 38

Slide 38 text

CDK のテストは定着したが・・・  当社ガイドラインでは、共通のセキュリティ・コンプラ要件がある  そもそも設計から上記要件が抜け落ちていたら、デプロイ後まで気づけない  CDK の単体テストでは、スタックまでしかチェックしていない ⇒最上位の app レイヤーで、デプロイ資産を一括チェックしたいレトロスペクティブで新たな取り組み目標ができた！

Slide 39

Slide 39 text

cdk-nag を導入する  cdk-nag とは、セキュリティ・コンプライアンスチェックできるツール（詳細は、過去の CDK 支部資料をご参照！）  デプロイ時に違反リソースがあれば、デプロイを停止してくれる（cdk synth でも同様に違反を教えてくれる）設計実装ビルド (cdk synth) デプロイ (cdk deploy) リリース運用 cdk-nag

Slide 40

Slide 40 text

cdk-nag の気づき  お手軽に試せる！一方、AWS Solutions ルールパックはリッチすぎ？  基本ルールから独自ルールパックを作成し、設計漏れを抑制できた (社内ルールで、cdk-nag の基本ルールにハマらないものもでてきた)  cdk-nag のカスタムルールを書くよりは、アサーションテストの方が楽そう（全社的にCDKを使っているわけではないので、ルール化は気が重い） → ルール外の細かいセキュリティ設定はアサーションテストで確認することに

Slide 41

Slide 41 text

CDK における各テストの比較 No. 種類主な恩恵導入速度難易度 1 スナップショットテスト・手軽に差分確認・いつでも始められる速低 2 cdk-nag ・違反リソース未然防止・設計漏れ抑制速中 3 アサーションテスト（実装→テスト）・変更容易性が高い・高信頼ドキュメント中中 4 アサーションテスト（TDD）・上記恩恵 + YAGNI ・動作するきれいなコード遅高

Slide 42

Slide 42 text

テストコードで体力をかけずに素早く構成チェックしたい場合はどうする？ CDK で細かいアサーションテストを書くのは躊躇う・・・（余談）※スクラム開発事例ではないです

Slide 43

Slide 43 text

単体テストで 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/

Slide 44

Slide 44 text

プロダクトコードを保存する度に cdk-nag が自動実行！  npm test -- --watch で、cdk-nag を実行した例

Slide 45

Slide 45 text

cdk-nag の単体テスト Tips を以下記事にまとめました https://qiita.com/y_matsuo_/items/6ef17964ff3c557f6d1e 単体テストでcdk-nagを適用すればアサーションテストとの重複チェックも抑えられそう

Slide 46

Slide 46 text

デプロイ後の確認はどうする？（スクラム開発事例に戻ります）

Slide 47

Slide 47 text

CDK デプロイ後の確認について  セキュリティ関連の構築がメインだが、デプロイ後環境をどこまで確認？  Config ルール（Control Tower 管理）でも設定不備を一部検知可  CFn ドリフトがなければアサーションテストの内容が担保されているはず  凝った自動テストは不要と判断し、手動テストを継続  IP 制限をしている静的サイトについては、CDK パイプラインでデプロイ後に curl 実行し、アクセス拒否されることを確認

Slide 48

Slide 48 text

CDK リソースチェックをまとめてみた設計実装ビルド (cdk synth) デプロイ (cdk deploy) リリース運用スナップショットテスト Control Tower Proactive Controls アサーションテスト (実装→テスト) cdk-nag (UT) アサーションテスト (TDD) Config ルールデプロイ後テスト cdk-nag

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

テスト関連で今後やりたいこと・気になっていること  cdk-nag ルールパックのカイゼン  カイゼンした cdk-nag ルールパックを単体テストに導入  Control Tower Proactive Controls の検討  生成系 AI の活用

Slide 51

Slide 51 text

まとめ  スナップショットテスト・cdk-nag は手軽に始められるのでオススメ  CDK でアサーションテスト・TDD の導入は、ちょっと大変かも →とはいえ、スクラム開発に取り入れたら、テストがない世界には戻れない！  Pros & Cons を踏まえて、CDK のテスト導入を検討しよう