J2EEパフォーマンス・チューニングの“虎の巻”・前編

コア氏は、J2EEアプリケーションのスケーラビリティを左右する主要な要素として、「アプリケーションに対する負荷の大きさ」「スレッド数」「キャッシュサイズやプールサイズ」を挙げる。さらに同氏は、「メッセージングを用いる場合はメッセージ処理にかかる遅延時間、そしてXMLを用いる場合は扱うXML文書の大きさにそれぞれ注目する。例えば非常に大きなXML文書を処理する必要があるかどうか、といった部分がポイント」と説明する。

一方、アプリケーションのアーキテクチャについても考慮が必要だ。例えば大規模なJ2EEアプリケーションではクラスタ構成をとるのが定石だが、その場合の重要なポイントとして「ローカリティを意識すること」とコア氏は強調する。ここで言うローカリティとは、クラスタにおけるデータの局所性を意味する。「セッション・アフィニティ(ユーザ・セッションを特定ノードに固定する技法)を利用してノード間でのセッション情報の共有を減らし、オーバーヘッドを最小限に抑えることも考慮すべき」という。

また、スケーラビリティが要求されるJ2EEアプリケーション開発では、その開発工程のひとつのステップとして「パフォーマンス検証」を組み入れることをコア氏は推奨している。具体的には、ユーザ・アクセスをシミュレートするテスト環境を作成し、以下に示す4種類のパフォーマンステストを実行する方法を提唱している。

• 負荷テスト――予想される通常負荷レベルを再現する
• ストレステスト――高負荷時に発生する不具合を検証する
• ソークテスト――予想以上の高負荷を再現する
• 長時間テスト――長時間の負荷を再現する

さらに、こうしたアプリケーション全体のテストに加えて、1ユーザ単位のリソース消費の計測が重要な意味を持つ。「ユーザごとにどの程度のリソースを消費するか実測しておくことで、システムのトレンド解析の基礎データが得られる。アプリケーションが今後どのようにふるまうか、長期間にわたって予測可能になる」とコア氏は説明する。

また昨今では、サービス指向アーキテクチャ(SOA)の隆盛にともない、アプリケーション機能をサービス単位に分割する手法も広く用いられつつある。このSOAにひそむ落とし穴について、コア氏は次のように指摘する。「SOAを導入することで、企業が有するさまざまな情報を抽象化し、個々のモジュールに分割して提供可能になる。しかしこれにはリスクも伴う。そのひとつは、パフォーマンスのオーバーヘッドが増加する懸念。もうひとつは、サービス開発のアプローチがサイロ型(垂直分割型)になりがちな点だ。」(コア氏)そこでSOA導入では、サイロ型のアプローチをできるだけ避け、企業のビジネス全体を見通した設計や実装を実施できるかがポイントとなる。

ここまで紹介した手法は、いずれもJ2EEアプリケーション内部のふるまいや設計にフォーカスしたものである。これに対し、パフォーマンス・チューニングの要となるポイントとしてコア氏が強調するのは、「システム全体に着目すること」だ。具体的には、以下の各要素についてパフォーマンスの計測と分析を実施していく。

• システム全体
• ネットワーク
• サーバ・ソフトウェア(OS、プロセス)
• サーバ・ハードウェア
• 個々のプロセス(アプリケーション・サーバ、JVM)
• 個々のスレッド

「まずはシステムを適切にセットアップできているか確認する必要がある。またシステムの構成を継続的に監査することも不可欠だ。例えばHPが提供するツールHPjconfigを使えば、JVMの運用に適したパッチやカーネル・パラメータ設定がOSに適用されているか自動的にチェックすることができる」(コア氏)。

図5は、HPjconfigによるOS構成の診断結果の例である。ここでは、診断対象のHP-UXサーバに追加で適用すべきパッチのリスト、そして設定すべきカーネル・パラメータの値が表示されている。とりわけカーネル・パラメータは、しばしばJ2EEアプリケーションのパフォーマンスの足を引っ張る要因となりうる。「ある事例では、アプリケーションの負荷上昇にともない動作の不具合が頻発した。そこでトレースを実行したところ、カーネル・パラメータ設定の変更が原因であると判明した」(コア氏)。

つづく後編では、HP-UXのパフォーマンス計測ツールGlanceを活用したチューニング・テクニックを紹介する。

その他のコラム（特集）もお読み下さい