東京リージョンのALBへの海外アクセス、CloudFrontとGlobal Acceleratorのどっちが正解か

  • AWS
  • Global Accelerator
  • CloudFront
  • Networking

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

東京リージョンのALBから配信してるサービスに、海外の特定の国からアクセスすると遅いという相談が来た。ユーザー体験に関わるレベルだったので、AWSのサービスで解決できないか検討した記録。

何が起きてたか

日本（東京リージョン）のALBに、海外からインターネット経由でアクセスすると遅延が大きい。原因はインターネット経路の距離と混雑らしい（実機でのtracerouteまでは追ってないので、あくまで一般的な要因としての推測）。

CloudFrontを検討して見送った

最初にCloudFrontを検討した。ただ、当時は以下の理由で見送った。

  • 配信してるのはキャッシュしづらい動的なコンテンツが多く、キャッシュポリシーやオリジンリクエストポリシーの設計をちゃんと詰める時間がなかった
  • 構成変更の余地がタイトだった

あと、DNSをCloudFrontのドメインに向け直す必要があるのは事実だけど、これはGlobal Acceleratorを使う場合も同様（後述のエイリアスレコード設定が必要）なので、CloudFront固有のデメリットとして挙げるのは筋が悪かった。

Global Acceleratorを選んだ理由

最終的に選んだのはGlobal Accelerator。理由は主に3つ。

  • キャッシュの設計を考えずに使える（そもそもキャッシュしない、ネットワーク層の高速化）
  • 既存のALB構成にほぼ手を入れずに導入できる
  • AWSのグローバルネットワークを経由することで、公衆インターネットの混雑を回避できる
flowchart LR
    User[海外ユーザー] -->|Anycast IP| GA[Global Accelerator]
    GA -->|AWSバックボーン| ALB[東京リージョン ALB]
    ALB --> App[アプリケーション]

やったこと

  1. アクセラレーターの作成 Global Acceleratorのコンソールから新規作成。作成すると自動でIPv4の静的Anycast IPが2つ割り当てられる。

  2. エンドポイントグループの設定 東京リージョンのALBをエンドポイントとして追加。ヘルスチェックを有効化して、ALBの死活監視をGlobal Accelerator側でも行うようにした。

  3. DNS設定の変更 既存のDNSレコードを、Global Acceleratorが提供するエイリアスターゲットに向けた。IPを直接書くんじゃなくてエイリアス経由にしたので、内部でIPが変わっても追従できる。

結果

導入後、海外からの接続遅延は体感でも数値でも改善した。オリジン（ALB）側の構成はほぼ変えてないので、リリース作業自体は軽かった。運用開始後も特に追加の管理コストは発生してない。

わかったこと

  • DNSの向け先変更は、CloudFrontでもGlobal Acceleratorでも避けられない。これを片方だけのデメリットとして扱うのは誤り