J2EE開発のパフォーマンス管理術（前編）

システムの内部動作を視覚化する

アイティ・フロンティア
西元信雄
2003/7/10

---

　開発プロジェクトの責任者の立場からみると、最近、J2EEアプリケーション開発の難易度が年々高まっていることに危機感を感じる。メインフレームの時代は、OS、DB、言語、設計、開発方法論のすべてを把握してプロジェクトを遂行できた。しかし、昨今のJ2EE開発では、設計、開発方法論、テクノロジ、開発スピード、コストといったさまざまな要因が複雑に絡み合い、プロジェクトの成功を危ういものにしている。

　このような危機感は、かつてのメインフレーム時代には感じなかったことだ。このような状況で必須となるのは、J2EEシステム全体および各コンポーネントが正常に動作するか、開発の細かい段階で常にチェックをすることである。それには、システムの内部がどのように動作しているかを“視覚的”に把握できる方法が求められるだろう。

　本記事は、J2EEアプリケーション開発における重要な要素としての「パフォーマンス管理」をテーマとし、筆者自身の開発経験を交えて執筆する。前編、後編の2部構成であり、前編では筆者のオブジェクト指向開発経験および経験に基づいたJ2EEアプリケーション開発の問題点を指摘する。後編では、前編で指摘した問題点を解決する方法として、システム内部動作の視覚化によるパフォーマンス管理解説を実例を挙げながら展開する。

---

実践で体得したオブジェクト指向の基本原則

　プロジェクトの責任者として、この十数年はそのときの最新のテクノロジを使ったビジネス・アプリケーションの構築を仕事としてきた。最初はメインフレーム上でのリレーショナル・データベースを中核にした数百万ステップの開発だった。

　その後に、メインフレーム上で100万ステップ以上の既存システムを、オブジェクト指向テクノロジによって再構築した分散オブジェクトシステムを開発した。私にとっては初めてのオブジェクト指向開発プロジェクトを推進するに当たり、設計の初歩から米国のエンジニアに学んだ。そのころは、ブーチ、ランボー、ヤコブソンがそれぞれで提唱する開発プロセスの覇権を争っていた時代である。米国のエンジニアと何回か真剣なディスカッションを重ねた結果、企業システムを構築する方法、特に大規模なデータベースを取り扱うトランザクションタイプのアプリケーションを実務的に設計するには、ヤコブソン（の提唱する方法論）であると判断し、その手法を採用した。その後、3人はラショナルに集結し、その成果はUMLへと結実した。

　UMLはモデリング言語のデファクト・スタンダードとして成功したが、3人が備えていた個性が希薄となってしまった感がある。とはいえ、当時感じたオブジェクト指向の基本原則はいまでも変わらないと考えている。それを以下に示す。

1. 少数精鋭のクラス開発チームと充実した支援スタッフ（プロジェクト・マネージャ・業務・DB・テスト担当など）が必要
   
   
2. 要件定義とリレーショナル・データベースの設計は、オブジェクト指向とは関係なく、既存の経験を重視して設計する必要がある。特に、大規模システムの開発経験は貴重なノウハウとなる
   
   
3. プロジェクト管理は、ウォーターフォール型で、マイルストーン単位にスケジュール・コスト管理を重点的に行うのが効率的
   
   
4. （システム全体の）中核プログラムは、イテレーションを繰り返しながら設計、開発を行う。イテレーションを繰り返さないと、良いクラスは作れないことが重要なポイントである。デザインパターンでも最初から優れたクラスを構築できるが、ドメインとプログラムの組み合わせが無数に生じてしまう。結局、イテレーションは行わなければならない。なお、イテレーションはウォーターフォール型のミニ開発の繰り返しではない。分散オブジェクトの世界では、必ずパフォーマンステストを行い、性能を確認する。ボトルネックがあればクラスを書き直し、再度テストを行う
   
   
5. コードのリファクタリングを行う勇気を持つ。スケジュール・コストの影響を受けないためにも、早い段階でパフォーマンステストを実施し、ボトルネックを発見するようにする
   
   
6. 将来の再利用は追求せず、プロジェクト内におけるクラスの再利用のみを考えて、簡単な抽象化を行うようにする
   

　（私が考える）オブジェクト指向の基本原則は、「XP」（エクストリーム・プログラミング）の精神と同一だと感じる。オブジェクト指向開発のスタイルは、「XP」の精神と大規模プロジェクトの業務設計、DB設計、プロジェクト管理が融合したスタイルが最適なのではないだろうか。

J2EEアプリケーションの問題点

　いくつかのオブジェクト指向開発案件を経験した後、コンビニエンスストアのECサイト構築という案件で、システムエンジニアとしては、苦手な領域であるWebデザインとアフィリエートなビジネスモデルを検討するという経験をした。これまでは堅牢な企業システムの開発に従事してきたため、このような“新奇な”ビジネスモデルに適するサイトのデザインを行うことは新鮮な経験だった。

　また、この案件を通じて、開発期間の短縮というスピード感覚を身をもって体験させられた。このことは、次世代のアプリケーション開発トレンドの到来を予感させたが、逆に漠然とした危機感をも持ち始めた。以下、私が考えるJ2EEアプリケーションの問題点と解決策を指摘してみる。

問題点1.「ブラックボックス」

　eビジネスを実現するコア・テクノロジはその多くがJavaアプリケーションで構築される。これは現在では動かしがたいトレンドだろう。しかし、大規模になればなるほど、Javaアプリケーションは、管理者（ビジネスオーナ、システム管理者、プロジェクトマネージャ、サーバ管理者など）の立場からは、ブラックボックスと化す。つまり、コンポーネントの詳細な設計を把握できない状態になるのである。

　現在では、ブラックボックス化の傾向はさらに進展し、システム構築と運用のリスクを各管理者がコントロールできないほどである。今後、Javaベースのアプリケーション・パッケージ（ERP、CRM、SCM）が出現してくるだろう。そうなると、ますます、Javaアプリケーションは、巨大なブラックボックスになっていく。この傾向は、開発の品質向上と生産性を改善するはずのフレームワークやコンポーネントそのもののブラックボックス化を誘引するようになる。

　このような状況では、プロジェクトを成功に導くために結成された少数精鋭のチームでも、コードのリファクタリングを行うだけで精いっぱいな状況に追い込まれることになる。しかし、たとえそのような体制を敷いたとしても、全クラスをチェックすることは事実上不可能であり、あるスタッフが構築したクラスは、ほかのスタッフにとってブラックボックスと化す“極めて混乱した状態”に陥る可能性がある。

図1 ブラックボックス×複雑性×リスク

問題点2.「複雑化」

　J2EE上のアプリケーションは、年々複雑な構造になっている。J2EE自体も、多機能、複雑化、大規模化し、DBサーバとの接続や負荷分散のためのクラスタ構成を採用することは必須となっている。さらに、レガシーシステムとの統合も今後は一般的なニーズとして浮上してくるだろう。特に、Webサービスによる既存システムとの有機的な結合（あるいは新規のシステム間連携）は、新たなアプリケーション・スタイルの中心的な役割を担うと考えられる。

　つまり、Javaアプリケーションが、eビジネスのハブ機能となり、ほかのシステムに接続しながら、全体として有機的なシステムとなっていくのである。

　このような複雑な開発状況において、個人がシステム全体を把握するのはほとんど不可能に近い。とはいえ、人材不足という厳しい要因もあり、プロフェッショナル・スタッフが、開発陣、管理層を支援する体制を構築することも困難である。システム構築後に、サービスレベルの維持が必要な運用体制となった場合、プロフェッショナル・スタッフによる支援体制を継続的に確保することは不可能に近いのである。

解決策1.「モニタリング」

　経済状況が厳しい昨今、企業システムは、既存のアプリケーション（特にビジネスロジックの固まりであるメインフレーム・システム）を再利用することが重要になっていくだろう。企業の重要な資産である現行システムと組み合わせ、eビジネスを展開する新システムに改変する開発スタイルが重要になってくる。このようなシステムは、フロントエンドでWebアプリケーションを稼働させる必要があるが、コア部分は、ミッションクリティカルな既存の基幹システムを再利用することがコスト面で見ても妥当だろう。そうなると、メインフレームと同品質の監視サービスが重要になってくる。

　Java開発者は、コンポーネントやフレームワークといった先進的な技術を習得し、ビジネスに適応していく努力をするべきだが、一方で、顧客と運用責任者のリスク（ボトルネック）を低減させるような、高品質なJavaアプリケーションを構築する、という意識を持たなければならない。

　顧客側の責任者とJava開発者、および運用責任者（アウトソーサーも含む）の3者が、システムの性能、品質を透過的（視覚的）に理解できることが、SLA（サービス・レベル・アグリーメント）を結ぶ大前提である。そのためには、Javaアプリケーションの最も小さい粒度のコンポーネントや相互に接続しているほかのシステムまで、全体的にかつ細かい所までパフォーマンスを監視できなければならない。つまり、問題が発生したときは、ピンポイントでボトルネックまで把握できるモニタリング技術が、今後のシステム構築、運用というシーンでは必須の条件となるのである。

解決策2.「視覚化を行う経験」

　“生きている”Javaアプリケーションとその周辺システムのパフォーマンスを、技術的な知識だけ基にして短時間に把握することは不可能である。たとえ、マニュアルを片手にモニタリングのログを分析したとしても、リアルな環境の分析にはほど遠い。

　Javaのアプリケーション環境は、「複雑」「スピード」「変化の多様性」で構成される世界である。その世界を直感的に体感し、アプリケーションを包括的に、かつ同時に細部まで知覚することが大切になる。そのためには、Javaアプリケーションを「視覚化」することが必要だ。視覚化を行う経験がJavaの深い理解へとフィードバックされることになる。

　さらに、これによって、Javaアプリケーションが企業のミッションクリティカルな基幹システムとなる重要な前提＝「品質」を保証できるようになるだろう。それ故、本番稼働中のコンポーネントや複雑なJ2EE基盤全体をリアルタイムに視覚化し、監視することは、非常に重要なことである。

図2 視覚化

　J2EEを取り巻く世界とコンポーネントをリアルタイムに視覚化するという行為の関係は、認知論における「アフォーダンス」（注）と同一の世界観ではないだろうか。視覚化することで、J2EEのインターフェイスは、内部のコンポーネントをリアリティのあるグラフに変換し、システム内部の情報を“外の世界”に顕現させる。J2EE内部のコンポーネントの動きを把握することは、J2EE内部の動きの深い理解につながるのである。

（注）「アフォーダンス」
　米国の知覚心理学者ジェームズ・Ｊ・ギブソンが提唱した認知理論。「主体としての人間が情報を知覚し、自身が持つ知識を用いて推論を行い、行動する」という従来の概念を否定、「知識は人間を取り巻く環境の中に存在し、意味や価値はそこから“探し出される（アフォードされる）”もの」だとする考え方。

J2EEアプリケーションの視覚化の実例

　J2EEアプリケーションを視覚化し、パフォーマンス管理を統合テストから本番監視のフェイズに適用したプロジェクトを紹介しよう。ユーザーがLAN上で互いに通信をしながらゲームを展開するIAサーバベースのシステムである。

図3 LANゲームの概念図

　ナムコが展開するこのLANゲームの実験店舗は、中核システムをJ2EEで構築した。店舗名は「LEDZONE（レッドゾーン）」である。LANレッドゾーンの最初のコンテンツは、米国のシューティングゲーム「カウンターストライク」で、ナムコが日本人向けにカスタマイズした。日本での名称は「カウンターストライク・ネオ」である。LAN上のPCで「テロリストチーム」と「SWATチーム」に分かれて戦うシューティングゲームだ。

レッドゾーン実験店舗

　店舗は24時間営業を目標としている。また、ローコスト運営を目指し、IAサーバのOSにLinuxを導入した。J2EEのアプリケーション・サーバ（WebSphere）とデータベース・サーバ（DB2）を、最小限度のCPUで、最高の性能が出るように設計した。

　設計段階から最高のパフォーマンスを引き出すために、統合テスト時から負荷をかけ、ボトルネックがあるかを確認した。システムの中枢コンポーネントとJ2EE全体の性能をその都度、パフォーマンス監視ツールでチューニングしていくのである。最終の本番環境でも20人以上のプレイヤーがゲームをしている状況でパフォーマンスを監視した。ボトルネックやJVMのガベージコレクションを確認するため、同時にモニタリングも実施した。

　後編では、このゲームシステムの内部動作を視覚化し、パフォーマンス管理を実施する詳細について解説する。

IT Architect 連載記事一覧