Azure Monitor の信頼性のベスト プラクティス

クラウドでは、障害が発生することを認識しています。 目標は、障害がまったく発生しないように努力することではなく、障害が発生した単一コンポーネントの影響を最小限に抑えることです。 次の情報を使用して、仮想マシンとそのクライアント ワークロードの障害を監視します。

この記事では、Azure Well-Architected Framework の一部としての Azure Monitor の信頼性について説明します。 Azure Well-Architected Framework は、ワークロードの品質向上に使用できる一連の基本原則です。 このフレームワークは、優れたアーキテクチャの 5 つの柱で構成されています。

• 信頼性
• 安全
• コストの最適化
• オペレーショナル エクセレンス
• パフォーマンス効率

Azure Monitor ログ

Log Analytics ワークスペースは、高い信頼性を提供します。 インジェスト パイプラインによって、収集されたデータが Log Analytics ワークスペースに送信されますが、このパイプラインでは各ログ レコードが Log Analytics ワークスペースによって正常に処理されたことが検証された後に、そのレコードがパイプから削除されます。 このインジェスト パイプラインが使用できない場合は、データを送信するエージェントがログをバッファーに入れて、送信を何時間も再試行します。

回復性を高める Azure Monitor ログの機能

Azure Monitor ログには、さまざまな種類の問題に対するワークスペースの回復性を高める多数の機能があります。 これらの機能は、ニーズに応じて個別に使うことも、組み合わせて使うこともできます。

このビデオでは、Log Analytics ワークスペースで使用できる信頼性と回復性のオプションの概要について説明します。

可用性ゾーンを使用するリージョン内保護

可用性ゾーンをサポートする Azure リージョンのそれぞれに一連のデータセンターがあり、これらは独立した電源、冷却、およびネットワークのインフラストラクチャを備えています。

Azure Monitor ログの可用性ゾーンは冗長です。つまり、Microsoft はサポートされているリージョン内のさまざまなゾーンにサービス要求を分散させるとともに、データをこれらのゾーン間でレプリケートしています。 インシデントが 1 つのゾーンに影響を与える場合は、Microsoft はリージョン内の別の可用性ゾーンを自動的に使用します。 ゾーン間の切り替えはシームレスであるため、アクションを実行する必要はありません。

ほとんどのリージョンの Azure Monitor ログ可用性ゾーンでデータの回復性がサポートされています。つまり、お客様が保存したデータは、ゾーンレベルの障害に関連するデータ損失から保護されます。ただしこの場合も、サービス オペレーションはリージョンレベルのインシデントの影響を受ける可能性があります。 サービスがクエリを実行できない場合は、その問題が解決されるまでお客様はログを見ることができません。

データの回復性がサポートされる可用性ゾーンでは、サービスの回復性もサポートされます。つまり、Azure Monitor ログのサービス オペレーション、たとえばログ インジェスト、クエリ、アラートなどは、ゾーン障害が発生した場合でも続行できます。

可用性ゾーンによる保護の対象は、インフラストラクチャ関連のインシデント (たとえばストレージ障害) です。 障害のあるコードのデプロイや証明書の障害など、リージョン全体に影響を与えるアプリケーション レベルの問題から保護されません。

連続エクスポートを使用して特定テーブルからのデータをバックアップする

Log Analytics ワークスペース内の特定のテーブルに送信されたデータを Azure ストレージ アカウントに連続エクスポートすることができます。

データのエクスポート先となるストレージ アカウントは、Log Analytics ワークスペースと同じリージョンに存在している必要があります。 取り込み済みのログを保護して、ワークスペースのリージョンがダウンしている場合でもアクセスできるようにするには、構成の推奨事項で説明している geo 冗長ストレージ アカウントを使用します。

エクスポート メカニズムでは、インジェスト パイプラインまたはエクスポート プロセス自体に影響を与えるインシデントからの保護は提供されません。

注

ストレージ アカウント内のデータに Azure Monitor ログからアクセスするには、externaldata 演算子を使用します。 ただし、エクスポートされたデータは 5 分間の BLOB に格納され、複数の BLOB にまたがるデータの分析には手間がかかることがあります。 したがって、データをストレージ アカウントにエクスポートすることはデータ バックアップのメカニズムとして優れているものの、バックアップ済みのデータをストレージ アカウントで保存しておくことは、そのデータが Azure Monitor ログでの分析に必要な場合は理想的とはいえません。 大量の BLOB データに対してクエリを実行するには、Azure Data Explorer、Azure Data Factory、またはその他の任意のストレージ アクセス ツールを使用できます。

ワークスペース レプリケーションを使用したリージョン間のデータ保護とサービスの回復性

ワークスペース レプリケーションは、Log Analytics ワークスペースと受信ログを別のリージョンにレプリケートするため、最も広範な回復性ソリューションです。

ワークスペース レプリケーションによって、ログとサービス オペレーションの両方が保護されます。また、インフラストラクチャまたはアプリケーション関連の、リージョン全体に影響するインシデントが発生した場合でもシステムの監視を続行できます。

Microsoft がエンドツーエンドで管理する可用性ゾーンとは対照的に、お客様自身でプライマリ ワークスペースの正常性を監視して、いつワークスペースをセカンダリ リージョンに切り替えていつ戻すかを決定する必要があります。

設計チェックリスト

• リージョン全体に影響するインシデントに対するサービスとデータの回復性を確実にするには、ワークスペース レプリケーションを有効にしてください。
• データセンターの障害に対するリージョン内保護を確実にするには、可用性ゾーンをサポートするリージョン内にワークスペースを作成します。
• 特定のテーブル内のデータのクロスリージョン バックアップを行うには、連続エクスポート機能を使用して、geo レプリケートされるストレージ アカウントにデータを送信します。
• Log Analytics ワークスペースの正常性を監視します。

構成に関する推奨事項

勧告	メリット
回復性を最大限に高めるには、ワークスペース レプリケーションを有効にします。	ワークスペースのデータとサービス オペレーションに対するクロスリージョン回復性。 ワークスペース レプリケーション では、別のリージョンにワークスペースのセカンダリ インスタンスを作成し、両方のワークスペースにログを取り込むことで、高可用性が確保されます。 必要に応じて、プライマリ ワークスペースに影響する問題が解決するまでの間、セカンダリ ワークスペースに切り替えます。 ログの取り込み、データに対するクエリ実行、ダッシュボード、アラート、Sentinel の使用は引き続きセカンダリ ワークスペースで行うことができます。 また、リージョン切り替え前に取り込まれたログにもアクセスできます。 これは有料機能であるため、受信したログすべてと一部のデータ ストリームのみの、どちらのレプリケートが必要かを検討してください。
可能であれば、Azure Monitor サービス回復性をサポートするリージョン内にワークスペースを作成します。	データセンターの問題が発生した場合のワークスペース データとサービス オペレーションのリージョン内回復性。 サービスの回復性をサポートする可用性ゾーンでは、データの回復性もサポートされます。 つまり、あるデータセンター全体が使用不可になった場合でも、ゾーン間で冗長であるため、Azure Monitor のサービス オペレーション (インジェストやクエリ実行など) は引き続き機能し、取り込み済みのログも引き続き使用可能になります。 可用性ゾーンによってリージョン内保護が可能になりますが、リージョン全体に影響を与える問題からの保護はできません。 どのリージョンでデータの回復性がサポートされているかについては、「可用性ゾーンを使用して Azure Monitor ログのデータとサービスの回復性を強化する」を参照してください。
データの回復性がサポートされるリージョン内にワークスペースを作成します。	リージョン内保護によって、データセンターの問題の発生時にワークスペース内のログの損失を防ぎます。 データの回復性がサポートされるリージョン内にワークスペースを作成すれば、データセンター全体が使用不可になった場合でも、取り込み済みのログに影響が及ぶことはありません。 サービスがクエリを実行できない場合は、その問題が解決されるまでお客様はログを見ることができません。 どのリージョンでデータの回復性がサポートされているかについては、「可用性ゾーンを使用して Azure Monitor ログのデータとサービスの回復性を強化する」を参照してください。
特定のテーブルからストレージ アカウントへのデータ エクスポートを構成し、このアカウントをリージョン間でレプリケートします。	ログ データのバックアップ コピーを別のリージョン内に保持します。 Azure Monitor のデータ エクスポート機能を使用すると、特定のテーブルに送信されたデータを Azure ストレージに継続的にエクスポートして、長期間保持することができます。 geo 冗長ストレージ (GRS) または geo ゾーン冗長ストレージ (GZRS) アカウントを使用すると、あるリージョン全体が使用不可になった場合でもデータの安全を保つことができます。 データを他のリージョンから読み取れるようにするには、セカンダリ リージョンに対する読み取りアクセス権を持つようにストレージ アカウントを構成します。 詳細については、Azure Storage のセカンダリ リージョンでの冗長性と Azure Storage のセカンダリ リージョンのデータへの読み取りアクセスに関するページを参照してください。 連続データ エクスポートがサポートされていないテーブルについては、他のデータ エクスポート方法、たとえば Logic Apps を使用してデータを保護できます。 これは主に、データの分析とワークスペースへの復元が困難な場合があるため、データ保持のコンプライアンスを満たすためのソリューションです。 データ エクスポートは、リージョン内の Azure Monitor インジェスト パイプラインの安定性に依存するため、リージョン インシデントの影響を受けやすくなります。 リージョンインジェスト パイプラインに影響を与えるインシデントに対する回復性は提供されません。
Log Analytics ワークスペースの正常性を監視します。	Log Analytics Workspace Insights を使用して障害が発生したクエリを追跡し、正常性状態アラートを作成してデータセンターまたはリージョンの障害が原因でワークスペースが利用できなくなった場合に事前に通知されます。

Azure Monitor ログの回復性機能の比較

特徴	サービスの回復性	[データ バックアップ]	高可用性	保護の範囲	セットアップ	費用
ワークスペース レプリケーション	✅	✅	✅	リージョン全体のインシデントに対するクロスリージョン保護	ワークスペースのレプリケーションと、関連するデータ収集ルールを有効にします。 必要に応じてリージョンを切り替えます。	レプリケートされる量 (GB) とリージョンに基づきます。
可用性ゾーン	✅ サポートされているリージョンで	✅	✅	データセンターの問題に対するリージョン内保護	サポートされているリージョンでは自動的に有効になります。	コストなし
継続的データ エクスポート		✅		リージョン障害が原因のデータ損失からの保護1	テーブルごとに有効にします。	データ エクスポート + ストレージ BLOB または Event Hubs のコスト

¹ データ エクスポートによってクロスリージョン保護が可能になるのは、geo レプリケートされるストレージ アカウントにログをエクスポートする場合です。 インシデントが発生した場合、以前にエクスポートされたデータがバックアップされ、すぐに使用できるようになります。ただし、インシデントの性質によっては、追加のエクスポートが失敗する可能性があります。

アラート

Azure Monitor アラートは、設計上の決定なしに高度な信頼性を提供します。 アラート データの一時的な損失が発生する可能性がある条件は、多くの場合、他の Azure Monitor コンポーネントの機能によって軽減されます。

設計チェックリスト

• サービス正常性アラート ルールを構成する。
• リソース正常性アラート ルールを構成する。
• 大規模な通知を生成するアラート ルールのサービス制限を回避する。

構成に関する推奨事項

勧告	メリット
サービス正常性アラート ルールを構成する。	サービス正常性アラートは、停止、サービス中断、計画メンテナンス、およびセキュリティ アドバイザリに関する通知を送信します。 詳細については、「Azure portal を使用して Service Health アラートを作成する」を参照してください。
リソース正常性アラート ルールを構成する。	Resource Health アラートでは、これらのリソースの正常性状態が変化すると、ほぼリアルタイムで通知できます。 詳細については、 Azure portal での Resource Health アラートの作成に関するページを参照してください。
大規模な通知を生成するアラート ルールのサービス制限を回避する。	大量の通知を送信するアラート ルールがある場合は、メールまたは SMS 通知の送信に使用するサービスのサービス制限に達する可能性があります。 プログラムによるアクションを構成するか、大規模な通知を処理する別の通知方法またはプロバイダーを選択します。 詳細については、「 通知のサービス制限」を参照してください。

仮想マシン

設計チェックリスト

• Azure VM 用の可用性アラート ルールを作成します。
• エージェントの正常性を確認するためのエージェント ハートビート アラート ルールを作成します。
• クライアント ワークフローの信頼性を監視するために、データ収集とアラートを構成します。

構成に関する推奨事項

勧告	説明
Azure VM 用の可用性アラート ルールを作成します。	可用性メトリック (プレビュー) を使用して、Azure VM が実行されているタイミングを追跡します。 推奨されるアラートを使用して個々のマシンの可用性アラート ルールをすばやく有効にすることができますが、リソース グループまたはサブスクリプションを対象とする 1 つのアラート ルールを使用すると、特定のリージョンのそのスコープ内のすべての VM に対して可用性アラートを有効にすることができます。 これにより、VM ごとにアラート ルールを作成するよりも管理が簡単で、スコープ内に作成された新しい VM が自動的に監視されるようになります。 このアラート ルールでは、Azure Monitor エージェントを VM にインストールする必要はありませんが、Azure 以外の VM では使用できません。
エージェントの正常性を確認するためのエージェント ハートビート アラート ルールを作成します。	Azure Monitor エージェントは、毎分 Log Analytics ワークスペースにハートビートを送信します。 エージェントのハートビートを使用したログ検索アラート ルールを使って、エージェントがハートビートの送信を停止したときにアラートを受け取ります。これは、VM がダウンしているか、エージェントが異常であり、クライアント ワークロードが監視されていないことを示しています。 このアラート ルールでは、Azure Monitor エージェントが VM にインストールされ、Azure VM と Azure 以外の VM の両方に適用される必要があります。
クライアント ワークフローの信頼性を監視するために、データ収集とアラートを構成します。	「Azure Monitor を使用して仮想マシンを監視する: データを収集する」の情報を使用して、クライアント ワークロードの潜在的な問題を示すクライアント イベント収集を構成します。 「Azure Monitor を使用した仮想マシンの監視: アラート」の情報を使用して、クライアント ワークロードの潜在的な運用上の問題を事前に通知するアラート ルールを作成します。

コンテナー

設計チェックリスト

• クラスターに対して Prometheus メトリックのスクレイピングを有効にする。
• クラスターからログとパフォーマンス データを収集するために Container Insights を有効にする。
• 診断設定を作成して、AKS クラスターのコントロール プレーン ログを収集する。
• 推奨される Prometheus アラートを有効にする。
• Container Insights をサポートする Log Analytics ワークスペースの可用性を確保する。

構成に関する推奨事項

勧告	メリット
クラスターに対して Prometheus メトリックのスクレイピングを有効にする。	Prometheus 環境がまだない場合は、Prometheus 用の Azure Monitor マネージド サービスを使用して、クラスターで Prometheus を有効にします。 Azure Managed Grafana を使用して、収集された Prometheus データを分析します。 既定の構成を超えて追加のメトリックを収集する場合は、「Prometheus 用 Azure Monitor マネージド サービスで Prometheus メトリックのスクレイピングをカスタマイズする」を参照してください。
クラスターからログとパフォーマンス データを収集するために Container Insights を有効にする。	Container Insights では、クラスター内の各ノードから stdout/stderr ログ、パフォーマンス メトリック、および Kubernetes イベントが収集されます。 ノードやその他のコンポーネントの可用性など、このデータを分析するためのダッシュボードとレポートが提供されます。 Log Analytics を使用して、収集したログの可用性エラーを特定します。
診断設定を作成して、AKS クラスターのコントロール プレーン ログを収集する。	AKS では、Azure Monitor のリソース ログとしてコントロール プレーン ログが実装されます。 診断設定を作成して、これらのログを Log Analytics ワークスペースに送信し、ログ クエリを使って可用性に影響するエラーや問題を特定できるようにします。
推奨される Prometheus アラートを有効にする。	Azure Monitor のアラートにより、問題が検出されたときに事前に通知されます。 クラスターで最も一般的な可用性とパフォーマンスの問題を検出する一連の推奨される Prometheus アラート ルールから始めます。 Container Insights によって収集されたデータを使用して、ログ検索アラートを追加する可能性があります。
Container Insights をサポートする Log Analytics ワークスペースの可用性を確保する。	Container Insights は、Log Analytics ワークスペースに依存します。 ワークスペースの信頼性を確保するための推奨事項については、「Azure Monitor ログのベスト プラクティス」を参照してください。

次のステップ

• Azure Monitor の概要について詳しくは、こちらをご覧ください。