TeleTrackingがGrafana Cloudを使ってより優れたオブザーバビリティプラットフォームを構築するための旅の全貌
Oren Lion（ソフトウェアエンジニアリング、プロダクティビティエンジニアリングディレクター）とTim Schruben（ロジスティクスエンジニアリング副社長）は、医療システムのケアへのアクセス最適化、ケア提供の合理化、ケア移行の接続を支援することで、Expanding the Capacity to Care™を実現する統合ヘルスケア・オペレーション・プラットフォーム・プロバイダーであるTeleTrackingに勤務している。
今日の分散アプリケーションが多くの複雑さをもたらすならば、オブザーバビリティチームにとっての聖杯は、開発チームが自分たちのサービスにオブザーバビリティを簡単に統合し、フィードバックを得て、潜在的な問題に対応することを可能にすることです。
TeleTrackingのエンジニアリングチームは、この哲学を現実にするために、PrometheusとGrafana Cloudを組み合わせた中央集権的なオブザーバビリティスタックの採用を進めています。これらのツールは、私たちのサービスに対する可視性を向上させるだけでなく、常に進化する開発者体験の重要なフィードバックメカニズムとして機能します。また、Grafana Cloudのメトリクスコスト管理ツールであるAdaptive Metricsを使用することで、オーバーヘッドを削減し、チームの他の高インパクトプロジェクトへの投資を増やしています。
このブログでは、私たちがどのようにしてここにたどり着いたのか、社内の他のメンバーをどのように巻き込んだのか、そしてGrafana Cloudがどのようにしてビジネスにより多くの価値をもたらし、時間とコストを節約するのに役立ったのかをご紹介します。
SaaSからOSSへ、そして再びSaaSへ
現在私たちがどのようにGrafana Cloudを使用しているかについて説明する前に、ここに至るまでの経緯を簡単に振り返りたいと思います。約6年前、私たちのオブザーバビリティのコストは非常に高額になり、それを見直すためにオープンソースツール（Grafana、 Prometheus、Thanos）を使ってすべてを社内で開発することに決めました。
私たちは、AWSとMicrosoft Azureにまたがるサービスのグローバルビューを提供するシステムを設計しました。これには、Amazon EKSやAzure Kubernetes Service（AKS）のクラスター、Amazon EC2、AWS Lambda、Azure VMs、Azure App Servicesなど、さまざまなクラウドリソースが含まれていました。オープンソースを愛する一方で、最初に目指していたオブザーバビリティを効果的にし、セルフサービスで低コストにするという目標を見失ってしまいました。運用が拡大するにつれ、反対の方向に進み、管理されたソリューションに戻る必要があることに気付きました。
最終的に私たちはGrafana Cloudを選びました。メトリクスとログに共通のラベルを持てる点、Grafana Loki（Grafana Cloud Logsを支えるオープンソースのロギングソリューション）の性能の良さ、ログの解析方法を事前に定義する必要がない点を気に入りました。また、リモート書き込みモデルを使用するGrafana Cloud Metricsの中央集権的なアプローチや、Grafanaダッシュボードでメトリクスとログの両方を並べて視覚化できる点も評価しました。
Grafana Cloudでのオブザーバビリティ向上への道
私たちが移行を決めたとき、開発者が自分たちのサービスを監視する方法を簡単に設定できるようにしたいと思いました。ここでは、私たちが行った変更の概要を紹介します。
設定の簡素化
最初に行った変更の一つは、開発者が監視設定（アラートルールを含む）を自分たちのサービスのソースコードと同じリポジトリに保存できるようにすることでした。
アラートルールの設定は、リポジトリのビルドファイルに一行のBitbucket Pipe アラートルールを追加することで簡素化されました。これにより、アラートルールがGrafana Cloudに公開されます。多くのアラートルールはすべてのサービスで共通しており、例えば、サービスの稼働状況（up）や停止状態（absent）のアラート、イベント処理の偏差などです。そのため、標準アラートは中央リポジトリに保存しました。
監視設定は、リポジトリにServiceMonitorを追加することで簡素化されました。デプロイパイプラインに変更を加えることなく、kustomizationファイルに追加するだけで簡単にデプロイできます。
目的地: 2つの重要なラベル
ソフトウェアエンジニアリングチームはサービスラインとサービスに沿って再編成されました。そのため、チームが同じ原則をオブザーバビリティに適用しやすくすることを目指しました。これを実現するために、すべてのメトリクスとログに2つの重要なラベル（servicelineとservice）を標準化しました。メトリクスとログに対してシンプルで一貫したラベル付けを行うことで、開発者はデータを関連付け、両者間をスムーズに移動し、一貫したアラートを受け取ることが容易になります。
これらのラベルはすでにKubernetesで実行されるサービスのServiceマニフェストに設定されていたため、メトリクスにこれらのラベルを追加するには、ServiceMonitorファイルのtargetLabelsフィールドに「service」と「serviceline」を設定するだけで済みました。targetLabelsはKubernetesのサービスからラベルをメトリクスに注入します。
ログについては、サービスラインラベルとして値をどこから取得するかという問題に直面しました。最終的には、Kubernetesのネームスペースをサービスラインラベルとして使用することにしました。ただし、チームはサービスをサービスラインにちなんで命名されたネームスペースにデプロイしていなかったため、開発者はこれらの新しいネームスペースに再デプロイする必要がありました。
Kubernetesクラスターで実行されないサービスには、追加の変更が必要でした。これには、AMIsにGrafana Agentを組み込むことから、レガシーサービスにログアペンダーを追加するコード変更までが含まれます。すべての設定には、サービスラインとサービスのラベルを注入する必要がありました。
これらの2つの重要なラベルを手に入れたことで、チームはメトリクスとログを簡単にクエリおよびアラートする方法を得ました。ダッシュボードの設定も同様に、これらのラベルをフィルタリングすることで簡素化されました。これにより、プラットフォーム全体のREDメトリクスに可視性を得やすくなり、サービスラインや各サービスに焦点を絞ることができるようになりました。
機能のための「舗装された道」
AWS Lambdaで実行されるサービス向けに、「舗装された道」リポジトリ作成ツールを構築しました。これにより、新しいコードリポジトリを事前に構築し、次の機能を備えています：
- SpinnakerとTerraformを使用してAWSにコードをデプロイ
- メトリクスをPrometheus Pushgatewayにプッシュ
- アラートルールをGrafana Cloudに公開
- ログをLokiに転送
これにより、「舗装された道」Lambdaリポジトリを使用する開発者は、サービスのデプロイや監視などの依存関係に費やす時間を減らし、ビジネス機能に集中する時間を増やすことができます。今年の後半には、このモデルをマイクロサービスに拡大する予定です。
2つのラベル、1つのルート、そして1つのレシーバーがバーに入る
アラートもサービスラインとサービスラベルに基づいているため、定義されたすべてのサービスラインに対して、すべてのルートとレシーバーが事前に構築されていました。24時間365日オンコールエンジニアにページングする高優先度のアラートと、緊急度の低い情報アラートを区別するために、各サービスラインには2つのレシーバーがあります。一つは高優先度のアラート用でオンコールエンジニアに送信され、もう一つは低優先度のアラート用で中央のSlackチャンネルに投稿されます。
最初はこのアイデアに抵抗するエンジニアもいましたが、キーワードラベルを使い始め、ダッシュボードを立ち上げ、簡単にアラートを書き始めると、その価値をすぐに理解しました。ログとメトリクスをシームレスに行き来できる能力も相まって、開発者はすぐにこの新しいフレームワークに夢中になりました。
少ない労力でより多くを得る
Grafana Cloudは私たちのチームの作業負荷を大幅に軽減しました。自己ホスティングのスタックを管理したり、ネットワーク全体でのクエリに関する権限の問題をトラブルシューティングしたりする心配がなくなり、すべてが処理されています。
そして、2つのキーワードラベルのルールが実を結びつつあります。今では細かいレベルから粗いレベルまでのビューを組み合わせることができます。ダッシュボードに配置したラベル上の変数を使用して、ビジネスメトリクスから低レベルのサービスラインやサービスメトリクスまで移動し、再び戻ることができます。
ツール間のこの一貫性により、多くのタスクを簡単に実行できるようになりました。すべてを1つのダッシュボードに集約し、他の人が自分自身のアラートを作成できるようにすることができます。これは他のオブザーバビリティツールでは実現できなかったことであり、私たちが成長し、他のGrafana Cloudサービスやサードパーティのデータソースを統合するにつれて、このラベルフックはさらに価値を発揮するでしょう。
コストの抑制
メンテナンスの軽減に加えて、私たちはかなりのコスト削減も実現しましたが、初期の予算制約に直面することもありました。Grafana Cloud Logsの初期コストは、月間目標を上回る傾向にありましたが、チームがより良いログ管理の実践を採用するにつれて、ある程度の変動が予想されました。これらの超過に対処するために、ログの取り込み量を監視し、デバッグ作業が完了した後にログレベルを調整するために開発チームと協力しました。
予想外だったのは、Grafana Cloud Metricsのコストがどれほど急速に増加するかでした。メトリクスのコストを予測するのは難しいですが、新しいサービスやエクスポーターごとに費用が大幅に増加することに気づきました。
Grafana CloudのCardinality Managementダッシュボードを使用して、費用増加の原因となるメトリクスを特定しましたが、コード変更やデプロイが完了するまで費用削減がすぐに実現されるわけではありませんでした。しかし、Adaptive Metricsを使用することで、迅速かつ低労力でコストを削減することができました。Adaptive Metricsは、未使用または部分的に使用されているメトリクスを低カードナリティバージョンに集約します。これはメトリクスの「ログレベル」のように機能します。アクティブにデバッグして詳細なラベルが必要な場合にはメトリクスの詳細度を上げ、デバッグが完了したら、Adaptive Metricsを使用してラベルを再集約して詳細度を下げることができます。これにより、Grafana Cloud Metricsの費用を50％削減しました！
さらに、Grafana Cloudが予想外の方法で私たちにお金を節約してくれたことにも満足しています。例えば、Grafana Labsと協力して契約を調整し、予測使用量に基づく前払いの支出コミットメントで運営できるようにしました。この変更により、潜在的な超過を回避し、全体の請求額を20％削減することができました。また、Grafana Cloudでのリソース割り当てに柔軟性を持たせることができました。最後に、最近の経済不安の中で重要だった費用の予測可能性も提供されました。
より多くの機能を低コストで
現在、これらの節約と全体の請求額の削減を組み合わせることで、主要なラベルで結びつけられたこのオブザーバビリティフレームワークの下でより多くの機能を統合する準備が整いました。これらの節約分をGrafana Cloudに再投資する予定です。
Frontend Observabilityを採用して、ブラウザでのユーザー体験とバックエンドサービスの間の相関関係を描くことができるリアルタイムのフロントエンドメトリクスを取得します。また、Grafana Incidentを採用して、オンコールのサービスラインチームメンバーとログやメトリクスをより緊密に統合し、サービスの復旧を迅速化します。
Frontend Observability（オープンソースのGrafana FaroウェブSDKによって提供される）およびGrafana Incident（Grafana Incident & Response Managementサービスの一部）への移行により、今年後半に移行予定の競合製品に対する支出を大幅に削減できます。
数年前とはまったく異なる状況です。もはや、ただの維持管理や問題対応に追われることはありません。今日では、積極的に新しい方法を見つけてビジネスをサポートし、開発者がより簡単に、迅速に、効率的に仕事をできるように支援しています。
Grafana Cloudは、メトリクス、ログ、トレース、ダッシュボードなどを始める最も簡単な方法です。永遠に無料の手厚いプランや、あらゆるユースケースに対応するプランがあります。今すぐ無料でサインアップしましょう！
