正常かつ安定した状態が長期間保たれるようにアプリを設計し、その状態を維持するのに役立つ Azure Container Apps の機能とサービスを確認します。
Container Apps の制限について
ネットワーク、コンピューティング、監視、またはデータ レベルでワークロードを分離することを検討してください。
ワークロードのリソース消費を制御する方法を理解します。
正常性プローブを使用し、アプリケーションの正常性が悪化していることを報告させて、回復します。
Dapr を使用して、外部サービスへのセキュリティで保護された接続を確立します。
ログ記録と監視を使用して、アプリケーションに関連する問題に関する分析情報を提供します。
重要なアプリケーションやシステムのイベント中にアラートを使用して、運用スタッフがイベント アプリケーションの障害に迅速に対処できるようにします。
使用されていない容量を最小限に抑えながら、アプリケーションへのトラフィックを処理するのに十分な容量を確保するために、スケーリング戦略を定義します。 スケーリング トリガーには、CPU またはメモリの使用量と、KEDA でサポートされているスケーラーが含まれます。
Azure Container Apps では、ネットワーク プロキシとして Envoy が使用されるため、Envoy についてよく理解しておいてください。
事業継続とディザスター リカバリーに関する目標復旧時間 (RTO) と回復ポイントの目標 (RPO) の要件に注意してください。 インフラストラクチャとアプリケーションのサービス レベル アグリーメント (SLA) を定義します。 Azure Container Apps の SLA について説明します。 月間稼働率の計算の詳細については、SLA の詳細セクションを参照してください。
アプリケーションの特定の要件によっては、基になる Azure プラットフォームに問題がある場合に、高可用性の手段を使用して継続的な操作を行う必要がある場合があります。 Azure では、さまざまなゾーンとリージョンを使用して、高可用性のためのソリューションを構築できます。
Availability Zones は、Azure データセンター設計における障害の分離コンストラクトとして機能します。 ゾーン全体で停止が発生する可能性を最小限に抑えるために、各ゾーンは独自の電源、ネットワーク、冷却機能を備えています。 Availability Zones を使用するには、各 Azure リソースを特定のゾーンまたはすべてのゾーン ("ゾーン冗長") にデプロイできます。
複数リージョンのソリューションでは、最高レベルの障害分離を実現し、最高の信頼性が得られますが、多くの場合、地理的リージョン間の待機時間が長くなるため、実装が困難になります。 この待機時間により、データ レプリケーションの遅延が発生する可能性があります。 複数リージョン設計の詳細については、Azure ミッション クリティカルに関するドキュメントを参照してください。
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 Application Insights アプリケーション マップでコンテナー アプリの分散トレースを視覚化します。
Application Insights SDK を使用する: 自動インストルメンテーション エージェントとしてアプリケーション データに Application Insights SDK を使用する方法はまだサポートされていません。
可用性ゾーンを使用する: 高可用性が必要な場合は、すべてのリソースで Availability Zones を使用します。 Container Apps がゾーン冗長であるだけでなく、データベース、ストレージ、メッセージング サービスなどの要求を実行するために必要な関連するサービスもあることを確認します。
分散レプリケーションを使用する: ディザスター リカバリー (DR) の目的で、アプリケーション データとソース コードが複数の Azure リージョンで使用できることを確認します。 たとえば、Azure Storage アカウントでは geo レプリケートされるストレージが許可され、Azure SQL Database では読み取りレプリカを他のリージョンに配置することが許可されます。
ビルドを自動化する: エンド ツー エンドの自動化を使用して、Azure Container Apps アプリケーションをビルドしてデプロイします。
コンテナー レジストリを使用する: コンテナー イメージを Azure Container Registry に格納し、レジストリを各 ACA リージョンに geo レプリケーションします。
ディザスター リカバリー計画をテストする: 重大な障害のシナリオに基づいて、定期的にディザスター リカバリー計画を作成し、テストします。 詳細については、バックアップとディザスター リカバリーのテストに関するページを参照してください。