Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWS CDKにテストは必要?試行錯誤したスクラム開発事例を紹介!/CdkConJp2023
Search
みずほリサーチ&テクノロジーズ株式会社 先端技術研究部
May 19, 2023
Technology
5
5.7k
AWS CDKにテストは必要?試行錯誤したスクラム開発事例を紹介!/CdkConJp2023
「AWS CDK Conference Japan 2023」での登壇資料です。
イベントURL:
https://jawsug-cdk.connpass.com/event/278205/
みずほリサーチ&テクノロジーズ株式会社 先端技術研究部
May 19, 2023
Tweet
Share
More Decks by みずほリサーチ&テクノロジーズ株式会社 先端技術研究部
See All by みずほリサーチ&テクノロジーズ株式会社 先端技術研究部
Kubernetes でワークフローを組むなら cdk8s-argoworkflow がよさそう!/ cdk8s-argoworkflow is great!
mhrtech
3
920
IaCでセキュリティを強化しよう!~IAMが苦手な開発者でも簡単に権限を絞れる。そう、AWS CDKならね!~/secjaws32
mhrtech
5
2.4k
AWS Control Towerを2年弱運用して得たエッセンスと展望/securityjaws31
mhrtech
1
1.5k
そのリファレンス誰のため?ユーザ活用に向き合う/finjaws31
mhrtech
0
590
Pandas卒業?大規模データを様々なパッケージで高速処理してみる/pyconjp2022-hpc
mhrtech
10
12k
閉域要件におけるS3周辺ポリシーの組み合わせ方
mhrtech
0
2.3k
閉域要件におけるEC2のアクセス制御 ~SaaS・PrivateLinkの罠とNetwork Firewallの活用~
mhrtech
0
3.4k
Other Decks in Technology
See All in Technology
歴史と背景から改めて振り返るVPC
shotashiratori
2
220
Dive Deep in Cloud Run: Automatic Base Image update
aoto
PRO
0
900
強いチームを夢見て-PMからSREに転身して1年の振り返り / 20240906_bengo4_sre
bengo4com
1
750
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
41k
2024年版 運用者たちのLLM
nwiizo
3
290
Namespace, Now and Then
tagomoris
0
170
エンジニア採用を起点に取り組む組織の改善活動と課題、中長期のタスク管理/ #HRmethod
nishiuma
4
3.3k
なぜクラウドサービスで Web コンソールを提供するのか
shuta13
4
1.3k
AWS IAM Identity Center議論会 〜 認証認可結合モデルと認証認可分離モデル / 20240827-jawsug-arch-iam_identity_center
opelab
3
320
音声AIエージェントの世界とRetell AI入門 / Introduction to the World of Voice AI Agents and Retell AI
rkaga
3
470
データウェアハウス製品のSnowflakeでPythonが動くって知ってました?
foursue
1
150
Discover Your Tailored Platform Strategy with Real-World Practice
hhiroshell
1
130
Featured
See All Featured
Ruby is Unlike a Banana
tanoku
96
10k
Pencils Down: Stop Designing & Start Developing
hursman
118
11k
What's new in Ruby 2.0
geeforr
340
31k
Building Your Own Lightsaber
phodgson
101
5.9k
In The Pink: A Labor of Love
frogandcode
139
22k
What the flash - Photography Introduction
edds
67
11k
BBQ
matthewcrist
83
9.1k
GitHub's CSS Performance
jonrohan
1029
450k
Being A Developer After 40
akosma
82
580k
Into the Great Unknown - MozCon
thekraken
28
1.4k
Code Reviewing Like a Champion
maltzj
518
39k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
157
15k
Transcript
AWS CDK にテストは必要? 試行錯誤したスクラム開発事例を紹介! 2023.5.20 AWS CDK Conference Japan 2023
Copyright (c) Mizuho Research & Technologies, Ltd. All Rights Reserved. (免責事項) 当資料は情報提供のみを目的として作成されたものであり、商品の勧誘を目的としたものではありません。 本資料は、当社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を 保証するものではありません。また、本資料に記載された内容は予告なしに変更されることもあります。
自己紹介 氏名: 松尾 優成(まつお ゆうせい) 所属: 先端技術研究部 兼
プロジェクト推進部 主な役割: 社内共通 AWS プラットフォームの構築・運用 休日の過ごし方: 0歳児の娘と戯れる! ビッグバンドでサックス演奏 (5/21, 池袋ジャズフェス2023に出演予定!)
これまで主にやってきたこと 2015年~ 勘定系周辺の システム開発・保守 (管理・調整が主) 2019年~ CCoE 活動 予防的統制 (サービス認定)
2020年~ 大型 AWS 案件の 設計・構築 (N/W・Security等) 2022年~現在 社内プラットフォーム 構築 (Platform as a Product) スクラム開発・ CDK(TypeScript)と 初めてのことだらけ!
本日話すこと • スクラム開発の取組概要 • AWS CDK の単体テスト • CDK におけるテスト駆動開発(TDD)
• cdk-nag 導入 ※ドメインロジックに関するアプリケーションのテストは本発表の対象外
スクラム開発の概要
社内プラットフォーム 社内プラットフォームのプロダクト概要 “安心して AWS の有用性を発揮し、 ビジネス価値の創造に素早く着手・集中できるプラットフォームを提供” ※AWS Summit Tokyo 2023
では、プラットフォームの他社事例が沢山出ていました AWS account A Control Tower ユーザー関連 セキュリティ AWS account B AWS account C 事前に整備された AWS アカウントを払い出し Azure AD
CDK で作っているものを一部紹介 Security 関連の共通リソース • CIS ルール違反検知(メトリクスフィルタ・アラーム) • 通知設定(EventBridge・SNS)
• CIS 不要ルールの無効化(Custom Resource) • 違反リソースの自動修復(SSM Automation) ※ AFT(Account Factory for Terraform)や CfCT で構築するのが主流かも? プラットフォーム利用者向け静的サイト(WAF・CloudFront・S3 etc...)
開発体制・内部事情 2021年末頃から、スクラム開発で構築 (チーム全員がスクラム初心者で、殆どのメンバーがCDK・TypeScript 初挑戦) Dev メンバーは流動的で、入替・人数の増減が激しい(2~8人) 全
Dev メンバーは他業務と兼務で、1人あたり50%以下の工数を捻出 ※アンチパターンなので非推奨 プロダクトの足元整理などで、開発停止期間が相応にある CDK に触れるのは 貴重な楽しい時間!
開発初期から CDK テスト導入までの経緯
初期は、プロダクトコードのみを書いていたが・・・ プロダクトコードの検証では、デプロイ後の手動テストが主体 スプリントが空き、久しぶりにコードをみると思い出すのに時間がかかった コーディングしたメンバーが離任し、用途不明なコード・コメントが残留
そんな中、以下イベントに出会う
吉川さんの以下発表で、危機を感じる 単体テスト・ スナップショットテスト どちらも未実施…💦 https://winteryukky.github.io/slides-look-back-3rd-year-cdk
CDK ベストプラクティスで単体テストの話を思い出す https://aws.amazon.com/jp/blogs/news/best-practices-for-developing-cloud-applications-with-aws-cdk/
CDK に単体テスト導入を決意!
CDK ワークショップで復習し、ガイドや docs を読む https://cdkworkshop.com/ja/20-typescript/70-advanced- topics/100-construct-testing.html
CDK の単体テストは、一般的に以下 3 種 No. 名称 概要 1 スナップショットテスト CDK
で生成された CFn テンプレートの断面を保持し、 前回実行時との差分を確認する。 2 アサーションテスト CDK で生成された CFn テンプレートが想定通りの値か、 確認する。 3 バリデーションテスト Construct で、無効な入力値を受け取った際の挙動を確認する。 自作のカスタム Construct をチーム外へ 配布はすることは当分なさそうだし、 バリデーションテストは一旦見送る?
スナップショットテスト・アサーションテストを取り入れることに (余談)2023年5月現在、開発者ガイドや CDK 実践勉強会には、バリデーションテストの紹介なし https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/testing.html No. 名称 概要 1 スナップショットテスト
CDK で生成された CFn テンプレートの断面を保持し、 前回実行時との差分を確認する。 2 アサーションテスト CDK で生成された CFn テンプレートが想定通りの値か、 確認する。 3 バリデーションテスト Construct で、無効な入力値を受け取った際の挙動を確認する。
スナップショットテストを導入してみる
お手軽に CFn テンプレートの断面を保持できた! https://qiita.com/y_matsuo_/items/3c12e4d745dbfe56d4ea 共通部を除くと 実質これだけ スナップショットの中身は 概ね CFn テンプレート
スナップショットテストの気づき 特に有用だと感じたのは、他のテストが全くない状態のリファクタリング (L3 → L2 Construct に移行した際など、効果を実感) CDK
バージョンアップの変更点を確認しやすい (cdk diff は別途実行推奨) 一方、実装が設計通りかは確認できない
アサーションテストを導入してみる 事例が少なく、苦戦・・・
アサーションテストのコードを書くのに、CFn の知識が必要 社内研修で CFn を学べることもあり、CFn に慣れたメンバーが多かった とはいえ、ネストの深い CFn
テンプレートは珍しくなく、序盤は苦戦した
どの粒度でアサーションテストを書くか悩む 設計通りになっているか確認する 一般論に沿って、1 つのテストケースで 1 項目を確認する https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/ testing.html#testing_tips
失敗要因が明確(テスト名から何が失敗したか分かる) リソース単位で各ケースをまとめる方がテスト工数は少ない 一方、設計は見えづらくなるので、方針次第
ワークショップ・べスプラでは Construct テストのみ紹介 CDK のデプロイ単位はスタックが該当 → 当チームでは、スタックのテストも実施 https://d1.awsstatic.com/webinars/jp/pdf/services/ 20200303_BlackBelt_CDK.pdf#page=46
カスタム Construct の確認が単体テストなら スタックの確認は結合テストと言えるかも?
(余談) カスタム 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)
アサーションテストの気づき テストコードにドキュメントとしての価値あり リソース数のチェックで、設計外のリソースを認識できた (ハイレベル Construct が裏側で Lambda 関数を使っているパターンなど)
変更容易性が高まり、MVP を拡張するスクラムとの相性がよい • リグレッションテストが容易で、追加実装が楽になった • スタックの分離や統合をする際も、テストが大きな支えとなった
アサーションテストが不要だと感じるパターン PoC などの検証 L1 Construct を宣言的に記述(繰り返し処理なし・単純な分岐のみ) Step
Functions など複雑な連携・フローを確認したいとき (後続の別テストで確認) テストコードに慣れるまでは どうしても工数が膨らむ・・・
CDK アサーションテストの書き方を以下記事にまとめました https://qiita.com/y_matsuo_/items/bc27db7942179ffb5825
アサーションテストのカイゼン
プロダクトコード作成後にテストコードを書いていたが・・・ 設計書にない項目まで実装・テストしていた 設計の実装漏れがデプロイ後に発覚する(特にセキュリティ関連) テストコードの記述で消化試合感が否めない(モチベ・・・) スプリントの進捗がカツカツの場合、テストコードが後回しにされがち ⇒
レトロスペクティブで Dev メンバー共通の課題となっていた セキュリティ機能を提供する側が セキュリティの考慮漏れ・・・
テスト駆動開発(TDD)を導入する Red テストと最低限の プロダクトコードで TEST FAIL Green 素早くコードを 修正し TEST
PASS Refactor 重複除去など リファクタリング https://www.youtube.com/ watch?v=Q-FJ3XmFlT8 とても分かりやすい!
CDK における TDD の効果① 設計書作成後、すぐにテスト項目を洗い出すので、実装漏れがない → 設計にないことを過剰に実装・テストすることがなくなった(YAGNI) 要件 すり合わせ
設計書 作成 テスト ToDo 洗い出し 実装 例) 副次効果で精度向上
CDK における TDD の効果② 重複除去により、『動作するきれいなコード』に近づいた パターン化されている箇所が、カスタム Construct になっていった
スタック SNS Topic ① Events Rule ① SNS Topic ② Events Rule ② 重複箇所を Construct 化 スタック カスタム Construct SNS Topic Events Rule カスタム Construct ① カスタム Construct ②
CDK における TDD の効果③ ハイレベル Construct の特徴である抽象化をより活用するようになった 初めて使う L2
Construct だけど 要件満たせるかな? L2 Construct 問題なさそう! テスト以外の項目は L2 Construct の デフォルト値に任せよう! 設計中 TDD 実践中
CDK における TDD の悩みどころ CFn テンプレートの出力が見えていないと厳しい (初めて触る AWS サービスなどは特に時間がかかる)
ネストの深い CFn テンプレートのテストを先に書くのは難しい CFn テンプレートのサジェストがないのもきつい → 最初から完璧なテストコードを目指さない! CFn テンプレートを生成し、先に構成をみてしまうのも手
悩みどころは多いものの、 TDD は CDK のベストプラクティス https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices- cdk-typescript-iac/development-best-practices.html CFn に慣れているなら 試しやすいのでオススメかも?
デプロイ前チェックのカイゼン
CDK のテストは定着したが・・・ 当社ガイドラインでは、共通のセキュリティ・コンプラ要件がある そもそも設計から上記要件が抜け落ちていたら、デプロイ後まで気づけない CDK の単体テストでは、スタックまでしかチェックしていない ⇒最上位の
app レイヤーで、デプロイ資産を一括チェックしたい レトロスペクティブで 新たな取り組み目標ができた!
cdk-nag を導入する cdk-nag とは、セキュリティ・コンプライアンスチェックできるツール (詳細は、過去の CDK 支部資料をご参照!) デプロイ時に違反リソースがあれば、デプロイを停止してくれる
(cdk synth でも同様に違反を教えてくれる) 設計 実装 ビルド (cdk synth) デプロイ (cdk deploy) リリース 運用 cdk-nag
cdk-nag の気づき お手軽に試せる!一方、AWS Solutions ルールパックはリッチすぎ? 基本ルールから独自ルールパックを作成し、設計漏れを抑制できた (社内ルールで、cdk-nag の基本ルールにハマらないものもでてきた)
cdk-nag のカスタムルールを書くよりは、アサーションテストの方が楽そう (全社的にCDKを使っているわけではないので、 ルール化は気が重い ) → ルール外の細かいセキュリティ設定はアサーションテストで確認することに
CDK における各テストの比較 No. 種類 主な恩恵 導入速度 難易度 1 スナップショットテスト ・手軽に差分確認
・いつでも始められる 速 低 2 cdk-nag ・違反リソース未然防止 ・設計漏れ抑制 速 中 3 アサーションテスト (実装→テスト) ・変更容易性が高い ・高信頼ドキュメント 中 中 4 アサーションテスト (TDD) ・上記恩恵 + YAGNI ・動作するきれいなコード 遅 高
テストコードで体力をかけずに 素早く構成チェックしたい場合はどうする? CDK で細かいアサーションテストを 書くのは躊躇う・・・ (余談)※スクラム開発事例ではないです
単体テストで 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/
プロダクトコードを保存する度に cdk-nag が自動実行! npm test -- --watch で、cdk-nag を実行した例
cdk-nag の単体テスト Tips を以下記事にまとめました https://qiita.com/y_matsuo_/items/6ef17964ff3c557f6d1e 単体テスト でcdk-nagを適用すれば アサーションテストとの重複チェックも抑えられそう
デプロイ後の確認はどうする? (スクラム開発事例に戻ります)
CDK デプロイ後の確認について セキュリティ関連の構築がメインだが、デプロイ後環境をどこまで確認? Config ルール(Control Tower 管理)でも設定不備を一部検知可
CFn ドリフトがなければアサーションテストの内容が担保されているはず 凝った自動テストは不要と判断し、手動テストを継続 IP 制限をしている静的サイトについては、CDK パイプラインで デプロイ後に curl 実行し、アクセス拒否されることを確認
CDK リソースチェックをまとめてみた 設計 実装 ビルド (cdk synth) デプロイ (cdk deploy)
リリース 運用 スナップショットテスト Control Tower Proactive Controls アサーションテスト (実装→テスト) cdk-nag (UT) アサーションテスト (TDD) Config ルール デプロイ後テスト cdk-nag
当チームで現在取り入れているのは太字箇所 設計 実装 ビルド (cdk synth) デプロイ (cdk deploy) リリース
運用 スナップショットテスト Control Tower Proactive Controls アサーションテスト (実装→テスト) cdk-nag (UT) アサーションテスト (TDD) Config ルール デプロイ後テスト cdk-nag
テスト関連で今後やりたいこと・気になっていること cdk-nag ルールパックのカイゼン カイゼンした cdk-nag ルールパックを単体テストに導入 Control
Tower Proactive Controls の検討 生成系 AI の活用
まとめ スナップショットテスト・cdk-nag は手軽に始められるのでオススメ CDK でアサーションテスト・TDD の導入は、ちょっと大変かも →とはいえ、スクラム開発に取り入れたら、テストがない世界には戻れない!
Pros & Cons を踏まえて、CDK のテスト導入を検討しよう