ウェブホスティング

Anycast DNS が自動的に高速になるわけではない理由 – 実際のテストと落とし穴

Anycast DNS は低レイテンシーの近道のように聞こえますが、実際の測定結果では次のようなことが明らかになっています。 エニーキャスト 必ずしも最速の応答時間を保証するわけではありません。テストでは、anycast DNS が期待を下回る結果になることが多い理由、その落とし穴、そして明確な指標と実行可能な改善策を用いて、パフォーマンスを現実的に評価する方法についてご説明します。 レイテンシー.

中心点

重要なポイントをまとめて、その内容についてすぐに理解できるようにします。 エニーキャスト 到着します。第一に、キャッシュは、Anycast ノードへの近さよりも、DNS の速度の知覚に大きく影響します。第二に、BGP は地理的な決定を行わず、ポリシーに従うため、最適ではない経路が生じる場合があります。第三に、ノード数が多いからといって、遅延の問題が自動的に解決されるわけではなく、分散性が高まる場合もある。第四に、測定方法では、エンドユーザーの視点とサーバーの視点を組み合わせる必要があり、そうしないと、見落としが生じる。第五に、真の最適化は、ルーティング、キャッシュ、モニタリング、および TTL.

キャッシング ユーザーレイテンシーが支配的であり、ルートクエリはまれです。.
BGP 誤った、より長いパスにつながる可能性があります。.
もっと ノードは、誤った割り当てを増加させる場合があります。.
測定クライアントとサーバーの視点が必要です。.
TTL そして、ピアリングは生々しい距離感を打ち破ります。.

Anycast DNS の実際の仕組み

Anycast は同一の IP を複数の場所に分散し、BGP はルーティングの観点から「最も近い」経路にリクエストを誘導しますが、必ずしも最も近い経路とは限りません。 データセンター. 監査では、ピアリング、ローカルプロバイダのポリシー、プレフィックスの長さが、地理よりもルートに大きな影響を与えていることをよく目にします。そのため、時間帯、負荷、ネットワークイベントによって、レイテンシーが顕著に変化します。地理的なロジックを期待している人は、実際には、多くの調整要素を含むポリシーロジックを見ていることになります。分類には、GeoDNS との比較が役立ちます。なぜなら、異なる手順は異なる結果をもたらすからです。 問題点 – 概要： GeoDNS 対 Anycast – 簡単なルーティングチェック.

キャッシュは近接性を打ち負かす：ルートおよび TLD の現実

ルート層およびTLD層では、 キャッシュ ユーザーエクスペリエンス。APNIC および RIPE の調査によると、TLD レコードは多くの場合 2 日間保持され、一般的なユーザーは 1 日に 1 回未満の頻度でルートクエリを発行します。この低い頻度により、ルートレベルでの最小限のエニーキャスト遅延という想定上の利点は、日常的にはほとんど意味を成しません。大規模な ISP リゾルバーにとって、これはルート経路がトラフィックの大部分に顕著な影響を与えないことを意味します。そのため、私は、権威あるネームサーバーおよびリゾルバーへのレイテンシーを優先的に測定しています。なぜなら、そこに真に関連性のある問題が発生しているからです。 タイムズ.

Anycastが自動的に高速になるわけではない理由

Anycast CDN の測定シリーズでは、クライアントの約 20% が最適ではないフロントエンドに到達し、平均で約 25 ミリ秒の遅延が発生しました。IMC の調査によると、約 10% は 100 ミリ秒以上の遅延が発生しました。 2015. これらの値は小さく聞こえるかもしれませんが、多くのリクエストや TLS ハンドシェイクでは、その影響は明らかに大きくなります。BGP の決定、突然のトポロジの変更、ピアリングの非対称性がこのばらつきを引き起こしています。私は、ルーティングポリシーが異なるため、一定数以上の追加ロケーションでは誤割り当ての可能性が高まることを観察しています。したがって、エニーキャストは、平均的には多くの場合良好な結果をもたらしますが、分位点では痛ましい結果をもたらす可能性があります。 アウトライアーズ 生成する。.

コンテキストが決め手：DNS、CDN、BGP の微調整

レイテンシーに敏感なコンテンツを扱うCDNは、BGPの微調整に投資し、プレフィックスとコミュニティを調整して、ホップ数が少なく、ピアリングが優れたパスを優先するようにしています。マイクロソフトは、賢明なアナウンスによってユーザーをパフォーマンスの高いエッジに近づける方法の例としてよく挙げられます。 操縦する. 。厳しいレイテンシー要件のない DNS サービスでは、この努力は必ずしも見合うとは限りません。その場合は、可用性と回復力が最後の 1 ミリ秒よりも重要になります。さらに、DNS 応答の有効期間は、知覚される速度に大きく影響します。最適なDNS TTL を選択することで、ユーザーは多くの往復通信を節約でき、レイテンシのピークを持続的に低減できます。多くの場合、追加のPOPを設置するよりも効果的です。 ネット.

測定方法：Anycast 設定の評価方法

私は単一の視点に頼るのではなく、クライアント視点、サーバー視点、および個々のアクティブプローブを組み合わせています。 ノード. Anycast Efficiency Factor (α) という指標は、選択した Anycast インスタンスへの実際のレイテンシと、ローカルで最適なノードへのレイテンシを比較するもので、1.0 が理想的です。さらに、RTT の分布もチェックします。これは、外れ値がユーザーエクスペリエンスに大きな影響を与えるためです。サーバー側の測定は、何百万ものクライアントに関する幅広い情報を提供しますが、クライアントプローブは、実際のラストマイルの状況を反映しています。両者を比較することで、ルーティングポリシーが適切に機能しているかどうか、あるいはポリシーが近さ打つ。.

指標	意味	良い（目安）	警報信号
エニーキャスト効率係数 (α)	実際のRTTと最良のRTTの比率	中央値 1.3 以下	多くの地域で 2.0 以上
最寄りのサイトへのRTT	到達可能時間の下限	< 20～30 ミリ秒（地域によって異なる）	> 60 ミリ秒、理由なし
最適ではないルートの割合	クライアントの誤った割り当て	< 10%	> 20% 頻繁
キャッシュ・ヒット率	キャッシュからの回答割合	> 90%（レゾルバー用）	< 70% 永久

実務でよくある落とし穴

定番のケース：BGPポリシーは、より近いパスが存在するにもかかわらず、より遠いASNにトラフィックを誘導します。これは、ローカルポリシーが決定的な発疹個々のノードに障害が発生すると、トラフィックが別の大陸に飛び移ることがあり、200～300 ミリ秒の追加遅延が発生する可能性があります。公開されたリゾルバー環境でのインシデントでは、アナウンス障害後に 300 ミリ秒以上の遅延が発生しました。また、ノードアフィニティも時折機能しなくなり、クライアントはノードの切り替えを目撃し、キャッシュは空になります。接続が弱い地域では、Anycast が有効であるにもかかわらず、POP の数が少ないことで配信の品質が低下します。そのため、私は、グローバルな 平均値 離れる。.

アーキテクチャの決定：ノード、プレフィックス、ピアリング

私は、一律の基準ではなく、予想されるユーザープロファイルに基づいてノードの数を計画しています。引用. 優れた接続性と良好なピアリングを備えた少数のPOPは、多くの場合、多くの脆弱なロケーションを明らかに上回ります。プレフィックスの長さ、コミュニティ、地域分割によって、ポリシーが真の近接性を選択するか、迂回を選択するかが決まります。厳しい要件のあるプロジェクトでは、現地でピアリングの機会を確認し、必要に応じて、より細かい制御のために小さなプレフィックスを設定します。物理的なロケーションは、レイテンシーとデータ保護にとって依然として重要であり、このガイドが参考になります。サーバーの場所とレイテンシークリアで ヒント.

実践ガイド：レイテンシーを改善するためのステップバイステップ

まず、現状を把握することから始めます。権威ネームサーバーはどの位置にあり、実際のユーザーから見てどの程度の RTT を提供しており、地域ごとに外れ値はどのように分布しているかを把握します。次に、頻繁に問い合わせのあるゾーンの TTL を最適化し、リゾルバーが再問い合わせを行う頻度を減らし、ピークを排除します。その後、BGP アナウンスを調整し、さまざまなコミュニティをテストし、ピアが実際にトラフィックをどのように処理しているかを分析します。顕著な地域については、効率指標 α が明らかに低下するまで、ピアリング、新しい POP、または代替パスなどのローカルな改善策を講じます。その後に初めて、別のロケーションが本当に有益であるかどうか、あるいは何よりも散乱生成される。.

測定マトリックスと評価の例

グローバルゾーンオペレーター向けに、各地域ごとに定期的に測定を行っています：中央値RTT、95パーセンタイル、αをローカルベストノードと比較し、大規模キャッシュヒット率を追加しています。 リゾルバ. 私は、個々のノードの内部 IP へのアクティブなプローブとこれらの数値を比較して、「物理的な」下限を確認します。α が高いにもかかわらず、シングルノードの RTT が良好である場合は、問題はほぼ確実にルーティングにあり、サーバーのパフォーマンスにあるわけではないと言えます。これにより、ピアリング、プレフィックス、ロケーションの選択を修正すべきかどうかを、的を絞って特定することができます。この測定マトリックスにより、盲目的な変更を防ぎ、実際の ボトルネック.

トランスポートプロトコルとハンドシェイク：UDP、TCP、DoT、DoH、DoQ

Anycast が「高速」に機能するかどうかは、トランスポートに大きく依存します。従来の DNS は UDP, 、ハンドシェイクが不要で、通常は最速です。ただし、応答サイズやパケット損失が問題となる場合は例外です。切り捨て（TCフラグ）によって応答が TCP 戻る場合、すぐに追加の往復が発生します。 DoT/DoH (DNS over TLS/HTTPS) には TLS ハンドシェイクが追加されます。実際には、DoH 接続は頻繁に再利用されるため、最初のリクエスト以降の追加コストは減少します。そのため、アクセスが集中するゾーンについては、次のように計画しています。

断片化を避けるため、EDNS0バッファは控えめなサイズ（例：1232～1400バイト）に設定してください。.
DoT/DoH/DoQ ポートをすべて同じように終端して、プロトコルが混在している場合でも、Anycast ノードが一貫した反応をするようにします。.
UDP の最適化だけでなく、TCP および TLS のチューニング（初期輻輳ウィンドウ、可能な場合は DoT/DoQ での 0-RTT）も積極的に確認してください。.

特にモバイルアクセスでは、UDP ではパケット損失がタイムアウトにつながることが多いため、堅牢な DoH/DoQ 実装が効果を発揮します。私は、プロトコルファミリーごとに個別にレイテンシを測定し、中央値だけでなく分布も比較して、実際のユーザーパスを反映しています。.

応答サイズ、DNSSEC、およびフラグメンテーション

大きな回答はレイテンシの要因となります。. ディナセック, 、SVCB/HTTPSレコード、多数のNSまたはTXTエントリは、一般的なMTU制限を超えてパケットを転送します。断片化されたUDPパケットはより頻繁に失われ、その後のTCPフォールバックには時間がかかります。私は、応答がコンパクトに保たれるようにゾーンを計画しています。

ショート RRSIG-チェーン（長いRSAキーの代わりにECDSA/ECDSAP256）による小さな署名。.
意味のある委任：権限/追加セクションに不要な追加エントリは記載しない。.
SVCB/HTTPS を意識的に使用し、切り捨てがどのくらいの頻度で発生するかテストしてください。.

EDNS0バッファの小型化とスリムな応答の組み合わせにより、再送信が減少して安定性が向上します。 通信事業者-分布。私の分析では、95パーセンタイルと99パーセンタイルは、ユーザーが遅延を感じるまさにその部分で、中央値よりも大きく縮小することがよくあります。.

安定性対速度：ヘルスチェックとフェイルオーバー

Anycast は、ヘルスチェックの設定が不適切な場合、ほとんど許容しません。過度に積極的な撤退ロジックは、 フラップ, 保守的なチェックは、誤ったノードをルーティングに長すぎる時間保持します。私は以下を重視しています。

ICMPだけでなく、複合的なヘルス信号（ローカルプローブ、外部チェック、サービスステータス）も確認します。.
BGP アナウンスにおけるヒステリシスと減衰により、短時間の障害がグローバルな切り替えを引き起こさないようにします。.
BFD による迅速な検出、しかしキャッシュアフィニティを維持するための制御されたネットワークへの復帰（グレイスフルリターン）。.

メンテナンス時には、ローカルプレフィックスを減らしてプレフィックスを通知し、トラフィックを流してから、ノードをネットワークから完全に切断します。これにより、ユーザーパスが安定し、キャッシュのコールドスタートが回避されます。.

一貫性、TTL 戦略、およびキャッシュの動作

速度は キャッシュ – 一貫性が、その安定性を決定します。更新については、TTL と変更頻度をバランスさせています。頻繁に要求され、変更がほとんどないレコードには、より高い TTL を設定します。動的なエントリには、適度な TTL とセカンダリへの事前通知 (NOTIFY) を使用します。さらに、以下の方法も有効です。

サーブステール：上流の障害が発生した場合、リゾルバーは一時的に古い応答を返してもかまいません。タイムアウトよりも良い方法です。.
プリフェッチ TTLの終了間際に、人気のあるエントリがキャッシュに最新の状態として残るようにします。.
意識的な ネガティブ・キャッシング (NXDOMAIN TTL) は、人気のあるが誤ったリクエストの負荷を軽減します。.

すべてのエニーキャストノードにアップデートがタイムリーに届くか（SOA によるシリアルモニタリング）を確認し、収束までの時間を比較します。データ分配が適切に行われていない状態でレイテンシーを最適化すると、応答に一貫性がなくなり、結果としてエラーが発生します。.

IPv6、デュアルスタック、非対称ルーティング

多くのネットワークでは、IPv4 と IPv6 の経路は明らかに異なります。私は測定します。 デュアルスタック 常に分離：α、中央値 RTT、および IP ファミリーごとの外れ値。v6 の接続が劣ったり、他のポリシーに従ったりすることも珍しくありません。私は、同一の告知、調整されたコミュニティ、およびターゲットを絞った v6 ピアリングによってこの問題を解決しています。クライアント側では Happy Eyeballs が機能するため、優れた v6 パフォーマンスは「あれば良いもの」ではなく、ユーザーエクスペリエンスに直接影響を与えます。.

測定誤差を避ける：私がしないこと

ICMP ping を Anycast IP で測定すると、現実とはかけ離れた結果になることがよくあります。ファイアウォール、レート制限、DNS から切り離された ICMP ポリシーが結果を歪めるからです。クラウドモニタリングでは、大陸全体を隠してしまう単一ロケーションも同様に問題があります。したがって、私は次のように評価します。

実際のクエリ（A/AAAA、NXDOMAIN、DNSSEC 検証済み）による UDP/53、TCP/53、および DoH/DoT の RTT。.
データセンターだけでなく、ISPおよびモバイルネットワークのクライアントに近いプローブ。.
数週間にわたる長期の分析により、時間帯や曜日による影響を確認。.

合成サンプルとサーバー側のログを比較して初めて、問題がローカル、地域、グローバルのいずれであるか、また、ルーティングとアプリケーションのどちらで時間が失われているかが明らかになります。.

BGP の微調整の実践

微調整は、多くの場合 10～50 ミリ秒で決まります。私は地域ごとに作業を行っています。 コミュニティ ローカルプリファレンスについては、必要に応じて選択的なデアグリゲート（クリーンな ROA 内で）を設定し、大規模なキャリアでドロップされるプレフィックス長を避けてください。重要：IPv4/IPv6 を一貫してアナウンスし、すべてのトランジットでポリシーの効果を検証してください。個々の地域で α の値が高いままの場合は、プレフィックスを一時的に分割し、再度測定して、分割を維持すべきか、より優れたピアリングの方がより持続可能な解決策であるかをデータに基づいて判断します。.

オペレーションプレイブック：繰り返し可能な手順

最適化が単発プロジェクトに終わらないよう、私は簡潔なプレイブックを用意しています。

地域およびIPファミリーごとの月次αレビュー、具体的なISPを含む異常値リスト。.
四半期ごとに カオスドリル （ノード撤退、リンクダウン）ドリル前後のメトリック比較付き。.
ゾーン変更のリリースチェックリスト：応答サイズ、DNSSEC の影響、フラグメント化のリスク、TTL の影響。.
ピアリング監査：コスト/便益、容量、パケット損失、ジッター、明確な限界値およびエスカレーション手順。.
ヒステリシスと文書化されたしきい値を備えた、透明性の高いヘルスチェックポリシー。.

これらのルーチンにより、レイテンシー、安定性、一貫性のバランスが保たれ、Anycast はその能力を発揮します。つまり、堅牢なアクセス性と、自動的には完璧ではないものの、良好なパフォーマンスを実現します。 パフォーマンス.

要約：運営者にアドバイスすること

Anycast DNS は安定した可用性と概ね良好な応答時間を実現しますが、クリーンな チューニング. 効率をαで測定し、中央値と外れ値を検証し、個々のノードに対して積極的にテストを行ってください。キャッシュを優先してください。適切なTTLは、追加のPOPよりもラウンドトリップを大幅に削減できる場合が多いです。新しいノードについては、データに基づいて判断し、BGPポリシーを検証してから、さらに展開を進めてください。そうすることで、回避可能な 誤ったルート 走る。.