CloudFront の 600 超 PoP はどう動いているのか - Anycast ルーティングとキャッシュ階層の仕組み
CloudFront がユーザーのリクエストを最寄りの PoP にルーティングする Anycast の仕組み、エッジロケーションとリージョナルエッジキャッシュの 2 層構造、キャッシュヒット率を左右する設計要因を解説します。
PoP (Point of Presence) とは何か
CloudFront の PoP は、世界中に分散配置されたキャッシュサーバー群です。2024 年時点で 600 以上の PoP が 90 以上の都市に展開されています。PoP の役割は、オリジンサーバー (S3 バケットや EC2 インスタンスなど) のコンテンツをキャッシュし、ユーザーに物理的に近い場所から配信することで、レイテンシを削減することです。東京のユーザーが米国バージニアの S3 バケットに直接アクセスすると、太平洋を横断する往復で 150〜200ms のレイテンシが発生します。東京の PoP にコンテンツがキャッシュされていれば、レイテンシは 5〜10ms に短縮されます。PoP のサイズは均一ではありません。東京、ロンドン、バージニアのような大規模 PoP は数千台のサーバーで構成され、大量のコンテンツをキャッシュできます。一方、小規模な都市の PoP は数十〜数百台で、キャッシュ容量は限られます。CloudFront はトラフィック量に応じて PoP のキャパシティを動的に調整しており、大規模イベント (スポーツ中継、製品発表など) の際には一時的にキャパシティを増強します。
Anycast ルーティング - ユーザーを最寄りの PoP に導く仕組み
CloudFront がユーザーのリクエストを最寄りの PoP にルーティングする仕組みは、DNS ベースのルーティングと Anycast の組み合わせです。ユーザーが CloudFront のディストリビューション URL (例: d1234.cloudfront.net) にアクセスすると、まず DNS 解決が行われます。CloudFront の DNS サーバーは、ユーザーの DNS リゾルバの IP アドレスから地理的な位置を推定し、最寄りの PoP の IP アドレスを返します。ここで Anycast が登場します。Anycast は、同じ IP アドレスを複数の PoP が同時にアナウンスする技術です。BGP (Border Gateway Protocol) のルーティングにより、パケットはネットワーク的に最も近い PoP に自動的に到達します。DNS ベースのルーティングだけでは、DNS リゾルバの位置とユーザーの実際の位置が異なる場合 (企業の集中 DNS サーバーを使用している場合など) に最適な PoP が選択されないことがあります。Anycast はネットワークレベルで最短経路を選択するため、この問題を補完します。2022 年以降、CloudFront は EDNS Client Subnet (ECS) にも対応しており、DNS リゾルバがユーザーの実際のサブネット情報を CloudFront の DNS に伝えることで、より正確な PoP 選択が可能になっています。
2 層キャッシュ - エッジロケーションとリージョナルエッジキャッシュ
CloudFront のキャッシュは 2 層構造になっています。第 1 層はエッジロケーション (PoP) で、ユーザーに最も近い場所にあります。第 2 層はリージョナルエッジキャッシュ (REC) で、エッジロケーションとオリジンサーバーの間に位置します。REC は世界に 13 箇所あり、エッジロケーションよりも大きなキャッシュ容量を持っています。リクエストの流れはこうです。ユーザーのリクエストがエッジロケーションに到着し、キャッシュにコンテンツがあれば即座に返します (キャッシュヒット)。エッジロケーションにキャッシュがなければ、REC に問い合わせます。REC にキャッシュがあればそこから返し、なければオリジンサーバーに取りに行きます。この 2 層構造の利点は、オリジンサーバーへのリクエスト数を大幅に削減できることです。人気のないコンテンツ (ロングテール) は個々のエッジロケーションではキャッシュから追い出されやすいですが、REC の大きなキャッシュ容量により保持される確率が高くなります。AWS の公表データによると、REC の導入によりオリジンへのリクエスト数が最大 60% 削減されたケースがあります。
キャッシュヒット率を左右する設計要因
CloudFront のキャッシュヒット率は、設計次第で 50% にも 99% にもなります。キャッシュヒット率を決定する最大の要因はキャッシュキーの設計です。CloudFront はデフォルトで URL のフルパスをキャッシュキーとして使用しますが、クエリ文字列、ヘッダー、Cookie をキャッシュキーに含める設定にすると、同じコンテンツでもキャッシュキーが異なるため、キャッシュが分散してヒット率が低下します。たとえば、クエリ文字列にトラッキングパラメータ (utm_source、utm_medium など) が含まれる場合、同じページでもパラメータの組み合わせごとに別のキャッシュエントリが作られます。CloudFront のキャッシュポリシーで、キャッシュキーに含めるクエリ文字列をホワイトリスト方式で指定し、トラッキングパラメータを除外すれば、ヒット率が劇的に改善します。TTL (Time to Live) の設定も重要です。TTL が短すぎるとキャッシュが頻繁に無効化され、オリジンへのリクエストが増加します。静的アセット (画像、CSS、JS) は TTL を 1 年に設定し、ファイル名にハッシュを含める (app.a1b2c3.js) ことで、コンテンツ更新時に新しい URL でキャッシュを自動的に切り替える戦略が最も効果的です。
Origin Shield - 3 層目のキャッシュでオリジンを守る
2020 年に導入された Origin Shield は、REC とオリジンの間に追加のキャッシュ層を設ける機能です。Origin Shield を有効にすると、すべての REC からのオリジンフェッチが 1 つの Origin Shield ロケーションに集約されます。Origin Shield にキャッシュがあれば、オリジンへのリクエストは発生しません。Origin Shield の最大の効果は、キャッシュの「サンダリングハード問題」の緩和です。人気コンテンツの TTL が切れた瞬間、世界中の PoP から同時にオリジンへのリクエストが殺到する現象です。Origin Shield がなければ、13 の REC から同時にオリジンフェッチが発生しますが、Origin Shield があれば 1 つのリクエストに集約されます。Origin Shield の料金はリクエスト数ベース (1 万リクエストあたり 0.0090 USD) で、オリジンサーバーの負荷軽減とスケーリングコストの削減を考慮すると、多くのケースで費用対効果が高い投資です。特に、オリジンが Lambda Function URL や API Gateway のように従量課金のサービスである場合、Origin Shield によるリクエスト削減がそのままコスト削減につながります。CDN の設計と最適化を体系的に学ぶには、専門書籍 (Amazon)が参考になります。