J2EEミッションクリティカル時代のソリューション「HP OpenView」（1）

　かつてOAなどと呼ばれたころの情報システムは、各部署ごとの個別の業務を処理したり、経営層向けに資料を作成したりといったサービスを行うためのものだった。会計処理、販売管理、在庫管理などの単独の業務オペーレーション、あるいはバッチ処理によるレポート作成などがそれだ。ERP（統合業務システム）というソリューションも出てきたが、その昔は大型汎用機で動作するものであり、予算に余裕のある大企業が時間をかけてゆっくりと導入するものだった。

　しかし、現在のビジネス環境は厳しさを増している。経営そのものにもスピードが叫ばれ、企業活動のすべてに効率化が求められている。ITバブル崩壊後は、情報システム投資の費用対効果が注目されているが、少ない投資で大きな成果を得るために、従来のデータやシステムを有効に活用することが求められるようになってきている。それまでバラバラに構築されていた既存のデータベースやシステムが連携し、さらなる生産性向上を目指すという傾向が強くなってきているのだ。

　市場の変化は以前にも増して激しくなってきており、昨日までのベストプラクティスが、今日も通用するとは限らない。競合他社に打ち勝つためには業務の絶え間ない改善が必要であり、企業システムも仕様変更やハードウェアなどの動作環境の変更に素早く対応できる柔軟性や拡張性、信頼性が強く求められている。

　こうした企業ニーズに応える基盤テクノロジがJ2EEだ。J2EEはこの3年、ソフトウェアのコンポーネント化、JDBCによるデータベース接続、非同期メッセージ交換など、ビジネスでの実用に必要な機能の実装が進められてきた。その結果、ミッションクリティカルな分野を含め、さまざまなシステムがJ2EE環境で行われるようになってきている。

　

J2EE環境下で求められる管理ツールとは

　このようにJ2EEがビジネスシーンで本格的に使われるようになってくると当然、安定性や信頼性も強く求められることになる。WebでのECサイトのように“いわゆる”ミッションクリティカルな業務でなくても、システムダウンは販売機会の喪失を意味し、ダウンタイムはビジネスロスに直結する。そうしたリスクに対処するために、万一システムダウンしても迅速に復旧するという態勢を構築することは必須といえるだろう。

　しかし、大規模システムであれば、多階層アーキテクチャによる分散処理環境として、極めて複雑な形に構築されているはずだ。

　トラブルが発生した場合、原因がデータベースにあるのか、アプリケーションサーバなのか、Webサーバなのか、ネットワークなのか、OSなのか、コンポーネントなのか……即座に問題の切り分けができない場合がほとんどだ。ダウンしたシステムが企業の基幹業務システムあれば、この間この会社は機能停止に追い込まれてしまうだろう。

　

J2EEシステムはハードウェア、OS、アプリケーションサーバ、コンポーネントとレイヤが積み上がり、トラブルの原因を突き止めることだけでも容易ではない

　このためにはJ2EEシステムでは、ネットワークやJ2EE上のロジック外にあるDBMSなどの要素を含めた統合的なステータスや、運用中の各コンポーネントの動作履歴を含め、トータルの情報を分析可能にするツールが求められるのだ。

　

複雑なJ2EEシステムで問題の原因を把握するためには

　トラブル発生以前に原因になりうる異常を早期発見できればなおよい。“止められない、止めてはならない”システムではなおさらだ。

　これまでにも、J2EE環境でコンポーネントの動作を監視するツールは存在したが、単に動作状況を監視するだけでは、ミッションクリティカルな分野での要求は満たせない。なぜならJ2EE環境下での各コンポーネットは、ネットワーク透過で接続され、仮想的なひとつのシステムとして深く結びついているためだ。個々のコンポーネントだけを監視するだけでは、問題発生の予測やトラブル対応の情報とするには不十分なのだ。

　こうした多数のコンポーネントが複数のコンピュータに分散して配置されている環境において、パフォーマンスに重大な影響を与えている箇所や脆弱な部分を、実稼働前にあぶり出すことは非常に難しいのである。

　一方、アプリケーション開発者向けのツールを活用するという手もある。Javaアプリケーションの動作プロファイルを作成、分析する開発ツールを用いれば、トラブル予測や解決の何らかの手がかりになるかもしれない。各メソッドの関係や実行時間などから、クリティカルなポイントを開発時に洗い出す機能を用いて、問題となりそうな箇所を絞り込んでいくことはできそうだ。しかし、Java環境の外にある要素（例えばDBMS）までを含めた、システム全体を見渡すプロファイリングを行うことができないという制限がある。

　もう少し狭い視野で、J2EEの中だけに限ってみても、わずかなメモリリークによるシステム障害をJavaのプロファイラで見つけることは難しい。数カ月運用していると、あるコンポーネントのパフォーマンスが落ちたり異常動作を起こすといった状況では、対処療法的な対応策では原因が特定できないままトラブルを数カ月ごとに繰り返すことになる。

　また、そもそもネットワーク管理者向けのツールと開発者向けツールでは目的が異なり、相互のツールから得られる情報を突き合わせるためには、管理者と開発者、両方のスキルが必要になる。

　

ネットワークの運用管理と開発を一元的に見通す必要性

　開発者は、運用現場でのシステムの状態を正確に把握できていないことが多い。逆にネットワーク管理者は、複雑に結びついたコンポーネント全体の関係を詳細に把握していないことが多い。そして両者は異なるツールで、システムの状態について会話を行うことになり、結果として迅速なトラブル原因の追及を阻害することになる。

　実際、J2EEではコンポーネントが部品としてブラックボックス度が高く、運用者は個々のコンポーネントの挙動についてまで、深く知らないことが多い。

　またJ2EEの導入が進んでくると、同じコンポーネントが複数のシステムで再利用されるようになる。これはJ2EEの優れた部分でもあるが、一方でブラックボックス化が進むと、システムの全体像は把握できても、問題発生時に正しい状況認識を行えないというジレンマが発生するわけだ。

　これでは管理運用を行う担当者と、システム開発の担当者が、同じ言葉、同じテーブルで有意義な情報交換を行うことはできないだろう。しかし、アプリケーション全体の動作プロファイルと運用情報を一体化し、一覧・分析できるならばそうした問題にも素早く対処することが可能だ。

　ミッションクリティカルな分野を含め、情報システムのあらゆる部分をJ2EEへと移行させる際、一番の問題となるのはこの部分だろう。問題解決は、開発者自身が開発環境下でのシミュレーション・テストだけではなく、実際に運用をしている本番稼働環境での運用データを元に事態を正確に把握することに始まるはずだ。

　本番環境の状況が把握できれば、開発者にとっては開発効率・生産性の向上につながり、ユーザー企業サイドにとってはIT投資のROIの面で大きなメリットがあるだろう。

　開発者と管理者をつなぐツールは、これまでに存在してこなかった。J2EEの普及によるアプリケーション実装環境の変化に、ツールが追従し切れていなかったことが原因である。しかし、これからは悠長に構えているわけにはいかない。今後も企業システムの中で、J2EEはその存在感を増していくと考えられるからだ。

　

プロファイラとネットワーク監視の両面性を持つHP OpenView

　そうした中、日本ヒューレット・パッカード（以下HP）は、日本BEAシステムズとの提携により、BEA WebLogic Server上で動作するJ2EEコンポーネントの詳細なステータスの読み出しをHP OpenViewから行えるように、BEA WebLogic Serverに対応したWebサービス管理ソリューション「HP OpenView smart plug-in for WebLogic Server」をリリースした。J2EE環境下でのアプリケーションパフォーマンスを自動監視する「HP OpenView internet services」、トランザクション分析ツールの「HP OpenView transaction analyzer」と合わせて、J2EE環境下で管理者と開発者が双方に抱えている問題に応えようとしている。

　中でもHP OpenView transaction analyzerは、運用中Javaシステムのトランザクションを分析し、障害の元になりそうな情報を検出、報告するといった機能を持つ。またJavaコンポーネント単位での動作状況を階層的にドリルダウンしながら、パフォーマンス低下や過負荷が考えられるパートへとたどり着くための手助けをしてくれる。その手順は開発者向けツールよりも管理者に対して易しく、かつ実際の監視データに基づいた正確な情報だ。運用上のトラブルに対して迅速に対応したり、トラブル発生前に問題となりそうな箇所を推定するために有効なツールとなるだろう。しかもJ2EEコンポーネントだけでなく、Oracleデータベースやロードバランサーなどを含むあらゆるネットワーク環境の監視・管理が行えるHP OpenViewのメリットを活かし、開発から運用管理、トラブルシュートまで、広範な情報をカバーできる。

　同時にHP OpenView transaction analyzerは、開発者にとっても優れたツールとなり得る。HP OpenView transaction analyzerは、コンポーネント単位だけでなくメソッド単位の呼び出しや応答などの状況が細かく報告されるからだ。開発者にとっての、より良いデバッグツールになり得るのである。

　しかもHPは、「HP OpenView internet services 4.0 日本語版評価バージョン」「HP OpenView transaction analyzer 1.0 英語版評価バージョン」という形で、60日間の無償ライセンス版を提供している。このため、J2EEアプリケーション開発者は、無償でHP OpenView transaction analyzerを用いて最適化やデバッグを進められる。さらにユーザー側の運用管理者がシステムをHP OpenViewで監視・管理・運用していれば、何らかのトラブルが発生した場合、あるいは運用開始後の点検などで、HP OpenView transaction analyzerを共通ツールとして開発者自身が本番ログを元にトラブルの詳細を正確に把握できる。

　ネットワーク管理とJ2EE環境下におけるコンポーネントプロファイラの両面性を持つツールはほかに例がない。ビジネスロジックをJ2EEへと移植している、あるいは移植することを検討しているユーザーは、いま一度、運用管理とアプリケーション開発の両面から、このようなツールの導入について検討すべきときがすでに来ているのではないだろうか。

　次回は、HP OpenView Webサービス管理ソリューションの実際について、見ていこう。

第2回「J2EEエキスパートが語るHP OpenViewの魅力」へ

Webサービス管理ソリューション 評価版が 無料でダウンロード、もしくはCD-ROMの請求ができます

評価版ダウンロード＆CD-ROM請求ページへ （日本HPサイトへジャンプします）

Index
J2EEミッションクリティカル時代のソリューション「HP OpenView」
	第1回	ビジネス利用が進むJ2EEの大きな課題とは？
	第2回	J2EEエキスパートが語るHP OpenViewの魅力