可観測性

概要

可観測性（Observability、略して o11y）は、システムが外部に出す情報 — 数値・記録・追跡データ — だけを手がかりに、内部で何が起きているかをどれだけ推測できるかという「性質」を指す言葉です。もともとは制御工学の用語で、「出力から内部状態を推定できるシステムは可観測である」という定義を、ソフトウェア運用の世界が借りてきました。

ポイントは、可観測性がツールの名前ではなくシステム側の設計品質だということです。どれだけ高機能なダッシュボードを買っても、アプリケーションが「いま何をしているか」を外に出していなければ中身は見えません。逆に、リクエストごとの文脈を丁寧に出力しているシステムなら、初めて遭遇する障害でも「どのユーザーの、どのリクエストが、どこで詰まったのか」をデータから掘り当てられます。この「事前に想定していなかった問いに、後からデータで答えられる」ことが、可観測性という言葉が担う中心的な価値です。

マイクロサービスやKubernetesのように部品が多く動きが速いシステムが主流になった現在、可観測性はSREの実践を支える土台として、運用を語るうえで欠かせない語彙になっています。

なぜ生まれたか

従来の監視は「既知の問い」に答える仕組みでした。CPU使用率が80%を超えたら知らせる、死活監視に応答しなければ知らせる — つまり「何が壊れうるか」を事前に予想し、その項目にチェックリストを仕掛けておくアプローチです。モノリスを数台のサーバで動かしていた時代は、壊れ方のパターンが限られていたため、これで十分に機能しました。

しかし、システムが数十〜数百のサービスに分割され、コンテナが数分単位で生まれては消える環境になると、障害は「予想したどの項目にも引っかからない形」で起きるようになります。全サービスのダッシュボードは緑なのに、特定の条件を満たすユーザーだけ決済が失敗する — こうした「未知の未知（unknown unknowns）」に対して、事前定義のチェックリストは無力でした。

そこで2010年代後半、「予想できる故障を監視する」発想から「予想できない故障でも後から調査できるだけの手がかりを、システム自身に語らせておく」発想への転換が起こります。これが可観測性です。問いを事前に固定するのではなく、豊かなデータを出しておいて問いは障害が起きてから立てる — 監視の否定ではなく、監視を包含するより広い設計思想として広まりました。

詳細

3本柱 — メトリクス・ログ・トレース

可観測性を構成するデータ（テレメトリと総称します）は、伝統的に3種類に整理されます。第一の柱メトリクスは、リクエスト数やエラー率といった数値の時系列です。集計済みで軽量なため「システム全体がいま健康か」を俯瞰するのに向きますが、集計の過程で個別の事情は失われます。第二の柱ログは、出来事を一件ずつ記録したものです。個別の事情が最も詳しく残る反面、量が膨大で、大量のログから目当ての一件を探すのは骨が折れます。第三の柱分散トレーシングは、1つのリクエストが複数のサービスをまたいで処理される道筋を、一本の線としてつなぎ直したものです。「どのサービス間の呼び出しで時間を食っているか」という、分散システム特有の問いに答えます。

3本柱は「どれか1つを選ぶ」ものではありません。実際の障害調査では、まずメトリクスのグラフで「何かがおかしい」ことに気づき、トレースで「どのサービスのどの処理か」を絞り込み、最後にログで「なぜそうなったか」を突き止める — という動線で3つを行き来します。この行き来をスムーズにするため、近年は3種類のデータにリクエストIDなどの共通の文脈を埋め込み、ワンクリックで相互に飛べるようにする設計が重視されています。

監視と可観測性の関係

両者は対立概念ではなく、問いの性質が違います。監視は「既知の問い」を常時チェックし続ける活動で、アラートによって異常を人に知らせる出口を持ちます。可観測性は「未知の問い」に事後から答えられる能力で、探索的な調査を支えます。実務では「監視で気づき、可観測性で理解する」と役割分担して捉えると整理しやすいでしょう。監視だけのシステムは「壊れたことは分かるが、なぜかは分からない」状態に、逆に高カーディナリティなデータを溜めるだけで監視の仕組みがないシステムは「調べれば分かるが、壊れたことに気づけない」状態に陥ります。両輪です。

計装と OpenTelemetry

システムにテレメトリを出力させる作業を「計装（instrumentation）」と呼びます。かつては監視ベンダーごとに独自のエージェントやSDKを組み込む必要があり、ベンダーを乗り換えると計装をやり直すロックインが問題でした。この状況を変えたのが、CNCF（Cloud Native Computing Foundation）の標準仕様 OpenTelemetry です。メトリクス・ログ・トレースの生成と送出をベンダー中立なAPI・SDK・プロトコル（OTLP）に統一し、「計装は一度だけ、送り先は自由に選ぶ」を実現しました。主要言語のフレームワークには自動計装（コードをほぼ書かずにHTTPリクエストやDB呼び出しを追跡する仕組み）も整い、現在では計装のデファクトスタンダードになっています。

実務の論点 — カーディナリティとコスト

可観測性の実務で最初にぶつかる壁がカーディナリティ、つまり「データに付けるラベルの値が何通りあるか」です。未知の問いに答えるには、ユーザーIDやリクエストIDのような高カーディナリティの属性が欲しくなりますが、メトリクスの時系列はラベルの組み合わせごとに増えるため、安易に付けると保存コストと検索速度が破綻します。このため「俯瞰は低カーディナリティのメトリクスで、深掘りは高カーディナリティを許容するログ・トレースで」という住み分けや、全リクエストではなく一部だけを記録するサンプリングが設計の要所になります。テレメトリの転送・保存コストはクラウド請求の中でも膨らみやすい項目であり、「何を、どの解像度で、どれだけの期間残すか」を決めることが、可観測性エンジニアリングの実質的な仕事の大半を占めます。

観測できることは、改善できることの前提です。SLOの計測も、インシデント対応の初動も、カオスエンジニアリングの仮説検証も、すべて「システムの状態がデータとして見えている」ことの上に成り立ちます。可観測性は派手さのない裏方の性質ですが、信頼性に関わる語彙の多くがここを土台にしています。