【祝】MackerelでALBの応答速度パーセンタイル監視が可能になる反面、監視メトリックが増えることで請求額に影響があるケース【要検討】

3/30付けでALBレスポンスタイムのパーセンタイル監視が実装されるアナウンスがありましたが、それによって請求額が上昇するパターンがあります（アナウンスにも書いてあります）。具体的にどのような時に影響があるのかまとめました。

モニタリングツール特集

#Mackerel

#監視サービス

#Application Load Balancer（ALB）

#AWS

渡辺聖剛

2020.03.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Mackerel の ALB 監視において、レスポンスタイムのパーセンタイル値が監視できるようになる、というアナウンスがありました！

「パーセンタイルとはなんぞ？」という方は↓の弊社佐々木の記事をご参照頂ければと思いますが、大部分端折って誤解を恐れず簡単に言えば一時的なスパイクや突発的なイレギュラーに踊らされず、大局をみることができる値といえます。

具体的には、ALBならびにそのターゲットグループ（TG）について、それぞれ 3メトリックずつが増えることになります。

90パーセンタイル
95パーセンタイル
99パーセンタイル

仕様変更は、ほぼ2週間後の 4/14 を予定しているとのこと。Mackerel でこれらの値が監視できるようになったことはとても喜ばしいのですが、その対価として、1 ALB あたりの監視コストが上昇するケースがあります。「あります」というか、多くのケースで上昇します。
そちらについて、以下詳しくご紹介します。

要は

ALBに設定されているターゲットグループ（TG）の数に依存します。AWSインテグレーション機能で取得できる全てのメトリックを収集していると仮定した場合、以下のようになります。

TG x1 ... 現状 1マイクロホスト(MH)換算だったものが 2MH 換算に（+1）
TG x4 ... 現状 2 MH 換算だったものが 3MH 換算に（+1）
TG x6以上 ... TG数に応じて MH数が +1〜される

ざっと表にしてみました。

ひとつの ALB にひとつの TG、という使い方をしている場合は軒並み該当することになりますね。

何故そうなる？

Mackerelの課金は「ホスト単位（スタンダードホスト・マイクロホスト単位）」で行われます。
そしてそれぞれに、収集されるメトリック数の上限が設定されています。スタンダードホストは200、マイクロホストは30です。ALBは（Mackerelの定義において）マイクロホストなので、30メトリックまでは 1台、それを超えると 30メトリック毎に +1台として計算されます。

従来、ALB 1つに対して収集されるメトリックは下記の計算式で算出できました。

15 + 10 × (ターゲットグループ数)

これは「ALB のロードバランサーに対して収集されるメトリック数 15 + ターゲットグループ（TG）毎にメトリック数 10」という意味です。
つまり、TG が 1なら 15+10 = 25、TG が 2 なら 15 + 10 x 2 = 35 となります。

ホスト台数は 30で割って少数点切り上げすればいいので、 TG x 1で 1 ( 25/30 ≒ 0.83)、TG x 2 で 2 ( 35/30 ≒ 1.17) となります。

さて。
今回の仕様変更により、ALB ロードバランサーに対して収集されるメトリックが 15 -> 18 に、ターゲットグループ毎に収集されるメトリックが 10 -> 13 にそれぞれなりました。式にするとこうなります。

18 + 13 × (ターゲットグループ数)

つまり、TG x 1 なら 18+13 = 31(メトリック) = 2 マイクロホスト ( 31/30 ≒ 1.03) となります。現在の仕様の時より +1 されてますね。
一方で TG x 2 なら 18 + 13 x 2 = 44 = 2 マイクロホスト ( 44/30 ≒ 1.47) となり、この場合は変化がないことになります。

現状の確認

ALB に設定されているターゲットグループの数は、もちろんAWSのマネジメントコンソールで確認することもできますが、Mackerel上であれば、Hostsから該当ALBの詳細画面を開くことで確認できます。

上部右側「ALB Instance Info」内の Target Groups 欄に、現在接続されているターゲットグループが記載（複数あればコンマ区切り）
右ペイン下「ホスト情報」内のメトリック数で判断

回避するには？

上で説明したとおり、今回の仕様変更がコストに反映されるのはメトリック数が増えたためです。
ということはつまり、仕様変更後もメトリック数を減らせばコスト上昇にはならないことになりますね。例えばターゲットグループ x1 の場合、なにかひとつメトリック収集を止めれば 1 マイクロホストの範囲に収まることになります（ 18 + 13 - 1 = 30）。

収集するメトリックは、Mackerel の AWS インテグレーション設定画面で変更可能です。方法は↓のドキュメントに記載がありますが、当然ですが収集しないメトリックに対してはグラフも表示されませんし、それに対してアラート通知させることも出来なくなります。

どのメトリックが重要かは環境によるのでうかつなことは言えませんが、例えばMackerelでは異常検知・トラブル通知を主目的として使っている場合は、 HTTPCode_Target_2XX_CountやHTTPCode_Target_3XX_Countは不要という判断が、あるいは SSL 証明書の異常検知はURL外形監視に任せるということであれば、Mackerel においては TLS 周りのメトリックは不要という判断が可能かも知れません。
それぞれのメトリックがどのような意味を持っているかは、AWSのドキュメントを是非ご参照ください。

なお、収集するメトリックを少なくしても、それが直ちにアクティブホスト数に反映されるわけではありません。Mackerelのホスト数計算は「1時間程度以内の間隔で定期的に」計測されるためです。また課金計算の元となるホスト台数は「過去一ヶ月分の移動平均」ですので、 4/14 以降、はやめに台数を削減すれば、コストへのインパクトを最小に抑えることができると思われます。