DNSラウンドロビン

ウィキペディア

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/03/01 07:10 UTC 版)

ナビゲーションに移動検索に移動

概要

トラフィック負荷を複数のIPアドレスに振り分けることにより、例えばHTTPサーバに対するアクセスをほぼ同量ずつ複数のサーバマシンに分配することができる。これはBIND等DNSサーバのゾーン設定により容易に実現できる負荷分散方式である。アクセス数に応じた負荷分散のほか、通信量、サーバの負荷（CPUやメモリの使用率）、応答時間で負荷分散をすることができる。

後述するような問題点があることに加え、主にIPv6における宛先アドレス選択アルゴリズムとして定義された「RFC3484」では、DNSが同一サーバ名に対し複数のIPアドレスを持つ場合に「自分のアドレスに近いアドレスを優先的に選択する」ことを定めており^[1]、Windows Vistaなどマイクロソフト製OSの一部や、最近のLinuxなどではこのルールに従いDNSラウンドロビンがデフォルトで無効にされている^[2]^[3]。

このため、近年では他の負荷分散方式を用いたり、クラスタリングを導入するケースが増えてきている。またYouTubeなどが採用する「IPアドレスの上位プレフィックスを同じ値で揃える」方法など、RFC3484が有効な環境でもDNSラウンドロビンの効力を発揮させるテクニックも編み出されている^[4]。

メリット

導入が容易である……ゾーンファイルの設定のみで導入できる
ネットワーク的に離れたサーバーに分散できる

問題点

分散先サーバの通信継続性: 接続ごとに接続先が違うと、接続の継続性が求められるサーバの場合に問題が起きる可能性がある(Webアプリケーションのセッション管理や暗号化通信など)。
分散先サーバの同期: 分散サーバのコンテンツの内容が同一でないと、接続に問題が起きる可能性がある(Webサーバでのリンクなど)。
DNSキャッシングの情報更新の際に生じる時差: レコードのTTLが長い場合、変更前の情報を参照してしまう期間が長くなってしまう。後述のようにTTLを短めにした運用が一般的である。
トラフィック負荷を分散する際の予期せぬ偏り: 均等な負荷分散はできない。ヘビーユーザが一つの通信先に集中してアクセスを行う場合もある
分散先サーバの障害検知が不可能: DNSラウンドロビンでは、基本的に分散先サーバの状態が取得できないため分散先サーバが応答不可能な状態になっていても分散先として割り振ってしまう。
512バイト問題: 同一のサーバ名に対し多くのIPアドレスを割り当てた結果、DNS Queryの結果が一般的なUDPパケットのサイズである512バイトを超えてしまう場合に、ソフトウェアによって正常な処理が行われない場合がある^[5]。

ゾーンファイル記述例

hoge       IN  A  127.0.1.1
hoge       IN  A  127.0.1.2
hoge       IN  A  127.0.1.3

※実際に運用する際には

hoge   30m  IN  A  127.0.1.1
hoge   30m  IN  A  127.0.1.2
hoge   30m  IN  A  127.0.1.3

のように、TTLを短めに設定して頻繁にリクエスト先を変えさせることが好ましい。

以前は、以下のようにCNAMEレコードを用いて記述されることがあったが、現在のDNSの仕様ではこの方法は禁止されている。

hoge       IN  CNAME hoge1
           IN  CNAME hoge2
           IN  CNAME hoge3
hoge1      IN  A     127.0.1.1
hoge2      IN  A     127.0.1.2
hoge3      IN  A     127.0.1.3

脚注