ミッション クリティカルなワークロードの正常性モデリング
アプリケーションとインフラストラクチャの監視は、すべてのインフラストラクチャのデプロイにおいて重要な部分です。 ミッション クリティカルなワークロードの場合、監視はデプロイにおいて不可欠な部分です。 Azure リソースのアプリケーションの正常性と主要なメトリックを監視すると、環境が期待どおりに動作しているかどうかを理解するのに役立ちます。
これらのメトリックを完全に理解し、ワークロードの全体的な正常性を評価するには、監視されているすべてのデータを総合的に理解する必要があります。 正常性モデルでは、未加工のメトリックではなく、ワークロードの正常性を明確に示すことで、全体的な正常性状態の評価に役立ちます。 その状態は、多くの場合、赤色、緑色、黄色などの "信号機" インジケーターで示されます。 明確なインジケーターを持つ正常性モデルが示されると、オペレーターはワークロードの全体的な正常性を理解し、発生した問題に迅速に対応できます。
正常性モデリングは、ミッション クリティカルなデプロイのための次の運用タスクに拡張できます。
アプリケーション ヘルス サービス - スタンプの正常性を判断する API を提供するコンピューティング クラスター上のアプリケーション コンポーネント。
監視 - アプリケーションとインフラストラクチャの正常性とパフォーマンスを評価するパフォーマンスおよびアプリケーションのカウンターのコレクション。
アラート - インフラストラクチャとアプリケーションの問題または停止に関するアクションにつながるアラート。
エラー分析 - 根本原因のドキュメントを含む、エラーの内訳と分析。
これらのタスクは、ミッション クリティカルなインフラストラクチャの包括的な正常性モデルを構成します。 正常性モデルの開発は、すべてのミッション クリティカルなデプロイにおいて包括的かつ不可欠な部分になり得ます (また、そうするべきです)。
詳細については、「Azure でのミッション クリティカルなワークロードの正常性モデリングと監視」を参照してください。
アプリケーション ヘルス サービス
アプリケーション ヘルス サービス (HealthService) は、カタログ サービス (CatalogService) とバックグラウンド プロセッサ (BackgroundProcessor) と共にコンピューティング クラスター内に存在するアプリケーション コンポーネントです。 HealthService には、スタンプの正常性を判断するために呼び出す Azure Front Door の REST API が用意されています。 HealthService は、独自の状態に加えて、依存関係の状態を反映する複雑なコンポーネントです。
コンピューティング クラスターがダウンしている場合、ヘルス サービスは応答しません。 サービスが稼働している場合、インフラストラクチャ内の次のコンポーネントに対して定期的なチェックを実行します。
Azure Cosmos DB に対してクエリを実行しようとします。
Event Hubs にメッセージを送信しようとします。 メッセージは、バックグラウンド worker によってフィルターで除外されます。
ストレージ アカウント内の状態ファイルを検索します。 このファイルを使用すると、他のチェックがまだ正しく動作している間でも、リージョンをオフにできます。 このファイルは、他のプロセスとの通信に使用できます。 たとえば、メンテナンスのためにスタンプを空ける場合は、異常な状態を強制してトラフィックを再ルーティングするためにファイルを削除できます。
正常性モデルにクエリを実行して、すべての運用メトリックが事前に定義されたしきい値内にあるかどうかを判断します。 正常性モデルによってスタンプが異常であることが示された場合は、HealthService が実行する他のテストが正常に返された場合でも、トラフィックをスタンプにルーティングしないでください。 正常性モデルでは、正常性状態のより完全なビューが考慮されます。
すべての正常性チェック結果は、構成可能な秒数 (既定では 10) の間、メモリにキャッシュされます。 この操作により、停止の検出にわずかな待機時間が追加される可能性がありますが、必ずしもすべての HealthService クエリでバックエンド呼び出しが必要ではなくなるため、クラスターとダウンストリーム サービスの負荷が軽減されます。
Azure Front Door のようなグローバル ルーターを使用すると HealthService クエリの数が大幅に増えるので、このキャッシュ パターンは重要です。要求を処理するすべての Azure データセンター内のすべてのエッジ ノードは、ヘルス サービスを呼び出して、機能するバックエンド接続があるかどうかを判断します。 結果をキャッシュすると、正常性チェックによって生じる追加のクラスター負荷が軽減されます。
構成
HealthService と CatalogService には、HealthService によって排他的に使用される次の設定を除き、コンポーネント間で共通の構成設定があります。
| 設定 | 値 |
|---|---|
HealthServiceCacheDurationSeconds |
メモリ キャッシュの有効期限を秒単位で制御します。 |
HealthServiceStorageConnectionString |
状態ファイルが存在するストレージ アカウントの接続文字列。 |
HealthServiceBlobContainerName |
状態ファイルが存在するストレージ コンテナー。 |
HealthServiceBlobName |
状態ファイルの名前。正常性チェックでは、このファイルが検索されます。 |
HealthServiceOverallTimeoutSeconds |
チェック全体のタイムアウト。既定値は 3 秒です。 この間にチェックが完了しない場合、サービスによって異常が報告されます。 |
実装
すべてのチェックは非同期的かつ並列で実行されます。 いずれかが失敗すると、スタンプ全体が使用不可と見なされます。
チェックの結果は、標準の非分散の ASP.NET Core MemoryCache を使用して、メモリにキャッシュされます。 キャッシュの有効期限は SysConfig.HealthServiceCacheDurationSeconds で制御され、既定で 10 秒に設定されています。
Note
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 などの視覚化ツールがあります。
監視: 視覚化
Log Analytics 正常性クエリの結果を視覚化するために、参照実装では Grafana を使用しました。 Grafana は Log Analytics クエリの結果を表示するために使用され、ロジック自体は含まれません。 Grafana スタックはソリューションのデプロイ ライフサイクルの一部ではありませんが、個別にリリースされます。
詳細については、「視覚化」を参照してください。
アラート
アラートは、全体的な運用戦略の重要な部分です。 ダッシュボードの使用などのプロアクティブな監視は、問題に迅速に注意を向けるアラートと共に使用する必要があります。
これらのアラートは、正常性状態の変化 (機能低下/黄色の状態または異常/赤色の状態) をオペレーターに警告することで、正常性モデルを拡張します。 正常性モデルのルート ノードにアラートを設定すると、オペレーターはソリューションの状態に影響するすべてのビジネス レベルを直ちに認識します。つまり、基になるユーザー フローまたはリソースのいずれかが黄色または赤色のメトリックを報告した場合、このルート ノードは黄色または赤色に変わります。 オペレーターは、トラブルシューティングのために正常性モデルの視覚化に注意を向けることができます。
詳細については、「自動インシデント対応」を参照してください。
エラー分析
エラー分析の作成は、主に理論上の計画演習です。 この理論上の演習は、継続的な検証プロセスの一部である自動エラー挿入の入力として使用する必要があります。 ここで定義されているエラー モードをシミュレートすることで、これらのエラーに対する解決策の回復性を検証して、停止を回避できます。
次の表に、Azure Mission-Critical 参照実装のさまざまなコンポーネントのエラー ケースの例を示します。
| サービス | リスク | 影響/軽減策/コメント | Outage |
|---|---|---|---|
| Microsoft Entra ID | Microsoft Entra ID が使用できなくなります。 | 現時点では、可能な軽減策はありません。 複数リージョンのアプローチの場合、グローバル サービスであるため、停止は軽減されません。 このサービスはハードの依存関係です。 Microsoft Entra ID は、新しい AKS ノードの作成、ACR からのコンテナー イメージのプル、ポッドの起動時の Key Vault へのアクセスなどのコントロール プレーン操作に使われます。 Microsoft Entra ID で問題が発生したときに、既存の実行中のコンポーネントを実行し続けられることが期待されます。 新しいポッドや AKS ノードは生成できなくなる可能性が高いです。 この期間中にスケール操作が必要な場合、ユーザー エクスペリエンスが低下し、停止する恐れがあります。 | Partial |
| Azure DNS | Azure DNS が使用できなくなり、DNS 解決が失敗します。 | Azure DNS が使用できなくなった場合、ユーザー要求とアプリケーションのさまざまなコンポーネント間の DNS 解決が失敗する恐れがあります。 現時点では、このシナリオに対して可能な軽減策はありません。 複数リージョンのアプローチの場合、グローバル サービスであるため、停止は軽減されません。 Azure DNS はハードの依存関係です。 使用されるすべての PaaS コンポーネントは Azure DNS に依存するため、バックアップとしての外部 DNS サービスは役に立ちません。 IP に切り替えて DNS をバイパスすることはできません。 Azure サービスには、静的で保証された IP アドレスがありません。 | 完全 |
| Front Door | Front Door の全般的な停止。 | Front Door が完全にダウンした場合、軽減策はありません。 このサービスはハードの依存関係です。 | はい |
| Front Door | ルーティング、フロントエンド、バックエンドの構成エラー。 | デプロイ時の構成の不一致が原因で発生する場合があります。 テスト段階で検出する必要があります。 DNS を使用したフロントエンド構成は、各環境に固有です。 軽減策: 以前の構成にロールバックすると、ほとんどの問題が修正されます。 Front Door での変更のデプロイには数分かかるため、停止が発生します。 | 完全 |
| 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 | Throttling | 調整によってスケールアウト操作が遅れ、パフォーマンスが一時的に低下する可能性があります。 軽減策: Azure Mission-Critical で、1 分あたり 10,000 の読み取り操作を提供する Premium SKU を使用します。 コンテナー イメージは最適化され、レイヤーの数が少ないだけです。 ImagePullPolicy は、ローカルにキャッシュされたバージョンを最初に使用するために IfNotPresent に設定されます。 コメント: コンテナー イメージのプルは、レイヤーの数に応じて複数の読み取り操作で構成されます。 1 分あたりの読み取り操作の数は制限されており、ACR SKU サイズによって異なります。 | いいえ |
| Azure Kubernetes Service | クラスターのアップグレードが失敗します | AKS ノードのアップグレードは、スタンプ間で異なる時間に行われる必要があります。 1 つのアップグレードが失敗した場合に、もう一方のクラスターが影響を受けないようにします。 すべてのノードが使用できなくなるのを防ぐために、クラスターのアップグレードは、ノード間でローリング方式でデプロイする必要があります。 | いいえ |
| Azure Kubernetes Service | 要求を処理するときにアプリケーション ポッドが強制終了されます。 | これにより、エンド ユーザーにエラーが発生し、ユーザー エクスペリエンスが低下する可能性があります。 軽減策: Kubernetes は、既定でポッドを適切な方法で削除します。 ポッドは最初にサービスから削除され、ワークロードは、終了する前にオープン要求を完了し、データを書き込むための猶予期間で SIGTERM を受け取ります。 アプリケーション コードは SIGTERM を解釈する必要があり、ワークロードのシャットダウンに時間がかかる場合は猶予期間の調整が必要になる場合があります。 | いいえ |
| Azure Kubernetes Service | ノードを追加するためのコンピューティング容量をリージョンで使用できません。 | スケールアップ/アウト操作は失敗しますが、既存のノードとその操作には影響しません。 負荷分散のためにトラフィックが他のリージョンに自動的に移動するのが理想的です。 | いいえ |
| Azure Kubernetes Service | サブスクリプションは、新しいノードを追加するための CPU コア クォータに達します。 | スケールアップ/アウト操作は失敗しますが、既存のノードとその操作には影響しません。 負荷分散のためにトラフィックが他のリージョンに自動的に移動するのが理想的です。 | いいえ |
| Azure Kubernetes Service | TLS/SSL 証明書を発行および更新できません。 | クラスターは Front Door に対して異常を報告し、トラフィックは他のスタンプに移動する必要があります。 軽減策: 問題または更新エラーの根本原因を調査します。 | いいえ |
| Azure Kubernetes Service | リソース要求/制限が正しく構成されていない場合、ポッドの CPU 使用率は 100% に達し、要求が失敗する場合があります。 アプリケーションの再試行メカニズムにより、失敗した要求を回復できます。 再試行すると、クライアントにエラーは表示されることなく、要求時間が長くなる場合があります。 負荷が過剰になると、最終的に失敗します。 | いいえ (負荷が過剰でない場合) | |
| Azure Kubernetes Service | サード パーティ製コンテナー イメージまたはレジストリを使用できません | 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 秒あたり 1000 操作の制限があります。 シークレットの自動更新のため、スタンプに多数 (数千) のポッドがある場合は、理論上、この制限に達する可能性があります。 考えられる軽減策: 更新頻度をさらに減らすか、完全にオフにします。 | いいえ |
| Application | 誤った構成 | アプリに挿入された接続文字列またはシークレットが正しくありません。 自動デプロイ (パイプラインによって構成が自動的に処理される) と、更新プログラムのブルーグリーン ロールアウトによって軽減されます。 | いいえ |
| Application | 有効期限が切れた資格情報 (スタンプ リソース) | たとえば、ポッドでイベント ハブの SAS トークンまたはストレージ アカウント キーを使用できるように、Key Vault でこれらが適切に更新されずに変更された場合、それぞれのアプリケーション コンポーネントは失敗します。 このエラーはヘルス サービスに影響し、スタンプは自動的にローテーションから除外されます。 軽減策: それをサポートするすべてのサービスに対して Microsoft Entra ID ベースの認証を使います。 AKS では、ポッドが Microsoft Entra ワークロード ID (プレビュー) を使って認証する必要があります。 参照実装では、ポッド ID の使用が検討されました。 現時点では、ポッド ID が十分に安定していないことが判明し、現在の参照アーキテクチャでは使用しないことが決定されました。 将来的にはポッド ID が解決策になる可能性があります。 | いいえ |
| Application | 期限切れの資格情報 (グローバル共有リソース) | たとえば、ポッドで Azure Cosmos DB API キーを使用できるように、すべてのスタンプ Key Vault でこれが適切に更新されずに変更された場合、それぞれのアプリケーション コンポーネントは失敗します。 このエラーにより、すべてのスタンプが同時にダウンし、ワークロード全体の停止が発生します。 Microsoft Entra 認証を使ったキーとシークレットの必要性を回避する方法については、前の項目を参照してください。 | 完全 |
| Virtual Network | サブネットの IP アドレス空間が使い果たされた | サブネット上の IP アドレス空間が使い果たされた場合、新しい AKS ノードやポッドの作成などのスケールアウト操作は行われません。 停止にはなりませんが、パフォーマンスが低下し、ユーザー エクスペリエンスに影響を与える可能性があります。 軽減策: IP 空間を増やします (可能な場合)。 その方法を選択できない場合は、ノードごとのリソース (より大きな VM SKU) またはポッドごとのリソース (CPU/メモリの増加) を増やして、各ポッドがより多くのトラフィックを処理できるようにし、スケールアウトの必要性を減らすと役立つ場合があります。 | いいえ |
次のステップ
参照実装をデプロイして、このアーキテクチャで使用されているリソースとその構成を完全に理解します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示