DocsDigest
Back to listLanguage: JA
OpenAICloudflareJul 10, 2026, 1:00 PM

Improving Smart Tiered Cache for Public Cloud Regions

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

openaienmodel: gpt-5-mini-2025-08-07

Improving Smart Tiered Cache for Public Cloud Regions

tiered-cacheanycastcloud-regionsawsgcpazureoracle-cloudterraform

Key Points

  • Set region hints for anycast cloud origins
  • Detects anycast via latency speed-of-light check
  • Maps cloud regions to optimal primary and fallback upper tiers

Summary

Cloudflare’s Smart Tiered Cache now supports public cloud regions (AWS, GCP, Azure, Oracle Cloud) for origins that appear anycast. Engineers can provide a region hint so Cloudflare maps the origin to the correct cloud region and selects an optimal primary and fallback upper tier, reducing cross-continent hairpinning and improving cache efficiency.

Key Points

  • When an origin IP is detected as anycast, set a region hint in the dashboard (Caching > Tiered Cache > Origin Configuration > Set Region Hint) or via API/Terraform. Hints can be set per-IP or bulk-edited.
  • Anycast detection uses multi-checkpoint latency probes and a speed-of-light constraint: if combined probe latencies are faster than physically possible from a single location, the IP is treated as anycast and won’t be pinned automatically.
  • Cloudflare fetches cloud provider IP range files every few hours and uses continuous upper-tier latency probes (refreshed ~every 15 minutes) to map subnets to upper tiers.
  • For each cloud region, matching subnets cast weighted votes based on current upper-tier assignments; the strongest signal chooses the region’s primary upper tier and distinct PoPs are chosen for primary and fallback to avoid single-PoP failures.
  • If probe data is insufficient for a region, the system falls back to the geographically closest Tier 1 PoP and migrates to data-driven choices as probes accumulate.
  • Benefits: fewer origin connections, higher cache hit ratios, and reduced latency from avoided hairpin routing.

How to enable

  • Dashboard: Caching > Tiered Cache > Origin Configuration -> edit an anycast-detected origin -> Set Region Hint (examples: aws:us-east-1, gcp:europe-west1).
  • API / Terraform: same configuration is available for automation and infra-as-code workflows.

Notes for engineers

  • Only origins Cloudflare detects as anycast can be assigned region hints from the dashboard; API/Terraform supports bulk operations.
  • Supported providers at launch: AWS, GCP, Azure, Oracle Cloud. More providers planned.
  • Configuration hands off selection and failover logic to Cloudflare; your action is to provide accurate region hints for public-cloud anycast origins.

Full Translation

Translations

A translation section that keeps the flow of the original article.

openaijamodel: gpt-5-mini-2025-08-07

パブリッククラウドリージョン向け Smart Tiered Cache の改善

パブリッククラウドリージョン向け Smart Tiered Cache の改善

2026-07-10 — Chenxi Zhang — 読了 6 分

2021 年に私たちは Smart Tiered Cache をリリースしました。アイデアは単純です：サイト背後の各オリジンについて、Cloudflare はリアルタイムのレイテンシに基づいてルーティングする最適な単一の上位データセンター（upper-tier）を選択します。スイッチ一つで、ネットワークからオリジンまでの最速経路を見つけます。

ただしこれは、オリジン IP が単一の固定場所にある場合に限ります。パブリッククラウドのオリジンは通常そうではありません。ロードバランサーやフロントエンドが anycast やリージョナルなユニキャストで公開されているため、1 つのオリジン IP が複数の Cloudflare データセンターに同等に近く見え、レイテンシプローブでは位置を特定できないことがあります。

Smart Tiered Cache は安全な方法でこれに対処します：明確な勝者がいない場合、複数の上位 tier にフォールバックします。何も壊れませんが、単一の最寄り tier を選ぶことによるキャッシュ効率が失われます。

今回導入した「Smart Tiered Cache for Public Cloud Regions」は、クラウドのリージョンヒントを提供できるようにすることでこれを解決します。ヒントがあれば、anycast や曖昧な IP 表示であっても Cloudflare はオリジンを正しいクラウドリージョンにマップし、より適切なプライマリおよびフェイルバックの上位 tier を選べます。

これまでに行ってきたこと

Smart Tiered Cache は導入以来、Cloudflare の顧客の間で最も人気のある tiered cache トポロジーになりました。全プランで無料で利用可能です。継続的な改善の一環として、これまでに多くのオリジン構成にも対応できるよう拡張してきました。

  • 2024 年 11 月：Smart Tiered Cache for R2 — R2 バケットが実際に存在する場所に最も近い上位 tier を自動で選択するようにしました（ゼロ設定でレイテンシ短縮）。
  • 2025 年 1 月：Smart Tiered Cache for Load Balancing — ロードバランシングプール全体に対して単一の最適上位 tier を選出するよう拡張し、プール内のすべてのオリジンが同一キャッシュを共有することでヒット率を向上させました。

これらの改善の共通目標は、顧客のオリジンインフラを理解し、そのインフラに対して自動的に最適な判断を下すことです。

Anycast クラウドオリジンが特別な理由

Smart Tiered Cache は、各 Cloudflare データセンターからオリジンの IP へプローブして得られるレイテンシを元に動作します。最も低いレイテンシを示したデータセンターが上位 tier になり、すべてのキャッシュミスがその一点を経由してオリジンに向かいます。キャッシュミスを一箇所に集中させることで、キャッシュヒット率の向上、オリジンへの接続数削減、オリジンプルのレイテンシ低下を実現します。

しかしクラウドプロバイダはロードバランサーやフロントエンド、リージョナルな入口で anycast やリージョナルユニキャストを使うことが多く、同じ IP をプローブしても多くのデータセンターから「近い」と表示されることがあります。これはその IP がクラウドプロバイダのフロントエンドを表していて、単一の物理的オリジン位置を示していないためです。異なる Cloudflare データセンターは同じ IP に対してそれぞれ近いクラウドエッジに到達し、プロバイダ側でリクエストをバックエンドに引き回す場合があります。

そのため Smart Tiered Cache は確実に 1 つの最良上位 tier を選べません。実運用では大陸横断のヘアピン（往復迂回）が発生し、余計な往復が入って数百ミリ秒の遅延を招くことが報告されています。

例：オリジンがシンガポールにあり anycast IP の背後にあるとします。anycast の振る舞いにより、弊社のシカゴ（Chicago）データセンターがその IP に対して最も低いプローブレイテンシを示すことがあり得ます。Smart Tiered Cache がシカゴを上位 tier に選ぶと、アジアのエンドユーザーからのリクエストが近隣の Cloudflare データセンターに到達したあと、シカゴ経由でシンガポールのオリジンへ戻るという、不要な大陸横断ループが発生します。

anycast の検出方法（光速による制約）

不要な往復を防ぐため、Smart Tiered Cache は物理学的制約（光速）を使って anycast を検出します。複数のチェックポイントとなるデータセンターからオリジンへプローブし、2 つのチェックポイントからの合成レイテンシが、単一地点の往復として光ファイバー中で物理的にあり得る最短時間を下回る場合、そのオリジンは複数地点で応答している（anycast）とみなします。

簡単に言うと：複数の Cloudflare データセンターからのプローブ経路の合算が単一ロケーションでは説明できないほど速ければ、その IP は複数の場所から応答している可能性が高い、ということです。

anycast 検出時の挙動

Smart Tiered Cache が anycast を検出すると、安全策としてその IP を単一の上位 tier に固定しません。代わりに複数の上位 tier を持つ tiered cache トポロジーにフォールバックします。これにより tiered caching 自体は機能しますが、トラフィックが複数の上位 tier に分散されるため、オリジンに到達するリクエスト数が増え、キャッシュ効率は下がります。

このトレードオフは多くの構成で受け入れられる場合もありますが、パブリッククラウドの anycast 背後にあるオリジンに対して「オリジン近傍に単一の上位 tier を置きたい」ニーズがあり、その選択肢がこれまで十分ではありませんでした。そこで今回のリージョンヒント機能です。

リージョンヒントの設定方法

ダッシュボードで次の操作を行います：

  1. Caching > Tiered Cache > Origin Configuration に移動します。
  2. オリジン IP を見つけ、Set Region Hint（または編集アイコン）をクリックします。
  3. クラウドリージョンを選択します（例：aws:us-east-1 や gcp:europe-west1）。

注意点：ダッシュボード上では、リージョンヒントは弊社が anycast と検出したオリジン IP に対してのみ設定できます。

  • ヒントは個別の IP 毎に設定することも、一括でクラウドリージョンを編集することも可能です。
  • ダッシュボード以外に、同じ設定は API と Terraform 経由でも利用可能です。インフラストラクチャをコードで管理しているワークフローに組み込めます。
  • 現時点での対応プロバイダは AWS、GCP、Azure、Oracle Cloud で、今後さらに拡大予定です。

Smart Tiered Cache for Public Cloud の動作概要

  • 数時間ごとに、対応クラウドプロバイダから最新の IP レンジファイルを取得します。これにより各クラウドリージョンとそのサブネットの現在の対応関係を把握します。
  • 取得したサブネットを、継続的なレイテンシプローブ（15 分ごとに更新される）で構築された上位 tier データベースと照合します。
  • 各クラウドリージョンについて、マッチしたサブネットそれぞれが現在の上位 tier 割り当てに応じた重み付き投票を行います。最も強いシグナルを持つ上位 tier がそのリージョンのプライマリになります。
  • プライマリとフェイルバックは常に異なる PoP（Point of Presence）から選ばれます。つまり 1 つの PoP を失っても両方が同時に失われることはありません。
  • 一部のリージョンではプローブデータが不足する場合があります（プロバイダがローリング展開中、あるいはそのリージョンにまだ Cloudflare に接続されたオリジンがない等）。その場合は地理的に近い Tier 1 PoP をフォールバックとして使用します。オリジンが稼働しプローブデータが蓄積されるにつれて、地理的推測から実測に基づく選択へと静かに切り替わります。

今すぐ試す方法と今後の予定

  • これにより、最適なキャッシュ地域の選定（継続的なプローブ、各リージョンの最良上位 tier のアルゴリズム選定、地理的フォールバック、PoP 間のフェイルオーバー）はすべて弊社側で行われます。お客様がするべきことはリージョンヒントを選ぶことだけです。
  • anycast の背後にあるパブリッククラウドオリジンをお持ちであれば、今すぐ有効化できます。ダッシュボードで Caching > Tiered Cache > Origin Configuration に行き、オリジン IP を選んで Set Region Hint を設定してください。
  • 次のステップとして、対応プロバイダの拡大と、さらに多様なオリジン構成を Smart Tiered Cache が自動認識して最適経路を選べるよう継続的に改良していきます。

詳細や Tiered Cache の利点については、Tiered Cache documentation をご参照ください。

タグ: Tiered Cache、Cache Performance、Product News、CDN、Smart Shield