次の方法で共有

特定の Azure サービスの回復性のチェックリスト

回復性とは、障害から回復して動作を続行する、システムの能力です。 各テクノロジには独自の障害モードがあり、アプリケーションの設計および実装の際に考慮する必要があります。 このチェックリストを使用して、個々の Azure サービスの回復性の考慮事項を確認します。 回復性のあるアプリケーションの設計の詳細については、「 信頼性の高い Azure アプリケーションの設計」を参照してください。

アプリサービス

Standard または Premium レベルを使用します。 これらの階層は、ステージング スロットと自動バックアップをサポートします。 詳細については、Azure App Service プランの詳細な概要に関するページを参照してください。

スケールアップまたはスケールダウンを回避します｡ 代わりに、一般的な負荷の下でパフォーマンス要件を満たす層とインスタンス サイズを選択し、トラフィック 量の変化を処理するためにインスタンスを スケールアウト します。 スケールアップとスケールダウンにより、アプリケーションの再起動がトリガーされることがあります。

構成をアプリ設定として格納します。 アプリ設定を使用して、構成設定をアプリケーション設定として格納してください。 Resource Manager テンプレートに、または PowerShell 使用して設定を定義して、それを自動化されたデプロイや更新プロセスの一部として適用できるようにしてください。それによって信頼性が向上します。 詳細については、「 Azure App Service で Web アプリを構成する」を参照してください。

運用とテスト用に別々の App Service プランを作成します。 テストには運用環境のデプロイのスロットを使用しないでください。 同じ App Service プラン内のすべてのアプリが同じ VM インスタンスを共有します。 運用デプロイとテスト デプロイを同じプランに入れると、運用デプロイに悪影響を与える可能性があります。 たとえば、ロード テストは実稼働の運用サイトの機能を低下させる可能性があります。 テスト デプロイを別のプランに入れて、運用バージョンから切り離してください。

Web アプリから Web API を分離します。 ソリューションに Web フロントエンドと Web API の両方がある場合は、それらを別々の App Service アプリに分解することを検討してください。 この設計により、ソリューションをワークロード別に分解しやすくなります。 Web アプリと API を別々の App Service プランで実行できるため、それらを個別にスケーリングできるようになります。 最初はこのレベルのスケーラビリティが不要な場合は、アプリを同じプランにデプロイし、後で必要に応じて別のプランに移行することができます。

ゾーン冗長のアプリ サービス プランをデプロイします。 サポートされているリージョンでは、App Service プランをゾーン冗長としてデプロイできます。つまり、インスタンスは可用性ゾーン間で自動的に分散されます。 App Service はゾーン間でトラフィックを自動的に分散し、ゾーンで障害が発生した場合はフェールオーバーを処理します。 詳細については、「 App Service を可用性ゾーンのサポートに移行する」を参照してください。

Azure SQL データベースをバックアップするのに App Service バックアップ機能を使用しないでください。 代わりに、 SQL Database の自動バックアップを使用してください。 App Service のバックアップでは、データベースを SQL BACPAC ファイルにエクスポートします。DTU のコストがかかります。

ステージング スロットにデプロイします。 ステージング用のデプロイ スロットを作成します。 アプリケーションの更新プログラムをステージング スロットにデプロイし、運用環境にスワップする前にデプロイを確認してください。 これにより、運用環境で不正な更新が発生する可能性が減少します。 また、すべてのインスタンスが、運用環境にスワップする前に確実にウォーム アップされます。 ウォームアップとコールドスタートに時間がかかるアプリケーションは多数あります。 詳細については、「 Azure App Service で Web アプリのステージング環境を設定する」を参照してください。

前回正常起動時 (LKG) のデプロイを保持するデプロイ スロットを作成します。 運用環境に更新プログラムをデプロイするときは、以前の運用環境のデプロイを LKG スロットに移動してください。 これにより、不適切なデプロイをより簡単にロールバックできます。 後で問題を見つけた場合は、LKG バージョンにすばやく戻ることができます。 詳細については、「 基本的な Web アプリケーション」を参照してください。

アプリケーション のログ記録や Web サーバーのログ記録など、診断ログを有効にします。 監視と診断にはログ記録が重要です。 「Azure App Service で Web アプリの診断ログを有効にする」を参照してください

Blob Storage にログを記録します。 これによって、データの収集と分析が簡単になります。

ログ用の別のストレージ アカウントを作成します。 ログとアプリケーション データに同じストレージ アカウントを使用しないでください。 これは、ログ記録によってアプリケーションのパフォーマンスが低下するのを防ぐのに役立ちます。

パフォーマンスを監視する。 New Relic や Application Insights などのパフォーマンス監視サービスを使用して、負荷がかかったアプリケーションのパフォーマンスと動作を監視します。 パフォーマンスの監視により、アプリケーションをリアルタイムで理解できます。 これにより、問題を診断し、障害の根本原因分析を行うことができます。

Azure Load Balancer（アジュールロードバランサー）

Standard SKU を選択します。 Standard Load Balancer は、Basic では提供されない、信頼性のディメンション (可用性ゾーンとゾーンの回復性) を提供します。 つまり、あるゾーンがダウンしても、ゾーンの冗長性を備えた Standard Load Balancer が影響を受けることはありません。 これにより、デプロイがリージョン内のゾーン障害に耐えられるようになります。 さらに、Standard Load Balancer はグローバルな負荷分散をサポートしているため、リージョンで障害が発生してもアプリケーションが影響を受けることはありません。

少なくとも 2 つのインスタンスをプロビジョニングします。 バックエンドに少なくとも 2 つのインスタンスを持つ Azure Load Balancer をデプロイします。 単一のインスタンスが、単一障害点を引き起こす可能性があります。 スケールを構築するために、Load Balancer と Virtual Machine Scale Sets をペアにすることが推奨されます。

アウトバウンド規則を使用します。 アウトバウンド規則を使用することで、送信元ネットワーク アドレス変換 (SNAT) ポートが枯渇することによって生じる接続エラーが発生しないようにすることができます。 送信接続の詳細を確認します。 送信規則は小規模から中規模のデプロイのソリューションを改善するのに役立ちますが、運用環境のワークロードでは、Standard ロード バランサーまたはサブネットデプロイと VNet ネットワーク アドレス変換 (NAT) を結合することをお勧めします。

Azure 公開 IP

Standard SKU を選択します。 Standard パブリック IP には、Basic パブリック IP とは異なり、可用性ゾーンとゾーンの回復性があります。 パブリック IP が必要なサービスを使用する場合は、ゾーン冗長パブリック IP を選択します。 既存の IP の場合は、既定 でゾーン冗長の利点を得るために、それらを Basic から Standard にアップグレードします。

アプリケーション ゲートウェイ

少なくとも 2 つのインスタンスをプロビジョニングします。 少なくとも 2 つのインスタンスのある Application Gateway をデプロイしてください。 単一のインスタンスは、単一障害点です。 冗長性とスケーラビリティのために、2 つ以上のインスタンスを使用してください。 サービス レベル アグリーメント (SLA) の対象にするには、2 つ以上の中規模以上のインスタンスをプロビジョニングする必要があります。

Azure Cosmos DB (アジュール コスモス データベース)

ゾーン冗長を構成します。 ゾーン冗長を使用すると、Azure Cosmos DB は可用性ゾーン間ですべての書き込みを同期的にレプリケートします。 ゾーンが停止した場合は、自動的にフェールオーバーされます。 詳細については、「 Azure Cosmos DB を使用した高可用性の実現」を参照してください。

リージョン間でデータベースをレプリケートします。 Azure Cosmos DB では、Azure Cosmos DB データベース アカウントに Azure リージョンをいくつでも関連付けることができます。 Azure Cosmos DB データベースには、1 つの書き込みリージョンと複数の読み取りリージョンを含めることができます。 書き込みリージョンに障害がある場合は、別のレプリカから読み取ることができます。 クライアント SDK はこれを自動的に処理します。 書き込みリージョンを別のリージョンにフェールオーバーすることもできます。 詳細については、「 Azure Cosmos DB を使用してデータをグローバルに分散する方法」を参照してください。

イベント ハブ

チェックポイントを使用します。 イベント コンシューマーは、事前定義された間隔で永続的ストレージに現在位置を書き込む必要があります。 このように、コンシューマーで障害が発生した場合 (たとえば、コンシューマーがクラッシュした場合や、ホストに障害が発生した場合)、新しいインスタンスは最後に記録された位置からストリームの読み取りを再開できます。 詳細については、「 イベント コンシューマー」を参照してください。

重複メッセージを処理します。 イベント コンシューマーに障害が発生すると、メッセージの処理は最後に記録されたチェックポイントから再開されます。 最後のチェックポイントの後で既に処理されたメッセージはすべて、再度処理されます。 したがって、メッセージ処理ロジックは同一結果を持つか、またはアプリケーションがメッセージの重複を除去できる必要があります。

例外の処理.. イベント コンシューマーは、通常、ループ内のメッセージをバッチで処理します。 1 つのメッセージによって例外が発生した場合は、メッセージのバッチ全体を失わないように、その処理ループ内の例外を処理する必要があります。

配信不能キューを使用します。 メッセージを処理した結果、一時的でないエラーが発生した場合は、状態を追跡できるように、メッセージを配信不能キューに配置します。 シナリオによっては、メッセージを後で再試行したり、補正トランザクションを適用したり、他の何らかのアクションを実行したりする可能性があります。 Event Hubs には、組み込みのデッドレターキュー機能がないことに注意してください。 Azure Queue Storage または Service Bus を使用して配信不能キューを実装したり、Azure Functions またはその他のイベント処理メカニズムを使用したりすることができます。

ゾーンの冗長性を構成します。 名前空間でゾーン冗長が有効になっている場合、Event Hubs は複数の可用性ゾーン間で変更を自動的にレプリケートします。 1 つの可用性ゾーンが失敗した場合、フェールオーバーは自動的に行われます。 詳細については、「 可用性ゾーン」を参照してください。

セカンダリ Event Hubs 名前空間にフェールオーバーして、ディザスター リカバリー (DR) を実装します。 詳しくは、Azure Event Hubs ジオディザスターリカバリー を参照してください。

Azure Cache for Redis（レディスのためのAzureキャッシュ）

ゾーン冗長を構成します。 キャッシュでゾーン冗長が有効になっている場合、Azure Cache for Redis は、キャッシュをホストする仮想マシンを複数の可用性ゾーンに分散します。 ゾーン冗長により、データセンターが停止した場合の高可用性とフォールト トレランスが提供されます。 詳細については、「 Azure Cache for Redis のゾーン冗長を有効にする」を参照してください。

ジオレプリケーションを構成します。 geo レプリケーションには、レベルが Premium である Azure Cache for Redis の 2 つのインスタンスをリンクするメカニズムが用意されています。 プライマリ キャッシュに書き込まれたデータは、読み取り専用のセカンダリ キャッシュにレプリケートされます。 詳細については、「 Azure Cache for Redis の geo レプリケーションを構成する方法」を参照してください。

データ永続化を構成します。 Redis の永続化を使用すると、Redis に格納されたデータを保持できます。 また、スナップショットを取得したりデータをバックアップしたりして、ハードウェア障害のときに読み込むことができます。 詳細については、「 Premium レベルの Azure Cache for Redis のデータ永続化を構成する方法」を参照してください。

永続ストアとしてではなく、一時的なデータ キャッシュとして Azure Cache for Redis を使用する場合、これらの推奨事項は適用されません。

複数のレプリカを用意します。 読み取りの高可用性のためには少なくとも 2 つのレプリカ、読み取り/書き込みの高可用性のためには少なくとも 3 つのレプリカを使用してください。

ゾーン冗長性を利用する。 複数の可用性ゾーンに AI Search レプリカをデプロイできます。 このアプローチは、データセンターの停止が発生した場合でもサービスを運用状態に保つのに役立ちます。 詳細については、「AI Search の信頼性」を参照してください。

複数リージョンのデプロイ用のインデクサーを構成します。 複数リージョンのデプロイがある場合は、インデックス作成の継続性のためのオプションを検討してください。

  • データ ソースが geo レプリケートされる場合は、通常、各リージョン AI Search サービスの各インデクサーをローカル データ ソース レプリカにポイントする必要があります。 ただし、このアプローチは、Azure SQL データベースに格納されている大規模なデータセットは推奨されません。 その理由は、AI Search ではセカンダリ SQL Database レプリカからの増分インデックス作成を実行できず、プライマリ レプリカからのみ実行できないためです。 代わりに、すべてのインデクサーをプライマリ レプリカにポイントしてください。 フェールオーバー後、新しいプライマリ レプリカで AI Search インデクサーをポイントします。

  • データ ソースが geo レプリケートされていない場合は、複数のインデクサーを同じデータ ソースにポイントして、複数のリージョンの AI Search サービスがデータ ソースから継続的かつ独立してインデックスを作成できるようにします。 詳細については、「 AI Search の信頼性に関する考慮事項」を参照してください。

サービスバス

運用環境のワークロードには Premium レベルを使用します。 Service Bus Premium メッセージング では、専用の予約済み処理リソースと、予測可能なパフォーマンスとスループットをサポートするメモリ容量が提供されます。 また、Premium メッセージング レベルでは、Premium のお客様だけがいち早く利用できる新機能にもアクセスできます。 予想されるワークロードに基づいて、メッセージング ユニットの数を決定できます。

重複するメッセージを処理します。 メッセージ送信後すぐにパブリッシャーで障害が発生した場合、またはネットワークやシステムで問題が発生した場合は、メッセージが配信されたことをエラーのため記録できないことがあり、同じメッセージがシステムに 2 回送信される可能性があります。 Service Bus では、重複の検出を有効にすることで、この問題を処理できます。 詳細については、「 重複検出」を参照してください。

例外を処理します。 メッセージング API では、ユーザー エラー、構成エラー、その他のエラーが発生すると、例外が生成されます。 クライアント コード (送信側と受信側) では、コード内でこれらの例外を処理する必要があります。 バッチ処理では、例外処理を使用してメッセージのバッチ全体が失われるのを防ぐことができるので、特に重要です。 詳細については、「 Service Bus メッセージングの例外」を参照してください。

再試行ポリシー。 Service Bus を使用すると、アプリケーションに最適な再試行ポリシーを選択できます。 既定のポリシーでは、最大 9 回の再試行が許され、待機時間は 30 秒ですが、これをさらに調整できます。

配信不能キューを使用します。 複数回再試行しても、メッセージを処理できないか、またはどの受信者にも配信できない場合、メッセージは配信不能キューに移動されます。 配信不能キューからメッセージを読み取り、検査して、問題を修復するプロセスを実装します。 シナリオに応じて、そのままのメッセージで再試行したり、メッセージを変更して再試行したり、メッセージを破棄したりします。 詳細については、「Service Bus デッドレターキューの概要」を参照してください。

ゾーン冗長性を使用せよ。 名前空間でゾーン冗長が有効になっている場合、Service Bus は複数の可用性ゾーン間で変更を自動的にレプリケートします。 1 つの可用性ゾーンが失敗した場合、フェールオーバーは自動的に行われます。 詳細については、「 Service Bus の停止や災害からアプリケーションを保護するためのベスト プラクティス」を参照してください。

Geo-Disaster Recovery を使用します。 geo ディザスター リカバリーを使用すると、Azure リージョン全体またはデータセンターが災害により使用できなくなった場合でも、別のリージョンまたはデータセンターでデータの処理が続けられることが保証されます。 詳細については、Azure Service Bus ジオディザスターリカバリーを参照してください。

ストレージ

ゾーン冗長ストレージ (ZRS) を使用します。 ゾーン冗長ストレージ (ZRS) は、プライマリ リージョンの 3 つの Azure 可用性ゾーン間でデータを同期的にコピーします。 可用性ゾーンが停止した場合、Azure Storage は自動的に代替ゾーンにフェールオーバーします。 詳細については、 Azure Storage の冗長性に関するページを参照してください。

地理的冗長性を使用する場合は、読み取りアクセスを構成してください。 マルチリージョン アーキテクチャを使用する場合は、グローバルな冗長性に適したストレージ層を使用します。 読み取りアクセス geo 冗長ストレージ (RA-GRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) を有効にすると、データはセカンダリ リージョンにレプリケートされます。 RA-GRS ではプライマリ リージョン内でローカル冗長ストレージ (LRS) が使用され、RA-GZRS ではプライマリ リージョン内でゾーン冗長ストレージ (ZRS) が使用されます。 どちらの構成でも、セカンダリ リージョン内のデータへの読み取り専用アクセスが提供されます。 プライマリ リージョンでストレージが停止した場合、アプリケーションはセカンダリ リージョンからデータを読み取ることができます (この可能性に備えて設計した場合)。 詳細については、 Azure Storage の冗長性に関するページを参照してください。

VM ディスクの場合は、マネージド ディスクを使用します。マネージド ディスク では、単一障害点を回避するためにディスクが互いに十分に分離されているため、可用性セット内の VM の信頼性が向上します。 また、マネージド ディスクはストレージ アカウントで作成した VHD の IOPS 制限の対象ではありません。 詳細については、「 Azure での Windows 仮想マシンの可用性の管理」を参照してください。

Queue Storage では、別のリージョンにバックアップ キューを作成します。 Queue Storage では、項目をキューやデキューすることができないため、読み取り専用レプリカの使用は制限されています。 代わりに、別のリージョンのストレージ アカウントにバックアップ キューを作成します。 Azure Storage が停止した場合、アプリケーションは、プライマリ リージョンが再び使用可能になるまで、バックアップ キューを使用できます。 そうすることで、停止中もアプリケーションで新しい要求を引き続き処理できます。

SQLデータベース

Standard または Premium レベルを使用します。 これらの階層は、より長いポイントインタイム リストア期間 (35 日間) を提供します。 詳細については、「 SQL Database のオプションとパフォーマンス」を参照してください。

SQL Database の監査を有効にします。 監査は、悪意のある攻撃や人的ミスの診断に使用できます。 詳細については、「 SQL データベースの監査の概要」を参照してください。

アクティブ Geo レプリケーションを使用します。アクティブ Geo レプリケーションを使用して、異なるリージョンに読み取り可能なセカンダリ レプリカを作成します。 プライマリ データベースに障害が発生した場合、またはオフラインにする必要がある場合は、セカンダリ データベースへの手動フェールオーバーを実行します。 セカンダリ データベースは、フェールオーバーするまでは読み取り専用のままです。 詳細については、「 SQL Database のアクティブ geo レプリケーション」を参照してください。

シャーディングを使用します。 シャーディングを使用して、データベースを水平方向にパーティション分割することを検討してください。 シャーディングによって障害を分離できます。 詳細については、「 Azure SQL Database を使用したスケールアウト」を参照してください。

人的ミスから復旧するには、ポイントインタイム リストアを使用します。 ポイントインタイム リストアは、データベースを以前の特定の時点に戻します。 詳細については、「 自動データベース バックアップを使用した Azure SQL データベースの復旧」を参照してください。

サービス障害から復旧するには、ジオリストアを使用します。 ジオリストアはジオ冗長バックアップからデータベースを復元します。 詳細については、「 自動データベース バックアップを使用した Azure SQL データベースの復旧」を参照してください。

Azure Synapse Analytics

geo バックアップを無効にしないでください。 既定では、Azure Synapse Analytics により、ディザスター リカバリー用にデータの完全バックアップが24 時間ごとに専用 SQL プール に作成されます。 この機能を無効にすることはお勧めしません。 詳細については、「 geo バックアップ」を参照してください。

VM で実行されている SQL Server

データベースをバックアップします。 既に Azure Backup を使用して VM をバックアップしている場合は、DPM を使用して SQL Server ワークロードに Azure Backup を使用することを検討してください。 このアプローチでは、組織用の 1 つのバックアップ管理者の役割と、VM および SQL Server 用の 1 つにまとめられた復旧手順があります。 それ以外の場合は、 Microsoft Azure への SQL Server マネージド バックアップを使用します。

交通マネージャー

手動フェールバックを実行します。 Traffic Manager のフェールオーバーの後は、自動的にフェールバックするのではなく、手動フェールバックを実行してください。 フェールバックする前に、すべてのアプリケーション サブシステムが正常であることを確認してください。 そうしないと、アプリケーションがデータセンター間で切り替わる状況が発生する可能性があります。

ヘルスプローブのエンドポイントを作成します。 アプリケーションの全体的な正常性についてレポートするカスタム エンドポイントを作成してください。 これにより、クリティカル パスが失敗した場合に、フロント エンドだけでなく Traffic Manager をフェールオーバーできます。 エンドポイントは、重要な依存関係が正常でない場合、または到達できない場合に、HTTP エラー コードを返す必要があります。 ただし、重要でないサービスについてはレポートしないでください。 そうしないと、必要のないときに正常性プローブがフェールオーバーをトリガーして、誤検知が生じる可能性があります。 詳細については、 Traffic Manager エンドポイントの監視とフェールオーバーに関する記事を参照してください。

Virtual Machines

単一の VM で運用環境のワークロードを実行しないでください。 単一の VM のデプロイには計画または計画外メンテナンスに対する回復力がありません。 代わりに、ロード バランサーを前面に配置して、可用性セットまたは 仮想マシン スケール セットに複数の VM を配置します。

VM をプロビジョニングするときに、可用性セットを指定します。 現時点では、VM がプロビジョニングされた後に、VM を可用性セットに追加する方法はありません。 既存の可用性セットに新しい VM を追加するときは、必ず VM 用の NIC を作成し、NIC をロード バランサーのバックエンド アドレス プールに追加してください。 そうしないと、ロード バランサーがその VM にネットワーク トラフィックをルーティングしなくなります。

各アプリケーション層を別々の可用性セットに配置します。 N 層のアプリケーションでは、同じ可用性セットの別の層からは VM を配置しないでください。 可用性セット内の VM は、障害ドメイン (FD) と更新ドメイン (UD) にまたがって配置されています。 ただし、FD と UD の冗長性の利点を活用するには、可用性セットのすべての VM が同じクライアント要求を処理できる必要があります。

Azure Site Recovery を使用して VM をレプリケートします。 Site Recovery を使用して Azure VM をレプリケートすると、すべての VM ディスクがターゲット リージョンに非同期的に継続的にレプリケートされます。 復旧ポイントは数分ごとに作成されます。 これにより目標復旧時点 (RPO) が数分単位で設定されます。 ディザスター リカバリー訓練を、運用環境のアプリケーションまたは実行中のレプリケーションに影響を与えることなく、必要な回数だけ実施できます。 詳細については、「 Azure へのディザスター リカバリー訓練を実行する」を参照してください。

パフォーマンスの要件に基づいて適切な VM サイズを選択します。 既存のワークロードを Azure に移動する場合は、オンプレミスのサーバーに最も適合性が高い VM サイズから開始します。 次に、CPU、メモリ、およびディスクの IOPS について、実際のワークロードのパフォーマンスを測定し、必要に応じてサイズを調整します。 これにより、アプリケーションがクラウド環境で期待どおりに動作することを確認できます。 また、複数の NIC が必要な場合は、各サイズの NIC の制限に注意してください。

VHD にはマネージド ディスクを使用します。マネージド ディスク では、単一障害点を回避するためにディスクが互いに十分に分離されているため、可用性セット内の VM の信頼性が向上します。 また、マネージド ディスクはストレージ アカウントで作成した VHD の IOPS 制限の対象ではありません。 詳細については、「 Azure での Windows 仮想マシンの可用性の管理」を参照してください。

OS ディスクではなく、データ ディスクにアプリケーションをインストールします。 そうしないと、ディスク サイズの上限に達する可能性があります。

Azure Backup を使用して VM をバックアップします。 バックアップにより偶発的なデータ損失から保護されます。 詳細については、「 Recovery Services コンテナーを使用した Azure VM の保護」を参照してください。

診断ログを有効にする。 基本的な正常性メトリック、インフラストラクチャ ログ、 ブート診断を含めます。 VM が起動不可能な状態になった場合は、起動エラーを診断するのにブート診断が役立ちます。 詳細については、「 Azure 診断ログの概要」を参照してください。

Azure Monitor を構成します。 ゲスト オペレーティング システムとその中で実行されるワークロードを含む Azure Virtual Machines から監視データを収集して分析する方法については、「 Azure Monitor と クイック スタート: Azure Monitor」を参照してください。

仮想ネットワーク

パブリック IP アドレスを許可したりブロックしたりするには、サブネットにネットワーク セキュリティ グループを追加します。 悪意のあるユーザーからのアクセスをブロックしたり、アプリケーションにアクセスする権限を持つユーザーからのアクセスのみを許可したりしてください。

カスタムのヘルスプローブを作成する。 ロード バランサー正常性プローブでは、HTTP または TCP のいずれかをテストできます。 VM が HTTP サーバーを実行している場合、HTTP プローブは TCP プローブよりも優れた正常性状態のインジケーターです。 HTTP プローブでは、すべての重要な依存関係を含む、アプリケーションの全体的な正常性をレポートするカスタム エンドポイントを使用してください。 詳細については、「 Azure Load Balancer の概要」を参照してください。

ヘルスプローブをブロックしないでください。 ロード バランサー正常性プローブは、既知の IP アドレスである 168.63.129.16 から送信されます。 任意のファイアウォール ポリシーまたはネットワーク セキュリティ グループの規則で、この IP を送受信するトラフィックをブロックしないでください。 正常性プローブをブロックすると、ロード バランサーによってローテーションから VM が削除されることがあります。

ロード バランサーのログ記録を有効にします。 ログには、プローブの応答に失敗したことが原因で、ネットワーク トラフィックを受信していない、バックエンドの VM 数が表示されます。 詳細については、「 Azure Load Balancer のログ分析」を参照してください。