web-dev-qa-db-ja.com

gRPC負荷分散

https://github.com/grpc/grpc/blob/master/doc/load-balancing.md の負荷分散ページを読みましたが、それでも正しいことについて混乱していますバックエンドGRPCインスタンス間のロードバランシングへのアプローチ。複数のgRPC「マイクロサービス」インスタンスをデプロイしており、他のgRPCクライアントがそれらの間でルーティングできるようにしたいと考えています。これらをkubernetes（実際にはGoogle Container Engine）のポッドとしてデプロイしています。

誰かがgRPCサーバー間でgRPCクライアントリクエストをロードバランシングする「推奨」アプローチを説明できますか？クライアントはエンドポイントを認識する必要があるようです-Container Engineに組み込まれているLoadBalancerを利用して支援することはできませんか？

kubernetesgoogle-kubernetes-enginegrpcgrpc-java
11
user3707

Kubernetesについて話すことはできませんが、gRPCの負荷分散に関しては、基本的に2つのアプローチがあります。

  1. 単純なユースケースでは、特定の名前に対して返されるアドレスのリスト（つまり、service.foo.comに対して返されるIPのリスト）でラウンドロビンを有効にできます。これを行う方法は言語に依存します。 C++の場合は grpc::ChannelArguments::SetLoadBalancingPolicyName "round_robin"を引数として（将来的には " service configuration "で選択することも可能ですが、その構成をDNSレコードにエンコードする方法の設計では、まだ確定していません）。
  2. Grpclbプロトコルを使用します。これは、より複雑な展開に適しています。この機能には c-ares DNSリゾルバー が必要で、これにより ＃11237 が導入されます（このPRはマージに非常に近いものです）。これは、オープンソースでgrpclbを機能させるために欠けている部分です。特に：
    • このドキュメント をご覧ください。バランサーとしてマークするアドレスを制御するために必要なDNS構成の変更について説明します。現在は「提案」であり、まもなくドキュメントに昇格します。これは非常に信頼できるものであり、それが ＃11237 がバランサー発見のために実装しているものです。
    • ロードバランサプロトコル を実装する通常のgRPCサーバーを（任意の言語で）作成します。これは、DNSレコードでバランサーとしてマークされているサーバーです（ 前述のドキュメント で説明されています）。これにより、クライアントのgrpclbは、バックエンドアドレスのリストを取得するために通信します（いわゆる- server_lists ）。このバランサー内のロジックを必要に応じて単純にするか複雑にするかは、あなた次第です。
    • クライアントは、チャネルを作成するときにバランサーのDNS名を使用します。また、バランサーDNS名が複数のアドレスを指している場合があることにも注意してください。それらの1つ以上がバランサーとしてマークされている場合、grpclbが使用されます。複数ある場合、どのバランサーがピックアップされますか？クライアントが最初に接続するもの。

ご不明な点がありましたらお知らせください。

8
David García Quintas

サマレンドラが述べたように

Envoy を確認できます。元はLyftで構築されたものです。

着信接続と発信接続の両方でHTTP/2とgRPCをファーストクラスでサポートしています。

  • GRPCのL7ロードバランシング
  • クラスター検出サービス（例：領事）

私たちはgojekでgRPCサービスにenvoyを使用しており、非常に高い負荷の下でも十分に機能します。

3
Mehak Kahlon

Grpcサーバー間の負荷分散では、kubernatesのデフォルトの負荷分散はL4ロードバランサーであるため役に立ちません。 L7ロードバランサーが必要になります。

なぜL7なのか？

grpcはhttp2を使用します。接続は永続的で、リクエストは同じ接続を介して送信されます。 L4ロードバランサーはtcp接続を使用して負荷分散しますが、要求レベルでのロードバランスが必要なため、L7ロードバランサーが必要になります。特に通信がgrpcサーバー間である場合。

いくつかのオプションがあります。Linkered/Envoyこのため、これらはkubernatesで適切に動作し、優れたサービスメッシュも提供します。

サービスを外部の作業に公開するには、nghttpxおよびnghttpx Ingressコントローラーを使用できます。

クライアント側のロードバランシングを使用することもできますが、良いメリットはありません。

1
Samarendra

nghttpx および nghttpx Ingress controller プロジェクトをチェックアウトすることをお勧めします。これらのプロジェクトにより、HTTP/2ストリームのL7ロードバランシングを実行できます。

Google Cloud Platformにバンドルされているエンドポイント管理に関する情報については、 https://cloud.google.com/endpoints/docs/architecture-overview もご覧ください。

0
MarkNS

AWS/ECSの場合 https://aws.Amazon.com/blogs/aws/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/ =ターゲットグループ間のラウンドロビン接続に機能します。

NLBがHTTP1でのみ実行できるヘルスチェックをリッスンするために何かを行う必要があります。また、独自のSSLを終了することもできます。

0
jdwyah