# Apdex ## 定義 Apdex(Application Performance Index、アプリケーションパフォーマンス指標)は、アプリケーションのパフォーマンスや可用性が条件を満たす頻度を表す指標である。ユーザ対面 SLA を構築する際にサービスレベルを単純な数値へ圧縮する手段として使われる。算出手順は次の4段階である。(1) 性能指標を決める(例: 「ログインページを2秒以内に読み込む」)。(2) 読み込まれたトランザクションを、目標時間内なら「満足」、目標時間の4倍未満なら「許容」、4倍以上または読み込み失敗なら「不満」の3等級に分類する。(3) 次の式でスコアを計算する。(4) 結果は0から1の値になり、1はすべてのトランザクションが性能指標以内に完了したこと、0はすべてのユーザが不満を感じたことを意味する。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 11 訪問者の気持ち：ユーザ対面メトリクス]] §11.4.1) $\text{Apdex スコア} = \frac{\text{満足の数} + \text{許容の数} / 2}{\text{合計の数}}$ 満足・許容・不満という3値の合計値だけでサイト・ページ・時間ごとの Apdex を算出でき、性能指標がページごとに異なっていても、計測値の数が多かろうと少なかろうと使える点が特徴である。単純さゆえに経営層にも理解されやすく(本章は「経営者は、ゴルフのスコア計算より難しいものは理解できない」と評する)、複数チーム・複数システム間の比較に使われる共通言語として機能する。(Source: ch.11 §11.4.1) ## 横断的知見 - **標準化された統計的手法(Apdex)対、現場に根付いた「マジックナンバー」——同じ「単一の閾値でレスポンス品質を判定する」設計が、対照的な正当化の道筋を辿る**: 11章のApdexは、目標時間・目標の4倍・失敗という3等級を apdex.org の標準仕様に基づいて定義し、複数チーム・複数システム間の比較に使える共通言語として設計されている。これに対し18章([[Cookpad|クックパッド]])は、リバースプロキシベースの平均レスポンスタイム200msecという単一の閾値を「マジックナンバーのようなものだが、エンジニア全員に根付いている」と明言し、統計的な導出の手続きを経ていない経験則として運用する。Apdexが「なぜこの値か」を仕様(4倍という倍率)によって外部から正当化しようとするのに対し、18章の200msecは「チームが体感として合意している」という内部的な正当化に留まる。両者とも単一閾値による3値(または2値)判定という同じ骨格を持ちながら、閾値の妥当性の根拠づけ方が対照的である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 11 訪問者の気持ち：ユーザ対面メトリクス]] §11.4.1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.2) - **18章は、Apdexが抽象化する「満足/許容/不満」の3値判定を、赤/非赤の2値判定と5秒間隔の常時可視化という、より単純だが即応性の高い運用に落とし込んでいる**: Apdexはトランザクション単位のスコアを(満足数+許容数/2)/合計数という式に圧縮し、経営層にも伝わる単純さを狙う。18章の実装は、200msecを超えたかどうかだけをオフィス中央のディスプレイ上で赤色表示するという、さらに単純な2値の可視化に絞り込んでおり、その代わり5秒単位というリアルタイム性でエンジニアの端末・携帯電話への即時通知を実現している。Apdexが「経営層への報告」という比較的低頻度な用途に向けた圧縮指標であるのに対し、18章の赤色表示は「エンジニアの即応」という高頻度な運用に向けた圧縮であり、同じ単一閾値判定でも圧縮の目的によって設計が分岐することを示す一事例である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 11 訪問者の気持ち：ユーザ対面メトリクス]] §11.4.1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.2) ## 未解決の問い - 「目標時間の4倍」という許容の閾値は Apdex の標準仕様(apdex.org)に由来するが、本章はこの倍率の根拠(なぜ2倍や3倍でないか)を説明していない。倍率の妥当性はどのような実証で支持されているか。 - Apdex スコアは単一の性能指標(例: 2秒)を前提に3等級化するが、[[SLO目標値の選定]] が扱うような複数パーセンタイル(p50/p95/p99)ベースの SLO 設計とはどう対応づけられるか。Apdex は情報を大きく圧縮する分、パーセンタイル分布が持つ詳細(外れ値の偏り等)を失う可能性がある。 - Apdex はトランザクション単位のスコアだが、[[統合監視]] と [[リアルユーザモニタリング]] のどちらのデータソースから算出するかによってスコアの意味(疑似アクセスの結果か実訪問者の結果か)がどう変わるかは本章では明示的に区別されていない。 - 18章の200msecという「マジックナンバー」は、なぜ200msecという値に落ち着いたのか(統計的根拠の有無)を明示していない。Apdexのような標準化された導出手続きなしに、現場の経験則として閾値が定着するプロセス(いつ・どう合意形成されたか)は、本章・本wikiのどのソースにも記録がない。組織固有の閾値がApdex的な標準仕様に「昇格」する、あるいはしないための条件は何か。 ## 関連 - 概念: [[エンドユーザメトリクス]](ユーザ対面SLAの構成要素) / [[統合監視]] / [[リアルユーザモニタリング]](Apdex算出のデータ源) / [[可用性]] / [[SLO目標値の選定]] - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 11 訪問者の気持ち：ユーザ対面メトリクス]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]](200msecという経験則的閾値の対比事例) - エンティティ: [[Alistair Croll]] / [[Sean Power]] / [[Cookpad]] ## 出典 - アリステア・クロール、シーン・パワー, 「11章 訪問者の気持ち：ユーザ対面メトリクス」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §11.4.1(原典: http://www.apdex.org). - 濱崎 健吾, 「18章 日本の料理のインフラ」, 同書, §18.2.