Azure Container Apps の信頼性

2024-11-21

この記事では、Azure Container Apps の信頼性サポートについて説明し、可用性ゾーンでのリージョンの回復性とディザスターリカバリーによるリージョン間の回復性の両方を取り上げます。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。

可用性ゾーンのサポート

可用性ゾーンは、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure Container Apps は、利用可能なリージョンの可用性ゾーンを使用して、データセンターの障害からアプリケーションとデータの高可用性の保護を実現しています。

Container Apps のゾーン冗長機能を有効にすると、レプリカがリージョン内のゾーン間に自動的に分散されます。トラフィックはレプリカ間で負荷分散されます。ゾーンで障害が発生した場合、トラフィックは残りのゾーンのレプリカに自動的にルーティングされます。

注

ゾーン冗長を有効にするための追加料金は発生しませんが、ゾーン冗長をサポートするほとんどのリージョンには 3 つのゾーンがあるため、2 つ以上、理想的には 3 つ以上のレプリカがある場合にのみ利点があります。

前提条件

Azure Container Apps では、プランの種類に関係なく、同じ信頼性のサポートが提供されます。

Azure Container Apps では、使用可能なリージョンの可用性ゾーンが使用されます。 Availability Zones をサポートするリージョンのリストについては、「Azure のリージョンと Availability Zones」をご覧ください。

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" には、[内部] または [外部] を選択できます。
［作成］ を選択します

[Container Apps 環境の作成] ページの [ネットワーク] タブのスクリーンショット。

Azure CLI を使用してゾーン冗長を有効にする

Container Apps 環境に含める仮想ネットワークとインフラストラクチャサブネットを作成します。

これらのコマンドを使用する場合は、<PLACEHOLDERS> を実際の値に置き換えます。

注

従量課金のみの環境では、CIDR 範囲が /23 以上の専用サブネットが必要です。ワークロードプロファイル環境では、CIDR 範囲が /27 以上の専用サブネットが必要です。サブネットのサイズ設定の詳細については、「ネットワークアーキテクチャの概要」を参照してください。

Azure CLI
Azure PowerShell

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

$SubnetArgs = @{
    Name = 'infrastructure-subnet'
    AddressPrefix = '10.0.0.0/21'
}
$subnet = New-AzVirtualNetworkSubnetConfig @SubnetArgs

$VnetArgs = @{
    Name = <VNetName>
    Location = <Location>
    ResourceGroupName = <ResourceGroupName>
    AddressPrefix = '10.0.0.0/16'
    Subnet = $subnet 
}
$vnet = New-AzVirtualNetwork @VnetArgs

次に、インフラストラクチャサブネット ID に対してクエリを実行します。

Azure CLI
Azure PowerShell

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:]'`

$InfrastructureSubnet=(Get-AzVirtualNetworkSubnetConfig -Name $SubnetArgs.Name -VirtualNetwork $vnet).Id

最後に、--zone-redundant パラメーターを使用して環境を作成します。この場所は、仮想ネットワークの作成時に使用した場所と同じである必要があります。

Azure CLI
Azure PowerShell

az containerapp env create \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --___location "<LOCATION>" \
  --infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
  --zone-redundant

Container Apps 環境には Log Analytics ワークスペースが必要です。次のコマンドを実行すると、Log Analytics ワークスペースが作成され、ワークスペース ID とプライマリ共有キーが環境変数に保存されます。

$WorkspaceArgs = @{
    Name = 'myworkspace'
    ResourceGroupName = <ResourceGroupName>
    Location = <Location>
    PublicNetworkAccessForIngestion = 'Enabled'
    PublicNetworkAccessForQuery = 'Enabled'
}
New-AzOperationalInsightsWorkspace @WorkspaceArgs
$WorkspaceId = (Get-AzOperationalInsightsWorkspace -ResourceGroupName <ResourceGroupName> -Name $WorkspaceArgs.Name).CustomerId
$WorkspaceSharedKey = (Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName <ResourceGroupName> -Name $WorkspaceArgs.Name).PrimarySharedKey

環境を作成するために、次のコマンドを実行します。

$EnvArgs = @{
    EnvName = <EnvironmentName>
    ResourceGroupName = <ResourceGroupName>
    Location = <Location>
    AppLogConfigurationDestination = "log-analytics"
    LogAnalyticConfigurationCustomerId = $WorkspaceId
    LogAnalyticConfigurationSharedKey = $WorkspaceSharedKey
    VnetConfigurationInfrastructureSubnetId = $InfrastructureSubnet
    VnetConfigurationInternal = $true
}
New-AzContainerAppManagedEnv @EnvArgs

Azure CLI を使用してゾーン冗長を確認する

注

Azure Portal には、ゾーン冗長が有効になっているかどうかが表示されません。

Container Apps 環境でゾーン冗長が有効になっていることを確認するには、az container app env show コマンドを使用します。

Azure CLI
Azure PowerShell

az containerapp env show \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --subscription <SUBSCRIPTION_ID>

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 でのリージョン間レプリケーションに関するページを参照してください。

注

選択する戦略に関係なく、デプロイ構成ファイルはソース管理に配置して、必要に応じて簡単に再デプロイできるようにします。

その他のガイダンス

次のリソースが独自のディザスターリカバリープランを作成するのに役立つ場合があります。

次のステップ

Azure での信頼性