【実務・中級編】 AWS Global Acceleratorのanycast IPとエッジロケーションルーティング – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは、SREチームのシニアエンジニアです。

グローバル展開しているWeb APIのレイテンシー（応答速度）改善に頭を悩ませたことはありませんか？「東京リージョンにあるAPIサーバーへ、ヨーロッパや北米のユーザーからアクセスすると、インターネットの荒波を越えてくる途中でパケットがロスし、TCPのハンドシェイクだけで何百ミリ秒もかかる……」これはグローバルサービスを運用するエンジニアなら誰もが直面する悪夢です。

パブレストランやカフェのWi-Fiから、何段ものBGPルーターをホップしてAWSの東京リージョンにたどり着くまでの不確実性を、どうにかして排除したい。パケットがAWSのプライベートな超高速バックボーンに「一刻も早く飛び乗る」ことができたら、どれほど世界が変わることか。

今回は、そんなインフラエンジニアの長年のロマンを具現化する「AWS Global Accelerator」を取り上げます。Anycast IPとAWSのエッジロケーションが、どのようにパケットの旅路を劇的に変えるのか、実務で即座に使える設定やデバッグ手法を交えて徹底解説していきましょう。

—

1. AWS Global Acceleratorの正体：なぜ「パブリックIPのルーティング」が変わるのか？

私たちが普段Webアプリケーションを公開する際、Route 53などのDNSを使ってドメイン名をALB（Application Load Balancer）やEC2のパブリックIPに解決させます。しかし、これにはDNSキャッシュのTTL問題や、インターネットのBGP経路が最適化されないという宿命的な弱点があります。世界中のISP（インターネットサービスプロバイダー）の気まぐれなルーティングによって、遠回りな経路を通らされることは珍しくありません。

ここで登場するのが、AWS Global Accelerator（以下、AGA）です。

Anycast IPによる「最寄りのエッジ」への着地

AGAを作成すると、AWSは世界中にある数百のエッジロケーション（PoP: Point of Presence）から、固定の静的なAnycast IP（IPv4×2個、IPv6×2個）をインターネットに向けて広告（BGPアナウンス）します。

世界中のユーザーがAPIにリクエストを投げると、BGPの最短パス原則により、ユーザーから地理的・ネットワーク的に最も近いAWSのエッジロケーションへパケットが吸い寄せられます。ユーザーは、DNSの名前解決を待つことなく、数ホップでAWSのネットワーク網の入り口に到達できるのです。

AWSのグローバルバックボーンという名の「高速道路」

エッジロケーションでパケットを受け取った後、パケットは一般のインターネット（公衆網）ではなく、世界中に張り巡らせたAWS専用のプライベート・グローバルネットワークバックボーンに即座に乗せられます。

パブリックインターネットの混雑やパケットロスをバイパスし、VPCが存在する宛先のリージョン（例えば東京リージョン ap-northeast-1）のゲートウェイまで、AWSの管理下にある高品質な回線で一気に転送されます。これにより、TCPの輻輳制御アルゴリズムが健全に働き、スループットが劇的に向上するのです。

—

2. 通信フロー（シーケンス）の裏側：パケットはどこを走るのか？

実務でトラブルシューティングを行う際、パケットがどのような経路をたどり、どのレイヤーで処理されているかをイメージできることは極めて重要です。AGAを使った場合の通信のライフサイクルを追ってみましょう。

1. Anycastルーティング:
クライアント（例: ロンドン在住）が 203.0.113.1（AGAのAnycast IP）宛てにHTTPSリクエストを送信。BGPにより、ロンドン近郊のAWSエッジロケーションのルーターがパケットを受信。
2. エッジでの終端とトンネリング:
エッジロケーションでTCPコネクションが一度終端（あるいはプロキシ）され、AWSの内部プロトコルでカプセル化される。
3. AWSバックボーン横断:
大西洋海底ケーブルなどを含むAWSの専有光回線を経由し、宛先リージョン（例: 東京）のAGAエンドポイントへ超高速転送。
4. VPC内転送:
東京リージョンのAGAサービス基盤から、指定されたVPC内のエンドポイント（ALB、NLB、EC2インスタンス）へルーティング。

ここで特筆すべきは、クライアントの送信元IPアドレス（Client IP）がそのままVPC内のアプリケーションまで保持される点です（ALBやNLBを経由する場合、Proxy Protocol v2を使用するか、ALBの機能によって維持されます）。アクセスログの解析やジオターゲティング、セキュリティのIP制限がそのまま機能するため、既存のアーキテクチャを大きく変更する必要がありません。

—

3. 実践：AWS CLIによるGlobal Acceleratorの構築

理屈はこれくらいにして、実際にインフラをコードやCLIで構築してみましょう。今回は、すでに存在する東京リージョンのALBに対して、グローバルアクセラレーターを前段に配置する手順を解説します。

まずは、アクセラレーター自体の作成と、リスナー、エンドポイントグループ、エンドポイント（ALB）の紐付けを行います。

# 1. グローバルアクセラレーターの作成
# 戻り値として返される AcceleratorArn を控えておきます。
aws globalaccelerator create-accelerator \
    --name "global-api-accelerator" \
    --ip-address-type IPV4 \
    --enabled \
    --region us-west-2

# 2. リスナーの作成（クライアントからのHTTPS/443トラフィックを受け付ける）
# --accelerator-arn には手順1で取得したARNを指定します。
aws globalaccelerator create-listener \
    --accelerator-arn "arn:aws:globalaccelerator::123456789012:accelerator/abcdef01-2345-6789-abcd-ef0123456789" \
    --port-ranges FromPort=443,ToPort=443 \
    --protocol TCP \
    --client-affinity NONE

# 3. エンドポイントグループの作成（今回は東京リージョン ap-northeast-1 を指定）
# --listener-arn には手順2で取得したARNを指定します。
aws globalaccelerator create-endpoint-group \
    --listener-arn "arn:aws:globalaccelerator::123456789012:listener/abcdef/1234567890" \
    --endpoint-group-region "ap-northeast-1" \
    --traffic-dial-percentage 100

# 4. ALBをエンドポイントとして登録
aws globalaccelerator add-endpoints \
    --endpoint-group-arn "arn:aws:globalaccelerator::123456789012:endpoint-group/abcdef/1234567890" \
    --endpoint-configurations EndpointId="arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-prod-alb/1234567890abcdef",Weight=255

この設定により、AWSが提供する2つのAnycast IPに対して世界中からアクセスが可能になり、トラフィックは自動的に東京のALBへと流し込まれます。

—

4. クライアント側（Web API設計・実装）からのアプローチ

インフラ側でAGAを導入したら、アプリケーション層（Web API）側では何か特別な実装が必要になるでしょうか？

基本的には通常のHTTPS通信と変わりませんが、クライアント側のSDKやHTTPクライアントの接続タイムアウト設定には注意が必要です。グローバルな通信では、物理的な距離による伝搬遅延（Propagation Delay）がどうしても発生するため、極端に短いタイムアウト（例: 500msなど）を設定していると、遠隔地のユーザーからのリクエストがタイムアウトエラーを引き起こす原因になります。

以下は、Python（requests ライブラリ）およびJavaScript（Fetch API）を用いた、AGA経由のAPI叩き方の実例です。

PythonによるAPIリクエスト例

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def call_global_api():
    # AGAのAnycast IP、またはAGAに紐付けたカスタムドメインを指定
    api_url = "https://api.example.com/v1/data"
    
    # グローバル通信の揺らぎを考慮し、リトライ戦略と適切なタイムアウトを設定
    session = requests.Session()
    retries = Retry(total=3, backoff_factor=0.5, status_forcelist=[500, 502, 503, 504])
    session.mount("https://://", HTTPAdapter(max_retries=retries))
    
    try:
        # 接続(connect)と読み込み(read)のタイムアウトを明示的に長めに確保
        response = session.get(api_url, timeout=(3.0, 10.0))
        response.raise_for_status()
        
        print(f"Status Code: {response.status_code}")
        print(f"Response Body: {response.json()}")
        
    except requests.exceptions.Timeout:
        print("エラー: ネットワークの往復に時間がかかりすぎました（タイムアウト）")
    except requests.exceptions.RequestException as e:
        print(f"通信エラーが発生しました: {e}")

if __name__ == "__main__":
    call_global_api()

JavaScript (Fetch API) による実装のポイント

フロントエンドから直接AGA経由のAPIを叩く場合、ブラウザはAnycast IPやCDNと同様にスムーズなTCPコネクション確立の恩恵を受けます。

async function fetchGlobalData() {
  const apiUrl = 'https://api.example.com/v1/data';

  try {
    // AbortControllerを使用して、グローバル通信でのネットワーク遅延に対応したタイムアウトを設定
    const controller = new AbortController();
    const timeoutId = setTimeout(() => controller.abort(), 8000); // 8秒でタイムアウト

    const response = await fetch(apiUrl, {
      method: 'GET',
      headers: {
        'Content-Type': 'application/json',
      },
      signal: controller.signal
    });

    clearTimeout(timeoutId);

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const data = await response.json();
    console.log('取得成功:', data);

  } `catch` (error) {
    if (error.name === 'AbortError') {
      console.error('リクエストがタイムアウトしました');
    } else {
      console.error('API通信エラー:', error.name, error.message);
    }
  }
}

—

5. 現場のSREが教える！トラブルシューティングと運用TIPS

最後に、実務の現場でAGAを導入・運用する際に必ず役立つ、泥臭いデバッグ手法と実践的なTIPSをいくつか伝授します。

1. 「どこのエッジを通っているか？」をトレースする (traceroute / tcptraceroute)

ユーザーからの「海外からつながらない」「遅い」という問い合わせに対して、どのエッジロケーションにパケットが吸い寄せられているかを調査するには、traceroute や mtr を使います。

# Anycast IPに対してtracerouteを実行し、最寄りのエッジルーターのホスト名やレイテンシーを確認
traceroute 203.0.113.1

出力結果の途中に aws やエッジ拠点のIATAコード（例: lhr（ロンドン）や fra（フランクフルト））が含まれるホスト名が現れれば、正しくAWSのエッジ網にヒットしています。

2. ヘルスチェックとトラフィックダイアルの活用

AGAは、配下のエンドポイント（ALBやEC2）の死活監視を自動で行います。もし東京リージョンのALBが異常と判定された場合、トラフィックを自動的に別のリージョン（例: オレゴンリージョン us-west-2 のDR用API）へ数秒でフェイルオーバーさせることができます。
また、traffic-dial-percentage パラメーターを操作することで、カナリアリリースや、特定のリージョンへのトラフィックの徐々な切り替え（Blue/Green Deployment）をノーコード・ノーDNS切り替えで実現可能です。

3. コストとのトレードオフを忘れない

SREとして忘れてはならないのがコスト管理です。AGAは「アクセラレーター自体の固定費（月額料金）」に加えて、「データ転送量に応じた従量課金（GB単価）」が発生します。通常のインターネット転送量と比較してコストが割高になる傾向があるため、「グローバルなレイテンシー削減によるビジネス上の売上貢献（コンバージョン率向上など）」が、インフラコストの増加を正当化できるか、事前のPoCで必ず計測・検証するようにしてください。

—

まとめ

AWS Global Acceleratorは、単なる「IPルーティングの最適化ツール」ではありません。世界中に散らばるユーザーと、日本のVPC内にあるAPIサーバーとの間の「物理的な距離の壁」を、AWSの強力なグローバルバックボーンによって力技で解決する、極めて実用的なSREの武器です。

DNSのTTL伝搬遅延に悩まされることも、パブリックインターネットの不可解なルートフラッピングに泣き寝入りする必要ももうありません。ぜひ次のグローバル向けアーキテクチャ設計の際には、このAnycastの魔法を取り入れてみてください。あなたのAPIは、世界中どこからでも「すぐ隣にあるかのように」軽快に動き出すはずです。