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.
   （免責事項）
   当資料は情報提供のみを目的として作成されたものであり、商品の勧誘を目的としたものではありません。
   本資料は、当社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を
   保証するものではありません。また、本資料に記載された内容は予告なしに変更されることもあります。
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. スクラム開発の概要
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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 で、無効な入力値を受け取った際の挙動を確認する。
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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）
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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/
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide