Movatterモバイル変換

続・PFNのオンプレML基盤の取り組み2022/08/29 オンプレML基盤 on Kubernetes #2Hidehito Yabuuchi

自己紹介薮内秀仁 (Hidehito Yabuuchi)● 2020/04 入社● Cluster Services チーム○ オンプレクラスタをはじめとした社内計算基盤の開発・運用● 最近の仕事○ Pod のリソース要求量の最適化を助るしみ○ 社内 CI 基盤の刷新2

目次● オンプレクラスタの概要○ PFN オンプレクラスタを選ぶ理由○ オンプレクラスタ・ストレージクラスタ○ 社内計算基盤目指す姿● 最近のトピック○ 新し構築したクラスタ「MN-2b」○ Pod のリソース要求量の最適化を助るしみ○ Kubernetes クラスタのアップグレード3

オンプレクラスタの概要4

PFNがオンプレクラスタを選ぶ理由● ビジョン「現実世界を計算可能にする」○ シミュレーションや深層学習は膨大な計算リソースを必要とする○ 計算力は競争力の源泉であり、大量の計算機必要● 大規模な計算を息をするようにしたい○ 16 GPUs, 32 GPUs, ... な分散学習を回したい○ 1 GPU な学習をパラメータを変えて大量に回したい / NAS をしたい○ 1,000 GPU年超でデータセットを作成した例：PFN blog: 材料探索のためのユニバーサルなニューラルネットワークポテンシャル● 計算基盤全てをコントロールしたい○ ノード内・ノード間通信、ストレージの全ての最適化高速な学習には必要● 上から下まで（ハードもソフトも人も）保有することの重要性○ （設計・調達らアルゴリズムまで）様々な技術バックグラウンドを持つメンバー集結するとで新しいものを生み出していたい

PFNのオンプレクラスタ6MN-2a MN-2bMN-3New!2022/07 ~PFN's SupercomputersIcon pack by Icons8 - https://icons8.com

7Icon pack by Icons8 - https://icons8.comMN-2b (A30)42 nodes(252 GPUs)A30 (24G)PCIe x 6100GbE x 2RoCEv2with SR-IOVMN-2b (A100)42 nodes(168 GPUs)A100 (80G)SXM4 x 4100GbE x 2RoCEv2with SR-IOVMN-JMN-2a128 nodes(1024 GPUs)V100 (16 / 32 G)SXM2 x 8100GbE x 4RoCEv2with SR-IOVMN-348 nodes(192 MN-Cores)MN-Core x 4100GbE x 2MN-CoreDirectConnect80 CPU Cores128 CPU Cores48 CPU Cores36 CPU CoresPFNのオンプレKubernetesクラスタNew!2022/07 ~New!2022/07 ~DDR4 384GB DDR4 384GB DDR4 1024 GB DDR4 512 GB

PFNのストレージクラスタ8トータル約 8.4 PB(論理容量、拡大中)FileSystemMediumMN-J ストレージNFSHDDNVMeSSDHDFS Apache OzoneIcon pack by Icons8 - https://icons8.com

社内計算基盤が目指す姿● 多様なリテラシのユーザが使いやすいこと○ 「入社初日らクラスタで大規模に実験をして成果を出せる」● リソースを効率的かつ公平に利用できること○ 効率的：マルチテナント、スケジューリング、プロファイリング○ 公平性：各ユーザ利用した量に基づプリエンプションなど● 信頼性・運用効率○ 自動プロビジョニング○ 健全性の自動診断・保守省力化9取り組みの内容はオンプレML基盤 on Kubernetes #1 を参照ください！

最近のトピック10● 新し構築したクラスタ「MN-2b」● Pod のリソース要求量の最適化を助るしみ● Kubernetes クラスタのアップグレード

新しく構築したクラスタ「MN-2b」2022/07 より稼働中最新世代の GPU (A100, A30), CPU と大めの主記憶を搭載11MN-2b (A30)42 nodes(252 GPUs)A30 (24G)PCIe x 6100GbE x 2RoCEv2with SR-IOVMN-2b (A100)42 nodes(168 GPUs)A100 (80G)SXM4 x 4100GbE x 2RoCEv2with SR-IOV80 CPU Cores128 CPU CoresDDR4 1024 GB DDR4 512 GB多様なワークロードに対応Icon pack by Icons8 - https://icons8.com

使いたいGPUの種類を簡単に指定できるしくみ● クラスタ内の GPU の種類が増えた○ Kubernetes 的にはすべて nvidia.com/gpu● 課題● Node selector で意図通りの種類の GPU を指定するのは難しい○ 「V100なら何でも」「A30 いい」「VRAM 32 GB あれば何でも」● 各種 GPU の需要を知りたい○ ユーザどう GPU 種を選んだ意図を集計したい12

使いたいGPUの種類を簡単に指定できるしくみ● 解決策：gpu-v100-32gb のように指定できるように○ gpu-<GPU name>-<minimum VRAM amount>○ Admission webhook で node selector に変換● 結果○ ユーザ意図通りに GPU を選べるように○ 管理者ユーザの意図を反映した需要を把握でるように13* サンプルデータ

Pod のリソース要求量の最適化を助けるしくみオンプレクラスタの容量は限られている → 無駄なく使いたい● アプローチ 1: スケジューラで pod をうま詰め込む● アプローチ 2: 各 pod が必要十分な量だけリソースを要求する14�� Pod 使用中要求した不使用* サンプルデータ課題：Pod の最適なリソース要求量を決めるのは難しい / 面倒

Pod のリソース要求量の最適化を助けるしくみ解決策：適切なリソース要求量を自動で提案する15Icon pack by Icons8 - https://icons8.comVerticalPodAutoscalerDeploymentVPArecommenderoursystemkubernetes/autoscalervertical-pod-autoscaler2. watchresource usage3. write appropriateresource1. createtargetRef 4. watch

Kubernetes クラスタのアップグレード● PFN では minor version 一つ遅れで Kubernetes をアップグレード○ 1.24 への更新を準備中● Cluster API でクラスタのライフサイクルを管理● MAAS と Ansible でベアメタルマシンをプロビジョニング16

Kubernetes クラスタのアップグレード17eval MN-JProvision nodes with AnsibleCluster APIMAAS provider(in-house)+Custom OS imageEditmanifestsIcon pack by Icons8 - https://icons8.com

Kubernetes 1.24 といえば：dockershim の削除● PFN では 2021/07 に containerd に移行済み○ レジストリを Google Artifact Registry に移行したためキャッシュサーバへのミラー機能必要になった● キャッシュサーバの必要性○ クラウドらイメージを大量に pull するとコスト高い○ ML 向のイメージは大い・多様○ ノード多ローカルキャッシュ効にい● 95% ほどキャッシュヒット18

コンテナイメージのキャッシュ19Google ArtifactRegistryPull/push-throughcacheInternetInternal networkIcon pack by Icons8 - https://icons8.comキャッシュサーバから pullキャッシュサーバにpush もできるGAR にも write-through

We're Hiring!機械学習プラットフォームエンジニア (Infrastructure)● こんな環境にワクワクする方を募集しています！○ 日進月歩で進化している機械学習にフォーカスした計算技術を低レイヤーから高レイヤーまでトータルに吸収できる○ 大規模機械学習クラスタの開発・運用が経験できる○ Kubernetesを始めとするOSSコミュニティでも活躍できるチャンスがある○ HPCとCloud Nativeの境界領域という今後ますます重要になる分野の経験ができる○ 多様な要求・ユーザーリテラシをサポートするプラットフォーム設計・実装を経験できる20

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

23GPU のスケジューリングや断片化にどんな対策をしてる？

GPU のスケジューリング&断片化対策● GPU NodeにCPU Podをスケジューリング● 断片化対策○ 独自のNodeScoreプラグイン(Lua)■ Pod/Node種別による柔軟なスコアリング○ 同一PriorityによるPreemption24

GPUノードにCPU Podをスケジューリング25CPUGPUGPU PodsCPUが無駄��CPUGPUGPU PodsCPUPods��CPUGPUCPUPodsCPU詰めすぎてGPU使えない��CPUGPUCPUPodsCPU,GPU両方活用できてるPreemptGPU Pods��☠GPUPodsCPU,GPU両方活用できてるCPU PodをGPUノードにスケジュールしてCPUを有効利用CPU Podの優先度を下てGPU Podを邪魔しない

GPU断片化: 独自のNodeScoreプラグイン(Lua)Luaで様々なヒューリスティックを導入可26…888 GPU Pods右ら詰める(意訳)(でるためるように)<8 GPU PodsMostRequested(Greedy BinPacking)<8 GPU, 8 GPUのScoreが別(8GPUは主に分散学習向け)Resource Sharing Pod/Node用のScore(主にInteractive環境向け)2 4 1 2Resource Sharing Podは要求量をεにしているのでPod数だでNodeをScoring

Luaでロジック追加ってどうなの？● 👍メリット○ ちょっとしたノード追加や方針変更での重み変更などは楽○ 独自Pluginじゃなてもなり柔軟なPolicy 実装可能● 👎デメリット○ 結局e2eテストを行わないと怖て本番投入は無理■ コードで書るので、柔軟だテストしないと不安○ e2eテストを行うのはgoをビルドするのよりも時間る■ すでにスケジューラを拡張している場合、環境ある● 📜背景○ resource weightedなMostAllocated Plugin ない時代に開発れてそれを引継いでいる27

GPU断片化: 同一PriorityによるPreemption(Deschedulingに似ている)28Preempted and Defrag-ed● 先勝ちで占有れないように● 断片化したPodをPreemption対象にするとで断片化も防止

29どんなk8sコントローラ/Operator を開発してる？

どんな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

job-controller: MPIにおけるプロセス起動31launcher node$ mpiexec ./exechost1host2host3hostﬁlerank=0 (host1 node)$ ./execrank=1 (host2 node)$ ./execrank=2 (host3 node)$ ./execssh host2./execssh host1./execssh host3./execMPI_Comm_rank() -> 0 MPI_Comm_size() -> 3 MPI_Comm_rank() -> 1 MPI_Comm_size() -> 3 MPI_Comm_rank() -> 2 MPI_Comm_size() -> 3

job-controllerにおける起動とクリーンアップ32launcher pod$ mpiexec ./execworker0worker1worker2hostﬁlerank=0 (worker0 pod)$ ./execrank=1 (worker1 pod)$ ./execrank=2 (worker2 pod)$ ./execkubectl exec./exec./execkubectl exec./execConﬁgMap生てる？生てる？生てる？kind: MPIJob# 死活監視status: Running

kubeﬂowの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最近どんな障害あった？

● Pod 起動直後に名前解決に失敗して死ぬ！なぜ！○ 名前解決以外にもあらゆるクラスタ内のサービスに起動直後だアクセスでない（kube-apiserver も含む）● 失敗しないともあれば、起動後数十秒ダメなともある（そら）Pod 数多すると原因で、CNI プラグイン kubelet kube-proxy で問題起ているPod が起動直後に名前解決に失敗して死ぬ 😱 (1/3)35

pods/LIST に7秒以上もっちゃってる😇Pod が起動直後に名前解決に失敗して死ぬ 😱 (2/3)36

エラーや完了済みの Pods を削除するとで解消れるとを確認。● 根本対策: システムコンポーネントのチューニングやエラーや終了したPods の自動掃除を検討（まだ取り組めてない）● 対処療法: ネットワークの疎通確認でるまでスリープするコンテナを Init container として自動的に挿入Pod が起動直後に名前解決に失敗して死ぬ 😱 (3/3)37スリープどのらいで終了したをログで観測 (10分の1秒)

最近あった障害 - CIDRNotAvailable イベント● API Server 不調になった原因を探っていたら・・・● イベント多いの原因も？ → あまり見ないイベント出てる!?● CIDRNotAvailable !?!? なんだっれ● 最近、何変わったっ・・・もしして？38

CIDRNotAvailable: 原因● 最近追加したノードの一部だで発生● 250台に台数を減らすと発生しない● 256に境目ありそうな値では?● 結果分ったと● クラスタ全体のCIDR: /16● ノードのCIDRブロックサイズ: /24● ブロック数は8ビット分 😇39MN-2Bでノード増えた

最近あった障害 - 大量のOutOfCpu イベント● 起たと○ 大量のPod OutOfCpuイベントを発行しFailし続た○ ユーザらは確率的にPodの実行失敗するとの多数の問い合わせ○ ノードによらず発生・再起動などでも回復せず● 当時の様子○ 数分に一回スケジュール直後にFail状態になるPod 多数○ まずい40

大量の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どんなチーム構成で取り組んでいるのか教えて！

クラスタを取り巻く組織43MN-CoreClusterServicesClusterPlanningMN-Core企画&設計ASIC設計コンパイラ・ランタイム計算基盤サービス化計算基盤Project A利用・フィードバックファシリテーションProject BProject Z…利用・フィードバックファシリテーション利用・フィードバックファシリテーション連携連携連携

● Product Management/Support○ GitHub Issuesによる要望収集ベース○ Cluster Solution Architectによる吸い上○ Documentは基本Google Docs● 開発・運用○ テーマとのSIGを構成して所属(3ヶ月サイクル)○ それぞれのSIGで優先度を決定して活動○ 全体SyncはWeeklyCluster Servicesチーム内ではどう取り組んでいるか？44ユーザ直接要望ProjectSAによる吸上SAによる強力サポートProvisioning Monitoring Usability Resource Eﬃciency HardeningSIGs …※図はイメージです極端な所属の偏りはEngineering Managerによる調整

We're Hiring!機械学習プラットフォームエンジニア (Infrastructure)● こんな環境にワクワクする方を募集しています！○ 日進月歩で進化している機械学習にフォーカスした計算技術を低レイヤーから高レイヤーまでトータルに吸収できる○ 大規模機械学習クラスタの開発・運用が経験できる○ Kubernetesを始めとするOSSコミュニティでも活躍できるチャンスがある○ HPCとCloud Nativeの境界領域という今後ますます重要になる分野の経験ができる○ 多様な要求・ユーザーリテラシをサポートするプラットフォーム設計・実装を経験できる45

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

Movatterモバイル変換

Change Language

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

Recommended

More Related Content

What's hot

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

More from Preferred Networks

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