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

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

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

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

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

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

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.
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
取り組みの内容は オンプレML基盤 on Kubernetes #1 を参照ください！

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

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

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

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

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

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

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

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

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

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

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

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

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

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.
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.
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.
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
最近どんな障害あった？

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

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

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

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

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

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

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

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

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

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