Azure Container Apps へのマイクロサービスのデプロイ

Azure Container Apps

Azure Cosmos DB

Azure Service Bus

このシナリオでは、もともと Kubernetes 用に設計された既存のワークロードが示されています。これは、Azure Container Apps で実行するように再プラットフォーム化されています。 Container Apps では、チームがインフラストラクチャとコンテナーのオーケストレーションを簡素化するブラウンフィールドワークロードがサポートされています。

ワークロードの例は、コンテナー化されたマイクロサービスアプリケーションです。 Azure Kubernetes Service (AKS) のマイクロサービスアーキテクチャで定義されているのと同じワークロードが再利用されます。このアーキテクチャは、Container Apps のワークロードをアプリケーションプラットフォームとして再ホストします。

Important

このアーキテクチャでは、アプリケーションコードの変更を最小限に抑え、プラットフォームの移行として AKS から Container Apps への移行にアプローチすることに重点を置いています。目標は、既存の実装をレプリケートし、移行を侵害する可能性のあるコードまたはインフラストラクチャの最適化を延期することです。

グリーンフィールドワークロードについては、「 Container Apps と Dapr を使用したマイクロサービスのデプロイ」を参照してください。

ヒント

実装例では、このアーキテクチャをサポートし、この記事で説明する設計の選択肢の一部を示します。

アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

同じ環境を共有するサービスには、次のような利点があります。

内部イングレスとサービス検出
ランタイムログ記録用の単一の Log Analytics ワークスペース
シークレットと証明書の安全な管理方法

データフロー

インジェストサービス: クライアント要求を受信し、バッファーに入れてから、Azure Service Bus に発行します。ワークロードへの唯一のイングレスポイントです。
ワークフローサービス: Service Bus からのメッセージを取り込み、バックエンドのマイクロサービスにディスパッチします。
パッケージサービス: パッケージを管理します。サービスは、Azure Cosmos DB で独自の状態を維持します。
ドローンスケジューラサービス: ドローンをスケジュールし、フライト中にドローンを監視します。サービスは、Azure Cosmos DB で独自の状態を維持します。
配信サービス: スケジュールされた配送または輸送中の配送を管理します。サービスは、Azure Managed Redis で独自の状態を維持します。
シークレットの取得: これは既存のワークロードであるため、一部のコンポーネントのみが Azure Key Vault にアクセスしてランタイムシークレットを取得します。他のサービスは、Container Apps 環境からこれらのシークレットを受け取ります。
ログとメトリック: 環境とすべてのコンテナーアプリは、Azure Monitor が機能するログとメトリックを出力し、収集して視覚化します。
コンテナーイメージ: コンテナーイメージは、AKS で以前に使用され、Container Apps 環境にデプロイされた既存の Azure Container Registry からプルされます。

コンポーネント

ワークロードでは、次の Azure サービスが相互に連携して使用されます。

Container Apps は、コンテナーのオーケストレーションと管理を簡略化するサーバーレスコンテナープラットフォームです。このアーキテクチャでは、Container Apps は、すべてのマイクロサービスのプライマリホスティングプラットフォームとして機能します。

次の機能は、以前の AKS アーキテクチャの機能の多くを置き換えます。
- 組み込みのサービス検出
- マネージド HTTP および HTTP/2 エンドポイント
- 統合された負荷分散
- ログ記録と監視
- KUbernetes ベースのイベントドリブン自動スケーリング (KEDA) を利用した HTTP トラフィックまたはイベントに基づく自動スケール
- アプリケーションのアップグレードとバージョン管理
Container Registry は、プライベートコンテナーイメージを格納および管理するためのマネージドレジストリサービスです。このアーキテクチャでは、Container Apps 環境にデプロイされているすべてのコンテナーイメージのソースです。レジストリは、AKS 実装で使用されるのと同じです。
Azure Cosmos DB は、グローバルに分散された複数モデルのデータベースサービスです。このアーキテクチャでは、ドローンスケジューラサービスはデータストアとして Azure Cosmos DB を使用します。
Azure DocumentDB は、最新のアプリケーションを構築するためのフルマネージド MongoDB 互換データベースサービスです。このアーキテクチャでは、パッケージサービスはデータストアとして Azure DocumentDB を使用します。
Service Bus は、非同期通信機能とハイブリッド統合を提供するクラウドメッセージングサービスです。このアーキテクチャでは、インジェストサービスとタスクベースのワークフローマイクロサービスの間の非同期メッセージングを処理します。既存のアプリケーションの残りのサービスは、他のサービスが HTTP 要求でそれらを呼び出すことができるように設計されています。
Azure Managed Redis はメモリ内キャッシュサービスです。このアーキテクチャでは、待機時間が短縮され、頻繁にアクセスされるドローン配信データのスループットが向上します。
Key Vault は、API キー、パスワード、証明書などのシークレットを安全に格納してアクセスするためのクラウドサービスです。このアーキテクチャでは、ドローンスケジューラと配信サービスは、ユーザー割り当てマネージド ID を使用して Key Vault で認証し、ランタイム要件に必要なシークレットを取得します。
Azure Monitor は、テレメトリデータを収集して分析する包括的な監視ソリューションです。このアーキテクチャでは、Log Analytics ワークスペースを介して、すべてのアプリケーションコンポーネントからメトリックとログを収集して格納します。このデータを使用して、アプリケーションを監視し、アラートとダッシュボードを設定し、エラーの根本原因分析を実行します。
- Application Insights は、拡張可能な監視機能を提供するアプリケーションパフォーマンス管理サービスです。このアーキテクチャでは、アプリケーションのパフォーマンスを監視するために、各サービスが Application Insights SDK でインストルメント化されます。

代替

高度な AKS マイクロサービスアーキテクチャでは、Kubernetes を使用するこの例の代替シナリオについて説明します。

シナリオの詳細

コンテナー化されたアプリケーションをホストするためのサーバーレス環境である Container Apps を使用すると、マイクロサービスコンテナーのデプロイと管理を簡略化できます。

架空の会社である Fabrikam 社は、ユーザーが配送用の商品を受け取るためにドローンを要求するドローン配送ワークロードを実装しています。顧客が集荷をスケジュールすると、バックエンドシステムによってドローンが割り当てられ、推定乗車時間がユーザーに通知されます。

マイクロサービスアプリケーションが AKS クラスターにデプロイされました。しかし、Fabrikam チームは、高度またはプラットフォーム固有の AKS 機能を利用していませんでした。アプリケーションを Container Apps に移行し、次のアクションを実行できるようにしました。

アプリケーションを AKS から Container Apps に移動するときに、最小限のコード変更を採用します。コードの変更は、新しい環境では関係のない Kubernetes ノード情報を使用してログとメトリックを拡張する可観測ライブラリに関連していました。
Bicep テンプレートを使用したインフラストラクチャとワークロード両方のデプロイ: アプリケーションコンテナーのデプロイに Kubernetes YAML マニフェストは不要でした。
マネージドイングレスを使用してアプリケーションを公開します。インジェストサービスを公開するための外部の HTTPS ベースのイングレスの組み込みサポートにより、独自のイングレスを構成する必要がなくなりました。
コンテナーレジストリからコンテナーイメージをプルします。 Container Apps は、使用可能なリポジトリに格納されているすべての Linux 基本イメージと互換性があります。
リビジョン機能を使用して、アプリケーションのライフサイクルのニーズをサポートします。特定のコンテナーアプリの複数のリビジョンを実行し、A/B テストまたは青/緑のデプロイシナリオでトラフィックを分割できます。
マネージド ID を使用して、Key Vault と Container Registry で認証します。

考えられるユースケース

管理を簡素化し、コンテナーオーケストレーターの実行の複雑さを回避するために、ブラウンフィールドマイクロサービスベースのアプリケーションをサービスとしてのプラットフォーム (PaaS) にデプロイします。ブラウンフィールドワークロードでは、次の理由により、Kubernetes デプロイよりもこのアーキテクチャを使用してコストを削減しました。

ワークロードプロファイルの選択
運用チームの 2 日目の運用タスクに費やす時間の短縮
過剰なプロビジョニングを回避する機能

注

すべてのワークロードでこのようなコスト削減が実現されるわけではありません。

Container Apps の他の一般的な用途を検討します。

サーバーレスの従量課金ベースのプラットフォームでコンテナー化されたワークロードを実行します。
KEDA でサポートされている HTTP または HTTPS トラフィックとイベントドリブントリガーに基づいてアプリケーションを自動スケーリングします。
コンテナー化されたアプリケーションのメンテナンスオーバーヘッドを最小限に抑えます。
API エンドポイントをデプロイします。
バックグラウンド処理アプリケーションをホストします。
イベント駆動型の処理を行います。

Optimizations

ワークロードチームの目標は、最小限のコード変更で既存のワークロードを Container Apps に移行することです。ただし、移行後にアーキテクチャとワークロードの実装を改善するために、いくつかの最適化を行う必要があります。

シークレット管理を改善する

ワークロードでは、ハイブリッドアプローチを使用してシークレットを管理します。マネージド ID は、マネージド ID に切り替える場合にコードを変更する必要がないサービスにのみ適用されます。ドローンスケジューラと配信サービスでは、Key Vault を使用してユーザー割り当てマネージド ID を使用して、格納されているシークレットにアクセスします。残りのサービスでは、マネージド ID を採用するためにコードを変更する必要があるため、これらのサービスは Container Apps 環境で提供されるシークレットを使用します。

環境で提供されるシークレットではなく、アプリまたはジョブ ID を使用して、マネージド ID をサポートするようにすべてのコードを更新することをお勧めします。ワークロード ID の詳細については、「 Container Apps のマネージド ID」を参照してください。

単一リビジョンモードを必要とする設計は避けてください。

ワークフローサービスコンテナーアプリは、単一リビジョンモードで実行されます。単一リビジョンモードでは、アプリには 0 個以上のレプリカでバックアップされた 1 つのリビジョンがあります。レプリカは、アプリケーションコンテナーと必要なサイドカーで構成されます。この例ではサイドカーを使用しないため、各レプリカは 1 つのコンテナーです。ワークフローサービスは、メッセージスキーマとの前方互換性のために設計されていません。 2 つの異なるバージョンのサービスを同時に実行しないでください。

Service Bus メッセージスキーマを変更する必要がある場合は、新しいワークフローサービスバージョンをデプロイする前にバスをドレインする必要があります。より良い方法は、前方互換性のためにサービスコードを更新し、マルチリビジョンモードを使用して、キューのドレインに関連するダウンタイムを減らすことです。

ジョブベースの作業を検討する

ワークフローサービスは、実行時間の長いコンテナーアプリとして実装されます。ただし、 Container Apps でジョブとして実行することもできます。 ジョブはコンテナー化されたアプリケーションであり、オンデマンドで開始され、使用可能な作業に基づいて完了まで実行された後、リソースをシャットダウンして解放します。ジョブは、継続的に実行されるレプリカよりも経済的です。キューで使用可能な作業に基づいて Container Apps ジョブとして実行するようにサービスを移行することは、実用的なオプションである場合があります。これは、一般的なキューボリュームと、ワークフローサービスが書き込まれる有限、並列化可能、およびリソース最適化の方法によって異なります。実験と検証を行って、最適なアプローチを決定します。

イングレス制御を実装する

ワークロードでは、Container Apps の組み込みの外部イングレス機能を使用して、インジェストサービスを公開します。イングレス制御アプローチでは、イングレスポイントを Web アプリケーションファイアウォール (WAF) の背後に完全に配置したり、Azure DDoS Protection プランに含めたりすることはできません。すべての Web 向けワークロードを WAF によってフロントエンドに配置する必要があります。 Container Apps 環境でこの構成を実現するには、組み込みのパブリックイングレスを無効にし、 Application Gateway または Azure Front Door を追加する必要があります。

注

ゲートウェイには意味のある正常性プローブが必要です。これにより、イングレスサービスが稼働し続け、ゼロにスケーリングされるのを防ぐことができます。

Dapr を使用して最新化する

分散アプリケーションランタイム (Dapr) と統合することで、ワークロードをさらに最新化できます。ワークロードコードと状態ストア、メッセージングシステム、サービス検出メカニズムの間に抽象化が追加されます。詳細については、「 Container Apps と Dapr を使用したマイクロサービスのデプロイ」を参照してください。 Kubernetes のワークロードで既に Dapr または一般的な KEDA スケーラーが使用されている場合、Container Apps への移行は簡単に行われ、その機能を維持できます。

ユーザーの認証と承認に移行する

ワークロードは、承認をゲートウェイに委任しません。インジェストサービスは、クライアントの承認を処理します。より良い方法は、この責任を組み込みの認証と承認機能 (多くの場合、 Easy Auth と呼ばれます) にオフロードすることです。この変更はプラットフォーム機能を利用し、インジェストマイクロサービスのカスタムコードを減らします。

考慮事項

次の考慮事項では、Microsoft Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。詳細については、「 Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性は、アプリケーションが顧客に対するコミットメントを確実に満たすことができるのに役立ちます。詳細については、「信頼性設計レビューチェックリスト」を参照してください。

Container Apps は、ワークロード内のアプリケーションのデプロイ、管理、保守、監視に役立ちます。主要な推奨事項に従うことで、信頼性を向上させることができます。一部の推奨事項は、Kubernetes からの移行中に実装されます。

リビジョンは、ダウンタイムをゼロにしてアプリケーションの更新プログラムをデプロイするのに役立ちます。リビジョンを使用して、アプリケーション更新プログラムのデプロイを管理し、リビジョン間でトラフィックを分割して、青/緑のデプロイと A/B テストをサポートできます。
Container Apps の監視機能を使用すると、環境内で実行されるコンポーネントに関する分析情報を得ることができます。 Container Apps は、Application Insights と Log Analytics と統合されます。このデータを使用して、操作を追跡し、監視システムの一部としてメトリックとイベントに基づいてアラートを設定します。

パフォーマンス監視は、負荷が高いアプリケーションを評価するのに役立ちます。メトリックとログは、傾向を認識し、障害を調査し、根本原因分析を実行するためのデータを提供します。
正常性プローブと準備プローブを使用して、起動速度の遅いコンテナーを処理し、準備が整う前にトラフィックを送信しないようにします。 Kubernetes の実装には、これらのエンドポイントが含まれています。有効なシグナルが提供される場合は、引き続き使用します。
サービスが予期せず終了すると、Container Apps によって自動的に再起動されます。ワークフローサービスがダウンストリームマイクロサービスを検出できるように、サービス検出が有効になります。回復性ポリシーを使用してタイムアウトを処理し、コードをさらに調整する必要なくサーキットブレーカーロジックを導入します。
トラフィックとワークロードの増加に応じて需要を満たす自動スケールルールを有効にします。
Container Apps の動的負荷分散とスケーリング機能を使用して、可用性を向上させます。環境のサブネットを過剰にプロビジョニングして、将来のレプリカまたはジョブに対して十分な IP アドレスが常に使用可能になるようにします。
レプリカがシャットダウンするとすべての状態が失われるため、Container Apps 環境内に状態を直接格納しないようにします。各マイクロサービスの専用状態ストアに状態を外部化します。このアーキテクチャでは、Azure Managed Redis、Azure Cosmos DB for NoSQL、Azure DocumentDB の 3 つの異なるストアに状態が分散されます。
マルチゾーントポロジを使用して、Container Apps を含むすべてのリソースをデプロイします。詳細については、「 Container Apps での可用性ゾーンのサポート」を参照してください。

非一時的なアプリケーションの最小レプリカ数を、可用性ゾーンごとに少なくとも 1 つのレプリカに設定します。一般的な運用条件下では、レプリカはリージョン内の可用性ゾーン間で確実に分散され、バランスが取られます。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。詳細については、「セキュリティ設計レビューチェックリスト」を参照してください。

シークレット

コンテナーアプリは、機密性の高い値をシークレットとして格納および取得できます。コンテナーアプリのシークレットを定義すると、アプリケーションおよび関連するすべてのスケールルールで使用できるようになります。複数リビジョンモードで実行している場合、すべてのリビジョンが同じシークレットを共有します。シークレットはアプリケーションスコープの変更と見なされるため、シークレットの値を変更しても、新しいリビジョンは作成されません。ただし、実行中のリビジョンで新しいシークレット値を読み込むには、それらを再起動する必要があります。このシナリオでは、アプリケーションと環境変数の値が使用されます。
事前共有シークレットではなく、アプリ独自のマネージド ID を使用して依存関係に対する認証を行うサービスコードを書き換える。すべての依存関係には、マネージド ID 認証をサポートする SDK があります。
機密性の高い値は、アプリケーションレベルで環境変数に安全に格納できます。環境変数が変更されると、コンテナーアプリによって新しいリビジョンが作成されます。

ネットワークのセキュリティ

外部アクセスを制限するために、インジェストサービスのみが外部イングレス用に構成されます。バックエンドサービスには、Container Apps 環境の内部仮想ネットワーク経由でのみアクセスでき、内部モードとして構成されます。必要な場合にのみ、サービスをインターネットに公開します。

このアーキテクチャでは組み込みの外部イングレス機能が使用されるため、このソリューションでは、WAF の背後にイングレスポイントを完全に配置したり、DDoS Protection プランに含めたりすることはできません。 Web アプリケーションファイアウォールを使用して、Web に接続するすべてのワークロードを前面に出します。イングレスの機能強化の詳細については、「イングレス制御の実装」を参照してください。
環境を作成するときに、カスタム仮想ネットワークを指定できます。それ以外の場合、Microsoft は仮想ネットワークを自動的に生成および管理します。ネットワークセキュリティグループ (NSG) の追加やエグレスファイアウォールへのトラフィックの強制トンネリングなど、この Microsoft が管理する仮想ネットワークを操作することはできません。この例では、自動的に生成された仮想ネットワークを使用しますが、カスタム仮想ネットワークを使用すると、セキュリティ制御が強化されます。カスタムネットワークを使用すると、 NSG とユーザー定義ルート (UDR) ベースのルーティングを Azure Firewall 経由で適用できます。

イングレスのプライベートエンドポイントのサポートなど、ネットワークトポロジオプションの詳細については、「 Container Apps のネットワークアーキテクチャ」を参照してください。

ワークロード ID

Container Apps では、Microsoft Entra マネージド ID がサポートされています。これにより、コンテナーアプリで資格情報を管理することなく、アプリが Microsoft Entra ID (Key Vault など) によって保護されている他のリソースに対して自身を認証できるようになります。コンテナーアプリでは、システム割り当て ID、ユーザー割り当て ID、またはその両方を使用できます。 Microsoft Entra ID 認証をサポートしていないサービスの場合は、シークレットを Key Vault に格納し、マネージド ID を使用してシークレットにアクセスします。
Container Registry アクセスには、専用のユーザー割り当てマネージド ID を 1 つ使用します。 Container Apps では、コンテナーレジストリアクセスとは異なるマネージド ID をワークロード操作に使用できます。この方法では、きめ細かなアクセス制御が提供されます。ワークロードに複数の Container Apps 環境がある場合は、インスタンス間で ID を共有しないでください。
ワークロード ID のシステム割り当てマネージド ID を使用して、ID のライフサイクルをワークロードコンポーネントのライフサイクルに関連付けます。

その他のセキュリティに関する推奨事項

このワークロードの Kubernetes 実装は、 Microsoft Defender for Containers 機能を使用して保護を提供します。このアーキテクチャでは、Defender for Containers はコンテナーレジストリ内のコンテナーの脆弱性のみを評価します。 Defender for Containers では、Container Apps のランタイム保護は提供されません。ランタイム保護が要件である場合は、Microsoft 以外のセキュリティソリューションで補足を評価します。
共有 Container Apps 環境ではワークロードを実行しないでください。これらのマイクロサービスへのアクセスを必要としない他のワークロードまたはコンポーネントからセグメント化します。個別の Container Apps 環境を作成します。 Container Apps 環境で実行されるアプリとジョブは、内部イングレスが有効になっている環境で実行されている任意のサービスを検出して到達できます。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。詳細については、「コストの最適化設計レビューチェックリスト」を参照してください。

ワークロードの価格見積もりの例を確認します。 Azure 料金計算ツールを使用します。構成は異なるため、シナリオに合わせて調整します。
このシナリオでは、Azure Cosmos DB、Azure Managed Redis、Service Bus Premium が主なコストドライバーです。
通常、消費する CPU とメモリの量が少ないコンテナーの場合は、まず消費ワークロードプロファイルを評価します。使用量に基づいて消費プロファイルのコストを見積もり、ベースラインコストデータを収集し、他のプロファイルを評価するのに役立ちます。たとえば、高度に予測可能で安定した使用状況を持ち、専用ノードを共有できるコンポーネントには、専用のワークロードプロファイルを使用できます。コストの最適化のために、各専用プロファイルに対して 3 つのノードの倍数を維持して、十分なコンピューティングホストと可用性ゾーン間のレプリカ分散を確保します。
コンポーネントをゼロにスケーリングし、必要なときにのみ支払うことができるようにすることで、非アクティブな期間中のコンピューティングコストを排除します。この方法により、使用量が変動するアプリや使用頻度の低いアプリの費用が削減されます。健康チェックは通常、完全にゼロまでスケールダウンするのを防ぎます。アーキテクチャでは、ワークフローサービスをジョブとして再実装することにより、アイドル状態中にスケールをゼロまで縮小するメリットを活用することができます。この方法は、従量課金プランを使用できるワークロードとうまく組み合わせています。
リージョン間のネットワーク料金を回避するには、状態ストアやコンテナーレジストリなどのすべてのコンポーネントを同じリージョンにデプロイします。

オペレーショナルエクセレンス

オペレーショナルエクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。詳細については、「オペレーショナルエクセレンス設計レビューチェックリスト」を参照してください。

GitHub Actions または Azure Pipelines 統合を使用して、自動化された継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを設定します。
トラフィック分割でマルチリビジョンモードを使用して、ワークロードコードとスケールルールの変更をテストします。
Application Insights および Log Analytics と統合して、ワークロードに関する分析情報を提供します。ワークロードの残りのコンポーネントと同じ Log Analytics ワークスペースを使用して、すべてのワークロードの分析情報をまとめておきます。
Bicep や Terraform などのコードとしてのインフラストラクチャ (IaC) を使用して、すべてのインフラストラクチャデプロイを管理します。デプロイには、Container Apps 環境、コンテナーレジストリ、マイクロサービス状態ストアが含まれます。マイクロサービスデプロイパイプラインは、多くの場合、同様のライフサイクルを共有しないため、インフラストラクチャパイプラインから分離します。 Azure インフラストラクチャの宣言型パイプラインでは、コンテナーアプリリソースを除くすべてのリソースをデプロイする必要があります。
コンテナーアプリを作成、更新、および環境から削除するには、命令型のアプローチを使用します。リビジョン間でトラフィックシフトロジックを動的に調整する場合は特に重要です。デプロイワークフローで GitHub アクションまたは Azure Pipelines タスクを使用します。この命令型アプローチは、 YAML アプリ定義に基づくことができます。正常性チェックの失敗を最小限に抑えるには、コンテナーアプリをデプロイする前に、パイプラインによってコンテナーレジストリに新しいコンテナーイメージが設定されていることを常に確認してください。

Kubernetes 実装からの重要な変更は、Kubernetes オブジェクトの定義など、Kubernetes マニフェストファイル Deployment 管理からの移行です。 Kubernetes では、このマニフェストオブジェクトを使用して、マイクロサービスのデプロイがすべて同時に成功するか、あるいはすべて同時に失敗するというアトミックなアプローチを提供します。 Container Apps では、各マイクロサービスは個別にデプロイされます。デプロイパイプラインは、安全なデプロイを行うために必要なシーケンス処理とロールバック戦略を調整する役割を担います。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。詳細については、「パフォーマンス効率設計レビューチェックリスト」を参照してください。

ワークロードは、複数のマイクロサービスアプリケーション間で分散されます。
各マイクロサービスは独立しており、他のマイクロサービスと状態を共有しないため、独立したスケーリングが可能になります。
有限のプロセス実行に Container Apps ジョブを使用して、一時的なランタイムを実装し、アイドル状態のサービスのリソース消費量を削減します。ジョブを立ち上げたり停止したりすることのパフォーマンスへの影響と、コンポーネントを常に準備万全の状態に保つことのパフォーマンスへの影響を評価します。
自動スケールが有効になっています。可能な場合は、メトリックベースのスケーリングよりもイベントベースのスケーリングを優先します。たとえば、ワークフローサービスをサポートするように設計されている場合は、Service Bus キューの深さに基づいてスケーリングできます。既定の自動スケーラーは、HTTP 要求に基づいています。再プラットフォーム化中は、同じスケーリングアプローチから開始し、後でスケーリングの最適化を評価することが重要です。
要求は、リビジョンの使用可能なレプリカに動的に負荷分散されます。
CPU、メモリ、帯域幅情報、ストレージの使用率などのメトリックは、Azure Monitor を通じて利用できます。

このシナリオのデプロイ

Container Apps サンプルシナリオリポジトリの README.md の手順に従います。

共同作成者

Microsoft では、この記事を保持しています。次の共同作成者がこの記事を書きました。

貢献：

ジュリアン・ストレーブル |クラウドソリューションアーキテクト
Steve Caravajal |クラウドソリューションアーキテクト
Simon Kurtz |クラウドソリューションアーキテクト

次の手順

Container Apps のドキュメント

フィードバック

このページはお役に立ちましたか?