DOP-3.2ビジネス要件を満たすスケーラブルなソリューションを実装する。

ヒントボタン

世界中の視聴者へ 95 パーセンタイル遅延 100 ms 未満を届けるには、200 以上の PoP を持つ Amazon CloudFront を前段に置きエッジキャッシュさせる設計が王道です。リージョン単位の Amazon S3 バケット URL や Application Load Balancer だけでは距離による RTT を吸収できないため、非公開の S3 Standard をオリジンにした CloudFront ディストリビューションをイメージしてみてください。

DDoS と OWASP Top 10 への備えは、AWS Shield Standard がデフォルトで組み込まれる CloudFront に AWS WAF ウェブ ACL を追加すると L3〜L7 まで多層防御が整います。S3 をパブリック公開する方法では WAF を直接適用できず、API Gateway 経由は転送量コストが高くなるので、オリジンアクセスコントロールで S3 をプライベートに保ちつつセキュリティレイヤを CloudFront へ集約する流れを思い描くと要件が自然に満たせるはずです。

ゼロダウンタイム更新と 5 分以内の全エッジ反映は、AWS CodePipeline から aws s3 sync でオブジェクトをアップロードし続けて CloudFront CreateInvalidation API を呼び出す手順で達成できます。EC2 や EFS を使わない S3＋CloudFront＋ACM のサーバーレス構成ならストレージ、配信、TLS 証明書がフルマネージドとなり、パフォーマンス、セキュリティ、運用コストの複数要件を俯瞰した総合判断としても最適解に近づきます。

ヒントボタン

5秒以内にダッシュボードへ反映させるには、Oracle の REDO ログを取り込み続ける AWS DMS の「フルロード＋CDC」モードが中心となります。マルチ AZ のレプリケーションインスタンスを選択すれば AZ 障害でも自動フェイルオーバーし RPO1 分・RTO15 分を維持でき、KMS で暗号化や自動パッチ適用も任せられるため運用負荷を軽減できます。さらに S3 中間バケットと並列 COPY によって Amazon Redshift への取り込みが高速化され、Direct Connect 1 Gbps を活かして 5,000 件/秒の更新を処理できます。

分析チームが SQL を書き換えずに済ませたい場合、データを Amazon Redshift の内部テーブルへ格納しておくことが重要です。Redshift Spectrum の外部テーブルや Redshift Federated Query を利用するとビュー追加やスキーマ名変更が必要になり、既存ダッシュボード側で SQL を修正する手間が発生します。DMS で S3 ステージを経由しながら COPY を自動実行すれば同じテーブル名・列定義のまま高速ロードが行え、クエリ整合性と性能を同時に確保できます。

高可用性・暗号化・追加ライセンス不要・低運用負荷という複数要件を総合的に見渡すと、AWS SCT でスキーマを変換しマルチ AZ の AWS DMS で CDC を行い、VPC エンドポイント経由の S3 から Amazon Redshift に並列 COPY するアプローチが、性能・コスト・運用のバランスを最も取りやすい総合解と言えるでしょう。

ヒントボタン

HTTP API を同期で扱う Java ランタイムではコールドスタートが P95 レイテンシを悪化させやすいので、AWS Lambda の Provisioned Concurrency で常時ウォーム状態を保つ意義を押さえてください。Amazon CloudWatch の Duration を比較すると効果が明確に見えます。Reserved Concurrency は同時実行枠を確保するだけでウォーム化しないため、200 ms 未満の応答を安定させる用途とは役割が異なる点を整理しておくと判断が楽になります。

平常 500 rps が数分で 3 000 rps に跳ね上がるようなワークロードでは、EventBridge でのスケジュール増減だけに頼ると想定外スパイクを捕捉できません。Application Auto Scaling で Lambda の ProvisionedConcurrencyUtilization を 70% などに設定すれば、CloudWatch メトリクスを毎分確認しながら最小 500・最大 3 000 の範囲で自動伸縮できます。秒〜分単位で追従するため、木曜夜の定例ピークはもちろん突発的なアクセス集中にも自律的に対応でき、追加オペレーションを要しません。

平常時にも最大キャパシティを維持すれば性能には余裕がありますが、Provisioned Concurrency の課金が常に発生するためコスト効率は低下します。SQS でバッファする方法は非同期処理向けで HTTP レイテンシを圧迫しがちです。AWS Lambda のウォーム数をターゲット追跡で動的に調整する設計なら、必要最小限のコンカレンシーで費用を抑えつつ、CloudWatch 監視に基づき数秒〜数分で自動スケールアウトし、200 ms のレスポンス保証も守れます。性能・コスト・運用自動化という複数要件を俯瞰すると、この仕組みが最もバランスの取れた選択肢といえるでしょう。

ヒントボタン

ヒント1
世界 200 超の国から 1 秒未満で初期表示させるには、高い PoP 数を持ち HTTP オブジェクトをエッジキャッシュできる Amazon CloudFront が鍵になります。静的アセットは TTL とオリジングループで分散し、動的 HTML は Origin Request フェーズの Lambda@Edge が Cookie を読み取って /v2/ へリライト可能です。コードのみで動くサーバーレス実装なので運用負荷も抑えられます。

ヒント2
API 呼び出しは Application Load Balancer のパスベースルールで /api/* を分岐し、背後の EC2 Auto Scaling グループが RequestCountPerTarget=50 のターゲット追跡ポリシーで自律拡張すると、平均 50 リクエスト以下を維持できます。起動テンプレートに Amazon Linux 2 と UserData を組み合わせるとインスタンスは 2 分程度で投入され、99.9% 可用性を満たしつつ台数が自動最適化されます。

ヒント3
CI/CD からのブルー/グリーンデプロイは CloudFront のキャッシュバージョンと ALB の重み付きターゲットグループを使えば無停止で切替可能です。Auto Scaling の管理はマネージドメトリクスに任せ、独自 AMI や複雑なスケジューリングを避けることで運用チームの負担とコストを両方削減できます。Lambda@Edge と CloudFront Functions を併用すれば追加のエッジサーバーも不要です。

以上を踏まえ、CloudFront＋Lambda@Edge でグローバルキャッシュと AB テストを実現し、ALB＋ターゲット追跡 Auto Scaling で /api/* の負荷を数値目標で制御する構成が、性能・可用性・コスト・運用簡素化という複数要件を最もバランス良く満たすと判断できます。

ヒントボタン

RPOをゼロにしつつ障害発生から60秒以内に自動で書込みを継続させるには、複数リージョンで同時書込みを許可し副次リージョンへのフェイルオーバーや復旧方向の切替が数クリックではなく内蔵ロジックで行われるDynamoDB グローバルテーブル v2 のようなサービスが最短経路で非同期レプリケーションを行いつつ衝突解決も吸収できる設計が現実的です。
EU圏のデータをEUリージョン以外から更新させない制約は、アイテムのパーティションキーに“EU#”のような識別子を埋め込み、IAM ポリシーで dynamodb:LeadingKeys と aws:RequestedRegion を組み合わせて該当キーと eu-central-1 以外の組み合わせの PutItem や UpdateItem を拒否することで、アプリケーションを変更せずにGDPR要件をフルマネージドに満たせます。
1日5億件の書込みと片道50ms以内の遅延を両立しながら運用労力を抑えるには、最寄りリージョンの API Gateway と Lambda へ Route 53 レイテンシールーティングで誘導し、DynamoDB のマルチマスター構成で局所書込みを完結させ、レプリケーションやフェイルオーバーはサービス側の制御に委ね、CloudWatch 監視や自動復旧も標準機能で担保するという多要件を俯瞰した設計判断が鍵となります。

ヒントボタン

60 秒で RPS が 3 倍になり追加容量を 90 秒以内に供給するという SLA と、Amazon EC2 インスタンスがユーザーデータで CIS ベンチマークとコンテナイメージを取得するのに 180 秒要するという現実の間には大きなギャップがありますから、Auto Scaling が新規に起動してから Launch ライフサイクルフックで初期化を済ませて InService へ入るのを待つ方式では遅く、ウォームプールを使って初期化済み状態（Warmed:Running）で待機させ、需要発生時に数秒で昇格させるアイデアを軸に考えると時間要件をクリアしやすくなります。

平常時は 20 台でコスト増を +10% 以内に抑えるという制約があるため、DesiredCapacity を大きく上げて余剰キャパシティで備える案や EventBridge と AWS Lambda でライブ直前に 60 台へ拡張する案は、Auto Scaling グループの稼働台数が一時的であっても大幅に増えることで EC2 コストが 50〜200% 近く跳ね上がり条件に抵触しやすく、ステップスケーリングで 30 秒ごとに台数を追加しても各インスタンスのウォームアップ 180 秒がボトルネックとなり 90 秒の SLA 内に処理能力を届けられない点を見逃さないようにしましょう。

スパイク直後の処理性能、180 秒の初期化時間、90 秒以内の追加提供、平常時コスト +10% 以内、運用変更は最小限という複数の条件を並べて評価すると、Auto Scaling のウォームプールと Launch ライフサイクルフックで必要最小限のインスタンスを事前に温めておき、負荷発生時に即座に InService へ切り替える構成が時間・コスト・運用すべてのバランスを最も取りやすいと総合判断できます。

ヒントボタン

急激な同時接続増に5分以内で追従したい場合、Elastic BeanstalkでApplication Load BalancerとAuto Scaling Groupを自動生成してくれるロードバランス済み環境を選び、CloudWatchのCPUUtilizationを3分間50%超でスケールアウト、20%未満が10分続けばスケールインというルールを組むと、応答200msと運用負荷最小化を両立しやすいです。
RPO15分・RTO1時間を担保しつつ誤削除も防ぐには、Aurora MySQLで自動バックアップ保持期間を35日に設定しPoint-In-Time Recoveryを有効化し、Deletion Protectionをオンにする構成が最も手間が少なく、安全性と復旧性の両方を満たします。
スパイク対策のAuto Scaling条件、35日保持の自動バックアップ、削除保護、そして運用工数削減という複数要件を俯瞰すると、Elastic Beanstalkのロードバランス済みプロファイルと標準のAurora MySQLを組み合わせたシンプルかつマルチAZな構成が総合的に最適と判断できます。

ヒントボタン

世界三極にユーザーが均等にいる状況では、API Gateway と AWS Lambda を各リージョンへ配置し Route 53 Latency ルーティングで近接リージョンへ導くと、TCP や TLS の往復もリージョン内で完結し 95 パーセンタイル 100 ms 未満が狙えます。単一リージョンの Edge-Optimized エンドポイントを Weighted で振り分ける構成では、大陸間経由となる欧州・アジア側の遅延がどうしても大きくなります。

RPO 0 と RTO 1 分を保証するには DynamoDB Global Tables のマネージド複製が最も手堅く、数百ミリ秒以内の非同期レプリケーションでデータを保護できます。Streams＋Lambda で自作レプリケーションを組むと衝突解決や監視が追加され運用負荷が急増し、Aurora Global Database へ移行するとスキーマ設計や Proxy 構築が新たに必要です。各リージョンで同一カスタムドメインを持つ API Gateway に Route 53 ヘルスチェックを関連付ければ、障害発生から 60 秒以内に該当リージョンが経路から除外されます。

可用性 99.99%、単一 DNS 名、低レイテンシ、低運用という複数要件を並べて比較すると、サーバーレスで計算レイヤをアクティブ-アクティブ化し DynamoDB Global Tables でデータを多リージョン化する案が最も自然です。Global Accelerator や DAX は一部課題しか解決できず、ECS Fargate と自作同期は管理工数が増えます。複数要件を俯瞰すると、Route 53 Latency ルーティング＋ヘルスチェックとマネージド多リージョンサービスの組合せがバランス良く条件を満たすと判断できます。

ヒントボタン

ピーク20万接続・p95 10ms・RPO=0という厳しい条件を3AZで満たしつつアプリケーションを完全にステートレス化するには、共有インメモリ層が必須であり、Amazon ElastiCache for Redisのクラスターモード有効マルチAZレプリケーショングループはTLS暗号化、自動フェイルオーバー、オンラインシャード増減、Global Datastoreによる将来のリージョン間DR対応まで備えるため、Fargate側の設定を変えずに運用工数を抑えながらコスト増を20％以内に収めやすいです。
Application Load BalancerのスティッキーセッションはタスクやAZ障害でセッションが失われ、Sidecar型Redisや既存memcachedは再起動時にデータが揮発しTLS設定も冗長になり、Amazon DynamoDBはインメモリでないため10msを超える可能性とRCU/WCU課金が大きく、これらの方式では低レイテンシ・ゼロデータロス・20％以内のコストという複数要件を同時に満たすのが困難である点を比較材料として整理してください。
設計判断では低レイテンシ、マルチAZでのゼロデータロス、自動スケーリング、TLS暗号化、20％以内のコスト、将来のリージョン間DRといった条件をまとめて満たせるかが重要であり、ElastiCache for Redisクラスターモードはグローバルデータストア、オンラインリシャーディング、読取専用エンドポイント、サーバーサイド暗号化、CloudWatch連動Auto Scalingを揃えECS FargateのBlue/Greenデプロイとも親和性が高いため、複数要件を俯瞰した総合判断では最も整合的な選択肢となります。

ヒントボタン

EC2 のステータスチェックには Instance と System の 2 種類があり、CloudWatch で個別に監視できます。Instance は OS 内部の障害を示す一方、System はハイパーバイザやネットワークなど物理ホスト側の問題を検知できるため、ハードウェア故障による停止時間を縮めたい場合は System 側を素早く捉えることが鍵となり、さらにライセンスがインスタンス ID にひも付くサーバーでは ID を変えずに復旧できるアクションを選ぶ視点が欠かせません。
CloudWatch アラームのアクションで指定できる EC2 の Recover は、EBS ルートボリュームと Elastic Network Interface を保持したまま別ホストへ移行する仕組みなのでインスタンス ID が変わらず、平均停止 2〜3 分と短時間で RTO 5 分を容易に満たします。標準メトリクス利用なら追加費用はなく、設定はアラーム 1 つだけで完了するため、Lambda や Systems Manager で再起動フローを組む方法と比べて運用負荷を大幅に削減できます。
Auto Scaling による置換や SNS と Lambda での stop/start は新しいインスタンス ID や ENI への切り替え、ユーザーデータ実行時間、IAM 設定などコストと工数が増えやすいため、RTO・RPO・ライセンス維持・追加費用ゼロ・運用負荷最小という複数要件を俯瞰すると、System 障害を CloudWatch で検知して EC2 の自動復旧を発動する構成が最もシンプルかつ要件達成へ近づく選択肢だと整理できます。