Azure Container Apps と Dapr を使ってマイクロサービスをデプロイする
この記事では、Azure Container Apps で 10 個のマイクロサービスを持つ注文管理システムを実行するためのソリューションについて説明します。 また、このソリューションでは、分散アプリケーション ランタイム (Dapr) と Kubernetes イベントドリブン自動スケーリング (KEDA) を使用したイベントドリブン スケーリングを通じて、マイクロサービスのベスト プラクティスを使用します。
Dapr と Traefik は、各社の商標です。 これらのマークを使用することが、保証を意味するものではありません。
アーキテクチャ
このアーキテクチャの PowerPoint ファイルをダウンロードします。
データフロー
このソリューションでは、架空の Red Dog 注文管理システムとそのサポートする Azure インフラストラクチャについて説明します。 このアーキテクチャは、10 個の .NET Core マイクロサービス アプリケーションをホストする単一の Container Apps 環境で構成されます。 このソリューションでは、Dapr SDK を使用して、発行/サブスクライブ、状態、バインドの構成要素を介して Azure リソースと統合します。 また、サービスでは KEDA スケール ルールを使用して、イベント トリガーとゼロへのスケールシナリオに基づくスケーリングを可能にします。
次のデータフローは、前の図に対応しています。
Traefik: 対話型ダッシュボードのために、UI から会計と Makeline のサービスにユーザー要求をルーティングする基本的なプロキシです。
UI: Red Dog 注文管理システムのリアルタイム注文と集計された売上データを表示するダッシュボード。
仮想顧客: 注文サービスを介して注文する顧客をシミュレートする顧客シミュレーション プログラムです。
注文サービス: 注文を配置および管理するための作成、読み取り、更新、および削除 API。
会計サービス: 注文データを処理、格納、集計するサービスです。 これは、顧客の注文を、UI が示す意味のある売上メトリックに変換します。
レシート サービス: 監査と履歴の目的で注文のレシートを生成して格納するアーカイブ プログラムです。
ロイヤルティ サービス: 注文金額に応じて顧客のリワード ポイントを追跡することでロイヤルティ プログラムを管理するサービスです。
Makeline サービス: フルフィルメントを待機している現在の注文のキューを管理するサービス。 仮想ワーカー サービスによる注文の処理と完了を追跡します。
仮想ワーカー: 顧客の注文完了をシミュレートする "ワーカー シミュレーション" プログラムです。
| サービス | イングレス | Dapr コンポーネント | KEDA スケール規則 |
|---|---|---|---|
| Traefik | 外部 | Dapr は有効ではありません | HTTPの |
| ユーザーインターフェース | 内部 | Dapr は有効ではありません | HTTPの |
| 仮想顧客 | なし | サービス間呼び出し | 該当なし |
| 注文サービス | 内部 | Publish-subscribe: Azure Service Bus | HTTPの |
| 会計サービス | 内部 | Publish-subscribe: Service Bus | Service Bus トピックの長さ(HTTP) |
| レシート サービス | 内部 | Publish-subscribe: Service Bus バインド: Azure Blob Storage |
Service Bus トピックの長さ |
| ロイヤルティ サービス | 内部 | Publish-subscribe: Service Bus 状態: Azure Cosmos DB |
Service Bus トピックの長さ |
| Makeline サービス | 内部 | Publish-subscribe: Service Bus 状態: Azure Cache for Redis |
Service Bus トピックの長さ(HTTP) |
| 仮想ワーカー | なし | サービス間呼び出し バインド: Cron |
該当なし |
注
コンテナー アプリに Bootstrap を実装することもできます。 ただし、このサービスは 1 回実行してデータベースの作成を実行し、Azure SQL Database に必要なオブジェクトを作成した後、0 にスケーリングします。
コンポーネント
Application Insights は、ライブ アプリケーションを監視し、パフォーマンスの異常を自動的に検出するために使用できる拡張可能なアプリケーション パフォーマンス管理サービスです。 このアーキテクチャでは、Azure Monitor で Application Insights を使用してコンテナー ログを表示し、マイクロサービスからメトリックを収集します。
Blob Storage は、テキスト ファイルやバイナリ ファイルなどの大量の非構造化データを格納するためのクラウドベースのソリューションです。 このアーキテクチャでは、レシート サービスは、Dapr 出力バインドを介して Blob Storage を使用して注文のレシートを格納します。
Azure Cache for Redis は、分散型、インメモリのスケーラブル マネージド Redis Cache です。 このアーキテクチャでは、Makeline サービスの Dapr 状態ストア コンポーネントとして使用され、処理中の注文に関するデータが格納されます。
Azure Cosmos DB は、NoSQL の複数モデルのマネージド データベース サービスです。 このアーキテクチャでは、顧客のロイヤルティ データを格納するためのロイヤルティ サービスの Dapr 状態ストア コンポーネントとして使用されます。
Azure Monitor は、Azure インフラストラクチャ環境から顧客のコンテンツ データを収集、分析、操作できる統合プラットフォームです。 このアーキテクチャでは、 Application Insights で Azure Monitor を使用してコンテナー ログを表示し、マイクロサービスからメトリックを収集します。
Service Bus は、キューとパブリッシュ/サブスクライブのトピックを持つフル マネージドのエンタープライズ メッセージ ブローカーです。 このアーキテクチャでは、Dapr 発行/サブスクライブ コンポーネントの実装に Service Bus を使用します。 複数のサービスがこのコンポーネントを使います。 注文サービスはバス上でメッセージを発行し、Makeline、会計、ロイヤルティ、レシートの各サービスは、これらのメッセージをサブスクライブします。
Container Apps は、最新のアプリを大規模にビルドしてデプロイするために使用される、フル マネージドのサーバーレス コンテナー サービスです。 このアーキテクチャでは、10 個すべてのマイクロサービスを Container Apps でホストし、それらを 1 つの Container Apps 環境にデプロイします。 この環境は、システム周辺のセキュリティで保護された境界として機能します。
SQL Database は、クラウド用に構築されたインテリジェントでスケーラブルなリレーショナル データベース サービスです。 このアーキテクチャでは、 Entity Framework Core を使用してデータベースとインターフェイスする会計サービスのデータ ストアとして機能します。 ブートストラップ サービスは、データベース内の SQL テーブルを設定する役割を担います。 その後、アカウンティング サービスへの接続を確立する前に 1 回実行されます。
Traefik は、マイクロサービスのデプロイが簡単になる、最新のリバース プロキシとロード バランサーの代表的存在です。 このアーキテクチャでは、Traefik の動的構成機能を使用して、Vue.js シングルページ アプリケーションである UI からパスベースのルーティングを実行します。 この構成により、テストのためにバックエンド サービスへの直接 API 呼び出しも可能になります。
代替
このアーキテクチャでは、Vue.js API のパスベースのルーティングを有効にするために、Traefik プロキシをデプロイしています。 この目的で使用できる代替のオープンソース プロキシは多数あります。 他の 2 つの一般的なプロジェクトは NGINX と HAProxy です。
SQL Database を除くすべての Azure インフラストラクチャでは、相互運用性のために Dapr コンポーネントが使用されます。 Dapr の利点の 1 つは、コンテナー アプリのデプロイ構成を変更することで、これらすべてのコンポーネントを切り替えられることです。 このシナリオでは、Service Bus、Azure Cosmos DB、Azure Cache for Redis、Blob Storage で、使用可能な 70 を超える Dapr コンポーネントの一部が紹介されています。 Dapr ドキュメントでは、代替の 発行/サブスクライブ ブローカー、 状態ストア、 および出力バインド の一覧を入手できます。
シナリオの詳細
マイクロサービスは、広く採用されているアーキテクチャ スタイルです。 スケーラビリティ、機敏性、独立したデプロイなどの利点があります。 マイクロサービス アプリケーションをデプロイするメカニズムとしてコンテナーを使い、Kubernetes などのコンテナー オーケストレーターを使うことで運用を簡素化できます。 大規模なマイクロサービス アーキテクチャでは、多くの要因を考慮する必要があります。 通常、インフラストラクチャ プラットフォームでは、コンテナー オーケストレーターなどの複雑なテクノロジを大きく理解する必要があります。
Container Apps は、最新のアプリケーションを大規模に実行するためのフル マネージド のサーバーレス コンテナー サービスです。 これにより、基になるプラットフォームの抽象化を使用して、コンテナー化されたアプリをデプロイできます。 この方法を使用すると、複雑なインフラストラクチャを管理する必要はありません。
このアーキテクチャでは、Container Apps とマネージド バージョンの Dapr の統合が使用されます。 Dapr は、開発者が状態管理やサービス呼び出しなどの分散アプリケーションに固有の課題を克服するのに役立つオープンソース プロジェクトです。
Container Apps には、 KEDA のマネージド バージョンも用意されています。 KEDA を使用すると、Service Bus や Azure Cache for Redis などの外部サービスからの受信イベントに基づいて、コンテナーを自動的にスケーリングできます。
さらに多くの Azure ネットワーク リソースを作成することなく、Container Apps で HTTPS イングレスを有効にすることもできます。 Envoy プロキシを使うことで、トラフィック分割シナリオにも対応できます。
詳細については、「 Container Apps と他の Azure コンテナー オプションの比較」を参照してください。
この記事では、Container Apps で 10 個のマイクロサービスを持つ注文管理システムを実行するためのソリューションについて説明します。 また、このソリューションには、Dapr を使ったマイクロサービスのベスト プラクティスと、KEDA を使ったイベントドリブン スケーリングも使っています。
考えられるユース ケース
このソリューションは、分散システムにステートレスおよびステートフル マイクロサービスを使うすべての組織に適用されます。 このソリューションは、注文とフルフィルメントのシステムがあるコンシューマー向けパッケージ商品や製造業に最適です。
次のソリューションにも同様の設計があります。
- Azure Kubernetes Service (AKS) 上のマイクロサービス アーキテクチャ
- Azure Functions 上のマイクロサービス アーキテクチャ
- イベントドリブン アーキテクチャ
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Well-Architected Framework」を参照してください。
[信頼性]
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性
Container Apps は、基になるインフラストラクチャとして動作する Kubernetes 基盤上に構築されています。 回復性メカニズムは、コンテナーまたはポッド (問題がある場合) を監視および再起動する Kubernetes に組み込まれています。 回復性メカニズムには、各コンテナー アプリの複数のレプリカにトラフィックを分散する組み込みのロード バランサーが含まれます。 この冗長性により、1 つのレプリカが使用できなくなった場合でも、システムは動作を維持できます。
安全
セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
次の一覧では、このアーキテクチャで省略されているいくつかのセキュリティ機能と、その他の推奨事項と考慮事項について説明します。
このアーキテクチャでは 、プライベート エンドポイントは使用されません。これにより、仮想ネットワークから IP アドレスを割り当てることで、Azure サービスへのより安全でプライベートな接続が可能になります。 プライベート エンドポイントを使用する場合は、パブリック ネットワーク アクセスを無効にすることができます。 このアプローチでは、Microsoft バックボーン上のトラフィックが保持され、セキュリティとコンプライアンスが強化されます。
不正使用を検出して防止するには、ネットワーク アクティビティを継続的に監視する必要があります。 このアプローチを実現するには、 Azure Firewall とルート テーブルを使用します。 ルート テーブルを使用すると、仮想ネットワークを離れるトラフィックを最初にファイアウォール経由で通過できます。 このプロセスは、アーキテクチャがデータ流出攻撃に対して脆弱でないことを確認するための重要な手順です。
Web アプリケーション ファイアウォール (WAF) を使用して、一般的な脆弱性から保護します。 Azure Front Door または Azure Application Gateway を使用して、このアーキテクチャに WAF を実装 します。
Easy Auth と呼ばれる Container Apps の組み込みの認証と承認機能の使用を検討してください。Easy Auth を使用すると、ID プロバイダーを Web アプリに統合するプロセスが簡略化されます。 Web アプリの外部で認証が処理されるため、コードを大幅に変更する必要はありません。
ワークロード ID にはマネージド ID を使用します。 マネージド ID を使用すると、開発者は認証資格情報を管理する必要がなくなります。 たとえば、基本的なアーキテクチャでは、接続文字列のパスワードを使用して SQL Server に対して認証が行われます。 可能であれば、Microsoft Entra ID を使用して Azure SQL Server に対する認証を行います。
コストの最適化
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コストの最適化
このアーキテクチャのサービス コストを見積もるには、Azure 料金計算ツールを使用します。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
Azure Monitor と Application Insights を使用して、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 リソースの下にあるアプリケーション マップに移動して、次のようなマップを表示します。
詳細については、「 Container Apps でのアプリの監視」を参照してください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率
このソリューションは、イベント ドリブンスケーリングのために Container Apps の KEDA 実装に大きく依存しています。 仮想カスタマー サービスをデプロイすると、継続的に注文が行われます。 このスケーリングにより、注文サービスは HTTP KEDA スケーラーを介してスケールアップされます。 注文サービスが Service Bus 上で注文を発行すると、サービス バスの KEDA スケーラによって、会計、レシート、Makeline、ロイヤルティの各サービスがスケールアップされます。 UI と Traefik のコンテナー アプリも HTTP KEDA スケーラーを構成するので、ダッシュボードにアクセスするユーザーが増えると、アプリはスケーリングされます。
仮想顧客が動作していないときは、仮想ワーカーと Makeline の各サービスを除き、このソリューション内のすべてのマイクロサービスはゼロにスケーリングされます。 仮想ワーカーは、注文のフルフィルメントを継続的にチェックするため、スケールダウンしません。 詳細については、「 Container Apps でのスケーリング ルールの設定」を参照してください。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
プリンシパル作成者:
- Alice Gibbons | クラウド ネイティブ グローバル ブラック ベルト
その他の共同作成者:
- Lynn Orrell | プリンシパル ソリューション スペシャリスト (GBB)
- Kendall Roden | シニア プログラム マネージャー
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。