課題17: ニュースメディアのCMS基盤
難易度: 🟡 中級
1. 分類情報
| 項目 | 内容 |
|---|---|
| 難易度 | 中級 |
| カテゴリ | コンテナ |
| 処理タイプ | リアルタイム |
| 使用IaC | Terraform |
| 想定所要時間 | 5-6時間 |
2. シナリオ
企業プロフィール
〇〇株式会社は、政治・経済・スポーツなど幅広いジャンルのニュースを配信するオンラインメディアです。月間PVは1,000万を超え、速報ニュース配信時には瞬間的に10倍以上のアクセスが発生します。
現状の課題
オンプレミスのCMSサーバーでは、急激なトラフィック増加に対応できていません：
- スパイク対応の遅れ：速報時にサーバーがダウンし、機会損失が発生
- コンテンツ配信の遅延：画像・動画が重く、ページ読み込みが遅い
- 可用性の問題：単一障害点があり、メンテナンス時にサービス停止
- 運用負荷：サーバーの手動管理に工数を取られている
数値で見る問題
- 速報時のダウン回数：月 3回
- ページ読み込み時間：平均 4秒
- 可用性（SLA）：99.0%（目標99.9%）
- サーバー管理工数：月 40時間
成功指標（KPI）
| 指標 | 現状 | 目標 |
|---|---|---|
| スパイク時ダウン | 3回/月 | 0回 |
| ページ読み込み時間 | 4秒 | 1秒以下 |
| 可用性 | 99.0% | 99.9% |
| 運用工数 | 40時間/月 | 10時間/月 |
3. 学習目標
主要な学習成果
- ECS Fargateによるコンテナベースアプリケーションの構築
- CloudFrontとS3を組み合わせたコンテンツ配信最適化
- Aurora Serverlessによるスケーラブルなデータベース構築
- Application Auto Scalingによる自動スケーリング
習得するスキル
- ECS タスク定義とサービス設計
- CloudFront Cache Policy の設定
- S3 への静的アセット保存
- Auto Scaling ポリシーの設計
4. 使用するAWSサービス
コアサービス
| サービス | 用途 | 重要度 |
|---|---|---|
| ECS Fargate | CMS アプリケーション実行 | 高 |
| Aurora Serverless v2 | コンテンツデータベース | 高 |
| CloudFront | CDN・コンテンツ配信 | 高 |
| S3 | 画像・動画ストレージ | 高 |
| ALB | ロードバランシング | 高 |
補助サービス
| サービス | 用途 |
|---|---|
| ElastiCache (Redis) | セッション・キャッシュ |
| ECR | コンテナイメージ保存 |
| CloudWatch | ログ・メトリクス |
| WAF | セキュリティ |
| Route 53 | DNS管理 |
5. 最終構成図
| コンポーネント | 役割 |
|---|---|
| User | ユーザー（コンテンツにアクセス） |
| CloudFront | CDN（コンテンツ配信・キャッシュ） |
| S3 Static | 静的アセット（画像・CSS・JS）の保存 |
| WAF | Webアプリケーションファイアウォール |
| ALB | Application Load Balancer |
| ECS Fargate | CMSアプリケーションのコンテナ実行 |
| Aurora | Aurora Serverless v2（データベース） |
| ElastiCache | Redis（セッション・キャッシュ） |
6. 前提条件
必要な知識
- Dockerの基本操作
- HTTPの基本（キャッシュ、ヘッダー）
- CDNの概念
事前準備
- AWSアカウント
- AWS CLI v2
- Docker Desktop
- Terraform CLI
7. トラブルシューティング課題
Challenge 1: CloudFront でキャッシュが効かない
状況: 記事ページが毎回オリジンに到達している
調査ポイント:
- Cache-Control ヘッダーの確認
- Cookie の影響確認
- CloudFront Cache Policy の設定確認
Challenge 2: ECS タスクが頻繁に再起動
状況: ヘルスチェックに失敗してタスクが再起動
調査ポイント:
- ヘルスチェックの設定（interval, timeout）
- アプリケーションの起動時間
- メモリ使用量の確認
Challenge 3: 速報時のスケールアウトが間に合わない
状況: トラフィック急増時にスケールアウトが遅い
調査ポイント:
- スケーリングポリシーのクールダウン設定
- 予測スケーリングの導入検討
- Scheduled Scaling の活用
8. 設計考慮ポイント
ディスカッション1: CDN キャッシュ戦略
テーマ: キャッシュTTLの最適化
| コンテンツ | 推奨TTL | 理由 |
|---|---|---|
| 静的アセット | 1年 | バージョン管理で無効化 |
| 画像 | 1日-1週間 | 更新頻度が低い |
| 記事ページ | 5-15分 | リアルタイム性とのバランス |
| トップページ | 1-5分 | 新着記事の反映 |
ディスカッション2: FARGATE vs FARGATE_SPOT
テーマ: コスト最適化とリスク
| 観点 | FARGATE | FARGATE_SPOT |
|---|---|---|
| コスト | 100% | 約30%OFF |
| 可用性 | 高 | 中断リスクあり |
| ユースケース | 常時必要なタスク | スケールアウト分 |
ディスカッション3: キャッシュ無効化戦略
テーマ: コンテンツ更新時の反映
選択肢:
- TTL ベース（シンプルだが遅延あり）
- 明示的な無効化（即時だが複雑）
- バージョン付きURL（キャッシュ永続化）
9. 発展課題
Advanced 1: Lambda@Edge による動的コンテンツ
課題: エッジでのA/Bテストやパーソナライゼーション実装
Advanced 2: 予測スケーリング
課題: CloudWatch の予測スケーリングを有効化し、計画的なイベントに対応
Advanced 3: マルチリージョン展開
課題: 災害対策として別リージョンにスタンバイ環境を構築
10. 想定コストと削減方法
月額コスト概算
| サービス | 構成 | 月額コスト |
|---|---|---|
| ECS Fargate | 0.5vCPU/1GB × 2-20タスク | $70-350 |
| Aurora Serverless v2 | 2-8 ACU | $170-700 |
| CloudFront | 10TB転送 + 1億リクエスト | $150 |
| S3 | 100GB | $2 |
| ElastiCache | cache.t3.medium | $50 |
| ALB | 1 | $16 |
| NAT Gateway | 1 | $32 |
合計: 約 $490-1,300/月（約74,000-195,000円）
11. 学習のポイント
重要な概念の整理
CDN キャッシング
- エッジロケーションでのコンテンツ配信
- Cache-Control ヘッダーの重要性
- ETag による条件付きリクエスト
コンテナオーケストレーション
- タスク定義とサービス
- Auto Scaling ポリシー
- ヘルスチェックとローリングアップデート
サーバーレスデータベース
- Aurora Serverless の自動スケーリング
- ACU（Aurora Capacity Units）
- 一時停止機能（開発環境向け）
GCPとの比較
| 概念 | AWS | GCP |
|---|---|---|
| CDN | CloudFront | Cloud CDN |
| コンテナ実行 | ECS Fargate | Cloud Run |
| オブジェクトストレージ | S3 | Cloud Storage |
| サーバーレスDB | Aurora Serverless | Cloud SQL |
| キャッシュ | ElastiCache | Memorystore |
次のステップ
- WAF ルールの高度な設定
- リアルタイムログ分析（Kinesis + Athena）
- 画像最適化（Lambda@Edge）