Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

    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 ②
    重複箇所を
    Construct 化
    スタック カスタム
    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