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

by GO Inc. dev

Slide 1

Slide 1 text

Grafanaスタックをフル活用したオブザーバビリティ基盤の紹介 2025.09.02 Quentin Plessis GO株式会社

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 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 ライドシェア対応

Slide 7

Slide 7 text

© 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万ダウンロード突破！

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© GO Inc. 9 『GO』の裏側 ■ 100以上のマイクロサービスで構成 ■ 開発者100人以上、開発チーム10以上 ■ Kubernetesをベースとしたプラットフォーム「Kenos」で稼働 ■ EKS (AWS)とGKE (GCP)を利用したマルチクラウド構成パブリッククラウド上に構築されたサーバーシステムクラウドプラットフォーム AWS/GCP/Azure 乗務員向けアプリ後部座席タブレットユーザー向けアプリ運営者向け Webアプリタクシー事業者向け管理画面

Slide 10

Slide 10 text

© GO Inc. 10 Grafanaの導入前オブザーバビリティの重要性 ■ メトリクスとアラート：システムの継続監視 ■ ログ：問い合わせ対応、障害の際の調査 ■ トレース：ボトルネック特定 → とても複雑なシステム構成の中で統一されたオブザーバビリティ機能の提供が非常に重要 Grafana導入前の課題 (メトリクスはSaaS、ログはBigQuery) ■ 全体のユーザビリティの低さ ■ 可視化の難しさ ■ メトリクス、ログ、トレースの連携の難しさ ■ 料金の高さ

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© GO Inc. 15 自前運用の背景 Grafanaを自前で運用することにした理由 ■ コスト削減 - SaaSを利用する場合、データ量課金になりコストが爆増 - 送信するデータを絞ることになってしまう - → 自前運用になるとデータを大量に突っ込める（特にログとメトリクス) ■ カスタマイズ性 - 独自の仕組みと連携可能 - コンプライアンスとセキュリティポリシーに対しての対応 ■ メンテナンスの低負荷の予想 - Kubernetes運用の経験あり - データがS3/GCSなどObjectStorageに保存されるため運用不要

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© GO Inc. 20 アーキテクチャ - アラート MimirとLokiがアラートをAlertmanagerに送信 ■ 「ruler」コンポーネント ■ Mimirはメトリクスベースアラート ■ Lokiはログベースアラート ■ ログからメトリクスを作るためにLokiが Mimirにデータを送信することもある AlertmanagerがGrafana OnCallに通知 Grafana OnCall側でエスカレーションとスケジュールを管理し、必要に応じてSlackに通知したり、電話をかけたりする

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 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話」で検索

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© GO Inc. 25 自前運用の振り返り ■ 初期セットアップが少し大変 - コンポーネントが多い - パラメータが多くてLokiのパフォーマンスチューニングが大変 - 構成と動きを詳しく理解した方がいい → Grafana LabsのブログとPodcastがおすすめ ■ 普段からは安定していて調整する必要がない！ ■ バージョンアップの時は工数がかかる（自前運用のためしょうがない) ■ Grafanaを利用する社内のメンバーからの質問や問い合わせがそれなりにある

Slide 26

Slide 26 text

© 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 などをチューニングしている

Slide 27

Slide 27 text

© GO Inc. 27 自前運用の振り返り困ったエピソード ■ サービス障害が発生し、状況確認のためエンジニアが一斉にGrafanaを利用し、 Mimirの負荷が高まりメモリが足りなくなり、Mimirが大事な時にダウンした → メモリを多めに設定した方がいい ■ AWSのゾーン障害が発生した影響、Grafanaに一時的にアクセスできなくなり、サービスの状況を確認できなかった → マルチAZ構成を再確認した方がいい ■ サービスのトラフィックが急に増えた時、サービスだけではなくGrafanaの負荷も気にする必要がある → リソースを多めに設定するのと、オートスケールさせること全体の感想：それなりの規模で自前運用が可能。苦労するところもなくはないが、メリットが多くて継続予定。困ったらGrafana Cloudに切り替える選択肢もあるため安心！

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© GO Inc. 34 Loki - 圧倒的なコスト削減力サーバログの特徴 ■ 調査のため大量に残す必要がある（何が起きるかわからない) ■ ほぼ見ない（全体の量に対して検索されるのはわずか一部） → 書き込み課金のシステムだとコストパフォーマンスが悪い Lokiはコストが読み込みにかかるため、圧倒的なコスト削減力を持つ ■ Lokiに切り替えることで80%のコスト削減ができた実績もある ■ Lokiのコスト削減効果を得るためだけでも弊社のSREで運用している Kubernetes基盤「Kenos」に移行する社内サービスもある ■ 詳細は「GO TechTalk #30 クラウドコスト削減祭り」で検索

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© GO Inc. 37 Loki - 課題独自のデータフォーマット ■ ログをS3に保存しているため安いが、コンプライアンスのためログを長期保存する場合はそれでもお金がかかる ■ 特に読み込みパフォーマンス向上のためLokiの圧縮にsnappyを利用する場合は圧縮率が落ちる ■ Lokiが標準なフォーマットを利用していればS3からデータをコピペして gzipで再圧縮することも可能なはず → データを他のフォーマットとしてエクスポートする機能があれば嬉しい長期間の集計 ■ 長期間のデータ集計にあまり向いていない ■ データをBigQueryやAthenaなどに簡単に連携できれば嬉しい → 現在は独自の仕組みで連携している

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© 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、配車成功率 …) ■ など

Slide 40

Slide 40 text

© 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

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© GO Inc. 43 Tempo トレースのメリット ■ エラー発生箇所とボトルネックの特定（外部サービス？DB？アルゴリズム？) ■ リクエストの流れを簡単に追えること：特に多数のマイクロサービスを通るリクエストの場合、コードを読まなくても処理の流れがわかる ■ トレースを見るだけで不自然なパターンを発見し問題が発生する前に処理を修正することもあるセットアップ方法：「Golang マイクロサービスの徹底トレース方法 | オブザーバビリティ基盤第3話」で検索