背景
gRPCでは主に
- Proxy Model
- Balancing-aware Client
- External Load Balancing Service
といったLBアプローチがあります。
それぞれの特徴や実装方法を調べてみました。
Load Balancingアプローチ
こちらで定義されてます。
grpc/load-balancing.md at master · grpc/grpc · GitHub
主な負荷分散のアプローチとしては以下です。
Proxy Model
LBと言われて最初に浮かぶイメージですね。
ref: https://grpc.io/blog/loadbalancing/
メリット
クライアントと独立しているため、クライアントは自身のアプリケーション実装にのみ集中できます。シンプルでPolyglot向きでもあります。
またProxy側に様々な拡張ができます（メトリクス、サーキットブレーカー、etc）。
デメリット
デメリットとしてProxy用の追加リソースが必要で、Proxy自体がスケールのボトルネックになります。
また経路が増えレイテンシも上がるのでストレージのような大量リクエストがくる環境には向かないです。
加えてL4 ProxyだとgRPCのリクエスト分散ができないのも問題となります。
Balancing-aware Client
各クライアントがどのサーバに投げるかを自身で判断する実装です。
ref: https://grpc.io/blog/loadbalancing/
メリット
Proxy Modelに比べて途中に何も挟まないので高パフォーマンスになります。
デメリット
一方で自前で実装するので多言語向きじゃないです。
リクエストを投げるサーバ選択・負荷分散ロジックなど考慮すべき点も多々ありメンテコスト高いです。
External Load Balancing Service (Lookaside Load Balancing)
上記２つのハイブリッド的なイメージですね。
複雑なLBの役割を別の外部LBサーバ（もしくはプロセス）が担当します。
クライアントは外部LBにリクエストすべきバックエンド問い合わせてからリクエストを投げます。
ref: https://grpc.io/blog/loadbalancing/
メリット
パフォーマンスとシンプルさのバランスを取ったモデル。
マイクロサービス向き。
デメリット
外部LBへの問い合わせがあるのでBalancing-aware Clientほど高パフォーマンスではない。
具体的な実装
Proxy Model
普通のLB（GCLB、ALB、NLB）を用いるか、Envoyを使って
このようにFront Proxyパターンだったり
Sidecarパターンで実現する形になると思います。
Balancing-aware Client
こちらで紹介した内容で実装できます。
External Load Balancing Service (Lookaside Load Balancing)
grpclbプロトコルを使います。ライブラリは以下が有名です。
が、既存のgrpclbプロトコルは廃止され、今後はEnvoyで使われているようなxDSプロトコル
We will be moving away from our custom load balancing protocol and adopting xDS Protocol based on Envoy xDS API.
ref: https://groups.google.com/forum/#!msg/grpc-io/0yGihF-EFQo/A4QKdXffBwAJ
なのでまだしばらくはベストプラクティスな実装方法は確立しなそうです。
まとめ
どの選択肢もメリット・デメリットがあるため「今はEnvoyが流行りだから！」という理由でなくケースに応じた手段を選択すべきということが分かりますね。
