ラウンドロビンDNSを理解する

 (blog.hyperknot.com)
3 ポイント 投稿者 GN⁺ 2024-10-27 | 1件のコメント | WhatsAppで共有

ラウンドロビンDNSを理解する

  • ラウンドロビンDNSとは何か？

    • 一般的に、WebサイトをVPSで提供する際は、DNSプロバイダーの管理画面に単一のAレコードを追加する。
    • ラウンドロビンDNSでは、同じサブドメインに複数のサーバーを指定することで負荷を複数のサーバーに分散し、オフラインのサーバーを自動検知してオンラインのサーバーを選択できる。
    • ロードバランサーを使わずに、シンプルで洗練されたソリューションを提供し、コストもかからない。

  • 理論上はどのように動作するのか？

    • RFC 8305 "Happy Eyeballs" によれば、クライアントは接続前にアドレスを並べ替える必要がある。
    • サーバーがオンラインかオフラインかを確認し、オンラインのサーバーをping時間に応じて並べ替える。

  • 実際にはどのように動作するのか？

    • 米国、欧州、シンガポールに3台のVPSを作成し、Cloudflareに3つのプロキシAレコードと非プロキシAレコードを作成する。
    • 各サーバーは色付きの画像とホスト名を提供する。

クライアントのサーバー選択の挙動

  • Chrome

    • すべての場所でランダムに選択するが、いったん選ぶと固定される。
    • 数時間後に再評価する。

  • Firefox

    • Chromeと同様にランダムに選択し、固定される。

  • Safari

    • 常に最も近いサーバーを正しく選択する。

  • curl

    • 最初は正しくない場合があるが、2回目の実行時には最も近いサーバーに修正される。

  • Cloudflare

    • クライアントIPに基づいてランダムな場所を選択し、固定される。

一部のサーバーがオフラインの場合のクライアントの挙動

  • すべてのクライアントはオフラインのサーバーを検知し、代替サーバーを選択する。
  • Cloudflareはオフラインのサーバーを検知できず、選択されたサーバーがオフラインならそのままオフライン状態で提供される。

Cloudflareの改善点

  1. オフラインのサーバーを検知すべきである。
  2. 最も低いレイテンシのサーバーを選択する機能が必要である。

GN⁺のまとめ

  • ラウンドロビンDNSは複数のサーバーに負荷を分散し、ロードバランサーを使わずに簡単に実装できる方法である。
  • ブラウザーやクライアントのサーバー選択方式はさまざまで、特にSafariは最も近いサーバーをうまく選択する。
  • Cloudflareにはオフラインのサーバーを検知できない問題があり、改善が必要である。
  • この記事はラウンドロビンDNSの動作方式を理解するのに有用であり、サーバー選択アルゴリズムの違いを探るうえで興味深い。

関連記事

1件のコメント

 
GN⁺ 2024-10-27
Hacker Newsの意見

  • DNSチームに現状の説明を依頼しており、返答を受け取り次第共有する予定。コードの変更が頻繁で、現状を正確に把握しにくい。クライアントIPとバックエンドサーバー間の接続維持が問題の原因かもしれない。

  • DNSロードバランシングは複雑な問題を引き起こすことがある。golangのHTTP2クライアントがRR DNSを使うと問題が発生する可能性がある。クライアントが新しいサーバーを発見できない場合がある。

    • すべてのバックエンドサーバーがダウンすると、クライアントは最初に接続したサーバーに固定され、ほかのサーバーへ移動しない。
    • grpc-goでも同様の問題が発生し、サーバー側で MAX_CONNECTION_AGE を設定して定期的にクライアントを切断できる。

  • サービスディスカバリーのための標準的なソリューションが不足している。リクエストベースのロードバランサーを実装し、仮想IPを使ってロードバランサーにヘルスチェックを行わせるのが最善の方法かもしれない。

  • SRV DNSレコードは、すべてのサービスに優先順位を付けられる初期のソリューションだったが、政治的な理由でHTTPクライアントでは使われていない。新しいHTTPSおよびSVCB DNSレコードが、ロードバランシングの新たなソリューションとして提案されている。

  • サーバーがオフラインのとき、クライアントは接続拒否されると次のIPへ移る。しかし実際には、サーバーが応答しなかったり、接続後に沈黙したりすることがある。結果としてクライアントのタイムアウトに依存することになる。

  • 信頼性はクライアント側で決まる。常に最も低いIPアドレスを返してしまうシステムもあり、問題になることがある。DNS-RRはロードバランサーではなく、ロードバランサーのほうがより良い解決策だ。

  • Perlでデコーダーを書き、すべてがPerlであるべきだと主張している。

  • RR-DNSはロードバランシングにのみ有用で、サーバーの可用性を自動で検知しない。クライアントにスマートな機能を追加する必要がある。

  • サーバーがダウンしても、世界中に分散したIPアドレスがあるため、人々は接続を続けられる。

  • 2000年代のAmazonでは、オンサイトホストに対してラウンドロビンDNSを使っていた。当時は最も高速なロードバランシング手法だった。しかし、Wi-Fiが最大のボトルネックだった。

  • Cloudflare Load Balancingへの言及はあるが、実際のテストは行っていない。Cloudflareはオフラインのサーバーを自動検知し、別のサーバーへ切り替えられる。