この記事の要点
- 監視は、あらかじめ決めた項目を見張り、異常を知らせる仕組みです。オブザーバビリティは、予想していなかった問題についても「なぜ起きているのか」を調べられる状態を指します。
- 手がかりになるデータは、ログ・メトリクス・トレースの3つです。ばらばらに残すより、つなげて見られるほうが原因に近づきやすくなります。
- まずは監視の基本を整え、システムが複数のサービスに分かれてきたら、処理の流れを追うトレースを足していくのが現実的です。
オブザーバビリティ（可観測性）とは、システムが外に出すデータを使って、システムの中で何が起きているのかを、外から問いかけて理解できる性質のことです。監視が「決めておいた異常に気づく」ための仕組みだとすると、オブザーバビリティは「予想していなかった問題の原因を調べられる」ための備えといえます。監視をやめて置き換えるものではなく、監視の上に重ねて考えるものです。
オブザーバビリティとは
オブザーバビリティの考え方は、オープンソースの OpenTelemetry のプロジェクトの解説が分かりやすくまとめています。それによると、オブザーバビリティは、システムについて問いを立てることで、システムを外から理解できるようにするものです。そして、予想していなかった問題（未知の未知）に対処し、「なぜこれが起きているのか」に答える助けになる、と説明されています。
出典：Observability primer（OpenTelemetry）
用語としてのオブザーバビリティは、用語集でも説明しています。
監視と何が違うのか
監視は、CPU の使用率やサイトの応答のように、見るべき項目と、異常とみなす基準をあらかじめ決めておき、外れたら知らせる仕組みです。起こり得る問題を事前に想定できる場合に強い方法です。
一方、クラウドのシステムは、複数のサービスや外部の API がつながって動くことが増えています。そうした構成では、「どの画面も止まっていないのに、一部のお客様だけ処理が遅い」のように、事前に想定していなかった形の問題が起きます。決めた項目だけを見張っていると、異常には気づけても、原因をたどる手がかりが足りないことがあります。
| 観点 | 監視 | オブザーバビリティ |
|---|---|---|
| 主な目的 | 決めておいた異常に気づき、知らせる | 予想していなかった問題の原因を調べる |
| 答える問い | 「いま、異常は起きているか」 | 「なぜ、これが起きているのか」 |
| 準備するもの | 見る項目と、知らせる基準 | 後から問いを立てられるだけのデータと、それをつなげて見る道具 |
表は考え方の違いを整理したもので、実際の運用では両方を組み合わせます。異常に気づくのは監視、気づいた後に原因を探すのがオブザーバビリティ、という役割の分け方です。
手がかりになる3つのデータ
オブザーバビリティの手がかりになるのは、システムが出すデータ（テレメトリ）です。OpenTelemetry の解説は、テレメトリを、システムとその振る舞いから出されるデータとし、主な形としてトレース・メトリクス・ログの3つを挙げています。
- ログ：サービスなどが出す、時刻の付いたメッセージ
- メトリクス：基盤やアプリの数値のデータを、一定の期間で集計したもの（エラーの割合、CPU の使用率、リクエストの数など）
- トレース：1つのリクエストが、複数のサービスをどう通っていったかを追う記録。処理の1つ1つの単位を「スパン」と呼ぶ
同じ解説は、ログは単独では、どこから呼ばれた処理なのかといった文脈が足りないことが多く、スパンやトレースと結び付けると役に立ちやすくなる、としています。
出典：Observability primer（OpenTelemetry）
ログの残し方や保存の期間は、ログの取り方と見方。何を、どのくらい残すかで説明しています。
まず何を見るか
何から見ればよいか迷う場合は、Google の SRE の書籍が示す「4つの黄金の指標」が出発点になります。
- レイテンシ：リクエストを処理するのにかかる時間
- トラフィック：システムにかかっている需要の量
- エラー：失敗したリクエストの割合
- 飽和度：サービスがどのくらい「いっぱい」か
同じ書籍は、利用者から見える振る舞いを外から確かめる監視（ブラックボックス監視）と、システムの内部が出す数値にもとづく監視（ホワイトボックス監視）を分けています。外から見る監視は、いま起きている問題に気づくのに向き、内部の数値は、これから起きそうな問題や、再試行で隠れている失敗に気づくのに向くとされています。
出典：Monitoring Distributed Systems（Google SRE）
監視の項目の決め方は、クラウドの監視は何を見るのか。死活・リソース・アプリでくわしく説明しています。
データの集め方をそろえる（OpenTelemetry）
OpenTelemetry は、テレメトリを集めて送るための、オープンソースの仕組みと道具です。特定の製品やサービスに依存しない作りで、さまざまな保存・分析のサービスと組み合わせて使えると説明されています。一方で、OpenTelemetry 自体はデータを保存して見せるサービスではなく、保存や画面での表示は別の道具が担います。
出典：What is OpenTelemetry?（OpenTelemetry）
データの集め方を特定のクラウドの機能だけに寄せず、共通の形で集めておくと、分析の道具を替えるときや、複数のクラウドを使うときに、作り直す範囲を小さくできます。
中小企業はどこから始めるか
多くの会社では、オブザーバビリティの前に、監視の基本が整っていないことがあります。順番としては、次のように進めるのが現実的です。
- サイトや業務のシステムが止まっていないかを、外から確かめる監視を置く
- サーバーやデータベースの数値（CPU・メモリ・ディスク・接続の数など）と、アプリのエラーの数を集める
- ログを1か所に集め、時刻をそろえて、障害のときに検索できるようにする
- システムが複数のサービスに分かれてきたら、トレースを足し、ログ・メトリクスと結び付けて見られるようにする
データを集めるほど、保存の費用は増えます。何のために集めるのかを決め、残す期間と細かさを、費用とつり合う範囲にします。
当社のご支援
アメリア・テクノロジーのクラウドの構築と運用管理では、監視の項目と知らせる基準の設計、ログの集め方、トレースを足すかどうかの判断と設定をご支援しています。監視の仕組みは24時間自動で回し、原因の調査と再発の防止は当社の担当者が営業時間内に行います。いまの監視の状況は、無料のクラウドの自己診断でもおおまかに確かめられます。
- クラウド
- 監視
- オブザーバビリティ
- ログ
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。