Mackerelを振り返りやキャパシティプランニングのために毎月眺めている

はてなでWebアプリケーションエンジニアとして働いています。今回は私が所属しているチームでどのようにMackerelを活用しているのかを紹介します。

はてなでは多くのチームで「Performance Working Group」という定例を実施している
弊チームで実施しているPWG
PWGでの細かいMackerelの活用法
- 直近1ヶ月のアラート確認
- カスタムダッシュボードの確認
まとめ

はてなでは多くのチームで「Performance Working Group」という定例を実施している

まず前提としてはてなではほとんどのチームで「Performance Working Group」略してPWGを月1程度で実施しています。この定例では直近のインフラに関連する変更について共有したり、今後のリリース状況の確認なども行っています。以下のMackerel公式ブログでも紹介されています。

定期的にPWG（Performance Working Group）と呼ばれる会を開き、開発チームのエンジニアとインフラ担当が最近のパフォーマンス状況やサーバ構成の変更を共有します
はてなにおける日々の仕事の中にあらわれるMackerelの活用 - Mackerel お知らせ #mackerelio

上記の記事は2015年時点のことが書かれているので今では状況は変わっており、開発チームではアプリケーションエンジニアもインフラのオーナーシップを持って自分達で自由にTerraformないしAWS CDKでインフラに手を加えています。とはいえそれでもインフラ周りを専門としたSREチームの協力を受けるためにもこのPWGを今も実施しています。

やっていることはSRE本31章で紹介されているProduction Meetingと似ています。

弊チームで実施しているPWG

開発チームごとにプロダクトの状況や利用している技術スタック、チームの状況もバラバラなので細かいPWGのテンプレートは異なります。ここでは弊チームのPWGについて主に書きます。まず以下が我々のチームの「PWG」の目的です。

パフォーマンス等が悪くなっていないかチェックする機会を定期的に設ける

エンジニアリング面で気になっていることを雑談する場を定期的に設ける

SREチームとコミュニケーションする場を定期的に設ける

直近のイベント等をSREチームにも共有する

ここで言うところの「パフォーマンス等が悪くなっていないか」や「直近のイベント等」でこのままで問題ないかなどはMackerelを見て判断しています。PWG当日に利用しているテンプレートは以下のような構成になっています。

# 前回のTODOを確認する
- 前回のPWGでやると決めたことの状況を確認

# 直近1ヶ月のアラート確認
- (Mackerelの該当するサービスのアラート一覧画面へのリンク)
- 事前にアラートで気になるものをピックアップしておく

# カスタムダッシュボードの確認
- (Mackerelの該当するサービスのダッシュボードへのリンク)
- 今後数ヶ月スパンのトレンドをもとに、何らかの対応が必要かどうかを主に確認する

# アジェンダ
- 気になる話題などがあればなんでも話す
- 直近発生した障害やインフラ系の対応を眺める

# 今後1ヶ月のリリース予定
- アプリケーションやインフラ周りで大きな影響のあるものがある場合に何らかの対応をしておいたほうがいいかを確認する

# 今回出てきたTODOをissueとして登録

# 感想・コメントコーナー
- このPWGの会自体の進め方についてこうしたほうがいいかなど

普段アプリケーションの機能開発に集中してコードを書いているエンジニアとしてはインフラ層をこのまま置いておいて問題ないか（もしくは逆に余分になっているから削ったほうがいいかなど）の気になりが、このテンプレートに従って毎月会話しておけば解消されるのでとても助かっています。

PWGでの細かいMackerelの活用法

前提を色々と書いてきましたが、ここからはMackerelの細かい話を紹介します。

直近1ヶ月のアラート確認

まず「アラート確認」のセクションですが、ここではあらかじめ設定していた監視設定でアラートがあがったものを順番にみています。以下のポイントを特に意識しています。

アラートに気づくタイミングは適切だったか、今後もこの状態のままで良いか
特に対応のいらないものがアラートとして発報されたかどうか
何かしらのイベント起因のアラートだったのか

障害時にアラートが上がった際、サービス側の対応が必要なのはそうですが、過ぎ去ったアラートに関してそもそも監視設定の閾値が適切だったのかなどの見直しも行いたいものです。

「アラートに気づくタイミング」が遅かった場合、閾値をより厳しい値にしたり、そもそもの監視対象のロールが適切かなどが大事になります。逆に「特に対応のいらないものがアラートとして発報された」場合は閾値を緩めたりします。対応不要のアラートが溜まり続けると狼少年状態になるので定期的に見直すことが大事です*1。

また、メンテナンス作業をおこなったり、意図してサービスの一部を止めた場合にアラートが色々出ることがあると思います。そういう場合もメンテナンス作業中及び振り返りのタイミングでびっくりしないようにあらかじめダウンタイムを設定しておくと穏便です。
mackerel.io

他にも、明らかにインフラに影響のありそうな変更をおこなったタイミングでグラフアノテーションを設定しておくと複数のグラフで傾向が変わったりアラートがあがったときに判断しやすくなるのでおすすめです。実際に弊チームではリリース作業を行ったあとにつけてみたり、アプリケーションで利用しているGo言語のバージョンを上げたときにもつけてみてどういう風に傾向が変わったかみたりしていました。
mackerel.io

カスタムダッシュボードの確認

Mackerelのカスタムダッシュボードを確認するコーナーについては、あらかじめ確認したいポイントをまとめたダッシュボードを作っておいて、PWGの開催のタイミングでちょっとずつメンテナンスしていきます。なお、この機能は無料プランでは利用できませんのでご留意ください。
mackerel.io

さてダッシュボード作ってくださいと言われても正解はないのですが、弊チームでは大体以下のような雰囲気で作成しています。

Webアプリケーションの外側のレイヤーから内側に進んでいくイメージでグラフを並べる
関連するリソースは近くにおいて、セクションはMarkdown ウィジェットを利用して区切る
サービス固有の知識などがある場合はなるべくMarkdown ウィジェットに補足を書く

例えば弊チームのとあるサービス用のダッシュボードは上から

Response TimeやRequest数、エラー数などのグラフウィジェット
式による監視で計算したリクエスト成功率を表す数値ウィジェット
ECSコンテナのタスク数、CPU使用率、メモリ使用率などを表すグラフウィジェット
データベースの各種メトリック用のグラフウィジェット
...

のような感じになっています。こういう風に並べているとページの上から順番にみたときに「最近はリクエスト数が増加傾向」みたいな知識を頭に入れた上で各種メトリックにどう影響しているのかを判断しやすいです。

カスタムダッシュボードを見るパートの目的は特定の日の異常値を確認することよりも大局的に見て今後数週間・数ヶ月スパンで問題ないかをみることなのでこういう風にまとまっていると便利です。もちろん、PWG以外の用途（例えば負荷試験中の各種メトリックの様子を一覧したいときとか）でもカスタムダッシュボードは利用できますのでそこは自由です。

また、このダッシュボードをみて長期的に問題がありそうだけどアラートとして出ていないことに気づいた場合は新規で監視設定として追加するチャンスなので、そういう面でも見ています。サービスに新たなコンポーネントを増やしたときなども忘れずにダッシュボードに追加してメンテナンスし続けまています。