グローバル展開するEC（電子商取引）サイトを運営する企業は、AWSの東京リージョン（ap-northeast-1）にALB（Application Load Balancer）とEC2インスタンスでアプリケーションを構成

Question

グローバル展開するEC（電子商取引）サイトを運営する企業は、AWSの東京リージョン（ap-northeast-1）にALB（Application Load Balancer）とEC2インスタンスでアプリケーションを構成しています。
このサイトは静的コンテンツ（商品画像・CSS・JavaScript）と動的なコンテンツ（商品検索API・カート処理API）の両方を提供しています。
北米・ヨーロッパのユーザーから400ms以上のレイテンシーが報告されており、改善が求められています。
既存インフラへの変更を最小限にしながら、最もコスト効率よくグローバルユーザーのパフォーマンスを改善する方法はどれですか？

Accepted Answer

正解: Amazon CloudFront ディストリビューションを作成し、静的コンテンツはエッジロケーションでキャッシュし、動的リクエストはオリジン（ALB）に転送する Cache Behavior を設定する。Amazon CloudFront ディストリビューションを作成し、静的コンテンツはエッジロケーションでキャッシュし、動的リクエストはオリジン（ALB）に転送する Cache Behavior を設定する。

CloudFrontは400以上のエッジロケーションで静的コンテンツをキャッシュし、動的リクエストも最適化されたAWSバックボーン経由でオリジンに転送します。ECサイトは静的コンテンツの割合が高いためキャッシュヒット率が高くなり、コスト効率も優れています。
Global Accelerator（選択肢C）は動的コンテンツのTCPアクセラレーションには有効ですが、静的コンテンツのキャッシュ機能を持たず、混在コンテンツへの総合対応ではCloudFrontが優れています。
他リージョンへのEC2デプロイ（選択肢A）は効果はありますが、運用コストが大幅に増加します。
ElastiCache（選択肢D）はバックエンドの高速化にはなりますが、ネットワーク距離による遅延は解消できません。

Answer

Route 53 のレイテンシーベースルーティングを設定し、北米・欧州の各リージョンに EC2 インスタンスと ALB を新たにデプロイする — 北米・欧州に新規EC2インスタンスとALBを構築する必要があり、既存インフラへの変更を最小限にするという制約に反します。マルチリージョン運用の管理負荷とコストも大幅に増加するため、コスト効率の要件も満たしません。

Answer

AWS Global Accelerator を設定して東京の ALB をエンドポイントとして登録し、AWS グローバルバックボーンネットワーク経由でトラフィックをルーティングする — AWSグローバルバックボーンを活用したTCPアクセラレーションにより動的コンテンツの遅延を改善しますが、静的コンテンツのキャッシュ機能を持ちません。静的・動的コンテンツが混在するECサイトへの総合的な対応ではCloudFrontに劣ります。

Answer

Amazon ElastiCache for Redis を東京リージョンに追加して API レスポンスをキャッシュし、データベースへのレイテンシーを削減する — 東京リージョンのバックエンドデータベースアクセスを高速化しますが、北米・欧州ユーザーと東京サーバー間の物理的なネットワーク距離に起因するレイテンシーは解消できず、グローバルユーザーの体感速度改善には効果がありません。

解説

解説