クラウドネイティブの通信パターン
ヒント
このコンテンツは eBook の「Azure 向けクラウド ネイティブ .NET アプリケーションの設計」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。
クラウドネイティブ システムを構築する場合、通信は設計上の重要な決定事項になります。 フロントエンド クライアント アプリケーションとバックエンド マイクロサービスの通信はどのように行われるのか。 バックエンド マイクロサービスの相互通信はどのように行われるのか。 クラウドネイティブ アプリケーションに通信を実装するときに考慮する必要がある原則、パターン、およびベストプラクティスは何でしょうか。
通信に関する考慮事項
モノリシック アプリケーションの場合、通信はシンプルです。 コード モジュールは、サーバー上の同じ実行可能領域 (プロセス) で一緒に実行されます。 この方法では、すべてが共有メモリ内で実行されるため、パフォーマンスが向上する可能性があります。ただし、コードが密結合されて、保守、進化、スケーリングが困難になります。
クラウドネイティブ システムでは、多数の小規模な独立したマイクロサービスを備えたマイクロサービスベースのアーキテクチャが実装されます。 各マイクロサービスは個別のプロセスで実行され、通常は "クラスター" にデプロイされたコンテナー内で実行されます。
クラスターでは、仮想マシンのプールがグループ化されて、高可用性環境が形成されます。 これらは、コンテナー化されたマイクロサービスのデプロイと管理を担当するオーケストレーション ツールを使用して管理されます。 図 4-1 は、フル マネージドの Azure Kubernetes サービスを使用して Azure クラウドにデプロイされた Kubernetes クラスターを示しています。
図 4-1 Azure の Kubernetes クラスター
クラスター全体で、 microservices API と messaging テクノロジを介して相互に通信します。
多くの利点がありますが、マイクロサービスは万能ではありません。 コンポーネント間のローカルのインプロセス メソッド呼び出しがネットワーク呼び出しに置き換えられています。 各マイクロサービスは、ネットワーク プロトコルを介して通信する必要があります。これにより、システムの複雑さが増します。
- ネットワークの輻輳、待機時間、一時的な障害が、恒常的な問題となります。
- 回復性 (失敗した要求の再試行) が不可欠です。
- 一貫性のある状態を維持するために、一部の呼び出しがべき等である必要があります。
- 各マイクロサービスで、呼び出しが認証および承認される必要があります。
- 各メッセージをシリアル化してから逆シリアル化する必要があります。これには高いコストがかかるおそれがあります。
- メッセージの暗号化と暗号化の解除が重要になります。
Microsoft から無料で入手できるブック「.NET マイクロサービス: コンテナー化された .NET アプリケーションのアーキテクチャ」では、マイクロサービス アプリケーションの通信パターンの詳細について説明しています。 この章では、これらのパターンの概要と、Azure クラウドで利用可能な実装オプションについて説明します。
この章では、まずフロントエンド アプリケーションとバックエンド マイクロサービスの間の通信を取り上げます。 次に、バックエンド マイクロサービスによる相互通信を確認します。 ここでは、up and gRPC 通信テクノロジについて説明します。 最後に、サービス メッシュ テクノロジを使用した革新的な新しい通信パターンについて見ていきます。 また、Azure クラウドで、クラウドネイティブ通信をサポートするさまざまな種類の "支援サービス" がどのように提供されているかについても説明します。
.NET