DatabricksにおけるインテリジェントなKubernetesロードバランシング

序章

Databricksでは、Kubernetesが社内システムの中心となっています。単一のKubernetesクラスタ内では、ClusterIPサービス、CoreDNS、kube-proxyなどのデフォルトのネットワークプリミティブで十分な場合が多くあります。これらは、サービストラフィックをルーティングするためのシンプルな抽象化を提供します。しかし、パフォーマンスと信頼性が重要になると、これらのデフォルトには限界が見え始めます。

この記事では、トラフィック分散を改善し、テールレイテンシを削減し、サービス間通信の回復性を高めるために、インテリジェントなクライアントサイドの負荷分散システムをどのように構築したかを紹介します。

Databricksをご利用の皆様は、このブログの内容を理解していなくても、プラットフォームを最大限にご活用いただけます。しかし、内部の仕組みに興味がある方は、ぜひこのまま読み進めて、私たちが取り組んできた素晴らしい取り組みについてご覧ください。

課題

DatabricksではgRPCを使用していますが、Kubernetesにおいて永続的なHTTP/2接続を使用する場合、ハイパフォーマンスなサービス間通信にはいくつかの課題があります。

Kubernetes がデフォルトでリクエストをルーティングする仕組み

• クライアントはサービス名（例えば、`my-service.default.svc.cluster.local`）を名前解決します。CoreDNS 経由で、サービスの ClusterIP（仮想 IP）が返されます。
• クライアントは、ClusterIPが宛先であると想定してリクエストを送信します。
• ノード上では、kube-proxy によって構成された iptables、IPVS、または eBPF のルールがパケットをインターセプトします。カーネルは、ラウンドロビンなどの基本的なロード バランシングに基づいて、宛先 IP をバックエンド Pod IP のいずれかに書き換え、パケットを転送します。
• 選択されたポッドがリクエストを処理し、レスポンスがクライアントに返されます。

このモデルは一般的には機能しますが、パフォーマンスが重視される環境ではすぐに破綻し、大きな制限につながります。

制限事項

Databricksでは、各Kubernetesクラスター内でgRPCを介して通信する、数百ものステートレスサービスを運用しています。これらのサービスは多くの場合、高スループット、低レイテンシが求められ、大規模に実行されます。

この環境では、デフォルトのロードバランシングモデルがいくつかの理由でうまく機能しません。

• 高いテールレイテンシ: gRPCはHTTP/2を使用しており、クライアントとサービスの間に長時間持続するTCP接続を維持します。Kubernetesのロードバランシングはレイヤー4で行われるため、バックエンドのポッドが選択されるのは接続ごとに1回だけです。これによりトラフィックの偏りが生じ、一部のポッドが他のポッドよりも大幅に多くの負荷を受けます。その結果、テール レイテンシが増加し、負荷がかかった状態でのパフォーマンスにばらつきが生じます。
• 非効率なリソース使用: トラフィックが均等に分散されないと、容量要件の予測が困難になります。一部のポッドでCPUやメモリが枯渇する一方で、他のポッドはアイドル状態になります。これが過剰なプロビジョニングと無駄につながります。
• 限定的なロードバランシング戦略: kube-proxyは、ラウンドロビンやランダム選択のような基本的なアルゴリズムのみをサポートします。次のような戦略はサポートされていません。
  • 加重ラウンドロビン
  • エラーアウェア ルーティング
  • ゾーンアウェアなトラフィックルーティング

これらの制限により、私たちは Kubernetes クラスタ内でのサービス間通信の処理方法を再考せざるを得なくなりました。

私たちのアプローチ: リアルタイムのサービスディスカバリを伴うクライアントサイドのロードバランシング

Kubernetesにおけるkube-proxyとデフォルトのサービスルーティングの制限に対処するため、カスタムのサービスディスカバリーコントロールプレーンをバックエンドとして、プロキシレスで完全にクライアント駆動型のロードバランシングシステムを構築しました。

私たちが持っていた基本的な要件は、アプリケーション層でロードバランシングをサポートし、クリティカルパス上の DNS への依存を排除することでした。kube-proxy のようなレイヤー 4 ロードバランサーは、永続的な接続を利用するレイヤー 7 プロトコル (gRPC など) に対して、リクエストごとのインテリジェントな決定を行うことができません。このアーキテクチャ上の制約はボトルネックを生み出し、トラフィック管理に対するよりインテリジェントなアプローチを必要とします。

次の表は、主な違いとクライアントサイドアプローチの利点をまとめたものです。

表 1: デフォルトの Kubernetes LB と Databricks のクライアントサイド LB の比較

このシステムは、DNSやレイヤー4のネットワーキングへの依存を最小限に抑えながら、インテリジェントで最新のリクエストルーティングを可能にします。これによりクライアントは、ライブのトポロジーとヘルスデータに基づいて、情報に基づいた意思決定を行えるようになります。

この図は、私たちのカスタム Endpoint Discovery Service が動作している様子を示しています。Kubernetes APIからサービスとエンドポイントのデータを読み取り、xDSレスポンスに変換します。ArmeriaクライアントとAPIプロキシの両方がリクエストをストリーミングし、ライブのエンドポイントメタデータを受信します。このメタデータは、アプリケーションサーバーがフォールバッククラスタをバックアップとして使用するインテリジェントなルーティングに利用されます。

カスタムコントロールプレーン（エンドポイントディスカバリサービス）

私たちは、ServiceとEndpointSliceの変更についてKubernetes APIを継続的に監視する、軽量のコントロールプレーンを実行しています。これは、ゾーン、準備完了状態、シャードラベルなどのメタデータを含め、すべてのサービスのすべてのバックエンドポッドの最新のビューを維持します。

RPCクライアント統合

Databricks にとっての戦略的な利点は、主に Scala で書かれている社内サービスのほとんどで、サービス通信のための共通フレームワークが広く採用されていたことでした。この共通の基盤により、クライアントサイドのサービスディスカバリと負荷分散ロジックをフレームワークに直接組み込むことができ、カスタムの実装作業を必要とせずにチーム全体で簡単に導入できるようになりました。

各サービスは、当社のカスタムクライアントと統合されています。このクライアントは、接続確立時に、依存先のサービスに関する更新情報をコントロールプレーンからサブスクライブします。クライアントは、ゾーンやシャードといったメタデータを含む、正常なエンドポイントの動的リストを維持し、コントロールプレーンが変更をプッシュすると自動的に更新します。

クライアントは DNS 解決と kube-proxy の両方を完全にバイパスするため、常に最新で正確なサービストポロジのビューを持つことができます。これにより、すべての社内サービスにわたって、一貫性のある効率的な負荷分散戦略を実装できます。

クライアントにおける高度な負荷分散

rpc クライアントは、次のような戦略を使用してリクエストアウェアなロードバランシングを実行します:

• Power of Two Choices (P2C): ほとんどのサービスにおいて、シンプルな Power of Two Choices (P2C) アルゴリズムが非常に効果的であることが証明されています。この戦略では、2つのバックエンドサーバーをランダムに選択し、そのうちアクティブな接続が少ない、または負荷が低い方を選びます。Databricks の経験から、P2C はパフォーマンスと実装のシンプルさの間で絶妙なバランスを取り、エンドポイント全体で一貫して均一なトラフィック分散を実現することがわかっています。
• ゾーンアフィニティベース： このシステムは、ゾーンアフィニティベースのルーティングなど、より高度な戦略もサポートします。この機能は、ゾーン間のネットワークホップを最小限に抑えるために不可欠です。これにより、特に地理的に分散したKubernetesクラスターにおいて、ネットワークのレイテンシと関連データ転送コストを大幅に削減できます。
  
  このシステムは、ゾーンのキャパシティが不足したり、過負荷になったりするシナリオも考慮します。そのような場合、ルーティングアルゴリズムは、可能な限りローカルアフィニティを優先しながらも、トラフィックを他の正常なゾーンにインテリジェントに振り分け、負荷を分散します。これにより、ゾーン間で容量配分が不均一な場合でも、高可用性と一貫したパフォーマンスが保証されます。
• プラグイン可能なサポート： このアーキテクチャは柔軟性が高いため、必要に応じて追加のロードバランシング戦略をプラグインでサポートできます。

ゾーンアウェアルーティングのような、より高度な戦略には、サービストポロジー、トラフィックパターン、障害モードに関する慎重なチューニングと、より深いコンテキストが必要でした。これについては、別のフォローアップ記事で詳しく説明する予定です。

私たちのアプローチの有効性を確認するために、広範なシミュレーション、実験、実世界のメトリクス分析を実施しました。負荷が均等に分散され続けること、そしてテールレイテンシ、エラー率、ゾーン間トラフィックコストなどの主要メトリクスが目標のしきい値内に収まることを検証しました。サービスごとに戦略を適応させる柔軟性は価値がありましたが、実際には、シンプルに（そして一貫性を保つことが）最も効果的でした。

Envoy との xDS 統合

私たちのコントロールプレーンは、内部のサービス間通信を超えてその有用性を拡張します。Envoyに対してxDS API（クライアントがクラスター、エンドポイント、ルーティングルールなどの最新設定を動的に取得するための検出プロトコル）を使用することで、外部トラフィックの管理において重要な役割を果たします。具体的には、ClusterLoadAssignmentリソースをプログラミングすることでEndpoint Discovery Service（EDS）を実装し、バックエンドエンドポイントに関する一貫した最新のメタデータをEnvoyに提供します。これにより、ゲートウェイレベルのルーティング（例えば、イングレスや公開トラフィック向け）が、内部クライアントが使用するのと同じ信頼できる情報源と整合性がとれるようになります。

まとめ

このアーキテクチャにより、DNSとkube-proxyの制限からサービスディスカバリを切り離しつつ、ルーティング動作をきめ細かく制御できます。重要なポイントは次のとおりです。

1. クライアントは常にエンドポイントとその健全性をライブで正確に把握できます。
2. ロードバランシング戦略をサービスごとに調整して効率とテールレイテンシを改善し、
3. 内部トラフィックと外部トラフィックの両方が同じ信頼できる情報源を共有し、プラットフォーム全体で一貫性を確保します。

インパクト

クライアントサイドのロードバランシングシステムをデプロイした後、パフォーマンスと効率の両方で大幅な改善が見られました:

• 均一なリクエスト分散
  サーバーサイドのQPSが、すべてのバックエンドポッドに均等に分散されるようになりました。一部のポッドが過負荷になり、他のポッドが十分に活用されていなかった以前のセットアップとは異なり、トラフィックは予測どおりに分散されるようになりました。上のグラフはEDS導入前の分散を、下のグラフはEDS導入後のバランスの取れた分散を示しています。
  

  

• 安定したレイテンシプロファイル
  ポッド間のレイテンシのばらつきが目に見えて減少しました。ポッド間のレイテンシメトリクスが改善・安定化し、gRPCワークロードにおけるロングテール挙動が低減されました。下の図は、クライアントサイドのロードバランシングを有効にした後、P90レイテンシがより安定した様子を示しています。
  
• リソース効率
  レイテンシの予測可能性が高まり、負荷が均等になったことで、過剰にプロビジョニングされたキャパシティを削減できました。いくつかのサービスにわたり、これによりポッド数が約20%削減され、信頼性を損なうことなくコンピューティングリソースを解放できました。

課題と教訓

この展開は明確なメリットをもたらしましたが、その過程でいくつかの課題と洞察も明らかになりました。

• サーバーのコールドスタート：クライアントサイドの負荷分散を導入する前は、ほとんどのリクエストが長期間有効な接続で送信されていたため、既存の接続がリサイクルされるまで新しいポッドがリクエストを受信することはほとんどありませんでした。移行後は、新しいポッドがすぐにトラフィックを受信するようになり、完全にウォームアップされる前にリクエストを処理するというコールドスタートの問題が表面化しました。この問題に対処するため、スロースタートのランプアップを導入し、観測されたエラー率が高いポッドからトラフィックを遠ざけるようにしました。これらの教訓は、専用のウォームアップフレームワークの必要性を改めて浮き彫りにしました。
• メトリクスベースのルーティング： 当初、CPUなどのリソース使用率のシグナルに基づいてトラフィックを偏らせることを試しました。概念的には魅力的でしたが、このアプローチは信頼性が低いことが判明しました。監視システムはサービス提供ワークロードとは異なるSLOを持っており、また、CPUのようなメトリクスはキャパシティのリアルタイムなシグナルではなく、多くの場合、遅行指標でした。最終的にこのモデルから離れ、サーバーのヘルス状態など、より信頼性の高いシグナルに依存することを選択しました。
• クライアントライブラリの統合: ロードバランシングをクライアントライブラリに直接組み込むことは、パフォーマンスに大きなメリットをもたらしましたが、同時にいくつかの避けられないギャップも生み出しました。ライブラリを使用しない言語や、依然としてインフラのロードバランサーに依存するトラフィックフローは、クライアントサイドバランシングの対象外となります。

検討した代替案

クライアントサイドの負荷分散アプローチを開発する中で、他の代替ソリューションも評価しました。最終的にこれらを採用しなかった理由は次のとおりです。

ヘッドレスサービス

Kubernetesのヘッドレスサービス（clusterIP: None）はDNSを介して直接ポッドのIPを提供し、クライアントやプロキシ（Envoyなど）が独自のロードバランシングを実行できるようにします。このアプローチは、kube-proxyにおける接続ベースの分散の制限を回避し、Envoyが提供する高度なロードバランシング戦略（ラウンドロビン、コンシステントハッシュ、最小負荷ラウンドロビンなど）を可能にします。

理論上は、既存の ClusterIP サービスを headless サービスに切り替える（または同じセレクターを使用して追加の headless サービスを作成する）ことで、クライアントにエンドポイントの直接的な可視性が提供され、接続の再利用に関する問題が軽減されます。しかし、このアプローチには実用上の制限があります:

• エンドポイントの重み付けの欠如：ヘッドレスサービスだけではエンドポイントへの重み割り当てをサポートしていないため、きめ細かい負荷分散制御を実装する能力が制限されます。
• DNS のキャッシュと陳腐化: クライアントは頻繁に DNS 応答をキャッシュするため、古い、または異常なエンドポイントにリクエストを送信する原因となります。
• メタデータのサポートなし: DNSレコードには、エンドポイントに関する追加のメタデータ（ゾーン、リージョン、シャードなど）が含まれていません。このため、ゾーンアウェアルーティングやトポロジーアウェアルーティングといった戦略を実装することが困難または不可能になります。

ヘッドレスサービスはClusterIPサービスに比べて一時的な改善をもたらす可能性がありますが、実用上の課題と制限があるため、Databricksの規模では長期的な解決策として不適切でした。

サービス メッシュ（Istio など）

Istioは、すべてのポッドに注入されたEnvoyサイドカーを使用して、強力なレイヤー7ロードバランシング機能を提供します。これらのプロキシは、ルーティング、リトライ、サーキットブレーキングなどを処理し、これらすべてがコントロールプレーンを通じて一元的に管理されます。

このモデルは多くの機能を提供しますが、いくつかの理由からDatabricksの環境には適していないと判断しました。

• 運用の複雑さ: 数千ものサイドカーとコントロールプレーンコンポーネントを管理することは、特にアップグレードや大規模なロールアウトの際に、大きなオーバーヘッドを追加します。
• パフォーマンスのオーバーヘッド: サイドカーはポッドごとに追加の CPU、メモリ、レイテンシのコストを発生させ、これは私たちの規模では相当なものになります。
• クライアントの柔軟性の制限: すべてのルーティングロジックが外部で処理されるため、アプリケーション層のコンテキストに依存するリクエストアウェアな戦略を実装することが困難です。

私たちは Istio の Ambient Mesh も評価しました。Databricksにはすでに証明書配布などの機能のための独自システムがあり、ルーティングパターンも比較的に静的であったため、フルメッシュを採用することによる複雑さの増加がメリットを上回りました。これは、主に Scala のコードベースをサポートしている小規模なインフラチームにとっては特にそうでした。

sidecar ベースのメッシュの最大の利点の 1 つが、言語に依存しない点であることは注目に値します。これによりチームは、あらゆる場所でクライアント ライブラリを維持することなく、多言語サービス全体で復元性とルーティングを標準化できます。しかし、Databricksでは環境が主にScalaベースであり、monorepoと高速なCI/CDカルチャーがあるため、プロキシレスなクライアントライブラリのアプローチがはるかに実用的です。sidecar の運用上の負担を導入するのではなく、ライブラリとインフラストラクチャ コンポーネントに直接ファーストクラスの負荷分散を組み込むことに投資しました。

今後の方向性と探求分野

現在のクライアントサイドの負荷分散アプローチは、社内のサービス間通信を大幅に改善しました。しかし、Databricksがスケールし続ける中で、システムをさらに強化するために、いくつかの高度な分野を探求しています。

クラスタ間およびリージョン間のロード バランシング: 当社では複数のリージョンにわたって数千もの Kubernetes クラスタを管理しているため、個々のクラスタを越えてインテリジェントなロード バランシングを拡張することが非常に重要です。マルチリージョンのEndpoint Discovery Service（EDS）クラスターとシームレスに統合する、フラットなL3ネットワーキングやサービスメッシュソリューションなどのテクノロジーを調査しています。これにより、堅牢なクラスター間トラフィック管理、フォールトトレランス、そしてグローバルで効率的なリソース利用が可能になります。

AIユースケース向けの高度なロードバランシング戦略： 高度なAIワークロードをより良くサポートするために、加重ロードバランシングなど、より洗練された戦略を導入する予定です。これらの戦略により、特定のアプリケーションの特性に基づいた、よりきめ細かいリソース割り当てとインテリジェントなルーティング決定が可能になり、最終的にパフォーマンス、リソース消費、コスト効率が最適化されます。

このような大規模分散インフラの課題に取り組むことにご興味のある方を募集しています。私たちと一緒に開発しませんか — Databricksの募集中の職種をご覧ください！