Grafana 導入で実現したマイクロサービスの可視化と異常発見の効率化
エヌ・ティ・ティ・コミュニケーションズ株式会社 / pHaya72
メンバー / フロントエンドエンジニア / 従業員規模: 5,001名以上 / エンジニア組織: 51名〜100名
利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|
OSS | 10名以下 | 2024年3月 | B to C |
利用プラン | OSS |
---|---|
ツールの利用規模 | 10名以下 |
ツールの利用開始時期 | 2024年3月 |
事業形態 | B to C |
アーキテクチャ
アーキテクチャの意図・工夫
システム運用に極力稼働を割かないためにも、Google Cloud のサーバーレスサービスである Cloud Run でホスティングする形にしました。また、OpenTelemetry や Prometheus や Garafana Stack のコンポーネントをセキュアに連携したかったので、Cloud Run が外部からリクエストを受け付けられるのは Otel Collector と Google 認証が必要な形式とした Grafana のみとするような仕組みとしています。
導入の背景・解決したかった問題
導入背景
導入前の状況・課題
オブザーバビリティに関する仕組みは、プロダクトから出力されるログをクラウドサービスで見る程度でした。そのため、異常が発生した際にプロダクトから出力されるログをひたすら眺めて異常の原因を探索していました。
大抵の場合、原因を発見できるのはプロダクトに詳しいメンバーであり、そういったメンバーが不在だと原因を発見するまでに時間を要する状態であることが課題となっていました。
目指していた状態
異常が発生した際にプロダクトに詳しくないメンバーでもツールを活用することで、テレメトリデータから異常の原因を探索できるような状態を目指していました。特にトレース情報は収集/可視化できていなかったので注力したいポイントでした。トレース情報があれば、異常の原因究明、システム全体の挙動の可視化などが期待できるためです。
導入の成果
導入後 2 ヶ月で大きな異常は発生していませんが、マイクロサービスにおけるトレース情報を Grafana (に加えて、Grafana Tempo)によって可視化できるようになったのでどのコンポーネントが原因で HTTP ステータスコードが 4xx, 5xx を返しているかを確認しやすくなりました。これは「プロダクトに詳しくない人でも原因探索が可能になる」というところに今後寄与すると考えています。
また、トレース情報からリクエストの処理時間のボトルネックを見つけやすくなるという副次的な効果も得られています。今まではあるリクエストのレスポンスが遅かった時にどのコンポーネントの処理に時間がかかっているかを特定することが困難でしたが、トレースに紐づくスパンの処理時間を Grafana によって可視化できるようになり改善までのスピードが上がりました。
導入時の苦労・悩み
チームにオブザーバビリティの必要性を伝えるのが苦労したポイントでした。否定的ではなかったもののオブザーバビリティの仕組みがなくても運用できている状況下で、他の開発タスクの優先度より仕組みづくりの優先度を上げるためには前提知識や明確な現状課題のチームでの認識が必要不可欠でした。
導入に向けた社内への説明
上長・チームへの説明
上長は技術への理解が深く、SRE やオブザーバビリティの必要性は元から理解してもらっていました。
課題感の説明やチャレンジしたい気持ちを伝えたところ、ひとまず技術検証してみようということになり、実際の導入については、以下の2点で話を進めました。
- メンバーへの概念/具体的なユースケースの展開によるチーム理解の深化
- スモールに費用が極力かからない形である OSS 版のセルフホスティング
### 社内・チームへの展開 上記の「導入時の苦労・悩み」のポイントへのアプローチとして、SRE やオブザービリティの概念をチームに展開することから始めました。
また、概念がわかってもイメージが沸かないメンバーも多かったため、 Grafana のダッシュボードを作成して、メトリクスやログがどのように集約できるのか、トレースがどのように見えるのかをデモをしたりしました。
活用方法
よく使う機能
- ダッシュボード:HTTP ステータスコードの集計や各コンポーネントでの処理時間ヒートマップなどを見れるようにしています。
- Explore(Grafana Tempo):トレースに紐づくスパンを細かくみるために利用しています。
ツールの良い点
多種多様なデータソースプラグイン:今回はテレメトリーデータの可視化のために、Prometheus, Grafana Loki, Grafana Tempo をデータソースとして使用しています。また、Google Cloud のメトリクスやログを集約するためのプラグインを使用して、Cloud Monitoring や Cloud Logging も可視化しています。これ以外にも 100 を超えるプラグインが提供されており、多くの可視化ユースケースに対応可能なところが良い点です。
無料利用でコミュニティが活発:OSS であることから無料で利用できます。また、公式のコンテナイメージから実際に利用するまでもスピーディに行えます。最近では、Grafana Meetup Japan というイベントも開催されており、ドキュメントに加えて利用している会社のノウハウを吸収できる場も存在します。
ツールの課題点
運用管理の負荷:OSS であることから無料で利用できる一方で Grafana のホスティングから運用保守までを自分たちで行わなければいけません。また、コミュニティベースのサポートが中心になるので Enterprise 版や SaaS 版のようなサポートは期待できません。複雑な問題が発生した場合には、ある程度ノウハウを持っているエンジニアが必要となります。
高度な利用における高い学習コスト:アラート設定やカスタムでプラグインを開発しようとするとより詳細な知識が必要になる印象です。どれだけ使い込むか次第ではあると思いますが、ハードルが高く感じる部分ではあります。
ツールを検討されている方へ
OSS 版は無料で利用ができ公式のコンテナイメージがあることから、技術検証に取り組むまでの時間を短縮できると思うのでまずは触ってみるのがおすすめです。
また、OSS 版への機能拡張やサポートが充実する Enterprise 版や Grafana Cloud という SaaS 版の提供もあり、OSS 版から始めてより深いユースケースに当たったら費用はかかるものの Enterprise 版や SaaS 版に移るという選択肢も持てるかと思います。
エヌ・ティ・ティ・コミュニケーションズ株式会社 / pHaya72
メンバー / フロントエンドエンジニア / 従業員規模: 5,001名以上 / エンジニア組織: 51名〜100名
よく見られているレビュー
エヌ・ティ・ティ・コミュニケーションズ株式会社 / pHaya72
メンバー / フロントエンドエンジニア / 従業員規模: 5,001名以上 / エンジニア組織: 51名〜100名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法