Grafana 導入で実現したマイクロサービスの可視化と異常発見の効率化

導入背景

導入前の状況・課題

オブザーバビリティに関する仕組みは、プロダクトから出力されるログをクラウドサービスで見る程度でした。そのため、異常が発生した際にプロダクトから出力されるログをひたすら眺めて異常の原因を探索していました。

大抵の場合、原因を発見できるのはプロダクトに詳しいメンバーであり、そういったメンバーが不在だと原因を発見するまでに時間を要する状態であることが課題となっていました。

目指していた状態

異常が発生した際にプロダクトに詳しくないメンバーでもツールを活用することで、テレメトリデータから異常の原因を探索できるような状態を目指していました。特にトレース情報は収集/可視化できていなかったので注力したいポイントでした。トレース情報があれば、異常の原因究明、システム全体の挙動の可視化などが期待できるためです。

導入の成果

導入後 2 ヶ月で大きな異常は発生していませんが、マイクロサービスにおけるトレース情報を Grafana （に加えて、Grafana Tempo）によって可視化できるようになったのでどのコンポーネントが原因で HTTP ステータスコードが 4xx, 5xx を返しているかを確認しやすくなりました。これは「プロダクトに詳しくない人でも原因探索が可能になる」というところに今後寄与すると考えています。

また、トレース情報からリクエストの処理時間のボトルネックを見つけやすくなるという副次的な効果も得られています。今まではあるリクエストのレスポンスが遅かった時にどのコンポーネントの処理に時間がかかっているかを特定することが困難でしたが、トレースに紐づくスパンの処理時間を Grafana によって可視化できるようになり改善までのスピードが上がりました。

導入時の苦労・悩み

チームにオブザーバビリティの必要性を伝えるのが苦労したポイントでした。否定的ではなかったもののオブザーバビリティの仕組みがなくても運用できている状況下で、他の開発タスクの優先度より仕組みづくりの優先度を上げるためには前提知識や明確な現状課題のチームでの認識が必要不可欠でした。

導入に向けた社内への説明

よく使う機能

アーキテクチャ

アーキテクチャの意図・工夫

システム運用に極力稼働を割かないためにも、Google Cloud のサーバーレスサービスである Cloud Run でホスティングする形にしました。また、OpenTelemetry や Prometheus や Garafana Stack のコンポーネントをセキュアに連携したかったので、Cloud Run が外部からリクエストを受け付けられるのは Otel Collector と Google 認証が必要な形式とした Grafana のみとするような仕組みとしています。

ツールの良い点

ツールの課題点

ツールを検討されている方へ

OSS 版は無料で利用ができ公式のコンテナイメージがあることから、技術検証に取り組むまでの時間を短縮できると思うのでまずは触ってみるのがおすすめです。

また、OSS 版への機能拡張やサポートが充実する Enterprise 版や Grafana Cloud という SaaS 版の提供もあり、OSS 版から始めてより深いユースケースに当たったら費用はかかるものの Enterprise 版や SaaS 版に移るという選択肢も持てるかと思います。