クラウド監視戦略

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

組織がクラウド環境に移行するときは、開発者、運用スタッフ、インフラストラクチャ エンジニアが参加して、効果的な監視戦略を計画し、開発することが重要です。 戦略は、拡張指向で、最初は最小限の定義にしておき、繰り返し改良する必要があります。 常にビジネス ニーズに対応し、ビジネスが依存する複雑な分散型アプリケーションを事前に監視できるアジャイルな組織を作る必要があります。

どこから始めるか

クラウドへの移行を容易にするために、クラウド導入フレームワークの戦略と計画の各フェーズを使用します。 すべてのイニシアティブとプロジェクトの戦略と計画のフェーズに監視を含めます。

たとえば、最初の導入プロジェクトによって Azure での初期運用管理がどのように確立されるかを調べます。 監視の役割など、クラウドの運用モデルがどのようになる必要があるか想像してください。 監視は、運用機能としてサービス ベースのアプローチで提供するのが最善です。監視はアドバイザリ サービスであり、ビジネスおよび IT のコンシューマーに対する専門知識のプロバイダーです。

次に、適切な監視戦略に大きな影響を与える重要な領域を示します。

• コンポーネントおよび他の依存関係との関係に基づいて、アプリケーションの正常性を監視します。 クラウド サービス プラットフォームから始めて、リソース、ネットワーク、最後にアプリケーションまで、必要に応じてメトリックとログを収集します。 ハイブリッド クラウド モデルでは、アプリケーションが依存しているオンプレミスのインフラストラクチャとその他のシステムを含めます。

• お客様によるアプリケーションとの一般的な対話を模倣して、アプリケーションのパフォーマンス監視計画でエンド ユーザーのエクスペリエンスを測定します。

• セキュリティ要件が組織のセキュリティ コンプライアンス ポリシーに対応していることを確認します。

• 警告や例外など、関連する実用的なインシデントからのアラートに優先順位を付けます。 インシデントの優先度と緊急度のエスカレーション マトリックスに従って、それらの重大度と重要度を一致させます。

• ビジネスおよび IT 組織にとって有用で、測定可能で、特定できるメトリックとログのみを収集します。

• インシデントの生成またはアップストリーム監視のために、既存の IT サービスマネジメント (ITSM) ソリューション (Remedy、ServiceNow など) との統合計画を定義します。 どのアラートを転送する必要があるか、特定のフィルター要件をサポートするためにアラートの強化が必要であるかどうか、どのように構成するかを決定します。

• 見る必要があるユーザー、表示する必要があるもの、ロールと責任に基づいて視覚化する方法を理解します。

運用管理の中核である IT 組織では、IT サービスの構築、運用、管理に関する一元的なガバナンスと厳密な委任を確立する必要があります。

初期戦略の目標

アーキテクトまたは戦略プランナーは、運用管理の初期戦略を策定する必要がある場合があります。そこでは、監視が主要な役割を果たします。 次の 4 つの結果を考慮します。

1. ネットワーク、アプリケーション、セキュリティ、仮想インフラストラクチャなど、運用環境に移行するときにクラウド運用サービスを管理します。

2. 限られたリソースを適用して、既存の監視ツール、スキル、専門知識を合理化し、クラウド監視機能を使用して複雑さを軽減します。

3. 監視ソリューション プロセスをより効率的にし、大規模な環境で速くスムーズに動作するようにし、短時間で変更できるようにします。

4. 組織でのクラウド モデルに基づく監視の計画とホストの方法を考慮します。 組織が IaaS から PaaS に、そして SaaS に移行するに従って要件を減らすことを目標として作業します。

現状を確認する

運営委員会、アーキテクト、戦略プランナーと緊密に連携することがあります。 人員、パートナー、アウトソーシング、ツール、複雑さ、ギャップ、リスクなど、システム管理の現状を評価することによって、監視戦略を策定する場合があります。 評価は、見つかった問題のセットに優先順位を付け、現在の状況を改善する主要な機会を選択するのに役立ちます。 また、1 つの重要な結果としてオンプレミスに残す可能性が高いサービス、システム、データも決定します。 理想的には、経営陣はイニシアティブのロードマップを要求しますが、既知の計画期間に正比例します。 不明な点について議論することも同様に重要です。

高レベルのモデリング

ビジネスでクラウドに移行するサービスを決定するときは、リソースを慎重に投資する必要があります。 オンプレミスの場合、監視に関するすべての責任を負い、多額の投資が必要です。 たとえば、SaaS サービスへの移行によって監視の責任がなくなるわけではありません。 アクセスを必要とするユーザー、アラートを受け取るユーザー、少なくとも分析へのアクセスが必要なユーザーを決定します。 Azure Monitor と Azure Arc は、Azure 内のリソースだけでなく、4 つのクラウド モデルすべてを監視するシナリオに対応できる柔軟性を備えたサービスです。 次に示すように、一般的なクラウド モデルを超えて考えてください。 Microsoft 365 サービスによって提供される Microsoft Office アプリケーションの場合、Microsoft Defender for Cloud に加えて、Microsoft 365 を使用したセキュリティとコンプライアンスの監視を含める必要があります。 企業ネットワークの外部にある ID、エンドポイント管理、デバイスの監視を含める必要があります。

監視通知の戦略

多くの戦略決定では、初期の監視データに依存して、限られたリソースをガイドし、信頼性を向上させる機能のロードマップを構築します。 また、サービスの有効化の監視からの実際の入力も必要になります。

デジタル資産を段階的に保護し、セキュリティで保護するための戦略における監視の役割を検討します。

• アクティビティ ログとセキュリティの監視は、ディレクトリの使用状況と機密コンテンツの外部共有を測定したり、保護機能のレイヤーを追加する漸進的なアプローチを通知したり、プライバシー監視との適切なバランスを実現するために必要です。

• ポリシーとベースラインでは、合理化の目標 (移行、リフト アンド シフト、または再設計) が伝えられ、データと情報をオンプレミスからクラウド サービスに移行できるという信頼度が向上します。

このガイドの後半では、導入を促進するための一般的な監視シナリオやユース ケースについて説明します。

監視アーキテクチャを策定する

監視のために現在および将来のアーキテクチャを次のように定義します。

• リソースが限られている場合は、監視への投資を統合します。

• ビジネスで必要な将来のサービスを有効にするのに監視がどのように役立つかを決定します。

• クラウドで監視する将来のサービスとリソースに合わせます。

• 正常性モデルの 3 つのディメンション (深さ、幅、および全体) 間の監視のギャップを特定します。

• コスト効果分析をサポートする財務面、コスト、サポート要因をモデル化します。

• 行う必要のあるハイブリッドの決定についてガイドします。

監視の原則の 1 つは、サービスの可視性です。 サービス、資産、またはコンポーネントが完全に表示されるようにするには、この原則の次の 3 つの側面のバランスを取る必要があります。

1. 意味のある関連シグナルを収集して、詳細に監視します。
2. スタックの最下層からアプリケーションまで、エンド ツー エンドの範囲を監視する。
3. 正常性の側面 (可用性、パフォーマンス、セキュリティ、継続性) に重点を置いて East to West を監視します。

主な質問は次のとおりです。

• セキュリティ ログをどのように共有し、アクセスを保護しますか?

• どのサービスをグローバルに利用できるようにし、サービス エッジでグローバルに監視できるようにしますか?

• 問題がシステムにあるのかクラウド プロバイダーにあるのかを示すために、ネットワーク インフラストラクチャ間のネットワーク ポイントと、サービスおよびアプリケーション エンドポイントへのネットワーク接続についてはどうですか?

• セキュリティ運用と正常性およびパフォーマンスの境界は何ですか? 正常性と状態の概要をセキュリティ運用に提供し、サービス所有者にこれを戻すには、どうすればよいでしょうか?

このアーキテクチャを構築するための考慮事項は次のとおりです。

• サービス資産から始まり、スタック (インフラストラクチャ、IoT デバイス、モバイル デバイスなどによって生成されるメトリックとログ データ) に至るデータフロー アプローチを検討してください。 すべての項目が管理から監視までのツール (中間層) の対象ですか? 上方外側 (ITSM ツール、グローバル監視、セキュリティ情報とイベント管理 (SIEM)、カスタム アラート強化など) に移動します。

• Systems Center Operations Manager または他の監視ツールを引き続き使用するかどうか。

• 経済コスト。

• ビジネスでログとメトリックをどのように使用するか。 Azure Monitor では、セキュリティ操作エクスペリエンスと同様に、監視のパフォーマンスと正常性の側に大量のログと時系列データが取り込まれます。 ログとメトリックは、Azure Monitor アーキテクチャの 2 つの主要なデータ コンポーネントです。 これらは次の理由で重要です。

  1. 大規模で複雑なクラウド サービスを構築できるため、問題管理コストが削減されます。 問題の原因を 1 か所で分析、関連付け、特定できるため、リソースに直接アクセスする必要性が減り、セキュリティが向上します。

  2. SIEM と同様に、Azure Monitor によって、オンプレミスの資産と Azure リソース (アクティビティ ログ、テナントとサブスクリプションのデータ、REST クライアントからのすべてのログ データなど) からのマシン データが統合されます。 クエリ言語を使用して、これまでよりはるかに詳細なデータ分析を行えます。

データ フローとツールを検討します。

• ソースと種類: テレメトリ、トレース、ステートフル、時系列。

• ツールとスイート (行): 列: 可用性、容量、セキュリティ、継続性、コンプライアンス。

• グローバル監視または最上位層の役割。

• 重要なイベントに対してトリガーする ITSM 統合の役割。

アラートと通知を促進するイベントの重要性について、ガバナンス計画で単一のポリシーを検討してください。 これは、監視戦略における重要なポリシーの 1 つです。 次の表は、通知に使用されるイベント、重要性、アラートを標準化するためのインシデント管理優先度モデルの例です。

イニシアティブを策定する

監視の専門家またはシステム管理者は、クラウド監視の確立がより迅速かつ簡単になると、デモや価値の証明を低コストで実現できることに気付きました。 デモ モードのままになる傾向を克服するには、戦略を常に検討し、運用に重点を置いた監視計画を実行できるようにする必要があります。 戦略には多くの不確実性と不確定性があるため、すべての監視要件を事前に把握することはできません。 そのため、ビジネスと IT 管理に対して最小限の実行可能なプランに基づいて、導入計画の最初のセットを決定します。 これは、"作業を開始するために必要な" 機能と呼ぶことができます。 作業の進行を宣言するのに役立つ 2 つのイニシアティブの例を次に示します。

• イニシアティブ 1: 現在の監視投資の多様性と複雑さを軽減するために、同じスキルと準備がクラウド監視の他の領域にも適用されることを考慮して、最初に Azure Monitor を使用したコア機能の確立に投資します。

• イニシアティブ 2: ID、アクセス、全体的な情報の保護にライセンス プランを使用する方法を決定するために、セキュリティとプライバシーの部門がクラウドに移行する際のユーザーとコンテンツの初期アクティビティ監視を確立し、分類ラベル、データ損失防止、暗号化、および保持ポリシーに関する疑問点の明確化を支援します。

スケールを検討する

戦略のスケールと、"監視をコードとして" 定義して標準化する担当者を検討します。 組織では、次のようなツールの組み合わせを使用して、標準化されたソリューションの構築を計画する必要があります。

• Azure Resource Manager のテンプレート。
• Azure Policy の監視イニシアティブの定義とポリシー。
• スクリプト、コード、ドキュメントのソース管理を確立する GitHub。

プライバシーとセキュリティを検討する

Azure では、リソースとコントロール プレーン アクションによって生成され、Azure で記録される特定の監視データ (アクティビティ ログと呼ばれます) をセキュリティで保護する必要があります。 さらに、Microsoft Entra のサインインや監査ログ、統合されている場合は Microsoft 365 統合監査ログなど、ユーザー アクティビティを記録する特殊なログにはすべて、場合によってはプライバシーに関する法律で保護する必要がある機密データが含まれています。

監視戦略には、次のアクションを含める必要があります。

• 監視データから非監視データを分離します。
• リソースへのアクセスを制限します。

ビジネス継続性を検討する

Azure Monitor では、運用をサポートし、ビジネス上の意思決定を促進するために、マシンとリソースによって生成されるデータの収集、インデックス作成、分析がリアルタイムで行われます。 まれに、1 つのリージョン全体の施設がネットワーク障害などでアクセスできなくなることがあります。 また、自然災害などにより、施設が完全に失われることもあります。 これらのサービスはクラウドに移行されたため、計画の重点をインフラストラクチャの回復性と高可用性に置く代わりに、 以下について計画します。

• Azure 内のすべての依存サービスとリソース、他のクラウド内のリソース、オンプレミスからのデータ インジェストの可用性。
• 分析情報、ソリューション、ブック、その他の視覚化、アラート、ITSM との統合、および運用要件をサポートする Azure 内の他のコントロール プレーン サービスに関するデータの可用性。

復旧計画を作成し、データの復元、ネットワーク障害、依存サービスのエラー、およびリージョン全体にわたるサービス中断がその計画で網羅されていることを確認します。

成熟度を検討する

監視戦略が拡大し、進化します。 データを収集することから始めることをお勧めします。これは、戦略を決定するのに役立ちます。 最初に必要な監視ソリューションは、インシデントと問題管理などの応答性の高いプロセスを含めるために、監視を保証するソリューションです。

• 1 つ以上の Log Analytics ワークスペースを作成します。

• エージェントを有効にします。

• リソース診断の設定を有効にします。

• 初期アラート ルールを有効にします。

Azure Monitor の機能に自信が持てるようになったら、ログの収集に重点を置き、分析情報とメトリックを有効にして使用し、正常か異常かの測定と計算を促進するログ検索クエリを定義して、正常性インジケーターの測定を開始できます。

学習サイクルの一環として、監視データと分析情報をマネージャーに渡し、適切なコンシューマーが必要な監視データを確実に入手できるようにします。 学習サイクルには、適応させ、サービスを向上させ、導入計画を伝えるための、初期監視計画の継続的な調整と最適化が含まれます。

DIKW モデルは、学習によく使用されます。 アクションと意思決定は、"データ" から "情報"、"知識"、"知恵" に移行します。

監視は、Azure で構築するサービスの基礎となります。 戦略では、最新の監視に関する 5 つの規範に対処できます。これにより、実行可能な最小の監視を定義し、手順の信頼性を高めることができます。 ただし、機能をリアクティブからプロアクティブに移行し、その範囲をエンドユーザーに拡張することは、1 つの目標です。

• 監視: まず、監視を確立して、Azure のサービスとリソースの正常性と状態を観察する必要があります。 基本的な監視を構成し、Azure Policy と Azure Resource Manager テンプレートを使用して自動化します。これにより、サービスの初期表示とその保証 (可用性、パフォーマンス、容量、セキュリティ、および構成のコンプライアンス) が確立されます。 たとえば、Azure Monitor の実行可能な最小のセットアップに基づいて、監視と診断のためのリソースを構成し、アラートと分析情報を設定します。 インシデントや問題などのサービス作業のために、コンシューマーの監視およびイベントの定義とトリガーに関する知識と対応状況を含めます。 成熟度の 1 つの指標は、正常性と状態を手動で監視する不要な人的コストを削減するために自動化できる量です。 正常なサービスを把握することは、問題のあるサービスについてのアラートを受け取るのと同じくらい重要です。

• 測定する: 問題である兆候や状況を監視するために、すべてのリソースからのメトリックとログの収集を構成します。これにより、サービスの可用性に対する潜在的な影響や実際の影響、またはサービスやアプリケーションのコンシューマーの影響が示されます。 次に例を示します。

  • アプリケーションの機能を使用したとき、応答まで時間がかかったり、何かを選択したときにエラーが返されたり、応答しなくなったりすることがありますか。

  • サービスまたはアプリケーションの実用性を測定して、サービスがサービス契約を満たしていることを確認します。

• 対応する: 監視と測定に関する既知の問題のコンテキストに基づいて、バグに該当するもの、自動修復されるもの、またはインシデント、問題、または変更として分類された内容に基づいて手動による対応を必要とするものを評価します。

• 学習と改善: これら 2 つの相互に依存する規範により、プロバイダーとコンシューマーは学習サイクルに参加します。 分析情報、レポート、ブックを通じて監視データを使用します。 これらの方法を用いて監視構成を調整および最適化し、ターゲット サービスを継続的に改善します。 変更も重要です。 監視構成は、サービス保証を進化させるために、ビジネス、テクノロジ、クラウド プロバイダー、その他のサービスの変更と共に変化しています。

監視計画と戦略を整合させるには、次の表を使用して、発生するさまざまな監視シナリオをより詳細に分類します。 計画フェーズで以前に導入した合理化の "5 つの R" を念頭に置いてください。 System Center Operations Manager を使用している場合は、投資を合理化するためにハイブリッドおよびクラウド オプションを利用できます。

監視要件を策定する

このプロセスを進めていくと、最終的にやるべきことがたくさんあることが戦略から明らかになるかもしれません。 最終的には、監視を企業ネットワークを超えて職場、デバイスとエンドポイント、さらにはセキュリティとしての ID の境界まで拡張する必要があります。 クラウド監視で定義された新しいエッジは、データセンターとワークプレースの考え方とは対照的な、強力な動機付けになります。

オンプレミスに留まるサービスに対しても、Azure を使用してオンプレミス リソースのすべてまたは一部の側面を段階的に管理できます。 また、ビジネスで採用されているクラウド サービス モデルに基づいて、ビジネスのクラウド導入戦略に合わせて、責任の監視範囲も戦略で定義します。 IaaS に基づくサービスの場合でも、Azure Service Health 通じてメトリック、ログ、ビュー、アラートの機能を取得できます。 リソース正常性を使用して、Azure リソースの可用性の監視からアラートを構成できます。 Microsoft 365 などの SaaS サービスでは、多くは既に提供されており、ポータル、ダッシュボード、分析、アラートへの適切なアクセスを構成する必要があります。 サービスの観点から見ると、Microsoft 365 Exchange Online などの分散コンポーネントを含む大規模なサービスには、その正常性と状態を監視する必要性だけでなく、多くの目標があります。

アジャイルなソリューションのリリース

最終的に、監視構成またはソリューションを運用環境に提供します。 コンシューマー、マネージャー、IT 運用部門とのコミュニケーションを改善するために、標準的で単純な分類法を検討してください。 アジャイルな DevOps アプローチにより、クラウド サービスを構築および運用するチームに監視を組み込むことができます。 従来のプロジェクト管理も機能しますが、運用チームの標準プラクティスとしては速さが十分でなく、通常は受け入れられません。

監視計画、目標、および構成 (ソリューション) の通信方法を戦略および運用モデルに含めます。 たとえば、Azure Boards を使用する方法を次に示します。

最小限のガバナンスを確立する

できるだけ早く、クラウド監視への投資をどのように管理するかを決定します。 Azure Monitor は、管理グループとサブスクリプション全体の可視性を備えた "テナント" サービスであり、Azure のロールベースのアクセス制御によってユーザー特権を制限できることに注意してください。

ユーザーが自分のロールと責任をサポートするために Azure で持つアクセスのレベルを定義します。 コンシューマーを監視するための閲覧者ロールのアクセスをできるだけ早く設定してから、共同作成者ロールを付与するユーザーを制御する必要があります。

まず、ガバナンス フレームワークの一部として、Azure のリソース グループを所有および管理するロールを特定します。

• 監視チーム、またはリソースとリソース グループの 1 人または複数の管理者が、監視共同作成者ロールに対する特権アクセスを持つかどうかを決定します。

• Azure Monitor の機能へのアクセスを可能にする監視閲覧者ロールを付与する必要があるコンシューマーを選び、各 Azure リソースに含まれる監視セクション内の問題を調査します。

• レポート閲覧者ロールなど、他の Azure 閲覧者ロールへのアクセスを必要とするマネージャーを選びます。

まとめると、監視コンシューマーのロールでは広範なアクセスを必要とする場合があるのに対し、開発者やシステム管理者は特定の Azure リソースに対するロール ベースのアクセスだけが必要です。 その他の制限として、セキュリティ、サインイン、ユーザー アクティビティ ログなどの機密監視データへのアクセスから、閲覧者を除外するようにしてください。

準備を確立する

初期段階で、IT スタッフが Azure のクラウド監視に関する新しいスキル、プラクティス、および手法を採用するための準備計画を策定します。 スキルの準備のガイダンスを検討してください。

次のステップ