Loading article…
情報技術およびシステム管理の分野では、アプリケーションパフォーマンス管理（APM ）は、ソフトウェアアプリケーションのパフォーマンスと可用性の監視と管理です。APMは、期待されるサービスレベルを維持するために、複雑なアプリケーションパフォーマンスの問題を検出および診断することを目指します。APMは「 ITメトリクスをビジネス上の意味（つまり価値）に変換すること」です。 [ 1 ]
多くのツールベンダーは、監視という用語を可観測性という用語に置き換えました。監視はデータ収集の技術的なプロセスと見なされることが多いのに対し、可観測性はシステムの動作を理解する能力と見なされます。[ 2 ]
2種類のパフォーマンス指標が綿密に監視されます。1つ目のパフォーマンス指標は、アプリケーションのエンドユーザーが体感するパフォーマンスを定義します。パフォーマンスの一例として、ピーク負荷時の平均応答時間が挙げられます。この指標群の構成要素には、負荷と応答時間が含まれます。
2番目のパフォーマンス指標セットは、アプリケーションが負荷に対して使用する計算リソースを測定し、負荷をサポートするのに十分な容量があるかどうか、およびパフォーマンスのボトルネックの可能性のある場所を示します。これらの量を測定することで、アプリケーションの経験的なパフォーマンスベースラインが確立されます。ベースラインは、パフォーマンスの変化を検出するために使用できます。パフォーマンスの変化は外部イベントと相関付けられ、その後、アプリケーションのパフォーマンスの将来の変化を予測するために使用できます。[ 4 ]
APM の使用は Web アプリケーションで一般的であり、Web アプリケーションはより詳細な監視技術に最も適しています。[ 5 ]ユーザーの応答時間を測定することに加えて、Web アプリケーションのコンポーネントの応答時間も監視して、遅延の原因を特定するのに役立ちます。アプリケーションの Web サーバー層でトランザクション固有の応答時間をデコードできるHTTPアプライアンスも存在します。
Gartner Researchは、APMの概念フレームワークにおいて、 APMの5つの側面について説明しています。[ 6 ] [ 7 ] [ 8 ] [ 9 ]
2016年、ガートナーリサーチは定義を更新し、3つの主要な機能的次元に分類しました。[ 10 ]
アプリケーションのパフォーマンス測定はオーバーヘッドを伴い、ユーザーエクスペリエンスにも影響を与える可能性があります。オーバーヘッドは、監視対象イベントの数を減らす[ 11 ]、シリアル化前にデータを集約する[ 12 ]など、いくつかの技術的対策によって削減できます。
2013 年前半以降、APM は多数のベンダーと見解による技術と戦略の激しい競争の時代に突入しました。[ 13 ]これにより、ネットワーク監視、システム管理、アプリケーション計測、Web パフォーマンス監視など、関連性のないバックグラウンドを持つベンダーが APM に関するメッセージを採用するなど、市場に混乱が生じました。その結果、APM という用語は希薄化し、単一の市場ではなく、多様なコンピューティング プラットフォームにわたるアプリケーション パフォーマンスの管理の概念へと進化しました。[ 14 ]選択できるベンダーが非常に多いため、1 つを選択するのは困難です。それぞれの機能がニーズを満たしていることを確認するために、各ベンダーを慎重に評価することが重要です。[ 15 ]
APM を実装する際の 2 つの課題は、(1) アプリケーションのパフォーマンスを監視するためにアプリケーションを計測することが難しい場合があり、特にアプリケーションのコンポーネント間では困難であること、および (2) アプリケーションが仮想化される可能性があり、これにより測定の変動性が増大することです。[ 16 ] [ 17 ]最初の問題を軽減するために、アプリケーション サービス管理(ASM) は、ビジネス サービスのパフォーマンスの可視性を主要な目的とするアプリケーション中心のアプローチを提供します。分散型、仮想型、クラウド ベースのアプリケーションに存在する 2 番目の側面は、主要なシステム コンポーネントのほとんどが単一のマシンでホストされなくなったため、アプリケーション パフォーマンス監視に特有の課題をもたらします。各機能は、複数の仮想化システムで実行されるインターネット サービスとして設計されている可能性が高くなっています。アプリケーション自体は、サービス レベルの目標を達成し、一時的な障害に対処するために、あるシステムから別のシステムに移動する可能性が非常に高くなっています。[ 18 ]
アプリケーション自体は、多くの場合 .NET や Java などのアプリケーション開発フレームワークに依存する、高度に分散された、マルチティア、マルチ要素の構造へと移行するにつれて、管理がますます困難になっています。[ 19 ] APM 概念フレームワークは、5 次元の APM モデルの迅速な実装と全体的な理解のために、最初に何に焦点を当てるべきかについてのアプローチの優先順位付けを支援するために設計されました。フレームワークのスライドでは、各次元の 3 つの重点領域の概要を示し、それらの潜在的な利点について説明します。これらの領域は以下で「プライマリ」として参照され、優先順位の低い次元は「セカンダリ」として参照されます。 [ 20 ]
ユーザー要求からデータ、そして再びユーザー要求へとトラフィックが移動する様子を測定することは、エンドユーザーエクスペリエンス（EUE）を把握する上で重要な要素です。[ 21 ]この測定結果はリアルタイムアプリケーション監視（別名トップダウン監視）と呼ばれ、受動的監視と能動的監視の2つの要素から構成されます。受動的監視は通常、ネットワークポートミラーリングを使用して実装されるエージェントレスアプライアンスです。考慮すべき重要な機能は、マルチコンポーネント分析（データベース、クライアント/ブラウザなど）をサポートする機能です。[ 22 ]一方、能動的監視は、システムの可用性とビジネストランザクションを報告するために事前に定義された合成プローブとWebロボットで構成されます。能動的監視は受動的監視の良い補完となります。これら2つの要素を組み合わせることで、トランザクション量が少ないオフピーク時間帯のアプリケーションの状態を可視化することができます。[ 23 ]
ユーザーエクスペリエンス管理（UEM）は、ユーザーの行動コンテキストを監視するためにEUEディメンションから生まれたサブカテゴリです。今日のUEMは、可用性を超えて、人間がアプリケーションやその他のサービスとやり取りする際の遅延や不整合を捉えます。[ 24 ] UEMは通常エージェントベースであり、エンドユーザーデバイスを監視するためにJavaScriptインジェクションが含まれる場合があります。UEMは、リアルタイムアプリケーション監視のもう1つの側面と考えられています。
ランタイムアプリケーションアーキテクチャを実装する準備段階では、環境内のすべてのノードとサーバーに対して稼働状況監視（いわゆるボトムアップ監視）が実施されていることを確認する必要があります。これはイベント相関の基盤を築き、ネットワークトポロジーとアプリケーションアーキテクチャの相互作用を包括的に理解するための基礎となります。
ビジネスコミュニティにとって意味のある、ユーザー定義トランザクションまたはURLページ定義に焦点を当ててください。たとえば、特定のアプリケーションに200～300個の固有のページ定義がある場合、それらを8～12個の上位カテゴリにグループ化します。これにより、有意義なSLAレポートを作成でき、ビジネスの観点からアプリケーションのパフォーマンスに関する傾向情報が得られます。まずは大まかなカテゴリから始め、時間をかけて詳細化してください。より詳しい情報については、「ビジネストランザクション管理」を参照してください。
ディープダイブコンポーネントモニタリング（DDCM）にはエージェントのインストールが必要で、一般的にはミドルウェアを対象とし、Webサーバー、アプリケーションサーバー、メッセージングサーバーに重点を置いています。DDCMは、 J2EEおよび.NETスタックのリアルタイムビューを提供し、それらをユーザー定義のビジネストランザクションに結び付けます。堅牢なモニターは、コード実行（SpringやStrutsなど）からレンダリングされたURL、そして最終的にユーザーリクエストまでの明確なパスを表示します。DDCMはAPMモデルの2番目の次元と密接に関連しているため、この分野のほとんどの製品は、提供機能の一部としてアプリケーション検出依存関係マッピング（ADDM）も提供しています。