🎡 世界最大級のテーマパークの運営に例えると超わかりやすい！
AWSのグローバルアーキテクチャ = 世界中にあるテーマパーク
東京、ニューヨーク、ロンドン、シンガポール...世界中からお客様が来場します。
どうすれば
全員に最速で、快適な体験
を提供できるでしょうか？
4つの重要な仕組みを、テーマパークの運営に例えて理解しましょう✨
CloudFront・Lambda@Edge・ALB・Auto Scaling
の役割が一目瞭然！
🏗️ 4層アーキテクチャの全体像
東京のお客様 → 東京ゲートから入場（1ms）
ニューヨークのお客様 → NYゲートから入場（1ms）
ロンドンのお客様 → ロンドンゲートから入場（1ms）
📍 どこにいても、最寄りのゲートから入場できる！
わざわざ本部（オリジンサーバー）まで行く必要なし。
よく見られる地図やパンフレット（静的コンテンツ）は、
各ゲートにキャッシュしてあるのですぐ渡せる！
• 世界450以上のエッジロケーションに配置
• ユーザーに最も近い場所からコンテンツ配信
• 画像・CSS・JSなどの静的ファイルをキャッシュ
• レイテンシーを10ms以下に削減可能
• DDoS攻撃からの保護機能も標準装備
• HTTPSによる安全な通信をエッジで終端
⚡ 超高速配信
最寄りのエッジから配信するため、レイテンシーが劇的に改善
🔒 セキュリティ
AWS Shield StandardによるDDoS保護が標準で有効
💰 コスト削減
オリジンへのリクエスト数を90%削減してコスト最適化
お客様の属性を瞬時に判断：
👑 VIP会員 → 専用エントランスへ案内
📱 モバイルユーザー → 軽量版の地図を提供
🌍 海外からの観光客 → 多言語対応ルートへ
🤖 ボット・クローラー → 特別な対応
💡 重要：各ゲート（エッジ）で判断するから超高速！
本部に問い合わせる前に、その場で最適なルートを決定。
ユーザーのクッキー、デバイス、位置情報などを見て、
リクエストを書き換えたり、最適な体験を提供します。
• CloudFrontのエッジロケーションで実行される関数
• 4つのタイミングでカスタム処理が可能：
1. Viewer Request（リクエスト受信時）
2. Origin Request（オリジン転送前）
3. Origin Response（オリジン応答後）
4. Viewer Response（ユーザーへ返答前）
• A/Bテスト、認証、ヘッダー操作などが可能
• レスポンスタイムへの影響は1-5ms程度
• Node.jsまたはPythonで実装
🎭 A/Bテスト
エッジでユーザーを振り分けて異なるバージョンを表示
🔐 認証処理
オリジンに到達する前にJWT検証などを実行
📱 デバイス最適化
モバイル/PC/タブレットに最適なコンテンツを自動配信
お客様のリクエストに応じて、適切なエリアへ案内：
🎢 /attractions → アトラクションエリアへ
🍔 /restaurants → レストランエリアへ
🎁 /shop → ショップエリアへ
📸 /photos → 写真サービスエリアへ
⚖️ さらに負荷分散も担当！
各エリアに複数のスタッフ（EC2インスタンス）がいる場合、
混雑していないスタッフに優先的に案内。
健康チェックを定期的に行い、調子が悪いスタッフには
お客様を案内しません。
• URLパス、ホスト名、HTTPヘッダーで振り分け
• 例：/api/* → APIサーバー、/images/* → 画像サーバー
• WebSocketやHTTP/2に対応
• ヘルスチェックで正常なターゲットのみに転送
• SSL/TLS終端でバックエンドの負荷を軽減
• スティッキーセッションでセッション維持
• マイクロサービスアーキテクチャに最適
• Cross-Zone Load Balancingで複数AZ対応
🎯 パスベースルーティング
URLパスに応じて異なるマイクロサービスに振り分け
💚 ヘルスチェック
異常なインスタンスを自動検出して除外
🔄 自動復旧
障害発生時も正常なターゲットへ自動フェイルオーバー
平日午前（閑散期）：
👥 最小2名のスタッフで対応
休日午後（繁忙期）：
👥👥👥👥👥👥 最大10名まで自動でスタッフ追加
🎯 3つの賢い増減方法：
1️⃣ スケジュールベース
「毎週土日は朝9時に8名体制にする」
2️⃣ メトリクスベース
「CPU使用率70%超えたらスタッフ追加」
3️⃣ 予測スケーリング
「過去のパターンから来週末の混雑を予測」
• 需要に応じてインスタンス数を自動調整
• CPU・メモリ・ネットワークなどのメトリクスで判断
• 最小・最大・希望容量を設定可能
• スケールアウト（増加）は数分で完了
• スケールイン（削減）は段階的に実行
• CloudWatchアラームと連携
• 複数のAZにまたがって分散配置
• ヘルスチェックで異常インスタンスを自動置換
• コスト最適化：必要な時だけリソース確保
📊 動的スケーリング
リアルタイムの負荷に応じて自動でインスタンス増減
🔮 予測スケーリング
機械学習で需要を予測して事前にスケール
💰 コスト最適化
不要な時はインスタンスを削減して課金を削減
🔄 リクエストの流れを比較
❌ 従来型アーキテクチャ
東京 → 米国本社サーバー（150ms）
遠い！遅い！
1台のサーバーで全世界に対応
負荷が集中してダウンリスク大
閑散期も大型サーバーを維持
無駄なコストが発生
平均：150-300ms
ユーザー体験が悪い
✅ AWS 4層アーキテクチャ
東京 → 東京エッジ（5ms）
最寄りから超高速配信！
Lambda@Edgeで最適化
ユーザーごとにパーソナライズ
ALBが複数サーバーに分散
高可用性を実現
需要に応じて自動増減
コスト最適化と性能を両立
平均：5-20ms
劇的に高速化！
💼 実際のユースケース
ECサイト
解決策：
• CloudFront：商品画像を世界中にキャッシュ
• Lambda@Edge：地域別の価格表示
• ALB：/products、/cart、/checkoutで振り分け
• Auto Scaling：セール開始30分前に自動増強
結果： 通常の10倍トラフィックでも安定稼働
動画配信サービス
解決策：
• CloudFront：動画をエッジでキャッシュ
• Lambda@Edge：デバイスに応じた画質選択
• ALB：ストリーミングとAPI処理を分離
• Auto Scaling：夜間の視聴ピークに対応
結果： バッファリングなしの快適視聴を実現
オンラインゲーム
解決策：
• CloudFront：静的アセットを高速配信
• Lambda@Edge：最寄りのゲームサーバーへ誘導
• ALB：ゲームロジックとチャットを分離
• Auto Scaling：同時接続数でスケール
結果： レイテンシー10ms以下を維持
ニュースメディア
解決策：
• CloudFront：記事と画像を広域配信
• Lambda@Edge：有料会員の認証処理
• ALB：記事配信とコメント機能を分離
• Auto Scaling：アクセス数に応じて段階的増加
結果： 速報時も記事表示が1秒以内
✨ この4層アーキテクチャのメリット
# CloudFrontディストリビューション CloudFrontDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Origins: - Id: ALBOrigin DomainName: my-alb-123456789.ap-northeast-1.elb.amazonaws.com CustomOriginConfig: OriginProtocolPolicy: https-only DefaultCacheBehavior: TargetOriginId: ALBOrigin ViewerProtocolPolicy: redirect-to-https Compress: true LambdaFunctionAssociations: - EventType: viewer-request LambdaFunctionARN: arn:aws:lambda:us-east-1:123456789012:function:edge-auth # Application Load Balancer ApplicationLoadBalancer: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Subnets: [subnet-12345, subnet-67890] SecurityGroups: [sg-12345678] # ALBターゲットグループ（パスベースルーティング用） ApiTargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: HealthCheckPath: /api/health Port: 80 Protocol: HTTP WebTargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: HealthCheckPath: /health Port: 80 # Auto Scaling Group AutoScalingGroup: Type: AWS::AutoScaling::AutoScalingGroup Properties: MinSize: 2 MaxSize: 10 DesiredCapacity: 4 TargetGroupARNs: [!Ref ApiTargetGroup] LaunchTemplate: LaunchTemplateId: !Ref LaunchTemplate # スケーリングポリシー ScalingPolicy: Type: AWS::AutoScaling::ScalingPolicy Properties: PolicyType: TargetTrackingScaling TargetTrackingConfiguration: PredefinedMetricSpecification: PredefinedMetricType: ASGAverageCPUUtilization TargetValue: 70.0
• 静的コンテンツ（画像・CSS・JS）：TTL 1日以上
• 動的コンテンツ：TTL 0秒でも、圧縮とHTTP/2で高速化
• Cache-Controlヘッダーを適切に設定
2. Lambda@Edgeは軽量に保つ：
• 実行時間は5秒以内に抑える（理想は1秒以内）
• 重い処理はオリジン側で実行
• メモリサイズは128MBから始めて必要に応じて増やす
3. ALBのヘルスチェックを適切に設定：
• 間隔：30秒（トラフィックが多い場合は15秒）
• タイムアウト：5秒
• 正常しきい値：2回連続成功
• 異常しきい値：2回連続失敗
4. Auto Scalingのスケール速度を調整：
• スケールアウト：素早く（1-3分）
• スケールイン：慎重に（10-15分）
• ウォームアップ時間を考慮（アプリ起動時間 + 30秒）
5. 複数AZ配置は必須：
• 最低2つのAZにリソースを配置
• 本番環境は3つのAZ推奨
• Cross-Zone Load Balancingを有効化
6. モニタリングとアラート設定：
• CloudWatch Dashboardで全体を可視化
• レイテンシー、エラー率、スケーリングメトリクスを監視
• SNS通知で異常を即座に検知
7. コスト最適化のポイント：
• CloudFront：Reserved Capacityで最大25%削減
• EC2：Savings PlansやSpot Instancesの活用
• 不要なログやメトリクスは保存期間を短縮
8. セキュリティ強化：
• AWS WAFをCloudFrontに統合
• AWS Shieldでレイヤー3/4のDDoS対策
• セキュリティグループは最小権限の原則で設定
🎓 まとめ
🎡 テーマパーク = AWSグローバルアーキテクチャ
世界中のお客様に最高の体験を提供するには、
4つの層を組み合わせたアーキテクチャが最適解！
世界中の入口ゲート
最寄りから超高速配信
賢い振り分けスタッフ
エッジで最適化処理
総合案内所
パスベースで振り分け
スタッフ自動増減
需要に応じて最適化
🎯 この構成の威力：
⚡ レスポンスタイム：
150ms → 5ms
（30倍高速化）
🌍 グローバル対応：
450+拠点
から配信
💪 可用性：
99.99%
を実現
💰 コスト削減：
最大70%
のトラフィックコスト削減
📈 スケーラビリティ：
10倍のトラフィック
も自動対応
テーマパークの運営と同じように、
「お客様を待たせない」「どこからでも快適」「混雑時も安定」
この3つを実現するのがAWSグローバルアーキテクチャ！🎉
さあ、あなたのサービスも世界規模で展開しよう！🚀