こんにちは、「カミナシ レポート」の開発に携わっている furuya です。先日は Observability Conference Tokyo 2025 が開催され、盛況だったようですね。カミナシメンバーも登壇・参加しました！発表資料はこちらです。
この記事では、先日登壇したID管理・認証認可チームとは別で、「カミナシ レポート」の開発チームにおいてもここ数ヶ月間オブザーバビリティと向き合っていた、というお話ができればと思います。
課題
オブザーバビリティとはなんぞや？というところをそろそろちゃんと理解したいなと思い、書籍「オブザーバビリティ・エンジニアリング」を手に取りました。そこで理解したのは、高度に複雑で分散された現代のシステムにはモニタリングだけでは太刀打ちできず、その解決策としてオブザーバビリティを獲得する必要がある、ということです。
「ハンマー」を手に入れたが…？
さぁ、オブザーバビリティ獲得へのハンマーを手に入れたぞ！すべてが釘に見えてくる！「カミナシ レポート」でも「高いカーディナリティ」「高いディメンジョン」を持つ構造化イベントを集め…と思ったのですが、よくよく考えると「カミナシ レポート」は「高度に複雑で分散された」システムではありません。むしろアーキテクチャはシンプルです。
まず、モニタリングができていない
あらためて現状を把握してみると、課題は他にありました。気づかれないレイテンシの悪化、鳴り止まないオオカミ少年アラート、障害発生時の影響範囲がすぐ見えない、これらはモニタリングの範疇です。
凡事徹底
各種メトリクスおよびそのモニタリング（と拡大解釈しています）はオブザーバビリティ獲得のアプローチの一部として含む必要がある、と書籍でも言及されており、すなわちここにノイズが含まれるということはオブザーバビリティ獲得を阻害してしまいます。これに対してやるべきことはシンプルで凡事徹底、当たり前のことを徹底的にやりました。
モニター・ダッシュボードのお片付け
まずは不要なモニターやアラートを整理し、本当に対応が必要なものだけSlackへ通知を送るようにしました。また、なにか問題が発生したときにメトリクスがひと目でわかるダッシュボードを作成しました。アラート発生時にまず見る、「どこで何のエラーが、どのお客様に出ているのか」をまとめたものと、APM、メトリクス、主要エンドポイントのRequests / Errorsとレイテンシがまとまっています。
週次運用定例の開催
また、そのダッシュボードを毎週見る会を始めました。一緒に運用にまつわるあれこれをまとめて確認する会ということで、運用定例（Service Review）と呼んでいます。ここでは他にインフラコストの確認やAWSなど利用する外部サービスからの通知の確認、障害・ヒヤリハットの周知などを行っています。
効果
「本質」への集中
モニター・アラートを整理したことで、「このSlackチャンネルにあがってきた通知は対応が必要なものだ」という合意がチーム内でとれ、迷わず対応ができるようになりました。
ヒヤリ・ハットの発見
運用定例中に見つけたメトリクスの変化を追ってみると、社内で発行していた分析用クエリがDBに思った以上の負荷をかけていることがわかりました。このまま気づかずにいればDBが詰まってお客様への影響が発生するところだったので、事前に気づけてよかったです。
ログにちょい足ししてオブザーバビリティ向上
ここまでの凡事徹底によりオブザーバビリティにおけるノイズが減り、本来見るべき情報にフォーカスできるようになりました。それとは別で「オブザーバビリティ獲得に一役買っているな」と思ったポイントをご紹介します。
高いディメンジョン、高いカーディナリティの構造化イベントを収集することの大切さは書籍で強調されている通りですが、「カミナシ レポート」のAPIログもそれを意識したものになっています。たとえばアクセスログにしても「どの会社の」「誰が」という情報を付与（ディメンジョンを追加）することで、システムの内部状態を推測する手助けになっています。実際、これがあるだけで「誰が」「いつ」「どんな操作をしていたのか」が手に取るようにわかるようになっており、問い合わせ対応に役立っています。考えられうるすべてのディメンジョンが追加されていることが理想ですが、いくつか追加するだけでも大きな効果を発揮することを実感しています。
まとめ
「オブザーバビリティ・エンジニアリング」を読んで、さぁオブザーバビリティを獲得するぞ！と思っていたところ、実はモニタリングをなんとかしなければならないということに気が付き、凡事徹底、ちゃんとやることでオブザーバビリティ獲得への手助けになった、というお話でした。
今回の件を経て思ったのは、一周回ってメトリクス、ログ、トレースは重要だなぁ、ということでした。ノイズを減らしつつ「オブザーバビリティ・エンジニアリング」のエッセンスをちょい足しすることでオブザーバビリティを向上できる、ということもわかりました。この記事がオブザーバビリティのための、オブザーバビリティを見据えたモニタリングについて考えるきっかけになれば幸いです。
