1.オブザーバビリティとは

オブザーバビリティとは、「観測する」（Observe）と「能力」（Ability）を組み合わせた用語であり、「可観測性」や「システムの内部状態を観測できる能力」と訳される。「システムを観測できる」とは、システムから出力される様々なデータをもとにシステムの内部で何が起きているのか、それがなぜ発生したのかを把握し、説明できることを指す。

システムが出力するデータは大きく「メトリクス」「ログ」「トレース」の3種類に分けることができる。まずメトリクスとはシステムから定期的な間隔で収集される数値データで、システムの性能や状態を表したものである。例えばCPU使用率やメモリ使用率、ディスクの使用率、リクエストの処理時間などが該当する。次にログとはOSやアプリケーション、ネットワーク機器などでイベントや処理が発生した場合に出力されるテキスト形式のデータで、イベント情報、処理の結果、タイムスタンプなどの情報が出力される。これはよくシステムで障害が発生した際に、障害発生の原因を特定するために取得、分析される情報である。最後にトレースとはリクエストやトランザクションなどの処理がシステム内またはシステムを跨いでどのように処理されているかを追跡するためのデータである。このデータはシステムの処理フローやパフォーマンスのボトルネックを特定するために役立つデータである。

オブザーバビリティではシステムが出力する「メトリクス」「ログ」「トレース」などのあらゆるデータを収集し、分析することで、システム運用者がシステム全体の状態を理解し、システム障害の検知や迅速な対処および効果的なシステムの運用を可能にする。昨今ではこのような機能を備えたオブザーバビリティツールが多くの企業やコミュニティから提供されている。

2.オブザーバビリティが注目される理由

オブザーバビリティが注目される理由の一つに、「分散システム」と呼ばれるアーキテクチャを用いてシステムを構築する事例が増えている状況があげられる。

分散システムとは複数の独立した小規模なサービスで一つのアプリケーションを構築するソフトウェア開発手法である。各サービスは特定のビジネスロジックを担当し、それらがネットワーク上で連携することで高い柔軟性や信頼性、拡張性を実現することができる。分散システムの一形態にはマイクロサービスアーキテクチャ（注1）やサーバーレスコンピューティング（注2）などが挙げられ、早いサイクルで機能の追加や変更を行え、突発で発生する大規模なアクセスにも柔軟に対応でき、特定のサービスで障害が発生した場合でもシステム全体が影響を受けにくくなるなどの特徴がある。

顧客のニーズの多様化や社会的要求が目まぐるしく変化する昨今のビジネス環境ではそのような変化にも迅速に対応できるシステムが求められる。従来の単一の中央集権型のシステム構成（モノリシックアーキテクチャ）では柔軟性や拡張性に限界があるため頻繁なシステム変更を行うことは不向きとされる一方、分散システムの持つ特徴はこのような変化にも柔軟に対応できることとされている。

このように昨今のビジネスニーズに即した特徴を持つ分散システムだが、その一方で課題も存在する。分散システムはシステム全体が多数のサービスで構成されているため、モノリシックアーキテクチャでサービスを提供している場合と比較してシステムを運用監視するための複雑性が増す。またシステムが複雑になることによって従来では起こり得なかった、また予測できなかった障害が発生する可能性も高まる。もし障害が発生した場合、システムは分散しているためエラーログの確認作業の煩雑さが増したり、デバッグやエラーのトラブルシューティングも複雑になったりする。このように分散システムには様々な課題が発生するが、オブザーバビリティはこのようなシステムの運用監視や障害対応における課題を補うことができるとして注目されている。

3.オブザーバビリティの特徴

次にオブザーバビリティが分散システムの運用監視や障害対応における課題をどのように補うことができるのか、その特徴について具体的に確認する。

1つ目はシステムが出力するデータの一元管理である。システムで障害が発生した場合、従来の障害対応では個々のシステムにログインしてエラーログを取得し、そこから障害の原因を分析することが多い。しかしながら分散システムは多数のシステムが存在するため、多くのシステムにログインしてエラーログを取得することは非効率な作業となる。企業によっては申請書を提出して上長の承認を得てからでないとその作業が実施できないこともあるため、さらに時間を要することもある。一方、オブザーバビリティでは各システムが出力するデータをオブザーバビリティツールに対してリアルタイムまたは定期的な間隔でデータを送信しているため、あらゆるデータが一元管理されている。このため、オブザーバビリティツールを確認するだけであらゆるシステムのデータ確認作業を迅速に行うことができ、迅速な障害原因の分析および復旧対応に繋げることができる。このデータの一元管理は分散システム導入における前提条件と言えるほど重要なポイントになる。

2つ目は分散トレーシングである。分散トレーシングとは分散した複数のシステム間の通信がどのように伝播しているかを追跡して可視化するための技術である。例えば分散システムで提供されているウェブサイトにおいて、ユーザーが送信ボタンを押下してその処理結果が画面に表示されるまでの間に5つのシステムで処理が行われたとする。ユーザーからのリクエストが最初のシステムに到達すると一意のトレースIDが割り当てられる。このトレースIDは後続のすべてのシステムに対して伝播していき、各システムで行われる処理や出力されるログデータなどに対して関連付けすることができる。また分散トレーシングでは各システムにおける処理の開始・終了時刻や、処理の親子関係も把握することができる。最終的にこれらの情報はオブザーバビリティツールに収集され、分散システムの相関関係図やパフォーマンスを表すグラフとしてグラフィカルに表示される。そのため複雑な分散システムの関係性を理解するうえで役立てることができたり、システム障害が発生した具体的なロジックを特定したり、処理のボトルネックを特定してパフォーマンスの改善に繋げることもできる。

なお、分散トレーシングはAPM（Application Performance Management）と呼ばれるオブザーバビリティのサブセットとして位置づけられており、この機能に特化したツールも提供されている。

3つ目はダッシュボードである。ダッシュボードはオブザーバビリティツールに収集されたデータをグラフィカルに表示、分析、管理するための画面を指す。これはオブザーバビリティの概念ではなくオブザーバビリティツールが一般的に備えている機能になるが、ダッシュボードによってシステム運用担当者はシステムの状態やパフォーマンスなどの状況をリアルタイムで把握できるようになり、日常的なシステムの監視や障害発生時の対応を効率的に行うことができる。通常、ダッシュボードは表示項目を自由にカスタマイズすることができる。CPU使用率、メモリ使用率、 エラー発生率などの情報をチャート形式で表示しておけばシステムの状況を容易に把握できるし、アプリケーションの相関関係図やパフォーマンスの状況をグラフで表示しておけばシステムのボトルネックの発見やパフォーマンス改善に繋げることができる。またダッシュボードには高度な分析機能が搭載されていることが多く、システムから収集したデータをフィルタリング、グループ化、集計することでシステムの状態に関する様々な洞察を得ることができるため、障害対応にも役立つ。ダッシュボードは他チームやビジネスユーザー等に対して共有することもできるため、素早い情報伝達や円滑なコミュニケーションに役立てることもできる。

これらの特徴から、オブザーバビリティは複雑かつ高度な分散システムであってもシステムの状態を可視化でき、それによって運用監視の障害対応における早期発見・および迅速な復旧対応、ボトルネックの発見およびユーザーエクスペリエンスの向上に寄与することができる。

4.オブザーバビリティの導入プロセス

オブザーバビリティを導入するためには、いくつかのプロセスを経る必要がある。

まず導入対象とするオブザーバビリティツールを選定する。オブザーバビリティツールにはベンダーが有償で提供しているツールや、オープンソースソフトウェア（注3）で提供されているツールなどがある。コストや導入難易度、ツールに搭載されている機能、ツール提供元のサポート体制などを比較して導入対象ツールを選定する。

次に監視対象とするシステムを選定する。対象とするシステムに制限や決まりはないが、最初に導入対象とするシステムは分散システムや、頻繁に障害が発生して改善が必要なシステム、障害対応時間を短縮したいシステム、パフォーマンスに何かしら問題を抱えているシステムに導入することが推奨される。また、いきなり本番環境に導入するのではなく、検証環境へ導入して十分な検証を踏まえてから本番環境に導入することが推奨される。

導入対象のツールと監視対象システムの選定が完了したら、最初に必要となるのが監視対象システムから出力されるデータの収集である。一般的にオブザーバビリティツールは独自のデータ転送ツールや手順を用意しており、それを利用することで収集対象データをオブザーバビリティツールに転送できる。監視対象とするサーバーに対してエージェントと呼ばれるデータ転送用のツールをインストールしてデータ転送する方法や、アプリケーション内に手作業でデータ転送の仕組みを実装する方法などがある。データ転送の間隔はリアルタイムや定期的な間隔など、設定ファイルによって決定できる。もし複数ツールに対してデータを転送したい場合は、OpenTelemetry（オープンテレメトリー）というオープンソースソフトウェアのオブザーバビリティフレームワークを使用することで、ベンダーから提供されるエージェントなどのツールに依存しないデータ転送の仕組みを構築できる。この場合、導入難易度は高くなるものの、複数ツールへのデータ転送や後からオブザーバビリティツールを変更することができるなどベンダーロックインしないオブザーバビリティ環境を実現できる。

データ収集が完了したら、ダッシュボードを作成してシステム全体または一部がどのような状態にあるかを可視化できるようにする。上述の通り、ダッシュボードは全ての情報や項目を一つのダッシュボードに載せるのではなく、目的別やチーム別に作成することがポイントになる。例えば分散システムのインフラストラクチャの監視を目的としたものや、分散システムの依存関係を把握するためのもの、顧客体験やサービスの健全性を把握するためのものである。システムの運用や改善のために必要になるものをチーム内で検討し、必要なダッシュボードを作成する。

ここまでの作業が問題なく完了したら、検証環境においてこれまでに設定・構築してきた内容で十分なシステム監視ができるか、アラートを通知する指標は何にするか、障害が発生した場合に迅速に問題が特定することができるかどうかを評価・検証する。このプロセスにおいてオブザーバビリティツールを利用したシステム監視、分析、障害対応のプロセスを確立させ、本番環境における導入の事前準備を行う。ここで得られた知見は必ず明文化しておくことが重要になる。またオブザーバビリティツールを使いこなすためのユーザートレーニングも実施する。ここまで実施すれば本番導入の準備は整っているため、適切なタイミングで本番導入することを検討する。

5.オブザーバビリティの運用

オブザーバビリティは一度構築したシステム監視体制を維持し続けるだけではなく、フィードバックと改善を繰り返すことが重要になる。例えば顧客体験やサービスの健全性を把握するためのダッシュボードは、サービスの機能追加などによって発生する変更を常に追跡して最新の顧客体験やサービスの状態を説明できる状態を維持しなければならない。重要なことはダッシュボードを確認するだけで、当該システムに精通した人材でなくともシステムの状態やサービスの提供状況がどのような状態になっているかを説明できるという点である。もし、それが説明できない場合はダッシュボードに表示されている情報や分析可能なデータが不足しているため、改善が必要ということを意味する。

ダッシュボードがフィードバックと改善により最新の状態に維持されているかどうかを確認するためには、運用上の工夫が必要になる。例えば週次で行われる運用定例ミーティングにおいて、ダッシュボードレビューを行うことが一つの例としてあげられる。ミーティング出席者に対して当該システムの状態を説明させることによって、必要な情報が足りているか、ダッシュボードは誰でもシステムを明確に説明できる状態になっているかなどを確認する。もし説明できない項目があれば、それが改善点となるため、それを説明するために必要な情報をダッシュボードに反映させるという改善活動を繰り返す。場合によってはより深い分析を実現するためにアプリケーションを改修して新しいデータを出力し、オブザーバビリティツールに連携することが必要になるかもしれないが、そうした日々の改善活動が将来発生する未知の障害を事前に検知したり、障害発生後の迅速な原因特定および復旧を実現したりするための布石となる。

6.終わりに

企業が運用するシステムの分散化が進むにつれて、オブザーバビリティの重要性は今後ますます増していく。企業がオブザーバビリティを導入してシステムが出力するデータの一元管理やシステムを跨いだ多角的なデータ分析ができなければ、アプリケーションのパフォーマンスや顧客体験の低下、大規模なシステム障害といった様々な問題に直面する可能性がある。分散システムを安定稼働させつつ、複雑化・多様化するビジネスニーズに迅速に応えるためには、オブザーバビリティの実現が欠かせない取り組みになるだろう。