Application Performance Management for SOA について

apmdevops104jp
サービス指向アーキテクチャ(SOA)は、標準化された通信プロトコルに基づくアプリケーション プラットフォームであり、このアーキテクチャにより、疎結合のサービスを使用して、ビジネス目標を達成できるようになります。
SOA を使用する利点には以下のものが含まれます。
  • ビジネスの敏捷性と柔軟性の向上
  • カスタマ サービスと効率の向上
  • 開発コストの削減
ただし、複雑な SOA 環境の監視および管理は、従来のクライアント サーバ環境の管理に比べると、難しくなる場合があります。
従来のクライアント/サーバ環境では、クライアントと限られた数のサーバとの間で直接の通信が行われます。問題が発生しても、少数のシステムのみが個々のビジネス トランザクションにかかわっているため、障害の原因を見つけることは通常は容易です。トランザクションに直接かかわる特定のシステムを調査することにより、その問題の原因を隔離できます。
Web アプリケーション サーバを中心に、複数のクライアント サーバ システムにわたってアプリケーションへのアクセスが分散されていると、問題の原因の特定はより困難になります。パフォーマンスの低下、エラー、または処理の失敗は、Web サーバが接続されたインフラストラクチャに属している、あらゆるコンポーネントやコンピュータが原因となる可能性があります。
サービス指向アーキテクチャでは、アプリケーション パフォーマンスおよび可用性の監視のために、新たな複雑な仕組みが導入されています。SOA では、疎結合のサービスは標準化された通信に基づいて、さまざまなプラットフォーム上で実行されているアプリケーションを統合および拡張します。そのようなサービスでは、基盤となるオペレーティング システムまたはプラットフォームをビジネス ロジックから切り離すため、組織では市場や製品の動向の変化に対して、対応性と俊敏性が向上します。個々のサービスは、異機種環境間にまたがって結びつけられた依存関係を形成することで、複雑なビジネス プロセスや多段階のビジネス プロセスの特定の一部分を処理するように設計できます。
サービス指向アーキテクチャの使用により、組織ではアプリケーションをより短期間に、よりコスト パフォーマンスの高い方法で開発して展開できます。これは、ぞれぞれのサービスを独立したコンポーネントとして再使用したり、修正や、置き換えができるからです。ただし、アプリケーション アーキテクチャへのこの効率的なモジュール方式のアプローチゆえに、アプリケーション管理に関する独自の課題が生じることになります。
SOA インフラストラクチャの一般的なコンポーネント
SOA を使用することで、ビジネス プロセスの導入および統合が効率化されますが、基盤となる SOA インフラストラクチャは通常、複数のコンポーネントの複雑なインタラクションに依存します。たとえば、単一のビジネス トランザクションを完了するには、通常、複数のサービスが必要であり、それらのサービスは異なるプロトコルを使用して互いにメッセージ交換を行うさまざまなコンポーネント上で実行されているのが一般的です。トランザクションの重要なコンポーネントの監視には、サービスがどのように通信しているか、要求と応答がどのようにサービス間でルーティングされているか、どのサービスが他のサービスへの依存関係があるか、重大なボトルネックがどこで発生するかについて認識できる必要があります。
具体的な監視の要件は SOA の実装によって異なりますが、標準の SOA インフラストラクチャには次のものが含まれます。
  • さまざまなサービス。標準のインターフェースを使用して、クライアント側およびサーバ側コンポーネントが相互にメッセージをやり取りします。
  • メッセージ処理システムがひとつ。コンポーネント間で要求および応答を変換、ルーティング、配信します。
  • 各種アダプタ。外部またはレガシー システムが、展開されたサービスに接続して、それらのサービスを利用するために使用します。
  • レジストリがひとつ。使用可能なサービスに関する情報が記録および発行されます。
以下の図で示している簡略化された SOA インフラストラクチャでは、簡易オブジェクト アクセス プロトコル(SOAP)および拡張可能マークアップ言語(XML)を使用して、Web サービス(WS)が
Enterprise Service Bus
(ESB)を通じて、相互に通信しています。ESB は、適切なターゲットへのメッセージの配信を制御するために使用されています。
APM for SOA 2
SOA インフラストラクチャは、モジュラー方式で提供される再利用可能で柔軟なコンポーネントで構築されます。そのため、このような環境でのトランザクションでは通常、多くのコンポーネントが関与します。トランザクションにかかわるコンポーネントの数が増えるにつれ、トランザクションのフローの追跡はますます難しくなります。さまざまなトランスポート プロトコルを使用してプロセス間またはプラットフォーム間で渡されるメッセージが増えるにつれて、潜在的な障害点も増えます。さらに、組織は一度 SOA 環境でのアプリケーションの展開を始めると、ますます多くのミッション クリティカルなサービスをその環境に移動させる傾向があります。その結果、ビジネスの稼働状況を保つために、インフラストラクチャの監視がますます重要になります。
SOA パフォーマンス管理(SPM)では、これらの独自の課題に対処するために、SOA インフラストラクチャの稼働状況、および SOA トランザクションにかかわっているコンポーネントのリアルタイム パフォーマンスを可視化します。
CA Introscope を使用して SOA パフォーマンスを監視する
SOA パフォーマンス管理(SPM)では、SOA 環境のアプリケーション パフォーマンスのリアルタイムおよび履歴ビューが提供されています。CA APM for SOA によって CA Introscope のコア機能が拡張され、ユーザがサービスを要求する
フロントエンド
から、要求への応答に使用される
バックエンド
システムへの Web サービス トランザクションを監視および追跡できるようになります。CA Introscope を SPM と共に使用することで、SOA クライアントおよびサーバのパフォーマンスの積極的な監視、問題の切り分け、およびサービスに関連した問題の詳細な分析を、アプリケーションのソース コードや SOA アーキテクトにアクセスすることなく行うことができます。
CA Introscope に SOA パフォーマンス管理(SPM)を追加すると、以下のことが可能になり、SOA 環境の監視がより容易になります。
  • 概要および詳細メトリック。Web サービス、アプリケーション、またはバックエンドへの問題の切り分けに役立ちます。
  • エージェント、サービス、オペレーション間の依存関係を視覚的に表示。あるコンポーネントに関する問題がどのように他のコンポーネントに影響を与える可能性があるかの評価に役立ちます。
  • プラットフォーム、トランスポート プロトコル、およびアプリケーション サーバにわたる相関トランザクションの追跡。
  • Web サービス コンポーネントにより発生したアプリケーション エラーまたは SOAP 障害を可視化およびコンテキスト表示。
これらのデフォルトの機能により、SOA クライアントおよびサーバの監視およびアプリケーション管理が可能になりますが、さらに、独自のニーズに対応するために CA Introscope および SOA パフォーマンス管理(SPM)をカスタマイズできます。たとえば、以下のことが可能になります。
  • Web サービスの呼び出しの受信、完了を確認して、Web サービスの監査証跡を作成する
  • Web サービスのアプリケーション グループを作成し、グループが、応答時間、トランザクション容量、またはエラーしきい値を超えているかどうかを確認する
  • Web サービス クライアントおよびサーバに関して集約されたメトリックを収集するように、仮想エージェントをセットアップする
Web サービス クライアントおよびサーバを監視する
ほとんどの場合、Web サービスのトランザクションは、Web サービスに要求を送信するクライアント、および要求に応答するサーバで構成されます。たとえば、ユーザまたはプログラムが株価情報を要求できる Java クラスは、Web サービス クライアントと見なすことができます。要求に応じて価格情報を提供する株価情報 Web サービスは、Web サービス サーバと見なされます。
エージェントは、クライアントとサーバのメトリックを別々に追跡して表示します。それにより、クライアント側およびサーバ側のパフォーマンスに関するしきい値を別々に監視および設定することが可能です。また、クライアント側およびサーバ側が区別されるため、適切なコンテキストでの依存関係を参照することも可能です。
ほとんどの場合、Web サービスのクライアントとサーバは、個別の Java 仮想マシン(JVM)または Microsoft Common Language Runtime 環境(CLR)で実行されています。したがって、クライアント側およびサーバ側オペレーションに関するメトリックは通常、2 つ以上のエージェントによってレポートされます。クライアントとサーバが共に集約されたメトリックを確認したい場合、そのように仮想エージェントを構成します。
依存関係の表示およびメトリックの使用により、問題を切り分けて診断する
こうした複雑な SOA 環境で問題が発生した場合、その発生場所をどこから探し始めるべきかが判断しにくいことがよくあります。アプリケーション アーキテクチャはモジュール方式であるため、より多くのコンポーネントが各トランザクションにかかわっており、より多くの潜在的な障害点があります。
SOA 依存マップは、モジュール方式のコンポーネントがどのように相関しているか、それらのリレーションシップがどのようにパフォーマンスに影響を与えているかを可視化します。依存関係を使用することにより、潜在的なボトルネックまたはクリティカルなオペレーションがどこにあるかを分析し、相互に依存関係があるサービスについて、平均応答時間やその他のメトリックを比較できます。
俯瞰的なビューは、全体的なアプリケーション パフォーマンスを要約し、潜在的な問題を警告し、コンポーネント間のリレーションシップを示します。SOA パフォーマンス管理(SPM)を使用した CA Introscope では、俯瞰的なサマリと詳細なオペレーション レベル両方のメトリックが提供されます。これらを使用して、組織の設計者や開発者は問題を調査し、切り離して、解決することができます。メトリックを使用した Web サービス パフォーマンスおよびオペレーションの評価の詳細については、「Investigator を使用して SOA パフォーマンス メトリックを表示する」を参照してください。
SOA コンポーネントが関わるトランザクションを追跡する
SOA 環境では一般的に、複数のプロトコルを使用して疎結合のコンポーネント間でメッセージが渡されます。そのため、トランザクション フローの追跡は一層難しくなります。トランザクション追跡では、Web サービスがかかわる個々のトランザクションに関する詳細情報、Web サービスの障害の数と性質、コンポーネントのやり取りが提供されます。たとえば、トランザクション追跡は、トランザクションの各部分が実行された場所および実行状況をリアルタイムで特定します。その後、アプリケーション エキスパートは、それらの情報を使用して、エラーまたはパフォーマンス低下の根本原因を特定できます。
たとえば、特定の Web サービスの応答時間が遅延するなどといった問題が発生した場合、サービス レベル アグリーメント(SLA)違反が発生したり、ユーザに影響が及んだりする前に、アラートをしかるべき関係者に送ることができます。その後、アプリケーション サポート担当者は、個々のトランザクションを監視して、最も時間のかかっているトランザクションの部分、および収集された各トランザクションを完了するための同期または非同期の呼び出しシーケンスを視覚的に特定することで、その問題の性質に関する追加の詳細情報を収集できます。
複数のプラットフォームおよびトランスポートにわたって監視する
SOA パフォーマンス管理(SPM)を使用した CA Introscope では、インフラストラクチャ全体を監視および管理できます。たとえば、その対象は複数のオペレーティング システム、アプリケーション プラットフォーム、またはトランスポート プロトコルにわたるトランザクションなどです。標準の SOA 環境では、トランザクションは一般的に SOAP、XML、HTTP、HTTPS および JMS トランスポート プロトコルの組み合わせを使用します。また、複数のアプリケーション サーバ環境にわたる処理が含まれます。
SPM では、サポートされている J2EE または .NET サーバのあらゆる組み合わせにわたるトランザクションを追跡できます。たとえば、WebLogic 上で実行されているサービスが SAP NetWeaver または .NET アプリケーション サーバ上で実行されているサービスに要求を送信している場合、そのようなトランザクションを最初から最後まで追跡できます。また、追加の SOA 拡張機能を有効にすることで、Oracle Service Bus、TIBCO BusinessWorks、webMethods Integration Server、IBM WebSphere MQ コンポーネントのあらゆる組み合わせにわたるトランザクションを監視することもできます。
さらに、SOA 環境では一般的に、アダプタを通じて SOA インフラストラクチャにリンクされる
複合アプリケーション
、および SOAP や XML のような標準化されたプロトコルを使用する新しいアプリケーションの両方が含まれます。SOA 環境にはレガシー アプリケーションおよび新しいアプリケーションが含まれるため、さまざまなトランスポートおよびペイロード タイプを使用するアプリケーションを監視することが必要になる場合があります。たとえば、SPM では、SOAP over HTTP、SOAP over JMS、または XML over HTTP などの通信トランスポートおよびプロトコルを使用するアプリケーションを監視できます。
SOA 監視用のアーキテクチャについて
SPM は、CA Introscope の以下の軽量コンポーネントを提供します。
  • Java または .NET エージェント対応の SOA パフォーマンス管理(SPM)の拡張機能
エージェント拡張機能により、エージェントは、サポートされているアプリケーション サーバ上の Java と .NET ベースの Web サービスを監視し、Enterprise Manager にそれらの Web サービスのパフォーマンスに関する情報を送信できます。
Enterprise Manager 向けの SOA 固有の拡張機能により、エージェントによって収集された SOA 固有の情報を、CA Introscope Workstation を使用して、SOA 固有の依存マップ、Investigator ノード、およびタブに表示できるようになります。
以下の図は、2 台のアプリケーション サーバ用のエージェントおよび CA APM を備えた基本的なアーキテクチャを示しています。アプリケーション サーバは、Web サービス要求の送信および受信を行い、Web サービス データを SPM が有効な単一の Enterprise Manager にレポートします。
APM for SOA
その他の SOA プラットフォームのサポート
SPM モジュールにより提供される機能以外にも、監視可能な SOA プラットフォームがいくつかあります。組織の環境に応じて、以下の追加の SOA プラットフォームを監視することもできます。
  • Oracle Service Bus (OSB)。Oracle WebLogic 用にメッセージ配信および変換を処理する Enterprise Service Bus です。
  • TIBCO BusinessWorks。ビジネス サービスの開発および処理エンジンです。
  • TIBCO Enterprise Message Service。キュー、トピック、拡張コンポーネント(ブリッジ、マルチキャスト チャネル、ルートなど)を使用して、エンタープライズ全体にわたり、システム間の同期および非同期通信が可能です。
  • webMethods Broker。ドキュメントを公開および配信するための、非同期処理およびメッセージ通信処理サービスを提供します。
  • webMethods Integration Server。組織でビジネス プロセスおよび Web サービスの作成、組み合わせ、統合が可能になる、インフラストラクチャ コンポーネントを提供します。
ほとんどの SOA プラットフォーム拡張機能では、固有のファイルがエージェントと Enterprise Manager に追加されます。たとえば、以下の図では、アプリケーション サーバおよび Enterprise Manager に SOA Extension for TIBCO BusinessWorks が追加されていることを示しています。
TIBCO BusinessWorks and SOA
 
一部の SOA 拡張機能には、エージェントを使用できません。たとえば、SOA Extension for TIBCO Enterprise Message Service は、スタンドアロン エージェントを使用します。各 SOA 拡張機能の詳細については、その拡張機能に関する該当する章を参照してください。