パブリッククラウドリージョン向けスマートティアードキャッシュの改善

2021 年、私たちはスマート階層キャッシュ（Smart Tiered Cache）をリリースしました。そのコンセプトは、サイト背後にある各オリジンに対して、リアルタイムのレイテンシに基づいて、Cloudflare が通過させる最適な上位tier データセンターを 1 つ選択することです。スイッチを 1 つ切り替えるだけで、ネットワークからあなたのオリジンへの最速経路が見つかります。

これは、オリジンの IP アドレスが 1 つの固定された場所に存在する場合にのみ機能します。パブリッククラウド上のオリジンは通常そうではありません。それらはアニーキャスト（anycast）またはリージョンユニキャスト（regional unicast）のフロントエンド背後に位置しているため、1 つのオリジン IP が同時に dozen の Cloudflare データセンターに対して等しく近く見えることがあり、レイテンシプローブがロックオンできる対象がありません。スマート階層キャッシュはこれを安全な方法で処理します：明確な勝者がない場合、複数の上位tier にフォールバックします。何も壊れることはありません。ただし、単一の最寄りtier を選択する価値があったキャッシュ効率性という利点を失うことになります。

パブリッククラウドリージョン向けのスマート階層キャッシュは、クラウドリージョンのヒント（hint）を提供できるようにすることでこの問題を解決します。このヒントにより、Cloudflare はパブリッククラウド上のオリジンを正しいリージョンにマッピングし、オリジン IP 自体がアニーキャストまたは曖昧に見える場合でも、より適切なプライマリおよびフォールバック用の上位tier を選択できます。

私たちの最も人気のある階層キャッシュトポロジーをさらに賢くしました

リリース以来、スマート階層キャッシュは Cloudflare の顧客の間で最も人気のある階層キャッシュトポロジーとなっています。すべてのプランで無料で利用可能です。

私たちの作業の多くは、これを継続的に改善することを目指しています。時間の経過とともに、スマート階層キャッシュはより多くのオリジンアーキテクチャに対応するように拡張されてきました。その例として以下が挙げられます：

2024 年 11 月：R2 向けのスマート階層型キャッシュ（Smart Tiered Cache）では、R2 バケットが実際に存在する場所に対して最も近い上位ティアを自動的に選択するように学習させ、設定ゼロでレイテンシを削減しました。

2025 年 1 月：ロードバランシング（Load Balancing）向けのスマート階層型キャッシュでは、スマート階層型キャッシュの機能を拡張し、ロードバランシングプール全体に対して単一の最適な上位ティアを選択するようにしました。これにより、プール内のすべてのオリジンが同じキャッシュを共有できるようになり、ヒット率が向上します。

これらの改善はすべて、共通の目標を共有しています：顧客のオリジンインフラストラクチャを理解し、そのインフラストラクチャにとって最善の措置を自動的に実行することです。

私たちはこのシステムを長期間にわたって改善してきましたが、顧客からは依然として共通の不満の声が上がっていました。つまり、オリジンが anycast（アニーキャスト）またはリージョンユニキャストネットワークの背後にある場合、スマート階層型キャッシュは機能しないという点でした。なぜなら、このようなアーキテクチャでは、オリジンの場所を特定することができないからです。これは例外ケースではありません。anycast IP の背後でパブリッククラウドプロバイダにホストされているオリジンは、インターネット上で着実に増加している割合を占めています。

本日、私たちは AWS、GCP、Azure、Oracle Cloud にホストされたオリジンに対するこのギャップを解消します。

なぜ ancyast クラウドオリジンは異なるのか

スマートティアードキャッシュは、各 Cloudflare データセンターからオリジンの IP アドレスまでのレイテンシを測定することで動作します。最も低いレイテンシを持つデータセンターが上位層となり、キャッシュミスが発生した際にすべての要求が経由する単一のポイントとなります。キャッシュミスを一つのデータセンターに集中させることで、キャッシュヒット率の向上、オリジンへの接続数の削減、およびオリジンプル時のレイテンシ低下を実現できます。これは、信頼性のあるプローブが可能で固定されたユニキャスト IP アドレスを持つオリジンの場合に効果的です。

多くのクラウドプロバイダーは、ロードバランサー、フロントエンドサービス、およびリージョンのイングレスポイントに Anycast またはリージョン固有のユニキャストネットワークを使用しています。これらの IP をプローブすると、オリジンは同時に多くのデータセンターに対して「近い」状態にあるように見えます。これは、IP アドレスが単一の物理的なオリジン場所ではなく、クラウドプロバイダーのフロントエンドを表しているためです。同じ IP であっても、異なる Cloudflare データセンターは異なる近くのクラウドエッジに到達する可能性があり、プロバイダーはその要求を自社のネットワークを通じて実際のバックエンドへ転送します。そのため、スマートティアードキャッシュは、最適な上位層を確信を持って一つ選択することができません。

実際には、これにより大陸間を往復するヘアピン型トラフィックが発生し、追加のラウンドトリップが1回増えることになります。例えば、オリジンサーバーがシンガポールにあり、クラウドプロバイダーのアニーキャスト IP の背後にある場合、アニーキャストの仕組み上、シカゴのデータセンターがこの IP に対するプローブ遅延が最も低いと表示されることがあります。その結果、スマートティアードキャッシュ（Smart Tiered Cache）はシカゴを上位層として選択します。すると、アジアのエンドユーザーからのリクエストは近くの Cloudflare データセンターに到達しますが、そこから上位層であるシカゴへ大陸間を横断してルーティングされ、さらにシカゴがシンガポールのオリジンサーバーからデータを取得する際に再び海洋を越えるという経路になります。このヘアピン化により数百ミリ秒の遅延が発生し、クラウドホスト型のオリジンを持つ顧客から一貫して報告されている問題の一つとなっています。

ヘアピン型の例として、トラフィックがシカゴの上位層にルーティングされるものの、データ取得元がシンガポールのオリジンであるため、不要な大陸間往復が生じるケースがあります。

この不要な行き来を解消するため、Smart Tiered Cache は物理学の制約である光速を用いて、anycast 起源を検出する学習を行いました。世界中の複数のチェックポイントデータセンターから起源までのプローブ遅延時間を測定します。2 つのチェックポイントデータセンターからの結合遅延時間が、光がファイバー内を物理的に移動できる速度よりも速い場合、その起源は単一の場所ではなく複数の場所で応答していることになります。つまり、それは anycast です。

複数の Cloudflare データセンターからのプローブ遅延時間を比較することで、anycast 起源を検出します。2 つの経路が単一の起源場所に対して物理的に可能であるよりも速い場合、その起源は複数の場所で応答している可能性が高いです。

Smart Tiered Cache が anycast 起源を検出すると、安全策として動作します：その IP を単一の上位層に固定しません。代わりに、複数の上位層を持つ階層型キャッシュトポロジーにフォールバックします。階層型キャッシングは依然として機能しますが、1 つではなく複数の層にトラフィックを分散させることで、より多くのリクエストが起源に到達することになります。一部のセットアップではこれは許容できるトレードオフです。しかし、anycast IP の背後にあるパブリッククラウド上に存在する起源に近い上位層を 1 つだけ望む場合、これまで良い選択肢はありませんでした—それが今や解決しました。

Tell us the region

Cloudflare ダッシュボードから、Caching > Tiered Cache > Origin Configuration に移動します。対象のオリジン IP を見つけて「Set Region Hint」をクリックし、クラウドリージョン（例：aws:us-east-1 または gcp:europe-west1）を指定してください。Smart Tiered Cache がその後を引き継ぎます。なお、ダッシュボード上では、Anycast として検出されたオリジンの IP のみに対してリージョンヒントを設定できる点にご注意ください。

Tiered Cache ページの Origin Configuration テーブルに移動し、オリジン IP の横にある編集アイコンをクリックして、そのリージョンヒントを設定します。

IP ごとにヒントを設定することもできますし、すべてのオリジン IP に対してクラウドリージョンを一括で編集することも可能です。ダッシュボード以外でも、API や Terraform を通じて同じ設定が可能であるため、既存の Infrastructure as Code ワークフローに統合することができます。

AWS、GCP、Azure、Oracle Cloud での提供を開始し、今後さらに多くのプロバイダーが追加される予定です。

How Smart Tiered Cache for Public Cloud Regions works

数時間ごとに、各サポート対象のクラウドプロバイダーから最新の IP レンジファイルを取得しています。これらのファイルは、すべてのクラウドリージョンを現在の IP プレフィックスセットにマッピングしており、プロバイダーがサブネットを追加・削除・再割り当てした際に、それを検出します。

パブリッククラウド向けのスマートティアードキャッシュシステム図

これらのサブネットを、15 分ごとに更新される継続的なレイテンシプローブから構築された上位層データベースと照合します。各クラウドリージョンについて、一致する各サブネットは、その現在の上位層割り当てに基づいて加重投票を行います。最も強い信号を示す上位層が、そのリージョンのプライマリ上位層となります。プライマリとフォールバックは常に異なるポイントオブプレゼンス（PoP）から提供されるため、1 つの PoP が停止しても両方が同時に利用不能になることはありません。

一部のリージョンではプローブデータが十分でない場合があります。例えば、新しいリージョンのクラウドプロバイダーがまだ展開中である場合や、そのリージョンに Cloudflare へのオリジン接続がまだ設定されていない場合などです。この場合は投票対象となるデータが存在しません。そのため、地理的な位置に基づいてフォールバックし、当社の Tier 1 PoP のうち最も近いものを選択します。オリジンがオンラインになりプローブデータが蓄積されるにつれて、そのリージョンは自動的に地理的な推測から、実際のデータに裏付けられた最適なオプションへと静かに切り替わります。

今すぐお試しください。次なるステップについては...

つまり、キャッシュに最適なリージョンを選択するための作業——各リージョンの最上位階層をアルゴリズム的に選定する継続的なプロービング、地理的なフォールバック、PoP 間のフェイルオーバーなど——はすべて当社側で実行されます。お客様の役割は、リージョンヒントを選択することだけです。

アニーキャストオリジンがパブリッククラウド上に設置されている場合、すぐにこの機能を有効にできます。ダッシュボードでは、「Caching > Tiered Cache > Origin Configuration」へ移動し、対象のオリジン IP を見つけて「Set Region Hint」をクリックして、希望するリージョンを選択してください。

次は、より多くのプロバイダーへの展開と、Smart Tiered Cache がさらに多様なオリジン設定を認識し、自ら適切な経路を選べるように学習を進めることに注力します。Tiered Cache があなたのサービスにどのような恩恵をもたらすか詳しく知りたい場合は、当社の Tiered Cache ドキュメントをご覧ください。