オブザーバビリティとは？監視との違い、必要性について解説

ここ数年、注目を集めているオブザーバビリティですが、従来からある「監視」と混同している人も多いようです。しかし、オブザーバビリティと従来の監視には決定的な違いがあります。

ここでは、オブザーバビリティの正しい意味と、監視との違いのほか、オブザーバビリティの効果や実現方法について解説します。

オブザーバビリティとは、予期せぬトラブルを防ぐ仕組み

オブザーバビリティ（Observability）は、オブザーブ（Observe）：「観測する」と、アビリティ（Ability）：「能力」を組み合わせた複合語で、日本語では「可観測性」あるいは「観測する能力」などと訳されます。システム上で何らかの異常が起こった際に、それを通知するだけでなく、どこで何が起こったのか、なぜ起こったのかを把握する能力を表す指標、あるいは仕組みを指します。

オブザーバビリティでは、アプリケーションの稼働に伴って生まれる膨大な情報の中から、内部状況を把握するためのデータを取得し、複雑なシステムの状態やアプリケーションの動きを可視化します。つまり、エラーという結果だけでなく、そこに至るまでの道筋を逆にたどって、どこにトラブルの原因があるのかを探り出すのです。そのため、予期せぬトラブルに対しても有効に機能します。

オブザーバビリティの必要性

オブザーバビリティの概念そのものは、1960年代から提唱されており、決して新しいものではありません。しかし、近年になって、オブザーバビリティは急速に人々の注目を集めるようになりました。その理由は、初めからクラウドでアプリケーションを実行したりソフトウェアを開発したりすることを前提とした、「クラウドネイティブ」の分散型システムが普及してきたことにあります。

分散型システムは機能の追加や変更がしやすく、スケーラビリティや可用性を確保しやすいというメリットがあります。しかし、分散型システムの場合、管理が必要なコンピューターが増えるため、運用管理が複雑になりがちです。さらに、複数のコンピューターが、多様なインフラの上で稼働しているため、トラブル発生時の原因特定が困難で、時間もかかります。

この問題に対処するために、オブザーバビリティの必要性が高まってきたのです。

こうして、クラウドネイティブの分散型システムの普及により注目を集めたオブザーバビリティですが、実際にはクラウドネイティブだけではなく、レガシーシステムの運用でも効果を発揮します。

オブザーバビリティと監視・モダン監視の違い

言葉としての認知が広がり、導入する企業も増えつつあるオブザーバビリティですが、いまだに監視と混同されることが少なくないようです。特に、多層的な「モダン監視」は、オブザーバビリティと同義に使われることが多々あります。

しかし、オブザーバビリティは、監視、モダン監視とは決定的な違いがあります。あらためて、監視やモダン監視の意味と、オブザーバビリティとの違いについて確認しておきましょう。

監視：システム全体や一部のコンポーネントの動き、出力を観察し続けること

一般的な意味での監視とは、システム全体や一部のコンポーネントの動き、出力を観察し続けることです。あらかじめ監視項目としきい値を設定しておき、しきい値を超えたところでアラートを出すという仕組みです。OSリソース監視、プロセス監視、ログ監視、死活監視なども、すべてその仕組みです。

監視によってわかるのは、例えば「CPUの使用率が90％を超えた」というような結果だけです。あくまで設定した状況を通知するだけで、その原因まではわかりません。そのため、想定外の未知の障害が起こった場合、「エラーが発生しているが、理由がわからない」という状態に陥ってしまいます。つまり監視は、「何が起きたかを見続けること」といえます。

システムの構成がごくシンプルだった時代であれば、監視でも十分に対応できました。しかし、システム構成が複雑化してくると、原因の特定までに、多くの時間と労力を消費するようになってきたのです。

一方のオブザーバビリティは、システムの内部状況を把握するためのデータを取得し、それぞれを関連付けて保持しています。そのため、エラーを検知するだけでなく、データに手を加えなくても分析・原因特定ができる、プロアクティブな対応が可能なのです。

つまり監視は「何が起きたかを見続けること」であり、オブザーバビリティは一歩進んで「なぜそれが起きたかを探り出すこと」であるといえます。

モダン監視：監視を多層的に組み合わせたもの

モダン監視とは、監視を多層的に組み合わせたものです。従来の監視体制だけでは、システム上に異常が発生したとしても、それがサービスレベルにどのような悪影響を与えているのか知ることができません。

例えば、CPUの使用率が高まって設定どおりにアラートが出たとしても、それがサービスに影響しないならば、特に問題はないはずです。そこで必要になるのが、ユーザー視点での監視です。サービスレベルは十分か、UI/UXに問題はないか、アプリケーションは正常に稼働しているか。このような「外からの視点」を組み合わせることで、よりモダンな監視が実現できます。そのため、異常通知に対し、より効率的に対処することが可能になります。

しかし、多層的なモダン監視であっても、あらかじめ想定された事象を検知し通知する仕組みであることには変わりはありません。トラブルが発生してから行動するリアクティブなものであり、原因を特定したり、未知の異常に即応したりすることはできないのです。一方のオブザーバビリティは、システムの全容把握ができるため、問題の予防だけではなく、問題発生時においても迅速な対応や改善に取り組むことができます。

だからといって、監視が不要というわけではありません。クラウドネイティブな環境では、オブザーバビリティの導入は必須ですが、それにはモダンな監視が欠かせないといえるでしょう。つまり、モダン監視はオブザーバビリティに含まれる要素のひとつであり、通過点というわけです。

オブザーバビリティのメリット

オブザーバビリティを導入するメリットは、いくつも挙げることができます。代表的なものをピックアップしてご紹介しましょう。

サービスの信頼性向上に活用できる

デジタルで提供されるサービスで重要なのは、その信頼性です。オブザーバビリティで常にシステムを監視・分析し続け、障害が起こった際に原因を迅速に特定・改善する体制があれば、顧客体験を悪化させることなく、サービスの信頼性を高めることができます。

特に注力すべきは、モバイルデバイスです。現在では、多くのユーザーがモバイルでサービスを利用していますから、モバイルでのユーザビリティ、サービスレベルの高さは、非常に重要です。モバイルサービスの信頼性が高まれば、企業に対するブランドイメージにも好影響を与えることになるでしょう。

チーム間コラボレーションの改善

開発側と運用側が完全に分離していた従来の監視体制では、これら2つのセクションには対立関係が生まれやすいものでした。開発側はサービスを洗練させる新たな機能をいち早く組み込みたいと考え、運用側は障害のリスクが高まる改変はできるだけ避けたいと考えます。

ですが、開発側も運用側も、理想とするのは「より洗練されたサービスを、安定的に提供し続けること」です。つまり、目指すところは同じなのです。

オブザーバビリティの導入によって、開発と運用の衝突を「融合」へと導くことができます。ソフトウェアのライフサイクルすべてにおけるフィードバックが得られることで、サービスレベルを高く保てるのです。また、障害に対してはチームで対応することで、チーム間のコラボレーションを可能にし、さらに改善が期待できます。

ビジネスと収益の成長

デジタルサービスに遅延やエラーが起これば、それだけでビジネスに悪影響を与えてしまいます。「画面表示が◯秒遅れると、売上が◯％落ちる」というような話は、多くの人々がご存じでしょう。

オブザーバビリティの導入によって、開発側と運用側が効果的なコラボレーションを行えば、ビジネスにも好影響を与えます。「新たな機能が搭載され、サービスそのものが洗練される」「状況の変化に柔軟に素早く対応できて、安定性も高い」といったことが実現できるのは、チームの成長だけでなく、ビジネスの成長も意味します。

また、どのような場面でどのような選択をしたのかという顧客行動の理解を深めていけば、収益維持率を向上させることにもつながります。

オペレーショナル・エクセレンス

オブザーバビリティは、分散し複雑化したシステム上での問題特定を容易にし、優先順位をつけた上で順次対処していくことができます。そのため、原因の推測や発見に、余計な時間と手間を取られることが少なくなります。つまり、開発者とエンジニアの生産性が高まるのです。

このことで、開発側だけでなく運用側も含めたすべてのエンジニアに対してドライブをかけられ、他社が容易に追いつけないオペレーショナル・エクセレンスを得られるでしょう。

オブザーバビリティに必要不可欠な3要素＋1

従来の監視体制では、ログとして出力されるエラーをチェックしたり、アプリケーションの性能を管理するAPMというツールで、より詳細なエラーを監視したりという作業が行われてきました。そのため監視という作業、さらにそこで使われるツールそのものが、縦割りのサイロ化を起こしてしまうというデメリットがありました。このやり方では、システムが複雑化した環境に対応できません。

そこで、オブザーバビリティの出番になるのですが、ここでは、システムの内部状況を把握できるデータとして、「メトリクス」「トレース」「ログ」が使われます。それぞれについて簡単に解説しつつ、これら「オブザーバビリティの3本柱」に追加すべき、もうひとつの重要な要素についても見ていきましょう。

メトリクス：数値化された情報

メトリクスは、定期的にグループ化または収集されたデータの集計です。メモリ使用率やCPU使用率、ネットワーク使用率などの情報から「何が起きているのか」が秒単位で検知できます。

メトリクスデータによって、アプリケーションの動きやハードウェアの稼働状態が可視化でき、システム全体がどのように動いているのかを把握することが可能です。

トレース：対処するための出発点

トレースは、根本的な原因にいち早くたどりつくために、問題が起こった処理のプロセスを可視化したデータです。トラブルシューティングを行ったり、障害が起こった箇所を特定したりという作業が、これにあたります。オブザーバビリティでは、システムの構成要素をすべて関連付けているため、トレースによって「どこで問題が起こったのか」を容易に突き止め、対処することができます。

ログ：分析することで、根本原因にたどりつく

ログは、OSやミドルウェア、アプリケーションなどから出力されるテキスト情報です。障害の要因からつながる結果として、何が起きたのかを表すもので、根本的な原因究明の入り口になるものでもあります。

ただし、ログはあくまでも「結果」にすぎません。どのようなプロセスを経てこの結果が導かれたのか、それを明らかにできなければ、真のオブザーバビリティとはいえません。

イベント：真のオブザーバビリティを実現する要素

メトリクス、トレース、ログの「オブザーバビリティの3本柱」に追加しておきたい要素が、イベントデータです。ここでいうイベントデータとは、New Relic特有の概念です。

システムがさまざまなところで出力する数値化あるいはテキスト化されたデータは、あくまでも結果にすぎません。結果以上の意味を持たない、最小限のデータといえます。それを補完してくれるのが、イベントデータです。

イベントデータを取得・保持することで、異常が起こった際に、それがどのようなイベントによって引き起こされたのかがわかり、一連のプロセス上のどこに障害要因があるのかを、容易に突き止められます。つまり、イベントデータを取得・保持することで、障害の根本原因の特定が、より迅速で的確に行えるようになるため、真のオブザーバビリティの実現につながるといえるでしょう。

オブザーバビリティの実現にはNew Relicがおすすめ

自社のシステムにオブザーバビリティの導入を検討中なら、New Relicにお任せください。New Relicは強力な外形監視機能を備えているため、フロントエンドでの動きをチェックでき、PCブラウザやモバイルによるUI/UXの状況、さらにエラーやクラッシュもモニタリングできます。

運用中のシステムの状態を数クリックでチェックできますし、サービスレベルが下がった場合には、エラーの内容や応答時間だけでなく、その原因までプロアクティブに追うことが可能です。アプリケーションやクラウド、インフラ、ブラウザ、ログなどのすべての情報を関連付けて、障害の原因を特定できます。

オブザーバビリティの実現を目指す際には、ぜひNew Relicの導入を検討してみてはいかがでしょうか。New Relic導入のご相談については、お問い合わせフォームよりご連絡ください。