オライリー書籍で学ぶオブザーバビリティとモニタリングの違い

みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。

オブザーバビリティって言葉をよく聞くようになったけど、実際のところ従来の監視と何が違うのよ？という感想や疑問をお持ちの方はきっと多いのではないかと思います。

今回の記事は、オライリー社のオブザーバビリティ・エンジニアリングの本の内容を参考に、モニタリングとオブザーバビリティの違いについての深堀りしていきたいと思います。

※前回書いた書評の続きの記事です。前回の記事は下記をご参照ください。

blog.serverworks.co.jp

紹介した本の情報

出版社：オライリー・ジャパン

オブザーバビリティとモニタリング

個人的には最初にオブザーバビリティといわれた時に、ふわっとしすぎていてなかなかスッと頭の中に入り込んできませんでした。こういう時は原点に返ってみるのがよいと思いますので、オブザーバビリティ・エンジニアリングの本にどのように定義されているかを、まず原文で見てみましょう。

1 章オブザーバビリティとは? ：P31より引用

簡単に言うと、私たちが考えるソフトウェアシステムの「オブザーバビリティ」とは、システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です。

つまり、オブザーバビリティを一言で言えば「システムがどのような状態（どのような構成）になったとしても、そのシステムのことをどれだけ理解していて詳細に説明できるか」を表す尺度といいかえることができます。

従来型のシステム

一つの例になりますが、従来型のシステムとして20年くらい前のWebサーバーを想像してみましょう。サーバーの処理能力が限られていたため、大量の動的コンテンツを処理するのは困難なため、コンテンツといえば静的コンテンツが中心でテキストで書かれたHTMLファイルや容量の小さいGIFやJPGなどを使ってページを作成していました。一部でサーバーサイドで動作するCGI、PHP、ASPなどを使った動的コンテンツもありましたが開発スキルやリソースの兼ね合いで、一般的にはその多くが静的なものであったと認識しています。

そのようなシステムを監視する場合、Webサーバの転送量が多くなるとディスクI/Oなどに影響するためディスクI/Oを監視したり、コンテンツ保存のための容量がいつの間にかオーバーしないようディスク容量の監視をしたり、動的なコンテンツ配信の場合、限られた処理能力の中で動的コンテンツを動かさなければいけないためにCPUやメモリ使用率の状況を監視することがシステムの可用性を担保する上で重要だったと理解しています。これがいわゆる従来型のモニタリングの目的になります。

従来型のシステムでは、ひとつのサーバーの中にすべての関連するパーツが構成されているため、そのシステムのことを理解するのは比較的容易だったのではないかと考えています。

クラウドシフトしたシステム

その一方で最近のクラウドシフトした環境はどうでしょうか？それぞれのコンポーネント間の通信やコンテナやEC2などで動作しているアプリケーションの状態、バックエンドのDBの状態、はたまたクラウド基盤自体の状況など「システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるか」の尺度で考えて詳細に説明できるようなものでしょうか。

現代のシステムは、マイクロサービス化やクラウドネイティブ化が進み、ますます複雑になっています。このようなシステムでは、従来のモニタリングだけでは問題の発生源を特定したり原因を究明したりすることが困難です。オブザーバビリティはこのような複雑なシステムにおいても、問題を迅速に特定し解決するための強力なツールになると認識しています。

モニタリングとオブザーバビリティの違いを整理

ここまでの内容を踏まえて、モニタリングとオブザーバビリティの違いについて整理してみましょう

モニタリング
- システムレベルの問題を把握し、既知の障害を検知するのに有効
オブザーバビリティ
- アプリケーションレベルの問題を把握し、未知の障害を調査するのに有効

どちらの手法がより重要かはシステムの複雑さや組織のニーズによって異なりますが、オブザーバビリティを導入することで下記のようなメリットがあります。

属人的な知見から組織的な知見に
- モニタリングではシステムに関する知識は特定の熟練者に偏りがちですが、オブザーバビリティツールを使用することによって問題点が可視化されるため、可視化された問題をチーム全体で共有できる
隠れた問題の発見につながる
- モニタリングは既知の問題を検出するのに対し、オブザーバビリティは未知の問題を発見し、その原因を調査することができる
問題発見のためのきっかけ作り
- モニタリングは問題が発生した事実を通知してくれるだけですが、オブザーバビリティは様々な情報から問題の原因を特定し解決するための具体的な情報を提供してくれます

こうして整理してみるとオブザーバビリティが浸透してきたのにはちゃんと理由があって、利用者視点でのシステムの安定稼働といった観点や、障害が発生した際の問題解決までの時間の削減や障害切り分け工数の省力化などの観点から、近年オブザーバビリティが注目されているということなのかもしれません。

オブザーバビリティに必要なもの

ここまでオブザーバビリティとはどのようなものかといった点についてお話してきました。次にオブザーバビリティに必要なものについて見ていきましょう。ここでも原点に返ってみてオブザーバビリティ・エンジニアリングの本でどのように定義されているか、原文で見てみましょう。

1 章オブザーバビリティとは? ：P33より引用

オブザーバビリティを実現するためには、効果的なデバッグに必要なデータを収集するための考え方を進化させることが必要だと、私たちは考えています。

つまりオブザーバビリティでは、システムのあらゆる状態を把握し未知の障害にも対応できるように詳細なデータ収集と柔軟な分析を重視しており、こういった情報を元に問題になりそうな箇所を効率的に分析することでシステムの改善につなげるといったアプローチをとることを指しています。その際にオブザーバビリティでは、イベント、トレース、ログなど、システムのさまざまな側面から詳細なデータを収集する必要があります。

オブザーバビリティに必要な三本柱

オブザーバビリティに必要なデータとして「メトリクス」「ログ」「トレース」の3つがあります。これらはオブザーバビリティの三本柱と呼ばれており、システムの挙動を理解するための異なる情報を提供してくれます。

メトリクス
- メトリクスは、システムの状態を数値で表したものです。例えばCPU使用率、メモリ使用量、リクエスト数などがメトリクスとして挙げられ、これらの数値を時系列で追跡することで、システム全体の健全性やパフォーマンスの傾向を把握できます。
ログ
- ログは、システムで発生したイベントを時系列に記録したテキストデータです。例えばアプリケーションのエラーメッセージ、ユーザーの操作履歴、システムの起動・停止などログを分析することで、問題の原因特定やシステムの動作状況の把握に役立ちます。
トレース
- トレースは、リクエストがシステムを通過する際の経路を追跡したデータです。例えばWebサイトへのリクエストが、どのサーバーを経由し、どのデータベースにアクセスし、最終的にどのように処理されたかといった情報がトレースデータとして記録されます。トレースを分析することで、システム全体のボトルネックを特定したり、個々のリクエストの処理状況を把握したりできます。

オブザーバビリティを実現するためには、メトリクス、ログ、トレースの3つのデータを収集・分析することが重要ですが、こういったデータの収集方法や分析方法、そしてそれらを活用する文化的な側面も重要であるとオブザーバビリティ・エンジニアリングの書籍の中で述べられています。

効果的なデバッグに必要なこと

オブザーバビリティを用いたデバッグには、主に以下の3つの要素が必要です。

任意の幅で構造化されたイベント
- システムで起こった出来事を記録したデータであり、オブザーバビリティの基礎となるもの
- イベントは、発生時刻、イベントの種類、関連データなど、様々な情報を含みます
- 構造化されていることで、柔軟な検索や分析が可能になります
仮説の反復的な検証
- 収集した各種のデータから仮説を立て、それを検証するためにデータを探索し、仮説を検証または棄却するサイクルを繰り返します
- 問題の原因を特定するために、このサイクルを繰り返すことでより正確な原因究明を実現します
コア分析ループ
- オブザーバビリティデータを使って問題を特定し、診断するための体系的なプロセス
- 以下の4つのステップから構成されます
  1. 問題の特定: 顧客からの報告やアラートなどから問題を特定
  2. 仮説の生成: 問題の原因に関する仮説を立てる
  3. データの探索: 仮説を検証するために、オブザーバビリティデータを探索する
  4. 仮説の検証: データの探索結果に基づいて、仮説検証する

これらの要素を組み合わせることで、複雑な問題が発生した場合でも迅速に原因を特定し対応ができるオブザーバビリティの高いシステムを構築できるでしょう。

まとめ

オブザーバビリティ・エンジニアリングという書籍からオブザーバビリティとモニタリングの概念やそれぞれの違い、オブザーバビリティを実現する上で何が必要なのかといったところを深堀りしてみました。単に監視方法を替えるだけじゃなく、日々の運用の中での仮説検証や組織文化作りなどシステムの改善活動を進めていくことが重要なんだと理解できました。

こちらの記事がどなたかのお役に立てれば幸いでございます。