オブザーバビリティとは何か? CI/CDとdeploymentの解説

オブザーバビリティは、システムが発するデータ(metrics、logs、traces)を使って、その内部状態を外部から理解できるようにするシステムの性質です。

システムは、それを計装する新しいコードを出荷せずに、その挙動に関する新しい問いに答えられるとき、observableです。この用語は制御理論に由来しますが、ソフトウェアでは、3つのシグナル型が連携して機能することを中心に構築された文化とツール群の略語になっています。CI/CDにとって、オブザーバビリティは緑と赤のcheckの壁を、なぜbuildが遅くなったのか、あるいはなぜdeployが失敗したのかの説明へと変えるものです。

オブザーバビリティが実際に意味すること

オブザーバビリティは購入する製品ではなく、システムが持つか持たないかの性質です。システムは、その出力が内部で何が起きたかを再構成するのに十分な情報を運ぶとき、observableです。実践的なテストは、loggingを追加して再発を待つのではなく、すでに収集しているデータを使って、誰も予期しなかった真新しい障害モードを調査できるかどうかです。

3つの柱

Metrics: 時系列の数値測定で、保存が安価でクエリが高速、dashboardやアラートに適しています。
Logs: 離散的なイベントのtimestamp付き記録で、詳細に富み、事後の調査に適しています。
Traces: 単一のリクエストやjobがコンポーネントを横断する経路で、時間やエラーが蓄積する場所を見つけるのに適しています。

オブザーバビリティとmonitoring

monitoringは、すでに監視すると予期していたものが健全かどうかを教えてくれます。エラー率がしきい値を超えているか、ディスクが満杯か。オブザーバビリティはより広範です。それは事後に任意の問いを立てる能力です。monitoringは「壊れているか」に答え、オブザーバビリティは「なぜ、どこで壊れているか」に答える助けとなります。優れたmonitoringは優れたオブザーバビリティのデータの上に成り立ちます。

なぜCI/CDに重要か

pipelineもシステムであり、紛らわしい形で失敗します。特定のrunnerでのみ遅いbuild、成功するがappを不健全なままにするdeploy、再実行では通るflakyなjobなど。pipelineに対するオブザーバビリティとは、buildの所要時間と成功率のmetrics、各ステップからの構造化されたlogs、そしてpipelineが実時間をどこで費やすかを示すtracesを収集することを意味し、製品をデバッグするのと同じ厳密さでpipelineをデバッグできるようにします。

deploy自体を観察する

デリバリーで最もリスクの高い瞬間はdeployです。オブザーバビリティは、その境界を越えてシステムを観察できるようにします。変更の前後でエラー率、レイテンシ、飽和を比較し、あらゆる回帰を正確なcommitやreleaseに結びつけます。これが安全なrollout、canary分析、迅速なrollback判断の基盤です。

Latchkeyの視点

Latchkeyは、デリバリーのbuild側に対するオブザーバビリティを提供します。マネージドrunner上のjobごとのテレメトリで、各jobがどれだけ待ち、実行されたか、どのrunnerがそれを処理したか、どう完了したかを含み、pipelineの遅延や失敗を推測ではなく、見て説明できるものにします。

重要なポイント

オブザーバビリティは、システムが発するデータからそれを理解する能力です。
その3つの柱はmetrics、logs、tracesです。
monitoringは「壊れているか」を問い、オブザーバビリティは「なぜか」に答える助けとなります。
CI/CDでは、pass/failのcheckをbuildとdeployの挙動の説明へと変えます。