このシナリオの例は、もともと Kubernetes で実行するように設計された既存のワークロードが、代わりに Azure Container Apps で実行できることを示します。 Azure Container Apps は、複雑なインフラストラクチャとコンテナー オーケストレーションを備えたブラウンフィールド ワークロードを簡素化したい場合に適しています。 このワークロードの例では、コンテナー化されたマイクロサービス アプリケーションを実行します。
例では「Azure Kubernetes Service 上のマイクロサービス アーキテクチャ」で使用されているワークロードを取り上げ、アプリケーション プラットフォームとして Azure Container Apps へリホストします。
ヒント
このアーキテクチャは、この記事で説明する設計上の選択肢の一部を示す実装例に裏付けられています。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
このシナリオでは、コンテナー イメージは Azure Container Registry から供給され、Container Apps 環境にデプロイされます。
同じ環境を共有するサービスの利点は次のとおりです。
- 内部イングレスとサービス検出
- ランタイム ログ記録用の単一の Log Analytics ワークスペース
- シークレットと証明書の安全な管理
ワークフロー サービス コンテナー アプリは、単一リビジョン モードで実行されています。 単一リビジョン モードで実行されているコンテナー アプリには、ゼロ対多レプリカによってサポートされる単一のリビジョンが含まれます。 レプリカは、アプリケーション コンテナーと必要なサイドカー コンテナーで構成されます。 この例では、サイドカー コンテナーを使用していないため、各コンテナー アプリのレプリカは単一のコンテナーを表します。 この例ではスケーリングを使用しないため、各コンテナー アプリで実行されるレプリカは 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 トラフィックまたはイベントに基づく自動スケーリング
- アプリケーションのアップグレードとバージョン管理
外部ストレージとその他のコンポーネント
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 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 サービスには次の機能が用意されています。
- GitHub Actions 統合により、自動化された CI/CD デプロイを設定できます。
- トラフィック分割を使用したマルチリビジョン モードにより、アプリケーション コードとスケーリング ルールの変更をテストできます。
- Azure Monitor および Log Analytics との統合により、コンテナー化されたアプリケーションに関する分析情報を得ることができます。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
このソリューションのパフォーマンスに関する考慮事項:
- ワークロードは、複数のマイクロサービス アプリケーション間で分散されます。
- 各マイクロサービスは、独立してスケーリングできるように、他のマイクロサービスとは何も共有されず独立しています。
- ワークロードが増加したら、自動スケーリングを有効にできます。
- 要求は動的に負荷分散されます。
- CPU とメモリの使用率、帯域幅情報、ストレージ使用率などのメトリックは、Azure Monitor を介して使用できます。
- Log Analytics では、各 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 が主要なコスト ドライバーです。
このシナリオのデプロイ
このシナリオをデプロイするには、Azure Container Apps シナリオ例リポジトリにある、README.md の手順に従います。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Catherine Bundy | テクニカル ライター