このシナリオの例は、もともと Kubernetes で実行するように設計された既存のワークロードが、代わりに Azure Container Apps で実行できることを示します。 Azure Container Apps は、複雑なインフラストラクチャとコンテナー オーケストレーションを備えたブラウンフィールド ワークロードを簡素化したい場合に適しています。 このワークロードの例では、コンテナー化されたマイクロサービス アプリケーションを実行します。
例では「Azure Kubernetes Service 上のマイクロサービス アーキテクチャ」で使用されているワークロードを取り上げ、アプリケーション プラットフォームとして Azure Container Apps へリホストします。
ヒント
このアーキテクチャは、この記事で説明する設計上の選択肢の一部を示す実装例に裏付けられています。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
このシナリオでは、コンテナー イメージは Azure Container Registry から供給され、Container Apps 環境にデプロイされます。
同じ環境を共有するサービスの利点は次のとおりです。
- 内部イングレスとサービス検出
- ランタイム ログ記録用の単一の Log Analytics ワークスペース
- シークレットと証明書の安全な管理
ワークフロー サービス コンテナー アプリは、単一リビジョン モードで実行されています。 単一リビジョン モードで実行されているコンテナー アプリには、0 個のレプリカがサポートされる 1 つのリビジョンがあります。 レプリカは、アプリケーション コンテナーと必要なサイドカー コンテナーで構成されます。 この例では、サイドカー コンテナーを使用していないため、各コンテナー アプリのレプリカは単一のコンテナーを表します。 この例ではスケーリングが採用されていないため、コンテナー アプリごとに実行されるレプリカは 1 つだけです。
ワークフローでは、ハイブリッド アプローチを使用してシークレットを管理します。 マネージド ID は、そのような実装でコードを変更する必要がないサービスで使用されます。 ドローン スケジューラと配信サービスでは、ユーザー割り当てマネージド ID を使用して Azure Key Vault で認証を行い、そこに格納されているシークレットにアクセスします。 残りのサービスは、Container Apps サービスを介してアプリケーション レベルでシークレットを格納します。
この図は、ソリューションのランタイム アーキテクチャを示しています。
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
- 取り込みサービス: クライアント要求を受信し、それらをバッファー処理して、Azure Service Bus 経由でワークフロー サービスに送信します。
- ワークフロー サービス: Azure Service Bus からのメッセージを使用し、基になるサービスにそれらをディスパッチします。
- パッケージ サービス: パッケージを管理します。
- ドローン スケジューラ サービス: ドローンをスケジュールし、フライト中にドローンを監視します。
- 配送サービス: スケジュール済みの配送や輸送中の配送を管理します。
コンポーネント
ドローン配送サービスでは、一連の Azure サービスを相互に連携させることができます。
Azure Container Apps
Azure Container Apps は主要なコンポーネントです。
これらの機能は、以前の AKS アーキテクチャの複雑さの多くを置き換えます。
- 組み込みのサービス検出
- フル マネージド HTTP および HTTP/2 エンドポイント
- 統合された負荷分散
- ログ記録と監視
- KEDA を利用した HTTP トラフィックまたはイベントに基づく自動スケーリング (Kubernetes ベースのイベント ドリブン自動スケーリング)
- アプリケーションのアップグレードとバージョン管理
外部ストレージとその他のコンポーネント
Azure Key Vault サービス。API キー、パスワード、証明書などの機密情報を安全に格納し、それらにアクセスすることができます。
Azure Container Registry には、プライベート コンテナー イメージが格納されます。 Docker Hub などの他のコンテナー レジストリも使用できます。
Azure Cosmos DB では、オープンソースの Azure Cosmos DB for MongoDB を使ってデータが格納されます。 マイクロサービスは通常ステートレスであり、その状態は外部データ ストアに書き込まれます。 Azure Cosmos DB は、MongoDB および Cassandra 用のオープンソース API を使用する NoSQL データベースです。
Azure Service Bus では、信頼性の高いサービスとしてのクラウド メッセージングとシンプルなハイブリッド統合が実現されます。 Service Bus では、マイクロサービス アプリケーションで一般的な非同期メッセージング パターンがサポートされます。
Azure Cache for Redis ではアプリケーション アーキテクチャにキャッシュ レイヤーを追加して、負荷が高いトラフィックの速度とパフォーマンスを向上させます。
Azure Monitor は、アプリケーションからメトリックとログを収集して格納します。 このデータは、アプリケーションを監視したり、アラートやダッシュボードを設定したり、障害の根本原因分析を実行したりするために使用します。 このシナリオでは、Log Analytics ワークスペースを使用して、インフラストラクチャとアプリケーションを包括的に監視します。
Application Insights では、拡張可能なアプリケーション パフォーマンス管理 (APM) と、サービスの監視が提供されます。 アプリを監視し、データを Azure Monitor に送信するために、各サービスは Application Insights SDK を使用してインストルメント化されます。
アプリケーションを構成してデプロイするための Bicep テンプレート。
代替
この例の別のシナリオは、Kubernetes を使用した Fabrikam Drone Delivery アプリケーションです。これは、Azure Kubernetes Service (AKS) Fabrikam Drone Delivery リポジトリの GitHub で入手できます。
シナリオの詳細
Azure Container Apps を使用すると、お客様の会社でマイクロサービス コンテナーのデプロイと管理を簡略化できます。 Container Apps では、最新のアプリケーションをビルドおよびデプロイするためのフル マネージド サーバーレス環境が提供されます。
Fabrikam, Inc. (架空の会社) は、ユーザーが配送用の商品を受け取るためにドローンを要求するドローン配送アプリケーションを実装しています。 顧客が集荷のスケジュールを設定すると、バックエンド システムによってドローンが割り当てられ、推定配送時刻がユーザーに通知されます。
Azure Kubernetes Service (AKS) クラスターにマイクロサービス アプリケーションがデプロイされました。 しかし、Fabrikam チームは AKS の高度な機能や AKS プラットフォーム固有の機能を活用していませんでした。 最終的には、それほど多くのオーバーヘッドをかけることなく、アプリケーションを Azure Container Apps に移行しました。 ソリューションを Azure Container Apps に移行したことで、Fabrikam は次のようなことを実現できました。
- アプリケーションをほぼそのまま移行: AKS から Azure Container Apps にアプリケーションを移行した際に、コード変更を最小限に抑えることができました。
- Bicep テンプレートを使用したインフラストラクチャとワークロード両方のデプロイ: アプリケーション コンテナーのデプロイに Kubernetes YAML マニフェストは不要でした。
- マネージド イングレスによるアプリケーションの公開: インジェスト サービスを公開する外部の https ベース イングレスに対するサポートが組み込まれており、独自のイングレスを構成する必要がありませんでした。
- ACR (Azure Container Registry) からコンテナー イメージをプルする: Azure Container Apps では、特定の基本イメージまたはレジストリは必要ありません。
- アプリケーション ライフサイクルの管理: リビジョン機能では、特定のコンテナー アプリの複数のリビジョンの実行と、A/B テストまたはブルー/グリーン デプロイ シナリオにおけるそれらのリビジョン間でのトラフィックの分割がサポートされています。
- マネージド ID の使用: Fabrikam チームはマネージド ID を使用して、Azure Key Vault と Azure Container Registry で認証することができました。
考えられるユース ケース
- 管理を簡素化し、コンテナー オーケストレーターの実行の複雑さを回避するために、ブラウンフィールド マイクロサービス ベースのアプリケーションをサービスとしてのプラットフォーム (PaaS) にデプロイします。
- ネイティブのスケールツーゼロをサポートするプラットフォームに、コンテナー化されたサービスを移行することによって、操作と管理を最適化します。
- ワークフロー サービスなど、実行時間の長いバックグラウンド プロセスを単一リビジョン モードで実行します。
Azure Container Apps のその他の一般的な用途は次のとおりです。
- サーバーレスの使用量ベースのプラットフォームで、コンテナー化されたワークロードを実行する
- KEDA でサポートされている HTTP/HTTPS トラフィックやイベント ドリブン トリガーに基づいて、アプリケーションを自動スケーリングする
- コンテナー化されたアプリケーションのメンテナンス オーバーヘッドを最小限に抑える
- API エンドポイントのデプロイ
- バックグラウンド処理アプリケーションのホスティング
- イベント 駆動型処理の処理
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性
Container Apps を使用すると、アプリケーションのデプロイ、管理、保守、監視をより簡単に行うことができます。 次の主要な機能を使用して、可用性を確保できます。
- リビジョンは、ダウンタイムをゼロにしてアプリケーションの更新プログラムをデプロイするのに役立ちます。 リビジョンを使用して、アプリケーションの更新プログラムのデプロイを管理し、リビジョン間でトラフィックを分割して、青/緑のデプロイと A/B テストをサポートできます (このワークロード例では、現在使用されていません)。
- Container Apps のエンドツーエンドの監視機能を使用すると、実行中のアプリケーションを包括的に把握できます。 Container Apps は Azure Monitor と Log Analytics と統合されています。これにより、コンテナー アプリの実行を追跡し、メトリックとイベントに基づいてアラートを設定できます。
- アプリが予期せず終了すると、Container Apps サービスによって自動的に再起動されます。
- トラフィックとワークロードの増加に応じて、ニーズに合わせて自動スケーリング ルールを有効にすることができます。
- Container Apps の動的負荷分散機能は、パフォーマンスを最適化します (ただし、このワークロード例では使用されていません)。
Container Apps では、障害が発生しているコンテナーの再起動が試行され、ユーザーからハードウェアが抽出されます。 Microsoft は一時的な障害を処理し、バッキング コンピューティング リソースの高可用性を確保します。
Log Analytics と Azure Monitor によるパフォーマンス監視を使用すると、負荷の下でアプリケーションを評価できます。 メトリックとログ情報は、障害を防止し、障害が発生したときに根本原因分析を実行するために傾向を認識するために必要なデータを提供します。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティ
シークレット
- コンテナー アプリは、機密性の高い値をシークレットとして格納および取得できます。 コンテナー アプリに対してシークレットを定義すると、アプリケーションおよび関連するスケール ルールで使用できます。 複数リビジョン モードで実行している場合、すべてのリビジョンが同じシークレットを共有します。 シークレットはアプリケーション スコープの変更と見なされるため、シークレットの値を変更した場合、新しいリビジョンは作成されません。 ただし、実行中のリビジョンで新しいシークレット値を読み込むには、それらを再起動する必要があります。 このシナリオでは、アプリケーションと環境変数の値が使用されます。
- 環境変数: 機密性の高い値は、アプリケーション レベルで安全に格納できます。 環境変数が変更されると、コンテナー アプリによって新しいリビジョンが生成されます。
ネットワークのセキュリティ
- イングレス: 外部アクセスを制限するために、インジェスト サービスのみが外部イングレス用に構成されます。 バックエンド サービスには、Container Apps 環境の内部仮想ネットワーク経由でのみアクセスできます。 必要な場合にのみ、サービスをインターネットに公開します。 このアーキテクチャでは組み込みの外部イングレス機能が使用されるため、このソリューションでは、イングレス ポイントを Web アプリケーション ファイアウォール (WAF) の背後に完全に配置したり、DDoS Protection プランに含めたりすることはできません。 Web に接続するすべてのワークロードは、Web アプリケーション ファイアウォールを経由する必要があります。
- 仮想ネットワーク: 環境作成時に、カスタム仮想ネットワークを設けることができます。それ以外の場合、仮想ネットワークは自動的に生成され、Microsoft によって管理されます。 ネットワーク セキュリティ グループ (NSG) の追加やエグレス ファイアウォールへのトラフィックの強制トンネリングなど、この Microsoft が管理する仮想ネットワークを操作することはできません。 この例では、自動的に生成された仮想ネットワークを使用します。
詳しくは、Azure Container Apps のネットワーク アーキテクチャをご覧ください。
ワークロード ID
- Container Apps は Microsoft Entra マネージド ID をサポートしているため、コンテナー アプリで資格情報を管理することなく、Microsoft Entra ID によって保護されているリソース (Azure Key Vault など) に対してアプリ自体を認証できます。 コンテナー アプリでは、システム割り当てとユーザー割り当て、または両方の種類のマネージド ID を使用できます。 AD 認証をサポートしないサービスに対しては、Azure Key Vault にシークレットを格納し、マネージド ID を使用してシークレットにアクセスする必要があります。
- Azure Container Registry へのアクセスには、マネージド ID を使用します。 Azure Container Apps を使用すると、コンテナー レジストリアクセスとは異なるマネージド ID をワークロードに使用できます。 この方法は、マネージド ID に対するきめ細かいアクセス制御を実現するために推奨されます。
コストの最適化
コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コストの最適化
- Microsoft Azure Well-Architected Framework のコスト セクションには、コストに関する考慮事項が記載されています。 具体的なシナリオのコストを見積もるには、Azure 料金計算ツールを使用します。
- Azure Container Apps には、消費ベースの価格モデルが用意されています。
- Azure Container Apps では、スケールツーゼロがサポートされています。 コンテナー アプリがゼロにスケーリングされた場合、料金はかかりません。
- このシナリオでは、Azure Cosmos DB と Azure Cache for Redis が主要なコスト ドライバーです。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス
オペレーショナル エクセレンスを実現するために、Container Apps サービスには次の機能が用意されています。
- GitHub Actions 統合により、自動化された CI/CD デプロイを設定できます。
- トラフィック分割を使用したマルチリビジョン モードにより、アプリケーション コードとスケーリング ルールの変更をテストできます。
- Azure Monitor および Log Analytics との統合により、コンテナー化されたアプリケーションに関する分析情報を得ることができます。
- Log Analytics では、各 Container Apps 環境間で情報を収集するログ集計が提供されます。
パフォーマンス効率
パフォーマンス効率は、効率的な方法でユーザーの要求に合わせてワークロードをスケーリングする機能です。 詳細については、「パフォーマンス効率
このソリューションのパフォーマンスに関する考慮事項:
- ワークロードは、複数のマイクロサービス アプリケーション間で分散されます。
- 各マイクロサービスは、独立してスケーリングできるように、他のマイクロサービスとは何も共有されず独立しています。
- ワークロードが増加したら、自動スケーリングを有効にできます。
- 要求は動的に負荷分散されます。
- CPU とメモリの使用率、帯域幅情報、ストレージ使用率などのメトリックは、Azure Monitor を介して使用できます。
このシナリオのデプロイ
Azure Container Apps サンプル シナリオ リポジトリの README.md の手順に従います。
共同作成者
Microsoft では、この記事を保持しています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Catherine Bundy | テクニカル ライター