New Relic Advent Calendar 2017 3日目。今回も New Relic APM の Apdex の話。

前提として、前回の記事を読んでいること。今回は前回話さなかった Apdex を SLA (品質保証)として使う場合の話。企業で複数アプリを管理している場合に、効率良くパフォーマンス品質を管理、監視、改善するために Apdex がどのように役に立つのか、その使い方について。

前回も書いたけど、Apdex はそもそもこの目的で作られたもの。よって、企業や組織で、複数のサービスを運用しており、それらの品質を効率良く管理、改善したい場合の指標として、Apdex は適した指標です。

Apdex は、前回紹介した計算式によって、スコア(0 - 1)を求め、品質を評価します。

Apdex スコアのざっくりした意味は Apdex アライアンスは以下のように示しています。

(引用: http://apdex.org/apdexfaq.html)

では、このスコアや Apdex を使って、具体的にどのようにして品質の管理、改善を行っていくかを説明していきます。

Apdex を使ったパフォーマンス品質の管理、監視の流れは以下。

品質の定義(閾値の設定)
現状認識
改善対象のアプリと目標とするスコアの設定
改善

一旦、４まで進んだら、後は、2から4の繰り返しで、効率的に徐々に全体的にスコア(品質）を高めていく。

なにはなくとも最初に各アプリが目標とする品質を定義する必要がある。

Step1: 品質の定義

現状認識をするために、現在の品質である Apdex スコアを算出する。そのためには、Apdex T (閾値）を決める必要がある。前回は、この閾値は現在のアプリのパフォーマンスから決めたけど、今回は現状ではなく、理想(目標)とする秒数を決める必要がある。なにせ目標に向かって改善するのだから、現状をベースに決めてもしょうがない。

決め方は、各アプリごとに理想とするレスポンスタイム(90パーセンタイル地点)、つまり、全リクエストの内の9割がこの秒数に収まっているべきという秒数を考える。平均ではない。なぜ 90パーセンタイルなのかは前回の記事を参照。

各アプリごとに、ビジネス上の重要度(優先度)や目標とするレスポンスタイムを定義していく。

ここからは、例を使って説明していく。

以下の複数のアプリを運用しており、New Relic APM で管理しているとする。

ビジネスの優先度	アプリ	ターゲットとするレスポンスタイム(秒)
1	ECサービス	0.3
2	認証基盤	0.5
3	ECサービスの管理画面	2
4	在庫管理サービス	1
5	ダッシュボードサービス	2

上記は例だが、実際には、各企業ごとに各々の判断で閾値をどうするかは決めるしかない。

EC サービスなどは、0.2 - 0.3 秒とかと言われており、一般的なサービスは、2秒以内というのが一般的な基準とはなっているが、ターゲットとするレスポンスタイムに正解はない。

Step2: 現状認識

次に、定義した閾値(ターゲットとするレスポンスタイム)を New Relic APM の設定画面で設定し、Apdex スコアを計測する。設定変更の手順は、ここを参照。反映されるまで、30分から1日くらい待つ。

確認した結果、以下となったとする。

優先度	アプリ	Apdex スコア
1	ECサービス	0.88 [0.3]
2	認証基盤	0.63 [0.5]
3	ECサービスの管理画面	0.74 [2]
4	在庫管理	0.94 [1]
5	ダッシュボードサービス	0.58 [2]

※ [] 内の数字は、閾値を指す。

これで、現状が認識できた。

Step3: 目標とするスコアの設定

次に、Step2 の現状から、ビジネスの優先度と Apdex スコアを見て、どのアプリから改善していくかを決める。最終的に目指すべきは、Apdex スコアが 0.95 である。よって、優先度が高いが、Apdex が低いサービスが一番最初の改善対象(リソースをもっとも掛けるべき）だろう。

例えば上の現状からみると、在庫管理は、優先度は4番目なのに、Apdex スコアは 0.94 と現状でもほぼ理想どおりなので、改善の優先順位は一番最後だろう。一方、2番めの認証祈願は、ビジネス上重要にも関わらずスコアが 0.63 と非常に低い。スコアとして 5番目の方が低いが優先度も低いので後回しでいいだろう。よって、まずは、2番目の認証基盤を改善するべきだろう。

改善すべきアプリが決まったとして、まず目標とすべきスコアはいくつだろうか。何度も書いているように、理想は 0.95 だが、スコアが低いサービスをそこまで上げるのは結構たいへん(リソースが結構かかる）。ある程度まで、上げたら、一旦そこで改善を止め、その時点でビジネス上の優先度と Apdex スコアを見て、改善すべきアプリを見直すべき。では、その改善を止めるタイミングとなるスコアはいくつかだろうか。

ここまで書いておいてなんだけど、明確な答えはない。ただし、目安はある。冒頭で載せた Apdex スコアの意味がそれ。目安は、Good の最低ラインを意味する 0.85 もしくは、Fair の最低ラインを意味する 0.70 だろう。先ほどの認証基盤なら、0.7 より低いのは認証基盤と一番優先度の低いダッシュボードサービスだけなので、0.85 まで改善することを目標にするのがいいだろう。もちろん、0.7までとし、ダッシュボードサービスを改善するという手もある。そこはビジネス上の判断になる。

0.85 と 0.7 というスコアが意味する状況をざっくり書いておく (あくまで目安）。

Apdex スコア 0.85: 7割が満足、3割くらいが許容内で、不満がほぼいない状態。
Apdex スコア 0.70: 4割が満足、6割くらいが許容内で、不満がほぼいない状態。

Step 4 改善

Step 3 で決めた対象に対して、目標スコアまで New Relic APM などで遅いトランザクションや SQL などを見つけ出し、地道に改善していく。

New Relic APM PRO を使っている場合は、サービスを並べた週次の SLA レポートで簡単に Apdex スコアを知ることができる。

まとめ

以上のフローを回すことで、優先順位が高い順に効率よくパフォーマンス改善が行えるでしょう。リソースが限られているチームや組織の場合は特に役立つと思う。是非、パフォーマンスの高いアプリとなるように、Apdex を活用していただければと思う。

注: 本記事の内容は、Apdex アライアンスのサイトにある Using Apdexページを参考に作成したものです。