検証作業が明らかにした「WebLogic＋仮想化」の
潜在力・前編

≫ HP-UX 11i
Knowledge-on-Demand

≫コラム

≫連載
≫特集、特別企画

ドキュメント/ツール

HPラボ

≫Webキャスト

関連情報

≫HP-UX
- ≫各種ソフトウェア

≫日本HPサイトマップ

BEAシステムズの「WebLogic Server」は、市場でもっとも大きな成功を収めたJ2EEアプリケーション・サーバである。しかし、たとえWebLogic Serverをもってしても、ハードウェアの限界を超える負荷が集中すれば、サービスのレスポンスは低下してしまう。そこで、もし「ハードウェアの性能をソフトウェアから自由に制御できる環境」が存在すれば、これまでアプリケーション・サーバをとらえてきたハードウェアの呪縛を解くことができる。それを可能にするのが、仮想化技術である。今回は、HP BEAコンピテンス・センタとHP Oracle ソリューション・センタの共同検証結果をもとに、HPの仮想化技術がWebLogic Serverの潜在力をどの程度まで引き出せるかレポートしたい。

検証作業が明らかにした「WebLogic＋仮想化」の潜在力・前編

≫	WebLogicの呪縛を仮想化技術が解放する
≫	オンラインショッピングのシナリオ

2005年8月

テクニカルライター　吉川和巳

	WebLogicの呪縛を仮想化技術が解放する



	図 1：BEA WebLogic Server

BEAシステムズの「WebLogic Server」は、市場でもっとも大きな成功を収めたJ2EEアプリケーション・サーバである(図1)。国外はもとより、国内でも大手都市銀行や証券会社、携帯電話会社、鉄道、放送局、コンビニエンスストアなどの基幹系を支えるミドルウェアとして、業界標準の地位を確立した。オープンシステムとJavaの組み合わせがメインフレームを十分に代替できることを示した功績は大きい。

WebLogic Serverのようなアプリケーション・サーバの役割は、ユーザから集まる大量のリクエストをさばき、ハードウェアの能力を最大限に引き出しつつ、個々のトランザクションを確実に実行すること。しかし、いかに優秀なアプリケーション・サーバ製品でも、ハードウェアの限界を超える性能は達成できない。例えば、あらかじめ用意されたCPUリソースを上回る負荷が集中すれば、たとえWebLogic Serverをもってしても、サービスのレスポンスは低下してしまう。

しかし、もし「ハードウェアの性能をソフトウェアから自由に制御できる環境」が存在すれば、これまでアプリケーション・サーバをとらえてきたハードウェアの呪縛を解くことができる。それを可能にするのが、メインフレームで生まれオープンシステムで開花しつつある仮想化技術である。例えば、WebLogic Serverに供給するCPUリソースを仮想化し、負荷状況に応じてリアルタイムに増減させることで、上述したようなレスポンス低下を抑えて高い可用性を実現できる。こうしたアプリケーション・サーバと仮想化技術の組み合わせは、ポスト・メインフレーム時代の新しい基幹系のあり方を提示している。

	日本BEA＋日本HPによる共同検証



	図 2：HP BEA コンピテンス・センター

日本BEAと日本HPでは、両社のエンジニアによる共同検証のための施設を整えた「HP BEAコンピテンス・センター」を日本HPの市ヶ谷事務所に常設している(図2)。今回、同センターのHP-UX技術者は、WebLogic ServerとHPの仮想化技術のコンビネーションによるパフォーマンス検証テストを実施した。そこで以下では、この検証作業のいきさつを紹介し、仮想化技術がアプリケーション・サーバの潜在力をどの程度まで引き出せるかレポートしたい。

今回の検証では、以下のようなビジネスシナリオが設定された。

WebLogic Serverで構築されたオンラインショッピングサイト
お客様は「一般ユーザ」と「プレミアユーザ」の2種類
各ユーザのサービス需要予測は困難
混雑時には一般ユーザよりもプレミアユーザに優先的にサービスを提供したい

これらのうち、今回の検証のポイントは、最後の「混雑時には一般ユーザよりもプレミアユーザに優先的にサービスを提供したい」という要件である。一般ユーザとプレミアユーザを同じハードウェアで収容すると、サイト混雑時にはプレミアユーザのサービスレベル低下が避けられない。とはいえ、各ユーザのサービス需要予測は困難なため、一般ユーザとプレミアユーザを個別のサーバに分けるのはムダが多すぎる。そこで、同じハードウェアで両ユーザをサポートしつつも、仮想化技術による動的なワークロード分配を使い、プレミアユーザには一定のサービスレベルを確保することは可能か――というのが、今回の検証作業の趣旨である。

	検証用システムの構成

図3は、今回の検証作業に使用されたシステム構成である。

図 3：検証用システムの構成

検証用に用意されたハードウェアは、32個のインテル®Itanium® プロセッサーを搭載したハイエンドサーバ、HP Integrity Superdomeである。同サーバをnPartitionsと呼ばれるハードウェアパーティションによりnPar0からnPar2までの3つに分割、それぞれに8個のItaniumと32GBメモリを割り当てた。これら3つのパーティションは、各自が完全に独立した1台のサーバとして動作する。なお、各パーティション間は1000Base-TXスイッチで結んでいる。



	図 4：nPar1のアプリケーション・サーバ構成

図3に示したとおり、nPar0は負荷生成用クライアントとして使用し、日本HPが作成した負荷生成ソフトウェアを動作させる。一方、nPar1はテスト対象のアプリケーション・サーバとして使用し、BEA WebLogic Server 8.1 SP4と日本HP作成のテスト用J2EEアプリケーションを搭載する。そしてnPar2には、データベースサーバとしてOracle 10g Enterprise Editionをインストールした。

nPar1のアプリケーション・サーバの構成をもう少し詳しく見ていこう。図4は、nPar1内部のWebLogic Serverの配置を示した図である。

nPar1の内部では、一般ユーザ用とプレミアユーザ用の合計2つのWebLogic Serverインスタンスが動作し、8個のCPUを共有している。また両インスタンスは、nPar2のOracleデータベースを共有する構成である。