クラウド監視の可観測性

[アーティクル]
07/17/2023

この記事は、クラウド監視ガイドのシリーズの一部です。

以下のセクションでは、注意深く観察し、サービスの監視方法を改善するための反復を常に行うことで、運用の成熟度を高めることを目標とします。組織が各監視ソリューションの "可観測性" を確立することで一貫した監視戦略をより迅速に実装する方法について説明します。

可観測性の定義

可観測性と監視は相互に補完し合うものである一方で、次のような顕著な相違点もあります。

監視: 情報を収集し、問題を検出したことを、それらの条件をどのように監視するかの構成に基づいて通知します。既知または予測可能な失敗を監視していることになります。
可観測性: 出力データを調べることによって、システム内で何が起こっているかを理解する機能。 "可観測性ソリューション" は、このデータを分析してシステムの正常性を評価し、IT インフラストラクチャの問題を解決する方法を見つけるのに役立ちます。

可観測性は、まず監視コンシューマーが何がサービスの "通常" の運用と見なされるかを理解することを促します。つまり、できるだけ早い "完全な可視性" を追求することになります。

初期の可観測性を確立したら、その初期レベルの可視性に基づいて、アクションにつながるアラートの開発、有用なダッシュボードの作成、および AIOps ソリューションの評価を行います。これらの分析情報によって、基になるメトリックとログ監視データを使いこなせるようになります。

注意

これは、チームがビルド、テスト、およびデプロイの前に、まず紙の上で監視要件のすべてを定義する作業を行うという過去に使用されていたアプローチとは真逆のものです。

監視計画がアプリケーション、クラウドインフラストラクチャ、または Azure プラットフォームのどれを対象としていようとも、最初の手順は "可観測性を確立" することです。

このアプローチにより、計画も簡略化されます。すべての場合において、完全な可視性とは、次に示す 3 つのディメンションあるいは側面にわたって十分な可視性を達成し維持することを意味します。

詳細にわたる監視: 有意義で関連性が高いシグナルを収集します。
端から端までの幅広い監視: スタックの最下層からアプリケーションまでを監視します。
正常性モデル全体での監視: 可用性、パフォーマンス、セキュリティ、継続性などの正常性の側面に重点を置きます。

Three-sided cube example

可観測性は、IT チームにとっての重点項目であるだけではありません。重要な目標は、エンドユーザーがシステムを使用でき、サービスレベル目標 (SLO) が達成されるようにすることです。

監視ソリューションと可観測性

インフラストラクチャとアプリケーションの監視は複雑化する場合があります。ビジネストランスフォーメーションはテクノロジを適用して、戦略の実現と形成支援を行います。クラウドは、監視の複雑な性質にさらに影響を与えています。

これは、次のように示されます。

デジタルトランスフォーメーションシフト: ビジネスのデジタルトランスフォーメーションの取り組みは、クラウドテクノロジの高度な利用にシフトしています。
組み込みの監視: オンプレミスで管理されるツールとは対照的に、監視機能は Azure のリソースやリソースグループに埋め込まれるようになってきています。
拡張的な監視 Azure Monitor などのクラウドネイティブのアーキテクチャは、セキュリティインシデントイベント管理 (SIEM) ツールと類似しています。 Azure Monitor は、拡張性があり、ログ駆動型で、従来のオンプレミスツールに比べて桁違いの柔軟性があります。

"アーキテクト" は、"オペレーター" と同様に、インフラストラクチャコンポーネントやアプリケーションがどんな診断情報を生成するかを理解する必要があります。

多変量、動的、時系列、イベントフル、ステートフル、およびテレメトリのログストリームを組み合わせて価値あるインテリジェンスとできるかどうかは次のことにかかっています。

チームの知識: 監視対象を深く理解している開発者またはシステムエンジニアの知識と経験。
トラブルシューティングの経験: データを使用して問題の原因を見つけたり、場所を特定したサポートやトラブルシューティングの経験。
履歴からの学習: 過去のインシデントを確認して、後で自動修復できるテクノロジ以外の原因を見つけます。
ドキュメント: ソフトウェアまたはハードウェアのベンダーによるドキュメント、ソフトウェア、トレーニング、またはコンサルティング形式のガイダンス。

Microsoft とそのパートナーは、System Center Operations Manager 用の管理パックを提供しています。管理パックはテクノロジ固有です。たとえば、SQL 管理パックをインポートすると、Operations Manager は、SQL Server をホストしている対象サーバーを自動的に検出し、そのサーバーの監視を開始します。この時点で、"可観測性は多かれ少なかれ定義済みです"。 Operations Manager は、主にオンプレミスインフラストラクチャ用に設計されています。これはクラウドサービスと比較してコンポーネントとアーキテクチャ設計パターンに固定化される傾向があります。

クラウドでは、選択できるサービスの種類に非常な柔軟性があります。監視はサービスが時間の経過と共にどのように変化するかを含み、動的でグローバルであり、かつ回復性を持つことができます。 Azure Monitor を使用すると、Operations Manager の管理パックと同様の機能を提供する Azure Monitor Insights に含まれる既存のブックを利用できます。

観察技術

可観測性は、対象の何がどのように監視されているかにかかっています。

Azure には、複数の監視データソースがあり、それぞれがどのように対象が動作しているかについての異なる観点を提供します。 Azure にはこのデータのさまざまな側面を分析するのに役立つ数多くのツールが含まれています。

プラットフォームを監視する

Azure において、Microsoft はさまざまな "プラットフォームログ" を通して "サービスプロバイダー" の分析観点を提供しています。

Azure のサービスは、時間の経過と共に、さまざまな予測できない方法で変化する可能性があります。ここではこの振る舞いを動的と呼びます。長期間にわたってサービスを監視するクラウドサービスのマネージャーは、次の点も考慮する必要があります。

リソースの再配置: リソースは場所または地域をまたいで移行や移動を行う可能性があります。
リソースの変更: リソースは追加、削除、または変更が行われます。
従量課金: 従量課金はさまざまなサービスと実装によって異なります。コスト、従量課金、予想される支出を監視することを心掛けます。

プラットフォームの可観測性をもたらすツールの例をいくつか次に示します。

ログソース	説明
サービス正常性	Microsoft によって報告されるサービスインシデントと計画メンテナンス。
Azure Resource Health	リソースの現在および過去の正常性についてレポートを行います。
Azure Monitor アクティビティログ	サブスクリプションにデプロイされているすべてのリソースにわたるサブスクリプションレベルのイベントをレポートします。
Azure Monitor の変更分析	Azure アプリケーションに対する変更についてレポートを行い、平均修復時間 (MTTR) を短縮します。
Azure リソースログ	以前は "診断ログ" と呼ばれていたリソースログは、Azure リソース内のデータプレーン上で実行された操作についてレポートを行います。
Microsoft Entra レポート (AzureAD) ログ	特定のテナントの Microsoft Entra ID のサインインアクティビティの履歴と変更の監査ログについてのレポート。
Azure Advisor	Azure Advisor を使用して、Azure デプロイを最適化するためのベストプラクティスに基づく推奨ソリューションを受け取ります。
Microsoft Cloud for Sovereignty の透明性のためのログ	リソースがいつアクセスされ、どの Microsoft エンジニアがリソースにアクセスするかを報告します。透明性のためのログは、顧客リソースへのアクセスの詳細を提供します。また、アクセス権がない場合もログで通知されますが、これは一般的なことです。

可観測性は、最小限の実行可能な監視プランから徐々に進化し、現在、ツールとプロセスを統合するための作業が行われています。データ (メトリック、ログ、およびトランザクション) に慣れてくるにつれて、それらのリソースまたはアプリケーションからの症状や問題の動作および兆候を理解できるようになります。データに慣れることによって、Azure Monitor およびデータ操作に対する信頼を構築します。

可観測性から自信を得る

適切な可観測性があると、自信がついて、原因を認識して役立つ回答を見つけることができます。データについて学ぶほど、プロセスの進化が進み、チームは分析情報を得ます。

シーンを設定するために、可観測性から自信を得るためのいくつかの方法を次に示します。

予測可能性の向上: リソースとサービスの監視の改善は、問題を事前に特定することに役立ち、将来においてそれらを予測および管理可能にします。
異常の早期検出: 可観測性は、異常や期待される動作からの逸脱のタイムリーな検出を可能とし、潜在的な問題の影響を軽減します。
根本原因の特定: 詳細な可観測性データは、問題の根本原因の特定に役立ち、迅速な解決と再発の防止を可能とします。
トラブルシューティング効率の向上: 可観測性によって、チームは関連するデータを分析し、イベントを関連付けることで、複雑な問題をすばやく診断してトラブルシューティングできます。
システムの信頼性の改善: ボトルネック、パフォーマンスの問題、潜在的な障害点を特定することで、可観測性はシステムパフォーマンスの最適化と全体的な信頼性の向上に役立ちます。
カスタマーエクスペリエンスの改善: 可観測性によって、システムのパフォーマンスがどのようにエンドユーザーに影響を与えるかをより良く理解でき、顧客満足度を向上させるための予防的な対策が可能になります。
コラボレーションの促進: 可観測性プラットフォームは、共有された可視性とデータアクセスを提供し、開発者、運用、サポートなど、さまざまなチーム間のコラボレーションを促進します。
規制コンプライアンス: 可観測性は、追跡可能性の提供、監査ログ、セキュリティおよびプライバシー標準への準拠の確保によって、規制要件を満たすことに役立ちます。
解決までの時間の短縮: 豊富なデータと分析情報を提供することで、可観測性は、問題の診断と解決にかかる時間を短縮し、ダウンタイムとサービスの中断を最小限に抑えます。
事前の容量管理: 可観測性データは、リソースの需要を予測し、容量のギャップを特定し、最適なパフォーマンスを維持するためにリソースを事前に調整するのに役立ちます。
リスク軽減: 可観測性を使用すると、潜在的なリスクを早期に特定し、予防的な軽減策を可能にし、重大な影響の可能性を減らすことができます。
継続的な監視と学習: 可観測性は継続的な監視と学習を可能とし、チームが変化する環境、要件、ユーザーの行動に適応するのに役立ちます。
パフォーマンスの最適化: 可観測性データを分析することで、チームはパフォーマンスのボトルネックを特定して最適化し、システム効率を向上させることができます。
作業の優先順位付け: 可観測性分析情報は、チームがタスクに優先順位を付け、特定された問題の重要度と影響に基づいてリソースを割り当てることを可能とします。
変更管理における自信: 可観測性は、変更の影響に可視性をもたらし、新しいデプロイや更新プログラムが予期しない問題を持ち込まないことを保証します。
インシデント対応の改善: 可観測性により、インシデント対応チームは関連情報をすばやく収集し、コンテキストを理解し、適切なアクションを開始できます。

監視計画

監視計画を作成して、目標、目的、要件、およびその他の重要な詳細事項について記述します。次に、組織内の直接の利害関係者全員の合意を得るように働きかけます。

監視計画によって、1 つ以上の監視ソリューションを開発および運用する方法を説明する必要があります。プロジェクトの戦略および計画フェーズ中の早い段階で監視計画の作成を開始します。

計画を作成する際には、クラウド監視戦略のドキュメントで説明されているように、現代的な監視の 5 つの規範 (監視、測定、対応、学習、改善) を思い出すことが重要です。

以下は監視計画のための推奨されるアウトラインであり、サービスの個別の計画のための、あるいは Azure リソースタイプや Microsoft 365 サービスなどのクラウドサービス機能を標準化する際の主な考慮事項と見なされています。

この計画の本質は、(ソリューションを提供する) サービスプロバイダーと、(運用を行う、または価値を引き出す) コンシューマーの間の可視性の境界線を定義することです。

ビジネスの観点

包括的な監視計画が考慮する必要があるのは、ビジネスが監視に関して、および監視から何を求めているかであり、ユーザーを中心とした視点を含んでいます。計画を定義する際には、ビジネス要件を文書化して共有することが重要です。以下では計画のこの部分の "スコープを提案します"。

利害関係者とコンシューマー
ビジネス価値ストリームとプロセス
エンドユーザーの観点とユーティリティ
測定とレポートの要件
特定されたリスクとコンプライアンス制御フレームワーク
アクセスと制御の要件
ビジネスに対するリスク

サービスの観点

包括的な監視計画が考慮する必要があることは、サービス所有者が監視によって、および監視から何を求めているかです。計画を定義する際には、その要件を文書化して共有することが重要です。以下では計画のこの部分の "スコープを提案します"。

利害関係者とコンシューマー
ロールとアカウンタビリティ
サービスの定義
アクセスと制御の要件
アーキテクチャに関する考慮事項?
コントラクトを支えるサプライヤーとパートナー
サービス契約 (SLA、OLA)
サービス保証の範囲の特定
測定とレポートの要件
リスク

テクノロジの観点

計画のこのセクションは、ビジネスおよびサービスの観点からの情報を使用して、監視ソリューションを表します。以下では計画のこの部分の "スコープを提案します"。

ユーザーストーリーとシナリオ
技術ターゲット (ネットワークなど)
コンポーネントの依存関係マッピング
種類 (たとえば、クラウドネイティブ、ハイブリッド、オンプレミスなど)
観察
レスポンシブ
Measurement
チューニングと最適化

考慮事項

関連するすべてのコンシューマー、利害関係者、および経営レベルに確実に伝達および通知するための計画をまとめます。監視計画を成功させるには、次の点を考慮してください。

重要な考慮事項

運用ステージ: 監視ソリューションは、サービスが稼働するときには準備が整っている必要があります。計画では、推測の実験とテストに役立たせるための別の専用のサブスクリプションにテストまたは運用前の構成を含めることができます。
戦略: 計画を監視および IT 戦略にマップし直して、監視の目標がミッションまたはビジネスに合ったものかを調査することもできます。
ターゲット: 計画内で、検討中の対象資産またはサービスの説明と分析を行います。必要に応じて、監視対象のすべてのコンポーネント (サービスの依存関係を含む) をマップします。対象範囲のギャップを特定し、サービスの各部分の所有者を特定します。
ソリューション: 監視ソリューションについては、コンシューマー、利害関係者、サプライヤー、パートナー、アクセス、およびインストルメンテーションを特定します。また、アスペクト、スコープ、応答、レポートおよびダッシュボード (可用性、セキュリティ、ユーザーエクスペリエンスなど) を監視します。

一般的な考慮事項

重要な考慮事項に加えて、これらのポイントが組織の監視計画にどのように影響を与えるかをより良く理解することを目指します。

実用最小限の製品 (MVP): 計画で、実用最小限の製品の正解がどのようなものかを定義します。言い換えると、運用開始のためには最初に何が必要であり、それについて成功度を測定できますか? 運用開始後も、価値を最大化するために監視ソリューションを進化させ続けます。
監視データのセキュリティ保護: 現代においてセキュリティはすべての組織とチームにとって重要な側面です。監視ソリューションにリスクを追加 (たとえば、機密の監視データをログでさらしてしまうなど) することがないように、教育を受けて超えてはいけない線を知るようにするか、専門家にガイドしてもらいます。
Microsoft 365の検討: 優れた計画はすべて、Azure テナントで Microsoft 365 を重要なコンポーネントとして使用することを検討します。 Microsoft 365 は Microsoft Entra ID に依存し、Azure Monitor は Microsoft 365 のエンドポイント管理との統合を提供します。
可観測性が優先: アラートに重点を置く前に完全な可視性に重点を置きます。アラートはコストであるだけでなく、すぐにアラート疲れをもたらす可能性があるためです。
アクティビティの監視: 監査、サインイン、およびアクティビティの各ログは現在ではサービス所有者やセキュリティにとって詳しく分析するのが容易なものになりました。監視計画で、直接の利害関係者のために作成する必要がある分析情報やダッシュボードなどのアクティビティ監視が考慮されていることを確認します。

次のステップ

サービスレベル目標