基礎知識

オブザーバビリティとは。監視との違いと、3つの柱

監視は事前に決めた異常を検知しますが、想定外の問題は追えません。この記事では、可観測性という考え方と、その実務を整理します。

監視との違い

オブザーバビリティ（可観測性）は、監視の延長線上にありますが、目的が異なります。

監視は、想定した異常を検知する仕組みです。「CPU使用率が90%を超えたら通知」のように、何を見るかを事前に決めます。

オブザーバビリティは、想定していなかった問題を調べられる状態を指します。事前に決めた指標だけでなく、後から任意の切り口で追跡できることが条件です。

なぜ必要になったのか。システムが複数のサービスに分かれ、クラウド上で動的に変わる構成になったためです。どこで何が起きているかを、事前にすべて想定できなくなりました。

監視を置き換えるものではなく、補うものだと理解するのが正確です。

3つの柱

この考え方は、3種類のデータで構成されます。

• 指標（メトリクス）／数値の時系列。CPU、応答時間、件数。軽量で長期保存に向く
• ログ／個々の出来事の記録。詳細だが量が多い
• 分散トレース／1つの要求が複数のサービスをどう通ったかの追跡

3つ目が、この分野の中核です。処理が複数のサービスにまたがる構成では、どこで時間がかかったかをログだけでは追えません。

要求ごとに識別子を付け、通過した経路を記録することで、全体の流れが見えるようになります。

近年は、これらを共通の仕様で扱う動きもあり、特定の製品に依存しない形が広がりつつあります。

何が変わるのか

導入によって、実務がどう変わるかを整理します。

原因の特定が速くなる。「遅い」という報告に対し、どのサービスのどの処理が遅いかを、推測ではなく記録から特定できます。

想定外の問題を追える。特定の顧客だけで起きる、特定の条件でのみ発生する。事前に監視項目として設定していなくても、後から調べられます。

影響範囲が分かる。ある障害が、どの機能のどれだけの利用者に影響したか。

改善の根拠になる。どこを直せば効果が大きいかを、数字で判断できます。

属人的な調査から、記録に基づく調査へ移ることが、最も大きな変化です。

費用という制約

この分野で最も現実的な課題です。

データ量が膨大になります。すべての要求のログとトレースを保存すると、費用が事業を圧迫します。

対策として、標本を取る方法があります。全件ではなく一定割合だけ記録する形です。ただし、稀な問題を取りこぼす可能性があります。

誤りが起きた要求は必ず記録するといった、条件を付けた抽出も行われます。

保存期間を分ける。直近は詳細に、古いものは要約して残す。

何を、どれだけ、どの期間残すか。この設計が、費用と調査能力の両方を決めます。

導入の進め方

段階的な手順を示します。

第一に、利用者視点の指標から。応答時間、成功率。まず「使えているか」を測ります。

第二に、ログの形式を揃える。後から検索・集計できる形にします。自由な文章では機械的に扱えません。

第三に、要求に識別子を付ける。サービスをまたいで追跡できる状態にします。

第四に、トレースを導入する。構成が複雑な部分から始めます。

第五に、費用を監視する。データ量が増え続けるため、上限の設定が必要です。

すべてを一度に整える必要はありません。調査に困っている箇所から着手するのが現実的です。

何のために整えるのか

最後に、目的を確認します。

道具を導入することが目的ではありません。製品を入れても、何を見るかが決まっていなければ活用されません。

目的は、問題が起きたときに答えを出せる状態です。原因はどこか、影響は誰に及んだか、いつから起きていたか。

この状態があると、復旧が速くなり、改善の判断も速くなります。

一方、規模の小さいシステムでは過剰な場合があります。サービスが1つなら、通常の監視とログで足ります。

構成が複雑になるほど価値が出る取り組みだと考えます。

指標と目標の結びつけ

可観測性は、目標値の設定と組み合わせて意味を持ちます。

何をもって正常とするかを定める。応答時間、成功率。この定義がなければ、集めたデータをどう判断すべきか決まりません。

目標値に対する余裕を管理する。どれだけ逸脱したかを測り、余裕がある間は変更を優先し、使い切ったら安定化を優先する。

通知の設計にも影響します。目標に影響する事象だけを通知すれば、無視される通知が減ります。

データを集めることと、判断の基準を持つことは別です。両方が揃って初めて、運用が変わります。

誰が使うのか

この仕組みは、運用担当だけのものではありません。

開発者が使う。自分が書いたコードが本番でどう動いているかを確認できます。作って終わりではなく、動きを見る文化につながります。

事業側も使える。どの機能がどれだけ使われているか、どこで離脱しているか。

権限の設計が必要になります。ログには機微な情報が含まれる場合があり、誰が何を見られるかを定めます。

導入して定着しない理由の多くは、使う人が限られることです。運用担当だけが見る状態では、投資に見合いません。

開発者が日常的に見る状態を作れるかが、定着の分かれ目になります。