フロントエンド クライアント通信

ヒント

このコンテンツは、Azure 用のクラウド ネイティブ .NET アプリケーションの設計に関する電子ブックからの抜粋であり、.NET Docs またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できます。

PDF をダウンロードする

クラウドネイティブ システムでは、フロントエンド クライアント (モバイル、Web、デスクトップ アプリケーション) は、独立したバックエンド マイクロサービスと対話するための通信チャネルを必要とします。

オプションは何ですか?

物事をシンプルにするために、図 4-2 に示すように、フロントエンド クライアントはバックエンド マイクロサービスと 直接通信 できます。

図 4-2 クライアントからサービスへの直接通信

この方法では、各マイクロサービスには、フロントエンド クライアントからアクセスできるパブリック エンドポイントがあります。 運用環境では、マイクロサービスの前にロード バランサーを配置し、トラフィックを比例的にルーティングします。

実装は簡単ですが、ダイレクト クライアント通信は単純なマイクロサービス アプリケーションでのみ許容されます。 このパターンでは、フロントエンド クライアントとコア バックエンド サービスが緊密に結合され、次のような多くの問題が発生します。

• バックエンドサービスのリファクタリングに対するクライアントの感受性。
• コア バックエンド サービスが直接公開されるにつれて、より広範な攻撃対象領域が発生します。
• 各マイクロサービス間での横断的な懸念事項の重複。
• 過度に複雑なクライアント コード - クライアントは複数のエンドポイントを追跡し、回復性のある方法でエラーを処理する必要があります。

代わりに、広く受け入れられるクラウド設計パターンは、フロントエンド アプリケーションとバックエンド サービスの間に API Gateway サービスを実装することです。 パターンを図 4-3 に示します。

図 4-3 API ゲートウェイ パターン

前の図では、API Gateway サービスがバックエンド コア マイクロサービスを抽象化する方法に注意してください。 Web API として実装され、 リバース プロキシとして機能し、受信トラフィックを内部マイクロサービスにルーティングします。

ゲートウェイは、内部サービスのパーティション分割とリファクタリングからクライアントを絶縁します。 バックエンドサービスを変更した場合は、クライアントに影響を与えることなく、ゲートウェイで調整を行うことができます。 また、アイデンティティ、キャッシュ、回復性、測定、制限など、複数領域にまたがる課題への対策の最前線でもあります。 これらの横断的な懸念事項の多くは、バックエンド コア サービスからゲートウェイにオフロードできるため、バックエンド サービスが簡略化されます。

API ゲートウェイをシンプルかつ高速に保つように注意する必要があります。 通常、ビジネス ロジックはゲートウェイから保持されます。 複雑なゲートウェイはボトルネックになり、最終的にはモノリス自体になるリスクがあります。 大規模なシステムでは、多くの場合、クライアントの種類 (モバイル、Web、デスクトップ) またはバックエンド機能によってセグメント化された複数の API ゲートウェイが公開されます。 フロントエンドのバックエンド パターンは、複数のゲートウェイを実装するための方向を提供します。 パターンを図 4-4 に示します。

図 4-4. フロントエンド用バックエンドのパターン

前の図では、クライアントの種類 (Web、モバイル、デスクトップ アプリ) に基づいて、受信トラフィックが特定の API ゲートウェイに送信される方法に注意してください。 この方法は、各デバイスの機能がフォーム ファクター、パフォーマンス、および表示の制限によって大きく異なるため、理にかなっています。 通常、モバイル アプリケーションでは、ブラウザーやデスクトップ アプリケーションよりも少ない機能が公開されます。 各ゲートウェイは、対応するデバイスの機能と一致するように最適化できます。

Simple Gateways

まず、独自の API Gateway サービスを構築できます。 GitHub を簡単に検索すると、多くの例が提供されます。

単純な .NET クラウドネイティブ アプリケーションの場合は、 Ocelot Gateway を検討できます。 .NET マイクロサービス用に作成されたオープン ソースは、軽量で高速でスケーラブルです。 他の API ゲートウェイと同様に、その主な機能は、受信 HTTP 要求をダウンストリーム サービスに転送することです。 さらに、.NET ミドルウェア パイプラインで構成できるさまざまな機能もサポートしています。

YARP (さらに別のリバース プロキシ) は、Microsoft 製品チームのグループが率いるもう 1 つのオープン ソースリバース プロキシです。 NuGet パッケージとしてダウンロード可能な YARP は、ミドルウェアとして ASP.NET フレームワークにプラグインし、高度にカスタマイズできます。 YARP には、さまざまな使用例が 記載されています 。

エンタープライズ クラウドネイティブ アプリケーションの場合、作業をすぐに開始するのに役立つマネージド Azure サービスがいくつかあります。

Azure Application Gateway

単純なゲートウェイ要件については、 Azure Application Gateway を検討できます。 Azure PaaS サービスとして使用でき、URL ルーティング、SSL 終了、Web アプリケーション ファイアウォールなどの基本的なゲートウェイ機能が含まれています。 このサービスでは、 レイヤー 7 の負荷分散機能が サポートされています。 レイヤー 7 では、低レベルの TCP ネットワーク パケットだけでなく、HTTP メッセージの実際のコンテンツに基づいて要求をルーティングできます。

この本では、 Kubernetes でのクラウドネイティブ システムのホスティングについて説明します。 コンテナー オーケストレーターである Kubernetes は、コンテナー化されたワークロードのデプロイ、スケーリング、運用上の問題を自動化します。 Azure Application Gateway は、 Azure Kubernetes Service クラスターの API ゲートウェイとして構成できます。

Application Gateway イングレス コントローラーを使用すると、Azure Application Gateway を Azure Kubernetes Service と直接連携させることができます。 図 4.5 にアーキテクチャを示します。

図 4-5 Application Gateway イングレス コントローラー

Kubernetes には、 イングレスと呼ばれる HTTP (レベル 7) 負荷分散をサポートする組み込み機能が含まれています。 イングレスは、AKS 内のマイクロサービス インスタンスを外部に公開する方法に関する一連の規則を定義します。 前の図では、イングレス コントローラーはクラスター用に構成されたイングレス ルールを解釈し、Azure Application Gateway を自動的に構成します。 これらの規則に基づいて、Application Gateway は、AKS 内で実行されているマイクロサービスにトラフィックをルーティングします。 イングレス コントローラーは、イングレス ルールの変更をリッスンし、Azure Application Gateway に適切な変更を加えます。

Azure API Management

中規模から大規模のクラウド ネイティブ システムの場合は、 Azure API Management を検討できます。 これは、API Gateway のニーズを解決するだけでなく、完全な機能を備えた開発者および管理エクスペリエンスを提供するクラウドベースのサービスです。 API Management を図 4-6 に示します。

図 4-6 Azure API Management

まず、API Management は、構成可能なルールとポリシーに基づいてバックエンド サービスへの制御されたアクセスを許可するゲートウェイ サーバーを公開します。 これらのサービスは、Azure クラウド、オンプレミス のデータ センター、またはその他のパブリック クラウドに配置できます。 API キーと JWT トークンによって、誰が何を実行できるかが決まります。 すべてのトラフィックは分析目的でログに記録されます。

開発者向けに、API Management には、サービス、ドキュメント、およびそれらを呼び出すためのサンプル コードへのアクセスを提供する開発者ポータルが用意されています。 開発者は、Swagger/Open API を使用してサービス エンドポイントを検査し、その使用状況を分析できます。 このサービスは、主要な開発プラットフォーム (.NET、Java、Golang など) で機能します。

パブリッシャー ポータルでは、管理者が API を公開し、その動作を管理する管理ダッシュボードが公開されます。 サービス アクセスを許可し、サービス正常性を監視し、サービス テレメトリを収集できます。 管理者は、動作に影響を与える ポリシー を各エンドポイントに適用します。 ポリシー は、サービス呼び出しごとに順番に実行される事前に構築されたステートメントです。 ポリシーは、受信呼び出し、発信呼び出し、またはエラー時に呼び出されるように構成されます。 ポリシーは、ポリシーを組み合わせるときに決定論的な順序付けを有効にするように、さまざまなサービス スコープで適用できます。 この製品には、多数の事前構築済み ポリシーが付属しています。

ポリシーがクラウドネイティブ サービスの動作に与える影響の例を次に示します。

• サービス アクセスを制限します。
• 認証を適用します。
• 必要に応じて、1 つのソースからの呼び出しを抑制します。
• キャッシュを有効にします。
• 特定の IP アドレスからの呼び出しをブロックします。
• サービスのフローを制御します。
• 要求を SOAP から REST に変換するか、XML から JSON などの異なるデータ形式間で変換します。

Azure API Management では、クラウドまたはデータ センター内の任意の場所でホストされているバックエンド サービスを公開できます。 クラウドネイティブ システムで公開できるレガシ サービスの場合、REST API と SOAP API の両方がサポートされます。 他の Azure サービスも API Management を使用して公開できます。 Azure Service Bus や Azure Logic Apps などの Azure バッキング サービスの上にマネージド API を配置できます。 Azure API Management には、組み込みの負荷分散サポートは含まれていないので、負荷分散サービスと組み合わせて使用する必要があります。

Azure API Management は、次の 4 つの異なるレベルで利用できます。

• ディベロッパー
• ベーシック
• スタンダード
• プレミアム

開発者レベルは、非運用環境のワークロードと評価用です。 他のレベルでは、段階的により多くの電力、機能、およびより高いサービス レベル アグリーメント (SLA) が提供されます。 Premium レベルでは、 Azure Virtual Network と 複数リージョンのサポートが提供されます。 すべてのレベルには、1 時間あたりの固定価格があります。

Azure クラウドには、Azure API Management 用の サーバーレス層 も用意されています。 従量課金レベルと呼ばれるこのサービスは、サーバーレス コンピューティング モデルを中心に設計された API Management のバリエーションです。 前述の "事前割り当て済み" 価格レベルとは異なり、従量課金レベルでは、即時プロビジョニングと従量課金制の価格が提供されます。

これにより、次のユース ケースで API Gateway の機能が有効になります。

• Azure Functions や Azure Logic Apps などのサーバーレス テクノロジを使用して実装されたマイクロサービス。
• Service Bus のキューやトピック、Azure ストレージなどの Azure バッキング サービス リソース。
• トラフィックが時折急増することがあるが、通常は低い状態であるマイクロサービス。

従量課金レベルでは、基になる同じサービス API Management コンポーネントが使用されますが、動的に割り当てられたリソースに基づいてまったく異なるアーキテクチャが採用されています。 これは、サーバーレス コンピューティング モデルと完全に一致します。

• 管理するインフラストラクチャはありません。
• 空いている容量がありません。
• 高可用性。
• 自動スケーリング。
• コストは実際の使用量に基づいています。

新しい従量課金レベルは、サーバーレス リソースを API として公開するクラウドネイティブ システムに最適です。

リアルタイム通信

リアルタイム (プッシュ) 通信は、バックエンド クラウドネイティブ システムと HTTP 経由で通信するフロントエンド アプリケーションのもう 1 つのオプションです。 金融ティッカー、オンライン教育、ゲーム、ジョブの進行状況の更新などのアプリケーションでは、バックエンドからの即時のリアルタイム応答が必要です。 通常の HTTP 通信では、新しいデータがいつ使用可能であるかをクライアントが認識する方法はありません。 クライアントは、サーバーに対して要求を継続的に ポーリング または送信する必要があります。 リアルタイム通信を使用すると、サーバーはいつでも新しいデータをクライアントにプッシュできます。

リアルタイム システムは、多くの場合、高頻度のデータ フローと多数の同時クライアント接続によって特徴付けられます。 リアルタイム接続を手動で実装すると、すぐに複雑になる可能性があり、接続されたクライアントに対するスケーラビリティと信頼性の高いメッセージングを確保するために、簡単ではないインフラストラクチャが必要になります。 Azure Redis Cache のインスタンスと、クライアント アフィニティ用にスティッキー セッションで構成されたロード バランサーのセットを自分で管理していることがわかります。

Azure SignalR Service は、クラウドネイティブ アプリケーションのリアルタイム通信を簡略化するフル マネージドの Azure サービスです。 容量のプロビジョニング、スケーリング、永続的な接続などの技術的な実装の詳細は抽象化されています。 これらは、99.9% のサービス レベル アグリーメントで対処されます。 インフラストラクチャの配管ではなく、アプリケーションの機能に重点を置いている。

有効にすると、クラウドベースの HTTP サービスは、ブラウザー、モバイル、デスクトップ アプリケーションなど、接続されているクライアントにコンテンツの更新プログラムを直接プッシュできます。 クライアントは、サーバーをポーリングしなくても更新されます。 Azure SignalR は、WebSocket、Server-Side イベント、ロング ポーリングなど、リアルタイム接続を作成するトランスポート テクノロジを抽象化します。 開発者は、接続されているクライアントのすべてまたは特定のサブセットにメッセージを送信することに重点を置く。

図 4-7 は、Azure SignalR が有効になっているクラウドネイティブ アプリケーションに接続する一連の HTTP クライアントを示しています。

図 4-7 Azure SignalR

Azure SignalR Service のもう 1 つの利点は、サーバーレス クラウドネイティブ サービスの実装です。 おそらく、コードは Azure Functions トリガーを使用してオンデマンドで実行されます。 コードではクライアントとの長い接続が維持されないため、このシナリオは難しい場合があります。 Azure SignalR Service は、サービスが既に接続を管理しているため、この状況を処理できます。

Azure SignalR Service は、Azure SQL Database、Service Bus、Redis Cache などの他の Azure サービスと密接に統合され、クラウドネイティブ アプリケーションの多くの可能性を開きます。

前へ次へ