元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2012/04/13

by ZakVTA

DNSラウンドロビンを使った時にアクセス・負荷が偏る話


昨日に続き、アクセスが偏る系のエントリです。

なにかと議論のネタになるDNSラウンドロビンですが、今日はDNSラウンドロビンを使った時に、各IPアドレスにくるリクエスト数に偏りが出るという話。


DNSラウンドロビンで設定されているFQDNに、コマンドラインで"host"とか"nslookup"のコマンドを何度か実行すると、返ってくるIPアドレスリストの順序が入れ替わっていくことが確認できると思います。

基本的に、クライアントはそのIPアドレスリストの上(最初)からアクセスを行うため、これによって(一応)負荷分散が実現できるはずですが、特定環境のクライアントでは、ラウンドロビンとはならずに必ず特定のIPアドレスにアクセスするケースがあるのです。(既知の事実ですが。)


この事は、Wikipediaの該当ページにも記載されています。

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

DNSラウンドロビン - Wikipedia

これが、どういうことかというと、RFC3484の以下部分に書いてあるとおりですが、

Rule 9: Use longest matching prefix.

When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then prefer DB.

http://www.ietf.org/rfc/rfc3484.txt

DNSの問い合わせ結果の各々のIPアドレスと自分のIPアドレスを比較し、一致する部分の長さが最も大きくなるものが使われるというもの。


このページの例がわかりやすいのですが、

11000000 10101000 00000000 00000001 = 192.168.0.1 = Client IP to match.
11000000 10101000 00000000 01100100 = 192.168.0.100 = (24 + 1 = 25 bits matching the client IP)
11000000 10101000 00000000 00001010 = 192.168.0.10 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001011 = 192.168.0.11 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001101 = 192.168.0.15 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00010100 = 192.168.0.20 = (24 + 3 = 27 bits matching the client IP)

↑の例だと、自分のIPアドレス(192.168.0.1)と、最長で一致しているのが、"192.168.0.10"、"192.168.0.11"、"192.168.0.15"の3つとなり、この中で一番上(最初)のIPアドレスが使われることになるっぽい。(つまり、192.168.0.10)

つまり、この環境だと問い合わせ結果のリストに含まれる"192.168.0.100"や"192.168.0.20"のIPアドレスは使われないことになる。


一部のクライアント(特にIPv6が有効になっているケースとか?)では、IPv4アドレスでの結果であっても、上記のようにRFC準拠したDNS問い合わせの実装となっているケースがあるようで、それによってDNSラウンドロビンで設定しているドメインであっても、リクエスト・トラフィックに偏りが出てしまう。

有名なのは、Windows VistaやWindows 2008 Server(R1以前?)のDNSクライアントらしい。Windows 7やWindows Server 2008 R2では問題ないみたい。

ただし、アプリケーション(Firefox等のブラウザとか)によっては、上記のような環境においても、アプリケーション側でラウンドロビンにのっとった実装を行ってくれているようだ。


ここで言いたかったのは、上記のような可能性がある以上、DNSラウンドロビンを採用している環境で、各IPアドレスでのアクセス・負荷に偏りが出ることは必然であり、RFC準拠である以上、DNSラウンドロビンは場合によっては使い物にならなくなる可能性があるということ。

今更な話かもしれませんが。


それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考


DNS & BIND 第5版

DNS & BIND 第5版

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/rx7/20120413/p1

オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)