eShopOnContainers から Azure Services へのマッピング

プロジェクトはクラウドネイティブ アプリケーションとして構築されているため、必須ではありませんが、Azure は eShopOnContainers のサポートに適しています。 アプリケーションは .NET で構築されているため、Docker ホストに応じて Linux または Windows コンテナーで実行できます。 アプリケーションは、それぞれが独自のデータを持つ複数の自律マイクロサービスで構成されています。 さまざまなマイクロサービスは、単純な CRUD 操作から、より複雑な DDD および CQRS パターンまで、さまざまなアプローチを紹介します。 マイクロサービスは、HTTP 経由でクライアントと通信し、メッセージ ベースの通信を介して相互に通信します。 アプリケーションは、標準の通信プロトコルとして HTTP を採用し、Android、iOS、および Windows プラットフォームで実行される ASP.NET Core および Xamarin モバイル アプリが含まれるため、クライアント向けの複数のプラットフォームもサポートしています。 (Xamarin は 2024 年 5 月時点ではサポートされていません)。

アプリケーションのアーキテクチャを図 2-5 に示します。 左側には、モバイル、従来の Web、Web シングル ページ アプリケーション (SPA) のフレーバーに分割されたクライアント アプリがあります。 右側には、システムを構成するサーバー側コンポーネントがあり、それぞれが Docker コンテナーと Kubernetes クラスターでホストできます。 従来の Web アプリは、黄色で表示される ASP.NET Core MVC アプリケーションを利用しています。 このアプリとモバイルおよび Web SPA アプリケーションは、1 つ以上の API ゲートウェイを介して個々のマイクロサービスと通信します。 API ゲートウェイは"フロントエンドのバックエンド" (BFF) パターンに従います。つまり、各ゲートウェイは特定のフロントエンド クライアントをサポートするように設計されています。 個々のマイクロサービスは API ゲートウェイの右側に一覧表示され、ビジネス ロジックと何らかの永続化ストアの両方が含まれます。 さまざまなサービスで、SQL Server データベース、Redis Cache インスタンス、および MongoDB/CosmosDB ストアが使用されます。 右端には、マイクロサービス間の通信に使用されるシステムの Event Bus があります。

2-5. eShopOnContainers アーキテクチャ。

このアーキテクチャのサーバー側コンポーネントはすべて、Azure サービスに簡単にマップされます。

コンテナーオーケストレーションとクラスタリング

ASP.NET Core MVC アプリから個々の Catalog および Ordering マイクロサービスまで、アプリケーションのコンテナーでホストされるサービスは、Azure Kubernetes Service (AKS) でホストおよび管理できます。 アプリケーションは Docker と Kubernetes 上でローカルに実行でき、同じコンテナーを AKS でホストされているステージング環境と運用環境にデプロイできます。 このプロセスは、次のセクションで説明するように自動化できます。

AKS は、コンテナーの個々のクラスターの管理サービスを提供します。 上のアーキテクチャ図に示すように、アプリケーションは AKS クラスター内のマイクロサービスごとに個別のコンテナーをデプロイします。 このアプローチにより、個々のサービスは、リソースの需要に応じて個別にスケーリングできます。 各マイクロサービスは個別にデプロイすることもできます。理想的には、このようなデプロイではシステムダウンタイムが発生しません。

API ゲートウェイ

eShopOnContainers アプリケーションには、複数のフロントエンド クライアントと複数の異なるバックエンド サービスがあります。 クライアント アプリケーションとそれらをサポートするマイクロサービスの間には、一対一の対応はありません。 このようなシナリオでは、セキュリティで保護された方法でさまざまなバックエンド サービスとインターフェイスするクライアント ソフトウェアを記述する場合、非常に複雑になる可能性があります。 各クライアントは、この複雑さに単独で対処する必要があり、その結果、重複が発生し、サービスの変更や新しいポリシーの実装時に更新を行う多くの場所が発生します。

Azure API Management (APIM) は、組織が一貫性のある管理しやすい方法で API を発行するのに役立ちます。 APIM は、API ゲートウェイと管理ポータル (Azure portal) と開発者ポータルの 3 つのコンポーネントで構成されます。

API ゲートウェイは API 呼び出しを受け入れ、適切なバックエンド API にルーティングします。 また、コードを変更することなく、API キーや JWT トークンの検証や API 変換などの追加サービスを提供することもできます (たとえば、古いインターフェイスを必要としているクライアントに対応するため)。

Azure portal では、API スキーマを定義し、さまざまな API を製品にパッケージ化します。 また、ユーザー アクセスの構成、レポートの表示、クォータまたは変換のポリシーの構成も行います。

開発者ポータルは、開発者のための主要なリソースとして機能します。 開発者には、API ドキュメント、対話型のテスト コンソール、および独自の使用状況に関するレポートが用意されています。 また、開発者はポータルを使用して、サブスクリプションや API キーのサポートなど、独自のアカウントを作成および管理します。

APIM を使用すると、アプリケーションは複数の異なるサービス グループを公開でき、それぞれが特定のフロントエンド クライアントのバックエンドを提供します。 複雑なシナリオでは APIM をお勧めします。 よりシンプルなニーズに合わせて、軽量 API ゲートウェイ Ocelot を使用できます。 eShopOnContainers アプリでは、Ocelot が使われます。その理由は、そのシンプルさ、およびアプリケーション自体と同じアプリケーション環境にデプロイできるためです。 eShopOnContainers、APIM、Ocelot の詳細を確認します。

アプリケーションで AKS を使用している場合のもう 1 つのオプションは、Azure Gateway イングレス コントローラーを AKS クラスター内のポッドとしてデプロイすることです。 この方法により、クラスターを Azure Application Gateway と統合し、ゲートウェイで AKS ポッドへのトラフィックを負荷分散できます。 AKS 用 Azure Gateway イングレス コントローラーの詳細について説明します。

データ

eShopOnContainers によって使用されるさまざまなバックエンド サービスには、異なるストレージ要件があります。 複数のマイクロサービスが SQL Server データベースを使用します。 Basket マイクロサービスは、永続化のために Redis Cache を利用します。 Locations マイクロサービスでは、そのデータに MongoDB API が必要です。 Azure では、これらの各データ形式がサポートされています。

SQL Server データベースのサポートのために、Azure には、単一データベースから高度にスケーラブルな SQL Database エラスティック プールまで、あらゆる製品があります。 個々のマイクロサービスは、独自の個々の SQL Server データベースと迅速かつ簡単に通信するように構成できます。 これらのデータベースは、必要に応じてスケーリングして、ニーズに応じて各マイクロサービスをサポートできます。

eShopOnContainers アプリケーションは、要求の間にユーザーの現在の買い物かごを格納します。 この側面は、Redis キャッシュにデータを格納する Basket マイクロサービスによって管理されます。 開発中は、このキャッシュをコンテナーにデプロイできますが、運用環境では Azure Cache for Redis を利用できます。 Azure Cache for Redis は、Redis インスタンスまたはコンテナーを独自にデプロイおよび管理する必要なく、高いパフォーマンスと信頼性を提供するフル マネージド サービスです。

Locations マイクロサービスは、永続化のために MongoDB NoSQL データベースを使用します。 開発中は、データベースを独自のコンテナーにデプロイできますが、運用環境では、サービスは Azure Cosmos DB の MongoDB 用 API を利用できます。 Azure Cosmos DB の利点の 1 つは、SQL API や MongoDB、Cassandra、Gremlin、Azure Table Storage などの一般的な NoSQL API など、複数の異なる通信プロトコルを利用できることです。 Azure Cosmos DB は、フル マネージドのグローバル分散データベースをサービスとして提供し、それを使用するサービスのニーズに合わせてスケーリングできます。

クラウドネイティブ アプリケーションの分散データについては、 第 5 章で詳しく説明します。

イベントバス

アプリケーションはイベントを使用して、異なるサービス間で変更を伝達します。 この機能はさまざまな実装で実装でき、ローカルでは eShopOnContainers アプリケーションで RabbitMQ が使用されます。 Azure でホストされている場合、アプリケーションはメッセージングに Azure Service Bus を利用します。 Azure Service Bus は、アプリケーションとサービスが分離された信頼性の高い非同期方式で相互に通信できるようにする、フル マネージドの統合メッセージ ブローカーです。 Azure Service Bus では、個々のキューと、パブリッシャーとサブスクライバーのシナリオをサポートするための個別の トピック がサポートされています。 eShopOnContainers アプリケーションは、Azure Service Bus のトピックを活用して、特定のメッセージに対応するために必要な他のマイクロサービスへの 1 つのマイクロサービスからのメッセージの配布をサポートします。

レジリエンス

運用環境にデプロイされると、eShopOnContainers アプリケーションは、回復性を向上させるために利用できるいくつかの Azure サービスを利用できるようになります。 アプリケーションは正常性チェックを発行します。これは Application Insights と統合して、アプリの可用性に基づいてレポートとアラートを提供できます。 Azure リソースには、バグやパフォーマンスの問題を特定して修正するために使用できる診断ログも用意されています。 リソース ログは、アプリケーションによって異なる Azure リソースが使用されるタイミングと方法に関する詳細情報を提供します。 クラウドネイティブの回復性機能の詳細については、 第 6 章を参照してください。