こんばんは。Espernaです。

オブザーバビリティという単語を最近聞くことが増えました。
私はファームウェアエンジニアで、昨年AWS Developer Associateを取りましたが、
以下２つの理由でオブザーバビリティ・エンジニアリングという本を読むことにしました。

自身やチームの開発の仕方を見直す上で重要そうな概念な気がした
- 開発の仕方はCI/CD、TDD、TiDDを取り入れたあたりで止まっていてそろそろ開発の仕方自体見直すタイミングなのではないかと思っていた
仮に今の自分にすぐに役に立つものではなくても、自分が知らない概念を知ることは思わぬところでどこかで何かにつながるかもしれないと思った

また大抵のことは生成系AIで調べれば効率的に答えがわかる世の中になりましたが、
単に読むよりも自身でアウトプットを残した方が自身の理解が深まると思ったので本記事を書くことにしました。

オブザーバビリティとは何か

オブザーバビリティとは、構造化されたイベントの集合をトレースとして繋ぎ合わせられるようにすることでどのようなリクエストに対しても問題を素早く診断するために必要な分析・可視化ができるような、システムの性質と現時点では理解しています。
まずイベントとトレースは次のようなものです。

イベント

本番環境のサービスへの影響を理解するために、ある特定のリクエストがそのサービスとやり取りしている間に発生したすべての記録
データ構造はマップで、マップにはリクエストの有効期間中に発生したものに関する詳細。たとえば以下が入っている
- ユニークID
- 変数の値
- ヘッダー
- リクエストで渡されたすべてパラメータ
- 実行時間
- リモートサービスへのコール
- それらのリモートのサービスの実行時間
これは構造化イベントと呼ばれる

トレース

スパンと呼ばれるリンクされたイベントの有向非巡回グラフ（グラフの向きが一方向で巡回しない）
上記構造は図にすることができる
トレース内のスパンはトレース内の最上位であるルートスパンかルートスパンの中で入れ子になったスパンのいずれかである
ルートスパンの中で入れ子になったスパンはそれ自身の入れ子になったスパンを持つことがある

メトリクスよりトレースが有用

このイベントと従来のメトリクスと呼ばれるものを比較すると、イベントを繋ぎ合わせたトレースの何が有用かがわかる気がします。

メトリクスとはCPU使用率のようなあらかじめ定義された期間にわたるあらかじめ定義された関係を集計されたスカラー値（低次、ディメンションは1）として表現したものです。
過去で発生した故障モードを特定するためにのみ有効で、CPU使用率がとある閾値より高かったらwarningといったような、ある一つのシステムの特性に関してある１つの見方しかすることができません。

それに対して、イベントというのは特定の時点で取った高次のスナップショットで
イベントの特定のパラメータに注目して複数のスナップショットからメトリクス（例えば平均）を計算することでメトリクスを作ることができます。そして、どのようなリクエストに対しても問題を素早く診断するために必要なメトリクスを計算し、問題を素早く診断するために必要な分析・可視化をすることできます。逆にメトリクスからトレースを作ることは難しいです。

まとめ

オブザーバビリティの基礎となる構成要素は任意の幅をもつ構造化イベント(データ構造的にはmap)である
オブザーバビリティのあるシステムではどのようなイベントの集合もトレースとして繋ぎ合わせられることで、どのようなリクエストに対しても問題を素早く診断するために必要な可視化ができる（トレースはスパンと呼ばれるリンクされたイベントの有向非巡回グラフであるため）

所感

ICEで取るトレースだったり複合機やメモリのソフトなどこれまでのソフトウェア開発で
イベントドリブンのプログラムを書くことは頻繁にあり、メトリクス的な概念に触れることは多かったです。
一方で、構造化イベント・トレースといった概念についてはGo言語による分散サービスでちょっとコードを動かしたことがあるくらいで、あまり馴染みがありませんでした。今後自分がゴリゴリのマイクロサービスアーキテクチャの世界でコードを書くかは分かりませんがシステムを考えた時に下位過ぎない、HWを制御するアプリケーションのようなレイヤーであれば「構造化イベント」を採用してみるのも良いかもしれないと思いました。今時人間しか解読できないログも属人性が高く非効率なので。

参考文献

オブザーバビリティ・エンジニアリング
 Go言語による分散サービス