Skip to content
Latchkey

オブザーバビリティとは?

オブザーバビリティは、システムが発するデータからその内部状態をどれだけ理解できるか - 構築時に予期しなかった質問に答えられるほどに - の度合いです。

制御理論から借用したオブザーバビリティは、ソフトウェアにおいてはシステムの振る舞いについて任意の質問をし、新しいコードを出荷することなくそのテレメトリから答えを得られることを意味します。予測した障害だけでなく、本番環境で新規の問題をデバッグできるようにするものです。

ツールではなく性質

オブザーバビリティはシステムの性質であり、その出力が内部で何が起きているかをどれだけよく推論させてくれるかを表します。ダッシュボードを買うことではなく、リッチで高カーディナリティなデータを発するようコードを instrument することで改善します。instrument が不十分なシステムは、どんなツールを使っても不透明なままです。

3つのテレメトリタイプ

  • Logs:離散的なイベントのタイムスタンプ付き記録。
  • Metrics:時間にわたって集約された数値測定。
  • Traces:複数のサービスをまたぐ単一リクエストの経路。

known unknowns 対 unknown unknowns

monitoring は、聞くべきとわかっていた質問 - 事前定義された閾値やダッシュボード - に答える傾向があります。オブザーバビリティは unknown unknowns、つまり新規で前例のない障害モードに関するものです。リッチなテレメトリがあれば、予期しなかった振る舞いを説明するためにデータをスライスして探索できます。

高カーディナリティが重要

現代のオブザーバビリティは、高カーディナリティ・高次元なデータ - user ID、request ID、region、build version のような詳細でイベントにタグ付けすること - を重視します。その粒度により、「遅いリクエストはすべて一つの新リリース上の一顧客からのものだ」と切り分けられ、粗い metrics ではこれを平均化して消してしまいます。

なぜ delivery にとって重要か

優れたオブザーバビリティはサービス復旧時間を短縮します。何かが壊れたとき、推測する代わりに素早く局所化して説明できます。また deploy のフィードバックループを閉じ、新しいリリースが本番環境で期待どおりに振る舞うことを確認させてくれます。

重要なポイント

  • オブザーバビリティは、システムの出力がその内部状態をどれだけよく理解させてくれるかです。
  • logs、metrics、traces の上に構築され、リッチで高カーディナリティなデータを重視します。
  • monitoring の事前定義された質問を超えて、unknown unknowns を対象とします。

関連ガイド