シリーズ連載
止まらないWebシステム構築の基礎知識

清水徳雄
日本BEAシステムズ
プロフェッショナル・サービス
2001/10/12

Javaアプリケーション・サーバを使った大規模なWebシステム構築案件が増えていく中で、顧客に対し24時間365日の安定したサービスを提供すること、将来のスケーラビリティを保障することなどが重要になってきている。本連載では、Webシステムのコンサルティングや開発を手がけるコンサルタントやエンジニアに、止まらないWebシステム構築を考える上で必要となる基礎知識を解説する。第１回は、アプリケーション・サーバ側で行うクラスタリング機能について、WebLogic Serverの機能を例にあげながら、日本BEAシステムズの清水徳雄氏に紹介していただく。（編集局）

第2回　目的に応じたクラスタ構成を考える

　第1回では、WebLogic Serverにおけるクラスタリングの概念を説明しました。第2回では、前回を踏まえてアプリケーション・サーバでのクラスタに着目し、現実のシステムでクラスタをどう構成するかを説明します。

■EJB Container層のクラスタリング

　実際のケースとしては少ないのですが、LAN環境内での使用を前提にEJB Container層だけでクラスタリングをしたい場合があります。ご存じのとおり、EJBへのアクセスはJNDIからHomeオブジェクトを取得することから始めます。クラスタ環境では、JNDIのInitialContextを取得するサーバを固定してしまっては意味がありません。そのサーバがダウンしているかもしれないからです。従って、InitialContextの取得先の負荷分散とフェイルオーバーの仕組みが必要になるわけです。

　InitialContext取得先の負荷分散とフェイルオーバーは、DNSラウンドロビンの仕組みを使用するのが一般的です。InitialContextを取得する際に指定する接続先のURLに、クラスタへ割り当てたDNS名を与えます。DNSがない環境では、DNS名の代わりに以下のようなURLを与えることで相等の機能を実現できますが、実運用環境での使用は推奨していません。

t3://servera,serverb,serverc:port

　EJB Container層だけでクラスタリングする場合は、次のようなシンプルな構成になります。

図１ EJB Container層でクラスタリングを実現する構成

■Web Container層のクラスタリング

　第1回で説明したとおり、Web Container層のクラスタリングではWebLogic Serverの前にProxyを配置する必要があります。また、セキュリティに関しても配慮する必要があるなど、関連する要素が多いため構成パターンもいくつか考えられます。

●Proxyとアプリケーションサーバを同じマシンに配置
　最初に、最もシンプルかつ安価な構成としてProxyとWebLogic Serverを同じマシンに配置するパターンを紹介します。

図2 Web Container層のクラスタリング：Proxyとアプリケーションサーバを同じマシンに配置する構成

　もちろん、Proxyを別のサーバに配置してもよいのですが、より多くのサーバ・マシンが必要となりコスト的な負担が大きくなりますので、小規模なシステムではこのような構成を取るのがよいでしょう。2台のサーバで同時に障害が発生する可能性を無視できるとすれば、上図のように最低限2台のサーバ・マシンでクラスタを構成し高可用性を実現することができます。必要とするサーバ台数が少ないので、運用管理のポイントが少ないのもこの構成のメリットです。

●Proxyとアプリケーションサーバを別マシンに配置
　次のようなケースでは、ProxyとWebLogic Serverを別々のマシンに配置してクラスタを構成します。

(1)	既存のコンテンツを配信しているWebサーバを継続して運用しつつ、WebLogic Server のコンテンツを追加したい
(2)	セキュリティ上の理由からProxyだけをDMZに配置したい

　ProxyをWebLogic Serverを別のマシンに配置する構成は次の図のようになります。

図3 Web Container層のクラスタリング：Proxyとアプリケーションサーバを別マシンに配置する構成

　この構成であれば、既存のWebサーバにPlug-inを適用してProxyを兼任させることもできるわけです。静的なコンテンツ（特に画像など）をProxyに置いて配信させることにより、Web Container層の中でさらに負荷分散を図ることができるのもこの構成のメリットです。

●Web Container層とEJB Container層とを分離
　Web Container層とEJB Container層とを別々のマシンに配置するケースもあります。この場合は、次の図のようにWeb Container層とEJB Container層とでそれぞれクラスタを構成することになります。

図4 Web Container層とEJB Container層とを分離した構成（クリックで拡大します）

　この構成のメリットは以下のとおりです。

(1)	Web Container層からEJB Container層の呼び出しをロードバランスさせることができます（Web Container層とEJB Container層を1つのWebLogic Serverに同居させた場合、Web Container層からのEJB呼び出しは必ずローカル・サーバ内のEJBへルーティングされます）
(2)	Web Container層とEJB Container層とで水平方向の負荷分散を行うことができます。Proxyまで含めると全体として以下のような負荷分散を提供できます Proxy： 静的コンテンツの配信 Web Container層： 動的コンテンツの生成 EJB Container層： ビジネス・ロジックの処理 それぞれの層でスケーラビリティーを提供することができます。例えば、Web Container層の処理に比べてEJB Container層の処理が非常に重たい場合、EJB Container層にだけサーバを追加してシステム性能を改善するといったことが可能になります

　ここで注意していただきたいのですが、「Web Container層とEJB Container層とを分離する」といっても、Web Container層だけ、あるいは、EJB Container層だけでWebLogic Serverを起動することができるわけではありません。この「分離」は、アプリケーション・コンポーネントを選択的にデプロイすることによって行います。図４でいえば、Web Container層のクラスタにはWeb Applicationだけをデプロイし、EJB Container層のクラスタにはEJBだけをデプロイします。この応用として、Web Container層に一部のEJBをデプロイして、ある種の処理ではこのローカルのEJBを呼び出し、そのほかの処理ではバックエンドのEJB Container層を呼び出すといった使い分けを行うこともできます。

　また、この構成ではEJB呼び出しのパーティショニングを実現することもできます。例えば、一部のプレミア・カスタマーの処理は高性能なサーバに振り分け、ほかの一般カスタマーはカスタマーIDでパーティショニングして中程度の性能のサーバに振り分けるといったことが可能になります。このようなEJB呼び出しのパーティショニングは、EJBのクライアント・スタブが使用するCallRouterインターフェイスをカスタマイズすることによって行います。CallRouterインターフェイスに関しては次のURLを参照ください（WebLogic 5.1／WebLogic 6.0／WebLogic 6.1）。

　この構成の最大のデメリットは、Web Container層からEJB Container層を呼び出す際のネットワーク・オーバーヘッドにあります。このため、先に挙げたメリットが最優先される場合を除いて、この構成を採用することはほとんどありません。採用に当たっては、フィージビイリティー・スタディーなどで事前に十分な検証を行うようお勧めします。

●セキュリティを考慮した構成
　上記の構成パターンについて、さらにセキュリティを考慮したのが以下の図です。

図5 セキュリティを考慮した構成例（その1）　（クリックで拡大します）

図6 セキュリティを考慮した構成例（その2）　（クリックで拡大します）

　これらの図はおおまかな接続例にすぎませんので、要求されるセキュリティ・レベル、冗長度、コストなど勘案して詳細を決定してください。

■JDBCコネクション・プールのフェイルオーバー

　第1回、第2回を通じて、ここまでアプリケーション・サーバのクラスタリングを解説してきましたが、特に高可用性を考えた場合、アプリケーション・サーバとRDBMSとのコネクション・プールについてもフェイルオーバーの仕組みを考えておかなければなりません。これは、クラスタ／非クラスタ環境を問わず検討すべき問題です。本稿の締めくくりとして、永続化層 (RDBMS)との接続であるJDBCコネクション・プールのフェイルオーバーについて解説します。

　JDBCコネクション・プールのフェイルオーバーは、アプリケーション・サーバ側だけではなくRDBMS側の機能との関係もあるので、RDBMS製品ごとに対応方法を考える必要があります。ここではOracleとの接続を例に説明します。なお、RDBMS自身の高可用性（2重化など）については各製品のマニュアルを参照ください。

　WebLogic Serverでは、JDBCコネクション・プールでプール内のコネクションをチェックする仕組みを提供しています。チェックは、RDBMSに対してダミーのSQL文を呼び出して行います。チェック用のテーブル名やSQL文はJDBCコネクション・プールのコンフィグレーションで設定します。Oracleの場合は、“SELECT * FROM DUAL”というSQL文でチェックするのが定石です。

　コネクションのチェックは以下のタイミングで行うことができます。

• 一定のインターバル
  
• プールからコネクションを取得する（getConnection時）
  
• 使用し終わったコネクションをプールに返す（close時）

　タイミングの設定は、いずれか1つだけを選択することも、組み合わせて使用することもできます。一定インターバルか取得時・返還時のいずれか一方だけ、あるいはこの両方のタイミングでチェックするよう設定するのが一般的です。プールからコネクションを取得する際にチェックを行うのが最も確実な方法ですが、getConnectionのたびにチェック用SQL文の実行というオーバーヘッドを伴う点に注意してください。

　WebLogic Serverはプールされたコネクションのチェックに失敗すると、そのコネクションを破棄して新たなコネクションを作り直そうとします。OracleをHA構成にしておけばチェックのタイミングで障害を検知し、待機系に再接続して処理を続行することができます。

　HA構成を取っていない場合でも、この仕組みを使用すればOracleが復旧し次第、自動的にコネクションを再生成して処理を再開することができます。この場合リカバリに要する時間はチェック・タイミングの設定に依存します。一定インターバルの場合は、RDBMS 復旧後最大でチェック・インターバル時間のタイムラグが発生する可能性があります。取得時にチェックするよう設定しておけば、復旧後アプリケーションの最初のDBアクセスでコネクションが再生成されますので、その時点ですぐ処理を再開することができます。コマンドラインあるいはAPIでJDBCコネクション・プールをリセットするインターフェイスが提供されていますので、非HA構成の場合はこれを利用するのも1つの方法です。

　WebLogic Serverが提供するこれらの機能を使ったとしても、チェックのタイミングは最善でコネクション取得時となります。従って、いったんコネクションの取得に成功した後、そのコネクションの使用中にRDBMSに障害が発生した場合は、自動的なフェイルオーバーは行われません。こういったケースを救済する必要がある場合は、アプリケーション側でエラーを検知してリトライするようにプログラミングしておかなければなりません。

　WebLogic Server 6.Xでは、さらにマルチプール（MultiPool）と呼ばれる機能が追加されています。これは、「JDBCコネクション・プールのプール」として機能するもので、設定する際にコネクション・プール名のリストを与えます。マルチプールのコンフィグレーションでは、「高可用性（High Availability）」か「ロードバランス（Load Balance）」のいずれかを選択することができます。

高可用性 （High availability）	リストの先頭のプールをプライマリとして扱います。プライマリのプールに障害が発生した場合は、リストの次のプールを使用してフェイルオーバーします
ロードバランス (Load Balance)	リスト内のプールに対して負荷分散を行います。複数のプールをラウンドロビンで順番に使用し、RDBMS に対する負荷分散を行う仕組みになっています

　一般的に、前者は本番系／待機系でRDBMSを2重化した構成を前提とした機能、後者はリアルタイムにレプリケートされたRDBMSクラスタを前提とした機能といえます。

　以上、アプリケーション・サーバを中心に、フロントとなるProxyからバックエンドのDBサーバまで、クラスタリングに関する解説をお届けしました。

　最後に、WebLogic Serverのクラスタリングに関連するURLをお伝えしておきます。詳細に関してはこちらを参照ください。

クラスタリング全般	WebLogic 5.1／WebLogic 6.0／WebLogic 6.1
Apache Plug-in	WebLogic 5.1／WebLogic 6.0／WebLogic 6.1
NSAPI (NES/iPlanet) Plug-in	WebLogic 5.1／WebLogic 6.0／WebLogic 6.1
ISAPI (IIS) Plug-in	WebLogic 5.1／WebLogic 6.0／WebLogic 6.1
JDBC Connection Pool	WebLogic 5.1／WebLogic 6.0／WebLogic 6.1
MultiPool	WebLogic 6.0／WebLogic 6.1

◆

　次回は、高トランザクションに耐えるWebシステムを構築するための、負荷テストツールの活用について紹介します。

連載記事一覧

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）