クラウド時代のJavaEEプラットフォーム選びのポイント

64bit環境を最大限に活用する

　Javaプログラムを動かす際に、大きなヒープメモリ空間を利用したいことがある。この要望を実現するには、今ならJVMを64bit化することになるだろう。ところが、国産のアプリケーション・サーバー製品などでは、そもそも64bit環境に対応しておらず、大きなヒープサイズの利用が難しいものもある。また、JVMが64bit対応さえしていればいいのかと言えば、実はそう簡単な話でもない。

　須江氏は「JVMを64bitにすると処理が遅くなることがあります」と指摘する。JVMのヒープは、性能に影響を与えるガベージコレクションの対象となるメモリ空間だ。64bit化すればメモリ空間は広がるのだが、オブジェクトを参照するポインタも32bitから64bitと2倍になるため、同じ数のオブジェクトを扱うために必要なメモリ量が増加してしまう。こうなると、1回のガベージコレクションの処理時間が増えてしまい、結果的にはアプリケーション停止時間が長くなってしまうのだ。

　これに対しWebSphere Application Server V7.0では、最新のIBM SDK for Java 6を利用することで、オブジェクトポインタの圧縮が可能となる。この圧縮機能の利用でヒープ利用量とガベージコレクションのオーバーヘッドを削減して、32bit JVMと数パーセントしか違わない性能を実現している（図2）。そのため、WebSphereでは実用的なパフォーマンスを維持しつつ、ヒープサイズは約25GBまで拡大可能だ。業務アプリケーションなど大きなヒープサイズを利用したい場合には、WebSphereの利用を検討するといいだろう。

図2： Effective Heap Consumption

　この他にもWebSphereではメモリを有効活用する機能として、ランタイム・プロビジョニングも提供されている。これは、稼働させるアプリケーションに必要なコンテナ・サービスのみを選択して起動する機能で、メモリ空間を有効に活用でき、起動時間の短縮や管理負荷の低減などを実現する。

　通常のアプリケーション・サーバーでは、アプリケーションが必要としていなくても、様々なコンテナ・サービスを起動しているのが普通だ。ランタイム・プロビジョニングは、必要な機能を自動的に判断し、必要なコンテナ・サービスだけを起動する。新たなアプリケーションを動かす際に別の機能が必要であれば、それを判断し自動で追加起動されるのだ。

　「WebSphereでは、Javaで作られたモジュールの動的な追加や削除を可能にするための仕様であるOSGi化を、V6.1から進めており、内部がすべてモジュール化されているため、このような柔軟な対応が可能なのです。ランタイム・プロビジョニング機能はV7.0から提供しており、V8.0ではユーザーアプリケーションもOSGi化が可能になり、さらにリソースを効率的に利用できるようになる予定です」（須江氏）。（次ページへ続く）