オブザーバビリティ(可観測性)とは？

監視とオブザーバビリティは概念が異なりますが、相互に依存しています。監視はシステムのオブザーバビリティを向上させるために行う活動のことです。オブザーバビリティは機能性やテスト容易性などと同じく、システムの属性です。

厳密には、監視はシステムのパフォーマンスを継続的に観測する活動を指します。監視ツールを使ってシステムデータを収集および分析し、実用的なインサイトを引き出します。基本的に、アプリケーションパフォーマンス監視などの監視テクノロジーでは、システムの稼働と停止やアプリケーションのパフォーマンスの問題などが報告されます。集約データや相関関係を監視することもシステムの全体的な状態を推測するのに役立ちます。たとえば、Webサイトやアプリケーションでは読み込み時間を監視することでユーザーエクスペリエンスを把握できます。

一方、オブザーバビリティは、システムの外部出力に基づいて内部の状態をどの程度正確に推定できるかを示す尺度です。つまり、監視を通じて得たデータとインサイトを使用して、健全性やパフォーマンスなど、システムの状態を包括的に把握します。そのため、システムのオブザーバビリティは、監視メトリクスからシステムのパフォーマンス指標をどのくらい正確に読み取れるかにある程度左右されます。

もう1つの重要な違いは、監視では、何を監視すべきかを事前に判断する必要があるのに対して、オブザーバビリティでは、システムのパフォーマンスを継続的に監視し、その結果について質問を投げかけることによって、何が重要かを判断できる点です。

オブザーバビリティが重要なのは、複雑なシステムをより適切に管理できるためです。シンプルなシステムは可動要素が少なく、管理が容易です。通常は、CPU、メモリー、データベース、ネットワークの状態を監視するだけでシステムの状態を十分に把握し、問題に適切に対処できます。

一方、分散システムは、相互接続する要素がはるかに多いため、発生する障害の数と種類も多くなります。また、常に更新されるため、変更があるたびに、発生する可能性のある障害の種類が増えます。分散環境では現行の問題を理解することが非常に難しくなります。その大きな要因は、シンプルなシステムよりも「未知の未知」が増えるためです。監視では「既知の未知」が前提なので、複雑な分散環境ではほとんどの問題に適切に対処できません。

オブザーバビリティは、分散システムの予測不可能性への対応に適しています。その大きな理由は、問題が発生したときにシステムの動作について「なぜXが故障したのか？」、「現在起きている遅延の原因は何か？」などの質問を投げかけて答えを得ることができるためです。

コンテナやマイクロサービスのオブザーバビリティ（可観測性）を高めれば、本番環境のアプリケーションの状態を可視化して、開発者がパフォーマンスの問題を特定および解決しやすくなります。

コンテナサービス(Docker、Kubernetesなど)やマイクロサービスを使えば、モノリシックなアプリケーションで発生するリスクの高いダウンタイムなどの問題を解消できます。モノリシックなアプリケーションでは、1つのコードベースの変更がアプリケーション全体とそれに依存するすべてのサービスに影響します。これに対して、コンテナやマイクロサービスでは、アプリケーションを複数の独立したサービスに分割することで、アプリケーション全体ではなく特定のサービスだけを変更して再デプロイできます。

ただし、コンテナベースのアーキテクチャは新たな課題を生みます。相互依存するマイクロサービスは通常、複数のホストに分散して配置します。また、インフラを拡張すると、本番環境のマイクロサービスの数も増えます。これにより、本番環境で現在実行されているサービスを把握するのが難しくなり、デリバリーサイクルの長期化やダウンタイムなどの問題につながります。

オブザーバビリティを高めれば、分散システムを可視化することで、アプリケーションのパフォーマンスや可用性をより正確に把握して、これらの課題に対応できます。また、障害が発生したときは、適切な情報に基づいて問題をすばやく特定し、デバッグまたは修正できます。

オブザーバビリティの軸となるデータクラスは、ログ、メトリクス、トレースの3つです。これらはよく「オブザーバビリティの3つの柱」と呼ばれます。

ログ：ログは、特定の時点で発生したイベントのテキストレコードであり、発生日時を示すタイムスタンプとコンテキストを示すペイロードが記録されます。ログには、プレーンテキスト、構造化、バイナリの3種類の形式があります。プレーンテキストが最も一般的ですが、近年では、追加データとメタデータを含み照会が容易な構造化ログも増えています。システムで問題が発生したときは、通常、最初にログを確認します。

メトリクス：メトリクスは、一定の期間にわたって測定された数値であり、タイムスタンプ、名前、KPI、値などの属性が記録されます。ログとは異なり、形式は構造化が基本であるため、照会や保存先の最適化が容易で、長期の保存に適しています。

トレース：トレースは、分散システムでのリクエストの処理経路をエンドツーエンドで表すデータです。ホストシステムでリクエストが処理される際に、リクエストに対して実行された各処理(スパン)が、それを実行したマイクロサービスに関する重要なデータとともにエンコードされます。トレースには1つ以上のスパンが含まれているので、トレースを確認することにより、分散システム内での処理経路を追跡し、ボトルネックや障害の原因を特定できます。

これらのデータクラスを収集していても、別々に扱っていたり、それぞれ異なるツールで調査したりしていると、オブザーバビリティは保証されません。オブザーバビリティを実現するには、ログ、メトリクス、トレースを単一のソリューションに統合する必要があります。そうすれば、問題の発生を検知し、その原因の特定にすばやく取り掛かることができます。

オブザーバビリティを実現するには、システムとアプリケーションから適切なテレメトリデータを収集するためのツールを導入する必要があります。独自のツールを開発することも、オープンソースのソフトウェアを使用することも、市販のオブザーバビリティソリューションを購入することもできます。オブザーバビリティは、通常、4つのコンポーネントで実現されます。

• インストルメンテーション：コンテナ、サービス、アプリケーション、ホスト、その他のシステムコンポーネントからテレメトリデータを収集する測定ツールです。このツールを使用することにより、インフラ全体を可視化できます。
• データの相関付け：システムから収集したすべてのテレメトリデータを処理して相関付けます。これにより、コンテキストを生成し、データを自動または独自の時系列で可視化できます。
• インシデント対応：インシデント対応を自動化することで、オンコールスケジュールや技術スキルに基づいて、障害に関するデータを適切な担当者やチームに提供できます。
• AIOps：機械学習モデルを使用して、インシデントデータを自動的に集約、相関付け、優先順位付けします。これにより、アラートノイズを排除し、システムに影響を及ぼす可能性のある問題を検出して、インシデント対応を迅速化できます。

独自のソリューションを開発する場合でも、オープンソースや市販のソリューションを使用する場合でも、オブザーバビリティツールには以下の要件が求められます。

既存のツールとの統合：オブザーバビリティツールが現行のスタックと連携しなければ、オブザーバビリティ実現の取り組みは失敗に終わります。既存の環境、コンテナプラットフォーム、メッセージングプラットフォーム、その他重要なソフトウェアで使用されるフレームワークや言語にツールが対応していることを確認しましょう。

使いやすさ：ツールの習得や使用が難しいと、ワークフローに組み込まれず、オブザーバビリティ実現は遠のきます。

リアルタイムデータの提供：優れたオブザーバビリティツールは、ダッシュボード、レポート、クエリーを介して、問題とその影響や解決方法を理解するために役立つインサイトをリアルタイムで提供します。

最新のイベント処理技術への対応：スタック、テクノロジー、運用環境全体からすべての関連情報を収集し、価値のあるシグナルとただのノイズを切り分け、問題に対処するために十分なコンテキストを提供するツールが効果的です。

集約データの可視化：ダッシュボードやインタラクティブなサマリーなど、視覚的にわかりやすい方法でインサイトを提示するツールを使えば、状況をよりすばやく把握できます。

コンテキストの提供：オブザーバビリティツールは、インシデントが発生したときに、パフォーマンスの経時的変化、他の部分への影響、問題の範囲、影響を受けたサービスやコンポーネントの相互依存関係など、システムの状態を理解するのに十分なコンテキストを提供する必要があります。オブザーバビリティレベルのコンテキストがないと、インシデント対応は難しくなります。

機械学習の活用：データの処理とキュレーションを自動化する機械学習モデルが組み込まれたツールなら、異常やその他のセキュリティインシデントをよりすばやく検出して対応できます。

ビジネス価値の提供：デプロイの速度、システムの安定性、カスタマーエクスペリエンスなど、ビジネスに重要なメトリクスを基準にしてツールを評価することが大切です。

本番環境の分散システムでオブザーバビリティを実現すれば、DevOps開発者は、アプリケーション内部の状態をいつでも確認し、問題の発生時には正確な情報にアクセスできます。主なメリットをいくつか紹介します。

可視性の向上：分散システムが拡大すると、本番環境でどのサービスが稼働中であるか、アプリケーションのパフォーマンスは安定しているか、サービスの所有者は誰か、最後のデプロイ前のシステムはどのような状態だったかなどを把握することが難しくなりがちです。オブザーバビリティを実現すれば、本番環境のシステムをリアルタイムで可視化して、これらの疑問を解消できます。

アラート対応の向上：オブザーバビリティを活用すると、問題の発見と解決を迅速化できます。システムを詳細まで可視化することで、すばやく変更箇所を特定し、問題をデバッグまたは修正し、変更による悪影響があれば、それを特定することができます。

ワークフローの向上：リクエストの処理をエンドツーエンドで追跡し、問題に関するコンテキストデータを確認できるようになるので、アプリケーションの調査とデバッグプロセスを効率化し、パフォーマンスを最適化できます。

情報収集の効率化：開発者がサービスの責任者や、最後のデプロイの数日または数週間前のシステムの状態を確認する際は、外部のサービスやアプリケーションを利用して情報を追跡しなければならないことがあります。適切なオブザーバビリティソリューションを導入すれば、これらの情報をすぐに入手できます。

開発の効率化：監視とトラブルシューティングを効率化することで、開発者の負担を減らすことができます。これにより、デリバリーを迅速化し、組織や顧客のニーズを満たす革新的なアイデアを考えるための時間を増やすことができます。

DevOpsと同様に、ソフトウェアエンジニアリングの領域でも、オブザーバビリティを実現することでインフラ全体に関するインサイトを獲得し、問題の発生、新しいソフトウェアのデプロイ、スケールアップやスケールダウンによるインフラへの影響を把握できます。

開発者とソフトウェアエンジニアは、外部のアプリケーションやサービスも内製のアプリケーションやサービスも含むアーキテクチャ全体を可視化できる点でオブザーバビリティのメリットを受けます。可視化により、問題の修正と防止が容易になるだけでなく、システムのパフォーマンスとそのカスタマーエクスペリエンスへの影響に関する理解が深まります。その結果、ビジネスに利益をもたらす戦略的イニシアチブの立案により多くの時間を費やせるようになります。

チームとしても、アーキテクチャ、健全性、パフォーマンスの時系列の変化を包括的に理解して、環境に対する認識を共有できる点でメリットがあります。開発者、オペレーター、エンジニア、アナリスト、プロジェクトマネージャー、その他のチームメンバーの間で、サービス、顧客、その他のシステム要素に関するインサイトを共有できます。また、インシデント事後レビューの精度も高まります。サイロ化された個々のソースのイベントをつなぎ合わせる作業が不要となり、リアルタイムのシステム動作に関する記録文書を検証できるようになるからです。インシデントの原因を人の意見ではなくデータに基づいて判断することで、将来のインシデントに対してより効果的な防止および対応策を立てることができます。

そして、おそらく組織全体のメリットが最大のものです。オブザーバビリティを実現すれば、システムの状況を包括的に把握し、発生した問題をすばやく特定して改善または解決できるようになるので、システムの安定性を損なうことなくアプリケーションやサービスを変更できます。新しい機能を投入しながらダウンタイムを短縮することにより、顧客の満足度を高め、収益の向上につなげることができます。

オブザーバビリティは単なる流行語ではありません。インフラ全体の状態を把握するための重要かつ実用的なアプローチです。クラウド、コンテナ化、マイクロサービス、その他のテクノロジーにより、システムはかつてないほど複雑化しています。総合的に見ればこれらのテクノロジーは非常に有用ですが、そのシステムの運用、トラブルシューティング、管理には困難が伴います。相互依存関係が増えることで問題が多様化し、ひとたび問題が発生すると、その検出と修正は容易ではありません。

幸い、これらの分散システムはさまざまなテレメトリデータを生成します。それらのデータを活用すれば、パフォーマンスをより正確に把握できます。効果的なオブザーバビリティツールは、インストルメンテーションと分析機能によって、システムの出力を捕捉し、コンテキストを生成して、システムの分散が進む今日の世界で成功するために必要なインサイトをもたらします。