| Oracle Composite Application Monitor and Modelerユーザーズ・ガイド リリース10.2.0.5 B56252-01 |
|
 戻る |
 次へ |
今日のIT組織の責任者は、進化し続けるビジネス要件に対処しながら、ミッションクリティカルなビジネス・アプリケーションを実現することを非常に強く迫られています。このような課題を克服するため、彼らの多くはさらに高いレベルのパフォーマンスと機敏性を得ようとして、J2EEおよびサービス指向アーキテクチャ（SOA）に目を向けました。IT組織がQAや製品に多くのJ2EEおよびSOAアプリケーションをデプロイするにつれて、アプリケーション・パフォーマンスを管理する従来の方法（JMXデータ・コレクションやバイトコード・インスツルメンテーションなど）はもはや適切ではないことが明らかになっています。
CAMMは、現在の複雑で分散したJ2EEおよびSOAアプリケーションの管理に関する課題を効果的に克服することができる、ただ1つのインテリジェントASMプラットフォームです。この章では、インテリジェントASMプラットフォームという新しい概念について詳しく説明します。
この章の内容は次のとおりです。
従来のAPMツールキットとは異なり、Oracle Composite Application Monitor and Modeler（これ以降ではCAMMと表記）は、J2EEおよびSOAアプリケーションを分析し、AppSchemaモデル（Oracleインテリジェント・プラットフォームの中心）に様々なアプリケーション・ビルディング・ブロック間の複雑な関係を取得します。
AppSchemaに格納されるインサイトを使用してCAMMが実現できるASM環境は、そのまま使用できるものを自己カスタマイズし、変化に応じて発展し、専門技術者の関与を最小限に抑え、異機種環境における総体的なサービス指向のビューを提供します。CAMMのようなインテリジェント・プラットフォームを採用することで、企業は分散アプリケーションをより効率的に管理でき、機敏な管理が可能になり、総保有コストを抑えることができます。
詳細は次の項を参照してください。
このマニュアルでは次の用語が使用されています。
表1-1 用語
| 用語 | 定義 |
|---|---|
|
ASM |
アプリケーション・サービス管理 |
|
APM |
アプリケーション・パフォーマンス管理 |
|
DIY |
Do-It-Yourself |
|
ISV |
独立系ソフトウェア・ベンダー |
|
リクエスト・トレース |
リクエストを実行する1つのスレッド。階層ビューでは1本の線として表示されます。 |
|
リクエスト・トレース・イベント |
左側のペインのノード |
|
リクエスト・トレース・イベント・ビュー |
トランザクション・イベント・ビュー |
|
SLA |
サービス・レベル合意 |
|
SLO |
サービス・レベル目標値 |
|
SOA |
サービス指向アーキテクチャ |
|
トランザクション分析 |
トランザクションのトレース |
|
トランザクション階層ビュー |
トランザクション階層ビューには、完全なトランザクションの階層がガント・チャートで表示されます。これは、絶対的時系列で各トランザクションの実行を示しています。 |
|
UI |
ユーザー・インタフェース |
|
WSRP |
Webサービス・リモート・ポートレット |
|
WSDL |
Webサービス記述言語 |
企業は、現在のJ2EEおよびSOAアプリケーションを利用して、重要な関係者（多くの場合、顧客、取引先および従業員）にミッションクリティカルなビジネス機能を提供することができます。このような複合アプリケーションは、多くの異なるJ2EEコンポーネントと、異機種環境に分散されている公開サービスを組み合せたものです。近年までの従来型モノリシック・アプリケーションとは異なり、現在のJ2EEおよびSOAアプリケーションの複雑さは次の理由から幾何学級数的に増大しています。
高度な分散実行
様々なランタイム環境で実行するインターコネクト・アプリケーション・コンポーネントにより、実行の複雑さが大きく増しています。
重要なコード生成
最新のアプリケーション・サーバーおよびアプリケーション開発フレームワークに関連するコード生成によって、アーキテクチャの複雑さが大きく増しています。
アプリケーションの急速なデプロイと変更
速いペースでのアプリケーションの増分デプロイや変更のために、操作の複雑さが大きく増しています。
残念ながら、従来のアプリケーション・パフォーマンス管理（APM）ツールキットでは、J2EEおよびSOAの複雑さという拡大する課題に効果的に対処することはできません。次に示す短所があるためです。
リソース中心の測定とビューへの特化
従来のAPMツールキットは、測定とビューを個々のエージェントに関連付けます。この方法では、コンポーネントとランタイムが広く分散しているアプリケーションの管理がきわめて困難です。
J2EE、SOAおよびアプリケーションの高度な専門技術の必要性
現在のJ2EEおよびSOAアプリケーションを管理するように従来のAPMツールキットを構成するには、J2EE、SOAおよびアプリケーションの高度な知識を持つ専門技術者チームが必要になります。技術者が専門知識に基づいて、様々なDo-It-Yourself（DIY）の手動タスクを実行します。技術者への大きな依存は、ITリソースへの負担を重くし、依存リスクを高めます。
反復的なDIY手動プロセスへの依存
従来のAPMツールキットを使用して効果的なASM環境を設定するには、DIY手動タスク（メトリックの選択、メトリックのグループ分け、しきい値の設定、アラート・アクションの構成など）を実行する専門技術者チームが必要です。新しいアプリケーションのデプロイや更新が発生すると、技術者チームは、いくつもの反復的DIY手動プロセスを忠実に実行して、このようなAPI環境の有効性を維持する必要があります。複雑さが増し、変更頻度が急速になると、この高コストの手動アプローチは破綻して手に負えない状況に陥ります。
これらの短所のため、従来のJ2EE用のバイトコード・インスツルメンテーションAPMツールキットを使用している企業が、分散J2EEおよびSOAアプリケーションのための効果的なAPM環境を設定して管理するには、大量のITリソースを割り当てる必要があります。複雑さの問題に対処するためにさらに多くのITリソースを投入することが解答でないのは明白です。現在の複雑かつ分散化したJ2EEおよびSOAアプリケーションの異機種環境での管理を有効に行うには、企業は次の特色を備えたインテリジェントASMプラットフォームを採用する必要があります。
異機種環境に対する総体的なサービス指向ビューの提供
インテリジェントASMプラットフォームは、低レベル（詳細）のテクノロジ中心メトリックにマッピングされる、高レベル（概要）のサービス指向メトリックを提供する必要があります。これらの測定は、異機種環境にデプロイされた多数のインターコネクト・アプリケーション・コンポーネントに関して統一された総体的なビューを提供するために、サービス指向の概念に基づいて整理されていることが必要です。
J2EE、SOAおよびアプリケーションの最小限の専門知識の必要性
インテリジェントASMプラットフォームは、現在のJ2EEおよびSOAアプリケーションにおける様々なインターコネクト・コンポーネントの複雑な関係を取得できることが必要です。この機能により、効果的なAPM環境の設定と維持にあたって、J2EE、SOAおよびアプリケーションの専門技術者への依存が最小限に抑えられます。
反復的なDIY手動プロセスの排除
インテリジェントASMプラットフォームは、そのまま使用できるものを自己カスタマイズしたり変化に応じて進化する機能を実現することにより、反復的なDIY手動プロセスを排除する必要があります。このような反復的DIY手動プロセスを排除することが、複雑化と急速な変化に容易に対処するただ1つの方法です。
現在のミッションクリティカルなビジネス機能は、高度な分散環境にデプロイされた多数のインターコネクト・コンポーネントで構成されるJ2EEおよびSOAアプリケーションを利用しています。このようなアプリケーションを効果的に管理するために、企業は、ビジネス機能、関連付けられているインターコネクト・コンポーネントおよび基礎となるランタイム環境の間の複雑な関係をまず理解する必要があります。明確かつ正確な理解を可能とするために、IT組織では、異機種環境にまたがる総体的なサービス指向ビューが必要になります。
さらに、これらのビューの適切なレンダリングにより、企業内の様々なレベルのユーザーが共同作業を行ったり、各自の仕事を効率よく行ったりできるようになります。
残念ながら従来のAPMツールキットは、管理方法に伴う制限のため、総体的なサービス指向ビューを提供することはできません。では、次にいくつかのアプローチについて詳しく説明します。
サーバー中心の管理
これは、J2EE層について表示するために、エンタープライズ・システム管理フレームワークによって使用される典型的なアプローチです。このリソース中心のアプローチでは、企業の様々なJ2EEコンテナから可用性とパフォーマンスの測定を収集して、1つのビューにまとめます。これは、様々なサーバーの状態を監視するためには適していますが、アプリケーション・レベルの管理については十分な内容が表示されません。
JVM中心のアプリケーション管理
従来のJ2EE用APMツールキットでよく使用されるこのリソース中心アプローチでは、1つのJVMで実行しているコンポーネントから低レベル（詳細）のテクノロジ指向測定を収集します。このようなツールキットにより、複数のJVMからの測定を論理単位に適宜グループ分けする方法がユーザーに提供されますが、これらのグループは分散アプリケーションを正確に表していません。このアプローチはJ2EEアプリケーションを監視するための最も一般的な方法でしたが、J2EEアプリケーションの複雑化や分散化が進み、サービス指向になるにつれ、次第に対処できなくなっています。
トランザクションのトレース
トランザクション中心アプローチは、複数のリソースにわたって1つのトランザクションのパスをたどり、その途中で低レベル（詳細）のテクノロジ指向測定を収集します。このアプローチでは分散アプリケーションについて十分な内容が表示されますが、トレースごとに大きなオーバーヘッドが発生するため、本番環境では従来使用されていませんでした。このために、従来のAPMツールキットは、サンプリング・レートの制限、サンプリング・ウィンドウの短縮およびオーバーヘッドを制御するオーバーフロー保護などの方法を取り入れています。これらの可視性を制限する方法や、事前にターゲット・トランザクションを識別する必要があることから、このアプローチは、J2EEおよびSOAアプリケーションを継続して管理するためにそれほど望ましいとはいえません。
オラクル社は、J2EEおよびSOAアプリケーションのために異機種環境の総体的なサービス指向ビューを提供できる、ただ1つのインテリジェントASMプラットフォームを開発しました。CAMMは、AppSchemaモデリング・テクノロジを使用して、分散アプリケーション、ソフトウェア・コンポーネントおよびランタイム・インフラストラクチャの複雑な関係を取得できます。CAMMは、AppSchemaモデルに格納されるセマンティック・マッピングを使用して、異機種環境の管理対象エンティティのパフォーマンスを適切なコンテキストで正確に測定できます。さらに、AppSchema視覚化およびAppSchemaナビゲーションといった機能により、全体の使用性が大幅に向上しています。AppSchema視覚化では、このような複雑な関係が様々な視覚化技術によって整理されて表示されます。
AppSchemaナビゲーションでは、階層トラバース、アーキテクチャ・モデル・ナビゲーション、文字列問合せ、ドリルダウン、ドリルアウトなど、関連する情報にアクセスするために効果的な方法が提供されます。
URLを使用して、AppSchemaモードの最も適切な表現方法を検索します。
今日の企業のIT組織は、企業が競争上の優位性を得るか、対等性を維持できるようなソリューションを作成することを、常に経営陣から迫られています。このような急速に変化する要件を満たすアプリケーションを量産するために、企業の開発者やアーキテクトは、最大限の効率性や柔軟性を得られるJ2EE、SOAおよびその他のアプリケーション開発フレームワークに目を向けました。その後、これらのフレームワークがそれぞれのIT組織で使用される方法に関して専門的な知識を持つこのような技術者たちが、ソフトウェア開発のライフサイクル・プロセスで不可欠になっています。
近年、J2EEおよびSOAアプリケーションの需要は着実に高まっています。結果として、現在IT組織では技術者が不足しており、現存する専門的リソースが限界まで達しています。したがって、IT組織は、技術者不足に対処し、専門的リソースへの依存を最小限に抑え、技術者が付加価値のある活動に専念できる余地を与えるための新しい方法を探しています。
残念ながら、従来のAPMツールキットを使用するとこの問題は悪化する一方です。従来のAPMツールキットを使用して効果的なAPM環境の設定と維持を行うには、J2EE、SOAおよびアプリケーションの専門的な知識が必要です。このようなツールキットでは、技術者が、これらの分散アプリケーションのアーキテクチャを判別し、ランタイム環境の構成を理解し、パフォーマンス測定を挿入する最適な場所を選択する必要があります。これらの知識集約的なタスクは、IT組織がより多くの専門的リソースを投入することを必要とし、技術者不足の問題が悪化します。
サード・パーティISVや海外の開発チームがこのような従来型ツールを使用して作成したアプリケーションの監視は、社内の知識が少ないために非常に困難です。
このような課題を克服し、J2EEおよびSOAパフォーマンスを効果的に管理するためには、IT組織は、設定と維持に必要な専門知識が最小限で済むCAMMのようなインテリジェント・プラットフォームを採用する必要があります。従来のAPMツールキットとは異なり、CAMMでは、カスタマイズしたAPM環境の設定や維持を専門技術者に依存しません。そのかわり、CAMMは独自のモデル駆動アプローチを使用し、AppSchemaモデルに格納された情報を活用して技術者の関与を最小限に抑えます。そのまま使用できるものを自己カスタマイズし、変化とともに発展する独特な機能のために、CAMMは、カスタム・エンタープライズ・アプリケーションだけでなく、外部パーティによって開発されたアプリケーションの管理においても申し分ないソリューションとなります。
開発者とアーキテクトは、何年間にもわたり、アプリケーションのパフォーマンスを測定するために反復的なDIY手動プロセスを利用していました。1990年代の終わりにJavaバイトコード・インジェクション技法が出現してから、IT組織は、部分的に自動化されたバイトコード・インスツルメンテーション技法を利用するようになり、完全な手動のソース・コード・インスツルメンテーション技法から次第に脱却してきました。従来のAPMツールキットは、バイトコード・インスツルメンテーションを自動的に挿入する機能を提供することでこの流れに乗りました。ただし、このような従来のAPMツールキットでは、効果的なAPM環境の設定や維持に必要な反復的DIYプロセスはほとんど削減されませんでした。
従来のAPMツールキットの場合、効果的なAPM環境を設定して維持するために、IT組織は次のアクティビティを繰り返して実行する必要があります。
アプリケーション構造とランタイム構成の理解
各アプリケーションに対する関連するパフォーマンス測定の手動選択
便宜的メトリック・グループの手動作成によるコンテキストの適用
変更発生時のAPM環境の更新
エンタープライズ・アプリケーションを効率よく量産するという今日のIT組織に対する要求のため、既存のITリソースは限界にまで達しています。さらに事態を悪化させることに、IT組織は、より多くのアプリケーションの本番環境へのデプロイを進め、アプリケーションの変更をより頻繁に行っています。このような傾向と技術者不足が結びつき、IT組織がAPM環境を最新状態に保つことはますます困難になっています。この結果、IT組織は、従来のAPMツールキットに付随する反復的なDIY手動プロセスなど、無駄なアクティビティを最小限に抑える方法を求めています。
CAMMはIT組織がこの課題を克服するために役立ちます。独特なモデル駆動アプローチに基づいたCAMMは、反復的なDIY手動プロセスを排除するただ1つのインテリジェントASMプラットフォームです。このレベルの自己カスタマイズと継続的な変更採用を達成するために、CAMMはAppsSchemaモデリング・テクノロジを使用して、アプリケーション構造やインフラストラクチャ構成を分析するというクリティカルなタスクを実行します。このようなインサイトをAppSchemaモデルに取得した後、CAMMはその情報を利用して完全にカスタマイズされたASM環境を確立します。この環境を最新に保つため、新しいアプリケーションがデプロイされたり、変更が適用されたりするたびに、CAMMは継続的にAppSchemaモデルを更新します。そのまま使用できるものを自己カスタマイズして変化とともに発展する、CAMMの独特な機能のために、迅速な価値実現、低い総保有コスト（TCO）および最大の投資収益率（ROI）が可能になります。
今日のIT組織は、急速に変化するビジネス要件を満たす高性能のエンタープライズ・アプリケーションを効果的に量産するために、J2EE、SOAおよびその他のアプリケーション開発フレームワークを活用しています。このようなミッションクリティカルなアプリケーションやサービスが使用可能な状態となり、最高のレベルで実行できるように、企業は適切なアプリケーション・パフォーマンス管理（APM）ソリューションに投資する必要があります。従来のAPMツールキットとその反復的Do-It-Yourself（DIY）手動プロセスは、かつてはモノリシック・アプリケーションの管理に適していました。ただし、残念ながら、このように異機種ランタイム環境で実行する、急速に変化し高度に分散化されたJ2EEおよびSOAアプリケーションを効果的に管理することはできません。
J2EEおよびSOAアプリケーションを管理する非常に優れたアプローチは、反復DIY手動プロセスを排除し、専門的人材の関与を低減できるような、高いインテリジェント性能を備えたASMプラットフォームを使用することです。さらに、このプラットフォームは、異機種実行環境における総体的なサービス指向ビューを提供できることが必要です。このために、メタデータ・ベースのモデルを活用して、様々なアプリケーション・ビルディング・ブロック間の複雑な関係を取得します。また、企業は、アプリケーションやインフラストラクチャの頻繁な変更に対処するために機敏性の高いソリューションを必要としています。つまり、IT組織に必要なのは、J2EEおよびSOAのためのインテリジェントAPMプラットフォームです。
オラクル社は、J2EEおよびSOAのための業界初のインテリジェントASMプラットフォームを提供しています。従来のAPMツールキットとは異なり、CAMMはこれらのアプリケーションを分析し、AppSchemaモデルに様々なアプリケーション・ビルディング・ブロック間の複雑な関係を取得します。AppSchemaモデルは、このインテリジェントASMプラットフォームの頭脳です。
CAMMが、AppSchemaモデルに格納されるインサイトを使用して実現できるASMソリューションは、そのまま使用できるものを自己カスタマイズし、変化に応じて発展し、専門技術者の関与を最小限に抑え、異機種環境における総体的なサービス指向のビューを提供します。Oracleのようなインテリジェント・プラットフォームを採用することで、企業は分散アプリケーションを効率的に管理でき、機敏な管理が可能になり、総保有コストを抑えることができます。
CAMMは、複数層の完全に分散された構成可能なアーキテクチャを利用して、企業デプロイメントの変化するニーズを満たすスケーラビリティと柔軟性を提供します。CAMMは主にサービス・モードとスタンドアロン・アプリケーション・モードという2つのモードで実行します。
サービス・モードでは、CAMMはマシン上のサービスとして機能します。マシンが最初に起動されるときに自動的に実行を開始し、永続的に実行を続けます。通常このモードでは、CAMMは専用のマシンにインストールされ、管理対象アプリケーション・サーバーのグループの監視のみを行います。
ブラウザを介してCAMMにリモート・アクセスできるようにするには、Webコンテナをインストールします。このWebコンテナは、CAMM UIアプレットをブラウザにプロビジョニングし、これらのアプレットとの通信を管理します。
図1-3に、サービス・モードでデプロイされたCAMMを示します。
アプリケーション・モードではCAMMはアプリケーションとして実行します。アプリケーションを起動するとCAMMが開始し、アプリケーションを閉じるとCAMMが処理を停止します。アプリケーション・モードは、ラップトップなどでデバッグ・ツールとしてたまに実行するときに役立ちます。
図1-4に、アプリケーション・モードでデプロイされたCAMMを示します。
次のコア・コンポーネントがデプロイされて、すべてのモードのCAMM ASMシステムを形成します。
CAMM Javaエージェントは、CAMM ASMシステムのデータ・コレクタです。CAMM Javaエージェントは、すべての管理対象アプリケーション・サーバーにデプロイされて一連のタスクを実行します。これには、パフォーマンス管理の収集、コンテキスト関係の追跡、およびオーバーヘッドを最低限に抑えたリアルタイムでのデータ要約などが含まれます。事前定義済集計間隔が終了すると、これらのエージェントは、要約済データをさらに分析するためにCAMMに転送します。様々なJ2EEプラットフォーム（Oracle SOA Suite、Oracle WebLogicおよびIBM WebSphereなど）について、CAMMはそれらのデプロイメント・インフラストラクチャを利用して、すべてのアプリケーション・サーバーにCAMM Javaエージェントを短時間でデプロイします。
CAMMマネージャは、CAMM ASMシステムのコア分析エンジンです。CAMMマネージャは、すべてのCAMM Javaエージェントからの要約済データに対して複雑な数学的モデリングや統計計算をリアルタイムで実行します。可用性を高めるためにCAMMマネージャのバックアップを構成することもできます。
また、CAMMマネージャは、UIコンポーネントを含めずに構成することもできます（ヘッドレス構成）。
