o11y（オブザーバビリティ／可観測性）とは何か — 監視の強化版ではない理由

システム運用の文脈で、ここ数年「o11y」という表記を見る機会が増えた。読み方はオブザーバビリティ、日本語では可観測性と訳される。本シリーズは、この概念を実務の判断につながる形で整理していく。初回の本稿では、言葉の意味と出自、そして従来の監視との違いを扱う。

結論を先に置く。オブザーバビリティは、監視の延長線上にある「より多く見る技術」ではない。問いの立て方そのものを入れ替える考え方であり、ここを取り違えると、製品選びも投資判断もずれる。なぜそう言えるのかを、順を追って説明する。

o11yは何の略か

o11yは observability の略記である。先頭の o と末尾の y の間に11文字あることから、その11文字を数字に置き換えて o11y と書く。Kubernetes を k8s、internationalization を i18n と書くのと同じ作法だ。読み方は綴りどおりオブザーバビリティで、英語圏では短くオリーと発音されることもある。

略記が使われること自体に、ひとつの示唆がある。これを略記で書く層は、すでに概念を知っている実務者だ。一方で可観測性とはと綴って検索する層は、これから学ぶ段階にいる。同じ概念でありながら、知っている人と知らない人とで入口の言葉が分かれている。本稿では両方の言葉を行き来しながら進める。

言葉の出自：もとは制御理論の用語

オブザーバビリティはソフトウェアのために作られた言葉ではない。起源は制御理論にある。1960年、ルドルフ・カルマンが線形力学系の性質として導入した概念で、システムの内部状態を、外部から観測できる出力だけでどこまで言い当てられるか、という度合いを指していた。

この原義が、後の議論の土台になる。オブザーバビリティは、たくさん監視するという量の話ではない。外から見える出力だけで、中で何が起きているかをどれだけ推し量れるか、という推論可能性の話だ。ソフトウェアに輸入されたときも、この含意はそのまま残った。データを大量に集めることが目的ではなく、集めたデータから内部の状態を再構成できることが目的になる。

監視を強化したものがオブザーバビリティだ、という説明をよく見かける。出自に照らすと、これは正確ではない。量を増やす方向の話ではなく、推論できる状態を作る方向の話だからだ。同じデータ量でも、後から問い直せる形で持っているかどうかで、オブザーバビリティの高さは変わる。

監視とオブザーバビリティ：問いの立て方が違う

実務でよく使われる線引きに、監視はシステムが動いているかを伝え、オブザーバビリティはなぜ動いていないかを伝える、というものがある。正しいが、これは結論であって理由ではない。理由は、問いの立て方の違いにある。

監視は、何を見るかを事前に決める方式だ。CPU使用率が一定を超えたら知らせる、エラー率が閾値を割ったら鳴らす、というように、起こると想定した事象を先に定義しておく。想定の範囲内で起きる障害には強い。逆に言えば、想定して画面を作っていない事象は、起きても気づけない。

オブザーバビリティは、何を見るかを事後に決められる状態を指す。障害が起きてから、この利用者の、この経路の、この条件のときだけ遅いのはなぜか、と、事前に用意していなかった角度で問い直せる。その前提として、問い直しに耐えるだけの豊富なデータを保持しておく。

両者の違いを、扱える問題の種類で整理する。

監視は、起こると分かっている障害に備える。オブザーバビリティは、起こると分かっていなかった障害が起きたとき、その場で原因に辿り着けるようにする。守備範囲が違うのであって、優劣の話ではない。重大で頻度の高い障害は、いまも監視で先回りして押さえるのが筋だ。両者は置き換えではなく、役割を分担する関係にある。

この違いをさらに掘り下げると、全部チェックするという発想がなぜ通用しなくなったか、という論点に行き着く。これは本シリーズの第2回で扱う。

なぜいま必要になったのか

監視だけで足りていた時代は確かにあった。アプリケーションが単一の塊で、限られた台数のサーバ上で動いていたころは、起こりうる障害のパターンが有限で、運用する人間の頭の中に収まっていた。事前に列挙して、列挙したものを見張れば、それでほぼ完全だった。網羅という言葉が、現実に成立していた。

この前提を崩したのが、クラウドとマイクロサービスへの移行だ。サービスが多数の部品に分かれ、コンテナが生成と破棄を繰り返し、構成が自動で変わり続ける環境では、部品の組み合わせが膨大になる。さらに、経路の一部が事業者のクラウドの内側にあって、自分からは見えない領域も増える。誰も事前に想定していなかった壊れ方が、日常的に起きるようになる。

事前に作ったダッシュボードには、そもそも見るべき軸が用意されていない。想定の外で起きる障害に、想定して作った画面では届かない。ここで、障害が起きた後に未定義の角度で切り込める性質、すなわちオブザーバビリティが要請される。技術の流行ではなく、システムの作りが変わったことの帰結だ。

長く運用の現場にいた立場から見ると、これは道具の世代交代というより、前提の崩壊として体験される。動いているかを見れば足りていたモデルが、ある時期を境に答えを返さなくなる。その崩れる側にいた感覚は、本シリーズの随所で触れていく。

三つのシグナルと、通説への一言

オブザーバビリティの説明では、メトリクス・ログ・トレースの三本柱がよく登場する。それぞれの役割は次のとおりだ。

メトリクスで何が起きているかを秒単位で捉え、トレースでどこで起きているかを絞り、ログでなぜ起きたかを確かめる。単独で持つのではなく、三つを相関させて初めて原因に辿り着ける。データを集めることが目的ではなく、相関させて推論することが目的だ、という出自の話とここでつながる。

ただし、三本柱という整理を絶対視しない立場も知っておきたい。三つを別々の基盤として持つと、三つのサイロと三つの請求書が生まれ、障害時には複数の画面を人間が突き合わせる作業に逆戻りする。本来の単位は柱ではなく、任意の次元を好きなだけ持てる構造化されたイベントであって、メトリクスもトレースもそこからの派生にすぎない、という考え方もある。三本柱は出発点であって到達点ではない、と捉えておくと、製品ごとの違いを見るときに視界が開ける。製品の差は第4回で扱う。

このシリーズで扱うこと

本稿はシリーズの総論にあたる。ここから各論を、それぞれ独立した回として展開していく。

第2回は、監視とオブザーバビリティの違いを掘り下げ、全部チェックする発想が組み合わせ爆発で成り立たなくなる過程を扱う。第3回は、企業がこれに何を投資すべきかを、規模ではなく複雑性と事業損失の観点から整理する。第4回は、主要な製品をその出自の系譜から読み解き、評価の地図を描く。第5回は、アプリ性能中心の比較が落としがちな、自分の管理下にない経路をどう観測するかを扱う。第6回は、調査をAIエージェントが肩代わりし始めた最近の動きに触れる。

通底させるのは一つの見方だ。オブザーバビリティは、起こることを全部先回りして防ぐ技術ではない。起こると分かっていなかったことが起きたとき、その場で説明できる状態を用意しておく考え方だ。この一点を軸に、各回を読み進めてほしい。

よくある質問

o11yとは何の略ですか

observabilityの略記です。先頭のoと末尾のyの間にある11文字を数字に置き換えた表記で、Kubernetesをk8sと書くのと同じ作法です。読み方はオブザーバビリティ、日本語では可観測性と訳されます。

監視とオブザーバビリティはどう違いますか

監視は見るものを事前に決めて、想定した障害に備えます。オブザーバビリティは、障害が起きた後に保持データへ未定義の角度から問い直せる状態を指します。役割分担の関係であり、置き換えではありません。

なぜいまオブザーバビリティが必要なのですか

クラウドとマイクロサービスで構成が動的になり、起こりうる障害を事前に列挙できなくなったためです。想定外の壊れ方が日常になった環境では、事後に原因へ辿り着ける性質が要ります。