はじめに
マイクロサービス化やクラウドネイティブ化が進み、システムの構成要素は増え続けています。その一方で、本番環境で起きている問題を突き止める手段は、いまだに「CPU使用率のダッシュボード」と「しきい値アラート」に依存しているチームが少なくありません。
本記事では、Charity Majors・Liz Fong-Jones・George Miranda 著『オブザーバビリティ・エンジニアリング』（大谷和紀・山口能迪 訳、オライリー・ジャパン、2023年）を読んだ内容を、設計やアーキテクチャに関心のあるエンジニア向けに整理します。
本書は「オブザーバビリティとは何か」という定義の話から始まり、構造化イベント・トレース・OpenTelemetry といった技術的な基礎、SLO を使ったアラート設計、大規模環境でのデータストアやサンプリング、そして組織文化の変革までを一冊で扱います。技術書でありながら、後半は完全に組織論・変革論になっているのが特徴です。
書誌情報
| 項目 | 内容 |
|---|---|
| 書名 | オブザーバビリティ・エンジニアリング |
| 著者 | Charity Majors、Liz Fong-Jones、George Miranda |
| 訳者 | 大谷 和紀、山口 能迪 |
| 出版社 | 株式会社オライリー・ジャパン |
| 発行 | 2023年1月27日 初版第1刷 |
| ISBN | 978-4-8144-0012-6 |
構成は全5部22章です。うち14章と18章は Slack のエンジニアによるゲスト寄稿となっています。
本書の全体像
本書の章立ては、大きく次のように分かれています。
- 第Ⅰ部 オブザーバビリティへの道（1〜4章）：定義、モニタリングとの違い、実例、DevOps/SRE との関係
- 第Ⅱ部 オブザーバビリティの基礎（5〜9章）：構造化イベント、トレース、OpenTelemetry、イベント解析、モニタリングとの共存
- 第Ⅲ部 チームのためのオブザーバビリティ（10〜14章）：導入の進め方、オブザーバビリティ駆動開発、SLO、ソフトウェアサプライチェーン
- 第Ⅳ部 大規模なオブザーバビリティ（15〜18章）：ROI と Build or Buy、データストア、サンプリング、テレメトリーパイプライン
- 第Ⅴ部 オブザーバビリティの文化を拡大する（19〜22章）：ビジネス事例、利害関係者、成熟度モデル、今後
「技術 → チーム → スケール → 文化」という順に視野が広がっていく構成で、読み進めるうちに関心の対象が自然にコードから組織へ移っていきます。
第Ⅰ部：オブザーバビリティとは何か
数学的な起源から出発する
本書はまず、オブザーバビリティという言葉の出自から入ります。この用語は1960年に Rudolf E. Kálmán が制御理論の文脈で提唱したもので、外部出力に関する知識から、システムの内部状態をどれだけうまく推測できるかを示す尺度として定義されました。
これをソフトウェアシステムに持ち込んだ本書の定義は次の通りです。
システムがどのような状態になったとしても、どんなに斬新で奇妙な状態であっても、どれだけ理解し説明できるかを示す尺度
重要なのは「事前にデバッグの必要性を予期・予測することなく」という条件です。新しいコードをリリースせずに、未知の状態を理解し説明できるか。ここがオブザーバビリティの有無を分ける線として置かれています。
モニタリングとの違いは「既知」か「未知」か
2章では、従来のモニタリングとオブザーバビリティのデバッグ手法の違いが丁寧に整理されます。
| モニタリング | オブザーバビリティ | |
|---|---|---|
| 基本姿勢 | リアクティブ | 探索的・反復的 |
| 対象 | 既知の障害モード | 既知・未知を問わない |
| データ | 集計されたメトリクス | 生の構造化イベント |
| 前提 | 何が壊れるか知っている | 何が壊れるか知らなくてよい |
従来のモニタリングは、システムの状態を既知のしきい値と照合し、過去に発生したことのあるエラー状態が存在するかを示すことで機能します。これは過去に起きた故障モードの特定にのみ有効な、本質的にリアクティブなアプローチです。
一方でオブザーバビリティツールは、パフォーマンス問題がどこでなぜ発生しているかを、反復的な探索によって体系的に判断できるようにします。
この対比は、本書を通じて繰り返し登場する軸になります。
Parse の失敗談が刺さる
3章は共著者 Charity Majors による、Parse（モバイルバックエンド・アズ・ア・サービス）での実体験です。Icinga/Nagios と Ganglia で監視を組み、しきい値を設定し、ダッシュボードを増やし続けた結果どうなったか、という話が一人称で語られます。
ここで印象的だったのは、ハンマーの比喩です。TSDB とそのインターフェースを理解すると、あらゆるシステムの問題が突然「時系列ハンマーで叩く釘」のように見えてくる、という一節があります。ツールの理解が深まるほど、そのツールの守備範囲を超えた問題まで同じ枠組みで解こうとしてしまう。心当たりのある人は多いのではないでしょうか。
マルチテナントのプラットフォームでは、「どこかのアプリが遅い」という問題が、全体の集計値には一切現れません。集計してしまった時点で、個別のテナントの体験は見えなくなります。この構造的な限界が、オブザーバビリティを必要とする動機として説得力を持って語られます。
DevOps / SRE / クラウドネイティブとの関係
4章では、オブザーバビリティが単独で生まれたものではなく、DevOps・SRE・クラウドネイティブという流れの結果であり、かつ不可欠な要素でもあると位置づけられます。
ここで挙げられている整理が的確でした。オブザーバビリティはテスタビリティと同種の性質であり、一度追加して終わりではなく継続的な投資を必要とする、というものです。
クラウドネイティブは疎結合による自律的なリリースを可能にしますが、その代償として複雑性の管理コストが発生します。抽象化されたシステムと動的な制御は、創発的な複雑性と非階層的な通信パターンという新しい課題をもたらす。モノリスならシンプルな監視で足りたが、そうはいかなくなった、という因果関係が明示されます。
第Ⅱ部：技術的な構成要素
ここからが本書の技術的な中核です。
構造化イベントという最小単位
5章のテーマは、オブザーバビリティの構成要素は任意の幅を持つ構造化イベントである、という主張です。
イベントの定義はシンプルです。あるリクエストがサービスとやりとりしている間に発生したすべての記録。実装としては、リクエスト開始時に空のマップを初期化し、ユニークID、変数の値、ヘッダー、パラメーター、実行時間、リモートサービスへの呼び出しとその所要時間など、後のデバッグに役立ちそうなコンテキストを片っ端から追加していきます。リクエストが終了またはエラーになった時点で、そのマップ全体をキーバリューのペアとして記録する。これが構造化イベント（ワイドイベント）です。
メトリクスとの決定的な違いは、コンテキストを保持しているかどうかです。メトリクスは特定の時間に発生したことの集計値であり、集計した時点でコンテキストは失われます。集計された値に対して、後から新しい質問を投げることはできません。
新しい質問を後からできるかどうか。これがオブザーバビリティの実務上の判定基準になります。
イベントをトレースにつなぐ
6章は分散トレースです。ここでの定義もシンプルで、分散トレースとは相互に関連した一連のイベントでしかない、と割り切られています。
トレースの構成要素、手作業でトレースを組み立てる手順、スパンに関連データを付与する方法がコード例つきで説明されます。そのうえで、この「イベント間の関係を作って追跡する」という概念は従来のトレースのユースケースをはるかに超えて適用できる、という展開になります。ログイベントをつなぎ合わせるといった、非伝統的な使い方が紹介されるのが面白いところです。
OpenTelemetry による計装
7章は OpenTelemetry を使った計装の実践です。本書はオブザーバビリティベンダーの社員によって書かれていますが、ここではベンダー非依存の姿勢が明確に打ち出されており、オープンソース標準を使った計装方法が解説されます。
ここで強調されているのは、自動計装はスタート地点にすぎないという点です。アウトオブザボックスの計装でひと通りのテレメトリーは出ますが、オブザーバビリティの真価は、意図したビジネスロジックが実際にどう動いているかをデバッグするためのコンテキストを、カスタム属性として追加したところから生まれます。
「とりあえず自動計装を入れました」で止まっているプロジェクトは多いはずで、この指摘は実務的です。
コア分析ループ
8章が個人的にもっとも学びが大きかった章です。
従来のデバッグは、システムについて知っていることを手がかりに行われます。シニアエンジニアが「どこを見ればいいか」を直感的に知っている、あの現象です。マネージャーはその魔法を捕まえようとして、詳細な手順書を書かせ、ダッシュボードを増やしていきます。
しかし本書は、その努力の大半は無駄になると断じます。理由は明快で、現代のシステムはまったく同じ方法で2度故障することがほとんどないからです。
これに対して提示されるのが「第一原理からのデバッグ」とコア分析ループです。仮説を立て、データを探索して確認し、絞り込み、また仮説を立てる。この反復を回すアプローチで、しかもその総当り部分は自動化できる、という流れで話が進みます。
そして本書がここで述べている効果が重要です。仮説駆動型のデバッグは、直感やパターンマッチに頼るより科学的であるだけでなく、デバッグという行為を民主化するというものです。
従来の手法では、システムに精通した経験豊富な人ほど早く答えにたどり着けます。しかしオブザーバビリティによるデバッグでは、好奇心が旺盛で本番環境のコードを熱心に見る人が有利になる。システムの知識がほとんどない人でも問題に飛び込んでデバッグできるはずだ、と。
属人化の解消をツールと手法の側から実現するという主張であり、チーム設計の観点からも示唆に富みます。
なお8章では AIOps に対する懐疑的な評価も述べられており、「機械が自動で根本原因を教えてくれる」という期待への冷静な反論として読めます。
モニタリングは捨てなくてよい
9章は、実務上とても現実的な章です。
「では既存のメトリクスと監視の資産は全部捨ててオブザーバビリティで作り直すのか」という問いに対して、本書はそれは大胆で軽率な行動だと明確に否定します。
提示されるガイドラインはシンプルです。
- オブザーバビリティはアプリケーションレベルの問題を理解するのに最適
- モニタリングはシステムレベルの問題を理解するのに最適
ワークロードの性質を考慮して、両者を共存させる。移行を検討する立場としては、このスタンスは非常にありがたいものでした。
第Ⅲ部：チームと開発プロセスへの適用
オブザーバビリティ駆動開発（ODD）
11章のテーマは、オブザーバビリティをリリース後のものだと思わないということです。
本書は TDD との対比でこれを説明します。TDD は過去20年で定着した強力なプラクティスですが、その強さの源泉は「テストが毎回同じ方法で実行される」ことにあります。データは実行の間で永続化されず、外部システムはスタブやモックで処理される。つまり TDD は、制御された状態における期待動作を定義する営みです。
しかし本番環境は制御された状態ではありません。ここに構造的なギャップがあります。
そこで、テストをシフトレフトしたのと同じ発想で、オブザーバビリティもシフトレフトする。コードを書く段階から「これは本番でどう観測されるか」を設計に織り込む、というのがオブザーバビリティ駆動開発です。
計装をリリース前の作業項目ではなく設計要素として扱う考え方は、個人開発でもすぐに取り入れられそうだと感じました。
SLO とエラーバジェット
12章・13章は SLO の実践です。
12章は、しきい値アラートがなぜ機能しないのかという話から始まります。CPU 80%超、空きメモリ10%以下といった「潜在的な原因」の測定は簡単ですが、そこから意味のあるアラートは生成できません。CPU 使用率の偏差は、バックアップ処理でもGCでも起こりうるからです。結果として偽陽性が多発します。
そして経験を積んだチームほど、そうしたアラートを無視したり抑制したりすることを学びます。「あのアラートは気にしなくていい、たまにメモリ不足になるのは知っている」というやつです。
本書はこれを、チャレンジャー号事故の調査から生まれた逸脱の常態化という言葉で説明します。アラームを遮断したり無反応でいることが繰り返されると、やがて期待される反応から外れた行為に鈍感になり、それが間違っているとすら感じなくなる。最悪の場合、連鎖的なシステム障害と悲惨な過失につながります。
「アラート疲れ」を組織文化の劣化として捉えるこの視点は重要です。
解決策として提示されるのが、ユーザー体験を基準にした SLI を定義し、SLO とエラーバジェットで運用するアプローチです。
13章では、エラーバジェットのバーンアラートの設計に踏み込みます。ここで本書が強調するのは、エラーバジェットが枯渇する前にアラートを出す必要があるという点です。枯渇してから気づいても手遅れなので、枯渇する軌道に乗ったかどうかを予測する必要がある。SLO の目標が高いほど、対応可能な時間は短くなります。
さらに、信頼性の高い計算のためには時間ベースのメトリクスではなくイベントベースのオブザーバビリティデータを使うべきだ、という主張がなされます。SLO とオブザーバビリティが技術的に接続される部分で、12章と13章はセットで読む価値があります。
CI/CD パイプラインにもオブザーバビリティを
14章は Slack の Frank Chen による寄稿で、ソフトウェアサプライチェーン（開発から CI/CD を経て本番デプロイに至るまでの、ソフトウェアに入るもの・影響を与えるものすべて）へのオブザーバビリティ適用がテーマです。
「ビルドが遅い」「たまにコケる」という問題は、本番環境の障害と同じ構造を持っています。ビルドシステムも予期せぬ形で変化し、不十分な統合や見えないボトルネックに苦しみます。ならば同じ道具立てで観測すればよい、という話です。
CI/CD をトレースの対象として捉える発想は、そのまま自分の環境にも持ち込めそうです。
第Ⅳ部：大規模化したときの現実
第Ⅳ部は、本書の中でもっとも技術的に濃い部分です。
作るか買うか
15章は Build or Buy の判断です。ここで著者たちは、自分たちがオブザーバビリティベンダーの社員であり明らかにバイアスを持っていることを最初に認めたうえで、コストを定量化する方法論を提示します。訳注で、翻訳者2名も同様のベンダーの社員であることが明かされているのも誠実です。
本書が繰り返し指摘するのは、人はオープンソースや「無料」の代替品と比較するとき、自分の時間の値段を考えることに慣れていないという点です。ベンダーの請求書は項目として見えますが、自前運用の人件費と機会費用は見えません。
そして、構築と購入は二項対立ではなく、状況によっては両方が正解になりうる、という結論に落ち着きます。
なぜ TSDB では足りないのか
16章は Honeycomb 自社のデータストア「Retriever」を題材にした実装解説です。
まず機能要件が整理されます。
- クエリは数秒以内に返る必要がある（コーヒーを淹れられる待ち時間なら、そのツールは実運用に向かない）
- イベント内のどのフィールドもクエリ可能でなければならない
- どのフィールドが関連するか事前に分からないため、事前集計はできない
- 特定のディメンションだけを優遇できない（すべて等しく高速である必要がある）
- 唯一の例外は時間というディメンション
これらの要件から、時系列データベースがオブザーバビリティに適さない理由が導かれます。すべてにインデックスを張るのは法外に高価であり、かといってインデックスなしで高速に検索する必要がある。この矛盾を解くためにカラムナ（列指向）データストアが選ばれる、という論理展開です。
その後、時間によるデータ分割、セグメント内での列ごとの格納、クエリワークロードの実行、リアルタイムクエリ、ストレージの階層化、並列処理、高カーディナリティへの対応、スケーリングと耐久性の戦略、と実装の詳細が続きます。
そして最後に「自前で構築する際の注意点」が置かれています。ここまで読むと、なぜそれが大変なのかが実感を伴って理解できる構成になっています。データストアの設計に関心があるなら、この章だけでも読む価値があります。
サンプリングを正しく理解する
17章はサンプリング戦略で、本書で最も分量のある章です。
出発点となる認識は明快です。ほとんどのアプリケーションでは、イベントの大半は事実上同じもの、つまり「正常動作している」というものです。それを100%バックエンドに転送するのは無駄である、と。
ただし本書は、単に量を減らす話としてサンプリングを扱いません。効果的なデバッグには「悪い」イベントと比較するための「良い」イベントの代表サンプルが必要であり、適切なメタデータを添えて送ることで、サンプルされなかったイベントで何が起きていたかを再構築できる。精度を上げるためのサンプリングという位置づけです。
紹介される手法は段階的に高度化していきます。
- 一定確率サンプリング
- 直近のリクエスト量に応じたサンプリング
- イベントの内容（キー）に基づくサンプリング
- 過去データの手法とキーの手法の組み合わせ
- 動的サンプリング
- ヘッドベース／テイルベースの判定タイミング
後半では実際にコードへ落とし込む節が用意されており、固定割合から始めて、サンプル割合の記録、一貫したサンプリング、目標割合サンプリング、複数の静的割合、キーと目標割合の組み合わせ、任意数のキーに対応する動的割合、と少しずつ積み上げていきます。最終的に、キー・目標割合・ヘッド／テイルをすべて使った実装に到達します。
サンプリングを「コスト削減の妥協策」ではなく設計判断として扱えるようになる章でした。
テレメトリーパイプライン
18章も Slack からの寄稿で、Suman Karumuri と Ryan Katkov によるものです。
パイプラインの価値はデータ量の制御だけではありません。ワークロードの分離、セキュリティとコンプライアンス要件への対応、異なる保持期間の実現、複数バックエンドへのルーティングなど、多対多の関係を抽象化するところに本質があります。
Slack はこのパターンを3年間本番で運用し、毎秒数百万イベントまでスケールさせているとのことです。主にオープンソースコンポーネントで構成された具体例が示されるため、規模は違えど設計の参考になります。
第Ⅴ部：文化としてのオブザーバビリティ
変革はリアクティブに始めない
19章はビジネス事例の作り方です。
ここで挙げられている失敗パターンが印象に残りました。大きな障害が起きて根本原因分析を行い、「バックアップを取っていなかった」という原因を特定し、ファイルを削除した従業員を降格させ、コンサルタントを雇って新しいバックアップ戦略を導入し、ギャップは埋まったと判断して経営陣が安堵する、というシナリオです。
一見安心感がありますが、本書はこれを間違いだと断じます。なぜその1つのファイルが連鎖的な障害を引き起こせたのか。なぜそれほど重要なファイルが簡単に削除できたのか。イミュータブルなインフラであれば緩和できたのではないか。問うべきはそちらです。
急いで解決しようとするほど、単純なアプローチが魅力的に見える。この指摘は、障害対応の現場で何度も見た光景でした。
エンジニアリング以外の味方をつくる
20章は、オブザーバビリティの利害関係者についてです。
リッチなワイドイベントを計装すれば、そのデータセットは市場における自社サービスの動作に関する情報の宝庫になります。任意の質問に素早く答えられるという性質は、非エンジニアリング部門との知識ギャップを埋めるのにも使えます。
本書はここで、オブザーバビリティをレンズと表現します。ソフトウェアの動作について自分たちが考えていること・宣言していること（コード、ドキュメント、ナレッジベース、ブログ記事）と、実際のユーザーの手元で動いていることとの不一致を、素早く示すレンズです。
カスタマーサポート、プロダクトマネジメント、営業といった隣接チームを味方につけることが、組織全体への浸透につながる、という戦略論になっています。
成熟度モデルとの付き合い方
21章はオブザーバビリティ成熟度モデル（OMM）です。
まず成熟度モデル一般に対する留保が置かれるのが誠実です。1990年代のカーネギーメロン大学のケイパビリティ成熟度モデル以来、成熟度モデルはソフトウェアマーケティング業界の寵児になりましたが、限界もあります。エンジニアリングチームのパフォーマンスには本来上限がないのに、モデルには最高レベルが存在してしまう。そしてその最終状態は、モデル作成時点で知られていたことだけを反映した静的なスナップショットであり、作成者のバイアスを多分に含みます。
そのうえで、批判的に検討するための出発点としては有用だ、という位置づけで OMM が提示されます。参照されるケイパビリティは次の5つです。
- システム障害にレジリエンスで対応する
- 高品質なコードをデリバリーする
- 複雑さと技術的負債に立ち向かう
- 予測可能なケイデンスでリリースする
- ユーザーのふるまいを理解する
これらは相互に関連しており、単独で伸ばすものではないと説明されます。自己評価のチェックリストとして使えそうです。
22章：定義の再確認
最終章では、冒頭の定義が本文の内容を踏まえて強化されます。
高カーディナリティ・高ディメンションのテレメトリーデータを任意に切り刻んで必要なビューにでき、コア分析ループで比較しながらデバッグして原因を素早く切り分けられ、それらのデバッグニーズを事前に定義・予測する必要がない。そこまで揃って初めてオブザーバビリティがあると言える、という形です。
執筆に3年以上かかった理由として、書き始めた当時は「オブザーバビリティ」を毎回定義するところから会話を始める必要があり、カーディナリティやディメンションの話は誰にも通じなかった、という振り返りも語られます。いわゆる「3本柱」の考え方はデータ型の話にすぎず、新しい洞察を得るために必要な分析と実践を完全に無視している、という主張を繰り返す必要があった、と。
現在はその説明が不要になりつつある、という記述に、この数年の変化が表れています。
読んで得られたもの
1. 「未知の未知」という基準を持てた
自分の監視設定を見直すときの問いが変わりました。「この障害を検知できるか」ではなく、「まだ想像していない障害を、リリースなしで調査できるか」という問いになります。
2. 集計とコンテキストのトレードオフを意識するようになった
メトリクスは軽くて安いが、集計した瞬間にコンテキストが失われる。イベントは重いがコンテキストを保持する。どちらが優れているかではなく、何を捨てているのかを自覚して選ぶ、という感覚が身につきました。
3. アラート設計を文化の問題として見るようになった
逸脱の常態化という概念は、技術的な設計ミスがどのように組織の感度を鈍らせるかを説明します。無視されるアラートを放置することは、単なる運用の怠慢ではなく、判断能力の劣化を招く行為だと理解できました。
4. デバッグの民主化という目標を得た
「あの人しか直せない」を、教育や手順書ではなく、データと手法で解消する。属人性の問題に対する新しいアプローチとして参考になりました。
こんな人におすすめ
- 分散システムやマイクロサービスの運用に関わっていて、既存の監視に限界を感じている方
- SLO を導入したい、あるいは導入したものの機能していないと感じている方
- OpenTelemetry を導入したが自動計装で止まっている方
- 大量のテレメトリーデータのコストとどう向き合うか悩んでいる方
- チーム内のデバッグ属人化を解消したい方
- データストアの設計に興味がある方（16章と17章だけでも価値があります）
一方で、特定ツールの操作手順を求めている場合は期待と違うかもしれません。本書はベンダー非依存の原則と設計思想を扱う本であり、画面のスクリーンショットで手順を追う本ではありません。
読み方の提案
22章と分量があるため、目的別に優先順位をつけるのが現実的だと感じました。
| 目的 | 優先して読む章 |
|---|---|
| 概念をまず掴みたい | 1〜2章、22章 |
| 実装から入りたい | 5〜7章 |
| アラートを改善したい | 12〜13章 |
| 大規模データと向き合う | 16〜18章 |
| 導入を推進する立場 | 10章、19〜21章 |
個人的には、1〜2章で軸を掴み、8章でデバッグ手法の転換を理解し、そのうえで自分の課題に近い部で深掘りするのが効率的だと思います。
まとめ
『オブザーバビリティ・エンジニアリング』は、オブザーバビリティを「ツールの導入」ではなく「システムの性質」として捉え直させる本でした。
本書の主張を一言でまとめるなら、次のようになります。
未知の状態を、コードをリリースすることなく、事前の予測なしに理解し説明できること。それがオブザーバビリティであり、そのためには集計されていない高カーディナリティな構造化イベントと、それを反復的に探索する手法と、それを支える文化が必要である。
技術的には構造化イベント・トレース・OpenTelemetry・カラムナストア・動的サンプリングが、プロセス的には ODD と SLO が、組織的には成熟度モデルと利害関係者の巻き込みが、それぞれ一冊の中で接続されています。
著者たちがベンダーの立場であることを自ら明示し、Build or Buy の章でバイアスを認めたうえで議論を進める姿勢も好感が持てました。
監視の設定を追加し続けることに疲れを感じているなら、一度立ち止まって読む価値のある一冊です。