はじめに
この記事は「これからこういうのを試しにやってみようと思う」という内容の記事であり, うまくいくかどうかは執筆時点では完全に未知数です.
Apdexとは
New RelicのApdexはWebサービス全体の速度性能を知るのに便利な指標です.
平均応答時間なんかの指標よりユーザーの満足度を測れるというように説明されています.
参考: https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measuring-user-satisfaction
Apdexでは目標時間Tを設定し, リクエストを以下のように分類します.
- 満足: T以下のリクエスト
- 許容: T以上かつ4T以下のリクエスト
- 不満: 4T以上または500などのエラーが発生したリクエスト
この分類を使って以下の式で算出されます.
Apdex = (満足リクエスト数 + 許容リクエスト数 / 2) / 総リクエスト数
例えばTを0.5秒に設定してあるサービスで以下のようなリクエストが発生していると
| 0.5秒以下のリクエスト | 0.5秒以上2.0秒以下のリクエスト | 2.0秒以上またはエラーのリクエスト |
|---|---|---|
| 80 | 14 | 6 |
Apdex = (80 + 14/2)/100 = 0.87
というように計算できます.
APP SERVER ApdexとBROWSER Apdex
New RelicではAPP SERVERとBROWSERの2種類のApdexを見ることができます.
APP SERVERのほうはAPMに付属する機能で, BROWSERはそのまんまBROWSERに付属する機能です.
目標時間Tもそれぞれ設定することができ, デフォルトではAPP SERVERは0.5秒, BROWSERは7.0秒に設定されています.
APP SERVERは「アプリケーションにリクエストが到達してからレスポンスを返すまで」の秒数のことです.
もっと具体的な計測時間の定義は恐らく言語ごとのNew Relic Agentの仕様次第だと思います.
BROWSERのほうはリンクのクリックからLoadイベントの発火までの秒数のことです.
(と思われます. これが明示されている資料が見つからなかったので このページ とかから推測しました. 正しい情報知ってる方教えてください.)
Apdexの問題点
Apdexは良い指標だとは思うんですが, 以下の点ではちょっと使いづらくね?と感じていました.
- 複数サービスの比較に使おうとすると数字の解釈が難しい
- Apdexの改善がどのくらいのインパクトなのか説明しづらくKPIに設定できない
それぞれちょっと説明します.
1. 複数サービスの比較に使おうとすると数字の解釈が難しい
4つWebサービスでBROWSERの目標時間Tをそれぞれ別に設定していて, 以下のようにApdexが表示されていたとします.
| サービスA | サービスB | サービスC | サービスD | |
|---|---|---|---|---|
| T | 9 | 9 | 5 | 4 |
| Apdex | 0.97 | 0.97 | 0.64 | 0.57 |
さてサービスAとサービスBではどちらのほうが優れているでしょうか?
あるいはサービスCとサービスDではどちらが優れているでしょうか?
個別に詳細な数字を見ていけばこの質問は答えられるでしょうが, 正直めんどくさいですしその程度の質問にはぱっと答えられるような指標を使いたいところです.
実際にはここまでハチャメチャなことになっている例はないかもしれませんが, 各サービスの担当者が各々適当にTを設定していると容易にこの状態に陥ります.
2. Apdexの改善がどのくらいのインパクトなのか説明しづらくKPIに設定できない
これはほとんど言葉の通りです.
たとえば先程の表のサービスCがApdexを0.75に改善できたとします.
これはどのくらいすごいことなのでしょうか? ユーザーはどのくらい嬉しいのでしょうか?
これもApdexだけを見るのではなく詳細な数字を見ればわかりますが, やっぱり調べるのめんどくさいですよね.
このような指標では**「今期の目標は0.64のApdexを0.8にすることです!」**と言ったところで目標の妥当性も達成したときのユーザーへのインパクトや達成感もなんだかよくわからないということになってしまいそうです.
問題点を解消する試み: Apdexを0.95に固定しTの設定をKPIとする
ここから本題です.
New Relicのブログで「こういう感じでT決めたらいいやん」というのが提案されています.
https://blog.newrelic.com/2017/06/29/how-to-choose-apdex-t/
要約すると
リクエスト全体の90パーセンタイルのレスポンスタイムで設定しておくと大抵の場合Apdexは0.95になるよ.
80パーセンタイルならApdexは0.90になるよ.
なんでかというと大抵のWebサービスが示すリクエスト数とレスポンスタイムの分布モデルがそういう感じになってるからだよ.
ということらしいです.
90パーセンタイルのレスポンスタイムはINSIGHTSのNRQLを使うと調べることができます.
SELECT percentile(duration, 90) FROM Transaction WHERE appId = APPID SINCE 1 week ago
SELECT percentile(duration, 90) FROM PageView WHERE appId = APPID SINCE 1 week ago
これを使って, 全サービスのApdexが0.95になるようにTの設定値を変更してみます.
複数サービスの比較が簡単になる
先程の表にこれを当てはめてTを変更してみると, Tの値が小さいほうが優れている! と断言できるようになり, 比較が簡単になりました.
| サービスA | サービスB | サービスC | サービスD | |
|---|---|---|---|---|
| T | 7.9 | 7.5 | 12.5 | 12.5 |
| Apdex | 0.95 | 0.95 | 0.95 | 0.95 |
「実はサービスBのほうが少々サービスAよりも優れており, サービスCとDには差が無かった.」ということが判明しました.
非常に簡単に比較可能な指標になってくれたので, 1つ目の問題点はこれで解消されました.
Tの変更の意味を説明できる
「Apdexが0.95を示すように常にTの設定値をメンテナンスし続ける」という運用を続けると, Tの設定値をもとにしてサービスの速度性能を簡単に説明できるようになります.
前の表だとサービスAはT=7.9でApdex=0.95なので,
「少なくとも90%のリクエストにおいて7.9秒以下でのページ表示ができている」
と説明できます.
もしサービスAが改善されて, T=5.0でApdex=0.95になったとすると,
「少なくとも90%のリクエストにおいて5.0秒以下でのページの表示ができ, 以前よりも1.9秒の改善になっている」
と説明でき, 何がどのくらい変わったのかが明確です.
これならTの設定値をKPIにしてチームで改善目標を設定するというのもできそうです.
2つ目の問題点も解消されました.
Q. Tの設定値をKPIにするなら90パーセンタイルのレスポンスタイムをKPIにするのと変わらなくね?
A. そのとおりだとおもいます
90パーセンタイルのレスポンスタイムをKPIにするだけで1つ目の問題点も2つ目の問題点も解消されるので, そこだけ切り取るとApdexという指標そのものが不要に思えます.
ただし, 今回は以下の理由でTの設定値をKPIにする運用を採用しました.
これらの理由が当てはまるチームとそうでないチームがありそうなので, 当てはまらない場合は90パーセンタイルのレスポンスタイムをKPIにしてしまえばいいと思います.
監視にもApdexを使う
自分がいるチームではNew RelicのAlertで監視する項目の一つにApdexを入れています.
90パーセンタイルのレスポンスタイムを監視するのと比べると, Apdexの監視のほうが極端なレスポンスタイムの偏りを検知しやすいなどのメリットがあります.
ApdexはAPMのOverviewに表示されるので気分がいい
気分の問題です
監視する項目数を増やしたくない
気分の問題です
やっていき
というところまで考えました.
週に1回Apdexを見て0.95からズレていないかチェックし, Tの設定値を修正していくという運用を始めてみようと思います.
自分のチームでは四半期ごとの目標を設定しているのですが, その目標設定の中にもTの設定値を組み込んでいきます.
この目標管理の方法を社内全体に展開し, どのくらいTの設定を比較できたかを競うWeb Service Kaizen Battleを社内で繰り広げようと思っています.
たぶん数カ月後には「実際に運用してみてどうなったか」的な記事を書くことになると思います.