Jump to content 日本-日本語

製品 >  ソフトウェア >  HP- UX Developer Edge 

J2EEサーバ、スケーラビリティと可用性の「現実」

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
J2EEサーバ、スケーラビリティと可用性の「現実」
スケーラビリティと可用性は、J2EEアプリケーション・サーバ(J2EEサーバ)の能力を測る重要な指標である。しかし、実はこの両者は、互いに相反する関係にある。例えば、サーブレットやEJBを利用したWebアプリケーションでは、ショッピング・カート内容などのWebブラウザとの更新履歴を「セッション情報」として保持する方法が一般的だ。セッション情報の可用性を高めるには、クラスタ上のノード間でセッション情報をコピーする「レプリケーション」が必要となる。このレプリケーションによって大量のノード間通信が発生すると、ネットワークがボトルネックとなりクラスタ全体のスケーラビリティが低下してしまうのである。ここでは、オラクルが提供する「Oracle Application Server(OAS)」を対象に実施されたラボ・テスト結果を検証し、J2EEサーバのスケーラビリティと可用性の「現実」を明らかにする。
J2EEサーバ、スケーラビリティと可用性の「現実」
スケーラビリティと可用性
レプリケーションは諸刃の剣
レプリケーション専用LANの効果
2004年3月
テクニカルライター:吉川 和巳

スケーラビリティと可用性


J2EEアプリケーション・サーバ(J2EEサーバ)のクラスタリングには、2つの目的がある。1つは、スケーラビリティの向上である。具体的には、システム全体にかかる負荷をクラスタ上の各サーバに分散させ、従来のクライアント・サーバ・システム(C/Sシステム)のように全負荷が1台のサーバに集中するような状況を防ぐ。これにより、クラスタ内のサーバ数を増やすことでシステム規模を拡張できる、いわゆる「スケールアウト」が実現する。もう1つの目的は、可用性(Availability)の確保である。例えば、クラスタ上のあるサーバがダウンした場合でも、他のサーバがその役割を肩代わりできる仕組みを実装する。こうした「フェイル・オーバー」のメカニズムにより、システム全体の運用を止めることなく継続できるのである。

Oracle Application Serverでクラスタ構築


これら2つのメカニズムについて、具体的な製品の例を用いて説明しよう。図1は、オラクルが提供するJ2EEサーバ「Oracle Application Server(OAS)」内部で動作するコンポーネントを示した図である。ここで示したとおり、OASは、「OHS(Oracle HTTP Server)」および「OC4J」と呼ばれる2つの主要なコンポーネントにより構成されている。前者のOHSは、ApacheベースのHTTPサーバであり、HTTPリクエストをOC4Jに転送する。一方のOC4Jは、オラクルが開発したJ2EE実行環境である。OHSが受信したHTTPリクエストはOC4Jに転送され、その内部で動作するJavaサーブレットやEnterprise JavaBeans(EJB)などによって処理されることになる。
ここで、このOHSとOC4Jの間が、「mod_oc4j」と呼ばれるモジュールによって結ばれていることに注目していただきたい。mod_oc4jは、オラクルが独自に開発したApacheモジュールであり、クラスタ内の全てのOC4Jに対して負荷分散を実行する能力を備えている。通常のロードバランサーに加え、このmod_oc4jによる負荷分散によって、OASで構築されたクラスタ全体で安定したスケーラビリティが得られる仕組みである。
また、OASで構築されたクラスタの可用性は、個々のOC4J間で実施される「レプリケーション」によって確保される。クラスタ内のOC4Jは、UDPもしくはIPマルチキャストを通じて互いにデータをコピーし合うことで、いずれかのOC4Jがダウンした場合でもデータが失われないようなメカニズムを実現している。
 
図1:「Oracle Application Server(OAS)」内部で動作するコンポーネント
  図1:「Oracle Application Server(OAS)」内部で動作するコンポーネント

ステートレスかステートフルか


だが、こうしたレプリケーションによる可用性の確保は、「ステートレスな設計」と「ステートフルな設計」という2種類のアプローチのどちらをクラスタ構築に採用するかによって、その重要性が大きく変化する。
ステートレスな設計とは、J2EEサーバが「ステート(状態)」を一切保持しない設計のことであり、TuxedoなどのTPモニタによるOLTPシステムでは一般的な構成である。この場合、ECサイトにおけるショッピング・カート内容やユーザのログイン状態などのセッション情報は、全てクライアント(Webブラウザ)もしくはデータベースに保持することになる。
 この設計では、いずれかのJ2EEサーバがダウンしたとしても、他のサーバが瞬時に肩代わりでき、高い可用性が得られる。また、リクエストを全てのJ2EEサーバに均等に分散させることも容易だ。ただし、デメリットも少なくない。Webブラウザ側で保持できるセッション情報には、セキュリティやサイズ上の制約が多い。よって、セッション情報の大部分は、ユーザのマウスクリックのたびにデータベースに書き込む必要がある。すると、システム全体の負荷がデータベースにダイレクトに集中し、またストアド・プロシージャへの依存度も自然と高まる。結果的に、従来のC/Sシステムと変わらぬ様態となり、J2EEサーバによるクラスタ構築の意義が失われてしまうのである。
これに対し、ステートフルな設計では、カート内容やログイン状態などを個々のJ2EEサーバ上に保持する。具体的には、Javaサーブレットのセッション・オブジェクト(HttpSessionオブジェクト)や、EJBのステートフルSessionBeanを利用し、ユーザがログアウトするかタイムアウトするまでの間、セッション情報をJ2EEサーバのメモリ内部に保管する。
この場合、J2EEサーバのリソースを多く消費するため、収容可能な同時セッション数につねに気を配る必要がある。また、ロードバランサーに対してスティッキー・セッション(セッション・アフィニティ)を設定し、WebブラウザとJ2EEサーバの1対1の対応付けを維持しなくてはならない。そうした面倒さの一方で、セッション情報をデータベースのキャッシュとして利用することで、多大なメリットが得られる。ECサイトの例で言えば、ユーザのログイン状態(認証結果)やアクセス権、カート内容などをデータベースに毎回問い合わせる必要がない。すなわち、リクエストの大部分をデータベースに頼らず処理できるため、スケーラビリティの向上というクラスタリング本来の目的を果たせるのである。
トップへ   次のページへ

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項