DevOpsモニタリングとは何ですか?

DevOpsモニタリングでは、テレメトリー（メトリクス、ログ、トレース）とイベント・データを使用してフィードバックを収集し、Full Stack Observability、プロアクティブな問題検知、DevOpsパイプラインでのソフトウェア配信の高速化を促進します。

DevOps監視ツールは、コーディングやビルドからデプロイメントまで、ソフトウェア開発プロセス全体を詳細に可視化します。インフラ、ネットワーク・コンポーネント、アプリケーション、継続的統合／継続的デリバリー（CI/CD）パイプライン、アプリケーション・プログラミング・インターフェース（API）、依存関係のヘルスと性能を追跡し、ソフトウェア製品とそのデリバリー方法を改善します。

監視とオブザーバビリティー（外部アウトプットに基づいて複雑なシステムの内部状態を理解する能力）は、別個の分野と見なされることがよくありますが、特にDevOps環境では、監視の取り組みがオブザーバビリティーをサポートすることがよくあります。オブザーバビリティーの実践にはDevOps監視も含まれ、特にマイクロサービスやクラウドネイティブ・アーキテクチャーにおいて、システムが特定の方法で動作する理由を説明するのに役立ちます。多くの場合、企業はオブザーバビリティーを実現するために高度な監視プラットフォームに依存しており、オブザーバビリティー・プラットフォームは監視ストラテジーを導くのに役立ちます。

高度な監視プラットフォームにより、DevOpsチームは包括的な問題検知機能と修復機能を活用できるようになり、合理化されたスケーラブルなソフトウェア・アプリケーションを構築し、シームレスな顧客体験を提供できるようになります。

DevOps監視により、チームと企業はソフトウェアの配信と管理に対する事後対応型のトラブルシューティング・アプローチから、事前対応型の予防的アプローチに移行できます。分散型のクラウド・ベースのアーキテクチャー全体にわたって、継続的なエンド・ツー・エンドの可視性を提供します。これは、明らかな個々の障害ではなく、サービス間の微妙な相互作用から障害が発生することが多い環境において非常に貴重な資産です。

たとえば、ヘルスケアの予約プラットフォームの患者がビデオ予約が開始されないことに苦情を言っているものの、このプラットフォームのビデオ・セッション・サービスには大きなダウンタイムは見られないとします。高品質のモニタリング・ソリューションは、テレメトリーを使用して、失敗した訪問が、プラットフォームのサード・パーティーのビデオ・セッション・サービスでレイテンシーとレート制限の問題がわずかではあるものの顕著な増加が見られた期間と相関していることを検出し、これにより患者のための部屋作成が遅れました。

DevOpsの観点から見ると、継続的な監視はコラボレーションのイネーブラーです。全ての利害関係者（オペレーション、開発、サイト信頼性エンジニアリング（SRE）、セキュリティー、製品チーム）は、多くの場合、単一の画面内で共有される信頼できる唯一の情報源から作業します。共有テレメトリーにより継続的なフィードバック・ループが可能になり、DevOpsチームは、DevOpsライフサイクル全体を通じて、バックログの決定、アーキテクチャーの変更、プロセスの改善を行うことができます。

DevOpsのモニタリングはシフトレフトの実践もサポートしています。「シフト・レフト」は、テスト、問題解決、セキュリティーなどの重要な開発タスクをソフトウェア開発ライフサイクルの初期段階に移すことを意味します。コードの欠陥やセキュリティー上の脆弱性は、理想的にはデプロイメントではなくコーディング中に発見されます。

監視ツールがデータを収集すると、DevOpsパイプラインにフィードバックします。ライブ環境のテレメトリーとインシデント・パターンを使用して、監視により、早期のテスト・ラウンドを回避する問題を明らかにできます。監視フックは、本番稼働後のデータと洞察をDevOpsチームに送り返します。DevOpsチームはその情報を活用して、将来のソフトウェア反復で開発における同様の欠陥を発見するための新しい本番前テストを設計できます。

DevOps監視は、複数の異なる（しかし関連している）タイプのIT監視をカバーし、システム、アプリケーション、およびユーザーの行動を完全に可視化します。各タイプは、インフラストラクチャーのヘルスからエンドユーザー・インタラクションに至るまで、ソフトウェア配信ライフサイクルの特定の層またはコンポーネントの計測に重点を置いています。

監視の種類には以下が含まれます:

インフラ監視は、アプリケーションをサポートするサーバー、ネットワーク、データベース、仮想マシン（VM）、クラウド・サービス、オペレーティング・システム、ストレージ・プラットフォームに焦点を当てています。目標は、これらの参考情報からINGESTすることで、コンピューティング・ネットワークのバックエンドが期待どおりに動作し、エンドユーザーに影響を与える前に異常を発見できるようにすることです。

インフラ監視ツールは、CPU使用率、メモリー消費量、ネットワーク・スループット、レイテンシーとアップタイムなどのメトリクスを収集します。その後、情報を一元化された監視プラットフォームに送り、DevOpsチームのためにデータを保存、分析、視覚化します。

ネットワーク監視ツールは、ルーター、スイッチ、ファイアウォール、ロードバランサー、VM、コンテナ、クラウドのワークロード間のデータフローを追跡し、データ転送を遅くする可能性のある接続性の問題や設定ミスを監視します。また、CI/CDパイプラインとインシデント管理ワークフローに情報を供給するため、DevOpsチームはリアルタイムのデータに基づいて自動アラートとロールバックを設定できます。

DevOpsプラクティスにはソフトウェアの迅速なリリースと高い信頼性が含まれるため、チームはデプロイメントの失敗を引き起こす前に問題を見つけて修正プログラムを適用するために必要なツールを用意しなければなりません。ネットワーク監視ツールは、このニーズに対応し、ネットワーク管理者が手動で実行するタスクを自動化します。

成熟したDevOps環境では、ネットワーク・モニタリングがチャット・ツール、ログ管理ツール、チケット発行システム、オンコール・スタッフのローテーションと統合されているため、アラートが実行可能なインシデントに変わります。同じデータを使用することで、DevOpsチームはインシデント後のレビューを合理化でき、ネットワーク・テレメトリーによって明らかになった内容に基づいてインフラストラクチャーをファイン・チューニングし、構成を更新し、将来のリリースを改善できます。

アプリケーション性能監視ツールは、アプリのフレームワーク（Javaや.NETなど）、オペレーティング・システム、データベース、API、ミドルウェア、Webアプリケーション・サーバーなど、アプリケーション・スタック全体を監視します。アプリケーションがユーザーのアクションにどれだけ迅速かつ確実に応答するか、また、ユーザーが必要とするときにアプリケーションが利用可能かどうかを測定します。

アプリケーション性能監視により、DevOpsチームは、高レベルのエクスペリエンスからデータベースや外部サービスなどの下位レベルの技術コンポーネントまで、あらゆるものを可視化できます。

例えば、多くの監視ツールは詳細なトランザクション・トレースと洞察を提供するため、チームは遅いデータベース・クエリー、非効率なコード・パス、依存関係の失敗を正確に特定できます。

従来のアプリ監視ソリューションは、「エージェント」と呼ばれる小さなソフトウェアコンポーネントに依存しています。エージェントはアプリケーション環境とサポート・インフラストラクチャー全体に展開され、性能とテレメトリーを定期的に（1分ごとに1回など）サンプリングします。より現代的なソリューションでは、エージェントレス監視を使用して非侵入型のデータ収集アプローチを採用し、ネットワーク・トラフィック分析を利用してアプリケーションのパフォーマンス・データを収集します。

どちらの場合も、DevOpsチームはアプリの性能監視ツールを使用することで、サービス・レベル契約（SLA）に準拠し、問題管理を自動化し、時間の経過とともにコード品質を向上させることができます。

ユーザーエクスペリエンスモニタリングは、しばしば デジタル・エクスペリエンス監視(DEM)と呼ばれ、実際の人々がサイトやアプリケーションを速度、信頼性、使いやすさの観点でどのように体験するかを理解することです。Webブラウザー、モバイル・アプリケーション、API、バックエンド・システムからデータをまとめ、ユーザーが苦労している場所とその理由を示します。

ユーザー・エクスペリエンス監視ツールは、ページの応答時間、インタラクションの遅延、エラー率などのメトリクスを追跡し、主要なユーザー・ジャーニー（登録、チェックアウト、検索など）が成功したかどうかを評価します。通常、ブラウザーやアプリのフロントエンド・メトリクスとバックエンドのオブザーバビリティー・データを組み合わせて、チームは不正なユーザー・インタラクションを特定のサービスや依存関係まで追跡できます。

ユーザー・エクスペリエンス監視は、リアルユーザー監視（RUM）や外形監視など、さまざまな監視アプローチで構成されています。RUMは、ライブ運用環境での実際のユーザー・セッションから性能とエラーのデータを収集します。外形監視（合成トランザクション・モニタリングとも呼ばれる）は、さまざまな場所や環境からのユーザー・アクションをシミュレートするスクリプト化された自動テストを使用します。

アプローチを問わず、ユーザー監視ツールを使用することで、DevOpsチームはアプリケーション・エコシステム全体のシステム的なパフォーマンス傾向を確認できます。

依存型システム監視は、アプリケーションが機能するために依存している外部システムやサービス（決済ゲートウェイ、認証プロバイダー、パートナーAPIなど）の可用性、性能、動作を測定します。

依存するシステム（または依存関係）がアプリケーションのコードベースの外に存在する場合でも、アプリの機能に大きな影響を与える可能性があります。たとえば、航空会社の予約アプリを決済プラットフォームに接続するAPIに障害が発生した場合、アプリ自体がどれほどうまく機能していても、顧客はフライトを予約できなくなります。

現代のIT環境は高度に分散しているため、かなりの数のインシデントが、上流または下流のサービスの障害やボトルネックに起因しています。依存システムの監視は、DevOpsチームが「コードが壊れている」状況と「依存関係が低下している」状況をすばやく区別するのに役立ちます。

そのため、依存するシステム監視により、DevOpsチームはインシデント対応を迅速化し、アプリの信頼性を向上させ、将来のフォールバックおよび再試行ストラテジーを通知することができます。

DevOpsにおけるセキュリティー監視とは、システム、アプリケーション、パイプラインのセキュリティー脆弱性や構成ミスを継続的に追跡することです。これにより、DevOpsチームは、1回限りのポイント・イン・タイムのセキュリティー・チェックから、スタック全体の継続的な自動監視に移行できます。

セキュリティー監視ツールは、テレメトリー監視と、脆弱性検知、アクセス監視、コンプライアンス・チェックなどのセキュリティー制御を組み合わせたものです。そうすることで、セキュリティー管理をCI/CD環境とランタイム環境に統合し、ソフトウェア・ライフサイクル全体にわたってセキュリティーの脅威を検知し、修正することができます。

監視ソリューションとオブザーバビリティー・ソリューションは多くの場合、互いに支援し合いますが、従来の監視とオブザーバビリティーの実践との違いを理解することが重要です。

基本的に、監視は事後対応型で、オブザーバビリティは事前対応型です。監視とオブザーバビリティーは、データの使用、範囲、深さ、柔軟性、視覚化機能の点でも大きく異なります。

監視とオブザーバビリティーはどちらも、同じ種類のテレメトリー・データ（メトリクス、ログ、トレース）を使用します。

監視では、チームはテレメトリー・データを使用して、システム内で何が起こっているかを明らかにします。例えば、ベンチマークを設定したり、（ソフトウェアのパフォーマンス目標に向けた進捗状況を示す）KPIを定義したりする場合があります。しきい値を設定する（特定のシステム・イベントに応答して通知とアクションをトリガーする）ダッシュボードの設置（テレメトリー・データの視覚化）が可能になりました。

チームはテレメトリーを使用して依存関係を特定して文書化し、各アプリケーションのコンポーネントが他のコンポーネント、アプリケーション、ITリソースとどのように連携するかを示すこともできます。

しかし、モニタリングでは問題のある事象が起こっている理由を説明することはできません。

オブザーバビリティー・プラットフォームは、テレメトリー・データを先見的に使用することで、監視を一歩先に進めます。

オブザーバビリティー・ツールは、表面レベルのデータ、CI/CDパイプラインからのデータ、および履歴データを使用してコンテキストを提供し、一見無関係に見えるシステム・イベントを関連付け、システムのヘルスの完全なコンテキスト化されたビューを作成します。相関機能は、開発者が問題の正確な根本原因をリアルタイムおよび遡及的に特定する上で役立ちます。問題の根本原因を特定する。

オブザーバビリティーにより、DevOpsチームはシステムイベントの「内容」、「場所」、「理由」、そしてイベントが環境全体の性能にどのような影響を与えるかを詳細に可視化できます。

さらに、多くのオブザーバビリティー・ソリューションは、システム内に出現するテレメトリの新しいソース（ソフトウェア・アプリケーションへの新しいAPI呼び出しなど）を自動的に検出できます。今日のオブザーバビリティー プラットフォームの多くには、AIと機械学習（ML）ツールが含まれており、最新のIT環境が生み出す未加工データの山から、チームがより詳細な洞察を得られるよう支援しています。

監視ツールは、メトリクスとログを使用して、システム・エラー、リソース使用パターンおよび特定の障害モードを検出します。これにより、ITチームは「既知の課題」を特定できるようになります。つまり、ITチームは、すでに可能性がわかっている問題のみを見つけることができるのです。たとえば、アプリケーションの性能監視ソフトウェアは、アプリケーションにオンライン、オフライン、またはレイテンシーの問題が発生しているかどうかを示します。

オブザーバビリティー・ツールは、ネットワーク全体の多様なデータ・ソースから抽出されたネットワーク環境に関する追加情報（トポロージ、構成、デバイスの役割、アプリケーションの依存関係など）でテレメトリー・データを強化することで、「未知の未知」を明らかにするのに役立ちます。

この可視性の向上と深い洞察により、ITチームはネットワークとアプリケーションの管理において、より探索的なアプローチを取ることができます。ダッシュボードで既知の故障を監視する代わりに、チームは観測可能性ソリューションにオープンエンドな質問をし、新しい故障モードやエッジケースを特定するために動作を反復的に「つついて探る」ことができます。

たとえば、エンジニアはオブザーバビリティーツールに「デプロイメント Y 後にトラフィックがサービス X を経由したオーストラリアのシドニーのアプリユーザーのレイテンシーが 5 秒を超えたトレースを表示する」ように依頼して、集計平均ではわかりにくいコホート固有のパフォーマンスの問題を発見することができます。

監視は、ITチームが提供する事前定義されたデータ・セットによって制限されます。ITチームが監視ソフトウェアをプログラムして認識すべき問題のみを特定できるため、監視ツールは動的な環境の管理には不十分であることがよくあります。

監視ツールだけに頼るということは、サイロ化された監視データに頼るということであり、チームはデータの関連付けや手作業による根本原因分析に余分なリソースを費やす必要があります。手動プロセスは問題解決を遅くし、人為的ミスの可能性を高め、サービスの中断や停止の頻度を増やします。

オブザーバビリティー・ツールは、クラウド環境（ハイブリッド環境やマルチクラウド環境など）、オンプレミス・インフラストラクチャ、サードパーティ・アプリケーションにわたる動的で多様なデータ・ソースから、データ相互作用をマッピングできます。本質的に順応性が高く、現代のITインフラに求められる問題解決に適しています。

さらに、オートメーションとAIOps機能により、オブザーバビリティー・プラットフォームはエコシステムに合わせて拡張できるため、チームはインフラストラクチャーの拡張に合わせて効果的に管理できます。

監視ツールは、多くの場合、システム・データをダッシュボードで視覚化し、IT担当者が主要なメトリクスを一元化された場所で表示できるようにします。ただし、システム・エラーの原因を説明することはできません。代わりに、監視ツールは予測タスクと根本原因分析を人間のオペレーターに任せます。

オブザーバビリティー・ツールは、DevOpsチームがコードベースとアプリのエコシステム全体を完全なコンテキストと相関した洞察とともに把握できるようにするトラバース可能なマップを作成します。この主要な機能により、チームはシステム・エラーを根本原因まで簡単に追跡し、トラブルシューティング・プロセスを効率化できます。

包括的なDevOpsモニタリングとオブザーバビリティーのプラクティスを導入することで、企業には次のようなさまざまなメリットがあります。