クラスタは何台までOK？―性能から見たWebLogicクラスタの適正台数―：事例に学ぶWebシステム開発のワンポイント（3）

本連載では、現場でのエンジニアの経験から得られた、アプリケーション・サーバをベースとしたWebシステム開発における注意点やヒントについて解説する。巷のドキュメントではなかなか得られない貴重なノウハウが散りばめられている。読者の問題解決や今後システムを開発する際の参考として大いに活用していただきたい。（編集局）

[重畠洋二，（株）NTTデータ] PC用表示関連情報

LINE

Hatena

今回のワンポイント

クラスタのオーバーヘッドは、Webシステムのパフォーマンスに性能にどのように影響を与えるのか意外に知られていない。クラスタの効果をフルに発揮するためには、そのオーバーヘッドの中身を知ること、実際に測定を行ってノウハウを蓄積することが重要だ。今回は、WebLogicを使った場合の最適な構成について解説する。

理想的なクラスタ構成が分からない

　一般的に、クラスタ化を行えば可用性は向上する。しかし、それに伴うオーバーヘッドも発生する。その場合、1台当たりの処理能力の低下が気になるところである。というのも、あるコンシューマ向けの大規模Webシステムにおいて、4台のWebLogicを1つのクラスタとして構成しても大丈夫かという疑問が起こったためである。日本BEAシステムズに相談したところ、当時4台のWebLogicを1クラスタとした実績はなかった。サービス開始時期を考慮し、いままでの実績から2台ずつの2クラスタ構成で構築することにした。

4台で1クラスタを構成するのではなく、2台で1クラスタを構成し、それを2クラスタ用意した

　2台×2クラスタで、そのシステムは無事に稼働したものの、本当は1クラスタ当たりどの程度の台数が望ましいのか気になるところである。そこで、WebLogicでのクラスタについて、詳細に調べてみることにした。

WebLogicクラスタによるオーバーヘッドとは何か？

　クラスタ化することによりオーバーヘッドは発生するのだろうか。クラスタ化すると何が起こるのかを理解し、何がオーバーヘッドになるかを考えてみた※1。

※1：ここではWebLogic Server 5.1を対象としている。

（1）HttpSessionのレプリケーション

　Servlet、JSPのクラスタにおいては、同一クラスタ内のWebLogic間でHttpSessionの情報がレプリケートされる。この機能により、1台のWebLogicがダウンしてもHttpSessionの情報をレプリケートしたWebLogicで処理を継続することが可能となる。このレプリケーションは、クラスタに属するWebLogicが何台あろうとも、そのうちの2台がペアとなって行っている。

　注意してほしいのは、クラスタに属するほかのWebLogicすべてにレプリケーションしているわけではないという点である（リクエストごとに任意の2台がペアとして決定される）。このため、クラスタを構成する台数が増えたとしても、HttpSessionのレプリケーションがオーバーヘッドになるとは考えられない。

（2）生存確認

　HttpSessionのレプリケートを行うにも、相手のWebLogicがきちんと動作していなければならない。それをチェックするのが、生存確認である。生存確認のために、10秒間隔でIPマルチキャストを用いて通信を行っている。ただし、パケットサイズは大きくなく、これもオーバーヘッドにはなるとは考えられなかった※2。

※2：ちなみに、このIPマルチキャストが3回NGとなるとクラスタとして認識されなくなるので、IPマルチキャストのネットワークの信頼性についても考慮しておく必要がある。

（3）サーバ情報のコピー

　同一クラスタ内にWebLogicサーバが起動されると、クラスタメンバの追加の通知やJNDIの情報（EJB名など）の交換が、IPマルチキャストを用いてやりとりされる。例えば、2台のマシン（サーバA、サーバB）がクラスタ構成で起動している状態で、さらにもう1台のマシン（サーバC）が起動された場合は、次のようなやりとりが行われる。

サーバ間での情報のコピーがオーバーヘッドに

　サーバCからの「起動通知」や「サーバ情報の通知」は、サーバごとに送信しているわけではないものの、「構成情報の変更」はサーバごとに送られている。このため、クラスタ構成台数が増加すると、この部分がオーバーヘッドになる可能性が考えられた。ただし、これはWebLogicが起動されたときに発生するだけなので、定常運用中のオーバーヘッドにはなり得ないものと結論付けられた。

本当は何台が望ましいのか

　以上、WebLogicのクラスタ時の動作を見てみたが、論理的にはクラスタを構成する台数が増えてもオーバーヘッドはなさそうに思える。しかし、実装レベルにおいて内部的に競合などが発生し、1台当たりの処理能力が低下するといったことはよくあることである。そこで、テストアプリケーションを用いてスループット測定を行った。測定に使用したアプリケーションは、TPC-Wベンチマークに基づき、われわれが実装したアプリケーションである。

クラスタは4台目からスループットが落ちる

　測定した結果、同一クラスタ内のWebLogicの台数が増加するほど、1台当たりのスループットが低下していることが分かった。そして、4台で構成した場合は、クラスタ全体でのスループットが3台で構成した場合よりも低い結果となった。

　では、4台のWebLogicを2台×2クラスタとするとどうなるのか、というところが気になる。このパターンについても測定を行った結果、2台で構成したクラスタの2倍の性能が出た。結局、WebLogic4台を1クラスタとして構成するよりも、2台×2クラスタとして構成した方が、全体のスループットが高いということになった。

複数のクラスタを組み合わせるのがよい

　WebLogicのクラスタについて、今回は性能という切り口で見てみた。複数のWebLogicでクラスタを構成することにより、可用性を向上させることができる。しかし、台数が増加するほど、1台当たりの処理能力が低下することを認識しなければならない。

　そして、多くの台数のWebLogicでクラスタを構築しなければならないときは、

1クラスタ当たり2台または3台で
複数のクラスタを構成

という構成が理想的であることがわかった。

著者プロフィール

重畠洋二（しげはたようじ）

株式会社NTTデータCOEシステム本部に所属。技術支援グループとして、J2EEをベースにしたWebシステム開発プロジェクトを対象に、技術サポートを行っている。

「次回」へ

「事例に学ぶWebシステム開発のワンポイント」バックナンバー