Azure Container Apps と Dapr を使ってマイクロサービスをデプロイする

この記事では、Azure Container Apps 上に 10 個のマイクロサービスがある注文管理システムを実行するソリューションについて説明します。 また、このソリューションには、Dapr を使ったマイクロサービスのベスト プラクティスと、KEDA を使ったイベントドリブン スケーリングも使っています。

Dapr と Traefik は、各社の商標です。 これらのマークを使用することが、保証を意味するものではありません。

アーキテクチャ

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

データフロー

このソリューションでは、Bicep テンプレートを使って、Reddog 注文管理システムとそれをサポートする Azure インフラストラクチャのデプロイを実行します。 このアーキテクチャは、10 個の .NET Core マイクロサービス アプリケーションをホストする 1 つの Azure Container Apps 環境で構成されています。 .NET Core Dapr SDK を使い、発行とサブスクライブ (pub/sub) と状態およびバインド構成ブロックを介して Azure リソースと統合します。 通常、Dapr を使うと、コンポーネントを柔軟に実装できますが、このソリューションは 1 つの意見に基づくものです。 また、このサービスは KEDA スケール規則も利用しており、イベント トリガーに基づくスケールやゼロへのスケール シナリオを実現できます。

次の一覧では、各マイクロサービスと、そのデプロイに使う Azure Container Apps の構成について説明しています。 コードを確認するには、GitHub 上の reddog-code リポジトリを参照してください。

1. Traefik: 対話型ダッシュボードのために、UI から会計と Makeline のサービスにユーザー要求をルーティングする基本的なプロキシです。

2. UI: Reddog 注文管理システムのリアルタイムの受注と集計売上のデータを表示するダッシュボードです。

3. 仮想顧客: 注文サービスを介して注文する顧客をシミュレートする顧客シミュレーション プログラムです。

4. 注文サービス: 注文を行い、管理するための CRUD API です。

5. 会計サービス: 注文データを処理、格納、集計するサービスです。 顧客の注文を、UI に表示される意味のあるセールス メトリックに変換します。

6. レシート サービス: 監査と履歴の目的で注文のレシートを生成して格納するアーカイブ プログラムです。

7. ロイヤルティ サービス: 注文金額に応じて顧客のリワード ポイントを追跡することでロイヤルティ プログラムを管理するサービスです。

8. Makeline サービス: 現在フルフィルメントを待機している注文のキュー管理を担当するサービスです。 仮想ワーカー サービスによる注文の処理と完了を追跡します。

9. 仮想ワーカー: 顧客の注文完了をシミュレートする "ワーカー シミュレーション" プログラムです。

10. ブートストラッパー (表示されません): 会計サービスに使うために、Entity Framework Core を使って Azure SQL Database 内のテーブルを初期化するサービスです。

Components

このソリューションでは、次のコンポーネントを使用します。

• Azure リソース グループは、Azure リソースの論理コンテナーです。 Azure portal で 1 つのリソース グループを使って、このソリューションに関連するすべてのものを構築します。
• Azure Container Apps は、モダン アプリを大規模に構築してデプロイするために使用されるフル マネージドのサーバーレス コンテナー サービスです。 このソリューションでは、10 個のマイクロサービスをすべて Azure Container Apps でホストし、1 つの Container App 環境にデプロイしています。 この環境は、システムを囲む安全な境界として機能します。
• Azure Service Bus は、キューとパブリッシュとサブスクライブのトピックを備えたフル マネージド エンタープライズ統合メッセージ ブローカーです。 このソリューションでは、Dapr pub/sub コンポーネントの実装に使います。 複数のサービスがこのコンポーネントを使います。 注文サービスはバス上でメッセージを発行し、Makeline、会計、ロイヤルティ、レシートの各サービスは、これらのメッセージをサブスクライブします。
• Azure Cosmos DB は、NoSQL、マルチモデル マネージド データベース サービスです。 これをロイヤルティ サービス用の Dapr 状態ストア コンポーネントとして使い、顧客のロイヤルティ データを格納します。
• Azure Cache for Redis は、分散型、インメモリのスケーラブル マネージド Redis Cache です。 これを Makeline サービスの Dapr 状態ストア コンポーネントとして使い、処理中の注文に関するデータを格納します。
• Azure SQL Database は、クラウド向けに構築されたインテリジェントでスケーラブルなリレーショナル データベース サービスです。 これは、会計サービスのために作成し、データベースとのインターフェイスに Entity Framework Core を使います。 ブートストラップ サービスは、データベースの SQL テーブルの設定を担当します。会計サービスへの接続を確立する前に 1 回実行されます。
• Azure Blob Storage は、テキスト ファイルやバイナリ ファイルなどの大量の非構造化データを格納します。 レシート サービスは、Dapr 出力バインドを介して BLOB ストレージを使い、注文のレシートを格納します。
• Traefik は、マイクロサービスのデプロイが簡単になる、最新のリバース プロキシとロード バランサーの代表的存在です。 このソリューションでは、Traefik の動的構成機能を使って、Vue.js のシングルページ アプリケーション (SPA) である UI からパスベースのルーティングを行います。 この構成を使うと、テスト用のバックエンド サービスへの直接の API 呼び出しも可能になります。
• Azure Monitor を使うと、Azure インフラストラクチャ環境の顧客コンテンツ データを収集、分析、操作できるようになります。 Application Insights と併用すると、コンテナー ログを表示し、マイクロサービスからメトリックを収集できます。

代替

このアーキテクチャでは、Vue.js API のパスベースのルーティングを有効にするために、Traefik プロキシをデプロイしています。 この目的で使用できる代替のオープンソース プロキシは多数あります。 一般的な 2 つのプロジェクトとして、NGINX と HAProxy があります。

Azure SQL Database を除くすべての Azure インフラストラクチャは、相互運用性のために Dapr コンポーネントを使っています。 Dapr の利点の 1 つは、コンテナー アプリのデプロイ構成を変更することで、これらすべてのコンポーネントを切り替えられることです。 このケースでは、70 種類以上ある Dapr コンポーネントの中から、Azure Service Bus、Azure Cosmos DB、Cache for Redis、BLOB Storage を選び、紹介しています。 代替の pub/sub ブローカー、状態ストア、出力バインドの一覧については、Dapr ドキュメントを参照してください。

シナリオの詳細

マイクロサービスは、高いスケーラビリティ、開発サイクルの短縮、簡素化などの利点が多数ある、ますます一般的になったアーキテクチャ スタイルです。 マイクロサービス アプリケーションをデプロイするメカニズムとしてコンテナーを使い、Kubernetes などのコンテナー オーケストレーターを使うことで運用を簡素化できます。 大規模なマイクロサービス アーキテクチャを実現するには、多くの要素を考慮する必要があります。 一般に、インフラストラクチャ プラットフォームでは、コンテナー オーケストレーターのような複雑なテクノロジを十分に理解する必要があります。

Azure Container Apps は、モダン アプリケーションを大規模に実行するためのフル マネージド サーバーレス コンテナー サービスです。 これを使って基になるプラットフォームを抽象化することで、コンテナー化されたアプリをデプロイできます。 そのため、複雑なインフラストラクチャを管理する必要はありません。 Azure Container Apps は、オープンソース テクノロジを利用しています。

このアーキテクチャは、マネージド バージョンの Distributed Application Runtime (Dapr) と統合された Azure Container Apps を使います。 Dapr は、状態管理やサービスの呼び出しなど、分散アプリケーションに固有の課題がある開発者を支援するオープン ソース プロジェクトです。

また、Azure Container Apps には、マネージド バージョンの Kubernetes Event-driven Autoscaling (KEDA) も用意されています。 KEDA を使うと、Azure Service Bus や Azure Cache for Redis などの外部サービスから受信するイベントに基づいて、コンテナーを自動スケーリングすることができます。

また、Azure ネットワーク リソースの作成を増やすことなく、Azure Container Apps で HTTPS のイングレスを有効にすることもできます。 Envoy プロキシを使うことで、トラフィック分割シナリオにも対応できます。

Azure Container Apps と Azure の他のコンテナー ホスティング プラットフォームの比較については、「Container Apps と他の Azure コンテナー オプションの比較」を参照してください。

この記事では、Azure Container Apps 上に 10 個のマイクロサービスがある注文管理システムを実行するソリューションについて説明します。 また、このソリューションには、Dapr を使ったマイクロサービスのベスト プラクティスと、KEDA を使ったイベントドリブン スケーリングも使っています。

考えられるユース ケース

このソリューションは、分散システムにステートレスおよびステートフル マイクロサービスを使うすべての組織に適用されます。 このソリューションは、注文とフルフィルメントのシステムがあるコンシューマー向けパッケージ商品や製造業に最適です。

以下の他のソリューションも設計は似ています。

• Azure Kubernetes Service (AKS) 上のマイクロサービス アーキテクチャ
• Azure Functions 上のマイクロサービス アーキテクチャ
• イベントドリブン アーキテクチャ

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

Azure Container Apps は、Kubernetes 上のバックグラウンドで実行されます。 Kubernetes には、問題が発生した場合にコンテナーまたはポッドを監視して再起動する回復メカニズムが組み込まれています。 この回復メカニズムは、組み込みのロード バランサーと連携して、各コンテナー アプリの複数のレプリカを実行します。 この冗長性があるので、ソリューションは 1 つの使用不能なインスタンスを許容できます。

Azure Monitor と Application Insights を使って Azure Container Apps を監視できます。 ポータルで各コンテナー アプリの [ログ] ペインに移動し、次の Kusto クエリを実行すると、コンテナー ログを表示できます。 この例は、Makeline サービス アプリのログを示しています。

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

また、Application Insights のアプリケーション マップには、サービスがリアル タイムでどのように通信しているかが表示されます。 次に、これらをデバッグ シナリオに使用できます。 Application Insights リソースの下のアプリケーション マップに移動すると、次のような内容が表示されます。

Azure Container Apps の監視の詳細については、Azure Container Apps でのアプリの監視に関する記事を参照してください。

コストの最適化

コストを最適化するには、不要な費用を削減し、運用効率を向上させる方法を検討します。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

このアーキテクチャのサービス コストを見積もるには、Azure 料金計算ツールを使用します。

パフォーマンス効率

パフォーマンス効率とは、需要に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

このソリューションは、イベントドリブン スケーリングのために、Azure Container Apps 内の KEDA 実装に大きく依存しています。 仮想顧客サービスをデプロイすると、継続的に注文が行われます。その結果、HTTP KEDA スケーラーを介して注文サービスがスケールアップされます。 注文サービスが Service Bus 上で注文を発行すると、サービス バスの KEDA スケーラによって、会計、レシート、Makeline、ロイヤルティの各サービスがスケールアップされます。 UI と Traefik のコンテナー アプリも HTTP KEDA スケーラーを構成するので、ダッシュボードにアクセスするユーザーが増えると、アプリはスケーリングされます。

仮想顧客が動作していないときは、仮想ワーカーと Makeline の各サービスを除き、このソリューション内のすべてのマイクロサービスはゼロにスケーリングされます。 仮想ワーカーは、注文のフルフィルメントを常に確認しているので、スケールダウンしません。 コンテナー アプリのスケーリングの詳細については、「Azure Container Apps でスケーリング ルールを設定する」を参照してください。 KEDA スケーラーの詳細については、スケーラーに関する KEDA のドキュメントを参照してください。

このシナリオのデプロイ

デプロイ手順については、GitHub 上の「Red Dog デモ: Azure Container Apps のデプロイ」を参照してください。

Red Dog Demo: マイクロサービス統合は、Azure Container Apps、App Service、Functions、API Management の統合をデモンストレーションし、インフラストラクチャをプロビジョニングするために、上記のコード アセット上に構築されたパッケージ アプリ テンプレートであり、GitHub Actions を使用してコードをデプロイします。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• Alice Gibbons | クラウド ネイティブ グローバル ブラック ベルト

その他の共同作成者:

• Kendall Roden | シニア プログラム マネージャー
• Lynn Orrell | プリンシパル ソリューション スペシャリスト (GBB)

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• Azure Container Apps ドキュメント
• Azure のコンテナー オファリングの比較
• その他の Reddog 注文管理システムの実装:
  • Azure Arc ハイブリッド デプロイ
  • AKS デプロイ
  • ローカル開発

関連リソース

• Azure Kubernetes Service 上のマイクロサービス アーキテクチャ
• 高度な Azure Kubernetes Service (AKS) マイクロサービス アーキテクチャ
• Azure Pipelines を使用した AKS アプリの CI/CD