ビデオ・ストリーミング・サービスが人気音楽アーティストの深夜コンサートをライブ配信することにしましたが、ユーザーがそれを視聴するために深夜にログインすると、バッファリングの問題が発生すると想像してみましょう。アーティストの熱心なファンの中には、問題が改善されるかどうかを確認するためにしばらくとどまる人もいるかもしれません。ただし、カジュアルなファンはストリームを放棄する可能性があります。さらに悪いことに、熱狂的なファンはイライラしてストリームだけでなくストリーミング・サービスも放棄するかもしれません。
今日のITサービスの利用者は、超高速のスピード、高水準のアップタイム、シームレスなインタラクションを期待しています。大規模なコンサートでのバッファリングの問題など、ネガティブなユーザー・エクスペリエンスは顧客離れを増加させる可能性があるため、ITチームは根本原因を迅速に特定し、システムの問題を解決する能力を必要としています。
そこで、監視ツールとオブザーバビリティー・ツールが現代のITオペレーション(ITOps)に不可欠となります。こうしたツールがどのようにしてそのようなシナリオを解決できるのかだけでなく、防止できるかを見てみましょう。
ライブ・ストリームのバッファリング問題に対処するために、オペレーション・チームは監視ツールを使用して、サーバーのグループが負荷のしきい値を超えたときに通知できます。そしてチームは、利用可能なサーバーにトラフィックを再分配することで、サーバーの負荷を再調整できます。
監視アラートによってトリガーされたオブザーバビリティー・プラットフォームは、主要なメトリクス(ビットレートへの適応など)を分析し、分散トレースを使用してビデオ・リクエストを追跡し、バッファリングの開始場所を特定できます。たとえば、ツールによってバッファリングの問題がコンテンツ配信ネットワーク(CDN)ノードのパフォーマンス不足に起因していることが検出された場合には、ツールはIT担当者にCDN構成を最適化し、デバイスの互換性を向上させるオプションを提供できます。
実際、主要なオブザーバビリティー・ツールは、同様のネットワーク・イベントの過去の監視データを分析し、コンサートが特定の地域のCDNノードを過負荷にすることを予測できます。このツールは、ITスタッフがCDNを事前予測的に再構成するよう促すことができ、ユーザーのバッファリングの問題が発生する前に、遅いノードに対処します。
つまり、監視とオブザーバビリティーは、システムの問題を診断するための補完的なアプローチを提供します。監視は何か問題が発生した際にチームに知らせるのに対し、オブザーバビリティーは、何が起こっているのか、なぜ起こっているのか、そしてそれを修正する方法をチームに教えます。これらを併用することで、ITチームがシームレスな顧客体験を確保するために必要な包括的な問題検知および解決機能が実現します。
オブザーバビリティーと監視の違いをより深く理解するために、それぞれの仕組み、類似点と相違点、ソフトウェア開発とネットワーク管理で果たす役割について見てみましょう。
オブザーバビリティーとは、外部出力に基づいて複雑なシステムの内部状態を理解する能力です。システムが観測可能な場合、ITチームは生成されたデータを調べることで性能に関する問題の根本原因を特定できます。追加のテストやコーディングは不要です。
「オブザーバビリティー」という用語は、動的なシステムの自動制御(たとえば、流量制御システムからのフィードバックに基づいてパイプを通る水の流れを調整する)に関連する工学理論である制御理論に由来しています。現代の自動車はその一例です。車の診断システムは、多くの場合、整備士向けのオブザーバビリティーを提供しています。整備士は、車を分解せずに、車が動かない理由を探るためにシステムを使用します。
ITOpsとクラウド・コンピューティングでは、オブザーバビリティー・ソフトウェアには、アプリケーションとそのアプリケーションが実行されるハードウェアおよびネットワークからの安定した性能データ・ストリームを集約して相関させるソフトウェア・ツールが必要です。
OpenTelemetryなどのオブザーバビリティー・ソリューションは、システムの出力データを分析し、システムの健全性の評価を提供し、問題に対処するための実用的な洞察を提供することができます。チームはそのデータを使って、アプリやネットワークの監視、トラブルシューティング、デバッグを実行できます。
観測可能なシステムとは、DevOpsチームがコンテキスト・データや相互依存関係を含むIT環境全体を把握できるシステムです。その結果、チームが問題を事前予測的に検出し、問題をより迅速に解決し、顧客体験を最適化し、サービス・レベル契約(SLA)に準拠することを可能にするITアーキテクチャが実現します。
監視は、事前に定義されたメトリクスとログのセットに基づいて、ITシステムから集約されたデータを収集・分析することで、システムの健全性を評価します。DevOpsでは、監視によってアプリケーションの健全性を測定し、既知の障害を検出し、ダウンタイムを防ぎます。たとえばITチームは、あるアプリのディスク使用量が100%に近づいたときにチームメンバーに警告するルールを、監視ツール内に作成する場合もあります。
監視の真価が発揮されるのは、長期的な傾向の分析です。監視ツールは、アプリがどのように機能しているか、また時間の経過とともにどのように使用されているかをチームに示すことができます。ただし、監視には制限があります。
監視を効果的に行うには、どのメトリクスとログを追跡すべきかをチームが把握している必要があります。チームが問題を予測していなかった場合、監視ツールは重大な本番環境の障害やその他の問題を見逃す可能性があります。また、監視ではITスタッフがサイロ化された監視ツール間で手動でデータを関連付ける必要があり、根本原因分析はより複雑で時間のかかるプロセスになり、開発者の予測能力も制限されます。
「オブザーバビリティー」と「アプリケーション性能監視」という用語は、しばしば同じ意味で使用されます。しかし、オブザーバビリティーはアプリケーション性能監視の進化形と見なす方が正確です。
アプリケーション性能監視とは、アプリケーションが性能基準やユーザーの期待を満たしているかどうかをITチームが判断する上で役立つツールとプロセスを指します。監視ツールは通常、ネットワーク・インフラストラクチャーの健全性と性能、アプリケーションの依存関係、ビジネス・トランザクション、ユーザー・エクスペリエンスを追跡します。これらのシステムは、性能上の問題を迅速に特定、隔離、解決することを目的としています。
アプリケーション・パフォーマンス管理(APM)は20年以上にわたって標準的な手法でしたが、アジャイル開発、DevOps、マイクロサービス、複数のプログラミング言語、サーバーレス、その他のクラウドネイティブ・テクノロジーの使用が増えるにつれて、チームは非常に複雑な環境を監視および評価するためのより高速で包括的な方法を必要としていました。前世代のアプリケーション・インフラストラクチャー用に設計されたAPMツールでは、アプリケーション環境全体の健全性と可用性について、高速で自動化され、コンテキスト化された可視性を提供できなくなりました。新しいソフトウェアは非常に急速に、非常に多くの小さなコンポーネントにデプロイされているため、従来のAPMは対応に苦労しています。
そこでオブザーバビリティーが重要になってきます。オブザーバビリティーは、アプリケーション性能監視ツールからのデータ収集方法に基づいて構築されており、クラウドネイティブ・アプリケーションとサービス・デプロイメントの分散的かつ動的な性質に対応する上で優れています。オブザーバビリティー・ソリューションは、ロギングと監視に総合的なアプローチを採用し、サービスがどのように相互作用し(たとえば、依存関係マップによって)、全体的なアーキテクチャにどの程度適合するのかチームがよりよく理解できるようにします。
監視とオブザーバビリティーの違いは、多くの場合、発生することがわかっている問題を特定することと、発生する可能性のある問題を予測する方法を見つけることの違いです。基本的に、監視は事後対応型で、オブザーバビリティーは事前対応型です。ただし、どちらもオブザーバビリティーの3つの柱と呼ばれる、同じタイプのテレメトリデータを使用しています。
3つの柱とは、以下の通りです。
監視では、チームはこのテレメトリー・データを使用してしきい値とベンチマークを定義し、事前構成されたダッシュボードと通知を作成します。また、テレメトリーを使用して依存関係を特定して文書化し、各アプリケーションのコンポーネントが他のコンポーネント、アプリケーション、ITリソースとどのように連携するかを明らかにすることもできます。
オブザーバビリティー・プラットフォームは、監視を一歩先に進めます。オブザーバビリティー・プラットフォームもテレメトリを使用しますが、事前対応的な方法で使用します。
DevOps、サイト信頼性エンジニア(SRE)、オペレーションチーム、ITスタッフは、オブザーバビリティツールを使用して、テレメトリをリアルタイムで相互に関連付け、システムの健全性を包括的かつ文脈的に把握します。これにより、チームはシステムの各要素と、さまざまな要素が互いにどのように関連しているかをよりよく理解できます。
依存関係を含むIT環境の包括的なビューを提供することで、オブザーバビリティー・ソリューションは、システム・イベントの「内容」、「場所」、「理由」、そしてそのイベントが環境全体のパフォーマンスにどのような影響を与えるかをチームに示すことができます。また、システム内に出現する可能性のあるテレメトリの新しいソース(ソフトウェア・アプリケーションへの新しいAPI呼び出しなど)を自動的に検出することもできます。
これらの機能は、多くの場合、DevOpsチームがアプリケーション・インストルメンテーション、デバッグ・プロセス、問題解決を実施する方法を決定します。多くのオブザーバビリティー・ソリューションには、現代のIT環境が作成する大量の未加工データから洞察を引き出し、重大度に基づいて問題をトリアージするのに役立つ機械学習(ML)とAIOps機能も含まれています。
監視とオブザーバビリティーは、どちらもネットワークとアプリケーションの管理に不可欠です。ただしこれらは、次のようないくつかの重要な点で異なります。
監視では、システムの性能を一定期間追跡し、KPIによって性能の問題を予測し、データの逸脱をリアルタイムでITチームに警告します。主に、システムの問題を発見し、異常なシステム・イベントを関係者に通知することに重点を置いています。したがって、監視は、予測可能なワークロードを行う静的で十分に理解されているネットワークに最適です。
オブザーバビリティーは、ネットワーク上のあらゆるデバイスとコンポーネントからのテレメトリ・データ(分散トレース機能を含む)を使用して、ネットワーク全体のパフォーマンスに関するより明確で包括的な視点を作成します。オブザーバビリティー・ツールは、複雑で動的なIT環境でリアルタイムの根本原因分析を実行できます。速度が遅い、または破損しているネットワーク・コンポーネントを特定し、先制的な修正アラートを提供することで、チームが監視すべき対象と、問題に事前対応的に対処する方法を理解できるようになります。
監視ツールは、メトリクスとログを使用して、システム・エラー、リソース使用パターンおよび特定の障害モードを検出します。これは、ITチームがすでに予期していた問題しか発見できないことを意味します。たとえば、アプリケーションの性能監視ソフトウェアは、アプリケーションにオンライン、オフライン、またはレイテンシーの問題が発生しているかどうかを示します。
監視はシステムが適切に機能していることを確認する際に役立つ重要なプロセスですが、監視ツールでは詳細な障害検出やインシデント対応に必要なコンテキストを提供できません。
オブザーバビリティーは、チームがアーキテクチャ全体を視覚化し、デバイス構成を保管し、ネットワーク全体で多様なデータ・ソースを統合し、シームレスなデータ分析を可能にする上で役立ちます。オブザーバビリティー・ツールは、ネットワーク環境(トポロジー、デバイス・ロール、アプリケーションの依存関係など)に関する追加情報でテレメトリー・データを強化し、ネットワーク・データを関連付けて「未知の未知数」を明らかにします。
可視性の向上と深い洞察により、ITチームはネットワークとアプリケーションの管理において、より事前対応的かつ探索的なアプローチを取ることができます。
監視システムは、使用傾向と性能に関するデータを収集し、そのデータを使用して起こっている事象を明らかにします。しかし、問題のある事象が起こっている理由を必ずしも説明できるわけではありません。
オブザーバビリティー・ツールは、表面レベルのデータ、CI/CDパイプラインからのデータ、および履歴データを使用してコンテキストを提供し、一見無関係に見えるシステム・イベントを関連付けます。相関機能は、開発者が問題の正確な根本原因をリアルタイムおよび遡及的に特定する上で役立ちます。
監視は、ITチームが確立した事前定義データセットによって制限されます。プログラムされた内容以外の問題を特定できないため、監視ツールは動的な環境の管理には不十分であることがよくあります。
監視ツールだけに頼るということは、サイロ化された監視データに頼るということであり、チームはデータの関連付けや手作業による根本原因分析に余分なリソースを費やす必要があります。手動プロセスでは問題解決が遅くなり、サービスの中断や停止の可能性が高まります。
オブザーバビリティ・ツールは、クラウド環境(ハイブリッド環境やマルチクラウド環境など)、オンプレミス・インフラストラクチャ、サードパーティ・アプリケーションにわたる動的で多様なデータ・ソースから、データ相互作用をマッピングできます。本質的に順応性が高く、現代のITインフラに求められる問題解決に適しています。
さらに、オートメーションとAIOps機能により、オブザーバビリティー・プラットフォームはエコシステムに合わせて拡張できるため、チームはインフラストラクチャーの拡張に合わせて効果的に管理できます。
監視ツールは、多くの場合、システム・データをダッシュボードで視覚化し、IT担当者が主要なメトリクスを一元化された場所で表示できるようにします。ただし、システム・エラーの原因を説明することはできません。代わりに、監視ツールは予測タスクと根本原因分析を人間のオペレーターに任せます。
ただし、オブザーバビリティー・ツールを使用すると、システム・エラーとその根本原因を含むトラバース可能なマップを作成できるため、根本原因分析ワークフローが自動化され、ITチームのトラブルシューティング・プロセスが効率化されます。
監視とオブザーバビリティーは密接に連携して、ITシステムを管理し、ネットワーク接続を最適化し、アーキテクチャーの拡張性を最大化するための包括的なフレームワークを構築します。
監視ツールは、テレメトリー・データやその他の主要なメトリクスを追跡し、パフォーマンスの逸脱をチームに警告することで、オブザーバビリティーの基盤を確立します。たとえば、アプリケーションが設定された応答時間のしきい値を超えると、監視ソリューションがアラートを生成します。
次に、オブザーバビリティー・ツールが、テレメトリー・データとデータの相関関係(最近のデプロイメントなど)を分析し、コンテキスト情報を追加し、データレイヤーを統合して、アラートの理由を決定します。アプリと他のサービスとのやり取りをトレースし、データベースのバグやネットワークの混雑が原因で動作が遅くなっているのかどうかを判別します。
オブザーバビリティーから得られる洞察は、監視機能を洗練させ、継続的な改善のためのフィードバック・ループを作る上でも役立ちます。オブザーバビリティー・ツールがデータ・パターンの変化を検出すると、監視アラートを更新して新しいパターンを反映し、監視ツールとオブザーバビリティー・ツールが連携して機能するようになります。
さらに、オブザーバビリティ・ツールは人工知能(AI)とMLを使用して監視データの可能性を最大限に引き出します。AI駆動型オブザーバビリティーの機能は、予測分析を使用してボトルネックや障害を予測することができます(たとえば、メモリ使用量の傾向を使用してサーバーの枯渇を予測するなど)。また、MLアルゴリズムを使用することで、オブザーバビリティー・ツールは、重要なアラートとノイズを区別し、アラートを洗練させることができます。
たとえば、CPU使用率の一時的な(ただし予想される)急増があった場合、オブザーバビリティー・ソリューションを利用することで、監視ツールによって生成されるアラートを抑制できます。ただし、CPU使用率が予期せず継続的に急増した場合、このソリューションを使用することで、関連するIT担当者にアラートを即座に送ることができます。
監視とオブザーバビリティーは、APMとITOpsのプラクティスを最適化するための不可欠で補完的なツールとして機能します。これらのソリューションは、さまざまなユースケースにおいて、事前対応的な問題解決と事後対応的な問題解決の両方をサポートし、ユーザーが期待する高速で可用性の高いITサービスを確実に提供できるよう支援します。
問題の原因を迅速に特定し、修正します。 リアルタイムの高精度データにより、動的なアプリケーションおよびインフラストラクチャーの環境を完全に可視化できます。
オブザーバビリティーを活用して、クラウドのリソースをプロアクティブに最適化し、パフォーマンスを確保し、コストを節約します。
異種の環境、アプリケーション、ツールセットからのデータを利用して依存関係と関連性を分析し、アプリケーション環境の全体にわたる可視性を提供します。