_ えーと。
この内容ではかじった程度の知識しかない人では誤解しかねないと思う。悪い記事ではないんだが、補足は必要だろう。こっち方面はわしもそんなに詳しいわけじゃないんだけどね。_ ひとつのホスト名に複数の IP アドレスがある場合に、接続が成功するまで次々とフォールバックする、という動作は、DNS を使ってなくても確認できる。実際に試してみようか。UNIX ならば /etc/hosts、Windows ならば \WINDOWS\system32\drivers\etc\hosts をバックアップしてから以下のような行を追加してみる。hosts に書くと、ランダムではなく常に記述された順番でアクセスしようとするので動作がわかりやすい。
この設定を追加して今ブラウザで見ている当ページをリロードしてみてくださいな。すぐにつながるよね。127.0.0.1 という IP アドレスでは httpd が動いてないけど、動いてないことがすぐにわかったから、すぐに次の 219.111.8.132 を試したわけだ。127.0.0.1 ya.maya.st # httpd が動いてない（もしローカルで動いてたら止めてくれ） 219.111.8.132 ya.maya.st # httpd が動いてる_ では、hosts を次のように変更してみる。
同じようにリロードしてみると、今度は数十秒待たされてからつながるはず。240.0.0.1 にアクセスしようとしたものの、そんな IP アドレスへのルーティングが存在しないから応答が返ってこない。返ってこないからタイムアウトするまで待ってから 219.111.8.132 を試す。これが数十秒の待ち時間の原因。手元の Windows + Firefox では20秒待った。240.0.0.1 ya.maya.st # 到達できない 219.111.8.132 ya.maya.st # 到達できる_ 以上実験終わり。hosts のバックアップを戻してさっき追加した変な行は消してくれ。
_ 上は hosts ファイルで実験したけど、DNS ラウンドロビンでも同じことが起きる。ホストは生きてるけどその上でプロセスが動いてない、というような場合は、そのホスト自身から「アクセスできねーよバカ」という応答がすぐに返るので、タイムラグなしにフォールバックできる。でも、物理的に電源が落ちているような場合はそういう応答もない。ホストが落ちた場合に TCP RST や ICMP destination unreachable などのパケットが返ってくるとはかぎらないことは頭に入れておく必要がある。
_ タイムアウトしても、結局はフォールバックして生きてるホストにつながるので、DNS ラウンドロビンでも可用性は確保されているといえないわけではない。しかし、DNS から抜いてキャッシュから消えるまでの間は 1/2 なり 1/3 なりの確率で数十秒も待たされるというのはサービス的にどうかと思う。 8秒ルールとか言うけど、接続するだけでその数倍の時間がかかるんだよ？
_ ちゃんとしたロードバランサは、配下のホストが生きているかどうかを数秒間隔でチェックして、応答がなければ自動で分散対象から抜く。ホストが死んでからバランサが検知するまでの数秒間にアクセスされた場合に 1/2 なり 1/3 なりの確率でだけ待たされる可能性がある程度で、DNS ラウンドロビンはそれに比べるとはるかに弱い。DNS ラウンドロビンでもアクセスできなくなるわけではないが、ロードバランサと比べるとムチャクチャ待たされることはある、ということは頭に入れておかなければならない。負荷分散はできるし、最終的にはつながるけど、これで冗長ですバッチリですっ、と胸をはるにはちょっとつらいと思う。
_ 以上はあくまで DNS ラウンドロビンをレイヤ4スイッチ（TCP レベルでの分散処理）の代替として使う場合のこと。
ロードバランサにはリクエストの振り分けだけでなくSSLアクセラレータ機能、HTTP圧縮転送機能、TCPコネクション維持機能、セッション維持用 Cookie値に合わせて特定のWebサーバに振る機能などを持つものもある。それらの機能に依存している場合には安易にロードバランサを捨ててDNSラウンドロビンに移行させるわけにもいかない。今どきの Web アプリだとこういうレイヤ7スイッチ（アプリケーションレベルの分散処理）の機能が欲しい場合がほとんどなんじゃないの？ こういう場合には、DNS ラウンドロビンはまったく何の役にも立たないっつーか、異常動作の原因にもなりかねない。_ さらに、たいていのロードバランサ製品は、ホストの処理能力に応じて分散対象ホストを重みづけできたり、負荷とか応答時間とかに応じてその重みづけを動的に変化させたりできる。また、ホストをメンテする際に、DNS から抜いて TTL が過ぎてアクセスがなくなるのを待ってそれからプロセスを落として、なんてまどろっこしいことをしないで済むのもありがたい。
_ 逆に言えば、上に挙げたような欠点があっても問題のないような用途ならば、ロードバランサを買わなくても十分やっていけるだろう。つーか、L4SW に特化した製品ってあったっけ？ 売る側もそれを十分認識してるからいまやロードバランサといったら L7SW ばっかりでしょ。L7SW と DNS ラウンドロビンじゃ、まさしくレイヤが違うよ。レイヤが違うんだから、同じ土俵で語ったらいかん。
_ 激しい雷雨。
_ 通り過ぎていったかな、と思ったころにとつぜん瞬停。かんべんしてください。
_ きのうの続き。考慮しなければならないことはまだまだたくさんある。
_ アクセスしようとしたホストが落ちてたときに別のアドレスにフォールバックするという挙動は
少なくとも、Internet Explorer 6.0 と Mozilla Firefox 1.5 は、記載のとおり動作しますと 書かれているが、ブラウザが直接 Web サーバにアクセスするばかりではない。プロクシを使ってる環境は非常に多く（ユーザが明示的にプロクシを指定するだけでなく、透過プロクシのように無意識に経由してる場合もある）、そいつらまですべて期待どおりの動きをするとは、はっきりいってまったく期待できない。接続できるまですべての IP アドレスを試すのは telnet のような原始的なツールでも実装していることなんだけど、だからといってぜんぶがぜんぶそういう動作をするわけではないことは頭に入れておく必要がある。_ DNS でラウンドロビンする場合、ふつーは TTL を短めに設定して障害時にすばやく切り替えできるようにするけど、TTL を無視して長時間キャッシュし続けるうんこなキャッシュ DNS が世の中にはゴロゴロしてるので注意。メンテのために1台を DNS から抜いたのに TTL が過ぎてもアクセスがちっともなくならないなんてことは、すこしも珍しくないどころか、むしろきっぱりアクセスがなくなることの方が皆無。DNS をどういじればそんな設定にできるのかまったく不明なんだけどねぇ。
_ それから、Windows は DNS への問い合わせ結果をキャッシュするが、そのキャッシュされた結果を常に固定順で返すのでラウンドロビンにはならない (*1)。Windows 以外にも、家庭用ルータのおまけの DNS でもそういう実装のものがあるらしい。TCP RST も返せない状態で死んだホストがキャッシュの先頭に入ってしまうと、そのクライアントからのアクセスはたとえ次のアドレスにフォールバックするとしても、長時間のタイムアウト待ちが発生し、しかもそれはキャッシュから消えるまでの間は何度アクセスしても毎回待たされることになる。これはサーバの側ではまったく手の打ちようがない。
_ 接続を試す順番が固定であっても、サーバから見てクライアントの数が非常に多ければ全体としてアクセスは平均的になる。しかし数が少なければ偏りが生じて負荷分散にならない。たとえばリバースプロクシを構成する場合、プロクシ先を DNS ラウンドロビンにしても、プロクシ元が常にホストを固定順で選択してしまったら、負荷分散としても冗長構成としてもまったく意味がない。
_ ……と、いうわけで、DNS ラウンドロビンをロードバランサがわりに使えると思ったら大きな間違い。きのうも書いたけど、こういう欠点があっても問題のない場合に使うのならば DNS ラウンドロビンでもいいだろうけど、そもそもロードバランサとはまったく違うものだということは理解しておかなければならない。っていうか、あんなに高価なのにロードバランサ製品が使われるのは、そういうことをちゃんと理解してて DNS をいじるだけじゃどうしようもないとわかってるからだよ。ほんとに無知で意味もないのに使ってるところもあるかもしれないけどさ。
_ 最後にぜんぜん関係ないけど、ラウンドロビンを RR と略すのはやめてね。DNS で RR といったらふつー resource record なので。混乱の元にしかならない。
(*1): コマンドプロンプトから nslookup www.yahoo.co.jp を何度も実行するとその都度 IP アドレスリストの順番は入れ替わるが、ping www.yahoo.co.jp を実行すると何度実行しても同じ IP アドレスにパケットを飛ばす。前者は毎回 DNS に問い合わせるが、後者は OS のキャッシュから IP アドレスを得るため。
_ Cisco 7200 Simulatorだそうな。FreeBSD の ports/emulators/dynamips にも入ってた。
_ 実行には本物 IOS が必要だそうで。といわれても、IOS ってそんなにほいほい拾ってこれるものなんだっけ？（本気で知らない） L7 の世界で生きるわしには無用の長物だけど、L3 な人には便利なんじゃないでしょーか。
_ クレーン船が送電線に接触したっつー今朝の首都圏大規模停電だけど、違うでしょ？ 風がやんだんでしょ？ だって 風で動くはてなが 停電で止まったんだよ？
_ 1箇所で送電が止まっただけなのに、局所的なものにとどまらずこんなに大規模な停電が起きるってのはちょとマズいんじゃないかしらん。迂回して送電するルートはあったみたいだけど、切り替えに数時間かかってるよね。瞬停すら許さんとは言わんけど、せいぜい数分程度で復帰できないものかしらん。
_ ところで、送電線のルーティングってどんなアルゴリズム使ってるんだろ。まさか BGP ってことはありえないけど、興味あるかも。
_ 東京電力って障害情報のページないんだな。もしかしたらどこかにあるのかもしれんけど、少なくともトップページを目 grep したかぎりでは見つからん。今朝のような大規模停電だけではなく、週末にあったような局地的な雷による停電の情報なんかも載せてくれるとうれしかったりするんだけど。いちおう 雨量・雷観測情報へのリンクはあるけど、あくまで雷が鳴ってます、であって、雷が落ちてこのあたり停電中です、ではないもんな。
_ ぜんぜん違うものです。区別しましょう。もちろん両者を兼ねることはあるけど、混同しちゃいけない。
_ 最近よく話題になるけど、mod_proxy_balancer ってバックエンドの負荷分散はできても全体の冗長化はできないよね。mod_proxy_balancer のうしろにホストを複数台用意してバランシングしても、そのアクセスを振り分けてる apache 自体が1台しかないんじゃ意味がない。よく知らないけどたしか pound も同じだよね。バックエンドだけ分散したってダメ。フロントのサーバも含めて single point of failure をなくさなければ、冗長構成としては意味がない。
_ つーわけで、安価に可用性を高めるにはどうしたらいいかという話にツッコミ入れるのに、このような 冗長化できない reverse proxy をまっさきに持ってきちゃダメだよね。あらかじめそのことをことわり入れておくのならともかく。これまた誤読を誘いかねない。ソフトウェアによるソリューションがいろいろ挙げられてるのはひじょーに参考になるんだけど。
_ サーバの負荷分散 + 冗長化の基本構成。
こういう構成にすると、ルータ、スイッチ(L2SW)、ロードバランサ(L4SW)のどれが落ちても、片方だけならば外からサーバ群に到達できる（サーバのすぐ上にある方の L2SW が死ぬと、サービスできるサーバが半分になるので注意）。あまりに教科書どおりでおもしろくないな。本気でこんなの作ったらあっとゆーまに金がふっとぶし。そこでコストをどうやって減らすか考えるわけだ。誰か考えて。わしのかわりに。The Internet | | Router Router | | L2SW - L2SW | | L4SW L4SW | | L2SW - L2SW /|\ /|\ S S S S S S ← 実際のサーバ群
_ 靖国通りでデモやってた。拡声器ごしのシュプレヒコールは通りを1本隔てるとビルに反射して、何を言ってるのかただの1語も聴き取れず。右でも左でもどっちでもいいから、うるさいだけだからとにかくおまえら黙れ。
_ DailyChanges.com。DNS サーバごとの登録ゾーンの毎日の増減調査をやってるらしい。
_ 新規に登録されたドメインを見ると、いかにも spam 送信のために取得されたものばっかりに見える。もちろんそればっかりじゃないんだろうけどさ。これだけたくさんのドメインがあって、実際に使われるのっていったいどのぐらいの割合なんだろ。もしかしてドメイン屋ってすげーうまい商売だったりする？
_ 小ネタ。今日ふつーにコマンドを打ってたら、うしろで見てた人がおどろいてたので。でも、まあ、ふつー。
_ 正攻法では、こんな感じ。
でも、grep って実は固定文字列の検索がほとんどで、正規表現が必要なことってそんなに多くないんだよね。egrep だとメタキャラクタのエスケープをちゃんとやっとかないと結果がおかしくなることあるし。そんなときはこれ。% egrep 'pattern1|pattern2' filename1行1パターンなので、なんか別のコマンドからの出力をコピペしたりするときにも便利。fgrep で書いてるけど、もちろん egrep でも可。シェルスクリプト中で使う場合は CTRL-D が入力できないのでかわりにヒアドキュメント(<<)でどぞ。% fgrep -f- filename pattern1 pattern2 CTRL-D_ 応用。
条件にマッチするメールがサーバに入ってきてから出ていくまでを追跡（queue id をキーに再検索）。ただし、見ればわかるとおり同じファイルを2回 grep するので、デカいログを相手にする場合はあまり効率がよくない。% grep 'なんか抽出条件' /var/log/maillog | cut -d: -f4 | fgrep -f- /var/log/maillog
_ 長梅雨のころは空を見上げながら、あー今日も出かけるのはやめようか、はやく梅雨が明けないかなー、などとつぶやいていたわけだが、いざ本格的に夏がやってくると、こんなクソ暑いのに外をほっつき歩くなんてとんでもねー、てなわけで、けっきょく外に出ないことには変わらんのであった。
_ 暑いから昼は素麺にでもするか、と鍋を火にかけた2分後、その熱に耐えかねて火を消して外に食いにいくことに方針変更。よわっ。
_ わしは先週吉林省方面から大量に打ち込んでくる spammer と戦っていたわけだが、 BIGLOBE もたいへんなようで。BIGLOBE が使ってる Cloudmark の spam 判定のしくみをかんたんに説明すると、あるアルゴリズムでメールのシグネチャを計算し、それがネットワーク上のデータベースに存在するかどうか問い合わせる、というものなんだけど、BIGLOBE のお知らせを読むだけでは判定をすり抜ける原因がどこにあるのかいまいちよくわからんなぁ。たんなる実装のバグなのか、spammer 側がシグネチャ生成アルゴリズムの穴を突いてるのか、運用ミスでデータベースへの反映がコケてるのか、それともまったく他の要因なのか。
_ で、この Cloudmark のこのしくみは Vipul's Razorや Pyzorとして SpamAssassin なんかのツールからもフリーで利用できるんだけど、こいつらも同じように影響を受けてるのかしらん？ ISP で使っているものはオープンソースのものとは参照しているデータベースが違う可能性もあるし、しくみは同じでも実装まで同じとは限らんので、同じようにコケてるかどうかはビミョーなところなんだけど。もし Razor つきで SpamAssassin を使ってる人がいたら、判定にどう反映されてるか調べてみてくださいまし。
_ Cisco 7200 simulatorだけでなく、 IOS simulatorなんてものまであるらしい。開発はもう何年も前から停止してるようだけど。
_ だそうです。ひょんなことから見つけた ページに書いてあった。
その qmail が「もはや使うことができないのでは」という話を読んだ。……って、リンクも何もないけど、もしかしなくてもわしが書いた これのことだよね（もう半年前になるのか）。でも、すんません、何を主張したいのかよくわかりません。djb の思想を紹介されてるだけで、書いた人の意見というのが見えないんだけど、わしが書いたことに反論したかったのかな？_ 2月にあれを書いたときは、かなりの反発を受けるかな、と思ってたんだけど、実はちっともそんなことはなく、「へー、そうなんだ」という声と「ほんとそうだよね」という声がほとんどだった。もちろん否定的な意見もゼロではないんだけど、圧倒的に少数。正直言って拍子抜けした。賛否両論を予想していたのに実際はそうはならなくて気持ち悪かったので、反対票に1票いただけたのはたいへんありがたい。といっても、主張がよくわからんのでどうしようもないのだが。これを書いた MRI の研究員の人（だけでなく、qmail でまだ戦えると思うすべて人）にはぜひ詳しい反論をいただきたいものだ。