WebLogicとEPICアーキテクチャが Javaの最高パフォーマンスを発揮

ネットの高速化と高まるユーザー要求

　日本国内のブロードバンド環境の整備と利用は、いまや世界最高の水準に達しつつある。2002年末の時点で、インターネット利用者に占めるブロードバンド利用人口は28.2％とされ、インターネット利用者の4人に1人がブロードバンドを利用していることになる。そして、将来のブロードバンド利用人口をブロードバンド契約数の推移等に基づき予測すると、2007年にはインターネット利用人口の67.1％がブロードバンドを利用していることになるという（出典：総務省「平成15年度 情報通信白書」）。

　すなわち、ブロードバンド利用者数がナローバンド利用者数を逆転する日は近い。そうなったときに、現在のサーバプラットフォームは予期せぬ負荷の増大に対応できるだろうか？ しかも、今後インターネットコンテンツは動画を含んだよりリッチでデータ量が多いものになっていく。さらに、これまでリアルビジネスで提供されていたさまざまなサービスがインターネット上へのサービスへと移行していく可能性も大きい。将来のサーバプラットフォームに求められる性能は未知数であり、可能な限り、より高性能なサーバ、そして、より高速にアプリケーションを実行できるミドルウェア・プラットフォームが要求されている。「8秒ルール」は、もはや過去の要件となりつつある。いまや3秒でも遅いとされる事例が出てきている。サイジングの見直しの要求に備える必要があるのだ。

高まる要求に応える次世代CPUアーキテクチャ「EPIC」

Itanium2プロセッサ

　サーバへの性能要求が指数関数的に伸びている状況に、もはやCPUの追加やスケールアウトなどの手法では応えられない。サーバそのものをより高速化する必要が出てくる。この要求に応えたのがインテルのItanium2プロセッサだ。Itanium2プロセッサがもつEPICアーキテクチャは、HPとインテルが共同開発した、IA-64アーキテクチャにおける並列実行技術である。

　EPICアーキテクチャを、これまで高速とされていたRISCプロセッサのスーパースカラー方式と比較してみよう。スーパースカラー方式では、シーケンシャルなマシンコードを実行時に解析して同時に実行できる命令を洗い出し、並列に実行する。しかしこの方式だと、命令の並列実行度を上げようとしたときに命令のスケジューラが複雑になり、高速化ができないという問題点があった。

スーパースカラー方式で動作するRISCアーキテクチャ

実行時に解析する方法では命令の並列実行度の向上に限界がある。しかも、使用されないExecution Unitを生み出す原因となり、CPUの性能を最大限に発揮できない。また、スケジューラも複雑になり、CPUのコストを押し上げ高価なものにしてしまう要因ともなる

　これに対しEPICは、同時に実行できる命令を実行時に判断しない。プログラムをコンパイルする時点で、並列に実行できる命令を解析してプログラム中に記述しておき、実行時にはそれらの命令をすべて同時に実行するという技術である。すなわち、実行時における動的なリソースの割り当てや、衝突の検出などを行わなくてすむ分、ハードウェア構造が単純になり、高速化が行えるというわけだ。

EPICが採用する並列技術

プログラムのコンパイル時にマシンコードの並列化を行うため、非常に高い並列度が実現できる。Execution Unitを効率的に使用することができ、CPUの性能をフルに発揮できる

　HPは、上記のようなEPICアーキテクチャによる高速化を実現したItanium2プロセッサを搭載するサーバ「HP Integrityシリーズ」を提供している。さらに、このIntegrityには、Itanium2アーキテクチャを熟知したHPが独自に開発したチップセット「HP zx1」「HP sx1000」が採用されている。HP zx1はItanium2対応のローエンド向けチップセットである。sx1000は8-way以上に対応したハイエンド向けのチップセットである。zx1、sx1000ともに、大きなメモリ帯域幅、大規模なメモリ容量、短いメモリレイテンシ、大きなI/O帯域幅をもたせている。メモリアクセスやアドレスバスへのアクセスの並列度を高めることに成功することで、Itanium2プロセッサの高速性の発揮に貢献する。さらにsx1000は、RAS機能を充実させることにより、メモリやCPUの故障があってもマシンの停止の可能性を極力低下させることに成功し、サーバの高可用性を実現している。

　サーバの高可用性は、増大するインターネットアクセスに耐えうるための性能として非常に重要なポイントだ。サーバを負荷分散することで可用性を高めることも可能だが、少ないサーバ台数とCPUで同じ可用性を実現できる方が、コスト面でも有利である。

EPICアーキテクチャとJavaの組み合わせは高速！

　あまり知られていないことだが、実はEPICアーキテクチャとHotSpot実装のJavaVMの相性は非常によい。EPICが効率よく機能するためには、コンパイラによる命令の綿密なスケジューリングが欠かせない。一方HotSpot VMは、実行時にCPUに最適なバイナリコードを生成する技術である。双方を組み合わせれば、EPICアーキテクチャに最適なバイナリコードを生成する事が可能＊1なのだ。もっとも、HotSpot VMはHPが提唱したJava VMのアーキテクチャである。すならち、EPICとHotSpot VMのアーキテクチャは、ともにHPが開発に携わっているからこそ、「EPIC+Java」を高速なアプリケーション実行のためのプラットフォームとして実現できたといえよう。HPが開発した双方のアーキテクチャは、次の世代を担うItanium2プロセッサとJava VMに標準技術として実装されている。

　ところで、Itanium2搭載サーバでJavaアプリケーションを利用するメリットは、EPICに対応したコードを生成してくれることだけではない。Javaアプリケーションは実行時にコンパイルされるために、既存のあらゆるJavaアプリケーションはItanium2上でEPICに最適化されたコードとして実行することができるのだ。Java以外の言語ではこのようにはいかない。Itanium2の性能を出すために、個別に最適化をあらためて行う必要＊2が出てくるのだ。

WebLogicとの組み合わせで高パフォーマンスを発揮

　日本HPでは、EPIC＋Javaの組み合わせが実際にどれくらいの性能を発揮するのかを実際に測定を行った。JavaアプリケーションサーバにBEA WebLogic Application Server 7.0（以下WLS 7.0）と、HotSpot VM 1.3.1を使用して、CPUの種類別に各種OS環境でベンチマークを行った。ベンチマークのプログラムは、サーブレットとMDB（メッセージドリブンビーン）を使用した単純なメッセージの折り返しを、単位時間内に何回完了できたかを測定するものだ。

　上記の環境別に、ベンチマークプログラムを使って性能を計測した結果が以下のグラフだ。

WLS 7.1 + 各CPU別のベンチマーク結果

　グラフを見ると、Itanium2を搭載したHP IntegrityとWLS 7.1の組み合わせが非常に高い性能を発揮することがわかる。ちなみに、Itanium2専用の最新のHotSpot VM 1.4.1と、同プラットフォーム用WLS 8.1Jもリリースされており、機能面、性能面でさらに前進していることが日本HPのベンチマークで確認されている。以下のベンチマークを参照いただきたい。

WLS 7.1とWLS 8.1でのパフォーマンス比較

　さて、BEAでは、JRockitという高性能なJVMを提供している。HP IntegrityではRedHat Linux、Windowsの動作もサポートしているので、Itanum2+JRockit+WLS 8.1の組み合わせも非常に高性能が期待できる。HP-UX、Linux、Windowsといった、各種OSを選択できるというのも、Itanium2搭載のHP Integrityの強みである。

　Javaアプリケーションは、単にWebのエンジンとしてだけではなく、企業ポータルからBPMまで、企業の基幹システムの領域にその範囲を広げつつある。それを支えるプラットフォームは、高まる性能要求/TCO削減の観点から、可用性に優れるだけでなく、高速でコスト面にも優位性をもったものでなければならない。HPのIntegrityサーバとBEA WebLogic Serverの組み合わせは、その課題に回答を示すプラットフォームとして、高く評価できるだろう。