Important
非推奨の通知: この記事は非推奨であり、更新されなくなりました。 最適なガイダンスのみが表示されるように、この記事は 2026 年 5 月に削除されます。
別のガイダンスについては、Azure アーキテクチャ センターAzure Container Apps アーキテクチャ ガイダンスを参照してください。
このガイダンスを保存する場合は、このページの左下にある PDF をダウンロードするか、GitHub からファイルをダウンロードします。
長期的な正常性と安定性のためにアプリの設計と保守に役立つAzure Container Appsの機能とサービスを確認します。
Container Apps の 制限について説明します。
ネットワーク、コンピューティング、監視、またはデータ レベルでワークロードを分離することを検討してください。
ワークロードごとのリソース消費を制御する方法について説明します。
ヘルスプローブを使用して、アプリケーションの健康状態の悪化を報告し、回復を図ります。
Dapr を使用して、外部サービスへのセキュリティで保護された接続を確立します。
ログ記録と監視を使用して、アプリケーションに関連する問題に関する分析情報を提供します。
重要なアプリケーションイベントとシステムイベント中に アラート を使用して、運用スタッフがアプリケーションの障害発生時に迅速なアクションを実行できるようにします。
使用されていない容量を最小限に抑えながら、アプリケーションへのトラフィックを処理するのに十分な容量を確保するための スケーリング戦略 を定義します。 スケーリング トリガーには、CPU またはメモリの使用量と、KEDA でサポートされているスケーラーが含まれます。
Azure Container Appsがネットワークプロキシとして使用するEnvoyを熟知してください。
ビジネス継続性とディザスター リカバリーに関する目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件に注意してください。 インフラストラクチャとアプリケーションのサービス レベル アグリーメント (SLA) を定義します。 Azure Container Apps の SLA について学ぶ。 毎月のアップタイム計算については、 SLA の詳細 セクションを参照してください。
アプリケーションの特定の要件によっては、基になる Azure プラットフォームに問題がある場合に、高可用性の手段を使用して継続的な操作を行う必要がある場合があります。 Azureでは、さまざまなゾーンとリージョンを使用して、高可用性のためのソリューションを構築できます。
Availability Zones は、Azure データセンター設計における障害分離の構成要素です。 各ゾーンには、ゾーン間で停止が発生する可能性を最小限に抑えるために、独自の電源、ネットワーク、冷却機能があります。 Availability Zonesを使用するには、各Azure リソースを特定のゾーン ("ゾーン") またはすべてのゾーン ("ゾーン冗長") にデプロイできます。
複数リージョンのソリューションでは、最高レベルの障害分離と最高の信頼性が提供されますが、多くの場合、地理的リージョン間の待機時間が長くなるため、実装が困難になります。 この待機時間により、データ レプリケーションの遅延が発生する可能性があります。 マルチリージョン設計の詳細については、Azure Mission Critical のドキュメントを参照してください。
Azure DevOpsとGitHubを使用して、開発、ビルド、デプロイのプロセスを管理する自動化された方法を提供することを検討してください。
推奨事項
環境別に分離する: 完全なリソース分離のために個別の Container Apps 環境を作成します。 リビジョンを使用してテナント固有のコンテナー アプリを作成しないでください。 詳細については、マルチテナント ソリューションのAzure Container Appsを参照してください。
コンピューティング リソースに制限を使用する: コンテナーの CPU リソースとメモリ リソース要求の制限 を使用して、環境内のコンピューティング リソースとメモリ リソースを管理します。 コンテナーの既定の制限は、コンピューティングとメモリにそれぞれ 2 vCPU と 4 GiB です。
正常性プローブを使用する: コンテナー アプリに正常性プローブを追加します。 リビジョンに
livenessProbe、readinessProbe、およびstartupProbeが含まれていることを確認します。 詳細については、Azure Container Apps の正常性プローブをご覧ください。正常性プローブを正しく構成する: 正常性プローブはエンドポイントへの呼び出しを行う役割を担い、システムが正常な状態のときに成功状態コード (通常は HTTP 2xx 範囲) を受け取ることを想定しています。 このエンドポイントでは、システムの正常性だけでなく、データベース、ストレージ、メッセージング サービスなどの重要なダウンストリーム コンポーネントの正常性に関するチェックを実行することをお勧めします。 正常性チェックの継続的な連鎖を防ぐには、ダウンストリームの正常性応答のキャッシュを短時間実装することが重要です。
広範にロギング: 警告、エラー、および重大なメッセージを検索するためのLog Analyticsクエリを作成します。
アプリケーション ログ は、コンテナー コンソール出力 (
stdout/stderr) メッセージによって生成されます。 Dapr が有効になっている場合、コンソール出力にはアプリケーション コンテナーと Dapr サイドカー メッセージの両方が含まれます。 ログ分析を使用してログにクエリを実行する方法の詳細については、ログ 監視 を確認してください。システム ログは、Azure Container Appsによって生成されます。
ビジュアル トレースを有効化: Dapr を有効にする場合は、ACA 環境レベルで `DaprAIInstrumentationKey` を構成し、Azure アプリケーション Insights アプリケーション マップでコンテナー アプリの分散トレースを視覚化します。
Application Insights SDK の使用: Application Insights SDK をアプリケーション データに 自動インストルメンテーション エージェント として使用することは、まだサポートされていません。
可用性ゾーンを使用する: 高可用性が必要な場合は、すべてのリソースで可用性ゾーンを使用します。 Container Apps がゾーン冗長であるだけでなく、データベース、ストレージ、メッセージング サービスなどの要求を満たすために必要な隣接サービスも確保します。
分散レプリケーションの使用: ディザスター リカバリー (DR) の目的で、アプリケーション のデータとソース コードが複数のAzure リージョンで使用できることを確認します。 たとえば、Azure Storage アカウントでは geo レプリケートストレージが許可され、Azure SQL データベースでは読み取りレプリカを他のリージョンに配置できます。
Automate ビルド: エンド ツー エンドの自動化を使用して、Azure Container Apps アプリケーションをビルドしてデプロイします。
コンテナー レジストリを使用する : コンテナー イメージをAzure Container Registry レジストリを各 ACA リージョンに geo レプリケートします。ディザスター リカバリー計画をテストする: 主な障害シナリオを使用して、ディザスター リカバリー計画を定期的に作成してテストします。 詳細については、「 バックアップとディザスター リカバリーのテスト」を参照してください。