Argo Smart Routing

解決する課題

• インターネットの標準的な経路（BGPが選ぶ最短ホップ数の経路）は、必ずしもその瞬間に最速・最安定とは限らない
• 特定の区間で輻輳やピアリングの混雑が起きると、オリジンまでの往復時間（RTT）が悪化し、体感速度が落ちる
• 遠隔地のオリジン、あるいは経路品質が不安定な地域からのアクセスで、タイムアウトや接続エラーが増える
• キャッシュ不可のAPIレスポンスや動的コンテンツなど、キャッシュでは救えないトラフィックの速度を改善したい

主要概念と用語

• Argo Smart Routing: Cloudflareのネットワークが常時収集する経路品質データを基に、リクエストごとに最適な中継経路を選んでオリジンへ転送する機能
• 最速経路 (Fastest Path): 単純な最短ホップではなく、実測の遅延・パケットロス・輻輳状況から動的に算出される、その時点で最も効率の良い経路
• ラストマイル (Last Mile): Cloudflareのエッジからオリジンサーバーまでの区間。Argoが最適化する主対象で、ユーザーからエッジまでの区間とは区別される
• Tiered Cache: 上位（親）データセンターを経由させてキャッシュ階層を作る機能。Argoと併用するとキャッシュ未ヒット時のオリジンフェッチも効率化される
• Argo Tunnel（現Cloudflare Tunnel）: 名称が似るが別機能。オリジンを公開せずにトンネル接続する製品で、Argo Smart Routingとは目的が異なる
• アナリティクス (Argo Analytics): 有効化前後の応答時間改善を可視化するレポート機能

仕様・制限・クォータ

• ゾーン（ドメイン）単位で有効化するアドオン機能で、有効化するとそのゾーンを通るトラフィック全体に適用される
• 課金は多くの場合、経由したデータ転送量に応じた従量制であり、固定費とは別に発生する（具体的な単価は公式の料金ページを参照）
• 効果はオリジンの地理的な位置やユーザー分布、既存の経路品質に依存するため、改善幅は環境ごとに異なる
• Tiered Cachingと組み合わせる場合、キャッシュ階層の構成（Smart Tiered CacheかCustom Tiered Cacheか）によって最適化される区間の範囲が変わる
• プランやアカウント種別によって、有効化できる範囲や提供形態（アドオンかバンドル済みか）が異なることがある

内部の仕組み

Cloudflareのネットワークは、自ネットワーク上を流れる膨大なリクエストのタイミング情報から、データセンター間・エッジからオリジンまでの各区間の遅延・パケットロス・輻輳状況をほぼリアルタイムに近い頻度で集計しています。Argo Smart Routingは、このデータを使ってリクエストごとに転送経路を動的に選び直します。

• ユーザーのリクエストはまず最寄りのCloudflareエッジに到達する（ここは通常のAnycastルーティング）
• キャッシュミスやキャッシュ不可のコンテンツの場合、エッジからオリジンへ向かう区間で、Argoが現在最も効率の良い中継データセンターの組み合わせを選択する
• 選ばれた経路は、標準のインターネット経路（BGPが選ぶ経路）よりホップ数が増えることもあるが、実測ベースでは遅延やロスが小さくなるよう選ばれる
• 経路品質データは継続的に更新されるため、輻輳の発生や解消に応じて選ばれる経路も追従して変化する

設計パターン / ベストプラクティス

• 動的コンテンツ中心のサイト・API: キャッシュで吸収できないトラフィックが多いほど、Argoによる恩恵を受けやすい
• オリジンが特定リージョンに集中している場合: ユーザーとオリジンの距離が遠い地域ほど、経路最適化の効果が出やすい
• Tiered Cachingとの併用: キャッシュミス時のオリジンフェッチ経路も最適化したい場合は、Tiered Cachingを合わせて有効化する
• 効果測定を先に行う: 有効化前後でArgo Analyticsのレスポンスタイム分布を比較し、実際の改善幅を確認してから本番トラフィック全体への適用可否を判断する
• 他の高速化機能と併用: HTTP/3やTLS 1.3、Smart Compression等の別のパフォーマンス機能と組み合わせて、区間ごとの最適化を積み重ねる

運用・監視

• Argo Analyticsでオリジンレスポンスタイムの改善状況を確認し、有効化の効果を継続的に把握する
• ダッシュボードやAPI経由でゾーン単位の有効・無効を切り替え可能なため、変更履歴は運用ルールとして残しておく
• 期待した改善が見られない場合は、まずキャッシュヒット率（そもそもオリジンへ行く割合）を確認し、次にオリジン自体の処理時間（アプリ側のレイテンシ）を切り分ける
• オリジンの地理的分散やマルチリージョン構成を変更した際は、改善幅も変わりうるため再測定するとよい

コスト

セキュリティ

• Argo Smart Routing自体はDDoS対策やWAFのようなセキュリティ機能ではなく、あくまで経路最適化機能である
• 経路選択の変更によってオリジンへの到達性は変わるが、認証・認可やアクセス制御の役割は担わないため、既存のWAFやアクセス制御は従来どおり別途構成する
• オリジンの保護（直接アクセスの遮断など）は、Argoの有無にかかわらず引き続き必要である

関連サービス・比較

ハンズオン / CLI例

Argo Smart Routingはダッシュボードから有効化するのが一般的ですが、API操作用のCLIとしてwranglerと同じCloudflare API基盤を使うcurlベースの確認・切り替え例を示します（wrangler自体にArgo専用サブコマンドはないため、Cloudflare APIを直接呼び出します）。

# 1) 対象ゾーンIDを確認（wranglerでログイン済みのAPIトークンを利用）
curl -s -X GET "https://api.cloudflare.com/client/v4/zones?name=example.com" \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json"

# 2) Argo Smart Routingの現在の設定状態を確認
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/argo/smart_routing" \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json"

# 3) Argo Smart Routingを有効化
curl -s -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/argo/smart_routing" \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"value":"on"}'

# 4) 併用する場合はTiered Cachingの状態も確認
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/cache/tiered_cache_smart_topology_enable" \
  -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  -H "Content-Type: application/json"