KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

プロダクト開発のモニタリングにおいて大事な4つの段階とベストプラクティス

カケハシで Musubi Insight のバックエンドエンジニアをしている末松です。今回はプロダクトのモニタリングをどう進めていくべきかについて、4つの大事な段階とそのベストプラクティスを紹介したいと思います。

この記事は秋の技術特集 2024の 10 記事目です。

想定読者

  • プロダクト開発に関わる人
  • モニタリングに興味がある人

モニタリングの悩みあるある

私自身 Musubi Insight というプロダクトを4年近く開発・運用している中で、モニタリングに関してさまざまな悩み・課題を抱えてきました。

  • 何を可視化すれば良いの?
  • 何を監視すれば良いの?
  • どんな時に通知を飛ばせば良いの?
  • SLOってどう決めれば良いの?
  • SLOをどう運用すれば良いの?

もし同じような悩みを抱えている方がいて、この記事が少しでも助けになれば幸いです。

モニタリングを始めるためには

モニタリングを始めるには、前提として「計測」ができるようになっていないといけません。 システムのメトリクスやアプリケーションのログなどがどこかに蓄積されている必要があります。

どう「計測」できるようにするかはシステムのアーキテクチャ次第なのでここでは割愛しますが、 カケハシでは基本的にAWS上にシステムが構築されておりそのメトリクスやログが Datadog連携されるようになっています。

モニタリングにおいて大事な4つの段階

私の経験上、プロダクト開発におけるモニタリングには4つの大事な段階があると思っています。

  1. 【可視化】プロダクトの状況がさまざまな断面で可視化されている
  2. 【共有】プロダクトの状況が定期的にチームに共有・認識されている
  3. 【検知】プロダクトが異常な状態であることにチームが気付くことができる
  4. 【集中】チームが優先すべき指標が定まっている

1から4まで優先度の高い順に並べているため、これからモニタリングを始めたい場合は1から進めていくと良いでしょう。

1. 【可視化】プロダクトの状況がさまざまな断面で可視化されている

もしまだプロダクトの状況がわかってないのであれば、とにかくいろんな側面から可視化をすべきでしょう。 DBやAPIのメトリクスからログ、フロントエンドのパフォーマンスなど思いつく限りグラフ化してダッシュボードに追加していきましょう。

【可視化】 のベストプラクティス

  • まずはとにかく可視化する(データを元に判断する癖をつける)
  • しばらく様子を見て、変化のないものや見る必要のないものは削除する(ノイズになるため)
  • 定期的にアップデートする

2. 【共有】プロダクトの状況が定期的にチームに共有・認識されている

可視化ができているのであれば次はチームに共有しましょう。 同期的な場をセッティングしてチーム全員でプロダクトの状況を確認し、安全なところと危険なところの共通認識を作ることでタスクの調整がスムーズになるはずです。

【共有】 のベストプラクティス

  • 同期的な場で行う(共通認識をしっかり作るため)
  • 隔週または月次の頻度で開催する(プロダクトの状況は刻々と変わるため)
  • 誰かがオーナーシップを持って共有する(全員が受動的にならないため)
  • 毎回ちょっとずつ見る指標を変える(マンネリ化しないため)

3. 【検知】プロダクトが異常な状態であることにチームが気付くことができる

プロダクトの状況をチームで共有・認識するようになると、この指標は大事・この指標は大事ではないという切り分けができるようになってくるはずです。 その大事な指標の悪化を自動で検知できるようにしましょう。

【検知】 のベストプラクティス

  • 基準値はとりあえずで決めて定期的に見直す
  • メンションをつけるなど、チームが気付けるような通知にする
  • 検知後にするべき行動を通知に含めることで、気づいた人が行動できるようにする
  • 検知したものの行動が不要だった場合は、基準を見直すか削除する(放置するとオオカミ少年化してしまう)

4. 【集中】チームが優先すべき指標が定まっている

可視化・共有・検知が十分にできるようになると、「あれも改善したい」「これも改善したい」となってしまったり、「何から手をつければ良いのかわからない」状態になってしまうことがよくあります。 改善に意識を取られすぎてプロダクトの新規開発やバグ修正などが疎かになってしまっては本末転倒です。

そんな時にはチームが優先すべき指標を定めて、この指標が悪化したら優先的に調査・改善に着手するルールを作りましょう。いわゆる「SLO」です。 SLOを定める最大のメリットは、「SLOが悪化するまでは改善をしなくて良い」という意識を持てることです。改善を最低限にしつつ新規開発などにフォーカスできるようになります。

【集中】 のベストプラクティス

  • SLOは2 ~ 3つまで(多すぎるとどのSLOを見ればよいかわからなくなってしまう)
  • 網羅的にする必要はない(今のプロダクトの状況から最も重要な指標を定める)
  • ユーザー目線で定める(ユーザー目線でないものは重要でない可能性がある)
  • 正常な状態から始める(初めから異常状態だと改善するまで運用を開始できない)
  • 定期的に基準・指標を見直す(プロダクトの状況に合わせる)

まとめ

プロダクトのモニタリングにおいて重要な【可視化】【共有】【検知】【集中】の4つの段階とそれぞれのベストプラクティスを紹介しました。

プロダクトの新規開発など本来やるべき業務に集中できるように、効率的なモニタリングを目指しましょう。