エニーキャストとユニキャスト: それぞれのケースでどちらを選択する方が良いか

Anycast について聞いたことがある人は多いでしょう。 このネットワーク アドレス指定およびルーティング方法では、単一の IP アドレスがネットワーク上の複数のサーバーに割り当てられます。 これらのサーバーは、互いに離れたデータセンターに配置することもできます。 エニーキャストの考え方は、リクエストの送信元の場所に応じて、データが最も近い (ネットワーク トポロジ、より正確には BGP ルーティング プロトコルに従って) サーバーに送信されるというものです。 こうすることで、ネットワーク ホップの数と遅延を減らすことができます。

基本的に、同じルートが世界中の複数のデータセンターからアドバタイズされます。 したがって、クライアントは、BGP ルートに基づいて「最適」かつ「最も近い」データセンターに送信されます。 なぜエニーキャストなのか？ ユニキャストではなくエニーキャストを使用するのはなぜですか?

ユニキャストは、Web サーバーが XNUMX つあり、トラフィック量が中程度のサイトに非常に適しています。 ただし、サービスに何百万もの加入者がいる場合は、通常、それぞれが同じ IP アドレスを持つ多数の Web サーバーを使用します。 これらのサーバーは地理的に分散されており、リクエストに最適に対応します。

このシナリオでは、エニーキャストはパフォーマンスを向上させ (トラフィックは最小限の遅延でユーザーに送信されます)、サービスの信頼性を確保し (バックアップ サーバーのおかげで)、負荷分散を実現します。複数のサーバーへのルーティングによりサーバー間の負荷が効果的に分散され、速度が向上します。サイトの。

オペレータは、エニーキャストと DNS に基づいたさまざまなタイプの負荷分散をクライアントに提供します。 クライアントは、サイトの地理的位置に基づいてリクエストの送信先となる IP アドレスを指定できます。 これにより、ユーザーのリクエストをより柔軟に振り分けることが可能になります。

たとえば、100 日に 000 件のリクエストがあるオンライン ストアや人気のブログなど、負荷 (ユーザー) を分散する必要があるサイトが複数あるとします。 ユーザーが特定のサイトにアクセスする地域を制限するには、Geo Community オプションを使用できます。 これにより、オペレーターがルートを宣伝する地域を制限できます。

エニーキャストとユニキャスト: 違い

エニーキャストは、DNS (ドメイン ネーム システム) や CDN (コンテンツ配信ネットワーク) などのアプリケーションでよく使用され、ネットワーク パフォーマンスを向上させるルーティングの決定を可能にします。 コンテンツ配信ネットワークは大量のトラフィックを処理するため、Anycast を使用します。この場合、Anycast には多くの利点があります (詳細は後述します)。 DNS では、エニーキャストを使用すると、サービスの信頼性とフォールト トレランスのレベルを大幅に向上させることができます。

エニーキャスト IP では、BGP を使用する場合、特定のホストへのルートが複数存在します。 これらは実際には、複数のデータセンターにあるホストのコピーであり、低遅延の接続を確立するために使用されます。

そのため、エニーキャスト ネットワークでは、同じ IP アドレスがさまざまな場所からアドバタイズされ、ネットワークはルートの「コスト」に基づいてユーザーのリクエストをどこにルーティングするかを決定します。 たとえば、BGP は、データ送信の最短ルートを決定するためによく使用されます。 ユーザーがエニーキャスト リクエストを送信すると、BGP はネットワーク上で利用可能なエニーキャスト サーバーの最適なルートを決定します。

エニーキャストの利点

レイテンシの短縮
エニーキャストを使用したシステムでは、最も近いサーバーからデータを受信できるため、ユーザー要求を処理する際の待ち時間を短縮できます。 つまり、ユーザーは常に (ルーティング プロトコルの観点から) 「最も近い」 DNS サーバーに接続します。 その結果、エニーキャストはクライアントとサーバー間のネットワーク距離を短縮することで対話時間を短縮します。 これにより、待ち時間が短縮されるだけでなく、負荷分散も実現されます。

スピード

トラフィックは最も近いノードにルーティングされ、クライアントとノード間の待ち時間が短縮されるため、クライアントがどこから情報を要求しているかに関係なく、配信速度が最適化されます。

安定性と耐障害性の向上

世界中の複数のサーバーが同じ IP を使用している場合、サーバーの XNUMX つで障害が発生したり切断されたりすると、トラフィックは最も近いサーバーにリダイレクトされます。 その結果、エニーキャストはサービスの回復力を高め、ネットワーク アクセス、遅延、速度を向上させます。 

したがって、ユーザーが複数のサーバーを常に利用できるようにすることで、たとえばエニーキャストは DNS の安定性を向上させます。 ノードに障害が発生した場合、ユーザーのリクエストは手動による介入や再構成を行わずに別の DNS サーバーにリダイレクトされます。 エニーキャストは、問題のあるサイトのルートを削除するだけで、他のサイトへの実質的に透過的なスイッチングを実現します。 

ロードバランシング

エニーキャストでは、ネットワーク トラフィックはさまざまなサーバーに分散されます。 つまり、ロード バランサーとして機能し、単一のサーバーが大量のトラフィックを受信するのを防ぎます。 負荷分散は、たとえば、リクエスト ソースから同じ地理的距離に複数のネットワーク ノードが存在する場合に使用できます。 この場合、負荷はノード間で分散されます。

DoS 攻撃の影響を軽減する 

エニーキャストのもう XNUMX つの特徴は、DDoS 耐性です。 DDoS 攻撃では、雪崩のようにネットワーク内のすべてのサーバーをリクエストで圧倒する必要があるため、エニーキャスト システムをダウンさせることはできそうにありません。 

DDoS 攻撃ではボットネットが使用されることが多く、攻撃対象のサーバーに過負荷を与えるほどの大量のトラフィックが生成される可能性があります。 この状況でエニーキャストを使用する利点は、各サーバーが攻撃の一部を「吸収」できるため、その特定のサーバーの負荷が軽減されることです。 サービス拒否攻撃はサーバーに限定される可能性が高く、サービス全体には影響しません。

高い水平スケーラビリティ

エニーキャスト システムは、大量のトラフィックを伴うサービスに適しています。 エニーキャストを使用するサービスで増加したトラフィックを処理するために新しいサーバーが必要な場合は、それを処理するために新しいサーバーをネットワークに追加できます。 新規または既存のサイトに配置できます。 

特定の場所でトラフィックが大幅に増加している場合、サーバーを追加すると、そのサイトの負荷のバランスが取れます。 新しいサイトにサーバーを追加すると、一部のユーザーに対して新しい最短ルートが作成され、待ち時間が短縮されます。 どちらの方法も、ネットワーク上で新しいサーバーが利用可能になるため、サービスの安定性を向上させるのに役立ちます。 こうすることで、サーバーが過負荷になった場合に、過負荷になったサーバーのリクエストの一部を受け入れられる場所に別のサーバーをデプロイするだけで済みます。 これには、クライアント側での構成は必要ありません。 

サーバーに 10 Gbps または 25 Gbps のポートが数個しかない場合でも、この方法のみでテラビットのトラフィックと非常に多くのユーザーにサービスを提供できます。 100 つの IP アドレスを持つ XNUMX 台のホストにより、テラビット規模のトラフィックを処理できるようになります。

簡単な構成管理

上で述べたように、エニーキャストの興味深い用途は DNS です。 ネットワーク ノード上に複数の異なる DNS サーバーを配置できますが、使用する DNS アドレスは XNUMX つだけです。 ソースの場所に応じて、リクエストは最も近いノードにルーティングされます。 これにより、DNS サーバーに障害が発生した場合に、ある程度のトラフィックのバランスと冗長性が提供されます。 このようにすると、場所に応じて異なる DNS サーバーを構成する代わりに、XNUMX つの DNS サーバーの構成をすべてのノードに伝播することができます。

エニーキャスト ネットワークは、距離だけでなく、サーバーの存在、確立された接続の数などのパラメータにも基づいてリクエストをルーティングするように構成できます。 または応答時間。

エニーキャスト テクノロジを使用するために、クライアント側に特別なサーバー、ネットワーク、または特別なコンポーネントは必要ありません。 しかし、エニーキャストには欠点もあります。 その実装は複雑な作業であり、追加の機器、信頼できるプロバイダー、適切なトラフィック ルーティングが必要になると考えられています。

純粋な源から美しさまでは程遠い

エニーキャストは最小ホップに基づいてユーザーをルーティングしますが、これは必ずしも遅延が最小であることを意味するわけではありません。 レイテンシは、XNUMX 回の遷移よりも XNUMX 回の遷移の方が高くなる可能性があるため、より複雑な指標になります。

例: 大陸間の通信には、遅延が非常に長い単一ホップが含まれる場合があります。

エニーキャストは主に、DNS などの UDP ベースのサービスに使用されます。 ユーザーリクエストは、BGP ルートに基づいて「最適な」および「最も近い」データセンターにルーティングされます。

例: エニーキャスト DNS IP アドレス 123.10.10.10 を持つ DNS クライアント ワークステーションは、同じエニーキャスト IP アドレスを使用して展開された 1 つの DNS ネーム サーバーのうち最も近いものに対して DNS 解決を実行します。 ルーター R2 またはサーバー A に障害が発生した場合、DNS クライアント パケットはルーター R3 および RXNUMX を介して次に近い DNS サーバーに自動的に転送されます。 さらに、サーバー A へのルートがルーティング テーブルから削除され、そのネームサーバーは今後使用できなくなります。

導入シナリオ

ユーザーが接続するサーバーを決定するために使用される一般的なスキームが XNUMX つあります。

• エニーキャストネットワーク層。 ユーザーを最も近いサーバーに接続します。 ここでは、ユーザーからサーバーまでのネットワーク パスが重要です。
• アプリケーションレベルのエニーキャスト。 このスキームには、サーバーの可用性、応答時間、接続数などを含む、より計算されたメトリックが含まれます。これは、ネットワーク統計を提供する外部モニターに依存します。

エニーキャストに基づく CDN

ここで、コンテンツ配信ネットワークでの Anycast の使用に戻りましょう。 エニーキャストは確かに興味深いネットワーキング概念であり、次世代 CDN プロバイダーの間で受け入れられつつあります。

CDN は、高可用性と低遅延でエンド ユーザーにコンテンツを配信するサーバーの分散ネットワークです。 コンテンツ配信ネットワークは現在、多くのオンライン メディア サービスのバックボーンとして重要な役割を果たしていますが、消費者はダウンロード速度の遅さに対してますます寛容ではなくなっています。 ビデオおよび音声アプリケーションは、ネットワークのジッターと遅延の影響を特に受けやすくなります。

CDN はすべてのサーバーを 5 つのネットワークに接続し、コンテンツの読み込みを高速化します。 場合によっては、ユーザーの待ち時間を 6 ～ XNUMX 秒短縮できる場合があります。 CDN の目的は、エンド ユーザーに最も近いサーバーからコンテンツを提供することで配信を最適化することです。 これはエニーキャストと非常に似ており、エンド ユーザーの位置に基づいて最も近いサーバーが選択されます。 すべての CDN サービス プロバイダーがデフォルトでエニーキャストを使用しているように見えますが、実際にはそうではありません。

HTTP/TCP などのプロトコルを使用するアプリケーションは、確立される接続に依存します。 新しいエニーキャスト ノードが選択された場合 (サーバー障害などにより)、サービスが中断される可能性があります。 これが、以前は UDP や DNS などのコネクションレス型サービスにエニーキャストが推奨されていた理由です。 ただし、エニーキャストは接続指向のプロトコルでも適切に機能します。たとえば、TCP はエニーキャスト モードで適切に機能します。

CDN プロバイダーの中には、エニーキャスト ベースのルーティングを使用するプロバイダーもあれば、DNS ベースのルーティングを好むプロバイダーもあります。ユーザーの DNS サーバーの場所に基づいて最も近いサーバーが選択されます。

ハイブリッドおよびマルチデータセンターのインフラストラクチャは、エニーキャストの使用例のもう XNUMX つです。 プロバイダーから受け取った負荷分散 IP アドレスを使用すると、プロバイダーのデータ センター内のさまざまなクライアント サービスの IP アドレス間で負荷を分散できます。 エニーデバイス テクノロジーのおかげで、トラフィックが多い場合でもパフォーマンスが向上し、耐障害性が向上し、多数のユーザーを処理する場合の応答時間の最適化に役立ちます。

ハイブリッド マルチデータ センター インフラストラクチャでは、トラフィックをサーバー全体に分散したり、専用サーバー上の仮想マシンにさえ分散したりできます。

したがって、インフラストラクチャを構築するための技術ソリューションには膨大な選択肢があります。 また、複数のデータセンターにわたる IP アドレス間で負荷分散を構成し、グループ内の任意のデバイスをターゲットにしてサイトのパフォーマンスを最適化することもできます。

各データセンター内の分散サーバーそれぞれの「重み」を定義する独自のルールに従ってトラフィックを分散できます。 この構成は、分散サーバー パークがあり、サービスのパフォーマンスが不均一な場合に特に役立ちます。 これにより、トラフィックがより頻繁に分散され、サーバーのパフォーマンスが向上します。

ping コマンドを使用して監視システムを作成するには、プローブを構成できます。 これにより、管理者は独自の監視手順を定義し、インフラストラクチャ内の各コンポーネントのステータスをより明確に把握できるようになります。 このようにして、アクセシビリティ基準を定義できます。

ハイブリッド インフラストラクチャを構築することも可能です。場合によっては、バック オフィスを企業ネットワーク内に残し、インターフェイス部分をプロバイダーにアウトソーシングする方が便利な場合があります。

負荷分散、送信データの暗号化、サイト訪問者と企業インフラストラクチャ間の通信のセキュリティのために SSL 証明書を追加することができます。 データセンター間の負荷分散の場合は、SSL も使用できます。

アドレス負荷分散を備えたエニーキャスト サービスは、プロバイダーから入手できます。 この機能は、ユーザーが位置情報に基づいてアプリを操作する方法を改善するのに役立ちます。 データセンターでどのようなサービスが利用できるかを通知するだけで十分であり、トラフィックは最も近いインフラストラクチャにリダイレクトされます。 フランスや北米などに専用サーバーがある場合、クライアントはネットワーク上の最も近いサーバーに誘導されます。

エニーキャストを使用するためのオプションの XNUMX つは、オペレータの Point of Presence (PoP) の最適な選択です。 あげましょう 例。 LinkedIn (ロシアではブロックされている) は、自社製品 (モバイル アプリケーションや Web アプリケーション) のパフォーマンスと速度の向上だけでなく、コンテンツ配信を高速化するためのネットワーク インフラストラクチャの改善にも努めています。 この動的なコンテンツ配信のために、LinkedIn は PoP (Point of Presence) を積極的に使用します。 エニーキャストは、ユーザーを最も近い PoP に誘導するために使用されます。

その理由は、ユニキャストの場合、各 LinkedIn PoP が固有の IP アドレスを持っているためです。 ユーザーは、DNS を使用して地理的位置に基づいて PoP に割り当てられます。 問題は、DNS を使用すると、米国のユーザーの約 30% が次善の PoP にリダイレクトされたことです。 エニーキャストの段階的な実装により、最適ではない PoP 割り当ては 31% から 10% に低下しました。

パイロット テストの結果がグラフに示されています。Y 軸は最適な PoP 割り当ての割合です。 エニーキャストの増加に伴い、米国の多くの州で最適な PoP へのトラフィックの割合が改善されました。

エニーキャストネットワーク監視

エニーキャスト ネットワークは理論的には単純です。複数の物理サーバーに同じ IP アドレスが割り当てられ、BGP はその IP アドレスを使用してルートを決定します。 しかし、エニーキャスト プラットフォームの実装と設計は複雑であり、この点ではフォールト トレラントなエニーキャスト ネットワークが特に有名です。 さらに難しいのは、エニーキャスト ネットワークを効果的に監視して、障害を迅速に特定して隔離することです。

サービスがサードパーティの CDN プロバイダーを使用してコンテンツを提供する場合、ネットワーク パフォーマンスを監視および検証することが非常に重要です。 エニーキャストベースの CDN モニタリングは、どのデータセンターがコンテンツを提供しているかを理解するために、エンドツーエンドの遅延と最後から XNUMX 番目のホップのパフォーマンスを測定することに重点を置いています。 HTTP サーバーのヘッダーを分析することは、データの送信元を判断するもう XNUMX つの方法です。

例: CDN サーバーの場所を示す HTTP 応答ヘッダー。

たとえば、CloudFlare は HTTP 応答メッセージで独自の CF-Ray ヘッダーを使用します。これには、リクエストが行われたデータセンターの指示が含まれます。 Zendesk の場合、シアトル地域の CF-Ray ヘッダーは CF-RAY: 2a21675e65fd2a3d-SEA、アムステルダムの場合は CF-RAY: 2a216896b93a0c71-AMS です。 HTTP 応答の HTTP-X ヘッダーを使用して、コンテンツの場所を特定することもできます。

他のアドレス指定方法

ユーザー要求を特定のネットワーク エンドポイントにルーティングするための他のアドレス指定方法もあります。

ユニキャスト

現在のインターネットのほとんどはこの方法を使用しています。 ユニキャスト - ユニキャスト送信では、IP アドレスはネットワーク上の XNUMX つの特定のノードのみに関連付けられます。 これを XNUMX 対 XNUMX マッチングと呼びます。 

マルチキャスト

マルチキャストでは、XNUMX 対多または多対多の関係が使用されます。 マルチキャストを使用すると、送信者からのリクエストを、選択された異なるエンドポイントに同時に送信できます。 これにより、クライアントは複数のホストから同時にファイルをチャンクでダウンロードできるようになります (これは、オーディオまたはビデオのストリーミングに役立ちます)。 マルチキャストはエニーキャストとよく混同されますが、主な違いは、複数のノードが利用可能な場合でも、エニーキャストは送信者を XNUMX つの特定のノードに誘導することです。

放送

単一の送信者からのデータグラムは、ブロードキャスト アドレスに関連付けられたすべてのエンドポイントに転送されます。 ネットワークは、ブロードキャスト内のすべての受信者 (通常は同じサブネット上) に到達できるように、データグラムを自動的に複製します。

ジオキャスト

ジオキャストはマルチキャストに似ています。送信者からのリクエストは複数のエンドポイントに同時に送信されます。 ただし、宛先が地理的位置によって決まるという点が異なります。 これは、モバイル アドホック ネットワークの一部のルーティング プロトコルで使用される特殊な形式のマルチキャストです。

地理ルーターはサービスエリアを計算して近似します。 ジオルーターはサービスエリアを交換し、ルーティングテーブルを構築します。 ジオルーター システムは階層構造を持っています。

ユニキャスト、マルチキャスト、ブロードキャスト。

エニーキャスト テクノロジーを使用すると、DNS の信頼性、耐障害性、セキュリティのレベルが向上します。 このテクノロジーを使用して、通信事業者は、DNS に基づいたさまざまなタイプの負荷分散サービスをクライアントに提供します。 コントロール パネルでは、地理的位置に応じてリクエストの送信先となる IP アドレスを指定できます。 これにより、クライアントはユーザーのリクエストをより柔軟に分散する機会が得られます。

一部の通信事業者は、各 Point of Presence (POP) にルート監視機能を実装しています。システムは、Point of Presence の最短のローカルおよびグローバル ルートを自動的に分析し、ダウンタイムなしで遅延が最も短い地理的場所を経由してルートをルーティングします。

現時点では、エニーキャストは、安定性と信頼性に対する高い要件が求められる高負荷の DNS サービスを構築するための最も安定性と信頼性の高いソリューションです。

.ru ドメインは、35 つの Anycast クラウドに分散された 20 ノードにグループ化された XNUMX の Anycast DNS サーバーをサポートします。 この場合、地理的特性に基づいた構築の原則が使用されます。 ジオキャスト。 DNS ノードを配置する場合、最もアクティブなユーザーに近い地理的に分散した場所、ノードが配置される場所でのロシアのプロバイダーの最大集中、および空き容量の利用可能性と容易な DNS ノードに移動することが想定されています。サイトとのやり取り。

CDN を構築するにはどうすればよいですか?

CDN は、ユーザーへのコンテンツの配信を高速化するサーバーのネットワークです。 コンテンツ配信ネットワーク すべてのサーバーを XNUMX つのネットワークに統合し、コンテンツの読み込みを高速化します。 サーバーからユーザーまでの距離は、読み込み速度に重要な役割を果たします。

CDN を使用すると、対象ユーザーに最も近いサーバーを使用できます。 これにより、待ち時間が短縮され、すべての訪問者に対するサイト コンテンツの読み込み速度が向上します。これは、大きなファイルやマルチメディア サービスを含むサイトでは特に重要です。 CDN の典型的なアプリケーションは、電子商取引とエンターテイメントです。

CDN インフラストラクチャ内に作成された追加サーバーのネットワークは、ユーザーにできるだけ近い場所に配置され、より安定した高速なデータ配信に貢献します。 統計によると、CDN を使用すると、CDN を使用しないサイトと比較して、サイトにアクセスするときの遅延が 70% 以上短縮されます。

Как DNSを使用してCDNを作成する? Anycast 独自のソリューションを使用して CDN をセットアップするのは非常に高価なプロジェクトになる可能性がありますが、より安価なオプションもあります。 たとえば、GeoDNS と一意の IP アドレスを持つ通常のサーバーを使用できます。 GeoDNS サービスを使用すると、地理位置情報機能を備えた CDN を作成できます。この CDN では、DNS リゾルバーの場所ではなく、訪問者の実際の場所に基づいて決定が行われます。 米国の訪問者には米国のサーバー IP アドレスを表示するように DNS ゾーンを構成できますが、ヨーロッパの訪問者にはヨーロッパの IP アドレスが表示されます。

GeoDNS を使用すると、ユーザーの IP アドレスに応じて異なる DNS 応答を返すことができます。 これを行うために、DNS サーバーは、要求内の送信元 IP アドレスに応じて異なる IP アドレスを返すように構成されています。 通常、GeoIP データベースは、リクエストの送信元の地域を決定するために使用されます。 DNS を使用した地理位置情報により、近くのサイトからユーザーにコンテンツを送信できます。

GeoDNS は、DNS 要求を送信したクライアントの IP アドレス、またはクライアント要求の処理時に使用されるプロバイダーの再帰 DNS サーバーの IP アドレスを決定します。 国/地域は、クライアントの IP および GeoIP データベースによって決定されます。 次に、クライアントは最も近い CDN サーバーの IP アドレスを取得します。 GeoDNS の設定について詳しくは、こちらをご覧ください。 ここで.

エニーキャストかGeoDNSか?

エニーキャストはコンテンツを世界規模で配信する優れた方法ですが、具体性に欠けます。 ここで、GeoDNS が役に立ちます。 このサービスを使用すると、ユーザーを場所に基づいて一意のエンドポイントに送信するルールを作成できます。

例: ヨーロッパのユーザーは別のエンドポイントに誘導されます。

すべてのリクエストを破棄して、ドメインへのアクセスを拒否することもできます。 これは特に、侵入者を素早く遮断する方法です。

GeoDNS はエニーキャストよりも正確な回答を提供します。 エニーキャストの場合、最短ルートがホップ数によって決定される場合、GeoDNS では、エンド ユーザーの物理的な位置に応じてエンド ユーザーのルーティングが発生します。 これにより、遅延が短縮され、詳細なルーティング ルールを作成する際の精度が向上します。

ドメインに移動すると、ブラウザは最も近い DNS サーバーに接続し、ドメインに応じて、サイトをロードするための IP アドレスを発行します。 オンライン ストアは米国とヨーロッパで人気がありますが、そのオンライン ストアの DNS サーバーはヨーロッパでのみ利用できると仮定します。 その場合、ストアのサービスを利用したい米国のユーザーは、最寄りのサーバーにリクエストを送信する必要がありますが、サーバーが非常に遠いため、応答まで長い時間待たなければならず、サイトはすぐに読み込まれません。

GeoDNS サーバーが米国にある場合、ユーザーはすでにそのサーバーにアクセスしています。 応答が早くなり、サイトの読み込み速度に影響します。

米国に既存の DNS サーバーがある状況では、米国のユーザーが特定のドメインに移動すると、必要な IP を提供する最も近いサーバーに接続します。 ユーザーはサイトのコンテンツを含むサーバーにリダイレクトされますが、コンテンツのあるサーバーは離れているため、すぐにはコンテンツを受信できません。

キャッシュされたデータを使用して米国で CDN サーバーをホストしている場合、クライアント ブラウザーはロード時に最も近い DNS サーバーにリクエストを送信し、必要な IP アドレスが返送されます。 受信した IP を持つブラウザは、最寄りの CDN サーバーとメイン サーバーに接続し、CDN サーバーはキャッシュされたコンテンツをブラウザに提供します。 キャッシュされたコンテンツのロード中に、サイト全体をロードするために不足しているファイルがメイン サーバーから受信されます。 その結果、メイン サーバーから送信されるファイルが大幅に減り、サイトの読み込み時間が短縮されます。

特定の IP アドレスの正確な場所を特定することは、必ずしも簡単な作業ではありません。多くの要因が関係しており、さまざまな IP アドレスの所有者が、その IP アドレスを地球の反対側にアドバタイズすることを決定する場合があります (その場合は、正しい場所を取得するには、データベースが更新されるまで待ちます)。 VPS プロバイダーは、米国にあると思われるアドレスをシンガポールの VPS に割り当てることがあります。

エニーキャスト アドレスを使用する場合とは異なり、配布はキャッシュ サーバーへの接続中ではなく、名前解決中に行われます。 再帰サーバーが EDNS クライアント サブネットをサポートしていない場合は、キャッシュ サーバーに接続するユーザーではなく、その再帰サーバーの場所が使用されます。

DNS のクライアント サブネットは、再帰 DNS サーバーがクライアント情報、特に GeoDNS サーバーがクライアントの位置をより正確に判断するために使用できるネットワーク情報を DNS サーバーに送信する方法を定義する DNS (RFC7871) の拡張機能です。

ほとんどの場合、ISP の DNS サーバー、または地理的に近い DNS サーバーを使用しますが、米国内の誰かが何らかの理由でオーストラリアにある DNS リゾルバーを使用することにした場合、オーストラリアに最も近い IP サーバー アドレスを使用することになる可能性があります。

GeoDNS を使用する場合は、場合によってはキャッシュ サーバーとクライアント間の距離が長くなる可能性があるため、これらの機能を認識しておくことが重要です。

概要: 複数の VPS を XNUMX つの CDN に結合する場合、最良の展開オプションは、GeoDNS + Anycast 機能を備えた DNS サーバー バンドルをそのまま使用することです。

出所： habr.com