DocsDigest
一覧へLanguage: EN
OpenAICloudflare2026/07/10 13:00

Improving Smart Tiered Cache for Public Cloud Regions

要点だけを先に読めるように短く再構成したセクションです。

元記事
OpenAIClaude

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

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

公開クラウドリージョン向け Smart Tiered Cache の改善

tiered cacheanycastcloud-regionscachingterraformapilatency-probing

Key Points

  • リージョンヒント追加
  • エニキャスト検出でヘアピン回避
  • API・Terraform対応

Summary

公開クラウド（AWS/GCP/Azure/Oracle）で anycast やリージョナル unicast を使うオリジン向けに、Smart Tiered Cache が「リージョンヒント」を受け取れるようになりました。これにより、Cloudflare はオリジンが実際に存在するクラウドリージョンを参照して最適なプライマリ／フォールバック上位ティアを選択し、不要な大陸横断のヘアピンやレイテンシ増を抑制します。

Key Points

  • 何が変わったか
    • ダッシュボード（Caching > Tiered Cache > Origin Configuration）または API / Terraform でオリジンIPにクラウドリージョンヒント（例: aws:us-east-1）を設定できるようになった。
  • なぜ有効か
    • Anycast のために IP が複数拠点で応答している場合、従来は複数上位ティアへフォールバックしてキャッシュ効率が下がっていた。リージョンヒントで正しいリージョンに紐づけることで単一の最適上位ティアを選べる。
  • 検出・選定ロジック（運用面のポイント）
    • Cloudflare は複数チェックポイントからのプローブ遅延を使い、光ファイバの物理限界より速い応答がある場合を anycast と判定する。
    • 対応クラウドの最新 IP プレフィックスを定期取得し、サブネットごとの上位ティア投票（重み付け）でリージョンのプライマリ／フォールバック PoP を決定する。プローブデータは継続的に更新（15分間隔）され、データ不足時は地理的最短 PoP にフォールバックする。
  • 運用上の利点
    • ヘアピン回避によるレイテンシ低減、キャッシュヒット率向上、オリジンへの接続数削減。
  • 今やるべきこと（実務的手順）
    • anycast 背後のオリジンIPを確認し、ダッシュボードまたは API/Terraform でリージョンヒントを設定する。
    • 新規リージョンや未登録のクラウドプロバイダについては今後対応予定なので、運用中はモニタリングを継続する。

短い技術注意点

  • プライマリとフォールバックは別 PoP を選ぶため、単一 PoP 故障で両方が落ちるリスクは低い。
  • 一時的にプローブデータが不足するリージョンは最初は地理的推定で運用され、データ蓄積後に自動切替される。

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

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