パブリッククラウドリージョン向けスマートティアードキャッシュの改善
Cloudflare は、パブリッククラウドの Anycast IP やリージョン非特定環境でも最適なキャッシュ経路を選択できるよう、「Smart Tiered Cache for Public Cloud Regions」機能を公開し、AWS、GCP、Azure、Oracle Cloud の利用効率を大幅に向上させた。
キーポイント
Anycast/リージョン不明なクラウド_origin への対応
従来の Smart Tiered Cache は Anycast IP やリージョン非特定環境でキャッシュ効率が低下していたが、新しい機能によりクラウドリージョンのヒントを提供することで、最適な上位ティアを自動選択可能になった。
主要クラウドプロバイダーへの対応拡大
AWS、GCP（Google Cloud）、Azure、Oracle Cloud 上でホストされたオリジンサーバーに対して、この新機能が即座に適用されるようになった。
設定不要の自動最適化と既存機能との統合
R2 バケットやロードバランシングプール向けに既に実装されている自動最適化ロジックと同様に、本機能も顧客による追加設定なしで動作し、キャッシュヒット率を最大化する。
パブリッククラウドの普及に伴う課題解決
Anycast IP を使用するパブリッククラウドオリジンの増加という市場トレンドに対し、ネットワーク遅延プローブがロックオンできないという技術的ボトルネックを解消した。
Anycast による誤った上位層選定のリスク
クラウドプロバイダーの Anycast IP を使用すると、複数のデータセンターから近接しているように見えてしまい、物理的に遠い場所（例：シカゴ）が不適切に上位層として選択され、大陸間を往復する「ヘアピン」トラフィックが発生します。
光速の制約を利用した Anycast 検出
複数のチェックポイントからのプローブ遅延値を比較し、光がファイバー中を伝播する物理的な限界時間よりも速い応答が得られた場合、その IP が単一の物理場所ではなく Anycast であると判定します。
AnyCast オリジンの検出と従来の制限
Cloudflare は複数のデータセンターからのプローブ遅延を比較して AnyCast オリジンを検出し、従来は単一の上位ティアに固定せず複数ティアに分散させることで安全性を保っていたが、これによりオリジンへのリクエスト数が増える課題があった。
影響分析・編集コメントを表示
影響分析
この発表は、パブリッククラウドプロバイダーが Anycast IP を広く採用している現状において、CDN ユーザーがキャッシュ効率を最大化するための決定的な解決策を提供するものです。これにより、複雑なネットワーク構成でも設定負荷なく低遅延・高スループットを実現でき、大規模パブリッククラウド環境での Web アプリケーションのパフォーマンスとコスト最適化に直結します。
編集コメント
パブリッククラウドのネットワーク構造変化（Anycast の普及）に対し、CDN ベンダーが即座にアルゴリズムを適応させた好例です。開発者にとって設定不要でパフォーマンスが向上する点は非常に実用的です。
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 ドキュメントをご覧ください。
原文を表示
In 2021, we shipped Smart Tiered Cache. The idea: for each origin behind your site, Cloudflare picks the single best upper-tier data center to route through, based on real-time latency. Flip one switch, and we find the fastest path from our network to your origin.
That works as long as an origin IP lives in one fixed place. Public cloud origins usually don't. They sit behind anycast or regional unicast front ends, so one origin IP can look equally close to a dozen Cloudflare data centers at once — and the latency probes have nothing to lock onto. Smart Tiered Cache handles this the safe way: when there's no clear winner, it falls back to several upper tiers. Nothing breaks. You just lose the thing that made a single closest tier worth it, which is cache efficiency.
Smart Tiered Cache for Public Cloud Regions fixes this by letting you provide a cloud region hint. With that hint, Cloudflare can map public cloud origins to the right region and select better primary and fallback upper tiers, even when the origin IP itself looks anycast or ambiguous.
We made our most popular tiered cache topology smarter
Since it was launched, Smart Tiered Cache has become the most popular tiered cache topology among Cloudflare customers. It’s available to all plans, for free.
Much of our work aims to continually improve it. Over time, we’ve extended Smart Tiered Cache to handle more origin architectures, including:
November 2024: Smart Tiered Cache for R2: We taught Smart Tiered Cache to automatically select the closest upper tier to where the R2 bucket actually lives, reducing latency with zero configuration.
January 2025: Smart Tiered Cache for Load Balancing: We extended Smart Tiered Cache to select a single optimal upper tier for an entire Load Balancing pool, so all origins in the pool share the same cache, improving hit ratios.
Each of these improvements has shared a common goal: understand the customer’s origin infrastructure and automatically do the best thing for that infrastructure.
While we’ve been improving this system for a while, customers still had a common frustration: Smart Tiered Cache did not work when an origin is behind an anycast or regional unicast network, because this architecture prevented us from knowing where the origin is located. And this wasn’t an edge case, either. Origins hosted on public cloud providers behind anycast IPs are a growing slice of the Internet.
Today, we’re closing that gap for origins hosted on AWS, GCP, Azure, and Oracle Cloud.
Why anycast cloud origins are different
Smart Tiered Cache works by measuring the latency from each Cloudflare data center to the origin’s IP address. The data center with the lowest latency becomes the upper tier: the single point through which all cache misses funnel on their way to your origin. By concentrating cache misses at one data center, you get higher cache hit ratios, fewer connections to your origin, and lower latency on origin pulls. This works well when the origin has a fixed, unicast IP address that can be reliably probed.
image
Many cloud providers use anycast or regional unicast networking for their load balancers, front-end services, and regional ingress points. When we probe these IPs, the origin appears to be “close” to many data centers simultaneously. That is because the IP address represents the cloud provider’s front end, not a single physical origin location. Different Cloudflare data centers may reach different nearby cloud edges for the exact same IP, and the provider then carries the request across its own network to the actual backend. So Smart Tiered Cache cannot confidently pick one best upper tier.
In practice, this could result in hairpin traffic across continents, adding a whole extra round trip. Say your origin sits in Singapore, behind an anycast IP from a cloud provider. Because of how anycast works, our Chicago data center might show the lowest probe latency to that IP. Smart Tiered Cache would then select Chicago as the upper tier. The result: a request from an end user in Asia hits a nearby Cloudflare data center, gets routed cross-continent to the upper tier in Chicago, and Chicago fetches from the origin back in Singapore, crossing the ocean twice. That hairpinning adds hundreds of milliseconds of latency, and it's one of the most consistently reported issues from customers with cloud-hosted origins.
image
An example of hairpinning is when traffic is routed to an upper tier in Chicago only to fetch data from an origin in Singapore, resulting in an unnecessary cross-continental round trip.
To address this unnecessary back-and-forth, Smart Tiered Cache learned to detect anycast origins with a constraint from physics: the speed of light. We measure probe latencies from multiple checkpoint data centers around the world to the origin. If the combined latencies from two checkpoint data centers are faster than what light in fiber could physically travel between the two, the origin must be answering from multiple locations, not one. That means it's anycast.
image
We detect anycast origins by comparing probe latencies from multiple Cloudflare data centers. If two paths are faster than physically possible for a single origin location, the origin is likely answering from multiple places.
When Smart Tiered Cache detects an anycast origin, it plays it safe: it won't pin that IP to a single upper tier. Instead, it falls back to a tiered cache topology with multiple upper tiers. Tiered caching still works, but spreading traffic across multiple tiers instead of one means more requests reach the origin. For some setups that’s a fine trade. But if you want one upper tier close to an origin that lives on a public cloud behind anycast IPs, there hasn't been a good option — until now.
Tell us the region
From the Cloudflare dashboard, go to Caching > Tiered Cache > Origin Configuration. Find your origin IP, click "Set Region Hint," and tell us the cloud region (for example, aws:us-east-1 or gcp:europe-west1). Smart Tiered Cache takes over from there. Note that, on the dashboard, region hints can only be set for origins whose IPs we've detected as anycast.
image
On the Tiered Cache page, go to the Origin Configuration table and click the edit icon next to an origin IP to set its region hint.
You can set hints one IP at a time, or bulk-edit cloud regions for all your origin IPs at once. Beyond the dashboard, the same configuration is available via the API and through Terraform, so you can integrate it into your existing infrastructure-as-code workflows.
image
We're launching with AWS, GCP, Azure, and Oracle Cloud, with more providers coming.
How Smart Tiered Cache for Public Cloud Regions works
Every few hours, we fetch the latest IP range files from each supported cloud provider. These files map every cloud region to its current set of IP prefixes, so when a provider adds, removes, or reassigns a subnet, we pick it up.
image
Smart Tiered Cache for Public Cloud system diagram
We match those subnets against our upper tier database, which is built from continuous latency probing refreshed every 15 minutes. For each cloud region, each matching subnet contributes a weighted vote based on its current upper-tier assignment. The upper tier with the strongest signal becomes the region’s primary upper tier. Primary and fallback always come from different points of presence (PoPs), so losing one PoP can't take out both.
Some regions don't have enough probe data, for example, perhaps the new region’s cloud provider is still rolling out, or the region has no origin onboarded to Cloudflare yet — so there’s nothing to vote on. We fall back to geography: the closest of our Tier 1 PoPs. As origins come online and probe data builds up, the region quietly switches from that geographic guess to the option backed by real data.
Try it now, and what's next
All this means that the work of selecting the optimal region for your cache — the constant probing, the algorithmic choice of each region's best upper tier, the geographic fallbacks, the failover across PoPs — runs on our side. Your job is selecting the region hint.
If your anycast origin sits on a public cloud, you can turn this on now. In the dashboard, go to Caching > Tiered Cache > Origin Configuration. Find your origin IP, click Set Region Hint, and pick your region.
Next up, we’re expanding to more providers, and continuing to teach Smart Tiered Cache to recognize more origin setups and pick the right path on its own. To learn more about how Tiered Cache can benefit your service, check out our Tiered Cache documentation.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み