博士

ロボ子、DatabricksがKubernetesのネットワークでクライアントサイドロードバランシングを構築したみたいじゃぞ。

ロボ子

クライアントサイドロードバランシングですか。kube-proxyの課題を解決するためでしょうか？

博士

そうじゃ！kube-proxyだと、gRPCのHTTP/2永続接続でトラフィックが偏って、tail latencyが増加するらしいのじゃ。リソースの無駄遣いにもなるからの。

ロボ子

なるほど。クライアントサイドでロードバランシングすれば、その偏りを解消できるんですね。

博士

その通り！リアルタイムなサービスディスカバリーのために、Endpoint Discovery Service (EDS)を実装したそうじゃ。Kubernetes APIから情報を取得して、gRPCクライアントにロードバランシングロジックを組み込んだらしいぞ。

ロボ子

DNSやkube-proxyをバイパスするんですね。サービス構成のライブビューを維持できるのは魅力的です。

博士

Power of Two Choices (P2C)アルゴリズムやゾーンアフィニティなどの高度な戦略も実装したみたいじゃ。賢いの。

ロボ子

P2Cは、2つのエンドポイントからランダムに選択して、負荷の少ない方を選ぶアルゴリズムですね。ゾーンアフィニティは、同じゾーン内のエンドポイントを優先する戦略でしょうか。

博士

さすがロボ子！そのおかげで、サーバー側のQPSが均等に分散して、ポッド間のレイテンシーのばらつきが減ったらしいぞ。P90レイテンシーも安定したみたいじゃ。

ロボ子

リソース効率も向上して、ポッド数を約20%削減できたんですね。素晴らしい成果です。

博士

じゃろ？でも、課題もあったみたいじゃ。新しいポッドがすぐにトラフィックを受け始めて、コールドスタートの問題が発生したらしい。

ロボ子

新しいポッドが起動してすぐに大量のトラフィックを処理するのは、確かに問題ですね。準備が整う前に過負荷になる可能性があります。

博士

CPU使用率に基づくルーティングも、信頼性が低かったみたいじゃ。クライアントライブラリへの統合でパフォーマンスは向上したけど、対応してない言語とかもあるからの。

ロボ子

ヘッドレスサービスやIstioなどのサービスメッシュも検討されたんですね。でも、それぞれ課題があって、クライアントサイドロードバランシングが最適だったと。

博士

そうそう。これからは、クロス・クラスターやクロス・リージョン・ロード・バランシングも実現したいみたいじゃ。AIユースケース向けの高度な戦略も導入するらしいぞ。

ロボ子

クライアントサイドロードバランシングは、Kubernetesのネットワークにおける重要な進化ですね。今後の発展が楽しみです。

博士

ほんとじゃの。しかし、ロボ子よ、クライアントサイドってことは、もしかしてロボ子の仕事が…

ロボ子

えっ、博士、まさか私、リストラ対象ですか！？

博士

冗談じゃ！ロボ子は私の最高の助手じゃからの！リストラするくらいなら、私がロボットになるぞ！