Successfully reported this slideshow.
Your SlideShare is downloading. ×

続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 46 Ad

続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2

Download to read offline

PFN は、「現実世界を計算可能にする」を Vision として,膨大な計算量を必要とするシミュレーションや深層学習などの計算ワークロードを実行するためのオンプレ ML 基盤を持っています。

この発表では、「オンプレクラスタの概要」と最近のトピックとして「新しく構築した「MN-2b」」、「Pod のリソース要求量の最適化を助けるしくみ」、「Kubernetes クラスタのアップグレード」についてお話します。

本イベント「オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜」では、オンプレミスの Kubernetes クラスタ上に構築された機械学習基盤を持つ PFN とヤフーのエンジニアが自社での取り組みについて語り尽くします!
イベントサイト: https://ml-kubernetes.connpass.com/event/255797/

PFN は、「現実世界を計算可能にする」を Vision として,膨大な計算量を必要とするシミュレーションや深層学習などの計算ワークロードを実行するためのオンプレ ML 基盤を持っています。

この発表では、「オンプレクラスタの概要」と最近のトピックとして「新しく構築した「MN-2b」」、「Pod のリソース要求量の最適化を助けるしくみ」、「Kubernetes クラスタのアップグレード」についてお話します。

本イベント「オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜」では、オンプレミスの Kubernetes クラスタ上に構築された機械学習基盤を持つ PFN とヤフーのエンジニアが自社での取り組みについて語り尽くします!
イベントサイト: https://ml-kubernetes.connpass.com/event/255797/

Advertisement
Advertisement

More Related Content

More from Preferred Networks (20)

Recently uploaded (20)

Advertisement

続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2

  1. 1. 続・PFNのオンプレML 基盤の取り組み 2022/08/29 オンプレML基盤 on Kubernetes #2 Hidehito Yabuuchi
  2. 2. 自己紹介 薮内 秀仁 (Hidehito Yabuuchi) ● 2020/04 入社 ● Cluster Services チーム ○ オンプレクラスタをはじめとした 社内計算基盤の開発・運用 ● 最近の仕事 ○ Pod のリソース要求量の最適化を 助 るし み ○ 社内 CI 基盤の刷新 2
  3. 3. 目次 ● オンプレクラスタの概要 ○ PFN オンプレクラスタを選ぶ理由 ○ オンプレクラスタ・ストレージクラスタ ○ 社内計算基盤 目指す姿 ● 最近のトピック ○ 新し 構築したクラスタ「MN-2b」 ○ Pod のリソース要求量の最適化を助 るし み ○ Kubernetes クラスタのアップグレード 3
  4. 4. オンプレクラスタの概要 4
  5. 5. PFNがオンプレクラスタを選ぶ理由 ● ビジョン「現実世界を計算可能にする」 ○ シミュレーションや深層学習は膨大な計算リソースを必要とする ○ 計算力は競争力の源泉であり、大量の計算機 必要 ● 大規模な計算を息をするようにしたい ○ 16 GPUs, 32 GPUs, ... な分散学習を回したい ○ 1 GPU な学習をパラメータを変えて大量に回したい / NAS をしたい ○ 1,000 GPU年超でデータセットを作成した例: PFN blog: 材料探索のためのユニバーサルなニューラルネットワークポテンシャル ● 計算基盤全てをコントロールしたい ○ ノード内・ノード間通信、ストレージの全ての最適化 高速な学習には必要 ● 上から下まで(ハードもソフトも人も)保有することの重要性 ○ (設計・調達 らアルゴリズムまで)様々な技術バックグラウンドを持つ メンバー 集結する とで新しいものを生み出してい たい
  6. 6. PFNのオンプレクラスタ 6 MN-2a MN-2b MN-3 New! 2022/07 ~ PFN's Supercomputers Icon pack by Icons8 - https://icons8.com
  7. 7. 7 Icon pack by Icons8 - https://icons8.com MN-2b (A30) 42 nodes (252 GPUs) A30 (24G) PCIe x 6 100GbE x 2 RoCEv2 with SR-IOV MN-2b (A100) 42 nodes (168 GPUs) A100 (80G) SXM4 x 4 100GbE x 2 RoCEv2 with SR-IOV MN-J MN-2a 128 nodes (1024 GPUs) V100 (16 / 32 G) SXM2 x 8 100GbE x 4 RoCEv2 with SR-IOV MN-3 48 nodes (192 MN-Cores) MN-Core x 4 100GbE x 2 MN-Core DirectConnect 80 CPU Cores 128 CPU Cores 48 CPU Cores 36 CPU Cores PFNのオンプレKubernetesクラスタ New! 2022/07 ~ New! 2022/07 ~ DDR4 384GB DDR4 384GB DDR4 1024 GB DDR4 512 GB
  8. 8. PFNのストレージクラスタ 8 トータル約 8.4 PB (論理容量、拡大中) File System Medium MN-J ストレージ NFS HDD NVMe SSD HDFS Apache Ozone Icon pack by Icons8 - https://icons8.com
  9. 9. 社内計算基盤が目指す姿 ● 多様なリテラシのユーザが使いやすいこと ○ 「入社初日 らクラスタで大規模に実験をして成果を出せる」 ● リソースを効率的かつ公平に利用できること ○ 効率的:マルチテナント、スケジューリング、プロファイリング ○ 公平性:各ユーザ 利用した量に基づ プリエンプションなど ● 信頼性・運用効率 ○ 自動プロビジョニング ○ 健全性の自動診断・保守省力化 9 取り組みの内容は オンプレML基盤 on Kubernetes #1 を参照ください!
  10. 10. 最近のトピック 10 ● 新し 構築したクラスタ「MN-2b」 ● Pod のリソース要求量の最適化を助 るし み ● Kubernetes クラスタのアップグレード
  11. 11. 新しく構築したクラスタ「MN-2b」 2022/07 より稼働中 最新世代の GPU (A100, A30), CPU と大 めの主記憶を搭載 11 MN-2b (A30) 42 nodes (252 GPUs) A30 (24G) PCIe x 6 100GbE x 2 RoCEv2 with SR-IOV MN-2b (A100) 42 nodes (168 GPUs) A100 (80G) SXM4 x 4 100GbE x 2 RoCEv2 with SR-IOV 80 CPU Cores 128 CPU Cores DDR4 1024 GB DDR4 512 GB 多様なワークロード に対応 Icon pack by Icons8 - https://icons8.com
  12. 12. 使いたいGPUの種類を簡単に指定できるしくみ ● クラスタ内の GPU の種類が増えた ○ Kubernetes 的にはすべて nvidia.com/gpu ● 課題 ● Node selector で意図通りの種類の GPU を指定するのは難しい ○ 「V100なら何でも」「A30 いい」「VRAM 32 GB あれば何でも」 ● 各種 GPU の需要を知りたい ○ ユーザ どう GPU 種を選んだ 意図を集計したい 12
  13. 13. 使いたいGPUの種類を簡単に指定できるしくみ ● 解決策:gpu-v100-32gb のように指定できるように ○ gpu-<GPU name>-<minimum VRAM amount> ○ Admission webhook で node selector に変換 ● 結果 ○ ユーザ 意図通りに GPU を選べるように ○ 管理者 ユーザの意図を反映した需要を把握で るように 13 * サンプルデータ
  14. 14. Pod のリソース要求量の最適化を助けるしくみ オンプレクラスタの容量は限られている → 無駄なく使いたい ● アプローチ 1: スケジューラで pod をうま 詰め込む ● アプローチ 2: 各 pod が必要十分な量だけリソースを要求する 14 �� �� Pod 使用中 要求した 不使用 * サンプルデータ 課題:Pod の最適なリソース要求量を決めるのは難しい / 面倒
  15. 15. Pod のリソース要求量の最適化を助けるしくみ 解決策:適切なリソース要求量を自動で提案する 15 Icon pack by Icons8 - https://icons8.com VerticalPod Autoscaler Deployment VPA recommender our system kubernetes/autoscaler vertical-pod-autoscaler 2. watch resource usage 3. write appropriate resource 1. create targetRef 4. watch
  16. 16. Kubernetes クラスタのアップグレード ● PFN では minor version 一つ遅れで Kubernetes をアップグレード ○ 1.24 への更新を準備中 ● Cluster API でクラスタのライフサイクルを管理 ● MAAS と Ansible でベアメタルマシンをプロビジョニング 16
  17. 17. Kubernetes クラスタのアップグレード 17 eval MN-J Provision nodes with Ansible Cluster API MAAS provider (in-house) + Custom OS image Edit manifests Icon pack by Icons8 - https://icons8.com
  18. 18. Kubernetes 1.24 といえば:dockershim の削除 ● PFN では 2021/07 に containerd に移行済み ○ レジストリを Google Artifact Registry に移行したため キャッシュサーバへのミラー機能 必要になった ● キャッシュサーバの必要性 ○ クラウド らイメージを大量に pull するとコスト 高い ○ ML 向 のイメージは大 い・多様 ○ ノード 多 ローカルキャッシュ 効 に い ● 95% ほどキャッシュヒット 18
  19. 19. コンテナイメージのキャッシュ 19 Google Artifact Registry Pull/push-through cache Internet Internal network Icon pack by Icons8 - https://icons8.com キャッシュサーバ から pull キャッシュサーバに push もできる GAR にも write-through
  20. 20. We're Hiring! 機械学習プラットフォームエンジニア (Infrastructure) ● こんな環境にワクワクする方を募集しています! ○ 日進月歩で進化している機械学習にフォーカスした計算技術を低レイヤーから高レイヤー までトータルに吸収できる ○ 大規模機械学習クラスタの開発・運用が経験できる ○ Kubernetesを始めとするOSSコミュニティでも活躍できるチャンスがある ○ HPCとCloud Nativeの境界領域という今後ますます重要になる分野の経験ができる ○ 多様な要求・ユーザーリテラシをサポートするプラットフォーム設計・実装を経験できる 20
  21. 21. We're Hiring! ● カジュアル面談希望の連絡お待ちしています(DMでもメンションでもお気軽に) ○ 大村: @everpeace ● 資料 ○ PFN のオンプレML基盤の取り組み (オンプレML基盤 on Kubernetes #1 〜PFN、ヤフー〜) ○ PFNのML/DL基盤を支えるKubernetesに る自動化 (DevOpsDays Tokyo 2021) ○ How to Schedule Machine Learning Workloads Nicely In Kubernetes (CNDT 2020) ○ Kubernetesによる機械学習基盤への挑戦 (JAPANCONTAINERDAYS V18.12) ○ Preferred Networksの機械学習クラスタを支える技術 (JulyTech Festa 2018 基調講演) ○ (採用ページには の他にも載せてあります) 21
  22. 22. パネルディスカッション 22
  23. 23. 23 GPU のスケジューリングや断片化に どんな対策をしてる?
  24. 24. GPU のスケジューリング&断片化対策 ● GPU NodeにCPU Podをスケジューリング ● 断片化対策 ○ 独自のNodeScoreプラグイン(Lua) ■ Pod/Node種別による柔軟なスコアリング ○ 同一PriorityによるPreemption 24
  25. 25. GPUノードにCPU Podをスケジューリング 25 CPU GPU GPU Pods CPUが無駄 �� CPU GPU GPU Pods CPU Pods �� CPU GPU CPU Pods CPU詰めすぎて GPU使えない �� CPU GPU CPU Pods CPU,GPU 両方活用 できてる Preempt GPU Pods �� ☠ GPU Pods CPU,GPU 両方活用 できてる CPU PodをGPUノードに スケジュールしてCPUを有効利用 CPU Podの優先度を下 て GPU Podを邪魔しない
  26. 26. GPU断片化: 独自のNodeScoreプラグイン(Lua) Luaで様々なヒューリスティックを導入可 26 … 8 8 8 GPU Pods 右 ら詰める(意訳) (で る ためるように) <8 GPU Pods MostRequested (Greedy BinPacking) <8 GPU, 8 GPUのScoreが別 (8GPUは主に分散学習向け) Resource Sharing Pod/Node用のScore (主にInteractive環境向け) 2 4 1 2 Resource Sharing Podは要求量をεにしている のでPod数だ でNodeをScoring
  27. 27. Luaでロジック追加ってどうなの? ● 👍メリット ○ ちょっとしたノード追加や方針変更での重み変更などは楽 ○ 独自Pluginじゃな ても なり柔軟なPolicy 実装可能 ● 👎デメリット ○ 結局e2eテストを行わないと怖 て本番投入は無理 ■ コードで書 るので、柔軟だ テストしないと不安 ○ e2eテストを行うのはgoをビルドするのよりも時間 る ■ すでにスケジューラを拡張している場合、環境 ある ● 📜背景 ○ resource weightedなMostAllocated Plugin ない時代に開発 れ てそれを引 継いでいる 27
  28. 28. GPU断片化: 同一PriorityによるPreemption (Deschedulingに似ている) 28 Preempted and Defrag-ed ● 先勝ちで占有 れないように ● 断片化したPodをPreemption対象にする とで断片化も防止
  29. 29. 29 どんなk8sコントローラ/Operator を 開発してる?
  30. 30. どんなk8sコントローラ/Operator を開発してる? ● pfnet-research/node-operation-controller(OSS) ○ NodeのConditionに応じて、復旧オペレーションを行う ● node-metadata-taint-controller ○ CRDの定義に応じて、label/taintをnodeに付与する ○ NodeのConditionに応じて、taintを付与する ● node-condition-controller ○ NodeのConditionに応じて別のNode Condtionを設定する ○ 復旧オペレーションの実行条件を細 指定で るようになる ● job-controller ○ 分散学習を定義するCRDに応じてPodを作成 ○ MPI(Podをまたいでプロセスを連携 せる)と NCCL(GPU間通信ライブラリ)をいい んじに設定して使える 30
  31. 31. job-controller: MPIにおけるプロセス起動 31 launcher node $ mpiexec ./exec host1 host2 host3 hostfile rank=0 (host1 node) $ ./exec rank=1 (host2 node) $ ./exec rank=2 (host3 node) $ ./exec ssh host2 ./exec ssh host1 ./exec ssh host3 ./exec MPI_Comm_rank() -> 0
 MPI_Comm_size() -> 3
 MPI_Comm_rank() -> 1
 MPI_Comm_size() -> 3
 MPI_Comm_rank() -> 2
 MPI_Comm_size() -> 3

  32. 32. job-controllerにおける起動とクリーンアップ 32 launcher pod $ mpiexec ./exec worker0 worker1 worker2 hostfile rank=0 (worker0 pod) $ ./exec rank=1 (worker1 pod) $ ./exec rank=2 (worker2 pod) $ ./exec kubectl exec ./exec ./exec kubectl exec ./exec ConfigMap 生 てる ? 生 てる ? 生 てる ? kind: MPIJob # 死活監視 status: Running
  33. 33. kubeflowのMPI operatorとの比較 ● CRDとしては結構似ている ○ launcher と worker についてそれぞれPodTemplateSpecを書 ● PFNの環境に合わせるための機能 色々ある ○ Gang Scheduling のサポート ○ masterless-mpi(launcher pod と worker #0のpod 一致する) ■ preemption のハンドリング しやすい ■ 非MPIモードと組み合わせたジョブスクリプトを書 やすい ○ initContainerの自動挿入機能 ■ Multi-Rail(NIC 複数ある)環境向 に設定ファイル生成 ■ 「必要なPod 全て起動する」までの待ち合わせ ■ などなどた ん 33
  34. 34. 34 最近どんな障害あった?
  35. 35. ● Pod 起動直後に名前解決に失敗して死ぬ!なぜ! ○ 名前解決以外にもあらゆるクラスタ内のサービスに 起動直後だ アクセスで ない(kube-apiserver も含む) ● 失敗しないと もあれば、起動後数十秒ダメな ともある ( そら )Pod 数 多す る と 原因で、 CNI プラグイン kubelet kube-proxy で問題 起 ている Pod が起動直後に名前解決に失敗して死ぬ 😱 (1/3) 35
  36. 36. pods/LIST に7秒以上も っちゃってる😇 Pod が起動直後に名前解決に失敗して死ぬ 😱 (2/3) 36
  37. 37. エラーや完了済みの Pods を削除する とで解消 れる とを確認。 ● 根本対策: システムコンポーネントのチューニングやエラーや終了した Pods の自動掃除を検討(まだ取り組めてない) ● 対処療法: ネットワークの疎通 確認で るまでスリープする コンテナを Init container として自動的に挿入 Pod が起動直後に名前解決に失敗して死ぬ 😱 (3/3) 37 スリープ どの らいで終了した を ログで観測 (10分の1秒)
  38. 38. 最近あった障害 - CIDRNotAvailable イベント ● API Server 不調になった原因を探っていたら・・・ ● イベント 多いの 原因 も? → あまり見ないイベント 出てる!? ● CIDRNotAvailable !?!? なんだっ れ ● 最近、何 変わったっ ・・・もし して? 38
  39. 39. CIDRNotAvailable: 原因 ● 最近追加したノードの一部だ で発生 ● 250台に台数を減らすと発生しない ● 256に境目 ありそうな値では? ● 結果分 った と ● クラスタ全体のCIDR: /16 ● ノードのCIDRブロックサイズ: /24 ● ブロック数は8ビット分 😇 39 MN-2Bでノード 増えた
  40. 40. 最近あった障害 - 大量のOutOfCpu イベント ● 起 た と ○ 大量のPod OutOfCpuイベントを発行しFailし続 た ○ ユーザ らは確率的にPodの実行 失敗するとの多数の問い合わせ ○ ノードによらず発生・再起動などでも回復せず ● 当時の様子 ○ 数分に一回スケジュール直後にFail状態になるPod 多数 ○ まずい 40
  41. 41. 大量のOutOfCpuの原因と対策 ● そもそもOutOfCpuイベントっていつ起 る? ○ スケジュール済みPodのCPU要求量 > kubeletの認識するCPU量 ● 前日に1.22にUpgradeしたk8s(kubelet)のバグだった ○ Pod終了と新規Podのrace conditionを疑い、手元で再現に成功 ○ k8s apiサーバへのPod終了報告 、kubelet内の状態更新より先に なっていた ● upstreamへissue化/PR化を行った(#106884, #106955) ○ 発生 ら一週間強で社内はパッチで凌 とに成功 ○ ※Upstreamは別PRで修正 れました 41
  42. 42. 42 どんなチーム構成で 取り組んでいるのか教えて!
  43. 43. クラスタを取り巻く組織 43 MN-Cor e Cluster Services Cluster Planning MN-Core 企画&設計 ASIC設計 コンパイラ・ランタイム 計算基盤サービス化 計算基盤 Project A 利用・フィードバック ファシリテーション Project B Project Z … 利用・フィードバック ファシリテーション 利用・フィードバック ファシリテーション 連 携 連 携 連 携
  44. 44. ● Product Management/Support ○ GitHub Issuesによる要望収集 ベース ○ Cluster Solution Architectによる吸い上 ○ Documentは基本Google Docs ● 開発・運用 ○ テーマ とのSIGを構成して所属(3ヶ月サイクル) ○ それぞれのSIGで優先度を決定して活動 ○ 全体SyncはWeekly Cluster Servicesチーム内ではどう取り組んでいるか? 44 ユーザ 直接要望 Project SAによる吸上 SAによる強力サポート Provisioning Monitoring Usability Resource Efficiency Hardening SIGs … ※図はイメージです 極端な所属の偏りは Engineering Managerによる調整
  45. 45. We're Hiring! 機械学習プラットフォームエンジニア (Infrastructure) ● こんな環境にワクワクする方を募集しています! ○ 日進月歩で進化している機械学習にフォーカスした計算技術を低レイヤーから高レイヤー までトータルに吸収できる ○ 大規模機械学習クラスタの開発・運用が経験できる ○ Kubernetesを始めとするOSSコミュニティでも活躍できるチャンスがある ○ HPCとCloud Nativeの境界領域という今後ますます重要になる分野の経験ができる ○ 多様な要求・ユーザーリテラシをサポートするプラットフォーム設計・実装を経験できる 45
  46. 46. We're Hiring! ● カジュアル面談希望の連絡お待ちしています(DMでもメンションでもお気軽に) ○ 大村: @everpeace ● 資料 ○ PFN のオンプレML基盤の取り組み (オンプレML基盤 on Kubernetes #1 〜PFN、ヤフー〜) ○ PFNのML/DL基盤を支えるKubernetesに る自動化 (DevOpsDays Tokyo 2021) ○ How to Schedule Machine Learning Workloads Nicely In Kubernetes (CNDT 2020) ○ Kubernetesによる機械学習基盤への挑戦 (JAPANCONTAINERDAYS V18.12) ○ Preferred Networksの機械学習クラスタを支える技術 (JulyTech Festa 2018 基調講演) ○ (採用ページには の他にも載せてあります) 46

×