“サムライAPサーバ”を選択する視点：アナリストに学ぶ情シストレンド（2/2 ページ）

[岩上由高（ノークリサーチ），ITmedia]

トラブル解決に役に立つ！ JavaVMの機能

　しかし、JavaVMを独自開発するのは、単に実行速度を速めるためだけではない。真の目的はワンストップソリューションの実現だ。

　JavaEEベースのAPサーバ上での開発や運用経験があれば「パフォーマンスが上がらない」「アプリケーションがメモリリークを起こして止まってしまう」といった苦労を一度は経験しているはずだ。そうした時はAPサーバとJavaVMそれぞれのユーザーフォーラムやナレッジベースを調べる必要がある。

　特に難しいのは両者の切り分けだ。ミッションクリティカルなシステムであれば一分一秒でも早い復旧が求められる。そうした場合にAPサーバ側とJavaVMのどちらに原因があるのかを自力で切り分ける作業は大きな負担となる。そこで、Cosminexusに同梱されたJavaVMではトラブルシュートに役立つ以下のような工夫が盛り込まれている。

---

・GC処理が遅くなる原因の切り分け

FullGCが長時間にわたってしまう場合、OSレベルでメモリスワップが発生することでI/O処理に時間がかかっているのか、それとも本当にガベージ収集に時間がかかっているのかの切り分けが困難な場合が多い。ログ出力を改善することで、そうした原因の切り分けも容易に行える仕組みが備わっている。

・詳細なダンプをいつでも取得できる

通常、JavaVMの実行時の詳しい状態を取得する場合にはJVMTI（Java Virtual Machine Tool Interface）などに対応したツールを利用する。だが、JVMTIはオーバーヘッドが大きいため、通常の運用で情報取得を有効にしておくことは難しい。CosminexusのJavaVMではJVMTIを用いず、処理性能を極力落とさずに詳細な情報を取得できる独自の仕組みが備わっている。そのため、現象が発生したその時に詳細なダンプを取ることが可能になり、実際の運用環境の状況を正確に把握できる。

・ローカル変数の値も分かるスタックトレース

たくさんのアクセスが集中している瞬間のスタックトレースでは、障害の原因となったスレッドと実際のリクエスト内容の結びつけが困難な場合も多い。そこでCosminexusのJavaVMはスタックトレースに含まれる各メソッド内のローカル変数値まで表示してくれる。これによってトラブルの原因となったメソッドの処理状況を細かく把握できる。さらにJVM本体のバグ回収期間の短さも特筆すべき点だ。標準的なJavaVMのバグ回収期間は約40日程度だが、CosminexusのJavaVMは約5日と1/8の短さとなっている。これもミッションクリティカルなシステム運用で実績を重ねた結果といえるだろう。

---

　ここまで読んできて、「それでも独自JavaVMには抵抗がある」という方もいるかもしれない。だが、そもそもサン・マイクロシステムズ製でないJavaVMは数多く存在している。例えば、Macに搭載されているJavaVMはAppleが開発したものだ。WebLogic Application Serverは旧BEA SystemsのJRockitを搭載しているし、IBMのWebSphere Application Serverが搭載しているJavaVMもIBM製だ。サン・マイクロシステムズ自体が、互換性テストさえクリアすればさまざまなプラットフォームやニーズに最適化された多種多様なJavaVMが提供された方がJava全体の普及につながるというスタンスだ。

　要求されるサービスレベルや業務の種類にあわせて、無償で提供されているAPサーバとJavaVM、商用のAPサーバとJavaVMをそれぞれ使い分けるという発想があってもいいだろう。JavaEEという標準に準拠していることのメリットがそこに生きてくるはずである。

APサーバとJavaVMの連携技

　最新のCosminexus V8ではAPサーバとJavaVMを緊密に連携させたさらなる工夫が施されている。

　APサーバ側でセッション情報のライフサイクル（いつ不要になるか？）を把握することは容易だが、JavaVMのレベルでは長寿命オブジェクトとして扱われるためにFullGCの対象となりやすい。この種のオブジェクトのメモリをAPサーバ側で直接管理することにより、FullGCそのものの発生を抑止するというのがCosminexus V8に実装されたFullGC回避の仕組みだ。

　APサーバとJavaVMが一体となって機能を実現しているという点に違和感を覚える方もいるかもしれない。だが、実際問題としてAPサーバとJavaVMの組み合わせをいろいろと変えているケースは、ほとんどないだろう。すでに述べたように商用APサーバの多くはそれぞれ独自のJavaVMを同梱しており、それとの組み合わせで利用することがサポート条件にもなっている。であれば、APサーバとJavaVMの垣根を取り払い、緊密に連携させることでトラブルを未然に防ぐという選択は、開発や運用の現場の視点では極めて現実的な解といえる。

適材適所のAPサーバとJavaVMの選択が重要

　ミッションクリティカルな案件ではワンストップソリューションが求められる傾向が強い。その結果、上記に述べた「APサーバとJavaVMの連携技」のように、階層化されたシステムの構成要素が逆に単一化へと向かう傾向も見られる。顕著な例は仮想化環境におけるAPサーバの構成だ。米Oracle（旧BEA Systems）ではAPサーバを仮想化環境で稼働させる際、OSを介さずに仮想化ハイパーバイザー上で直接動作させる「LiquidVM」を発表している。日立製作所も同様の構想を検討中だ。

　このように考えるとJavaEE環境を支えるAPサーバについては一部メインフレームへの回帰ともいえる状況が垣間見える。JavaEEという標準仕様によってアプリケーションレベルのオープン性を確保しつつ、それを支えるAPサーバのレベルではベンダー各社がJavaVMやOSまで含めて安定性や高いサポートを保証するといった、いわばオープンシステムとメインフレームのハイブリッド的状況を呈している。

　こうした状況を踏まえ、JavaEE開発者にとっては自社のノウハウとして蓄積していくべき部分とAPサーバベンダーに任せるべき部分を見極め、各案件が求めるサービスレベルに合わせた適材適所のAPサーバとJavaVMの選択ができる視点を養うことが重要になってくる。そのためにはまずベンダー各社のAPサーバやJavaVMがどのような機能やサポートサービスを提供しているかを把握し、一通り実際に動かして試すことが大切だ。APサーバやJavaVMの詳細な技術情報というと敬遠しがちな面もあるが、まずは親しみやすい情報源へアクセスすることから始めてみよう。

著者紹介：岩上 由高（いわかみ ゆたか）

ノークリサーチ シニアアナリスト。早稲田大学理工学部大学院数理科学専攻卒。ジャストシステム、ソニー・システム・デザイン、フィードパスなどを経て現職。豊富な知識と技術的な実績を生かし、各種リサーチ、執筆、コンサルティング業務に従事。