次の方法で共有

Service Mesh 通信インフラストラクチャ

ヒント

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

PDF をダウンロードする

Azure eBook 用の Cloud Native .NET アプリの表紙サムネイル。

この章では、マイクロサービス通信の課題について説明しました。 開発チームは、バックエンド サービスが相互に通信する方法に敏感である必要があると述べました。 理想的には、サービス間通信が少ないほど良くなります。 ただし、バックエンド サービスは操作を完了するために互いに依存することが多いため、回避は常に可能ではありません。

同期 HTTP 通信と非同期メッセージングを実装するためのさまざまな方法について説明しました。 いずれの場合も、開発者は通信コードの実装に負担がかかります。 通信コードは複雑で時間がかかります。 不適切な決定は、パフォーマンスの重大な問題につながる可能性があります。

マイクロサービス間の通信に対するより現代的なアプローチは、Service Mesh と呼ばれる新しく急速に進化するテクノロジーを中心としています。 サービス メッシュは、サービス間の通信、回復性、および多くの横断的な問題を処理する組み込み機能を備えた構成可能なインフラストラクチャ レイヤーです。 これらの懸念に対する責任は、マイクロサービスからサービス メッシュ レイヤーに移されます。 通信はマイクロサービスから抽象化されます。

サービス メッシュの主要なコンポーネントはプロキシです。 クラウドネイティブ アプリケーションでは、通常、プロキシのインスタンスは各マイクロサービスと併置されます。 これらは別々のプロセスで実行されますが、2 つのプロセスは密接にリンクされ、同じライフサイクルを共有します。 このパターンは サイドカー パターンと呼ばれ、図 4-24 に示されています。

サイドカー付きサービスメッシュ

図 4-24 サイドカー付きサービスメッシュ

前の図では、各マイクロサービスと共に実行されるプロキシによってメッセージがどのようにインターセプトされるかに注意してください。 各プロキシは、マイクロサービスに固有のトラフィック ルールを使用して構成できます。 メッセージを理解し、そしてそれらをサービス内および外部へルーティングできます。

サービス間通信の管理に加えて、Service Mesh はサービス検出と負荷分散のサポートを提供します。

一度構成すると、サービス メッシュは非常に機能します。 メッシュは、サービス検出エンドポイントからインスタンスの対応するプールを取得します。 特定のサービス インスタンスに要求を送信し、結果の待機時間と応答の種類を記録します。 最近の要求の待機時間など、さまざまな要因に基づいて高速応答を返す可能性が最も高いインスタンスが選択されます。

サービス メッシュは、アプリケーション レベルでトラフィック、通信、ネットワークに関する問題を管理します。 メッセージと要求を理解します。 通常、サービス メッシュはコンテナー オーケストレーターと統合されます。 Kubernetes では、サービス メッシュを追加できる拡張可能なアーキテクチャがサポートされています。

第 6 章では、アーキテクチャと使用可能なオープンソース実装に関する説明を含む、Service Mesh テクノロジについて詳しく説明します。

概要

この章では、クラウドネイティブの通信パターンについて説明しました。 フロントエンド クライアントがバックエンド マイクロサービスと通信する方法を調べることから始めました。 その過程で、API Gateway プラットフォームとリアルタイム通信について説明しました。 次に、マイクロサービスが他のバックエンド サービスと通信する方法について説明しました。 ここでは、サービス間の同期 HTTP 通信と非同期メッセージングの両方について説明しました。 クラウドネイティブの世界で今後予定されているテクノロジである gRPC について説明しました。 最後に、マイクロサービス通信を効率化できる Service Mesh という新しい急速に進化するテクノロジを導入しました。

特に重点を置いたのは、クラウドネイティブ システムでの通信の実装に役立つマネージド Azure サービスです。

次に、クラウドネイティブ システムの分散データと、それが提示する利点と課題に進みます。

リファレンス

前へ次へ