Global Performanceを改善する

前提

以下は既習として扱います。

• AWSリージョン、アベイラビリティーゾーン、エッジロケーション
• Amazon CloudFrontの基本的な役割
• AWS Wavelengthの基本的な役割
• CloudFrontのキャッシュ
• Route 53のルーティング
• リージョンと物理距離
• パフォーマンスベースラインとボトルネック分析

CloudFrontやWavelengthの基本定義は再講義せず、グローバルなレイテンシーが発生している区間を特定し、その区間を実際に変更できるアーキテクチャを選ぶことに集中します。

1. 「グローバルだから遅い」では改善策を決められない

日本の利用者が欧州にあるアプリケーションを利用する場合でも、応答時間には複数の区間が含まれます。

利用者
↓
インターネット / 通信事業者ネットワーク
↓
AWSエッジ
↓
AWSリージョン
↓
アプリケーション処理
↓
データアクセス

「世界中から使われているからCloudFront」「レイテンシーが高いからGlobal Accelerator」と先にサービスを決めず、どの区間を短縮する必要があるのかを最初に確認します。

2. グローバルパフォーマンスを4つの改善対象へ分ける

コンテンツ配信
→ Amazon CloudFront

ネットワーク経路
→ AWS Global Accelerator

コンピューティング配置
→ AWS Wavelength

処理地点
→ 複数リージョンなどへの地理分散

重要なのはサービス名ではなく、変更される区間が異なることです。

3. CloudFront利用時は「エッジまで」と「エッジより先」を分ける

CloudFrontでキャッシュヒットがp95 70 ms、キャッシュミスがp95 850 msなら、利用者からCloudFrontエッジまでだけが主因とは考えにくくなります。

CloudFrontエッジ
↓
オリジン
↓
アプリケーション処理

を追加で通る場合に差が生まれているため、CloudFrontの有無ではなく、どの経路を通ったときに遅延が増えるかを見ます。

4. CloudFrontを追加しても処理地点が自動的に近づくわけではない

静的コンテンツは高速でも、キャッシュ対象ではない動的APIが遠隔地域だけ遅い場合があります。

利用者
↓
エッジ
↓
遠い処理地点

最終的なアプリケーション処理が遠いリージョンで行われるなら、その距離は残ります。コンテンツ配信とアプリケーション処理地点を分けて考えます。

5. Global Acceleratorではネットワーク経路を改善対象にする

UDPアプリケーションが複数リージョンのNetwork Load Balancerを利用し、クライアント側では固定されたグローバルIPが必要な場合、改善対象は利用者からAWSリージョナルエンドポイントまでのネットワーク経路です。

AWS Global Acceleratorでは、利用者に近いAWSエッジからAWSグローバルネットワークへトラフィックを取り込み、正常なリージョナルエンドポイントへ転送できます。

判断するのはキャッシュの有無ではなく、リージョナルエンドポイントまでどの経路で届けるかです。

6. Global Acceleratorで改善しても残る遅延を確認する

AWS Global Acceleratorを導入した後でも要求レイテンシーを満たせない場合があります。

モバイル端末
↓
AWSエッジ
↓
AWSグローバルネットワーク
↓
親リージョン
↓
推論処理

AWSネットワークへの入口やリージョンまでの経路を改善しても、通信事業者ネットワークの利用者から遠いリージョンの処理地点までの距離が残る場合、ネットワーク経路の問題からコンピューティング配置の問題へ改善対象が変わります。

7. Wavelengthは「Global Acceleratorより速いサービス」ではない

AWS Wavelengthを評価するのは、Global Acceleratorより高速そうだからではありません。

利用者からAWSネットワークへの経路
→ 問題なし

親リージョン内の処理時間
→ 問題なし

通信事業者ネットワークから
親リージョンの処理地点までの距離
→ 要求レイテンシーを超える

という証拠があるとき、処理地点を通信事業者ネットワーク側へ近づけることが改善対象になります。AWS Wavelengthは、このコンピューティング配置を変更するための候補です。

8. エッジへ移す範囲もボトルネックから決める

映像受信、即時推論、結果返却だけが厳しいレイテンシー要件を持ち、長期保存・共有データ・分析処理には同じ要件がない場合があります。

その場合、全部をエッジへ移すのではなく、遅延区間を短縮するために必要なコンポーネントだけを近づけることを検討します。

判断するのはWavelengthの定義ではなく、どの処理を移動すれば測定した遅延区間が短縮されるかです。

9. 地理分散は「経路」ではなく「処理地点」を変える

遠隔地域の動的APIだけレイテンシーが大きく、アプリケーション内部処理時間は地域で変わらない場合、地理的距離が支配的である可能性があります。

既存リージョンまでのネットワーク経路だけを改善するのではなく、アプリケーション処理地点自体を利用者へ近づけることも検討します。

10. グローバルサービスは処理地点を自動複製しない

Amazon CloudFrontやAWS Global Acceleratorを追加しても、あるリージョンだけに存在するアプリケーション処理が別リージョンへ自動的に複製されるわけではありません。

入口や経路の改善
≠
アプリケーションの地理分散

処理をどの地域へ配置するかは別のアーキテクチャ判断です。

11. 地理分散した方がよいとは限らない

処理地点を増やせば利用者との距離を短縮できる可能性がありますが、データレプリケーション、整合性、書き込み競合、運用、コスト、リージョン間通信なども考慮する必要があります。

利用者が世界中にいるからすべてを全リージョンへ配置するのではなく、改善対象となっているコンポーネントと必要なレイテンシー目標から地理分散範囲を決めます。

12. グローバル平均だけで判断しない

グローバルp95だけでは、地域ごとの大きなレイテンシー差を隠すことがあります。

利用者地域

キャッシュヒット / ミス

接続先リージョン

ネットワーク経路

実際の処理地点

などで分けて確認し、地域差や経路差を改善するアーキテクチャ区間へ対応付けます。

13. 同じ利用者要求でも複数の改善策が必要になる

静的ファイルの配信、動的APIの処理地点、リアルタイムUDPのネットワーク経路がそれぞれ問題なら、全部をCloudFrontやGlobal Acceleratorへ統一するのではありません。

それぞれ、コンテンツ配信・処理地点・ネットワーク経路という異なる改善対象として扱います。

14. 選択の中心は「何を近づけるか」

再利用可能なHTTPコンテンツ
→ Amazon CloudFront

AWSネットワークへの入口
→ AWS Global Accelerator

レイテンシーに敏感なコンピューティング
→ AWS Wavelength

アプリケーション処理地点
→ 地理分散

この対応を暗記して終わりではなく、実際のシナリオではどの区間が遅いのかという証拠から逆算します。

15. このページで扱わないこと

CloudFrontのTTL、キャッシュキー、キャッシュ無効化、Route 53のルーティングポリシー詳細は扱いません。またCPU、メモリ、ストレージ、ネットワーク帯域からEC2の適正サイズを決める問題も扱いません。

ここでは、グローバル利用者に対するレイテンシー問題を、コンテンツ配信・ネットワーク経路・コンピューティング配置・地理分散へ対応付けることだけを扱います。

16. 判断フロー

グローバル利用者の
レイテンシー問題
↓
遅延する区間を確認

├─ HTTPコンテンツ配信
│    ↓
│  Amazon CloudFront
│
├─ 利用者 → AWSリージョナルエンドポイント
│  のネットワーク経路
│    ↓
│  AWS Global Accelerator
│
├─ 通信事業者ネットワーク →
│  コンピューティングの距離
│    ↓
│  AWS Wavelength
│
└─ アプリケーション処理地点自体が遠い
     ↓
   地理分散

採用後も、改善した区間が要求レイテンシーを満たしたかを確認し、まだ遅ければ残っている区間を再確認します。

まとめ

CloudFront、Global Accelerator、Wavelengthを「どれが最も高速か」で比較しません。

CloudFront
→ コンテンツ配信

Global Accelerator
→ リージョナルエンドポイントまでの
   ネットワーク経路

Wavelength
→ コンピューティングの配置

地理分散
→ アプリケーションの処理地点

重要なのは、グローバル利用者のレイテンシーがどの区間で発生しているかを特定し、その区間を実際に短縮できるアーキテクチャを選ぶことです。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• Amazon CloudFront Developer Guide
• AWS Global Accelerator Developer Guide
• AWS Wavelength Developer Guide