クラウド監視と応答
この記事は、クラウド監視ガイドのシリーズの一部です。
応答とは、監視によるデータ ドリブンの意思決定に基づいて、1 つ以上の "アクション" を定義した結果です。これにより、コンシューマーは次のことが可能になります。
- 実用的にする: 適切に調整された監視構成を使用して、実用的なシグナルを作成します。
- 継続的な監視: インシデント全体の監視とトラブルシューティング アクティビティを適用して、問題の診断にさらに役立つようにします。
- 自動化: 識別されたシグナルに基づいて、自動調査、診断、解決、回復、修復を構成します。
''重要性'' の原則はここで適用されます。 これは、アラート、通知、レポート ダイジェストを調整および最適化するためのアクションのプロセス フローまたはポリシーに役立ちます。 クラウド監視では、何らかの問題が発生したことを人に通知するだけではありません。 対応するシステムとサービスにシグナルを提供することも目的です。
監視は、さまざまなシナリオで重要な役割を果たします。
- 動的なサービス動作の有効化: 監視データに基づいて対応するシステムとサービスが動的に制御され、インシデントが自動的に排除されます。
- 継続的にシグナルを評価する: 動的プロセス、コンプライアンス、自動スケーリング、視覚化に関するテレメトリを常にお知らせして提供します。
- 組織のアクション: IT 組織が変更に対応し、管理するのに役立ちます。
アラート
自動化では、最新のクラウド環境でよりコストのかかるサービス管理プロセスを置き換え、より多くのインシデントを排除します。 アラートは認識において重要な役割を果たしますが、アラートの疲労またはノイズを回避するために実用的なものである必要があります。
アラートを定義すると、サービスやシステムの正常性、応答性、信頼性、および安全性の維持を予防的に確保するのに役立ちます。 パフォーマンスの保証、サービス レベル目標 (SLO)、可用性、プライバシーの維持には、適切なアラート戦略が必要です。 アラートのエスカレートは可観測性にとって重要でなく、今日では、防御の最前線と見なすべきではありません。 代わりに、自動化はここで重要な役割を果たす必要があります。
従来、監視とは、誰かが対応できるアラートを生成することを意味し、完全にリアクティブなプロセスを暗に意味します。 このアプローチは、最新のサービス管理またはクラウド運用プラクティスに従って変更する必要があります。 このアプローチは従来の ITIL インシデント管理のパスに厳密に従っており、機敏性、最小コスト、最適化によるクラウド効率の目標と一致しません。
最新のアプローチでは、はるかに多くの情報を持ち自動化された、検出条件の頻度が高くなります。
| 検出された条件 | プリミティブ アクション | 最新のアクション |
|---|---|---|
| アラートと通知、Webhook、プッシュ通知、プレイブック、自動スケール | ログにクエリを実行して問題のあるコンポーネントを特定し、問題のあるコンポーネントの問題を修正する自動化をトリガーする。 |
Azure のアラートと自動化の機能に関連するリソースの一覧を次に示します。
- Azure Monitor アラートとは
- Azure Monitor をサポートされている IT サービス管理 (ITSM) 統合製品と統合する。
- 自動化ルールを使って Microsoft Sentinel の脅威への対応を自動化する
最新のクラウド監視
過去に使用可能だった監視プラットフォームや関連ツールと比較して、クラウド コンピューティングでは次のものが得られます。
- デバイスの応答オプションへのはるかに高い柔軟性。
- 自動応答を開発して有効にする簡単な方法。
- 作業管理システム (DevOps など) と簡単に統合できるクラウド プロトコルや API メソッド。
調査、エンリッチメント、ルーティング、割り当て、修復、復旧、解決など、自動化されたアクションの範囲について、次のモードを検討します。
| オーケストレーションの方法 | 説明 |
|---|---|
| 完全自動 | アクションは自動的に実行されます。 完全な自動化は、その有用性が短くなく、安全であるというところまで、信頼性、効率性、耐久性を実証する必要があります。 完全自動を使用することでリソースが解放され、戦略的イニシアティブにより集中できるようになります。 |
| 半自動 | すべての修復アクションに対する承認が必要です。 |
| [手動] | オペレーターは、キュレーションされたライブラリから自動化の例またはプレイブックを選択します。 |
アラートは、セキュリティ イベント、パフォーマンス メトリック、可用性情報、ログに基づいてインストルメント化されたデータに依存します。 データ ドリブンのアクションは、その影響と実行する応答アクションを判断するために、収集された各種データを集計して処理することで、監視対象の各リソースの包括的でエンドツーエンドな観点を分析した結果です。
学習内容をこれらのリソースにまで広げることで、メトリック アラートとセキュリティ イベントに基づく自動化の詳細について確認してください。
- Azure Monitor を使用した Azure での自動スケーリングの概要。
コスト効率
他の可観測性の規範と同様に、チームは、コストへの影響と、最新のインシデント管理をサポートするために定義された応答の種類がどのようにコストを制御するのに役立つのかを理解し、実現する必要があります。 包括的な目標は、問題に迅速に対応して解決することで平均復旧時間 (MTTR) を削減することですが、IT またはビジネスの収益に対する潜在的なコストと影響を定常的に評価する必要があります。
報告されたインシデントごとにコストがかかります。 組織がオーケストレーションに投資して応答を自動化するとします。 この場合、クラウド サービスからの消費量を増やして、自動化を可能にするサービスまたは機能を利用することで、コストのメリットと影響を評価する必要があります。
Automation
クラウド自動化により、セキュリティと正常性の監視に大きな利点が得られます。 速度、柔軟性、精度は、クラウド自動化によって応答性の高い操作を実現する 3 つのアーキタイプです。 多くの場合、これはオーケストレーションと呼ばれ、Microsoft クラウドによっていくつかのサービスが提供されています。
次に例を示します。
- ID ドリブンの脅威が 1 つ以上のログから検出され、アラートが生成される。
- 自動化が即時にトリガーされ、より多くの情報が収集され、より多くのログが関連付けられて、アラートがエンリッチされます。
- オペレーターは、ユーザーの無効化など、ライブラリから適切な自動化を選択してアクションを実行します。
例またはユース ケースを完全に自動化できます。
ここでの自動化の役割は、コストを削減し、時間を節約する一種の "プレイブック" を提供することです。
- 時間のかかる調査と診断、解決、復旧に伴うセキュリティ インシデントは不要。
- 検出から修正のサイクルは、数時間ではなく、数秒または数分。
次に、チームは、パブリック Web サイト上にあるか、あるいは内部的にキュレーションされてソース管理リポジトリに格納されている原材料のいずれかから、柔軟に使用できる自動化の例の一覧またはライブラリを構築する必要があります。
ID またはセキュリティ イベントに基づいて自動化を強化するために推奨される資料の一覧を次に示します。
- Microsoft Sentinel を使用して Microsoft セキュリティ アラートからインシデントを自動的に作成する。
- Microsoft Sentinel でのセキュリティ オーケストレーション、オートメーション、および応答 (SOAR)
適切なアラート戦略
知らないものが壊れても直すことはできません。
重要なことについてアラートを発することが欠かせません。 適切なメトリックとログの収集と測定を行うことが、その土台となります。 また、格納、集計、視覚化、分析、および条件が満たされたときの自動応答の開始が可能な監視ツールが必要です。 サービスとアプリケーションの可観測性を改善できるのは、その構成を完全に理解している場合に限られます。 その構成を、監視プラットフォームによって適用される詳細な監視構成にマップします。 この構成には、アラートの対象とする意味がある、予測可能な障害状態 (障害の原因ではなく、現象) が含まれます。
情報案内アラート
特定の状況では、一部のアラートは ''情報'' である場合があります。 これを使用して、システムの動作について学習できます。 たとえば、これらの情報アラートを取得できます。
VM がシャットダウンされた: ''無駄を最小限に抑えてコストを管理する'' ために、スケジュールに従って、または検出された低使用率に基づいて VM が自動的にシャットダウンされました。
この例では、オーケストレーションは、ネイティブなスケジューリング機能に基づいて、使用率の状態を検出する監視プラットフォームによって使用されていました。 唯一のアクションとして通知またはエスカレートするアラートではなく、実行されたアクションとその理由が通知されます。
アイドル リソース: IaaS または PaaS のリソースが長時間アイドル状態にあるか、Azure Advisor の推奨事項に基づいてプロビジョニングされていません。
この例では、ビジネス ロジックまたは ITSM プロセス ワークフローに基づいて、オーケストレーションを使用して、これらのインフラストラクチャ関連のアクティビティを管理できます。 今日では、はるかに高速な応答とアクションが必要です。 クラウドを使用すると、自動化された応答に比べ、または自動化された値ストリームの一部として進行中のオーケストレーションに比べ、人に対する ''アラート'' が少なくなります。
アラート戦略に関する考慮事項
学習が重要であることに留意してください。適切に設計されている場合、情報アラートを使用すると、クラウド エコシステムと正常性に関する多くの分析情報を得ることができます。
ある症状がアラートの適切な候補であるかどうかを判断するには、以下の原則を考慮します。
実用的: 問題は重要ですか? アプリケーションの正常性に実際の問題が反映されていますか? たとえば、長期にわたってリソースの CPU 使用率が高すぎるときや SQL クエリが常にパフォーマンスの問題を引き起こしているときにアラートを送信したいが、短期間に CPU が急増したときにはアラートを送信したくない場合があります。 誤検知を減らし、アラートの疲労を回避するために物事を実用的にします。
緊急: この問題に緊急の注意が必要ですか? もしそうであれば、担当チームにすぐに通知する必要があります。
顧客への影響: サービスまたはアプリケーションのユーザーはこの問題の影響を受けますか?
依存システムへの影響: 相互関係がある依存関係からのこれらのアラートは、異なるチームに通知が行われ、すべてのチームが同じ問題に取り組むことを避けるために対応付けが可能ですか?
これらを最初に考慮して、監視構成の開発を開始できます。 環境にまたがる前提条件をテストおよび検証できます。 たとえば、運用環境だけでなく非運用環境でも、これらの考慮事項と質問を継続的に評価します。 継続的な改善は、監視シグナルに対する応答を成功させるために重要です。
何が機能しているのかを継続的に評価する場合は、監視応答の有効性の認識を高めるのに役立つ次の質問を自問することを検討してください。
- アラート ボリューム: 大量のアラートを受け取りますか? 回避できた可能性のある実用的でないアラートが多数存在しますか?
- 見過ごされた問題: 監視構成で検出されなかった問題が発生しているユーザーからレポートまたはチケットを受け取りますか?
- 誤検知: 誤ってフラグが設定されたアラートやシグナルを受け取りますか?
- アラートまたはイベント: 本当にアラートを送信する必要がありますか? または発生したアラートの一部は単に、システムでフラグが設定されたイベントである可能性がありますか? アラートを送信するのではなく、クエリを実行するときにシグナルが表示される場合、アラートの疲労や実用的でない通知を回避するのに十分でしょうか?
Microsoft 監視ソリューション全体の機能の詳細については、この記事シリーズの「監視プラットフォームの概要」を参照してください。