課題15: ゲーム会社のマルチ環境管理
難易度: 🟡 中級
1. 分類情報
| 項目 | 内容 |
|---|---|
| 難易度 | 中級 |
| カテゴリ | IaC・DevOps |
| 処理タイプ | バッチ |
| 使用IaC | CDK |
| 想定所要時間 | 5-6時間 |
2. シナリオ
企業プロフィール
〇〇株式会社は、モバイルゲームを開発・運営する企業です。主力タイトルは DAU(Daily Active Users)30万人を誇り、継続的なアップデートでユーザーを獲得しています。
現状の課題
急成長に伴い、インフラ管理が追いついていません:
- 環境間の差異:dev/stg/prodで設定が微妙に異なり、本番リリース時にトラブル発生
- 手動デプロイのリスク:本番環境へのデプロイは手動で実施、ヒューマンエラーのリスク
- インフラ変更の追跡困難:誰がいつ何を変更したか分からない
- スケーリング対応の遅れ:イベント時の負荷対応が後手に回る
数値で見る問題
- 環境差異によるリリース失敗:月 3件
- 手動デプロイ時間:1回あたり 2時間
- 本番インシデント(設定ミス起因):四半期 5件
- イベント時の緊急スケーリング対応:月 4回(各30分)
成功指標(KPI)
| 指標 | 現状 | 目標 |
|---|---|---|
| 環境差異起因のリリース失敗 | 3件/月 | 0件/月 |
| デプロイ時間 | 2時間 | 15分 |
| 設定ミス起因のインシデント | 5件/四半期 | 1件以下/四半期 |
| スケーリング対応時間 | 30分 | 自動化 |
3. 学習目標
主要な学習成果
- AWS CDKによる型安全なインフラ定義の習得
- CodePipelineを使った自動デプロイパイプラインの構築
- 環境別パラメータ管理とStage分離の実践
- Application Auto Scalingの設定方法
習得するスキル
- CDK Constructsの設計と実装
- cdk diff / cdk deploy の活用
- CodePipelineのステージ構成
- 承認フロー付きデプロイの実装
- Parameter Store / Secrets Manager連携
4. 使用するAWSサービス
コアサービス
| サービス | 用途 | 重要度 |
|---|---|---|
| AWS CDK | インフラのコード化 | 高 |
| CodePipeline | CI/CDパイプライン | 高 |
| CodeBuild | ビルド・テスト実行 | 高 |
| ECS Fargate | ゲームAPIサーバー実行 | 高 |
| Aurora Serverless v2 | ゲームデータベース | 高 |
| ElastiCache (Redis) | セッション・キャッシュ | 中 |
補助サービス
| サービス | 用途 |
|---|---|
| ECR | コンテナイメージ保存 |
| ALB | ロードバランシング |
| CloudWatch | ログ・メトリクス・アラーム |
| SNS | デプロイ通知 |
| SSM Parameter Store | 環境別パラメータ管理 |
| Secrets Manager | DB認証情報管理 |
5. 前提条件
必要な知識
- TypeScriptの基本文法
- AWSの基本サービス理解(VPC、ECS、RDS)
- Dockerの基本操作
事前準備
- AWSアカウント
- Node.js v18以上
- AWS CLI v2
- Docker Desktop
- VS Code + AWS Toolkit拡張機能
環境要件
bash
# CDKインストール
npm install -g aws-cdk
# バージョン確認
cdk --version # 2.x 以上6. アーキテクチャ概要
システム構成図
| コンポーネント | 役割 |
|---|---|
| GitHub | ソースコードリポジトリ |
| CodeBuild | ビルド・テスト実行 |
| Dev/Stg/Prod Deploy | 各環境へのデプロイ(Stg/Prodは承認必要) |
| ALB | Application Load Balancer |
| ECS | Fargate コンテナ実行(環境別タスク数) |
| Aurora | Aurora Serverless v2(環境別ACU) |
| Redis | ElastiCache Redis(セッション・キャッシュ) |
環境別構成
| 項目 | Development | Staging | Production |
|---|---|---|---|
| ECS タスク数 | 1 | 2 | 4-20 (Auto Scaling) |
| Aurora ACU | 0.5 | 1 | 2-16 (Auto Scaling) |
| Redis ノード | cache.t3.micro | cache.t3.small | cache.r6g.large |
| デプロイ承認 | 不要 | 必要 | 必要(2名) |
7. トラブルシューティング課題
Challenge 1: CDK Diffが予期せぬ変更を検出
状況: リソースを変更していないのに、cdk diffで大量の変更が表示される
[-] AWS::ECS::Service GameApiService/Service
[+] AWS::ECS::Service GameApiService/Service
Resources
[~] AWS::ECS::Service GameApiService/Service ...
└─ [~] TaskDefinition
└─ [~] .Fn::Join:
└─ @@ -1,6 +1,6 @@調査ポイント:
- CDK/AWS SDK のバージョン差異
- Context値の違い(cdk.context.json)
- Logical IDの変更
解決手順:
bash
# contextをリセット
rm cdk.context.json
cdk synth
# バージョンを固定
npm install aws-cdk-lib@2.100.0 --save-exactChallenge 2: ECS タスクがヘルスチェックに失敗
状況: デプロイ後、タスクが起動するが即座に停止する
調査ポイント:
- CloudWatch Logsでアプリケーションログを確認
- ターゲットグループのヘルスチェック設定
- セキュリティグループのルール
解決コマンド例:
bash
# タスクの停止理由を確認
aws ecs describe-tasks --cluster gamestudio-dev \
--tasks $(aws ecs list-tasks --cluster gamestudio-dev --desired-status STOPPED --query 'taskArns[0]' --output text) \
--query 'tasks[0].stoppedReason'Challenge 3: Aurora Serverless v2のスケーリングが間に合わない
状況: 急激な負荷増加時にデータベース接続エラーが発生
調査ポイント:
- ACUの最小/最大設定を確認
- CloudWatchでACU使用率を監視
- スケーリング速度の限界を理解
8. 設計考慮ポイント
ディスカッション1: CDK vs Terraform
テーマ: IaCツールの選定基準
| 観点 | CDK | Terraform |
|---|---|---|
| 学習コスト | プログラミング経験者なら低い | HCL学習が必要 |
| 型安全性 | TypeScriptで高い | terraform validate依存 |
| マルチクラウド | AWS特化 | 対応 |
| 抽象化レベル | 高い(Constructs) | 低い(宣言的) |
| チーム規模 | 小〜中規模向け | 大規模向け |
ディスカッション2: 環境分離戦略
テーマ: 同一アカウント内分離 vs アカウント分離
選択肢:
- 同一アカウント・VPC分離: シンプルだがセキュリティ境界が弱い
- 同一アカウント・名前空間分離: タグとIAMで分離
- マルチアカウント: 最も安全だが運用複雑
ディスカッション3: ブルーグリーン vs ローリングアップデート
テーマ: ECSのデプロイ戦略
| 戦略 | メリット | デメリット |
|---|---|---|
| ローリング | リソース効率が良い | ロールバックに時間がかかる |
| ブルーグリーン | 即座にロールバック可能 | 一時的に2倍のリソースが必要 |
9. 発展課題
Advanced 1: カナリアデプロイの実装
課題: 新バージョンを10%のトラフィックに限定してデプロイし、問題なければ100%に展開
Advanced 2: Feature Flag連携
課題: AWS AppConfig と連携して、デプロイとリリースを分離
Advanced 3: DR環境の自動構築
課題: 別リージョンにDR環境をCDKで自動構築し、定期的にフェイルオーバーテストを実行
10. 想定コストと削減方法
月額コスト概算
| 環境 | サービス | 構成 | 月額コスト |
|---|---|---|---|
| Dev | ECS Fargate | 0.25 vCPU / 0.5GB × 1 | $9 |
| Aurora Serverless v2 | 0.5 ACU | $43 | |
| ElastiCache | cache.t3.micro | $12 | |
| NAT Gateway | 1 × 730h | $32 | |
| ALB | 1 | $16 | |
| 小計 | $112 | ||
| Stg | ECS Fargate | 0.5 vCPU / 1GB × 2 | $36 |
| Aurora Serverless v2 | 1 ACU | $86 | |
| ElastiCache | cache.t3.small | $24 | |
| NAT Gateway | 1 × 730h | $32 | |
| ALB | 1 | $16 | |
| 小計 | $194 | ||
| Prod | ECS Fargate | 1 vCPU / 2GB × 4-20 | $144-720 |
| Aurora Serverless v2 | 2-16 ACU | $173-1,382 | |
| ElastiCache | cache.r6g.large × 2 | $219 | |
| NAT Gateway | 3 × 730h | $97 | |
| ALB | 1 | $16 | |
| 小計 | $649-2,434 | ||
| Pipeline | CodePipeline | 1 | $1 |
| CodeBuild | ビルド時間依存 | $10 | |
| ECR | イメージ保存 | $5 | |
| 小計 | $16 |
合計: 約 $971-2,756/月(約145,000-413,000円)
コスト削減のヒント
- Dev/Stg環境の夜間停止: スケジュールベースでタスク数を0に
- Aurora Auto Pause: 開発環境でアイドル時に自動停止(Serverless v1のみ)
- Savings Plans: Fargateの長期コミットメント割引
11. 学習のポイント
重要な概念の整理
CDK Constructs
- L1: CloudFormation直接マッピング(Cfn*)
- L2: 高レベル抽象化(便利なデフォルト付き)
- L3: パターン(複数リソースの組み合わせ)
環境分離のベストプラクティス
- 設定は外部化(環境変数、Parameter Store)
- 同じコードベースから全環境をデプロイ
- 差異は設定ファイルで吸収
CI/CDパイプライン設計
- 自動テストをゲートに
- 本番前の承認フロー
- ロールバック手段の確保
GCPとの比較
| 概念 | AWS | GCP |
|---|---|---|
| IaC (コード型) | CDK | Pulumi / CDK for Terraform |
| CI/CD | CodePipeline | Cloud Build / Cloud Deploy |
| コンテナ実行 | ECS Fargate | Cloud Run |
| マネージドDB | Aurora Serverless | Cloud SQL / AlloyDB |
| キャッシュ | ElastiCache | Memorystore |
次のステップ
- カナリアデプロイの実装
- 負荷テスト自動化の追加
- マルチリージョン展開