Grafanaスタックをフル活用したオブザーバビリティ基盤の紹介

Grafana Meetup Japan #6 で登壇した資料です。

https://grafana-meetup-japan.connpass.com/event/362953/

Transcript

1. Grafanaスタックをフル活用した オブザーバビリティ基盤の紹介 2025.09.02 Quentin Plessis GO株式会社
2. © GO Inc. 2 自己紹介 GO株式会社 SREグループ Senior Platform Architect Quentin Plessis / プレシ　カンタン SRE活動、Kubernetesを中心としたプラットフォームの開発と運用に携わる
3. © GO Inc. 3 Agenda ▪ Grafanaの導入背景 ▪ 自前運用について ▪ 活用事例の紹介 ▪ 今後 ▪ まとめ
4. © GO Inc. タクシーアプリ『GO』 4
5. © GO Inc. 5
6. © GO Inc. より「早く乗れる」体験に加え、ニーズに応じた豊富なオプションサービスを提供 6 タクシーアプリ『GO』とは？ GO優良乗務員 ※サービスによって提供エリア・提供条件が異なります 空気清浄機搭載 JPN TAXI AI予約 こだわり条件 空港定額 『GO PREMIUM』 複数台配車 アプリのりばも続々開設中 2021年12月 福岡空港 
 2022年4月 ららぽーと福岡 
 2022年7月 羽田空港 
 2022年9月 松山空港 
 2023年11月 麻布台ヒルズ 
 2023年12月 中部国際空港 
 2024年1月 成田空港 
 2024年4月 軽井沢駅 
 2024年6月 関西国際空港 
 2024年7月 旭川空港 
 2025年3月 伊丹空港 
 2025年4月 神戸空港 
 2025年7月 札幌丘珠空港 
 2025年7月 御殿場プレミアム・ 
 　　　　　 アウトレット 
 乗り込みGO Pay ライドシェア対応
7. © GO Inc. ※　　 は当社の登録商標です。 7 タクシーアプリ『GO』の事業成長　ー ダウンロード数推移 ー 2022年9月 1000万ダウンロード突破！ 2021年11月 法人向けタクシー配車管理 『GO BUSINESS』リリース 2021年10月 500万ダウンロード突破！ 2020年4月 Mobility Technologies誕生！ 2023年4月 「GO株式会社」に商号変更 『GO』累積ダウンロード数 2020年9月 タクシーアプリ『 GO』 全国11エリアでスタート ダウンロード数 (25年7月) 3000万 利用可能エリア 46都道府県 ネットワーク事業者数 1100社以上 年間実車数 (22年6月-23年5 月) 6000万回 No1※タクシーアプリとして成長中 ※Sensor Tower調べ - タクシー配車関連アプリにおける、日本国内ダウンロード数（ App Store/Google Play合算値） - 調査期間： 2020年10月1日~2025年6月30日 2024年4月 2000万ダウンロード突破！ 2025年7月 3000万ダウンロード突破！ 2024年10月 2500万ダウンロード突破！
8. © GO Inc. Grafanaの導入背景 8
9. © GO Inc. 9 『GO』の裏側 ▪ 100以上のマイクロサービスで構成 ▪ 開発者100人以上、開発チーム10以上 ▪ Kubernetesをベースとしたプラットフォーム「Kenos」で稼働 ▪ EKS (AWS)とGKE (GCP)を利用したマルチクラウド構成 パブリッククラウド上に構築された サーバーシステム クラウドプラットフォーム AWS/GCP/Azure 乗務員向けアプリ 後部座席タブレット ユーザー向けアプリ 運営者向け Webアプリ タクシー事業者向け 管理画面
10. © GO Inc. 10 Grafanaの導入前 オブザーバビリティの重要性 ▪ メトリクスとアラート：システムの継続監視 ▪ ログ：問い合わせ対応、障害の際の調査 ▪ トレース：ボトルネック特定 → とても複雑なシステム構成の中で統一されたオブザーバビリティ機能 の提供が非常に重要 Grafana導入前の課題 (メトリクスはSaaS、ログはBigQuery) ▪ 全体のユーザビリティの低さ ▪ 可視化の難しさ ▪ メトリクス、ログ、トレースの連携の難しさ ▪ 料金の高さ
11. © GO Inc. 11 オブザーバビリティ仕組みの評価 詳細はブログ記事：「LGTM！オブザーバビリティ基盤第1話」で検索
12. © GO Inc. 12 Grafanaの導入 Grafanaプロダクトを少しずつ導入 ▪ 2023年前半：GrafanaとLokiを導入 ▪ 2023年後半：Mimirを導入 ▪ 2024年：Tempoを活用 ▪ 2025年：OnCallを導入 現在はGrafana、Loki、Mimir、TempoとOnCallを毎日利用している！
13. © GO Inc. 13 規模感 オブザーバビリティ基盤で扱っているデータの量 ▪ ログ：2〜3 TB/日 ▪ メトリクス：25 GB/日 ▪ トレース：100 GB/日 オブザーバビリティ基盤の規模 (平均) ▪ テナント：40以上 ▪ Loki : 100 pods ▪ Mimir : 70 pods ▪ Tempo : 20 pods ▪ その他：10 pods
14. © GO Inc. 自前運用！ 14
15. © GO Inc. 15 自前運用の背景 Grafanaを自前で運用することにした理由 ▪ コスト削減 - SaaSを利用する場合、データ量課金になりコストが爆増 - 送信するデータを絞ることになってしまう - → 自前運用になるとデータを大量に突っ込める（特にログとメ トリクス) ▪ カスタマイズ性 - 独自の仕組みと連携可能 - コンプライアンスとセキュリティポリシーに対しての対応 ▪ メンテナンスの低負荷の予想 - Kubernetes運用の経験あり - データがS3/GCSなどObjectStorageに保存されるため運用不要
16. © GO Inc. 16 アーキテクチャ 専用のEKSクラスタ - SSOでGrafanaに入る - ストレージはS3を利用 - テナント:k8sネームスペース - カスタムな仕組みも サービスが動いている EKS/GKEクラスタから - Istioを活かして様々なデー タを送信 - アプリケーションからカスタ ムなデータも送信
17. © GO Inc. 17 アーキテクチャ - メトリクス データの提供(exporters) ▪ Envoy (Istio) ▪ アプリケーション ▪ Node exporter ▪ CloudWatch (AWS) ▪ Stackdriver (GCP) ▪ DB Exporters データプッシュ ▪ Prometheus (scrape) ▪ cortex-tenant (テナントを分ける)
18. © GO Inc. 18 アーキテクチャ - ログ データの提供 ▪ Envoy (Istio) ▪ アプリケーション データプッシュ ▪ Promtail
19. © GO Inc. 19 アーキテクチャ - トレース データの提供 ▪ Envoy (Istio) ▪ アプリケーション データプッシュ ▪ OpenTelemetry Collector
20. © GO Inc. 20 アーキテクチャ - アラート MimirとLokiがアラートをAlertmanagerに送信 ▪ 「ruler」コンポーネント ▪ Mimirはメトリクスベースアラート ▪ Lokiはログベースアラート ▪ ログからメトリクスを作るためにLokiが Mimirにデータを送信することもある AlertmanagerがGrafana OnCallに通知 Grafana OnCall側でエスカレーションとスケ ジュールを管理し、必要に応じてSlackに通知 したり、電話をかけたりする
21. © GO Inc. 21 アーキテクチャ - カスタム仕組み OpenResty(nginx)ベースの軽量プロキシを開発 Grafana Gateway : IP制限、アクセスログ Mimir/Loki OAuth Gateway : ▪ テナントごとの細かい認可とIP制限機能 ▪ アクセスログ 例：ログは基本的にIP制限をかけるが、一部の メトリクスについては障害対応を早めるためIP 制限をかけない
22. © GO Inc. 22 アーキテクチャ - 全体
23. © GO Inc. 23 Loki : 内部アーキテクチャ Lokiは「Simple Scalable Deployment」構成を 利用 (SSD) 3つのpodsの種類に分かれる ▪ 書き込み用のwrite pods ▪ 読み込み用のread pods ▪ ruler/compactorなど用のbackend pods データ送信時と参照時にテナントを X-Scope-OrgIDヘッダとして指定 HorizontalPodAutoscalerによってオートス ケールさせている 詳細は「Grafana Lokiでログを検索 | オブザー バビリティ基盤第2話」で検索
24. © GO Inc. 24 Mimir : 内部アーキテクチャ MimirはDistributedモードを利用 (SSDモードがないため) Mimirのコンポーネントごとに独立し たDeployment/Statefulsetが存在 Memcachedにデータをキャッシュ データ送信時と参照時にテナントを X-Scope-OrgIDヘッダとして指定
25. © GO Inc. 25 自前運用の振り返り ▪ 初期セットアップが少し大変 - コンポーネントが多い - パラメータが多くてLokiのパフォーマンスチューニングが大変 - 構成と動きを詳しく理解した方がいい → Grafana LabsのブログとPodcastがおすすめ ▪ 普段からは安定していて調整する必要がない！ ▪ バージョンアップの時は工数がかかる（自前運用のためしょうがない) ▪ Grafanaを利用する社内のメンバーからの質問や問い合わせがそれなりにある
26. © GO Inc. 26 自前運用の振り返り Lokiについて ▪ 3.x にアップデートすると色々安定してくる ▪ Lokiの設計上、ログ内容をインデックスしていない関係でwriteが安くて、read が高い。オートスケールなどで工夫してreadさえスケールすれば圧倒的なコス ト削減力を得られる ▪ memcachedを使うと逆に遅くなっていた (S3の性能の方がいい) → ユースケースによる ため絶対的に言えない ▪ 大量のデータをクエリする際にS3のrate limitに引っかかることがあった → S3もオートス ケールするもの！ ▪ replication factor = 1 にしている（コスト削減のため多少の欠損の可能性を妥協) ▪ 圧縮アルゴリズムは snappy ▪ read : split_queries_by_interval / tsdb_max_bytes_per_shard / max_query_capacity などをチューニングしている
27. © GO Inc. 27 自前運用の振り返り 困ったエピソード ▪ サービス障害が発生し、状況確認のためエンジニアが一斉にGrafanaを利用し、 Mimirの負荷が高まりメモリが足りなくなり、Mimirが大事な時にダウンした → メモリを多めに設定した方がいい ▪ AWSのゾーン障害が発生した影響、Grafanaに一時的にアクセスできなくなり、 サービスの状況を確認できなかった → マルチAZ構成を再確認した方がいい ▪ サービスのトラフィックが急に増えた時、サービスだけではなくGrafanaの負荷 も気にする必要がある → リソースを多めに設定するのと、オートスケールさせること 全体の感想：それなりの規模で自前運用が可能。苦労するところもなくはないが、メリッ トが多くて継続予定。困ったらGrafana Cloudに切り替える選択肢もあるため安心！
28. © GO Inc. 活用事例の紹介 28
29. © GO Inc. Grafana 29
30. © GO Inc. 30 Grafana ▪ Microsoft Entra ID によるSSO (旧Azure AD) ▪ Kubernetesネームスペースごとに「xxx Logs」と「xxx Metrics」データソー スを作成
31. © GO Inc. 31 Grafana - ダッシュボード 主にダッシュボードを利用している ▪ アプリケーションごとに作成 ▪ RPS/エラー/レスポンスタイム ▪ コンテナ情報 ▪ DB情報 ▪ カスタム情報 ▪ など 魅力 ▪ 見た目がカッコいい！ ▪ 手動でサクッと作れる ▪ jsonでコピペできる、コード管理 できる ▪ 何でもリンクで共有できる
32. © GO Inc. ▪ アラートルールはMimirとLokiで管理しているが、Grafanaでも確認 ▪ Slack通知からダッシュボードに飛んだり、クエリを確認したり、 silence設定したりできる 32 Grafana - アラート
33. © GO Inc. Loki 33
34. © GO Inc. 34 Loki - 圧倒的なコスト削減力 サーバログの特徴 ▪ 調査のため大量に残す必要がある（何が起きるかわからない) ▪ ほぼ見ない（全体の量に対して検索されるのはわずか一部） → 書き込み課金のシステムだとコストパフォーマンスが悪い Lokiはコストが読み込みにかかるため、圧倒的なコスト削減力を持つ ▪ Lokiに切り替えることで80%のコスト削減ができた実績もある ▪ Lokiのコスト削減効果を得るためだけでも弊社のSREで運用している Kubernetes基盤「Kenos」に移行する社内サービスもある ▪ 詳細は「GO TechTalk #30 クラウドコスト削減 祭り」で検索
35. © GO Inc. 35 Loki - 可視化 可視化が強い ▪ 特定のログのトレンドを簡単に可視化でき、他の人に共有でき、ダッ シュボードもサクッと作れる ▪ 他のシステムだったらまずログからメトリクスに変換する必要があっ たり、そもそも可視化できなかったりすることもある ▪ 調査の際に非常に便利
36. © GO Inc. 36 Loki - LogQL LogQLを活かす ▪ 最初はSQLなどよりも使いづらいが、慣れると色々できて便利 (if/rangeなど) ▪ GUIのボタンを利用してもいいが、LogQLでクエリを調整できると新しい世界が広がる ▪ 統一されたフォーマットを利用すると、サービスと関係なく同じクエリを利用でき、「便 利クエリ」一覧を用意できる
37. © GO Inc. 37 Loki - 課題 独自のデータフォーマット ▪ ログをS3に保存しているため安いが、コンプライアンスのためログを長期 保存する場合はそれでもお金がかかる ▪ 特に読み込みパフォーマンス向上のためLokiの圧縮にsnappyを利用する場 合は圧縮率が落ちる ▪ Lokiが標準なフォーマットを利用していればS3からデータをコピペして gzipで再圧縮することも可能なはず → データを他のフォーマットとしてエクスポートする機能があれば嬉しい 長期間の集計 ▪ 長期間のデータ集計にあまり向いていない ▪ データをBigQueryやAthenaなどに簡単に連携できれば嬉しい → 現在は独自の仕組みで連携している
38. © GO Inc. Mimir 38
39. © GO Inc. 39 Mimir 制限なくメトリクスをたくさん集める！ ▪ Istioメトリクス（istio_xxx, envoy_xxx …) ▪ k8sメトリクス（container_xxx , kube_xxx …) ▪ AWS/GCPメトリクス (aws_xxx , stackdriver_xxx …) ▪ DBメトリクス (mysql_xxx , pg_xxx …) ▪ カスタムメトリクス (Golang go_xxx、配車成功率 …) ▪ など
40. © GO Inc. 40 Mimir - カスタムメトリクス カスタムメトリクスの投入が非常に楽 - Prometheus形式のメトリクスを /metrics エ ンドポイントとして提供すればいい - Prometheus SDKを利用すれば更に楽 $ curl http://localhost/metrics # HELP custom_cpu_temperature_celsius Current temperature of the CPU. # TYPE custom_cpu_temperature_celsius gauge custom_cpu_temperature_celsius 65.3
41. © GO Inc. 41 Mimir - カスタムメトリクス カスタムメトリクスで新しいインサイトを得る ▪ アプリケーション内部情報：goroutines数、DBコネクションプー ル、メモリ利用量の内訳... ▪ サービスよりのKPI：配車成功率、決済手段ごとのエラー数など ▪ 機能の利用分析用の情報 ▪ など！
42. © GO Inc. Tempo 42
43. © GO Inc. 43 Tempo トレースのメリット ▪ エラー発生箇所とボトルネックの特定（外部サービス？DB？ アルゴリズム？) ▪ リクエストの流れを簡単に追えること：特に多数のマイクロ サービスを通るリクエストの場合、コードを読まなくても処理 の流れがわかる ▪ トレースを見るだけで不自然なパターンを発見し問題が発生す る前に処理を修正することもある セットアップ方法：「Golang マイクロサービスの徹底ト レース方法 | オブザーバビリティ基盤第3話」で検索
44. © GO Inc. 44 Tempo - トレースサンプル
45. © GO Inc. 45 Tempo - トレースサンプル Redis HTTP 独自関数 SQL DB
46. © GO Inc. 46 Tempo - ログとの連携
47. © GO Inc. 47 Tempo - パターン発見：loop loopの中でDBクエリ実行
48. © GO Inc. Span数が数百件のトレースも 48 Tempo - 複雑なシステム連携
49. © GO Inc. OnCall 49
50. © GO Inc. 50 OnCall - メンテナンスモード ▪ プロダクトがメンテナンスモードに入ってしまっている ▪ 2026年3月末にアーカイブされる予定 ▪ 弊社では今の所利用継続予定
51. © GO Inc. 51 OnCall - スケジュール
52. © GO Inc. 52 OnCall - エスカレーションチェイン
53. © GO Inc. 53 OnCall - Slack通知
54. © GO Inc. 更に 54
55. © GO Inc. 55 terraformで管理 Grafana/Loki/Mimirのterraform providerで管理が楽
56. © GO Inc. 56 高度なダッシュボード クリックするとそ のリクエストのア プリケーションロ グに飛ぶ クリックするとそ のリクエストのト レースに飛ぶ アクセスログ閲覧用ダッシュボード
57. © GO Inc. 57 アラートまとめダッシュボード 発生したアラートを 時系列で表示し、 集計するなど
58. © GO Inc. 58 緊急時のオートスケール仕組み 古いサービスが固まった時に緊急でオートスケールさせる仕組み ▪ CronJobで定期的にMimirのAPIを叩いてメモリ使用率や他のメトリ クスを取得 ▪ 特定条件を満たした場合Podを多めに増やす
59. © GO Inc. MimirのAPIを叩いてSLIを計算しGoogle Sheetにまとめる 59 SLI計算
60. © GO Inc. 60 Argo Rolloutsと連携した自動カナリアリリース Argo Rollouts Mimir メトリクス参照 ▪ 新しいバージョンをデプロイ ▪ トラフィックが徐々に切り替わる ▪ メトリクスを継続的に監視（エラー率、SLIなど) ▪ 問題があった際に自動ロールバック
61. © GO Inc. 今後 61
62. © GO Inc. 62 今後：Grafana Alloyに移行
63. © GO Inc. 63 今後：気になるGrafanaプロダクトの導入検討 ▪ Grafana Beyla：eBPFベースの自動計装 ▪ Grafana Faro：フロントエンドのオブザーバビリティ ▪ Grafana Pyroscope：継続的プロファイリング
64. © GO Inc. まとめ 64
65. © GO Inc. 65 まとめ ▪ を毎日利用していて非常に便利！ ▪ それなりの規模で自前運用が可能 - 送るデータを絞らないでフル活用できる！ - 圧倒的なコスト削減効果がある！ - 困ったらGrafana Cloudへ！ ▪ 面白い仕組みをたくさん作れる ▪ まだまだ可能性がある！
66. © GO Inc. 66 https://hrmos.co/pages/g oinc/jobs タクシーアプリ『GO』の開発を一緒にしませんか
67. © GO Inc. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください