Azure Container Apps をプロビジョニングする
Note
Basic、Standard、Enterprise プランは、2025 年 3 月中旬以降非推奨になり、廃止期間は 3 年間です。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の廃止のお知らせ」を参照してください。
Standard 従量課金と専用プランは、2024 年 9 月 30 日以降に非推奨になり、6 か月後に完全にシャットダウンされます。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の Standard 従量課金および専用プランを Azure Container Apps に移行する」を参照してください。
この記事の適用対象:✅ Basic/Standard ✅ Enterprise
この記事では、Azure Container Apps の作成時に考慮すべきことの概要について説明します。
Azure Spring Apps では、アプリケーションは、フル マネージド プラットフォームを提供するサービス インスタンス内にデプロイされます。 同様に、Azure Container Apps では、コンテナー アプリは、アプリケーション用の基盤ホストとして機能する Azure Container Apps 環境内に作成されます。 どちらのサービスもホスティング環境を提供しますが、価格モデル、メンテナンス、リージョンのサポート、管理操作など、さまざまな点で異なります。 この記事では、これらの違いについて説明し、Azure Container Apps 環境の作成と管理に関するガイダンスを提供します。
前提条件
- 有効な Azure サブスクリプション。 お持ちでない場合は、無料の Azure アカウントを作成することができます。
- Azure CLI。
-
Microsoft.App
リソース プロバイダーは、Azure サブスクリプションに登録されます。 詳細については、「Azure リソース プロバイダーと種類」を参照してください。
Azure Container Apps 環境を作成する
Azure Container Apps 環境を作成するには、次のコマンドを使います。
az containerapp env create \
--resource-group $RESOURCE_GROUP \
--name $ENVIRONMENT \
--location "$LOCATION"
他の構成オプションについては、Azure Container Apps CLI のコマンドに関する記事をご覧ください。
環境を作成した後、その中にコンテナー アプリをデプロイできます。 詳しい手順については、「クイック スタート: Azure portal を使用して最初のコンテナー アプリをデプロイする」をご覧ください。
Note
コンテナー アプリ環境は、特定の条件を満たしている場合 (たとえば、環境が 90 日以上アイドル状態のままである場合)、自動的に削除されます。 すべての条件の一覧については、「Azure Container Apps 環境」の「ポリシー」の項をご覧ください。
リージョンのサポート
Azure Container Apps で現在サポートされているリージョンは、Azure Spring Apps でサポートされているリージョンと完全には一致していない場合があります。 「リージョン別の利用可能な製品」で、最新の利用可能状況を確認してください。
価格
Azure Spring Apps インスタンスの場合、料金は利用可能なプラン (Basic、Standard、または Enterprise) のいずれかに基づきます。 一方、Azure Container Apps の価格は、環境の種類と選んだワークロード プロファイルによって異なります。
環境の種類
Azure Container Apps には、Workload profile
と Consumption only
の 2 種類の環境があります。 環境の種類は、Azure Container Apps 環境の作成時に --enable-workload-profiles
パラメーターを使って指定できます。
Workload profile
環境を作成すると、--enable-workload-profiles
は既定で true
に設定されます。 それを false
に設定すると、Consumption only
環境が作成されます。
Workload profile
環境を使うと、従量課金と専用の両方のワークロード プロファイルを作成できます。
Consumption only
環境では、ワークロード プロファイルの作成はサポートされていません。
異なる種類の課金に関する考慮事項について詳しくは、「Azure Container Apps 環境」の「種類」の項をご覧ください。 独自の仮想ネットワークを使う予定の場合は、次の表で概要を示す違いを考慮してください。
環境の種類 | サポートされるプランの種類 | 説明 |
---|---|---|
ワークロード プロファイル | 従量課金、専用 | コンテナー アプリ環境でのユーザー定義ルート (UDR)、NAT Gateway 経由のエグレス、プライベート エンドポイントの作成をサポートします。 必要な最小サブネット サイズは /27 です。 |
消費量のみ | 従量課金プラン | ユーザー定義ルート (UDR)、NAT Gateway 経由のエグレス、リモート ゲートウェイ経由のピアリング、またはその他のカスタム エグレスはサポートされません。 必要な最小サブネット サイズは /23 です。 |
詳しくは、「Azure Container Apps 環境」をご覧ください。
ワークロード プロファイル
Workload profile
環境の作成を選んだ場合は、既定の Consumption
プロファイルを使うか、特定のアプリケーション要件を満たすために追加の Dedicated
プロファイルを作成することができます。 次の表では、これらのオプションについて説明します。
プロファイルの種類 | 説明 | 考えられる用途 |
---|---|---|
従量課金 | あらゆる新しい環境に自動的に追加されます。 | 特定のハードウェア要件を必要としないアプリ。 |
専用 (汎用) | メモリとコンピューティング リソースのバランスを取ります。 | 大量の CPU やメモリを必要とするアプリ。 |
専用 (メモリ最適化) | メモリ リソースが増えます。 | 大量のメモリ内データ、メモリ内機械学習モデル、またはその他の高いメモリ要件へのアクセスが必要なアプリ。 |
専用 (GPU 対応) (プレビュー) | GPU は、米国西部 3 リージョンと北ヨーロッパ リージョンで使用可能なメモリとコンピューティング リソースの増加に対応しています。 | GPU を必要とするアプリ。 |
ワークロード プロファイルの種類とサイズについて詳しくは、「Azure Container Apps のワークロード プロファイル」の「プロファイルの種類」の項をご覧ください。
コストの見積もり
アプリケーションのリソース要件に基づいて、両方のワークロード プロファイルの種類のコストを見積もるには、Azure 料金計算ツールを使います。
リソースの使用状況に大きな影響を与えるので、スケーリング構成と自動スケーリング トリガーについて検討してください。
詳しくは、Azure Container Apps のワークロード プロファイルに関する説明をご覧ください。
管理
Azure Container Apps では、基になるメンテナンスの間にアプリケーションが正常に再起動されます。 次のコマンドを使って、アプリ環境のメンテナンス期間を設定できます。
az containerapp env maintenance-config add \
--resource-group <RESOURCE_GROUP> \
--environment <ENVIRONMENT_NAME> \
--weekday Monday \
--start-hour-utc 1 \
--duration 8
Azure Spring Apps の計画メンテナンス機能と同様に、Azure Container Apps でも曜日、開始時刻、期間 (少なくとも 8 時間) を設定できます。 Container Apps は、ユーザーのメンテナンス構成に従って重要でない更新を実行します。
Note
UTC 形式の時刻は、24 時間形式を使用して表されます。 たとえば、開始時刻を午後 1 時にする場合、start-hour-utc
の値は 13 になります。
Azure Container Apps では、構成されたメンテナンス期間内にメンテナンスが開始することは保証されますが、期間内にメンテナンスが完了することは保証されません。
構成されたメンテナンス期間に従うのは、重要でない更新のみです。 重要な更新はそうではありません。
詳しくは、「Azure Container Apps の計画メンテナンス」をご覧ください。
信頼性
可用性ゾーンのサポート
ほとんどのリージョンで、Azure Spring Apps と Azure Container Apps は、利用できるリージョンでは Availability Zones を使います。 Availability Zones をサポートするリージョンの一覧については、「可用性ゾーンをサポートする Azure サービス」をご覧ください。 Azure Container Apps では、プランの種類に関係なく、同じ信頼性のサポートが提供されます。
Azure Container Apps で Availability Zones を有効にするには、コンテナー アプリ環境を作成するときに、利用できるサブネットがある仮想ネットワークを指定する必要があります。 Azure Spring Apps でも Azure Container Apps でも、ゾーン冗長を有効にするために使うパラメーターは同じです。 Availability Zones を有効にする方法について詳しくは、「Azure Container Apps の信頼性」をご覧ください。
障害復旧
Azure Spring Apps と Azure Container Apps では、ディザスター リカバリーとビジネス継続性に統一された戦略が採用されています。 詳しくは、「リージョン間のディザスター リカバリーおよび事業継続」と「Azure Container Apps の信頼性」をご覧ください。
既知の制限事項
- 開始/停止: Azure Spring Apps では、サービス インスタンス全体または個々のアプリを開始または停止できます。 これに対し、Azure Container Apps ではコンテナー アプリ レベルでのみ開始/停止機能がサポートされており、環境全体はサポートされません。
- 削除: Azure Spring Apps サービス インスタンスを削除すると、基になるすべてのリソースが自動的に削除されます。 これに対し、Azure Container Apps では、コンテナー アプリ環境を削除する前に、すべてのコンテナー アプリの削除など、まずサブリソースを削除する必要があります。