 |
|
| 事例編〜Web 2.0サービスの中を見せます |
第５回：サーバの追加とロードバランシング
著者：はてな 伊藤 直也 2006/10/30
|
|
|
| 1 2 次のページ
|
|
| Webサーバーの追加とロードバランシング
|
さて、サービスがオープンしてしばらく経ってくるとトラフィックも増えて、アプリケーションサーバーの負荷が高くなってくることでしょう。そこで、アプリケーションサーバーを増やすことになります。同じ構成のアプリケーションサーバーをもう一台作って対応します。
ここでふと気づくわけですが、Webサーバーがproxy×1＋mod_perl×1の場合は、クライアントから受け付けたリクエストを振り分けて処理するといったことは意識する必要がありませんでした。
しかし、proxy×1＋mod_perl×2になると、リクエストを受け取ったリバースproxy側では、どちらのアプリケーションサーバーにリクエストを転送するかを考慮する、つまりロードバランシングをする必要が出てきます。
|
| mod_proxy_balancerでロードバランシング |
結論から言うと、ロードバランシングもリバースproxyでやってしまうことができます。
Apache 2.2にはmod_proxy_balancerというロードバランシング用のモジュールが標準パッケージに含まれています。これを利用しない手はありません。その扱いも非常に簡単です。
はてなブックマークでは、オープンした当初はApache 2.2が安定版ではなかったため、Apache 2.0でmod_rewriteの機能を使って工夫していました。いまはリバースproxyを2.2に置き換え、ロードバランシングにはmod_proxy_balancerを利用しています。
なおmod_proxy_balancerは単にリクエストの振り分けを行うだけでなく、バックエンドのサーバーが故障などで応答しなくなった場合それを検知して、生きているサーバーにだけ振り分けを行うフェイルオーバーの機能があったり、バックエンドサーバー群の生存確認を行うための簡単な管理ツールが付属していたりもします。
|
1 2 次のページ
|
|
|
|
著者プロフィール
株式会社はてな 伊藤 直也
取締役最高技術責任者
ブログサービスやソーシャルブックマークなど、はてなの各種サービスの企画、開発を行う。著書に「BlogHacks」（オライリージャパン刊）。「続・初めてのPerl」(オライリージャパン）、「Perl救命病棟」(翔泳社刊）では監訳を務めた。
|
|
|
|
|
|
