Grafanaが支えるプロダクト開発 - 開発から本番運用までをサポートする基盤

Transcript

1. Grafana が支えるプロダクト開発 開発から本番運用までをサポートする基盤 Grafana Meetup Japan Fukuoka #1 Staff Developer Advocate, Grafana Labs 反田光洋
2. 自己紹介 反田 光洋 （たんだ みつひろ） @mtanda Staff Developer Advocate Grafana Labs ▶ 約 10 年来の Grafana / Prometheus ユーザー ▶ Grafana 初期バージョンからのコントリビューター
3. はじめに
4. はじめに 今日お話しすること • Grafana Labs が提供しているプロダクトと、それぞれが役立つ場面の紹介 • オブザーバビリティ導入により、具体的にどういう悩みを解決できるか？ • 開発の初期からオブザーバビリティを導入することで実現できること
5. はじめに 今日紹介するプロダクト・機能一覧 プロダクト・機能 Grafana Loki Tempo Mimir Pyroscope Alloy OBI / Beyla k6 概要 可視化・横断調査 ログの保存・検索 トレースの保存・検索 メトリクスの保存・検索 継続的プロファイリングの保存・検索 テレメトリデータの収集・加工・転送 eBPF による自動計装 負荷試験ツール プロダクト・機能 Grafana Faro Synthetic Monitoring Application Observability Kubernetes Monitoring Database Observability SLO IRM AI Assistant 概要 フロントエンド計装 SDK 合成監視 アプリケーション特化の調査機能 Kubernetes 特化の調査機能 データベース特化の調査機能 サービス品質に基づくアラート インシデント対応フローの管理 AI アシスタント
6. 完成図
7. はじめに プロダクトがサポートする 4 つのエリア • 開発時にオブザーバビリティを高める • リリース前に性能を確認する • リリース後にユーザーから見たサービス品質を確認する • インシデントを検知し、対応する
8. はじめに 開発時にオブザーバビリティを高める • オブザーバビリティとは、サービス内部の状態を、外部から取得できるデータだけ で把握できる状態のこと • 内部の状態をテレメトリデータとして記録し、開発や運用に関わる判断の元とする • アプリケーションを計装し、テレメトリデータを収集し、保存した上で検索できる ようにする
9. 開発時にオブザーバビリティを高める
10. はじめに リリース前に性能を確認する • 負荷をかけて確かめなければ、想定した負荷に耐えられるかどうかは分からない • また負荷をかけてみて、はじめてボトルネックとなる箇所が判明する • 負荷試験とプロファイリングをとおして、高負荷時の振る舞いを理解する
11. リリース前に性能を確認する
12. はじめに リリース後にユーザーから見たサービス品質を確認する • サービス提供側は、ユーザーがどのような環境からアクセスしているかはわからな い • サーバ側のメトリクスだけを見ていると、ユーザーから見た体感の悪化には気づけ ない • 合成監視や RUM をとおして、ユーザーが実際に体感するサービス品質を確認する
13. リリース後にユーザーから見たサービス品質を確認する
14. はじめに インシデントを検知し、対応する • 検知の仕組みと対応の手順がなければ、インシデントにすぐに対応することは難し い • 休日や夜間でも確実に対応できる体制を整備する必要がある • インシデント対応の体制を整備し、継続的かつ安定的にインシデントに対応する
15. インシデントを検知し、対応する
16. 開発時にオブザーバビリティを高 める
17. 開発時にオブザーバビリティを高める オブザーバビリティは信頼性の基盤 • 現在のシステムは複雑すぎて、内部の状態を正確に理解することは難しい ‣ コンテナ、Kubernetes、マイクロサービス、サーバレス… • 内部の状態をテレメトリデータとして記録することで、理解を深められる • 正確な判断が下せるようになり、システムの信頼性を高めていける
18. 開発時にオブザーバビリティを高める 何を記録すればよいか？ • Kubernetes などは標準でテレメトリデータを出力しているので、それらを記録す るだけでよい • 開発しているアプリケーションに関しては、どういったデータが必要か考える必要 がある • どのようにしてサービス品質を計測するか、問題が起きた時に原因を調査するかと いう観点で考える • 設計のフェーズで検討し、必要なテレメトリデータが漏れなく正確に記録されるよ うにする
19. 開発時にオブザーバビリティを高める A Braid of Signals • 必要なテレメトリデータを、この 3 つに当てはめていく ‣ メトリクス(What): 何が、どれだけ変化したか。成功率・レイテンシ・スルー プットなど ‣ ログ(Why): 原因につながる文脈は何か。エラー・タイムアウト・依存先の情報 など ‣ トレース(Where): どこで遅延・失敗したか。リクエスト経路や依存先の特定
20. 開発時にオブザーバビリティを高める LGTM スタックで記録する • メトリクス、ログ、トレースを受け止める基盤が LGTM スタック ‣ Loki OSS ‣ Grafana OSS ‣ Tempo OSS ‣ Mimir OSS • OpenTelemetry に対応している • ログとトレースなど、テレメトリデータ同士を関連づけて調査できる
21. 開発時にオブザーバビリティを高める Grafana Alloy で収集する • Grafana Alloy OSS • Grafana Labs が提供する OpenTelemetry Collector のディストリビューション • テレメトリデータを収集し、バッファリングした上で送信する • 必要に応じてテレメトリデータの加工もできる
22. 開発時にオブザーバビリティを高める
23. 開発時にオブザーバビリティを高める 開発環境のオブザーバビリティ • テレメトリデータを出力できるようにする実装を計装という • 開発環境にも LGTM スタックを導入すれば、日々の開発で計装の動作確認ができ る • 特にログやトレースは、開発時の問題調査にも役立つ • 負荷試験時にも、目標とする性能が出ているか確認できる
24. 開発時にオブザーバビリティを高める 自動計装によるクイックスタート • OBI / Beyla OSS • 最初からコードに計装を組み込む以外の選択肢として、自動計装がある • OBI は eBPF を利用した自動計装ツール • 自動計装を使うことで、コードを変更せずに基本的な計装ができる • 足りない部分だけ手動計装で足していくこともできる
25. 開発時にオブザーバビリティを高める Application / Kubernetes / Database 特化の機能 • 記録されているテレメトリデータを専用の UI で表示して、調査をサポート • Application Observability Cloud : アプリケーションに特化した調査機能 • Kubernetes Monitoring Cloud : Kubernetes に特化した調査機能 • Database Observability Cloud : データベースに特化した調査機能
26. 開発時にオブザーバビリティを高める デモ: LGTM スタック • Grafana の Drilldown 機能
27. リリース前に性能を確認する
28. リリース前に性能を確認する リリースに対する信頼性を担保する • 失敗できないような大きなリリースに備える • 大きなリリースでは、運用実績がない新規の部分が多く、不確定要素が多い • 本番環境で初めて問題になることも多い ‣ インデックスの追加漏れ、ディスク性能の限界など • 本番環境相当の負荷をかけてみなければ、想定したとおりに動くかどうかはわから ない
29. リリース前に性能を確認する k6 による負荷試験 • k6 OSS • 本番環境のような高い負荷をかけるのは、実は難しい • 負荷試験専用のツールを使う必要がある • k6 は様々な種類の負荷試験に対応している • 負荷試験の結果を LGTM スタックに記録できるため、条件を変えた試験結果同士 を比較できる
30. リリース前に性能を確認する 継続的プロファイリング • プロファイリングとは、CPU などのリソースをどのコードが消費しているかを計 測する手法 •「継続的」とは、必要なときだけ計測するのではなく、一定間隔のサンプリングを 常時有効にしておくこと • 負荷試験の時間帯のプロファイルを見れば、ボトルネックとなっている処理を見つ けられる • ボトルネックを改善すれば、サービス品質の改善やコスト削減につなげられる
31. リリース前に性能を確認する Pyroscope • Grafana Pyroscope OSS • OpenTelemetry eBPF Profiler OSS • Pyroscope はプロファイリングデータを記録するバックエンド • OpenTelemetry eBPF Profiler はアプリケーションの再ビルド不要で使えるプロ ファイラ • Grafana Alloy に組み込まれているため、簡単に組み合わせて使える
32. リリース前に性能を確認する
33. リリース前に性能を確認する デモ: プロファイリング • k6 による負荷生成とプロファイリング結果の確認
34. リリース後にユーザーから見た サービス品質を確認する
35. リリース後にユーザーから見たサービス品質を確認する リリース後にも、確認しきれないことがある • 負荷試験は、いわば理想的な環境・条件での検証 • QA で様々なブラウザでのテストを行っても、それでも検証しきれないものがある • 実際のユーザーの環境はさまざまで、全てを網羅できない
36. リリース後にユーザーから見たサービス品質を確認する 合成監視とフロントエンド監視 • Synthetic Monitoring Cloud ‣ 世界各地に配備された probe を使って、サービス品質を計測する • Grafana Faro OSS ‣ ユーザーが使っている実際の端末を使って、サービス品質を計測する
37. リリース後にユーザーから見たサービス品質を確認する
38. インシデントを検知し、対応する
39. インシデントを検知し、対応する SLO に基づくアラート • SLO アラート Cloud • サービス品質に基づくアラートルールを設定する機能 • SLO アラートに関連した便利な機能を提供している ‣ SLO アラートの設定を補助する設定画面 ‣ 設定されている SLO の達成状況を確認できるダッシュボード
40. インシデントを検知し、対応する IRM でインシデント対応の体制を整える • IRM Cloud • アラートを適切に通知しなければ、気づけずに対応が遅れてしまう • 確実に対応できるように IRM で体制を整備する ‣ アラートの種別や発生時間を条件とした通知先設定 ‣ エスカレーション先の設定 • 対応中アラートの管理機能 • アラート通知を受け取れるアプリも提供されている
41. インシデントを検知し、対応する
42. 完成図
43. OSS で実現できる範囲
44. おまけ: AI 活用
45. おまけ: AI 活用 AI Assistant によるサポート • AI Assistant Cloud • やりたいことを伝えるだけで、誰でも簡単に Grafana を使いこなせる ‣ インシデントの原因調査 ‣ ダッシュボード作成 ‣ k6 の負荷試験スクリプト作成など • Grafana の UI に制約されることなく、記録されているあらゆるデータを連携させ て活用できる
46. まとめ
47. まとめ ご紹介したプロダクト・機能 自分のインフラで動かす • Grafana / Loki / Tempo / Mimir / Pyroscope OSS • Alloy OSS • OBI / Beyla OSS • k6 OSS • Grafana Faro OSS Grafana Cloud で使う • Application / Kubernetes / Database Observability Cloud • Synthetic Monitoring Cloud • SLO / IRM / AI Assistant Cloud • 手元で試すなら otel-lgtm の Docker イメージがおすすめ • Grafana Cloud にも無料枠があるので、個人利用の範囲であれば十分試せる
48. まとめ Grafana が支えるプロダクト開発 • Grafana Labs のプロダクトは、開発初期の段階からリリース後までの全てをサ ポートする • オブザーバビリティが基盤となり、あらゆる場面でサービスの信頼性向上に取り組 むことができる • 気軽に使い始められるものなので、ぜひ使ってみてください！