DNSラウンドロビンとは：複数IPへの分散

DNSラウンドロビンは、DNSが1つの名前に対して複数のアドレスレコードを公開し、応答ごとにその順序を入れ替える場合もある、シンプルな手法です。クライアントやリゾルバーには、固定された1つのIPではなく、複数の宛先の候補が見えます。サーバー間で接続を分散したり、基本的な冗長性を確保したりするために、よく使われます。ただし、DNSは個々のクライアントごとに各サーバーが正常かどうかを観測しません。また、キャッシュがあるため、リゾルバーはTTLの間、同じ応答を使い続けることがあります。つまりラウンドロビンは、軽量な分散方法であり、フェイルオーバーが保証された、正常性を考慮する完全なロードバランシングの仕組みではありません。

クライアントに見えるもの

DNS応答には、複数の A または AAAA レコードが含まれることがあります。再帰リゾルバーはそのセットをキャッシュし、返されたアドレスをどのように試すかは、オペレーティングシステムやアプリケーションが決めます。最初のアドレスを使うものもあれば、並べ替えたり複数の接続を試みたりするものもあります。最近のブラウザーのスタックは、独自の接続戦略に従って、アドレスファミリーを競わせることもあります。DNS応答の順序だけでは、最終的にどのサーバーがユーザーのリクエストを処理したのかは証明できません。検索を繰り返すと、順序や一部のアドレスが変わることがありますが、この動作は権威プロバイダーとリゾルバーに依存します。

重要な結果として、故障したサーバーは、該当するTTLが切れるか、リゾルバーがデータを更新するまで、キャッシュされた応答に残り続けることがあります。計画的な移行の前にTTLを下げておけば、想定されるキャッシュの期間は短縮できますが、古いTTLですでにキャッシュされた応答までは消えません。クライアント自身が、キャッシュや接続の再利用の動作を持っている場合もあります。こうした理由から、迅速で信頼性の高い、正常性に基づくフェイルオーバーがサービスに求められる場合、サーバー障害に対する唯一の保護手段としてDNSラウンドロビンに頼るべきではありません。

ロードバランサーとの比較

専用のロードバランサーは、接続やアプリケーションの層で判断を下し、ヘルスチェックを実行し、設定された条件を満たすエンドポイントにだけトラフィックを送れます。DNSプロバイダーもヘルスチェックや動的な応答を提供する場合がありますが、その機能はプロバイダーごとに異なり、やはり再帰キャッシュの影響を受けます。基本的なラウンドロビンのレコードセットは、選択肢を提供するだけで、フィードバックの仕組みは備えていません。これらの設計は組み合わせることもできます。たとえば、DNSがユーザーをリージョンごとのロードバランサーに誘導し、そのロードバランサーが正常なバックエンドを選ぶ構成です。対処したい障害の形態を観測できる層を選んでください。

• ラウンドロビンのセットに含まれるすべてのアドレスが、そのホスト名のサービスを提供できる状態に保つ。
• 各エンドポイントを個別に監視する。DNSの順序入れ替えはヘルスチェックではありません。
• 切り替えやフェイルオーバーを計画する前に、TTLとクライアントのキャッシュを理解する。
• エンドポイントを素早く除外する必要がある場合は、正常性を考慮するロードバランサーを使う。
• 名前を明示したリゾルバーから返る応答を繰り返し比較し、各クエリの時刻を記録する。

複数の応答のトラブルシューティング方法

ドメインが複数のIPアドレスに解決される場合は、まずそれが意図的なものかどうかを確認します。権威ゾーンまたはプロバイダーのダッシュボードで、レコードセット全体を確認し、そのうえで再帰リゾルバーの応答と比較します。そのアドレスが、想定されるホスティング、CDN、ロードバランサーのインフラに属しているかは、逆引きだけに頼らず、プロバイダーのドキュメントで判断します。管理している場合は、各エンドポイントを、意図したホスト名とTLS構成でテストしてください。IPへの直接のリクエストでは、異なる結果が返ることがあります。バーチャルホスティングはホスト名に依存するためです。そのため、IPだけでのテストを、通常のトラフィックの完全な代わりとして扱わないでください。

DNSラウンドロビンは設定が簡単ですが、運用上のシンプルさが、キャッシュの保持期間やエンドポイントの正常性に関する重要な前提を覆い隠すことがあります。より広い背景については、ドメインに複数のIPがある理由 と CDNがDNSでトラフィックをルーティングする仕組み をご覧ください。ドメインIP検索 では、現在公開されている応答セットを確認できます。その観測結果を、監視やサービス固有のチェックと組み合わせて、分散が意図どおりに機能しているかを把握してください。

すべての宛先でプールの一貫性を保つ

ラウンドロビンのセットに複数のアドレスを追加する前に、各エンドポイントが、同じホスト名と同じバージョンのアプリケーションを安全に提供できることを確認します。証明書の対象範囲、正常性、データの一貫性、セッション状態に関する前提を確認してください。ユーザーがどのアドレスに着地してもおかしくない場合、コンテンツが不完全なサーバーや、ログイン設定が異なるサーバーがあると、ランダムに見える断続的な障害が発生します。各アドレスを、正しいHostヘッダーとTLS名で監視し、pingだけに頼らず、アプリケーションのエラーも比較してください。故障した宛先を外すときは、キャッシュされたDNS応答と、すでに開いている接続を考慮に入れます。DNSは新しい検索に対してそのアドレスを通知しなくなることはできますが、すべてのクライアントの既存のセッションやキャッシュされた接続を、即座に終了させることはできません。