オブザーバビリティとは？ クラウドネイティブなシステムで求められる理由

オブザーバビリティとは

オブザーバビリティ（Observability）とは、「Observe（観察）」と「Ability（能力）」を組み合わせた造語で日本語では「可観測性」などと呼ばれています。オブザーバビリティという言葉自体は歴史が長く、1960年代にルドルフ・カルマンによって、線形力学系の分野で使われはじめたと言われています。この概念が近年になって、ITの分野でも使われるようになってきました。

ITシステムにおいてオブザーバビリティとは、システム全体の状態を観測すること、または実際に観測できる能力や手法全体を指して使われています。つまり、オブザーバビリティとは、特定の技術やツールを指す言葉ではなく、システム観測にまつわる包括的な概念だと考えてよいでしょう。

オブザーバビリティが生まれた背景

オブザーバビリティという概念が生まれた背景を理解するには、まず現代的なインフラの構造とそれが抱える問題を知る必要があります。

従来では、オンプレミスのサーバーにOSやミドルウェアをインストールし、その上にアプリケーションをデプロイするのが当たり前でした。こうしたサーバーを中心としたモノリシックな構成では、サーバーのCPUやメモリ、ネットワークなどの負荷を監視し、あらかじめ設定した閾値を越えたり、死活監視に応答しなくなった場合にアラートを上げていれば、システムの状態や健全性を十分把握できていました。しかし、現代的なITシステムでは、「マイクロサービスアーキテクチャ」が採用されることが増えてきました。マイクロサービスでは、機能ごとに分割されたサービス群をネットワークとAPIを通じて疎結合させ、全体としてのサービスを構成します。そして、マイクロサービスを構成する各サービスは、第三者である事業者が管理するクラウドやKubernetesをはじめとする分散システム上にデプロイされるのが一般的となってきています。マイクロサービスの詳細につきましては、「マイクロサービスとは」をご覧ください。

マイクロサービスには、アプリケーションが何らかの機能不全を起こした際、その原因がどこにあるのかを特定するのが難しいという問題があります。これは全体を構成する要素の数が多く、種類も多岐にわたること、またそれらが複数のインフラ上に分散して配置されることに起因しています。これに加えて、クラウド上のリソースは動的に拡張・再配置されることもあり、問題をさらに複雑にしています。

そのため、クラウドネイティブなシステムやマイクロサービスアーキテクチャで構成されたシステムでは、従来型の監視では十分な情報を得ることができないのです。この問題を解決するため、重要視されているのがオブザーバビリティです。

オブザーバビリティを構成する要素

オブザーバビリティとは、端的に言ってしまえば、システム全体の状態を観測するための考え方です。その目的は、対象がどんなに複雑な分散システムであっても、たとえどのような障害が起きたとしてもその状態を理解し、対処可能にすることです。

オブザーバビリティは大きく、「データ収集」→「データ分析」→「データ可視化」という3つのステップで構成されています。そして、収集されたデータのうち、特に「メトリクス」「ログ」「トレース」は、「オブザーバビリティの3つの柱」と言われています。

メトリクスとは、定期的に取得したシステムの情報をグループごとにまとめて整理したデータのことです。メトリクス自体は単なる数値のため、一般的にはこれを時系列に並べ、グラフなどにプロットして可視化します。例えば、CPU使用率やメモリ使用量、ネットワークトラフィックといった値はメトリクスです。メトリクスは、システムのパフォーマンスを測るには非常に都合のよい指標の1つで特にこれらを時系列のグラフで表したものは、従来のモニタリングでも広く利用されてきました。

ログとは、OSやアプリケーションが出力するイベントの履歴です。一般的にログは、イベントの内容や付随データをタイムスタンプと共にプレーンなテキストの形式で出力します。ログは、「どのアプリケーションにいつ何が起きたのか」といった情報を得るためには欠かせないデータの1つです。

トレース（分散トレースとも言います）とは、マイクロサービスを構成する複数のサービスの横断的な監視を可能にする機能です。マイクロサービスで構成されたアプリケーションに対してリクエストが行われると、内部では独立した複数のサービスが連鎖的に動作します。そのため、もしもアプリケーションがエラーを起こした場合、異なる場所で同時並列的に実行されていたマイクロサービスのどこに問題があったかを追跡調査しなければなりません。しかし、従来のログを用いた方法では、サービスAのログを確認し、続いてリクエストが転送されるサービスBのログから該当のリクエストを探し出し、そこからさらにサービスCのログを・・・といったように、非常に手間のかかる調査が必要になってしまいます。そこで、関連した一連のイベントを追跡・管理するための仕組みが考え出されました。これがトレースです。トレースにより、マイクロサービス間を横断していくリクエストの追跡や問題箇所の特定、デバッグが容易になります。

オブザーバビリティとモニタリング（監視）の違い

オブザーバビリティは言葉の指す範囲が広く、また抽象的な概念を含むため、具体的に「これがオブザーバビリティである」とイメージしづらい部分があります。そのため、従来のモニタリング（監視）と同一視されたり、あるいは単にモニタリングの上位概念であるかのように扱われることも珍しくありません。ですが、オブザーバビリティはモニタリングとは別の概念であるため、注意が必要です。

モニタリングとは文字通り、システムの状態を時間の経過に沿って、観察・記録し続けることを指す呼び名です。通常モニタリングは、メトリクスを用いてシステムを監視します。具体的な例を挙げると、前述したCPU使用率のような値を継続的に監視し、記録します。そして「CPU使用率がXX%を越えたらアラート」といった条件を事前に指定し、この条件を満たすか満たさないかで二値的に正常/異常を判断するのです。

ですが、この方法にはいくつかの問題があります。まず、異常とされる条件（この例では異常として扱うCPU使用率の具体的な数値）を事前に把握し、設定する必要があることです。そのため、仕組み上、未知のトラブルが発生した時にそれをキャッチするのが難しいのです。また、異常とする閾値の導出には過去の経験が必要となってきます。例えば、サーバーのCPUが80%使用されていたとしましょう。ですが、80%という数値を見ただけでは、このシステムにおいて、これが正常なのか異常なのかを判断することはできません。そのため、運用を始めて間も無いシステムでは、最適な閾値を導出できず、結果として誤報アラートを何度も鳴らしてしまうこともあります。

もちろん「こうなったら確実に異常である」ということが明確な部分に関して言えば、依然としてモニタリングは有効な手段です。ですが、現代的な分散システムにおいて、さまざまな未知の問題に対処するためには、メトリクスと閾値を用いた過去の経験に基くアプローチではカバーし切れないのです。これが、オブザーバビリティが注目されている理由です。ただし、オブザーバビリティとモニタリングは、まったく無関係なわけではありません。オブザーバビリティを実現するための1つの要素として、やはりモニタリングは欠かせません。

オブザーバビリティを実現するためには

冒頭で述べたように、オブザーバビリティとは可観測性、つまりシステム全体の状態を観測可能にすることです。ですが、システムにオブザーバビリティを持たせるという目的は、単にオブザーバビリティツール（を謳っている製品など）を導入するだけでは実現できません。

そういう意味において、オブザーバビリティの実現とは、DevOpsに似ている部分があると言えるでしょう。DevOpsは、具体的なツールや手法だけを指す言葉ではなく、企業の文化や考え方といった組織的な面も含む、幅広い概念でした。オブザーバビリティの実現も同様に支援ツールの導入だけでは十分ではなく、考え方や企業文化そのものから変えていく必要があります。

ツールを導入すればいいというものではありませんが、とはいえツールを導入しないことには始まらないのも事実です。しかし、現時点で要求を完全に満たせるオブザーバビリティツールと呼べるようなものは（ほぼ）存在しないのが現実です。そのため、メトリクス監視ツールとしては「Prometheus」、ログ監視ツールとしては「ELK」、トレースツールとしては「Jaeger」など、個別のツールの導入から始めてみるのがよいでしょう。

大切なのはシステムにオブザーバビリティを持たせることを、常に意識し続けることです。これを踏まえた上で、最初はオブザーバビリティの三本柱である、「メトリクス」「ログ」「トレース」の収集から始めてみるのがお勧めです。