20260530_JAWSUG彩の国埼玉支部1周年記念

Transcript

1. あの時のCFN設計思想は 正しかったのか 2026/5/30 JAWS UG 彩の国埼玉支部1周年記念 わかばやし ～大規模開発のcfnスタック管理のあるべきを考えたい～
2. 2 JAWS-UG 彩の国埼玉支部一周年 おめでとうございます！！ 埼玉県在住で勝手にご縁を感じて 申込参加させていただきました！ まずはじめに
3. 3 本日のテーマ 「適切なcfnスタック分割軸って何？？」 3月末まで関与してたシステム開発PJでの CFN設計開発の反省・改善点を考えてみました！ （あくまで所属PJならどうするべきだったか、 の一意見なので、お手柔らかにお願いします！
4. 4 ジョブ管理 基幹App/DB 現行システムの老朽化に伴い、ローコードツールを駆使してEKSとRDSで基幹システムを構築・オンプレと接続。 その他認証基盤・DWH・大規模並列処理基盤・監視基盤etcで利用する外部サービスと接続する超ハイブリッド構成。 前提 クラウド・オンプレ・PaaSを繋ぐ大規模ハイブリッド構成を1から立ち上げる！ セキュリティ ファイル連携 並列処理基盤 認証基盤 DWH ネットワーク リリース管理
5. 5 設計フェーズではAWSサービス単位で設計方針・パラメータを整理。 それに伴ってcfnスタックも「S3」「IAM」「EC2」といった形で、サービス種別単位で作成。 設計思想・方針 AWSサービス種別単位でスタックを分割 AWS基本設計 EC2 EKS S3 ・・・ サービスA 基本設計 サービスB 基本設計 AWS詳細設計 EC2 Ctrl Plane S3_01 ・・・ サービスA 詳細設計 サービスB 詳細設計 Worker Node S3_02 Ec2.yaml ctrlplaene.yaml workernode.yaml S3_01.yaml S3_02.yaml 方針書 オンライン機能 リリース管理 運用管理 セキュリティ 非機能要件定義書 要件定義 基本設計・詳細設計・Yamlテンプレート Yamlファイル群
6. 6 設計フェーズではAWSサービス単位で設計方針・パラメータを整理。 それに伴ってcfnスタックも「S3」「IAM」「EC2」といった形で、サービス種別単位で作成。 設計思想・方針 AWSサービス種別単位でスタックを分割 AWS基本設計 EC2 EKS S3 ・・・ サービスA 基本設計 サービスB 基本設計 AWS詳細設計 EC2 Ctrl Plane S3_01 ・・・ サービスA 詳細設計 サービスB 詳細設計 Worker Node S3_02 Ec2.yaml ctrlplaene.yaml workernode.yaml S3_01.yaml S3_02.yaml 方針書 オンライン機能 リリース管理 運用管理 セキュリティ 非機能要件定義書 要件定義 基本設計・詳細設計・Yamlテンプレート Yamlファイル群 リソースを分類しているだけで、 依存関係を設計・可視化出来ていない！
7. 7 IAM作成後でなければEC2・EKS・Lambdaが作成出来ない等、各スタックの依存関係が複雑化。 それに伴い、構築スピードの低下やリソースの相互依存による非効率なオペレーションが発生。 発生した問題① スタック・リソースの依存関係の複雑化・構築スピード低下 EKS IAMロール Lambda IAMロール 外部サービス IAMロール EKS Control Plane Lambda Cfnスタック EKS CfnスタックLambda 外部サービスのセットアップ IAMスタックの中で外部サービス用のIAMロールの作成に失敗すると、、 Cfnスタック IAM
8. 8 IAM作成後でなければEC2・EKS・Lambdaが作成出来ない等、各スタックの依存関係が複雑化。 それに伴い、構築スピードの低下やリソースの相互依存による非効率なオペレーションが発生。 発生した問題① スタック・リソースの依存関係の複雑化・構築スピード低下 EKS IAMロール Lambda IAMロール 外部サービス IAMロール EKS Control Plane Lambda Cfnスタック EKS CfnスタックLambda 外部サービスのセットアップ IAMスタック自体を作り直す必要があるため、他のリソース作成にも影響が発生 Cfnスタック IAM
9. 9 IAMやS3といった最下層の基盤リソースは往々にしてその後の構築フェーズにて改修が発生する。 サービス単位でスタックを分割している場合、各機能の構築チームで改修要望がバッティングして無駄な待ち時間やチーム間 のコミュニケーションコストが発生する。 発生した問題② コミュニケーションコスト・無駄な待機時間が発生 EKS構築にはXXXX権限の追加が 必要だと分かりました。 IAMポリシーの修正をお願いします。 外部サービスの構築のため、 IAMの信頼ポリシーに XXXを追加してください。 どちらも修正対応を行ってから両チー ムに連絡する？ EKS権限の修正の方が簡単そうなので まずはそっちから対応する、、？ AWS構築チーム App基盤構築チーム 外部サービス構築 チーム
10. 10 IAMやS3といった最下層の基盤リソースは往々にしてその後の構築フェーズにて改修が発生する。 サービス単位でスタックを分割している場合、各機能の構築チームで改修要望がバッティングして無駄な待ち時間やチーム間 のコミュニケーションコストが発生する。 発生した問題② コミュニケーションコスト・無駄な待機時間が発生 EKS構築にはXXXX権限の追加が 必要だと分かりました。 IAMポリシーの修正をお願いします。 外部サービスの構築のため、 IAMの信頼ポリシーに XXXを追加してください。 どちらも修正対応を行ってから両チー ムに連絡する？ EKS権限の修正の方が簡単そうなので まずはそっちから対応する、、？ AWS構築チーム App基盤構築チーム 外部サービス構築 チーム 不要なコミュニケーション・待ち時間が発生！ （チーム分担が明確化していない場合は修正に競合が発生することも、、）
11. 11 各スタック間での相互参照や循環参照により、スタックの二重更新等の無駄なオペレーションが発生。 発生した問題③ スタック間の循環参照やパラメータ出力漏れ等により無駄なオペレーションが発生 スタック間での循環参照 スタック間での参照 Cfn IAM KMS Key を指定 Cfn KMS IAM Role を指定 相互 参照 リソースの相互参照により 同一スタックを複数回更新して 段階的にリソースを作成する必要有 Cfn EventBridge IAMのSSM Parameter指定 Cfn IAM 参照したいSSM Parameterが存在せず、 別スタックを追加で更新する必要有
12. 12 では、“スケールするスタック設計”とは何か？
13. 13 AWSのベストプラクティスをまずは見てみる 「ライフサイクル」 と 「所有権」 に応じたスタックの整理 各層をその直下の層に依存させる 「多層アーキテクチャ」 各スタックで目的・機能を 自己充足させる 「サービス指向アーキテクチャ」 CloudFormation ベストプラクティス - AWS CloudFormation
14. 14 設計フェーズではAWS単位で設計をするのではなく、方針書で定義したシステム項目単位や 各項目で利用している外部サービス単位で設計を実施。各設計内の「AWS環境設計」として各AWSサービスの設計を行う。 解決策 設計フェーズでは要件定義で定義したシステム機能/ライフサイクル単位で設計 App基盤 基本設計 EKS IAM ・・・ 監視基盤 基本設計 App_infra.yaml Monitoring_infra. yaml 方針書 オンライン機能 リリース管理 運用管理 セキュリティ 非機能要件定義書 要件定義 基本設計・Yamlテンプレート 外部サービスA設計 AWS環境設計 IAM S3 ・・ ・・・ Yamlファイル群
15. 15 設計フェーズではAWS単位で設計をするのではなく、方針書で定義したシステム項目単位や各項目で利用している 外部サービス単位で設計を実施。各設計内の「AWS環境設計」として各AWSサービスの設計を行う。 解決策 設計フェーズでは要件定義で定義したシステム機能/ライフサイクル単位で設計 App基盤 基本設計 EKS IAM ・・・ 監視基盤 基本設計 App_infra.yaml Monitoring_infra. yaml 方針書 オンライン機能 リリース管理 運用管理 セキュリティ 非機能要件定義書 要件定義 基本設計・Yamlテンプレート 外部サービスA設計 AWS環境設計 IAM S3 ・・ ・・・ Yamlファイル群 各システム機能ごとの リソース間の依存関係をふまえて 適切な粒度で設計！
16. 16 機能単位でスタックを分割することで、リソース間の依存関係を局所化し、変更の影響範囲をコントロール可能にする。 これにより、各機能の構築チーム/担当者間の無駄なコミュニケーションや待ち時間を減らすことが可能。 期待される効果 ライフサイクル単位で適切な粒度でスタックを分割することで責任・影響範囲を分割する。 EKS IAMロール Cfnスタック （App基盤） EKS Control Plane App用ストレージ Lambda IAMロール Cfnスタック （Lambda） Lambda Lambda処理結果出力用 外部サービス用IAMロール Cfnスタック (外部サービス) 外部サービスログ出力用 外部サービス連携用 外部サービス用だけ 再作成 他機能には影響がないため 他リソースの作成は 進めることが可能！ 一部のIAM作成に失敗しても影響範囲が関連機能・リソースに留まる
17. 17 スタック間で発生していた依存関係を同一スタック内に集約することで参照関係を簡素化し、変更時の影響範囲を局所化する。 期待される効果 依存関係の境界をスタック境界で設計する スタック間での循環参照 スタック間での参照 Cfn 機能群A KMS Key を指定 IAM Role を指定 相互 参照 同一スタック内で 各リソースを参照可能であるため、 無駄なオペレーションが発生しない Cfn EventBridge IAMを指定 リソース間依存を 同一スタック内で吸収することで、 参照パラメータの管理を簡素化
18. 18 まとめ Cfnスタックはサービス単位ではなくライフサイクル単位で分割 リソース間の依存関係を簡素化し、構築を効率化！
19. おわり ご清聴ありがとうございました！