オンプレML基盤on Kubernetes パネルディスカッション

オンプレML基盤 on Kubernetes パネルディスカッション ヤフー株式会社 データプラットフォーム本部AIプラットフォーム ©2022 Yahoo Japan Corporation All rights reserved.

分散学習（LakeTahoeの場合） • ハイパーパラメータチューニングを並列分散で⾏うことが多い • 1つのタスク（Trial）でマルチノードを使った分散学習は少数派 • APIの機能としては実装されているけど… • 1ノード上のマルチGPU学習はそれなりに • LakeTahoeジョブの内訳 • テーブルデータやテキストデータを⽤いたタスクが多い • GBDTとDNNの両⽅が利⽤されている • GBDTの分散学習はSpark（on Hadoop）で⾏われることが多い ©2022 Yahoo Japan Corporation All rights reserved. 2

PodのPreemption • 定常処理 • Priority=highで必ず動くように • アドホックなデータ探索など • Priority=lowで余っているリソースの有効利⽤ • Masterはpriority=middleで、workerはpriority=lowにして、 WorkerはQueue形式でJobをとりいつでも死んでもいい状態にする • マルチノードの分散学習 • 基本的に⾜りるようにサーバーを追加 ©2022 Yahoo Japan Corporation All rights reserved. 3

⾼速なネットワーク作成のために取り組んでいること • 100GのSmart NICを活⽤した⾼速な通信の実現 • Open vSwitch with HV Offloadの活⽤ • 仮想環境ながら、ほぼワイヤーレートに近いスループット(100Gbps近く)を計測 • 現在のところ、ネットワーク帯域で困ったという話は利⽤者からは来ていない • AIPF上のマルチノードの分散学習がまだ多くない • AIPFで提供しているストレージの帯域が現状は太くないなどの事情もある • これから、上記の問題が解決されてトラフィックが増えていくはず ©2022 Yahoo Japan Corporation All rights reserved. 4

Network(再掲) • IP Clos Fabric NW • データ分析基盤のようなサーバ間の通信が多い環境に向けた「East-West」なトラフィックにも強い構成 • ⾼帯域で耐障害性があるNetwork • NW Security • コアスイッチではなくサーバ(HV)でNetwork ACLを管理 参考：データドリブンなサービスを支えるネットワークの作り方〜 ヤフーのデータセンターネットワーク紹介 https://techblog.yahoo.co.jp/entry/20200323819517/ ©2022 Yahoo Japan Corporation All rights reserved. 5

• https://techblog.yahoo.co.jp/entry/20200323819517/

Server(再掲) • OpenStack + KVMを⽤いたIaaS基盤 • 基本的に1HV1VM構成※ • 実機と⽐較して95%程度のパフォーマンス • GPU/NVMe/NICパススルーの活⽤ • 合計130台近くのGPUサーバ • SmartNICを活⽤した⾼速な通信 • パケット処理をHWにオフロードすることで⾼いパフォーマンスを実測 ©2022 Yahoo Japan Corporation All rights reserved. ※ K8S MASTER, INGRESS,ETCDなどのVMは除く 6

K8S network latency Horovod syntheVc benchmarch (Resnet50) 2node x 4gpu(V100) img/sec per GPU 350 300 250 200 20%程度の劣化 150 100 50 0 batch-size=64 centos device=host batch-size=256 centos vxlan mtu=1500 centos vxlan mtu=9000 ubuntu vxlan mtu=9000 batch-sizeが⼩さい場合、vxlanなどの影響が⼤きく出ている vDPAなどでopenstack側からdeviceを追加しないとうまくいかない ©2022 Yahoo Japan Corporation All rights reserved. 7

リソース使⽤率向上のために取り組んでいること • 課題 • LakeTahoe Notebooksで作成されたJupyterインスタンスが操作されずに起動されたままに → リソースの利⽤率の低下、リソースプールの圧迫 • 解決策 • 接続状況をもとに、⼀定時間接続されていないJupyterインスタンスを⾃動停⽌ • 現在の取り組み・今後の展開 • インスタンスの停⽌だけでなく、適切なマシンリソースへの⾃動調整にも取り組み中 • 現在はルールベースだが、将来的には時系列のメトリクスデータをもとにした 機械学習による判定にも取り組みたい ©2022 Yahoo Japan Corporation All rights reserved. 8

Kubernetesクラスタのアップグレード • コミュニティベースのAnsible playbook (kubernetes-sigs/kubespray) でのin-place upgrade • Air-gap化 • Mitogenによる⾼速化 • ノードチューニングの独⾃改修 • Ansible AWX でオペレーション集約・API化 • 社内のWebワークロード向けk8s環境のバージョン下限とライフサイクルを揃えている • k8s 1.21.6 (2022.03現在 ) ©2022 Yahoo Japan Corporation All rights reserved. 9

• https://github.com/kubernetes-sigs/kubespray
• https://mitogen.networkgenomics.com/ansible_detailed.html
• https://github.com/ansible/awx

NVIDIA Driver • 更新頻度 • Tensorflow,pytorchのサポートで必要になったらあげている(⼤体半年に⼀度) • ドライバに関するトラブル • 特になし • テスト • 過去のcudaも含め、 https://github.com/NVIDIA/cuda-samples の動作が変わっていないことを確認 ©2022 Yahoo Japan Corporation All rights reserved. 10

• https://github.com/NVIDIA/cuda-samples

Container Image管理 •tag Tag固定 (stableなど) バージョン ごとに Tag固定 (v1.0など) プラット フォーム ユーザ 事故の起こりにくさ ○ ○ × × × ○ プラット フォーム ユーザ 管理のしやすさ メリット/デメリット • Jupyterなど実験を⾏なってもらう際は常に最新を使って欲しい場合 • • 定常バッチなどでバージョンを固定したい場合 バージョンごとにセキュリティアップデートなどがあり 管理は多少めんどくさい ユーザもバージョンを変えるたびにテストが必要 ※ここでMLOPSが結局重要になる • • •Fat/Small メリット/デメリット • • 依存/インストール順序などを考慮しながら最新版にしていく必要が ある ユーザはとりあえず起動すれば全てのスクリプトが利⽤できる みんなが使えばcacheにのるのでサイズよりも共通化を意識 • • • 最新版を取り込む作業が簡単 ユーザは環境ごとに切り替えが必要 Imageが軽くなる • Fat × ○ × Small ○ × ○ ©2022 Yahoo Japan Corporation All rights reserved. 11

クラスタにデプロイしているアドオンやツール • 監査のsysdig falco、監視のPrometheus・Thanos、CSI Driver2種、OPA、 cert-manager、各種Webhook(Authorization, Admission) • バージョン追従の⽅法 • k8sアップグレードの前後で⼀⻫に追随するケースが多い • デプロイ、管理⽅法 • ユーザーアプリケーション同様に社内のCIからapply • AuthZ Webhookなどkubeletに影響するものはkubesprayに組み込み • ユーザーNSに影響するものはArgo CDマニフェストで配布・統制 ©2022 Yahoo Japan Corporation All rights reserved. 12

ユーザコミュニケーション • ユーザコミュニケーション • 機能追加などはSlackで周知 • ⼀⽇数件あがるので結構ユーザは⼤変と思う。。 • 周知とは別にまとめを作って欲しいと⾔われている • 基本的に↑と同じSlackで分からないことがあれば聞いてもらう • 情報はちょっとごちゃっとするが、他の⼈への周知や、ユーザ同⼠のフォローも⾏われる • 初めはK8S難しいなどの質問もあったが、現在はナレッジシェアとかも多くなっている(ユーザと⼀緒に成⻑したい) • ユーザコミュニティフォーラム • ユーザが試したことや、共有したいことをシェア ©2022 Yahoo Japan Corporation All rights reserved. 13

研究者のトイルを少なくするための取り組みがあるか • 実験環境 • LakeTahoe Notebooksで簡単に実験は⾏えるようになってきている • 今起きている問題 • 初期構築が⾯倒 • アップデートが⼤変 • リソースの無駄が多い • モデル開発から本番デプロイまでに連携が必要 K8S層を隠蔽したアプリケーションを提供が必要 Pipelineを簡単に作れるInterfaceが必要 ©2022 Yahoo Japan Corporation All rights reserved. 14

Storage(PVC) • NetApp • NFS + ISCSI • ランダムなRead/Writeで⾼スループットを実現 • DB(MySQL, NoSQL)、データキャッシュなど • Quobyte • File Storage + Object Storage(S3) • 安価なコモディティハードウェア上で動作しサーバを追加することで容量と性能がスケール • モデルデータ、メトリクス、ログなど ©2022 Yahoo Japan Corporation All rights reserved. 15

Kubernetes 事故 • Masterのラックが落ちて死亡(あるある) • ラック分散 • ArgoWorkflow,JobなどでCompleteJobが作られまくってETCD死亡 • Pod数に上限/CompleteJobを消すDefault設定(今は全体で10000podくらいが限界) • Priority/PodDisruptionBudget/topologySpreadConstraints設定し忘れ(あるある) • 設定しましょう。。w • DockerRegistryのTLS期限切れ • CertManger+ACME (HTTP01チャレンジ)の導⼊予定 • 最新のImageにしたら動かない • テストをひたすら追加/Runtimeバージョンを指定 • NUM_THREADSなどの設定がなくCPU使いまくり or 遅い • Deploy templateの共通化 ©2022 Yahoo Japan Corporation All rights reserved. 16

AMD vs Intel numpy thread python numpyの場合、amd/intelともに速度変わらず(amdの⽅が若⼲早い) condaなどでpureなmklを使う場合、古いバージョンの場合は、MKL_DEBUG_CPU_TYPE=5をつけないと遅くなる condaなどでpureなmklを使う場合は、最新版に変更を⾏うか、MKL_DEBUG_CPU_TYPE=5を設定して対応が必要 ©2022 Yahoo Japan Corporation All rights reserved. 17

©2022 Yahoo Japan Corporation All rights reserved.