概要: DNS レイテンシの原因と軽減策
ウェブページが複雑になり、多数のドメインからリソースを参照するようになると、DNS ルックアップがブラウジング操作の重大なボトルネックになる可能性があります。クライアントがネットワーク経由で DNS リゾルバにクエリを行う必要がある場合は、リゾルバがクエリする必要があるネームサーバーの数や近接性によっては、レイテンシが大幅に増加する可能性があります（2 台を超えることはまれですが、発生する場合もあります）。たとえば、次のスクリーンショットは、Page Speed ウェブ パフォーマンス測定ツールによって報告された速度を示しています。 各バーは、そのページから参照されるリソースを表しています。黒いセグメントは DNS ルックアップを示しています。このページでは、ページが読み込まれる最初の 11 秒間に 13 回のルックアップが行われています。いくつかのルックアップは並行して実行されていますが、スクリーンショットを見ると、合計 11 秒のページ読み込み時間のうちの数秒を占めている、5 つの連続したルックアップ時間が必要であることがわかります。
DNS レイテンシには次の 2 つの要素があります。
- クライアント（ユーザー）と DNS 解決サーバー間のレイテンシ。ほとんどの場合、これはネットワーク システムにおける通常のラウンドトリップ時間（RTT）の制約（クライアント マシンとサーバー マシン間の地理的距離、ネットワークの輻輳、パケットロスと長い再送信遅延（平均 1 秒）、サーバーの過負荷、サービス拒否攻撃など）に大きく起因します。
- 解決サーバーと他のネームサーバー間のレイテンシ。このレイテンシの原因は、主に次の要因です。
- キャッシュミス。リゾルバのキャッシュからレスポンスを提供できないが、他のネームサーバーに再帰的にクエリする必要がある場合、特に権威サーバーが地理的に離れた場所にいる場合、ネットワーク レイテンシが大幅に増加します。
- アンダープロビジョニング。 DNS リゾルバが過負荷状態になると、DNS 解決のリクエストとレスポンスをキューに入れる必要があり、パケットのドロップと再送信を開始することがあります。
- 悪意のあるトラフィック。 DNS サービスがオーバープロビジョニングされている場合でも、DoS トラフィックによってサーバーに過度の負荷がかかる可能性があります。同様に、Kaminsky スタイルの攻撃では、キャッシュのバイパスが保証され、解決のために送信リクエストが必要になるクエリで、リゾルバのフラッディングが行われる可能性があります。
Google は、キャッシュミスの要因が DNS レイテンシの最も大きな原因であると考えており、これについては後述します。
キャッシュミス
リゾルバに豊富なローカル リソースがある場合でも、リモートのネームサーバーとの通信に関連する基本的な遅延を回避することは困難です。つまり、サーバー側でキャッシュ ヒットがゼロになるようにリゾルバが十分にプロビジョニングされていると仮定した場合、キャッシュミスはレイテンシの点で非常に高コストのままです。ミスを処理するには、リゾルバが少なくとも 1 つ、通常は 2 つ以上の外部ネームサーバーと通信する必要があります。Googlebot ウェブ クローラーを操作したところ、応答したネームサーバーの平均解決時間は 130 ミリ秒でした。ただし、UDP パケットロスとサーバーにアクセスできないため、4 ～ 6% のリクエストは単にタイムアウトします。パケットロス、ネームサーバーの停止、DNS 構成エラーなどの障害を考慮すると、実際のエンドツーエンドの解決時間は 300 ～ 400 ミリ秒です。ただし、ばらつきが大きく、ロングテールもあります。
キャッシュミス率は DNS サーバーによって異なる場合がありますが、次の理由により、キャッシュミスを回避することは根本的に困難です。
- インターネットの規模と拡大。つまり、インターネットが成長し、新規ユーザーの追加と新しいサイトの増加によって、ほとんどのコンテンツが関心の対象にされているのはごく普通のことです。非常に人気のあるサイト（ひいては DNS 名）もいくつかありますが、ほとんどのサイトは限られたユーザーにしか関心がなく、アクセス頻度もめったにないため、リクエストの大半でキャッシュミスが発生します。
- 有効期間（TTL）が低い。DNS TTL 値は減少する傾向にあるため、解決にはより頻繁に検索を行う必要があります。
- キャッシュの分離。通常、DNS サーバーはロードバランサの背後でデプロイされ、異なるマシンにランダムにクエリを割り当てます。その結果、各サーバーが別々のキャッシュを保持するようになり、共有プールからキャッシュに保存されている解像度を再利用できなくなります。
リスクの軽減
Google Public DNS には、DNS ルックアップ時間を高速化するいくつかのアプローチが実装されています。これらのアプローチには、かなり標準的なものもあれば、試験運用版のものもあります。
- 悪意のあるトラフィックなどのクライアント トラフィックからの負荷を処理できるように、サーバーを適切にプロビジョニングする。
- DoS 攻撃と増幅攻撃の防止。これは主にセキュリティ上の問題であり、オープンなリゾルバよりもクローズド リゾルバに影響を及ぼしますが、DoS 攻撃を防ぐことで、DNS サーバーにかかる余分なトラフィックの負担が軽減され、パフォーマンスにもメリットがあります。攻撃の可能性を最小限に抑えるためのアプローチについては、セキュリティ上のメリットのページをご覧ください。
- 共有キャッシュのロード バランシング。サービス クラスタ全体で集計されたキャッシュ ヒット率を改善する。
- あらゆるユーザーと距離をグローバルにカバーする。
サービス クラスタを適切にプロビジョニングする
キャッシュ DNS リゾルバは、メモリからレスポンスを提供できないため、権威ネームサーバーよりも高コストのオペレーションを実行する必要があります。その代わりに、他のネームサーバーとの通信が必要になるため、ネットワークの入出力を大量に要求します。さらに、オープン リゾルバはキャッシュ ポイズニングの試みに対して脆弱で、キャッシュミス率を上昇させます（このような攻撃は、具体的にはキャッシュから解決できない偽名に対するリクエストを送信します）。また、トラフィックの負荷を増加させる DoS 攻撃に対しても脆弱です。リゾルバが適切にプロビジョニングされておらず、負荷に対応できない場合、パフォーマンスに大きな悪影響が生じる可能性があります。パケットがドロップされて再送信が必要な場合、ネームサーバーのリクエストをキューに入れる必要がある場合などです。こうした要因が遅延の原因となります。
したがって、DNS リゾルバを大容量の入出力用にプロビジョニングすることが重要です。これには、可能性のある DDoS 攻撃への対応も含まれます。この場合、唯一の効果的なソリューションは、多くのマシンでオーバープロビジョニングを行うことです。ただし、マシンを追加するときにキャッシュ ヒット率を低下させないことが重要です。そのためには、以下で説明する効果的なロード バランシング ポリシーを実装する必要があります。
共有キャッシュのロード バランシング
マシンを追加してリゾルバ インフラストラクチャをスケーリングすると、ロード バランシングが正しく行われない場合に、実際にはバックファイアが発生し、キャッシュ ヒット率が低下する可能性があります。一般的なデプロイでは、ロードバランサの背後に複数のマシンが配置され、ラウンドロビンなどの単純なアルゴリズムを使用して各マシンにトラフィックを均等に分散します。その結果、各マシンは独自のキャッシュを保持するため、キャッシュに保存されたコンテンツはマシン間で分離されます。受信クエリがランダムなマシンに分散される場合、トラフィックの性質に応じて、実質的なキャッシュミス率が比例して増加する可能性があります。たとえば、TTL が長い名前が繰り返しクエリされる場合、キャッシュミス率がクラスタ内のマシン台数だけ増加することがあります。（TTL が非常に短い名前、クエリの頻度が非常に低い名前、キャッシュできないレスポンス（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 クライアント サブネットをサポートするネームサーバーを自動的に検出します。