アプリケーション・パフォーマンス・インデックス(Apdex)スコアは、組織のWebアプリケーションおよびサービスの応答時間に対するユーザーの満足度を測定するオープン標準の定量的メトリクスです。
組織は、ITアプリケーションに関連する多くのパフォーマンス・メトリクスを収集して、パフォーマンスをより深く理解し、問題を検出し、アプリケーションの全体的な健全性を向上させる方法を特定するよう求められています。これらのメトリクスはすべて、全体的なユーザー満足度の向上に貢献します。一方、多岐にわたるメトリクスを照合して、アプリケーションが適切に動作しているかどうかを簡単に把握するのは難しい場合があります。ここで役に立つのがApdexスコアです。これは、アプリケーションの応答時間が設定されたしきい値を下回っているか上回っているかに基づいて顧客満足度を特定します。
Apdexスコアは、アプリケーション・パフォーマンス監視とも呼ばれるアプリケーション・パフォーマンス管理(APM)のコンポーネントとしてよく採用されます。
結果として得られるApdex値は、0から1までの均一なスケール(0は不満、1は満足)でユーザー満足度を表す数値的尺度です。これは、読み込み時間が「1」遅い(例えば、これを「1分かかる」と意味するとします)ことで歪められる可能性がある平均応答時間の数値よりも、読み込み時間に対するユーザー満足度をよりバランスよく理解することを目的としています。Apdexスコアは、1つの集計スコアを作成するのではなく、応答時間の各インスタンスを個別に扱います。
NetForecast社の創設者であるPeter Sevcik氏は、アプリケーション品質を測定するためのシンプルで一貫性のあるオープン・スタンダードの可能性を最初に提起しました1。この認識に基づき、業界の専門家グループを率いて、Apdex技術仕様を発表しました。この技術仕様が発表されるとすぐに、Apdex AllianceがApdex標準により採用され、現在では多くの組織で使用されています。
Apdexスコアを維持することは、多くの組織にとってほぼリアルタイムの主要業績評価メトリクス(KPI)を提供します。アプリケーションの応答時間を報告、ベンチマーキング、評価し、ユーザー満足度を評価するフレームワークを作成します。この最終目標は優れたユーザー・エクスペリエンスを提供することです。
Apdexスコアの特定は、組織が許容できるとみなす応答時間を示すApdexしきい値を設定することから始まります。しきい値を一定にすると、組織は時間の経過に伴う変化を追跡しやすくなります。すべての組織が使用する普遍的なしきい値は存在しないため、すべての組織が独自の応答時間のしきい値を特定する必要があります。
組織は通常、いくつかの要素に基づいて独自のしきい値を決定します。
Apdexスコアは、設定されたしきい値に基づいてアプリケーションの読み込み時間を決定するための比率スコアです。各ユーザー・エクスペリエンスは、ユーザーが経験した読み込み時間に基づいてApdexスコアに寄与します。
ユーザー・エクスペリエンスは、次の3つのカテゴリーのいずれかに分類されます。
Apdexスコアは、満足できる応答時間(満足カウント)を許容応答時間(許容カウント)の半分に追加し、サンプルの総数で割ることによって決定されます。
Apdexスコアは、0(どのユーザーも満足していないことを意味する)から1(すべてのユーザーが満足していることを意味する)の範囲で表示されます。Apdexスコアが低い場合、組織はAPM、問題管理、サイト信頼性エンジニアリングなどの実践を通じて、問題のトラブルシューティング能力とパフォーマンスの最適化能力を向上させる必要があるかもしれません。
Apdexスコアが低いということは、組織の現在のITオペレーションに問題があることを示している可能性があります。ここでは、組織がApdexスコアを向上させる方法の例とユースケースをいくつか紹介します。
コードとデータベース・クエリーを最適化:データベースの構成が適切でなく、コードが非効率的な組織では、Apdexスコアが低くなる可能性があります。例えば、標準以下のコードは必要以上にCPUとメモリーのリソースを必要とし、これにより読み込み時間が遅くなるかもしれません。この場合、コードとデータベース・クエリーを最適化することが、Apdexスコアを向上させる最善の方法です。
外部リクエストを最小限に抑える:サードパーティのサービスへのAPI呼び出しを行うと、Webサービスに大きな負担がかかり、レイテンシーが増大する可能性があります。Apdexスコアが低い組織は、外部リクエストを再検討して、リクエストが必要かつ価値があり、レイテンシーが大幅に増えないことを確認する必要があります。
コンテンツ配信ネットワーク(CDN)を使用する: CDN は、地理的に分散したサーバーのシステムであり、企業はこれを使用して、ユーザーに最も近いサーバーを介してリクエストを完了し、ユーザーにコンテンツをより迅速に配信します。例えば、ドイツのユーザーがニューヨークでホストされているコンテンツを含むWebページのコンテンツにアクセスしたい場合、ユーザーのリクエストはニューヨークのサーバーではなく、ヨーロッパにある会社のエッジ・サーバーから満たされます。これにより、データが移動する距離が短縮され、待ち時間が短縮されます。
負荷の高い作業には非同期処理を使う: 非同期処理は、相互通信環境において、アプリケーションに必要な処理をシステム間で分散することを可能にします。非同期処理は、負荷の高い作業を別のプロセスに振り分けることでリソースへの負荷を解放して、メインスレッドがユーザーの要求に対処できるようにします。
トラフィックの増加に対応したサーバーの拡張: サーバー容量を増やしたり、ロードバランシングを使用したりすることなく、トラフィックが大幅に増加すると、レスポンスタイムが低下する可能性があります。IBM® Turbonomicのように、リアルタイムの需要に基づいてネットワーク・リソースの割り当てを積極的に自動化するプラットフォームを使用すると、この問題を軽減できます。
Apdexスコアを使用してパフォーマンスを追跡する組織は、次のような複数のメリットを享受できます。
Web応答時間の短縮:Apdexスコアを追跡すると、組織はアプリケーションとサービスのパフォーマンスをより正確に把握できます。この情報により、応答時間が短縮され、組織は関連コンテンツをユーザーに迅速に提供できるようになります。
ユーザーの満足度の向上:Apdexスコアに重点を置く組織は、ユーザー・エクスペリエンスをより意識し、それに応える可能性が高くなります。Apdexスコアを継続的に監視して改善することで、不満を抱くユーザーが減り、組織の強力な支持者となる可能性のある顧客の満足度が向上します。
サービス・レベル契約(SLA)の遵守:組織のSLAでは、アプリケーションの読み込みにかかる時間を指定できます。読み込み時間がSLAで指定された時間よりも一貫して長い場合、組織はユーザーとの契約に違反している可能性があります。
データに基づく意思決定: Apdexスコアを追跡すると、ビジネス・リーダーは信頼性の高いデータを入手でき、Webアプリケーションのパフォーマンスについてより情報に基づいた意思決定を行うことができます。他社での事例や正確性の低いメトリクスに頼るよりも、顧客満足度を追跡するためのより体系的なシステムを構築できます。
IBM Instana Observabilityでアプリケーション・スタック全体を自動的に観察、監視、修正します。
カスタム・アプリケーションのポートフォリオ全体で、最高の性能と高いユーザー満足度を提供します。
Full Stack Observabilityと自動化されたアプリケーション・リソース管理を橋渡しし、顧客体験に影響を与える前に性能の問題に対処します。
1 Apdexの歴史、Apdex.org