エッジPOPとDNSのみのルーティング: レイテンシーバジェットのトレードオフ

URLリダイレクトのレイテンシーバジェットには2つの領域があります。p50で約50ms以下はエッジPOP領域です - エニーキャストがユーザーを近くのキャッシュにルーティングし、TCPハンドシェイクが高コストになる前にリダイレクトが応答します。約50ms以上はDNSのみ領域です - DNSベースのロードバランシングが名前解決時にクライアントをルーティングし、リダイレクトは大陸をまたぐ1回のTCPラウンドトリップであり、バジェットにそのラウンドトリップが含まれます。アーキテクチャは表面上似ています(どちらも302を提供します)。パフォーマンスエンベロープは同じではありません。この記事はその比較です。

レイテンシーバジェットのコーナーストーン記事はリダイレクトのp95を15ms以下に保つ方法で詳しく説明しています。この記事はその背後にあるアーキテクチャ上の意思決定です。

「DNSのみのルーティング」が実際に意味すること

DNSのみのルーティングは「このクライアントはどのオリジンにアクセスすべきか?」という質問にDNS解決で答えます。TCPパスではありません。シドニーのユーザーがr.example.comを解決すると、DNSプロバイダー(Route 53レイテンシーベースのルーティング、CloudflareのGeoDNS、NS1など)が最も近いオリジンのIP(例えばリダイレクトサービスのシドニーインスタンス)を返します。

アーキテクチャ:

クライアント(シドニー) ──DNSクエリ── 権威DNS
       │                            │
       │  シドニーポッドのIPを返す   │
       ↓
   シドニーオリジン ──302リダイレクト──→ クライアント

DNSプロバイダーは実際のHTTPリクエストを見ません。リゾルバークエリのみを見ます - そのリゾルバーが1つの国離れたところにある場合、「最も近い」は推測になります。HTTPリクエスト自体は選択されたオリジンへの1回のラウンドトリップです。

ラウンドトリップコスト。 最速のパスは最寄りのオリジンへの1回のTCPハンドシェイク + 1回のHTTP交換です。最寄りのオリジンが40ms離れている場合(シドニー→シドニーローカル)、リダイレクトは壁時計で約60〜80ms(ハンドシェイク + リクエスト + レスポンス)で解決されます。

障害モード。 選択されたオリジンがダウンすると、DNS TTLがボトルネックになります。60秒のTTLは、クライアントが障害を発見して別のIPでリトライするまでに最大1分かかる可能性があることを意味します。DNSプロバイダーのヘルスチェックのケーデンスが実際の回復ウィンドウを設定します。

「エッジPOPルーティング」が実際に意味すること

エッジPOPルーティングは多くのリージョンにキャッシュサーバーのフリートを配置し、すべてが同じエニーキャストIPで応答します。そのIPへのクライアントの最初のパケットは、BGPによってトポロジー的に最も近いPOPにルーティングされます - 地理的な距離ではなく、ネットワーク的な意味での最近傍(最少ルーターホップ、最低測定レイテンシー)です。

アーキテクチャ:

クライアント(シドニー) ──エニーキャストIPへのパケット── BGP最近傍POP(シンガポール)
                                              │
                                  キャッシュヒット? 302で応答
                                              │
                                  キャッシュミス → オリジン(フランクフルト)
                                  キャッシュ → 302で応答

BGP最近傍のPOPがキャッシュからリダイレクトを提供します。キャッシュヒットはオリジンを完全にスキップします。キャッシュミスはまれです(デプロイ後のホットリンクの最初のミス。デプロイはキャッシュ全体ではなく、スラッグごとに1行を無効化します)。

ラウンドトリップコスト。 キャッシュヒットは壁時計で5〜15ms(ローカルPOPへのTCPハンドシェイク、即時レスポンス)で応答します。キャッシュミスはオリジンへの大陸をまたぐラウンドトリップ(約80〜150ms)を追加しますが、そのラウンドトリップは1回発生し、その後、行はPOPで次のリクエストのためにキャッシュされます。

障害モード。 POPが障害を起こすと、BGPがプレフィックスを撤回します。クライアントの次のパケットは自動的に次に近いPOPに向かいます。回復はサブ秒であり、サブ分ではありません。

どのアーキテクチャが適合するかを決める4つの数値

1. オリジン数。 オリジンが1つ(単一リージョンのデプロイ)の場合、DNSルーティングは役立ちません - ルーティングする対象がありません。エニーキャストPOPは単一オリジンをキャッシュでフロントすることで価値を追加します。

2. キャッシュヒット率。 エッジPOPはキャッシュが応答する場合にのみ高速です。URL短縮サービスはヒット率が95%以上あります - スラッグ対目的地のマップは小さく読み取り支配的です。ワークロードのヒット率が50%以下の場合、エッジPOPは「オリジン前の余分なホップ」に劣化し、DNSルーティングの方がクリーンなアーキテクチャです。

3. 地理的分布。 ユーザーの90%以上が1つの国にいる場合、両方のアーキテクチャは同様のパフォーマンスを発揮します - その国の1つのオリジンはすでに誰からも<30ms以内にあります。ユーザーが大陸をまたいで分布している場合、エッジPOPアーキテクチャが優位になりはじめます。DNSルーティングでフランクフルト単一オリジンにアクセスするシドニーのユーザーは、すべてのリダイレクトで大陸をまたぐRTT(約180〜220msのTCPハンドシェイク)を払います。シンガポールにエッジPOPがあると、同じユーザーは約25msを払います。

4. 遅い伝播に対する障害耐性。 DNSベースの回復は最も遅いリゾルバーのTTLキャッシュによって制限されます。一部のリゾルバーは低いTTLを守らず、最小TTLを60秒または300秒にキャップします。URL短縮サービスが時々オリジンをオフラインにする必要がある場合(デプロイ、メンテナンス、リージョンアウト)、DNSルーティングはデッドオリジン上のクライアントの長いテールを残します。エニーキャストはサブ秒で撤回します。

典型的なURL短縮サービスワークロードに対して4つの数値をプロットします:

• オリジン数: 通常2〜3(冗長性のためのマルチリージョン)
• キャッシュヒット率: 95〜99%(スラッグマップは小さい)
• 地理的分布: 通常マルチコンチネント(消費者向けのブランド)
• 障害耐性: ゼロ(リンクは印刷物にある。ダウンタイムは信頼を損なう)

4つすべてがエッジPOPを支持します。DNSのみのアーキテクチャは、リダイレクトサーフェスがリージョン的でスラッグマップが頻繁に変動するB2B SaaS内部ツール(読み取りより多くのキャッシュ無効化)に適しています。

レイテンシー数値の実際

同じワークロード(単一ショートリンク、コールドキャッシュからウォームキャッシュ)に対して、4つの場所から両方のアーキテクチャをベンチマークしました。以下の数値は場所ごとに1000回の連続リクエストのp50/p95です。

DNSのみのルーティング(フランクフルトの単一オリジン、GeoDNSルーティング):

オリジン場所	クライアント → フランクフルト	p50	p95
フランクフルト	<1ms	4ms	9ms
ロンドン	14ms	22ms	35ms
ニューヨーク	90ms	110ms	145ms
シンガポール	165ms	195ms	240ms

エッジPOPルーティング(FRA、ASH、SGP全体のエニーキャスト)、キャッシュHIT:

クライアント場所	ルーティング先POP	p50	p95
フランクフルト	FRA	3ms	7ms
ロンドン	FRA	11ms	18ms
ニューヨーク	ASH	5ms	9ms
シンガポール	SGP	4ms	8ms

ギャップはロングテールの場所にあります。フランクフルトはDNSのみの場合にオリジンそのものであるため、両方で同様に見えます。シンガポールが最も劇的です: p50で195msから4msへ - エッジPOPアーキテクチャがシンガポールから直接応答するためです。DNSのみのアーキテクチャは、どれだけキャッシュされていても、すべてのリダイレクトで大陸をまたぐラウンドトリップを払います。

コストのトレードオフ

エッジPOPは低ボリュームでリダイレクトあたりのコストが高くなります。POPを運営する固定コスト(小さなHetzner Falkensteingのボックスでも)は実在します。月100kリダイレクト未満では、単一オリジンに対するDNSのみのルーティングの方が安価です。

クロスオーバーは月100万リダイレクト前後です。それ以上では、キャッシュヒットのレスポンスがオリジンのコンピュートもオリジンの帯域幅も使わないため、エッジPOPアーキテクチャがリダイレクトあたりのコストで勝ります。オリジンはフルのリクエストボリュームではなく、キャッシュフィル(リクエストの約1%)のためにスケールします。

ほとんどのURL短縮サービスはワークロード分布が重いテール分布であるため、初日からクロスオーバーより上にあります - 少数のホットリンクがほとんどのクリックボリュームを担い、そのリンクは事実上無限のキャッシュヒット率を持ちます。

エッジPOPが解決しないもの

エッジPOPは万能のアップグレードではありません。遅くなるワークロードが3つあります:

1. 書き込み。 新しいリンクの作成、目的地の更新 - これらは権威オリジンに到達し、その後キャッシュ無効化レイヤーに伝播する必要があります。読み取りレイテンシーは優れています。書き込みレイテンシーはオリジンのみのパスとほぼ同じです。

2. パーソナライズされたリダイレクト。 スラッグだけでなくユーザーアイデンティティでルーティングするスマートリンクはPOPでキャッシュできません - ユーザーのプロフィールを読み取るために毎回オリジンにアクセスする必要があります。POPは薄いTLS終端プロキシになり、オリジンへの直接アクセスに比べて5〜10msを追加します。ほとんどのURL短縮サービスでは、パーソナライズされたリダイレクトがトラフィックの少数派であるため問題ありません。ディープリンク製品(Branch、Adjust)では、パーソナライゼーション率が50%に近く、アーキテクチャの計算が変わります。

3. ジオ制限された目的地。 リダイレクトの目的地がユーザーの地理によって変わる場合(国ごとに異なるランディングページ)、キャッシュキーに国を含める必要があります。これによりキャッシュが断片化します - スラッグごとに1行ではなく、N個のサポートされる国に対してスラッグごとにN行になります。キャッシュヒット率が下がり、キャッシュメモリコストが上がります。POPは依然として役立ちますが、より少なく。

URL短縮サービスでは、3番目のケースが注意すべきものです。ほとんどのショートリンクはユーザーのジオに関わらず1つのURLに解決されるため、単一のキャッシュキーが機能します。しかし、国別バリアントを追加すると、コスト方程式が変わります。

Elidoはこれをどう実装しているか

3つのPOP(Hetzner Falkenstein、Hetzner Ashburn、OVH Singapore)、所有する/24上のエニーキャスト。エッジでTLS + オンデマンド証明書にCaddy、リダイレクト自体にCaddyの後ろのfasthttp。2層キャッシュ: インプロセスLRU(L1、メモリ内で約1万のホットスラッグ) → Redis Cluster(L2、フルスラッグセット)。キャッシュミスはapi-coreのgRPCエンドポイントにフォールスルーし、Postgresから読み取ります。

キャッシュフィルのケーデンス: リンクの目的地への更新はRedpanda上の無効化イベントを発行します。エッジPOPがサブスクライブして影響を受けるスラッグのL1エントリを削除します。そのスラッグへの次のリクエストがL2にアクセスし(まだウォーム)、L1に投入します。3つのPOP全体でのp95無効化レイテンシーは約120msです。

このアーキテクチャはリダイレクトp95 < 15msコーナーストーン記事で運用詳細として説明されています。アーキテクチャドキュメントは/docs/architecture/edge-redirectに完全な図があります。

意思決定ツリー

DNSのみとエッジPOPアーキテクチャのどちらかを選ぶ場合の短いチェックリスト:

• 単一国のユーザーベース + 単一オリジン? DNSのみで十分です。過剰に設計しないでください。
• 多国籍ユーザー + 高いキャッシュヒット率? エッジPOP。ロングテールの場所でのレイテンシーの勝利は劇的です。
• 多国籍ユーザー + トラフィックの50%以上でパーソナライズされたリダイレクト? 混合。POPはTLS終端には役立ちますが、リダイレクト自体には役立ちません。SSL終端のみのための小さなPOPフリート + DNSルーティングを検討してください。
• フェイルオーバー速度の厳格なSLA? エッジPOPが勝ちます - BGP撤回はDNS TTLキャッシュを桁違いで上回ります。
• 月100万リダイレクト未満? DNSのみの方が安価です。100万以上で再評価してください。

万能な答えはありません。URL短縮サービスは特に「多国籍 + 高いキャッシュヒット率 + 厳格なフェイルオーバーSLA」のバケットに入る傾向があり、それがほとんどの本番URL短縮サービスが最終的にエッジPOPアーキテクチャに移行する理由です。移行コスト(キャッシュフィルの再アーキテクティング、POPプロバイダーの選択、BGPのセットアップ)は実在しますが、範囲が限定されています。

ブログの関連記事

• フランクフルト、アシュバーン、シンガポールからのリダイレクトでp95 < 15msを達成する - 運用詳細を含むコーナーストーン
• URLリダイレクトのキャッシュ戦略: いつ何を退避させるか - L1/L2キャッシュアーキテクチャ
• ファイア・アンド・フォーゲットのクリック取り込み - キャッシュルックアップ以外のリダイレクトパスで起こること
• クリック分析にClickHouseを使う理由(Postgresではなく) - 同じアーキテクチャの分析サイド
• TerraformとしてのショートリンクI: エッジ設定管理のIaC - エッジ設定管理のIaC