gRPCロードバランシング

この記事では、gRPC のデプロイメントで見られるさまざまなロードバランシングシナリオについて説明します。複数のバックエンドを持つ gRPC を使用している場合は、この記事が役立ちます。

大規模な gRPC デプロイメントでは、通常、多数の同一のバックエンドインスタンスと多数のクライアントが存在します。各サーバーには一定の容量があります。ロードバランシングは、クライアントからの負荷を利用可能なサーバーに最適に分散するために使用されます。

gRPC の利点は？

gRPC は、HTTP/2 の上に実装された最新の RPC プロトコルです。HTTP/2 はレイヤー 7 (アプリケーションレイヤー) プロトコルであり、TCP (レイヤー 4 - トランスポートレイヤー) プロトコル上で実行され、TCP は IP (レイヤー 3 - ネットワークレイヤー) プロトコル上で実行されます。gRPC には、従来の HTTP/REST/JSON メカニズムに対する多くの利点があります。たとえば、

1. バイナリプロトコル (HTTP/2)
2. 1 つの接続で多数のリクエストを多重化 (HTTP/2)
3. ヘッダー圧縮 (HTTP/2)
4. 強力に型付けされたサービスとメッセージ定義 (Protobuf)
5. 多くの言語での、習慣に合ったクライアント/サーバーライブラリ実装

さらに、gRPC は、サービスディスカバリ、名前解決、ロードバランサー、トレース、モニタリングなどのエコシステムコンポーネントとシームレスに統合されます。

ロードバランシングのオプション

プロキシかクライアントサイドか？

注: プロキシロードバランシングは、一部の文献ではサーバーサイドロードバランシングとしても知られています。

プロキシとクライアントサイドのロードバランシングのどちらを選択するかは、主要なアーキテクチャ上の選択です。プロキシロードバランシングでは、クライアントはロードバランサー (LB) プロキシに RPC を発行します。LB は、RPC 呼び出しを、呼び出しの提供に必要な実際のロジックを実装している利用可能なバックエンドサーバーのいずれかに分散させます。LB は各バックエンドの負荷を追跡し、負荷を公平に分散するためのアルゴリズムを実装します。クライアント自体はバックエンドサーバーについて知りません。クライアントは信頼できない場合があります。このアーキテクチャは、通常、インターネット上のクライアントがデータセンター内のサーバーに接続できるユーザー向けサービスで利用されます。下の図に示すとおりです。このシナリオでは、クライアントは LB (#1) にリクエストを発行します。LB はリクエストをバックエンドのいずれか (#2) に渡します。バックエンドは LB に負荷を報告します (#3)。

クライアントサイドロードバランシングでは、クライアントは複数のバックエンドサーバーを認識しており、各 RPC に使用するサーバーを選択します。クライアントはバックエンドサーバーから負荷レポートを取得し、クライアントがロードバランシングアルゴリズムを実装します。より単純な構成では、サーバーの負荷は考慮されず、クライアントは利用可能なサーバー間でラウンドロビンできます。これは下の図に示されています。ご覧のとおり、クライアントは特定のバックエンド (#1) にリクエストを発行します。バックエンドは負荷情報 (#2) を返します。これは通常、クライアント RPC が実行されているのと同じ接続上で行われます。その後、クライアントは内部状態を更新します。

次の表は、各モデルの長所と短所をまとめたものです。

プロキシロードバランサーのオプション

プロキシロードバランシングは、L3/L4 (トランスポートレベル) または L7 (アプリケーションレベル) のいずれかです。トランスポートレベルのロードバランシングでは、サーバーは TCP 接続を終了し、選択したバックエンドへの別の接続を開きます。アプリケーションデータ (HTTP/2 および gRPC フレーム) は、クライアント接続とバックエンド接続の間で単純にコピーされます。L3/L4 LB は、設計上、処理が非常に少なく、L7 LB と比較してレイテンシが小さく、リソース消費が少ないため安価です。

L7 (アプリケーションレベル) ロードバランシングでは、LB は HTTP/2 プロトコルを終了し、解析します。LB は各リクエストを検査し、リクエストの内容に基づいてバックエンドを割り当てることができます。たとえば、HTTP ヘッダーの一部として送信されるセッション cookie を使用して、特定のバックエンドに関連付けることができます。これにより、そのセッションのリクエストはすべて同じバックエンドで処理されます。LB が適切なバックエンドを選択したら、そのバックエンドへの新しい HTTP/2 接続を作成します。次に、クライアントから受信した HTTP/2 ストリームを、選択したバックエンドに転送します。HTTP/2 を使用すると、LB は 1 つのクライアントからのストリームを複数のバックエンドに分散させることができます。

L3/L4 (トランスポート) vs L7 (アプリケーション)

クライアントサイドLBのオプション

シッククライアント

シッククライアントアプローチとは、ロードバランシングのインテリジェンスがクライアントに実装されていることを意味します。クライアントは、利用可能なサーバー、そのワークロード、およびサーバーを選択するために使用されるアルゴリズムを追跡する責任を負います。クライアントは通常、サービスディスカバリ、名前解決、クォータ管理などの他のインフラストラクチャと通信するライブラリを統合します。

ルックアサイドロードバランシング

注: ルックアサイドロードバランサーは、外部ロードバランサーまたはワンアームロードバランサーとしても知られています。

ルックアサイドロードバランシングでは、ロードバランシングのインテリジェンスが特別な LB サーバーに実装されます。クライアントはルックアサイド LB にクエリを発行し、LB は使用するのに最適なサーバー (複数可) を返します。サーバーの状態を維持し、LB アルゴリズムを実装するという重労働は、ルックアサイド LB に集約されます。クライアントは、LB に実装されている洗練されたアルゴリズムの上に単純なアルゴリズムを実装することを選択する場合があります。gRPC は、このモデルを使用してクライアントと LB 間の通信のためのプロトコルを定義しています。詳細については、gRPC におけるロードバランシングの ドキュメント を参照してください。

下の図はこのアプローチを示しています。クライアントは、ルックアサイド LB (#1) から少なくとも 1 つのアドレスを取得します。その後、クライアントはこのアドレスを使用して RPC (#2) を発行し、サーバーは LB に負荷レポートを送信します (#3)。ルックアサイド LB は、名前解決、サービスディスカバリなどの他のインフラストラクチャと通信します (#4)。

推奨事項とベストプラクティス

特定のデプロイメントと制約に応じて、次のことを推奨します。

• ←前へ
次へ→