こんにちは

これは Mackerel Advent Calendar 2021 の11日目の記事です.
Mackerel チームでは Performance Working Group を定期的に行っているのですが, 今の状況も踏まえてアップデートしたので内容をまとめてみました.

Performance Working Group とは

グラフを眺めて最近のパフォーマンス変化を確認したり, パフォーマンスに影響を与えうるできごとや構成変更についての共有を行う会です. Mackerel のカスタムダッシュボードを主に利用しています.
少し長めの期間指定でパフォーマンスを確認することで, 障害の発生や SLO 違反を未然に防いだりキャパシティプランニングに役立てたりなどの目的があることが監視設定と異なるところです.
Mackerel では現在, SRE とアプリケーションエンジニアが主に参加していて, Mackerel や kibana などのダッシュボードを確認しています.

Performance Working Group についてはこれまでもいくつかの場で紹介してきました.

アップデートしたきっかけ

Mackerel でも observability の改善を行っており, たとえばバッチ系のシステムでは処理対象の Queue と処理した Queue, 正常に処理した Queue を比率などで観測できるようにしてきました.
このような observability の改善は主に SRE 主導で進めており, その過程で開発した一部ツールを公開しています( mackerel-monitoring-modules/cloudwatch-logs-aggregator )
observability を改善し監視設定などに利用したりしていましたが, 加えてアプリケーションエンジニアと一緒に見ることで SRE が追加したメトリックについて共有するためにも Performance Working Group の項目として追加することにしました.
また Mackerel のフロントエンド "React化" プロジェクトを支える技術と設計 - Hatena Developer Blog のとおり, Mackerel のフロントエンドのフレームワークを移行中であり, フロントエンドが改修頻度が高い箇所になりました. ここも特定の画面のみエラー率が増えたりレイテンシが悪化したりしていないかなどを把握するためにフロントエンド全体ではなくパスベースにも見ることにしました.

情報共有の場

LeSSを回して3ヶ月 - HKtngchの徒然なるままにでも触れられているとおり, Mackerel は現在 LeSS を導入していますが SREは職能別のチームとして独立しています.
これは SRE チームでの情報交換や相談を密に行えるメリットはありつつ, 最近行った構成変更や今後予定しているアップデートなどについて, 誰にどのような形で共有するかは考えておく必要がありました.
アプリケーションエンジニア向けとしては, パフォーマンス変化があったときに SRE が行った構成変更などが原因になりうるため, いつ何がどのように変わり何に影響する可能性があるかを今は Performance Working Group で会話しています.
ディレクターや PO も含めた場としては, スプリントイベントでパフォーマンス懸念があったりコスト影響がありうるところなどを共有しています.
具体的なところや詳細を Performance Working Group で確認し, サマリをスクラムイベントで共有するイメージです.

オンラインでの Performance Working Group の実施

上記のように, 定期的に確認したい項目や情報共有を安直に増やすと Performance Working Group の時間がとても長くなってしまいます.

ここで利用したのが Mackerel チームでもリモートワークをしているメンバーがほとんどであり, Performance Working Group もオンラインで開催していることでした.
オンラインなのでオフラインに比べると, 会の途中でのメンバーの分割と合流で物理的な移動もないためお手軽にできることに気づきました.
また, オフラインでもオンラインでもあまり変わらないことですが, 人数が多いと固定の人がいつも発話しがちという特徴があり, 人数を減らすことで発話する機会をより増やす目的もあります.

今では Google Meets のブレイクアウトルームを利用し, まず全員での情報共有と SLO などを全員で見ておきたいダッシュボードを確認してから各チームに分けています. チームごとにパフォーマンス確認を行う対象が決められており, メンバーは毎回ランダムで決めています. チームごとに確認後, 合流して確認したことの共有をしています.

これはより多くのメトリックを短時間で網羅的に確認していくという目的はありますが, それとは別に Performance Working Group の進行の回転率を上げて経験数を増やすことでシステムやメトリックへの理解を深める狙いもあります.
進行は全体のときは一人, チーム分けしてからは各チームに一人用意しています. 進行の役割は今見ているグラフについて現状が問題ないかを確認していくことで, そのメトリックの意図がわからないと難しいです. これまでは進行が一人だったので一度やってから次回までに少し期間が空き記憶が薄れていたのですが, 今ではより速くサイクルを回し進行に慣れやすくすることにも繋げています.

チーム分割することでそこにいま見ているコンポーネントについて詳しい人がいない場合もあります. その場合は合流したときに気になった点やわからなかったところを共有して有識者に教えてもらったり, 誰もわからなければ調査を TODO として積んでいます.

用意したもの

これまでは主に１つの Mackerel のダッシュボードや kibana を確認していました.
今回, コンポーネントごとにダッシュボードを用意し, チーム分割後はそのダッシュボードでパフォーマンスを確認するようにしました. ものによってはそのコンポーネントに詳しい人とどんなメトリックを見ていくとよいか会話してダッシュボードを作ったりしました.
ダッシュボードにはサービスの利用状況が分かるメトリックと関連するシステムメトリックを近くに置くようにしています. これはシステムメトリックがサービスの利用状況によって変化する可能性があることと, キャパシティの変更が必要あるか確認することを目的にしています.

Performance Working Group のアップデートを考えたときに, しばらくは試行錯誤のためアジェンダの組み換えが発生することを想定していて, 組み替えやすいようにダッシュボードも１つのダッシュボードに全てまとめるのではなく,コンポーネント単位に分割した意図もあります.
結果としてアップデート初期は組み換えを小さなものですがほぼ毎回行っており, また不具合調査時などに必要な情報にたどり着きやすさもあるため, コンポーネント単位にわけておいてよかったです.

また, ダッシュボードは初回用意して終わりではなく Performance Working Group でグラフを追加したり修正したり育てていく必要があります. たとえば, ALB の status code で2XX系が圧倒的に多く5XX系が少ないとグラフでは5XXが見えづらくなるため5XXだけ抜粋したグラフを追加したり, 特定の処理のレイテンシがあがったときにそれが何を意味していてどのような状況かをメモウィジェットを使ってダッシュボードに書いたりするなど, ダッシュボードに情報を集めるようにしています.

やってみて

ダッシュボードやメトリックを改めて整備し Performance Working Group に参加していて, システムに対し理解を深められました.
ダッシュボード準備はは突き詰めると無限にやりたいことがでてきてしまうのですが, まずは Performance Working Group としてやってみることを優先していて, 現状観測できているところを定期的に確認し続けられる状態にすることをゴールにしました. まず始めてみることで全体でシステムについて理解が深められたと考えています.

Performance Working Group で会話して終わりではなく, 調査対応が必要なものは issue を上げて対応すること自体も運用のサイクルに組み込むことで浮いてしまわないようにする, という流れにもなりました.
実際に Performance Working Group から問題点を発見して修正した例もあったり, 少し長期的に構成変更の履歴を追うときに情報がまとまっているのも助かりました.

以上, Mackerel でいま行っている Performance Working Group のご紹介でした.

~~なんと明日はまだ空いています!~~

@stefafafan さんが書いてくれました！
Mackerelの「式グラフ」記法のシンタックスハイライトに対応したVS Code拡張を作った - stefafafan の fa は3つです
式グラフ, シンタックスハイライトがあると書きやすくなってすごくありがたいです.

Mackerel Advent Calendar 2021
ご参加お待ちしております