ミッションクリティカルなワークロードの健全性モデリング

2025-04-23

アプリケーションとインフラストラクチャの監視は、すべてのインフラストラクチャのデプロイにおいて重要な部分です。ミッションクリティカルなワークロードの場合、監視はデプロイにおいて不可欠な部分です。 Azure リソースのアプリケーションの正常性と主要なメトリックを監視すると、環境が期待どおりに動作しているかどうかを理解するのに役立ちます。

これらのメトリックを完全に理解し、ワークロードの全体的な正常性を評価するには、監視されているすべてのデータを総合的に理解する必要があります。正常性モデルでは、未加工のメトリックではなく、ワークロードの正常性を明確に示すことで、全体的な正常性状態の評価に役立ちます。その状態は、多くの場合、赤色、緑色、黄色などの "信号機" インジケーターで示されます。明確なインジケーターを持つ正常性モデルが示されると、オペレーターはワークロードの全体的な正常性を理解し、発生した問題に迅速に対応できます。

健康モデリングは、ミッションクリティカルな展開のために、以下の運用タスクに拡張できます。

アプリケーションヘルスサービス - スタンプの正常性を判断する API を提供するコンピューティングクラスター上のアプリケーションコンポーネント。
監視 - アプリケーションとインフラストラクチャの正常性とパフォーマンスを評価するパフォーマンスおよびアプリケーションのカウンターのコレクション。
アラート - インフラストラクチャとアプリケーションの問題または停止に関するアクションにつながるアラート。
エラー分析 - 根本原因のドキュメントを含む、エラーの内訳と分析。

これらのタスクは、ミッションクリティカルなインフラストラクチャの包括的な正常性モデルを構成します。正常性モデルの開発は、すべてのミッションクリティカルなデプロイにおいて包括的かつ不可欠な部分になり得ます (また、そうするべきです)。

詳細については、「Azure でのミッションクリティカルなワークロードの正常性モデリングと監視」を参照してください。

アプリケーションヘルスサービス

アプリケーションヘルスサービス (HealthService) は、カタログサービス (CatalogService) とバックグラウンドプロセッサ (BackgroundProcessor) と共にコンピューティングクラスター内に存在するアプリケーションコンポーネントです。 HealthService には、スタンプの正常性を判断するために呼び出す Azure Front Door の REST API が用意されています。 HealthService は、独自の状態に加えて、依存関係の状態を反映する複雑なコンポーネントです。

コンピューティングクラスターが停止すると、ヘルスサービスは応答しません。サービスが稼働している場合、インフラストラクチャ内の次のコンポーネントに対して定期的なチェックを実行します。

Azure Cosmos DB に対してクエリを実行しようとします。
Event Hubs にメッセージを送信しようとします。バックグラウンドワーカーはメッセージを除外します。
ストレージアカウント内の状態ファイルを検索します。このファイルを使用すると、他のチェックがまだ正しく動作している間でも、リージョンをオフにできます。このファイルは、他のプロセスとの通信に使用できます。たとえば、メンテナンスのためにスタンプを空ける場合は、異常な状態を強制してトラフィックを再ルーティングするためにファイルを削除できます。
正常性モデルにクエリを実行して、すべての運用メトリックが事前に定義されたしきい値内にあるかどうかを判断します。正常性モデルによってスタンプが異常であることが示された場合は、HealthService が実行する他のテストが正常に返された場合でも、トラフィックをスタンプにルーティングしないでください。正常性モデルでは、正常性状態のより完全なビューが考慮されます。

すべての正常性チェック結果は、構成可能な秒数 (既定では 10) の間、メモリにキャッシュされます。この操作により、停止の検出にわずかな待機時間が追加される可能性がありますが、必ずしもすべての HealthService クエリでバックエンド呼び出しが必要ではなくなるため、クラスターとダウンストリームサービスの負荷が軽減されます。

このキャッシュパターンは重要です。これは、Azure Front Door のようなグローバルルーターを使用する場合に HealthService クエリの数が大幅に増加するためです。要求を処理するすべての Azure データセンター内のすべてのエッジノードは、正常性サービスを呼び出して、機能的なバックエンド接続があるかどうかを判断します。結果をキャッシュすると、正常性チェックによって生じる追加のクラスター負荷が軽減されます。

構成

HealthService と CatalogService には、HealthService によって排他的に使用される次の設定を除き、コンポーネント間で共通の構成設定があります。

設定	値
`HealthServiceCacheDurationSeconds`	メモリキャッシュの有効期限を秒単位で制御します。
`HealthServiceStorageConnectionString`	状態ファイルが存在するストレージアカウントの接続文字列。
`HealthServiceBlobContainerName`	状態ファイルが存在するストレージコンテナー。
`HealthServiceBlobName`	状態ファイルの名前 - 健康診断でこのファイルが検索されます。
`HealthServiceOverallTimeoutSeconds`	チェック全体のタイムアウト - 既定値は 3 秒です。この間に検査が完了しない場合、サービスは異常状態と報告します。

実装

すべてのチェックは非同期的かつ並列で実行されます。いずれかが失敗すると、スタンプ全体が使用不可と見なされます。

チェック結果は、標準の非分散 ASP.NET Core MemoryCacheを使用してメモリにキャッシュされます。 SysConfig.HealthServiceCacheDurationSeconds はキャッシュの有効期限を制御します。既定の設定は 10 秒です。

メモ

SysConfig.HealthServiceCacheDurationSeconds 構成設定では、すべての要求が依存サービスへのダウンストリーム呼び出しを行うわけではないので、正常性チェックによって生成される追加の負荷が軽減されます。

次の表では、インフラストラクチャ内のコンポーネントの正常性チェックについて詳しく説明します。

コンポーネント	健康診断
ストレージアカウント BLOB	BLOB チェックは現在、次の 2 つの目的を果たします。 1. Blob Storage に到達できるかどうかをテストします。ストレージアカウントはスタンプ内の他のコンポーネントによって使用され、重要なリソースと見なされます。 2. 状態ファイルを削除して、手動でリージョンを "オフ" にします。チェックでは指定された BLOB コンテナー内の状態ファイルの存在のみを調べるという設計上の決定が行われました。ファイルの内容は処理されません。ファイルの内容を読み取り、ファイルの内容に基づいて異なる状態を返す、より高度なシステムを設定することもできます。内容の例としては、 HEALTHY、UNHEALTHY、MAINTENANCE などが挙げられます。状態ファイルを削除すると、スタンプが無効になります。アプリケーションをデプロイした後、正常性ファイルが存在することを確認します。ヘルスファイルがない場合、サービスは常に UNHEALTHYで応答します。 Front Doorではバックエンドを使用可能として認識しません。 Terraform はファイルを作成し、インフラストラクチャのデプロイ後に存在する必要があります。
イベントハブ	Event Hubs 正常性レポートでは、`EventHubProducerService` を処理します。 Event Hubs に新しいメッセージを送信できる場合、このサービスによって、正常であると報告されます。フィルター処理のために、このメッセージには次のような識別プロパティが追加されています。 `HEALTHCHECK=TRUE` このメッセージは受信側では無視されます。 `AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync()` 構成設定では、`HEALTHCHECK` プロパティがチェックされます。
Azure Cosmos DB	Azure Cosmos DB の正常性レポートでは、`CosmosDbService`が処理されます。 1 の場合は正常であると報告されます。 Azure Cosmos DB データベースに接続し、クエリを実行できる。 2. データベースにテストドキュメントを書き込める。テストドキュメントには、短い Time-to-Live が設定されています。 Azure Cosmos DB によって自動的に削除されます。 HealthService は、2 つの個別のプローブを実行します。 Azure Cosmos DB が、読み取りが機能し、書き込みが機能しない状態の場合、2 つのプローブによってアラートが確実にトリガーされます。

Azure Cosmos DB クエリ

読み取り専用クエリでは、次のクエリが使用されています。これはデータをフェッチせず、全体的な負荷に大きな影響を与えません。

SELECT GetCurrentDateTime ()

書き込みクエリによって、最小限の内容を持つ、ダミーの ItemRating が作成されます。

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

監視

Azure Log Analytics は、すべてのアプリケーションとインフラストラクチャのコンポーネントのログとメトリックを保存するための中央のストアとして使用されます。 Azure Application Insights はすべてのアプリケーション監視データに使用されます。インフラストラクチャ内の各スタンプには、専用の Log Analytics ワークスペースと Application Insights インスタンスがあります。 Front Door や Azure Cosmos DB などのグローバルに共有されるリソースには、別の Log Analytics ワークスペースが使用されます。

すべてのスタンプは有効期間が短く、新しいリリースごとに継続的に置き換えられます。スタンプごとの Log Analytics ワークスペースは、スタンプの Log Analytics リソースとして個別の監視リソースグループにグローバルリソースとしてデプロイされます。これらのリソースでは、スタンプのライフサイクルは共有されません。

詳細については、「相関分析用の統合データシンク」を参照してください。

監視：データソース

診断設定: Azure Mission-Critical に使用されるすべての Azure サービスは、ログとメトリックを含むすべての診断データをデプロイ固有の (グローバルまたはスタンプ) Log Analytics ワークスペースに送信するように構成されています。このプロセスは、Terraform デプロイの一部として自動的に行われます。新しいオプションは自動的に識別され、terraform applyの一部として追加されます。
Kubernetes モニタリング: 診断設定は、Azure Kubernetes Service (AKS) のログとメトリックを Log Analytics に送信するために使用されます。 AKS は、Container Insights を使用するように構成されています。 Container Insights によって、AKS クラスター内の各ノードに Kubernetes DaemonSet を介して OMSAgentForLinus がデプロイされます。 OMSAgentForLinux は、Kubernetes クラスター内から追加のログとメトリックを収集することができ、それらを対応する Log Analytics ワークスペースに送信します。これらの追加のログとメトリックには、ポッド、デプロイ、サービス、クラスターの全体的な正常性に関するより詳細なデータが含まれています。ミッションクリティカルなワークロードの次に Kubernetes にデプロイされた ingress-nginx、cert-manager、その他のコンポーネントなど、さまざまなコンポーネントからより多くの分析情報を得るために、Prometheus スクレイピングを使用できます。 Prometheus スクレイピングでは、クラスター内のさまざまなエンドポイントから Prometheus メトリックをスクレイピングするように OMSAgentForLinux が構成されます。
Application Insights データ監視: Application Insights は、アプリケーションから監視データを収集するために使用されます。このコードは、Application Insights SDK を使用してアプリケーションのパフォーマンスに関するデータを収集するためにインストルメント化されます。結果の状態コード、依存関係呼び出しの期間、未処理の例外のカウンターなどの重要な情報が収集されます。この情報は正常性モデルで使用され、アラートとトラブルシューティングに使用できます。

監視: Application Insights 可用性テスト

個々のスタンプとソリューション全体の可用性を外部の観点から監視するために、Application Insights 可用性テストは次の 2 つの場所で設定されます。

リージョンの可用性テスト: これらのテストは、リージョンの Application Insights インスタンスで設定され、スタンプの可用性を監視するために使用されます。これらのテストは、スタンプのクラスターと静的ストレージアカウントを直接対象にしています。クラスターのイングレスポイントを直接呼び出すには、要求が正しい Front Door ID ヘッダーを伝達する必要があります。それ以外の場合、イングレスコントローラーは呼び出しを拒否します。
グローバル可用性テスト: これらのテストは、グローバル Application Insights インスタンスで設定され、Front Door に ping を実行してソリューション全体の可用性を監視するために使用されます。 2 つのテストが使用されます。1 つは CatalogService に対して API 呼び出しをテストし、もう 1 つは Web サイトのホームページをテストします。

監視: クエリ

Azure Mission-Critical では、さまざまな Kusto 照会言語 (KQL) クエリを使用して、Log Analytics からデータを取得する関数としてカスタムクエリを実装します。これらのクエリは、グローバルおよびスタンプのデプロイ用に分離された個別のファイルとしてコードリポジトリに格納されます。これらは、各インフラストラクチャパイプライン実行の一部として Terraform を介して自動的にインポートされ、適用されます。

この方法では、クエリロジックが視覚化レイヤーから分離されます。 Log Analytics クエリは、コード (たとえば、HealthService API ) から直接呼び出されます。もう 1 つの例として、Azure ダッシュボード、Monitor ブック、Grafana などの視覚化ツールがあります。

監視: 視覚化

Grafana を使用して、参照実装で Log Analytics 正常性クエリの結果を視覚化します。 Grafana は Log Analytics クエリの結果を表示し、ロジック自体は含んでいません。ソリューションのデプロイライフサイクルとは別に Grafana スタックをリリースします。

詳細については、「視覚化」を参照してください。

アラート

アラートは、全体的な運用戦略の重要な部分です。ダッシュボードの使用などのプロアクティブな監視は、問題に迅速に注意を向けるアラートと共に使用する必要があります。

これらのアラートは、正常性状態の変化 (機能低下/黄色の状態または異常/赤色の状態) をオペレーターに警告することで、正常性モデルを拡張します。正常性モデルのルートノードにアラートを設定すると、オペレーターはソリューションの状態に影響するすべてのビジネスレベルを直ちに認識します。つまり、基になるユーザーフローまたはリソースのいずれかが黄色または赤色のメトリックを報告した場合、このルートノードは黄色または赤色に変わります。オペレーターは、トラブルシューティングのために正常性モデルの視覚化に注意を向けることができます。

詳細については、「自動インシデント対応」を参照してください。

エラー分析

エラー分析の作成は、主に理論上の計画演習です。この理論上の演習は、継続的な検証プロセスの一部である自動エラー挿入の入力として使用する必要があります。ここで定義されている障害モードをシミュレートすることで、これらの障害に対するソリューションの回復性を検証して、停止を最小限に抑えることができます。

次の表に、Azure Mission-Critical 参照実装のさまざまなコンポーネントのエラーケースの例を示します。

サービス	リスク	影響/軽減策/コメント	停止
Microsoft Entra ID	Microsoft Entra ID が使用できなくなります。	現時点では、可能な軽減策はありません。複数リージョンのアプローチでは、グローバルサービスであるため、停止は軽減されません。このサービスはハードの依存関係です。 Microsoft Entra ID は、新しい AKS ノードの作成、ACR からのコンテナーイメージのプル、ポッドの起動時の Key Vault へのアクセスなどのコントロールプレーン操作に使われます。 Microsoft Entra ID で問題が発生した場合、既存の実行中のコンポーネントは実行を継続できる必要があります。新しいポッドまたは AKS ノードが生成できない可能性があります。この期間中にスケール操作が必要な場合、ユーザーエクスペリエンスが低下し、停止する恐れがあります。	部分的
Azure DNS	Azure DNS が使用できなくなり、DNS 解決が失敗します。	Azure DNS が使用できなくなった場合、ユーザー要求とアプリケーションのさまざまなコンポーネント間の DNS 解決は失敗します。現時点では、このシナリオに対して可能な軽減策はありません。複数リージョンのアプローチでは、グローバルサービスであるため、停止は軽減されません。 Azure DNS はハードの依存関係です。使用されるすべての PaaS コンポーネントは Azure DNS に依存するため、バックアップとしての外部 DNS サービスは役に立ちません。 IP に切り替えて DNS をバイパスすることはできません。 Azure サービスには、静的で保証された IP アドレスがありません。	満杯
フロントドア	Front Door の全般的な停止。	Front Door が完全にダウンした場合、軽減策はありません。このサービスはハードの依存関係です。	はい
フロントドア	ルーティング、フロントエンド、バックエンドの構成エラー。	デプロイ時の構成の不一致が原因で発生する場合があります。テスト段階で検出する必要があります。 DNS を使用したフロントエンド構成は、各環境に固有です。軽減策: 以前の構成にロールバックすると、ほとんどの問題が修正されます。 Front Door での変更のデプロイには数分かかるため、障害が発生します。	満杯
フロントドア	マネージド TLS/SSL 証明書が削除されます。	デプロイ時の構成の不一致が原因で発生する場合があります。テスト段階で検出する必要があります。技術的にはサイトは引き続き機能しますが、TLS/SSL 証明書エラーにより、ユーザーはサイトにアクセスできなくなります。軽減策: 証明書の再発行には 20 分ほどかかる場合があり、さらにパイプラインの修正と再実行に時間がかかります。	満杯
Azure Cosmos DB	データベースやコレクションの名前が変更されます。	デプロイ時の構成の不一致が原因で発生する場合があります。Terraform によってデータベース全体が上書きされ、データが失われる恐れがあります。データベースまたはコレクションレベルのロックを使用すると、データの損失を防ぐことができます。アプリケーションはデータにアクセスできません。アプリの構成を更新し、ポッドを再起動する必要があります。	はい
Azure Cosmos DB	リージョンの停止	Azure Mission-Critical では、複数リージョンの書き込みが有効になっています。読み取りまたは書き込みでエラーが発生した場合、クライアントは現在の操作を再試行します。以降のすべての操作は優先順に次のリージョンに永続的にルーティングされます。優先設定一覧のエントリが 1 つだった (または空だった) が、アカウントに他の使用可能なリージョンがある場合は、アカウント一覧内の次のリージョンにルーティングされます。	いいえ
Azure Cosmos DB	RU の不足による広範な調整。	Front Door レベルで使用される RU の数と負荷分散に応じて、Azure Cosmos DB の使用率で特定のスタンプの負荷が高くなる可能性がある一方で、他のスタンプはより多くの要求を処理できます。軽減策: 負荷分散の向上または RU の追加。	いいえ
Azure Cosmos DB	パーティションが満杯	Azure Cosmos DB 論理パーティションサイズの制限は 20 GB です。コンテナー内のパーティションキーのデータがこのサイズに達した場合、追加の書き込み要求は "パーティションキーが最大サイズに達しました" というエラーで失敗します。	部分 (DB 書き込みが無効)
Azure Container Registry	リージョンの停止	コンテナーレジストリでは、Traffic Manager を使用してレプリカリージョン間でフェールオーバーします。要求は、別のリージョンに自動的に再ルーティングされます。最悪の場合、DNS フェールオーバーが発生している間、AKS ノードは数分間 Docker イメージをプルしません。	いいえ
Azure Container Registry	イメージが削除されました	画像を取得することはできません。この停止は、新しく生成または再起動されたノードにのみ影響します。既存のノードでは、イメージはキャッシュされています。 **軽減策: 直ちに検出された場合、最新のビルドパイプラインを再実行すると、イメージがレジストリに戻されます。	いいえ
Azure Container Registry	スロットリング	調整によってスケールアウト操作が遅れ、パフォーマンスが一時的に低下する可能性があります。軽減策: Azure Mission-Critical で、1 分あたり 10,000 の読み取り操作を提供する Premium SKU を使用します。コンテナーイメージは最適化され、レイヤーの数が少ないだけです。 ImagePullPolicy は、ローカルにキャッシュされたバージョンを最初に使用するために IfNotPresent に設定されます。コメント: コンテナーイメージのプルは、レイヤーの数に応じて複数の読み取り操作で構成されます。 1 分あたりの読み取り操作の数は制限されており、ACR SKU サイズによって異なります。	いいえ
Azure Kubernetes サービス	クラスターのアップグレードが失敗します	AKS ノードのアップグレードは、スタンプ間で異なる時間に行われる必要があります。 1 つのアップグレードが失敗した場合に、もう一方のクラスターが影響を受けないようにします。すべてのノードが使用できなくなるのを防ぐために、クラスターのアップグレードは、ノード間でローリング方式でデプロイする必要があります。	いいえ
Azure Kubernetes サービス	要求を処理するときにアプリケーションポッドが強制終了されます。	この結果、エンドユーザーがエラーに直面し、ユーザーエクスペリエンスが低下する可能性があります。軽減策: Kubernetes は、既定でポッドを適切な方法で削除します。ポッドは最初にサービスから削除され、ワークロードは、終了する前にオープン要求を完了し、データを書き込むための猶予期間で SIGTERM を受け取ります。アプリケーションコードは SIGTERM を解釈する必要があり、ワークロードのシャットダウンに時間がかかる場合は猶予期間の調整が必要になる場合があります。	いいえ
Azure Kubernetes サービス	ノードを追加するためのコンピューティング容量をリージョンで使用できません。	スケールアップ/スケールアウト操作は失敗しますが、既存のノードとその操作には影響しません。負荷分散のためにトラフィックが他のリージョンに自動的に移動するのが理想的です。	いいえ
Azure Kubernetes サービス	サブスクリプションは、新しいノードを追加するための CPU コアクォータに達します。	スケールアップ/スケールアウト操作は失敗しますが、既存のノードとその操作には影響しません。負荷分散のためにトラフィックが他のリージョンに自動的に移動するのが理想的です。	いいえ
Azure Kubernetes サービス	TLS/SSL 証明書を発行および更新できません。	クラスターは Front Door に対して異常を報告し、トラフィックは他のスタンプに移動する必要があります。軽減策: 問題または更新エラーの根本原因を調査します。	いいえ
Azure Kubernetes サービス	リソース要求/制限が正しく構成されていない場合、ポッドの CPU 使用率は 100% に達し、要求が失敗する場合があります。アプリケーションの再試行メカニズムにより、失敗した要求を回復できます。再試行すると、クライアントにエラーは表示されることなく、要求時間が長くなる場合があります。過剰な負荷は最終的に障害を引き起こします。	いいえ (負荷が過剰でない場合)
Azure Kubernetes サービス	サードパーティ製コンテナーイメージまたはレジストリを使用できません	cert-manager や ingress-nginx などの一部のコンポーネントでは、外部コンテナーレジストリからコンテナーイメージと Helm チャートをダウンロードする必要があります (送信トラフィック)。これらのリポジトリまたはイメージの 1 つ以上が使用できない場合は、(イメージがまだキャッシュされていない) 新しいノード上の新しいインスタンスを開始できない可能性があります。考えられる軽減策: 一部のシナリオでは、ソリューションごとのコンテナーレジストリにサードパーティのコンテナーイメージをすることが理にかなっています。このシナリオでは複雑さが増し、慎重に計画および運用化する必要があります。	部分的 (スケールおよび更新/アップグレード操作中)
イベントハブ	メッセージを Event Hubs に送信できません	スタンプが書き込み操作で使用できなくなります。ヘルスサービスはこれを自動的に検出し、スタンプをローテーションから除外する必要があります。	いいえ
イベントハブ	BackgroundProcessor でメッセージを読み取ることができません	メッセージは順番待ちになります。メッセージは永続化されるため、失われることはありません。現時点では、このエラーはヘルスサービスではカバーされません。メッセージの読み取り中にエラーを検出するには、worker に監視またはアラートが設定されている必要があります。軽減策: 問題が修正されるまで、スタンプを手動で無効にする必要があります。	いいえ
ストレージアカウント	Event Hubs チェックポイントの worker によってストレージアカウントが使用できなくなります	スタンプは Event Hubs からのメッセージを処理しません。ストレージアカウントは、HealthService でも使用されます。 HealthService はストレージの問題を検出し、スタンプをローテーションから除外する必要があります。スタンプ内の他のサービスが同時に影響を受ける可能性があります。	いいえ
ストレージアカウント	静的 Web サイトで問題が発生します。	静的な Web サイトで問題が発生した場合、Front Door はこのエラーを検出します。トラフィックはこのストレージアカウントに送信されません。 Front Door でのキャッシュも、この問題を軽減できます。	いいえ
Key Vault（キーボールト）	`GetSecret` 操作で Key Vault を使用できません。	新しいポッドの開始時に、AKS CSI ドライバーは Key Vault からすべてのシークレットを取得して、失敗します。ポッドを起動できません。現在、5 分ごとに自動更新が行われています。更新が失敗します。エラーが `kubectl describe pod` に表示されますが、ポッドは引き続き動作します。	いいえ
Key Vault（キーボールト）	`GetSecret` または `SetSecret` 操作で Key Vault を使用できません。	新しいデプロイを実行することはできません。現時点では、このエラーにより、影響を受けるリージョンが 1 つしかない場合でも、デプロイパイプライン全体が停止する恐れがあります。	いいえ
Key Vault（キーボールト）	Key Vault のスロットリング	Key Vault には、10 秒あたり 1,000 操作の制限があります。シークレットの自動更新のため、スタンプに多数 (数千) のポッドがある場合は、理論上、この制限に達する可能性があります。考えられる軽減策: 更新頻度をさらに減らすか、完全にオフにします。	いいえ
アプリケーション	誤った構成	アプリに挿入された接続文字列またはシークレットが正しくありません。自動デプロイ (パイプラインによって構成が自動的に処理されます) と、更新プログラムの青緑色のロールアウトによって軽減されます。	いいえ
アプリケーション	有効期限が切れた資格情報 (スタンプリソース)	たとえば、イベントハブの SAS トークンまたはストレージアカウントキーが、ポッドで使用できるように Key Vault で適切に更新せずに変更された場合、それぞれのアプリケーションコンポーネントは失敗します。このエラーはヘルスサービスに影響し、スタンプは自動的にローテーションから除外されます。軽減策: それをサポートするすべてのサービスに対して Microsoft Entra ID ベースの認証を使います。 AKS では、ポッドが Microsoft Entra ワークロード ID (プレビュー) を使って認証する必要があります。参照実装では、ポッド ID の使用が検討されました。現時点では、ポッド ID が十分に安定していないことが判明し、現在の参照アーキテクチャでは使用しないことが決定されました。将来的にはポッド ID が解決策になる可能性があります。	いいえ
アプリケーション	期限切れの資格情報 (グローバル共有リソース)	すべてのスタンプ Key Vault において、Azure Cosmos DB API キーが適切に更新されないまま変更された場合、ポッドがそれを利用できず、関連するアプリケーションコンポーネントの動作が失敗することになります。このエラーにより、すべてのスタンプが同時にダウンし、ワークロード全体の停止が発生します。 Microsoft Entra 認証を使ったキーとシークレットの必要性を回避する方法については、前の項目を参照してください。	満杯
Virtual Network	サブネットの IP アドレス空間が使い果たされた	サブネット上の IP アドレス空間が使い果たされた場合、新しい AKS ノードやポッドの作成などのスケールアウト操作は行われません。停止は発生しませんが、パフォーマンスが低下してユーザーエクスペリエンスが低下する可能性があります。軽減策: IP 空間を増やします (可能な場合)。これがオプションでない場合は、各ポッドがより多くのトラフィックを処理できるように、ノードあたりのリソース (より大きな VM SKU) またはポッドごとのリソースの増加 (CPU/メモリの増加) に役立つ可能性があるため、スケールアウトの必要性が減ります。	いいえ

次のステップ

参照実装をデプロイして、このアーキテクチャで使用されているリソースとその構成を完全に理解します。

実装: Mission-Critical Online