最近ソフトウェアによるロードバランジングネタがちょっとアツい。
元々は
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか
って記事が出て(これはこれで目から鱗だったのだけど)
そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか
という突っ込みを経て
ロードバランサの運用.DSRって知ってますか?
DNSラウンドロビンとmod_proxy_balancerによるWebサイトの負荷分散（案）
という発展を見せてます。
リアルの仕事でもロードバランサーは頻繁に使うのだけどこれまではBIG-IPなどのハードウェアで対処してます。
つまり「リッチ・エンジニアリング」だったのだけど、ソフトウェアで手軽に担保できるのならそれに越したことはない！
実はずっと以前にソフトで対応できないか調べて挫折した経緯があり、果たしてこの2006年現在で、ソフトウェアによるロードバランシングが使えるレベルなのかどうか、ちょっと考えてみる。
因みに何一つ実際には試してませんので、そのつもりで。

多分「ロードバランシング」「負荷分散」って言葉はケースバイケースで要件が違ったり、包含する範囲が変わったりして、割と幅広く使われる言葉だと思う。
ここで、僕の場合は主に次のような要件を求めることが多い。
1. ロードバランシング方法としてはリクエスト回数でランダムに分散してくれればそれでよし。別にサーバー個別の負荷とかは測らなくてもいい。でも重み付けは念のために欲しいかな(性能の違うサーバーを追加しないといけない場合対策)。
2. BIG-IPで言えば「Cookie Sticky」が欲しい。つまりログインしたりしたユーザーが次回以降Cookie値を見て常に同じサーバーにアクセスされるようにしたい。でないと、特に何の対策もしていない場合、他のサーバーに振られるとログイン・エラーなどになってしまうから。携帯アクセスを考えるとCookieだけではなく、URLパラメータに付加された値を見ることが必要になる。
3. HTTPS対応
4. フェイル・オーバー機能は当然必須。つまりサーバーのヘルスチェック機能を持っていて欲しい。
5. Sorryサーバー機能も欲しい。メンテナンス時などに便利。
6. GUI管理機能は欲しい。設定時は別に要らないけど、通常の管理時などに、例えばそれぞれのサーバーにどのようにリクエストが振られたとか、サーバーがダウンしているとかの統計情報は気軽に使いたい。
大体これだけ挙げた時点でソフトウェア向きじゃないのかも知れないけど、まあとりあえず。
先の記事を読み耽ると、簡単に言って2パターンに分けられますね。
1. L7スイッチパターン。LBがHTTPを解釈してHTTPレベルで負荷分散。必然的にLBがSSLアクセラレータを兼ねる事になる。多分これが素直に出来れば一番いい。
2. L4スイッチパターン。LBはIPまたはPort番号まで解釈して、リクエストをそのままリアルサーバーへ負荷分散する。
1パターンの代表格がApache2.2 + mod_proxy_balancerでしょうか。
次のような解説記事を見つけました。
Apache モジュール mod_proxy_balancer
Apache 2.2.0 のロードバランス機能(mod_proxy_balancer)を使いこなす
ついでにはてブ。
よさげに見えるんですが、stickysession機能が微妙？Cookie値によって振り分けられるサーバーが決定されるということですが、これ、わざわざアプリケーションの方でCookieにその値を入れないとダメなんでしょうか。
だとすると2が満たせません。簡易すぎて、ちょっと使えないかなぁ。
因みにBIG-IPだと、BIG-IP自身がHTTPヘッダーに介入して上記のような独自Cookieを挿入してそれで振り分けを行います。という意味でもないのかなぁ。
他にPOUND、mod_backhand なんかも挙げられていますが、少し調べたけどまだよく分からないな。むーん。
UltraMonkey-L7ってのもあるみたいですが、これNTTコムウェアのOSS製品なんですね。Seesaa2と同じ香りがどうもな。
L7パターンだとあまり選択肢は無いのかも。
L4パターンが世間では一番一般的に見えるんだけど、僕からすると幾つか面倒な問題がある気がします。
■ 各リアルサーバーそれぞれでSSL証明書をインストールしないといけない
これはLBがSSLアクセラレータとしては動作してくれないからです。各サーバーをSSL化する必要があります。サーバー台数が増えると結構大変。各証明書の有効期限が微妙にずれていたりすると結構悲惨・・。
■Cookie Stickyがそのままでは出来ない
これが一番の問題かな。
仕方が無いので、Tomcatのクラスタリングを使ったり、アプリケーションを変更してDBにセッション情報を格納するとかしてセッションを各リアルサーバー間で共有しないといけない、と。
■速度を求めてDSRを使おうとすると、リアルサーバーにGlobal-IPが必要になるか、または各リアルサーバーにIP Alias or iptablesの設定が必要らしい
これはこれで面倒・・。Global-IP必須というのは問題外としても、IP Aliasで逃げると、後で構成変更などでVIPが変わった時に全台変更が必要なのは面倒・・。
■L4レベルでヘルスチェックされてもなぁ。ポートが開いてるだけでOKになっちゃうんでしょ？
と、思ってたんですが、LVSのKeepalivedで可能っぽいですね。
全般に、L4パターンにしてしまうといい意味でのバーチャルさが損なわれてしまうのが一番のネックに思います。
ということで僕個人としては、恐らくL4パターンだとランニングコスト面などが不安で結局はハードウェア導入した方が手間無く安くあがるんでは？とか感じます。
もっとも、元々コストをかけられない環境ならたとえL4パターンであろうと人海戦術その他でさくっと出来てしまうんでしょうけどね。
個人的にはL7スイッチパターンがもう少し進歩してくれることに期待したいと思います。
でも、せっかくだからちょっと使ってみようかな・・？