[object Object]

Apdex (Application Performance Index) は、Web アプリケーションと IT サービスの応答時間に対するユーザーの満足度を測定するために、エンタープライズ ソフトウェア会社の連合によって開発されたオープン業界標準です。

Apdex は、平均またはパーセンタイルの応答時間指標のみに依存するのではなく、技術的な遅延指標を、エンドユーザーの満足度を直接反映する 0.0 (許容できない) から 1.0 (優れた) までの単一の標準化されたスコアに変換します。

回答優先のまとめ

Apdex スコアは、アプリケーションの応答時間を、ユーザーの満足度を測定する 0.00 から 1.00 までの単一の正規化された指標に変換します。リクエストは、目標応答時間 $T$ (通常 200 ミリ秒から 500 ミリ秒) に基づいて、満足 ($\le T$)、許容中 ($> T \text{ および } \le 4T$)、および不満 ($> 4T$ または HTTP 5xx エラー) に分類されます。式は $\text {Apdex} _T = (\text {Satisfied} + (\text {Tolerating} / 2)) / \text{合計サンプル数}$ です。0.94 を超える Apdex スコアは優れたパフォーマンスを表しますが、0.70 未満のスコアは、直ちにエンジニアリングの最適化が必要なユーザーの深刻なフラストレーションを示します。

Apdex スコアの計算方法

Apdex の計算では、定義された応答時間目標しきい値 $T$ ($200\text {ms} $ など) に基づいて、すべてのユーザー リクエストが 3 つの異なるパフォーマンス ゾーンのいずれかに分類されます。

1. 満足: 応答時間 $\le T$ のリクエスト。ユーザーは最適な応答性を体験し、ためらうことなくワークフローを進めることができます。
2. 許容範囲: 応答時間が $> T$ および $\le 4T$ のリクエスト。ユーザーはわずかな遅延に気づきますが、アプリケーションを放棄することなくタスクを完了できます。
3. 不満: 応答時間が $> 4T$ のリクエスト、または HTTP エラー (5xx ステータス コード) が発生するリクエスト。ユーザーは、許容できないほどの動作の遅さや完全なサービスの停止を経験します。

Apdex スコアの数式は次のように表されます。

$$\text {Apdex} _T = \frac{\text{満足した数} + \frac{\text{許容できる数}}{2}}{\text{総サンプル数}}$$

実用的な数学的例

目標しきい値 $T = 200\text {ms} $ を持つ 1 時間の監視ウィンドウで 10,000 リクエストを受信する SaaS アプリケーションを考えてみましょう。

• 満たされたリクエスト ($\le 200\text {ms} $): 8,500
• リクエストの許容範囲 ($200\text {ms} < t \le 800\text {ms} $): 1,000
• 不満のリクエスト ($> 800\text {ms} $ または 5xx エラー): 500

これらの値を Apdex 式に代入すると、次の結果が得られます。

$$\text {Apdex} _ {200} = \frac{8500 + \frac {1000} {2}} {10000} = \frac{8500 + 500} {10000} = \frac{9000} {10000} = 0.90$$

Apdex スコア 0.90 は 良い カテゴリに分類されます。これは、ほとんどのユーザーが高速なエクスペリエンスを享受している一方で、リクエストの 15% で最適化が必要な遅延やエラーが発生していることを示しています。

Apdex 評価スケールとスコア カテゴリ

Apdex Alliance は、数値スコアを実用的なエンジニアリング目標に変換するために、5 つの標準化された評価範囲を定義しています。

適切なターゲットしきい値 $T$ の選択

適切な目標しきい値 $T$ を選択することは、実用的な Apdex スコアを取得するために重要です。$T$ の設定が高すぎる場合 (たとえば、$2000\text {ms} $)、遅いリクエストは誤って満足として分類されます。逆に、$T$ の設定が低すぎる場合 ($20\text {ms} $ など)、通常のネットワーク遅延によりアプリケーション スコアが不必要に低下します。

アプリケーション タイプ別の推奨ターゲットしきい値:

• API とマイクロサービス: $T = 100\text {ms} - 200\text {ms} $
• 対話型 SaaS Web アプリケーション: $T = 200\text {ms} - 400\text {ms} $
• 電子商取引商品ページ: $T = 300\text {ms} - 500\text {ms} $
• ヘビー メディアおよびコンテンツ プラットフォーム: $T = 500\text {ms} - 1000\text {ms} $

Apdex が平均応答時間を上回る理由

従来の監視ツールは、平均応答時間を頻繁に報告します。ただし、平均値は次の理由により非常に誤解を招く可能性があります。

1. 異常値のスキュー: 少数の極端な 30 秒のタイムアウトにより、数千の高速 50 ミリ秒リクエストの平均応答時間が人為的に増大し、誤ったアラームが発生する可能性があります。
2. 二峰性ディストリビューション: アプリケーションがキャッシュされた静的アセットを 10 ミリ秒で処理し、キャッシュされていない複雑なデータベース クエリを 2000 ミリ秒で処理する場合、平均 1005 ミリ秒はどちらのユーザー エクスペリエンスも正確に表しません。
3. ユーザー中心の正規化: Apdex は、応答メトリクスを人間が理解できる 0 から 1 のスコアに正規化し、技術者以外の関係者、製品マネージャー、幹部がテレメトリの深い専門知識を必要とせずに長期的に追跡できるようにします。
4. エラーの重み付け: Apdex は、HTTP 5xx サーバー エラーとネットワーク タイムアウトをフラストラテッド リクエストとして自動的に処理し、可用性エラーをパフォーマンス インデックス内に直接キャプチャします。

Apdex 対 Core Web Vitals (LCP および INP)

Apdex はもともとサーバー側の応答時間と APM ツールのために開発されましたが、最新の Web パフォーマンス エンジニアリングでは、Apdex と Google の Core Web Vitals を組み合わせる必要があります。

• Apdex: すべての HTTP リクエストにわたるバックエンド サーバーの応答時間と API 処理遅延を測定します。
• 最大コンテンツフル ペイント (LCP): 最大のコンテンツ要素がユーザーのビューポートでレンダリングを終了するときのフロントエンドのビジュアル読み込み速度を測定します。
• Interaction to Next Paint (INP): ユーザー インタラクション (クリック、タップ、キーストローク) 中のフロントエンド UI の応答性を測定します。

バックエンドの Go/Gin API エンドポイントの Apdex をフロントエンドの Nuxt 4 アプリケーションの LCP および INP とともに追跡することで、エンジニアリング チームはサーバー側とクライアント側の両方のパフォーマンスにわたるエンドツーエンドの可視性を実現します。

Apdex を継続的監視ワークフローに統合する

SimpleOps は、登録されているすべての HTTP エンドポイント、Web アプリケーション ルート、API マイクロサービスにわたる Apdex スコアを自動的に追跡します。SimpleOps は、15 以上のグローバル チェック ロケーションからの合成プローブ ping と実際のユーザー テレメトリを組み合わせることで、アプリケーションの Apdex スコアが設定された SLO しきい値を下回るたびに、Slack、Telegram、または Webhook 経由でエンジニアリング チームに警告を発します。

DevOps チームは、合成稼働時間や Core Web Vitals と並行して Apdex を監視することで、世界中のユーザー集団の可用性とパフォーマンス品質の両方を完全に可視化し、顧客の離脱を防ぎ、ビジネス収益を保護します。