パフォーマンス上のメリット

はじめに: DNS レイテンシの原因と緩和策

ウェブページの複雑化に伴い、多くのドメインのリソースを参照するようになると、DNS ルックアップがブラウジングのボトルネックになる可能性があります。クライアントがネットワーク上で DNS リゾルバにクエリを行う必要がある場合、リゾルバがクエリする必要があるネームサーバーの近接性と数によっては、レイテンシが大きくなります（2 を超えることはまれですが、発生する可能性があります）。次のスクリーンショットは、ページ スピード ウェブ パフォーマンス測定ツールによって報告されるタイミングを示しています。各バーは、ページから参照されるリソースを表します。黒いセグメントは DNS ルックアップを示します。このページでは、最初の 11 秒間にページの読み込みが 13 回行われます。ルックアップのいくつかは並行して行われていますが、スクリーンショットでは 11 秒の合計ページの読み込み時間のうち数秒を占め、5 つのシリアル ルックアップ時間が必要であることが示されています。

DNS レイテンシには、次の 2 つのコンポーネントがあります。

  • クライアント（ユーザー）と DNS 解決サーバーとの間のレイテンシ。ほとんどの場合、これはネットワーク システムの通常のラウンドトリップ時間（RTT）制約によるものです。クライアントとサーバーマシンの間の地理的距離、ネットワークの輻輳、パケットロスと長い再送信の遅延（平均 1 秒）、サーバー過負荷、サービス拒否攻撃などです。
  • 解決サーバーと他のネームサーバーの間のレイテンシ。 このレイテンシの原因は、主に次の要因によって発生します。
    • キャッシュミス。リゾルバのキャッシュからレスポンスを配信することができないものの、他のネームサーバーに再帰的にクエリを実行する必要がある場合は、特に信頼できるサーバーが地理的に離れた場合に、ネットワークのレイテンシが増加する可能性があります。
    • アンダープロビジョニング。DNS リゾルバが過負荷になると、DNS の解決リクエストとレスポンスをキューに入れる必要があり、パケットのドロップと再送信が開始されることがあります。
    • 悪意のあるトラフィック。 DNS サービスがオーバープロビジョニングされていても、DoS トラフィックによりサーバーに過度の負荷がかかる可能性があります。 同様に、Kaminsky スタイルの攻撃では、キャッシュをバイパスすることが保証され、解決のために送信リクエストが必要となるクエリを使用して、フラッディング リゾルバが関与する場合があります。

キャッシュミス ファクタは DNS レイテンシの最も大きな原因であると考えています。詳細については、以降で説明します。

キャッシュミス

リゾルバに大量のローカル リソースがある場合でも、リモート ネームサーバーとの通信にともなう基本的な遅延を防ぐのは困難です。つまり、リゾルバが十分にプロビジョニングされ、キャッシュ ヒットがサーバー側でゼロ時間になる場合、キャッシュミスはレイテンシに関して非常に高コストのままになります。ミスを処理するために、リゾルバは少なくとも 1 つ（通常は 2 つ以上の外部ネームサーバー）と通信する必要があります。Googlebot ウェブクローラを動作させると、応答するネームサーバーの平均解決時間が 130 ミリ秒になることがわかりました。ただし、リクエストの 4 ～ 6% がタイムアウトします。これは、UDP パケットロスとサーバーにアクセスできないためです。パケットロス、デッド ネームサーバー、DNS 構成エラーなどの障害を考慮すると、実際の実際の平均解決時間は 300 ～ 400 ミリ秒ですが、ばらつきがあり、ロングテールです。

キャッシュミスの割合は DNS サーバーによって異なりますが、以下の理由から、キャッシュミスを回避することは根本的に困難です。

  • インターネットのサイズと増加 簡単に言うと、インターネットが成長するにつれ、新しいユーザーの追加や新しいサイトの追加によって、ほとんどのコンテンツには少々の関心が寄せられるようになりました。少数のサイト（結果として DNS 名）は非常に人気がありますが、ほとんどは少数のユーザーしか関心がなく、アクセスされることはほとんどありません。このため、大部分のリクエストではキャッシュミスが発生します。
  • 短い有効期間（TTL）値。 DNS TTL 値が小さい傾向にあるほど、解決でより頻繁にルックアップが必要になります。
  • キャッシュの分離。通常、DNS サーバーはロードバランサの背後にデプロイされ、異なるマシンにランダムにクエリを割り当てます。これにより、共有プールからキャッシュに保存された解像度を再利用せずに、個別のサーバーごとに個別のキャッシュが維持されます。

リスクの軽減

Google Public DNS では、DNS ルックアップ時間を短縮するためのいくつかの方法を実装しています。これらのアプローチの中には、かなり標準的なものや、試験運用版のものがあります。

  • サーバーを適切にプロビジョニングして、悪意のあるトラフィックなどのクライアント トラフィックからの負荷を処理する。
  • DoS 攻撃や増幅攻撃の防止。 これはほとんどセキュリティ問題であり、オープンなリゾルバよりもリゾルバが閉じているリゾルバに影響しますが、DoS 攻撃を防ぐことは、DNS サーバーにかかる余分なトラフィック負担をなくすことで、パフォーマンス上のメリットも得られます。 攻撃の可能性を最小限に抑えるために使用する方法については、セキュリティ上のメリットに関するページをご覧ください。
  • 共有キャッシュの負荷分散。サービスを提供するクラスタ全体で集計されたキャッシュ ヒット率を向上させるため。
  • 世界中のユーザーにサービスを提供

サービス クラスタの適切なプロビジョニング

DNS リゾルバをキャッシュに保存すると、権威ネームサーバーよりもコストのかかるオペレーションを実行する必要があります。これは、多数のレスポンスをメモリから配信できないためです。代わりに、他のネームサーバーとの通信が必要になり、大量のネットワーク入出力が必要になります。さらに、オープン リゾルバは、キャッシュ ポイズニングの試行に対して非常に脆弱です。キャッシュ ポイズニングの試みでは、キャッシュミス率（キャッシュから解決できない偽の名前に関するリクエストが送信されるなど）や、トラフィック負荷が増大する DoS 攻撃に対して攻撃が発生します。リゾルバが適切にプロビジョニングされておらず、負荷に対応できないと、パフォーマンスに非常に大きな悪影響を及ぼす可能性があります。パケットが破棄され、再送信される必要があり、ネームサーバー リクエストはキューに入れられる必要があります。これらすべての要因によって遅れが生じています。

したがって、DNS リゾルバを大容量の入力/出力用にプロビジョニングすることは重要です。これには、発生する可能性のある DDoS 攻撃への対処も含まれます。この場合、多くのマシンで過剰なプロビジョニングを行うことが唯一の有効な解決策となります。ただし、マシンを追加する際にキャッシュ ヒット率を低減しないことも重要です。これには、後述する効果的な負荷分散ポリシーの実装が必要です。

共有キャッシュの負荷分散

マシンを追加してリゾルバ インフラストラクチャをスケーリングすると、負荷分散が適切に行われていない場合、実際にはバックファイアが発生して、キャッシュ ヒット率が減少します。一般的なデプロイでは、複数のマシンがロードバランサの背後にあり、ラウンドロビンなどの単純なアルゴリズムを使用して各マシンにトラフィックを均等に分散します。その結果、各マシンはそれぞれ独自のキャッシュを維持し、キャッシュに保存されたコンテンツはマシン間で分離されます。受信クエリをランダムなマシンに分散すると、トラフィックの性質に応じて有効なキャッシュミス率が比例して向上します。たとえば、TTL が長いクエリが繰り返し行われる名前の場合、クラスタ内のマシンの数だけキャッシュミス率を上げることができます。（TTL が非常に短い名前、クエリ頻度が非常に低い名前、キャッシュに保存できないレスポンス（0 TTL とエラー）の場合、マシンの追加によるキャッシュミス率に特に影響はありません）。

キャッシュ可能な名前のヒット率を上げるには、キャッシュが断片化しないようにサーバーをロード バランシングすることが重要です。Google Public DNS には、2 つのレベルのキャッシュがあります。ユーザーのすぐ近くにある 1 つのマシンプールに、マシンごとの小さなキャッシュに、最も人気のある名前が含まれます。このキャッシュからクエリに対応できない場合、クエリは名前でキャッシュを分割している別のマシンプールに送信されます。この第 2 レベルのキャッシュでは、同じ名前のクエリはすべて同じマシンに送信されます。この場合、名前はキャッシュに保存されるか、そうでないかが決まります。

サービス提供地域を分散して広範な地理的に分散する

クローズされたリゾルバの場合、これは実際には問題ではありません。オープン リゾルバの場合、サーバーとユーザーの距離が近いほど、クライアント側でレイテンシが小さくなります。さらに、十分な地理的な対象範囲があれば、ネームサーバーは通常、DNS リゾルバの場所に対して最適化された結果を返すため、エンドツーエンドのレイテンシを間接的に改善できます。つまり、コンテンツ プロバイダが世界中のミラーリング サイトをホストしている場合、そのプロバイダは DNS リゾルバに最も近い IP アドレスを返します。

Google Public DNS は、世界中のデータセンターでホストされ、エニーキャスト ルーティングを使用してユーザーを地理的に最も近いデータセンターに誘導します。

さらに、Google Public DNS は EDNS クライアント サブネット（ECS）をサポートしています。これは、リゾルバがクライアントの場所をネームサーバーに転送する DNS プロトコルの拡張機能であり、リゾルバの IP アドレスではなく、実際のクライアント IP アドレスに対して最適化された、位置情報に依存するレスポンスを返すことができます。詳しくは、よくある質問をご覧ください。 Google Public DNS は、EDNS クライアント サブネットをサポートするネームサーバーを自動的に検出します。