UberのKubernetes上でのRayへの道のり

原文リンク(2025-05-08)

Uberは、Rayベースの機械学習ワークロードをKubernetes上で実行するための最近の移行について詳細を発表した。これはインフラストラクチャの進化を示しており、スケーラビリティ、効率性、開発者体験の向上を目指している。Uber Engineeringからの二部構成のシリーズが最近公開され、この移行中に直面した動機、課題、解決策について掘り下げている。

当初、Uberの機械学習ワークフローはMichelangelo Deep Learning Jobs (MADLJ)サービスによって管理されており、ETLプロセスにはApache Sparkが、モデル訓練にはRayが使用されていた。

Uberの元々の機械学習インフラストラクチャは、スケーラビリティと効率性を妨げるいくつかの課題に直面していた。主な問題の一つはリソース管理が手作業で行われていたことである。MLエンジニアはGPUの利用可能性や現在のクラスター容量を考慮して適切な計算リソースを自分で決定する必要があった。この手動プロセスはしばしば最適でない選択や不必要な遅延を引き起こした。問題をさらに悪化させたのは、リソースとクラスターの静的な設定であり、システムにハードコードされていた。この硬直性は負荷の不均一な分配とリソースの未利用を引き起こし、プラットフォーム全体の効率を制限していた。

さらに、システムの容量を柔軟に計画できないことも障害となっていた。プラットフォームはリソースを過剰にプロビジョニングしてコンピューティング能力を浪費するか、逆に不足してジョブの失敗や遅延を引き起こしていた。これらの制限は総じて非効率でスケールしにくい環境を作り出し、UberはKubernetesとRayへの移行を通じてより適応性が高く自動化されたソリューションを求めることになった。

これらの問題に対処するため、UberはMLワークロードをKubernetesに移行し、より宣言的で柔軟なインフラストラクチャを目指した。この移行には、ユーザーがジョブタイプとリソース要件を指定するだけで、基盤となるインフラストラクチャの複雑さに深入りすることなく、統一されたプラットフォームを開発することが含まれていた。システムは現在のクラスター負荷とジョブ仕様に基づいて最適なリソースを自動的に割り当てる。

Kubernetesにおける弾力的なリソース共有

Uberが機械学習ワークロードをKubernetesに移行する際、リソース利用率の向上に焦点を当てた。これを達成するために、チームは組織全体でコンピューティングリソースをより柔軟かつ効率的に使用するための一連の戦略を実装した。その一つの戦略は、クラスターリソースをチームや組織の境界に従って整理する階層的なリソースプールの導入であった。この構造により、チームは割り当てられた計算リソースをより細かく制御でき、使用パターンの可視性が向上した。

もう一つの改善点は、これらのリソースプール間での弾力的な共有であった。あるプールにアイドルリソースがある場合、それらは一時的に他のプールに借り出され、恒久的に容量を再割り当てすることなく全体の利用率を向上させることができた。これらの借り出されたリソースはプリエンプティブルであり、必要に応じて元のプールに返還される。公平性を確保しリソース競合を避けるために、リソースの権利はmax-min公平性の原則に基づいて強制された。これにより、各プールは保証されたリソースのシェアを保持しつつ、現在の需要に基づいて動的に追加の容量にアクセスできるようになった。これらのメカニズムにより、Uberはより効率的にスケールし、MLワークロードの変動する需要に対応できるようになった。

GPUポッド用のフィルタープラグイン

さらに、Uberは異種ハードウェアの使用を最適化するための戦略を実装した。クラスターはGPU対応ノードとCPU専用ノードの両方で構成されていた。データのロードや前処理などGPUを必要としないタスクはCPUノードに割り当てられ、トレーニングタスクのためにGPUノードを予約した。

Uberはまた、GPUノードにのみGPUワークロードがスケジュールされるようにするためのGPUフィルタープラグインを開発した。Kubernetesスケジューラーも、リソースの断片化を最小限に抑えるために、非GPUポッドを負荷認識戦略で、GPUワークロードをビンパッキング戦略で分配するように強化された。

これらの変更により、Uberは機械学習ワークロードのためのより効率的で柔軟なインフラストラクチャを実現し、リソース利用率とスケーラビリティを向上させた。