Azure Container Apps の信頼性
この記事では、Azure Container Apps の信頼性サポートについて説明し、可用性ゾーンでのリージョンの回復性とディザスター リカバリーによるリージョン間の回復性の両方を取り上げます。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。
可用性ゾーンのサポート
Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。
障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。
Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。
Azure Container Apps は、利用可能なリージョンの可用性ゾーンを使用して、データ センターの障害からアプリケーションとデータの高可用性の保護を実現しています。
Container Apps のゾーン冗長機能を有効にすると、レプリカがリージョン内のゾーン間に自動的に分散されます。 トラフィックはレプリカ間で負荷分散されます。 ゾーンで障害が発生した場合、トラフィックは残りのゾーンのレプリカに自動的にルーティングされます。
Note
ゾーン冗長を有効にするための追加料金は発生しませんが、ゾーン冗長をサポートするほとんどのリージョンには 3 つのゾーンがあるため、2 つ以上、理想的には 3 つ以上のレプリカがある場合にのみ利点があります。
前提条件
Azure Container Apps では、プランの種類に関係なく、同じ信頼性のサポートが提供されます。
Azure Container Apps では、使用可能なリージョンの可用性ゾーンが使用されます。 可用性ゾーンをサポートするリージョンのリストについては、可用性ゾーンのサービスとリージョン別サポートに関する記事を参照してください。
SLA の機能強化
Azure Container Apps での SLA の増加はありません。 Azure Container Apps の SLA の詳細については、Azure Container Apps のサービス レベル アグリーメントに関する記事を参照してください。
可用性ゾーンが有効になっているリソースを作成する
Container Apps 環境でゾーン冗長を設定する
可用性ゾーンを利用するには、Container Apps 環境を作成するときにゾーン冗長を有効にする必要があります。 この環境には、使用可能なサブネットを持つ仮想ネットワークが含まれている必要があります。 レプリカが適切に分散されるようにするには、アプリの最小レプリカ数を 3 に設定します。
Azure portal を使用してゾーン冗長を有効にする
Azure portal を使用してゾーン冗長が有効になっている環境でコンテナー アプリを作成するには、以下の手順を実行します。
- Azure portal に移動します。
- 上部の検索ボックスで「Container Apps」と検索します。
- [Container Apps] を選択します。
- "Container Apps 環境" フィールドで [新規作成] を選択して、"Container Apps 環境の作成" パネルを開きます。
- 環境名を入力します。
- "ゾーン冗長" フィールドで [有効] を選択します。
ゾーン冗長には、インフラストラクチャ サブネットを持つ仮想ネットワークが必要です。 既存の仮想ネットワークを選択することも、新しいものを作成することもできます。 新しい仮想ネットワークを作成するときは、提供された値をそのまま使用するか、設定をカスタマイズできます。
- [ネットワーク] タブを選択します。
- カスタム仮想ネットワーク名を割り当てるには、"仮想ネットワーク" フィールドで [新規作成] を選択します。
- カスタム インフラストラクチャ サブネット名を割り当てるには、"インフラストラクチャ サブネット" フィールドで [新規作成] を選択します。
- "仮想 IP" には、[内部] または [外部] を選択できます。
- ［作成］ を選択します
Azure CLI を使用してゾーン冗長を有効にする
Container Apps 環境に含める仮想ネットワークとインフラストラクチャ サブネットを作成します。
これらのコマンドを使用する場合は、<PLACEHOLDERS> を実際の値に置き換えます。
Note
従量課金のみの環境では、CIDR 範囲が /23 以上の専用サブネットが必要です。 ワークロード プロファイル環境では、CIDR 範囲が /27 以上の専用サブネットが必要です。 サブネットのサイズ設定の詳細については、「ネットワーク アーキテクチャの概要」を参照してください。
az network vnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--name <VNET_NAME> \
--location <LOCATION> \
--address-prefix 10.0.0.0/16
az network vnet subnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--vnet-name <VNET_NAME> \
--name infrastructure \
--address-prefixes 10.0.0.0/21
次に、インフラストラクチャ サブネット ID に対してクエリを実行します。
INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group <RESOURCE_GROUP_NAME> --vnet-name <VNET_NAME> --name infrastructure --query "id" -o tsv | tr -d '[:space:]'`
最後に、--zone-redundant パラメーターを使用して環境を作成します。 この場所は、仮想ネットワークの作成時に使用した場所と同じである必要があります。
az containerapp env create \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--location "<LOCATION>" \
--infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
--zone-redundant
Azure CLI を使用してゾーン冗長を確認する
Note
Azure Portal には、ゾーン冗長が有効になっているかどうかが表示されません。
Container Apps 環境でゾーン冗長が有効になっていることを確認するには、az container app env show コマンドを使用します。
az containerapp env show \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--subscription <SUBSCRIPTION_ID>
このコマンドからは JSON 応答が返されます。 応答に "zoneRedundant": true が含まれていることを確認します。
安全なデプロイ手法
コンテナー アプリのゾーン冗長を設定すると、レプリカがリージョン内のゾーン間に自動的に分散されます。 レプリカが分散されると、それらの間でトラフィックが負荷分散されます。 ゾーンで障害が発生した場合、トラフィックは残りのゾーンのレプリカに自動的にルーティングされます。
ブルーグリーン デプロイなどの安全なデプロイ手法を引き続き使用する必要があります。 Azure Container Apps では、一度に 1 ゾーンのデプロイやアップグレードは行いません。
セッション アフィニティを有効にしているときにゾーンがダウンすると、以前のレプリカが使用できなくなるので、そのゾーンのクライアントは新しいレプリカにルーティングされます。 以前のレプリカに関連付けられている状態はすべて失われます。
可用性ゾーンの移行
可用性ゾーンを利用するには、Container Apps 環境を作成するときにゾーン冗長を有効にしてください。 この環境には、使用可能なサブネットを持つ仮想ネットワークが含まれている必要があります。 既存の Container Apps 環境を非可用性ゾーン サポートから可用性ゾーン サポートに移行することはできません。
リージョン間のディザスター リカバリーおよび事業継続
ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。
DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。
万が一リージョン全体が停止した場合は、次の 2 つの戦略のいずれかを使用できます。
手動復旧: 新しいリージョンに手動でデプロイするか、リージョンが復旧するまで待ってから、すべての環境とアプリを手動で再デプロイします。
回復性がある復旧: まず、事前にコンテナー アプリを複数のリージョンにデプロイしておきます。 次に、Azure Front Door または Azure Traffic Manager を使用して受信要求を処理し、トラフィックをプライマリ リージョンに転送します。 その後、停止が発生した場合は、影響を受けるリージョンからトラフィックをリダイレクトできます。 詳細については、Azure でのリージョン間レプリケーションに関するページを参照してください。
注意
選択する戦略に関係なく、デプロイ構成ファイルはソース管理に配置して、必要に応じて簡単に再デプロイできるようにします。
その他のガイダンス
次のリソースが独自のディザスター リカバリー プランを作成するのに役立つ場合があります。