こんにちは、ヘンリーでSREをしているTODA（＠Kengo_TODA）です。 弊社ではデータの共有は主にNotionを用いています。ただ各システムからデータをかき集めて動的に共有するには、Notionはちょっと向いていないなと思うところがあります。データを通じてシステムや顧客、チームの課題を掴むことはスタートアップの生命線とも言え、SLOやKPIを動的に図示してスタンドアップミーティングなどで共有できる仕組みが必要だと感じていました。
このため、Grafanaを用いた仕組みをGCP上に構築しました。ウェブページを自動生成できるツールからの情報は以前Noteでご紹介したサーバーレス社内サイトで展開していますが、Grafanaであれば動的にコンテンツを構築して提供できると期待しています。
この記事ではGCPないしGrafanaの設定をどのようにしたか、その背景とともに説明していきます。
どのようなデータを共有したかったか
サービスを提供するうえで向き合うべきデータは多数存在します。例えばSRE文脈ではFour Keys Metricsや可用性が重要な指標となりますし、ユーザ体験の観点からはレスポンスのスピードも追っていく必要があります。また効果的にお金を使っていくうえで、クラウドやウェブサービスにかかっている費用も監視したいです。
また成長期にあるスタートアップとして価値提供の速度を増していくヒントを探すことも重要です。Product Managerを採用してStream-aligned Teamを増やすことを基本戦略としましたが、ひとつのサービスを複数チームで開発するにあたってチームのKPIやSLOを各チームが独自かつ低コストに追える体制が重要だと考えました。
なぜシステム化が必要だったか
こうしたデータをかき集めること自体は今までもやってきましたが、複数システムに横断したデータを扱おうとするとどうしても手作業が出てきてしまいます。 例えばFour Keys Metricsの変更障害率を算出する場合、デプロイ回数をSentryから、障害の数や対応所要時間をNotionから集めていました。
これらの数値をGoogle Spreadsheetで統合して図示しNotionに蓄積していたのですが、手作業だとデータの鮮度も落ちますし作業コストもかかるという課題がありました。各チームが毎日毎週参照してシステムやチーム、顧客の「今」を掴む仕組みとしてはかなり足りない状態でした。トイル排除が必要だったということです。
既存ソリューションを試す
まずは既存のソリューションを調査しました。評判が良さそうなサービスとしてWaydevがありましたが、事前情報よりかなり金額が高かったため検討から外しました。
OSSのソリューションとしては技術スタックの近いdora-team/fourkeysを検討しました。最近v1.0がリリースされたこともあり好感触でしたが、弊社が採用している開発ツールとのかみ合わせが充分ではなく、多くの指標が算出できないことがわかりました。
forkして対応することも考えましたがあまり再利用できるところがなく、新規に作成することとしました。
基本構成
データをBigQueryに集約してGrafanaで表示する、というdora-team/fourkeysの構成を踏襲しました。GrafanaはPRベースで開発することが可能なため、git-flowに最適化された既存開発体制にマッチしやすいことも強みになります。なおdora-team/fourkeysではPubSubを利用していますが、まだチーム規模は大きくないため不要と考え、PubSubは挟まずデプロイワークフローから直接BigQueryに書き込む形を採っています。
また解析と表示にはLooker Studioを使う選択肢もありましたが、別の用途で使っていることから混乱を避けるため、利用を避けました。
Cloud Runの手前にはIdentity-Aware Proxy（IAP）を置くことで認証をしています。これは以前ご紹介した社内向けサイトと同様の構成なので割愛しますが、GrafanaはProxyによる認証をサポートしていますので誰が何をどう使っているか把握しやすいのが嬉しいです。
どのような値を図示しているか
弊社には複数のStream-aligned Teamがあり、それぞれにプロダクトマネージャが存在します。彼らやエンジニアと議論したりヒアリングしたりしながら、チームごと・サービス全体としてどのような値を見たいかを詰めていきました。
現時点ではサービス全体の指標として、Four Keys Metricsやサーバサイドレイテンシを表示しています。これに加えてインフラコストや可用性、クライアントサイドレイテンシなどの情報を表示していきたいと考えています。
チームごとの指標としては、PRライフサイクルのどこにボトルネックがあるか・チームメイトがまんべんなくPRレビュアーになれているか・まんべんなくPR作成者になれているかなどの傾向をつかめるようにしています。
さらにお客様の体験を少しでも理解するために、可視化できるファクトを充実させていきたいと考えています。現時点で考えているのは、APIごとのレイテンシやエラー率、Cloud SQLのリソース利用状況の異常検知、バッチ処理におけるMTTRに替わる指標の模索などです。
まとめ：顧客の課題を知って向き合うためのダッシュボードを構築した
お客様の課題解決のためにシステムを作り込めば、それだけシステムが複雑になりお客様の体験を理解することが難しくなります。データがあちらこちらに散在していたり、一本軸を通してデータをつなぎ合わせることが難しかったり、そもそもデータを取れているのかわからなくなったりするからです。
それでも重要なのでコストをかけて解決するわけですが、ある程度型が見えてきたらこれをトイルとみなして削減する必要があります。使い勝手の良いダッシュボードを作成することで、サービスを開発するエンジニアとそのユーザとの距離を縮め、今まで以上の品質改善に役立てていけると考えています。
今回は背景と実装の話をしましたので、近々別の記事で実際に運用してみてどうチームや製品が変わったかをお伝えします。
