Azure Container Apps は、マイクロサービスとコンテナー化されたアプリケーションをデプロイするためのフル マネージドのサーバーレス コンテナー ホスティング サービスです。 この記事では、 Azure Container Apps での信頼性のサポートについて説明します。 可用性ゾーンとリージョン間のディザスター リカバリー オプションを使用したリージョン内の回復性について説明します。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービス内でこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を満たすために必要な機能を選択する責任があります。
運用環境のデプロイに関する推奨事項
ソリューションの信頼性要件をサポートするために Container Apps をデプロイする方法と、信頼性がアーキテクチャの他の側面にどのように影響するかについては、「 Azure Well-Architected Framework での Azure Container Apps のアーキテクチャのベスト プラクティス」を参照してください。
信頼性アーキテクチャの概要
Container Apps を使用する場合は、基本的なデプロイ ユニットとして機能し、コンテナー アプリのグループを囲むセキュリティで保護された境界を表す 環境をデプロイします。 この環境では、可用性ゾーンのサポートやネットワーク構成など、コア設定を構成します。 環境には、ワークロード プロファイル環境と消費専用環境の 2 種類があります。 詳細については、「 Azure Container Apps のコンピューティング構造と課金構造」を参照してください。
1 つの環境内で複数の アプリをデプロイし、それぞれが 1 つ以上の コンテナーを実行できます。 環境では、非対話型タスクを表す 1 つ以上の ジョブを実行することもできます。 詳細については、「Azure Container Apps のコンテナー」および「Azure Container Apps のジョブ」を参照してください。
各アプリには、アプリの実行中のインスタンスを表す 1 つ以上の レプリカがあります。 レプリカの最小数と最大数、アプリがレプリカを動的に追加および削除する方法など、アプリのスケーリング方法を制御できます。 プラットフォームのスケジューラは、レプリカ数の最小要件を考慮しながら、物理ホスト間での最適な分散を保証します。 詳細については、「Azure Container Apps でスケーリング ルールを設定する」を参照してください。
Container Apps は、次のようなさまざまな機能を使用して、アプリケーションの信頼性をサポートするように設計されています。
自動ヘルスモニタリング。 組み込みのイングレス コントローラーは、正常なレプリカ間でトラフィックを自動的に負荷分散します。 レプリカが正常性チェックに失敗した場合、またはその基になるインフラストラクチャが長時間使用できなくなった場合、サービスは失敗したコンテナーを自動的に再起動するか、代替レプリカを作成し、異常なレプリカから離れた場所にトラフィックを再配布し、クラスター内のネットワーク再試行を管理します。 この自動復旧プロセスでは、顧客の介入は必要なく、指定したレプリカ数が維持されます。 詳細については、「正常性プローブ」を参照してください。
Dapr によるアプリケーションの回復性。 Container Apps は、Dapr との緊密な統合を提供します。これは、他のサービスの問題に対する回復性を含め、運用グレードのマイクロサービスとコンテナー化されたアプリケーションを運用するためのさまざまな機能を提供するフレームワークです。 詳細については、「 Azure Container Apps を使用したマイクロサービス」を参照してください。
コントロール プレーン、イングレス コントローラー、コンテナー ランタイムなどのシステム コンポーネントのインフラストラクチャの回復性。 可用性ゾーンがあるリージョンでは、Container Apps によってゾーンの冗長性が提供されます。 詳細については、 可用性ゾーンのサポートに関するページを参照してください。
一時的な障害
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Container Apps は、プラットフォーム レベルの再試行メカニズムと正常性の監視によって、多くの一時的な障害を自動的に処理します。 一時的な障害に対するアプリケーションの回復性を確保するには、次の推奨事項に従います。
プラットフォームがアプリケーション固有の障害状態を検出して対応できるようにする正常性プローブを構成します。 アプリケーションのスタートアップ特性に基づいて適切な障害しきい値とタイムアウト値を設定します。たとえば、一時的な問題の間にコンテナーの早期再起動を回避するために、ライブネス プローブに 10 秒の期間で障害しきい値 3 を使用します。 詳細については、「正常性プローブ」を参照してください。
サービス検出の回復性ポリシー (プレビュー) を使用して 、単純な回復性ポリシーを使用して、サービス要求のエラーを事前に防止、検出、復旧します。 たとえば、回復性ポリシーを使用する場合、アプリが応答できない一時的な障害がある場合、アプリに対する各受信要求を自動的に再試行できます。 詳細については、「 サービス検出の回復性 (プレビュー)」を参照してください。
外部サービス呼び出し、データベース接続、および API 要求の再試行ロジックをアプリケーション内に実装します。
アプリケーションで Dapr を使用してクラウド サービスと統合する場合は、 Dapr コンポーネントの回復性 (プレビュー) を使用して、再試行、タイムアウト、およびサーキット ブレーカーを構成します。
その他の依存関係については、アプリケーションで一時的な障害を処理する必要があります。 外部サービスを呼び出すときに指数バックオフ戦略とサーキット ブレーカー パターンを使用して、ダウンストリーム サービスの中断中の連鎖障害を防ぎます。 Container Apps の組み込みのサービス検出と負荷分散により、失敗したインスタンスからトラフィックが自動的にルーティングされますが、アプリケーション レベルの再試行ポリシーでは、プラットフォーム レベルの正常性チェックによってコンテナーの再起動がトリガーされる前に、一時的な問題が正常に処理されます。
ジョブの実行または依存関係の障害など、一時的な障害に対する回復性を備えるジョブを設計します。 再起動した場合に自動的に作業を再開するようにジョブを設計するか、安全に再実行できるようにべき等性を設計します。
可用性ゾーンのサポート
可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Container Apps 環境を作成するときに、 ゾーンの冗長性 を有効にして、選択した Azure リージョン内の複数の可用性ゾーンに基になるインフラストラクチャを分散できます。 Container Apps では、ゾーン間でアプリのレプリカが自動的にスケジュールされます。 この分散は透過的に行われます。個々のレプリカのゾーン配置を指定する必要はありません。
ゾーン冗長性により、コンテナー アプリのレプリカが複数のゾーンに分散されるようにすることで、ゾーン レベルの障害に対するアプリケーションの回復性が向上します。
次の図は、それぞれ個別の可用性ゾーンで実行されている 3 つのレプリカを持つゾーン冗長コンテナー アプリの例を示しています。
リージョンのサポート
ゾーンの冗長性は、Container Apps と可用性ゾーンをサポートするすべてのリージョンで使用できます。
可用性ゾーンをサポートするリージョンを確認するには、可用性 ゾーンがサポートされている Azure リージョンを参照してください。
Container Apps をサポートするリージョンについては、「 リージョン別の製品の可用性」を参照してください。
Requirements
ゾーン冗長は、従量課金と専用ワークロード プロファイルの両方を含むすべての Container Apps プランで使用できます。
ただし、Azure Container Apps で可用性ゾーンを使用するには、次の要件を満たす必要があります。
環境の作成時にゾーン冗長を有効にします。 環境の作成後にこの設定を変更することはできません。
仮想ネットワーク内に Container Apps 環境をデプロイします。 仮想ネットワークは、可用性ゾーンをサポートするリージョンに存在する必要があります。 仮想ネットワークに適切なサイズのサブネットがあることを確認します。 従量課金のみの環境では、
/23CIDR 範囲以上のサブネットが必要ですが、ワークロード プロファイル環境では/27以上が必要です。レプリカの最小数を少なくとも 2 つに構成して、複数の可用性ゾーンに分散されるようにします。 次のいずれかの条件が適用される場合は、レプリカの最小数を高く設定することを検討してください。
- 予想されるピーク時の負荷には、2 つ以上のレプリカが必要です。
- 複数のゾーンで同時に障害が発生した場合でも耐えられる必要があります。
- ゾーンの停止中に、他のゾーンに新しいレプリカが作成されるのを待つ時間を最小限に抑えたいと考えています。
可用性ゾーンのサポートを設定する
ゾーン冗長化された「Container Apps」環境を作成します。 Azure portal、Azure CLI、Azure PowerShell に関するデプロイ手順については、「 方法: ゾーン冗長コンテナー アプリを作成する」を参照してください。
ゾーン冗長デプロイに移行します。 既存の Container Apps 環境でゾーン冗長を有効にすることはできません。 ゾーン冗長ではない既存の環境をアップグレードするには、サポートされているリージョンでゾーン冗長が有効になっている新しい環境を作成します。 次に、コンテナー アプリを再デプロイします。
ゾーン冗長を無効にします。 ゾーンの冗長性は、環境の作成時に有効にした後で無効にすることはできません。 ゾーン冗長以外のデプロイが必要な場合は、ゾーン冗長オプションを有効にせずに新しい環境を作成するか、可用性ゾーンをサポートしていないリージョンにデプロイする必要があります。
確認します。 Azure portal、Azure CLI、Azure PowerShell を使用して、環境のゾーン冗長状態を確認できます。 手順については、「 ゾーンの冗長性を確認する」を参照してください。
費用
Azure Container Apps のゾーン冗長性を有効にすると、標準の Container Apps 価格を超える追加料金は発生しません。 ゾーンの冗長性が有効かどうかに関係なく、コンピューティング リソース、要求、仮想コアの秒に対して同じ料金を支払います。 詳細については、 Azure Container Apps の価格 と Container Apps の課金に関するページを参照してください。
容量の計画と管理
可用性ゾーンが使用できなくなった場合、Container Apps プラットフォームはスケール ルールを使用して、そのゾーン内の失われたレプリカを置き換えるタイミングを決定します。 スケジューラが適切なスケジュール決定を行えるように、スケール ルールが正しく構成されていることが重要です。
スケール ルールを適切に構成するには、次の原則に従います。
アプリケーションで許容できるレプリカの最小数を設定します。 古いレプリカが失われたことをプラットフォームが検出する必要があるため、失われたレプリカが置き換えられるには少し時間がかかる場合があります。その後、新しいレプリカは、受信要求を送信する前に正常な準備プローブの状態を開始して返す必要があります。 指定した最小レプリカ数よりも少ない可能性がある期間を許容できない場合は、ゾーンが使用できなくなった場合でもアプリケーションのパフォーマンスを維持するために 、オーバープロビジョニングを 検討してください。
コンテナーのリソース要求と制限を適切に設定して、Container Apps スケジューラがゾーン間で最適な配置決定を行えるようにします。 リソース要件が指定されていないと、高負荷時に分散が不均一または配置に失敗する可能性があります。
詳細については、「構成オプションの スケーリング ルールを設定 する」を参照してください。
通常の運用
このセクションでは、Container Apps リソースがゾーン冗長用に構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング。 ゾーン冗長 Container Apps では、プラットフォームは、複数のレプリカが同時にトラフィックを処理するアクティブ/アクティブ モデルで動作します。 イングレス コントローラーは、既定でラウンドロビン方式の負荷分散を使用して、ゾーンの場所に関係なく、すべての正常なレプリカに受信要求を分配します。 各ゾーンは個別に要求を処理し、プラットフォームはトラフィック分散のために特定のゾーンに優先順位を付けません。 すべてのゾーンからヘルスプローブが送信されることで、各レプリカの正常性が複数の観点から正確に評価されることを確保します。
ゾーン間のデータ レプリケーション。 Container Apps はステートレス ワークロード用に設計されているため、ゾーン間でアプリケーション データをレプリケートしません。 コンテナースコープストレージやレプリカスコープストレージなど、アプリが エフェメラルストレージに格納するデータは、コンテナーまたはレプリカがシャットダウンされると削除されます。
ステートフル データ要件の場合は、ゾーン冗長ストレージ用に構成された Azure Files ファイル共有をマウント するか、独自のクロスゾーン レプリケーション機能を提供する Azure Cosmos DB や Azure SQL Database などの他の Azure サービスを使用します。
プラットフォームは、高可用性を実現するために、アプリの構成、スケーリング ルール、シークレットを含むコントロール プレーンメタデータのみをゾーン間でレプリケートします。 コンテナー イメージは、レプリカの作成時に必要に応じて、コンテナー レジスタから各ゾーンにプルされます。
ゾーンダウン エクスペリエンス
このセクションでは、Azure Logic Apps リソースがゾーン冗長用に構成されていて、可用性ゾーンの停止が発生した場合に想定される内容について説明します。
検出と応答: Azure はゾーンの障害を自動的に検出します。 Container Apps は、障害が発生したゾーンへの新しいレプリカのスケジュールを直ちに停止し、残りのゾーンの正常なレプリカへのトラフィックの再配布を開始します。 プラットフォームは、介入を必要とせずに、すべてのフェールオーバー操作を自動的に処理します。
通知: ゾーンがダウンしても、Container Apps から通知されません。 ただし、 Azure Service Health を使用して、ゾーンの障害を含む Container Apps サービスの全体的な正常性を把握できます。 ゾーンレベルの問題に関する通知を受け取るよう、アラートを設定します。 詳細については、「Azure portal で Service Health アラートを作成する」を参照してください。
Azure Monitor の Container Apps メトリックを使用して、アプリの正常性を監視することもできます。 ゾーン関連の問題が発生したときにすぐに通知を受け取るために、レプリカ数の低下と要求エラー率に関するアラートを構成します。
アクティブな要求: 失敗したゾーン内のレプリカへの処理中の要求が削除されたり、タイムアウトや接続エラーが発生したりする可能性があります。 影響を受けるゾーンで実行されているジョブの実行はすべて中止され、失敗としてマークされます。
予期されるデータ損失: サービスはステートレス ワークロード用に設計されているため、Container Apps プラットフォーム レベルではデータ損失は発生しません。 可用性ゾーン内の エフェメラル ストレージ に格納されているデータは、レプリカが終了すると失われ、エフェメラル ストレージは一時データにのみ使用する必要があります。
予想されるダウンタイム: アプリケーションは、ゾーンの障害時にダウンタイムがほとんどないか、まったく発生しません。 実際の影響は、アプリケーションの正常性プローブの設定と、正常なゾーン内のレプリカの数によって異なります。 影響を最小限に抑えるために、クライアントが 一時的な障害処理のガイダンス に従っていることを確認します。
影響を受けるゾーンで実行されているジョブの実行はすべて中止され、失敗としてマークされます。 ゾーン障害に対する回復性を備えるジョブが必要な場合は、再試行を構成するか、ジョブが同じ実行のコピーを実行するように並列処理を構成します。 詳細については、「 高度なジョブ構成」を参照してください。
トラフィックの再ルーティング: イングレス コントローラーの正常性プローブは、到達不能なレプリカをすばやく検出し、負荷分散プールから削除します。 アプリの正常性プローブの構成に応じて、これは通常約 30 秒以内に発生します。 後続の受信トラフィックは、残りの正常なレプリカに分散されます。 これは、同じアプリケーション URL を引き続き使用するクライアントに透過的に発生します。
セッション アフィニティを有効にしていて、ゾーンがダウンした場合、以前にそのゾーン内のレプリカにルーティングされていたクライアントは、以前のレプリカが使用できなくなったため、新しいレプリカにルーティングされます。 以前のレプリカに関連付けられている状態はすべて失われます。
新しいジョブの実行は、障害のあるゾーンではスケジュールされません。
インスタンス管理: 負荷の増加に基づいて自動スケール ルールがトリガーされる場合、新しいレプリカ インスタンスが正常なゾーンに作成される可能性があります。
ゾーンの回復
可用性ゾーンが障害から復旧すると、Container Apps は、ユーザーの介入を必要とせずに、ゾーンをアクティブなサービスに自動的に再統合します。 プラットフォームの正常性プローブは、復旧されたゾーン内のインフラストラクチャがいつ使用可能になるかを検出し、スケーリング構成に基づいてゾーンへの新しいレプリカのスケジュールを開始します。 正常なゾーン内の既存のレプリカは、この再統合プロセス中もトラフィックにサービスを提供し続け、サービスの中断を確実にしません。
Container Apps では、通常のスケーリング操作の一環として、使用可能なすべてのゾーンにわたるレプリカ分散が徐々に再調整されます。 この自動再調整は、スケーリング イベントが原因でレプリカが作成されたとき、または異常なレプリカが置き換えられたときに発生します。 このプラットフォームでは、既存の正常なレプリカの即時再配布は強制されません。これにより、不要なコンテナーの再起動が防止され、復旧中にアプリケーションの安定性が維持されます。
ゾーンエラーのテスト
Container Apps プラットフォームは、ゾーン冗長コンテナー アプリのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能はフル マネージドであるため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
ゾーン障害に対するアプリケーションの回復性を検証するには、制御されたテスト アプローチを使用して、アプリケーション レイヤーでゾーン レベルの中断をシミュレートします。 アプリケーションをスケールダウンし、残りのレプリカが負荷の増加にどのように対処するかを監視することで、特定のゾーンのレプリカを停止または削除します。 レプリカ数、要求成功率、応答時間、自動スケール動作など、回復性テスト中に主要なメトリックを監視します。 レプリカが削除されたときにレプリカの最小数がサービスの可用性を維持していることを確認し、スケーリング ルールが残りのレプリカの負荷の増加を処理できることを確認します。 正常性プローブの構成をテストするには、正常性エンドポイントを意図的に失敗させて、プラットフォームが予期した期間内のローテーションから異常なインスタンスを正しく削除することを確認します。
マルチリージョン サポート
Container Apps は、単一リージョンのサービスです。 リージョンが使用できなくなった場合、環境とアプリも使用できなくなります。
代替の複数リージョン アプローチ
アプリケーションに影響する単一リージョンの障害のリスクを軽減するために、複数のリージョンに環境をデプロイできます。 次の手順は、回復性の強化に役立ちます。
- アプリケーションを各リージョンの環境にデプロイします。 各環境には独自の仮想ネットワーク構成が必要であり、サブネットの要件は各リージョンのデプロイに個別に適用されます。 コンテナー イメージには、geo レプリケーションが有効になっている Azure Container Registry を使用して実現できる、すべてのリージョンからアクセスできる必要があります。
- Azure Front Door や Azure Traffic Manager などのサービスを使用して、負荷分散ポリシーとフェールオーバー ポリシーを構成します。
- 最後のアプリケーションの状態を回復できるように、リージョン間でデータをレプリケートします。
Backups
Azure Container Apps では、アプリケーションやデータに組み込みのバックアップ機能は提供されません。 Container Apps は、ステートレス コンテナー ホスティング プラットフォームとして、アプリケーションが外部サービスを通じて独自のデータ永続化と回復戦略を管理することを期待しています。 アプリケーション コンテナーとそのローカル ファイル システムは一時的なものであり、レプリカの再起動または移動時にローカルに格納されているデータは失われます。
アプリケーションの更新時の信頼性
リビジョン管理を使用して、ダウンタイムなしでアプリケーションに更新プログラムをデプロイします。 更新されたコンテナー イメージを使用して新しいリビジョンを作成し、 ブルーグリーンデプロイ戦略を使用してカットオーバーを実行したり、 トラフィック分割ルールを使用してトラフィックを徐々にシフトしたりできます。 アプリケーションの更新中、プラットフォームは、古いコンテナーを終了する前に新しいコンテナーを作成することで、最小限のレプリカ数を維持し、サービスの中断を防ぎます。
詳細については、「 Azure Container Apps での変更の更新とデプロイ」を参照してください。
サービスメンテナンス中の信頼性
Azure Container Apps では、プラットフォームの自動メンテナンスを実行して、セキュリティ更新プログラムの適用、新機能のデプロイ、サービスの信頼性の向上を行います。 プラットフォームは、実行中のアプリケーションへの影響を最小限に抑えるために、障害ドメインと可用性ゾーン間でローリング更新を使用します。 メンテナンス期間中は、基になるインフラストラクチャに段階的に更新プログラムが適用されるため、コンテナーは中断することなく実行を続けます。
独自のメンテナンス期間を指定できます。これは、アプリでメンテナンスを実行する期間です。 ただし、重要な更新はメンテナンス期間外に発生する可能性があります。 詳しくは、「Azure Container Apps の計画メンテナンス」をご覧ください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。
Azure Container Apps の可用性 SLA は、アプリに設定したスケール ルールに基づいています。