チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか

結論。DNSラウンドロビンという古くからある技術を取り巻く状況の変化を見過ごしている結果、負荷分散と可用性確保のために高価なロードバランサー機器を導入しているWebサイトは、実は大幅に金を無駄にしているのかもしれない。

一部の人には「今頃気がついたか」と笑われる可能性が高い話だ。
筆者が気づいたきっかけはとあるブログに書かれたこんな一節である。

あまり知られていないことかもしれませんが、DNS があるホスト名に対して複数の IP アドレスを返した場合、多くのウェブブラウザは、その全てのアドレスに対して接続を試みます (接続に成功するまで)。
Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Availability)

「えっ？そうだったの？だとすれば、、、」というのが筆者の素直な感想である。これだけでピンと来ている人はいいのだが、詳しくない人のために以下少々まわりくどく説明を加えながら話を進めることにする。

ある程度のアクセス数のあるWebサイトでは、1台のWebサーバではアクセスをさばききれなくなり、複数台のWebサーバーを設置している。この措置は大量アクセスをさばく目的だけでなく、Webサーバが1台くらい障害を起こしていても他のサーバがサービスを継続してくれる＝可用性の向上＝という目的もある。

問題は、アクセスの振り分けをどうするかだ。www.example.comというひとつのURLへのHTTPリクエストを、どうにかして複数台のWebサーバにに自動的に振り分ける必要がある。
それを実現する方法のひとつが、DNSラウンドロビンである。

インターネット上でドメイン名とIPアドレスを対応づけるDNSを応用して、アクセスの多いサーバの負荷分散を行なう手法。一つのドメイン名に複数のIPアドレスを割り当てて、問い合わせがあるたびに順番に答えることにより、1台のコンピュータへアクセスが集中するのを防ぐ。
DNSラウンドロビンとは 【DNS round robin】　─　意味・解説 ： IT用語辞典 e-Words

例えばコマンドプロンプトを開いて「nslookup d.hatena.ne.jp」と入力してみよう。

C:>nslookup d.hatena.ne.jpName:    d.hatena.ne.jpAddresses:  221.186.129.146, 61.196.246.67, 221.186.146.29

C:>nslookup d.hatena.ne.jp
Name:    d.hatena.ne.jp
Addresses:  61.196.246.67, 221.186.146.29, 221.186.129.146

ひとつのFQDNに対して複数のIPアドレスが返され、しかももう一度同じ問合せをすると、IPアドレスの順番が入れ替わる。
WebブラウザはどれかひとつのIPアドレス（＝Webサーバ）に向けてHTTPリクエストを送信する。IPが3つ返されれば、おおよそ3分の1の確率でHTTPリクエストが各Webサーバに自然と振り分けられることになる。これがDNSラウンドロビンによる負荷分散の原理である。

DNSラウンドロビンの欠点は、分散先のサーバが障害で停止しているとしてもそのIPアドレスを返してしまうのを避けられないことだ
（DNSサーバに小細工を加えることで可能かもしれないが、原則的には無理）。したがって、壊れているWebサーバのIPアドレスをDNS問合せ結果のリストの最初として返されてしまった運の悪いWebブラウザはWebページを見れないことになる。少なくともDNS問合せ結果がキャッシュされている間は。

この欠点を嫌い、ある程度資本力のある企業サイトではDNSラウンドロビンをあきらめて、ロードバランサーという特殊な機材を使っていることが多い。ロードバランサーはWebサーバの前面に設置されて全てのHTTPリクエストを受け取り、下位のWebサーバに振り分けてくれる。詳細は＠IT：パケットフローから負荷分散の基本を理解するという記事の図がわかりやすい。もちろんWebサーバがダウンしていればそれを察知しそのサーバにはリクエストを振らない、といったこともやってくれる。そこがDNSラウンドロビンとの違いだ。

ただし、ロードバランサーは高価だ。有名どころの製品で言うと
このくらいのお値段。もっと安い製品や販路もあるし、値引きもあるよという話もあるが、いずれにせよこれ1台でWebサーバが5台か10台くらい買えてしまうお値段であることは間違いない。

さて、最初に紹介したように「最近の多くのWebブラウザは、DNSがあるホスト名に対して複数の IP アドレスを返した場合にその全てのアドレスに対して接続を試みる (接続に成功するまで)。」ということが本当であれば、先述の「壊れているWebサーバのIPアドレスをDNS問合せ結果のリストの最初として返されてしまった運の悪いWebブラウザはWebページを見れないことになる。」というDNSラウンドロビンを採用しない理由（欠点）が無くなることになる。

筆者の手元の環境で実験した結果、本当だった。二つのWebサーバを立ててそれぞれ異なるIPアドレスを割り当て、しかしDNSサーバの登録にはひとつのホスト名で二つのIPを登録しておいた。htmlファイル上にはどのWebサーバがレスポンスを返しているのかがわかるように記述しておき、Internet Explorer6とFirefox1.5でアクセスする。レスポンスを返してきたWebサーバを停止させ、URLは変えずにただブラウザをリロードすると、ほんの一瞬の間をおいてもう一方のWebサーバがレスポンスを返してきた。その一瞬の間に、「最初のサーバにアクセスできない→もう一方のIPアドレスにリクエストする」という動作がブラウザ内で実行されていたと思われる。

これを裏付ける資料はないものかとMicrosoftのサイトをうろうろしてみたが見つからなかった。趣旨が違うのだが、
Internet Explorer における DNS ホスト エントリのキャッシュの使用方法
(Microsoft 2006/3) という記事を発見した。そこにはIE3からIE4に変わる過程でDNSキャッシュの取り扱いが変わったことが示されている。DNSラウンドロビンで複数IPが返されたときに接続が成功するまで全てにアクセスを試みる、という機能が加わったタイミングもこれと似たような時期ではないかという予測はあながちはずれてはいないだろう。

ふと記憶をたどると、「DNSラウンドロビンだと障害起こしたサーバにもアクセスが振られちゃうんだよね」「あーそうなんですかだからロードバランサいれるんですね」という会話を先輩と交わしたのはたしか2000年ごろだった気がする。あれからもう何年も経っている。その間にブラウザのほうが進化しているとしてもなんら不思議はない。

ところで、DNSラウンドロビンだと全てのWebサーバにグローバルIPアドレスを割り当てなければならないじゃないか（そんなに持ってないよ）と思う人もいるかもしれないが、Webサーバの前段にリバースプロキシ（apacheで言えばmod_proxy_balancerとか）を置くようにすればそれほどの数は必要ないだろう。
また、DNSのキャッシュが悪影響を及ぼさないか心配という人もいると思うが、TTL（生存期間）を短く設定しておけばいいだろう。例えばwww.yahoo.co.jpではほとんどのWebサーバのTTLが300秒（5分）に設定されている（通常は1日とか1週間とかが多い）。
そもそも先述のInternet Explorer における DNS ホスト エントリのキャッシュの使用方法にもあるように、ブラウザがDNS問合せ結果をキャッシュする時間はかなり短めになっている。

ただし、さっさとロードバランサを捨てようというのもまた短絡である。PCのブラウザではなく携帯電話（iモード）で試してみたのだが、apacheを停止させているほうのWebサーバにもつながってしまい、「混みあっています」のエラーが表示されることがあった。おおよそ2分の1の確率。つまり、iモードのブラウザ（正確にはiモードのゲートウェイプロキシ）は昔のままで、現在のPC用のブラウザほどインテリジェントじゃないということだ。Webサーバ側でkeepAliveを使っている場合はどうなるということもテストが必要だろう。またロードバランサにはリクエストの振り分けだけでなくSSLアクセラレータ機能、HTTP圧縮転送機能、TCPコネクション維持機能、セッション維持用Cookie値に合わせて特定のWebサーバに振る機能などを持つものもある。それらの機能に依存している場合には安易にロードバランサを捨ててDNSラウンドロビンに移行させるわけにもいかない。

思えば、Javascriptという古い技術がAjaxという新しい形で改めて脚光を浴びているのと同じだ。状況は変化し、古い技術が見直されることがある。
ブラウザの進化に気づかず（or目をつむって）高価なロードバランサーを使い続けるか、DNSラウンドロビンというチープな技術をフル活用するか、 みなさんはどちら？