PFN の研究活動を支えるストレージシステム（第 56 回 情報科学若手の会）

PFN は第 56 回 情報科学若手の会を支援しています。今回は PFN のスパコンと一緒に自社運用しているストレージシステムについて、なぜ自社でストレージを運用するのか？使いやすく運用しやすいストレージとしてどんな機能を重視するのか？どのように性能を実現するのか？の視点でストレージ運用の楽しさについてご紹介しました。

Transcript

1. PFNの研究活動を支える ストレージシステム 第56回 情報科学若手の会 杉原 航平 / 株式会社 Preferred Networks
2. 2 自己紹介 • 杉原 航平 （すぎはらこうへい） • 業務内容 ◦ PFN のオンプレストレージ全般 (企画、設計、管理、運用、サポート、…) • 所属 ◦ 株式会社 Preferred Networks (2021/04 -) ◦ 筑波大学大学院 博士後期課程 (2023/10 -) • 経歴 ◦ 2012/04: 徳山高専 情報電子工学科 入学 ◦ 2017/04: 筑波大学 情報科学類 編入学 ◦ 2019/04: 同大学院 コンピュータサイエンス専攻 入学 HPC、並列ファイルシステム
3. 3 本日の内容 • Preferred Networks (PFN) について ◦ どんな組織・事業か ◦ 自社計算基盤紹介: MN-2, MN-3 • 自社ストレージについて ◦ ストレージクラスタ紹介 ◦ 自社ストレージの需要、必要性 • ストレージの安定運用に必要な技術 ◦ 負荷分散、データリバランス、フォールトトレランス、分散合意技術 ◦ 記憶階層、性能ギャップの改善、インタフェース抽象化 • 今後の課題
4. 4 Preferred Networks（PFN）会社概要 設立 本社 代表取締役 従業員数 事業内容 主要子会社 出資企業 2014年3月 東京都千代田区 西川徹（最高経営責任者）、岡野原大輔（最高研究責任者） 約300名（2022年2月） 深層学習やロボティクスなどの先端技術を応用したソフト ウェア・ハードウェア・ネットワーク技術の研究・開発・販売 Preferred Networks America, Inc. 株式会社Preferred Computational Chemistry 株式会社Preferred Robotics トヨタ自動車株式会社 ファナック株式会社 日本電信電話株式会社 ENEOS ホールディングス株式会社 中外製薬株式会社 株式会社博報堂DYホールディングス 株式会社日立製作所 三井物産株式会社 みずほ銀行株式会社 東京エレクトロン株式会社 ミッション： 現実世界を計算可能にする
5. 5 PFNの主な研究領域と事業化領域 PFNは深層学習などのソフトウェア技術と、それを支える計算インフラなどのハードウェア技術を 融合し、様々な産業領域で最先端技術の実用化・事業化に取り組んでいます。 事業化領域 研究領域 計算インフラ 機械学習・深層学習 シミュレーション 画像認識 自然言語処理 ロボティクス 最適化 製造業 交通 システム エンタメ その他 プラント 最適化 材料探索 創薬・ ヘルスケア ロボット データ 生成補完 異常検知
6. 6 世界1位!! (ISC20, ISC21, SC21) 拠点名: MN-J PFN の自社計算基盤 MN-2a, MN-2b MN-3 Icon pack by Icons8 - https://icons8.com MN-2b A100 x168, A30 x252 Object Storage SATA HDD 14 TB x2160 100G IP-Clos Network Login Node NFS (home, archive) MN-3 MN-Core x192 MN-2a V100 x1024 ストレージサーバ
7. 7 PFN の自社計算基盤 拠点名: MN-J Icon pack by Icons8 - https://icons8.com MN-2b (A30) 42 nodes (252 GPUs) A30 (24 G) PCIe x 6 100 GbE x 2 RoCEv2 with SR-IOV MN-2b (A100) 42 nodes (168 GPUs) A100 (80 G) SXM4 x 4 100 GbE x 2 RoCEv2 with SR-IOV MN-2a 128 nodes (1024 GPUs) V100 (16 / 32 G) SXM2 x 8 100 GbE x 4 RoCEv2 with SR-IOV MN-3 48 nodes (192 MN-Cores) MN-Core x 4 100 GbE x 2 MN-Core DirectConnect 80 CPU Cores 128 CPU Cores 48 CPU Cores 36 CPU Cores DDR4 384 GB DDR4 384 GB DDR4 1024 GB DDR4 512 GB
8. 8 カスタム Kubernetes スケジューラ • 「入社初日からクラスタで大規模に実験して成果を出せる環境」 • 様々なリテラシレベルに対応するインタフェース ◦ Kubernetes を知らなくてもジョブを作成できる ◦ 使いやすいストレージシステム（スケーラビリティ、サードパーティサポート） • 公平かつ効率的に利用できる環境の提供 ◦ スロットルによる同時実行数・クレジットによる最大実行数抑制 ◦ プリエンプションを併用した優先度付きスケジューリング ◦ ネットワークトポロジを考慮したジョブの配置 簡単かつ公平に利用できる計算基盤を目指して
9. 9 • ・・・ここまでの話はこれまでよく発信してきました ◦ Kubernetes、スケジューラ、・・・ご存知の方がいらっしゃるかもしれません • ここからが今日の本題です ◦ ストレージの自社運用 今日はストレージの話をします
10. 10 • PFN では自社技術の育成を競争力にしている ◦ 利点: ボトルネック解析や障害対応の容易性・俊敏性、低コスト化、特定ベンダ のロックイン防止 ◦ 欠点: サービス品質が限定される、実現可能性・持続性の事前評価が難しい、 手間がかかる（構築コスト・時間的コスト） • ストレージ構築にあたっての議論 ◦ クラウド vs オンプレミス ▪ 自社チップ・GPU の近くにストレージを置きたい （帯域面の課題） ◦ プロプライエタリ（アプライアンス） vs オープンソースソフトウェア ▪ 我々が中身を知って運用できることが重要なので、OSSを選択 なぜ自社でストレージを運用するのか？
11. 11 • Cloudera Manager による省力運用 • 安定性 • Small File Problem への対処 • S3 API サポート • オープンソースソフトウェア選定の検討事項 ◦ 問題発生時にコードを読める、直せる、データを復旧できる ◦ ユーザ空間で動作する ◦ 手弁当な小体制でも運用できること • これまでの運用実績 ◦ HDFS (～ 2021) → Apache Ozone (2021 ～) → ？？？ PFN とオブジェクトストレージ
12. 12 ストレージサーバ およそ 100 台 総容量 30 PB (物理) • 現在は 2 系統の Apache Ozone クラスタを自社運用中 オブジェクトストレージの構成 クラスタ構成 #1 クラスタ構成 #2 総物理容量 18.1 PB 12.1 PB データノード台数 36 72 デバイス SATA HDD SATA HDD インターコネクト 100 GbE x2 100 GbE x2 ソフトウェア Apache Ozone 1.3.x Apache Ozone 1.3.x 運用開始 2021 2022 構成 OM/SCM HA
13. 13 • ストレージの容量需要は一定ラインで継続 • 毎日データノードの HDD が数本埋まる (> 20 TB/day) 社内の容量需要の増加
14. 14 • 学習データをコンピュータが生成する ◦ 現実世界では再現が難しい特殊ケースを含め、サンプルを大量生成 • ビジネス応用の例 ◦ 3DCG による仮想空間のレンダリング結果 ⇒ PFN 3D/4D Scan ◦ 原子シミュレータによる物理現象のシミュレート結果 ⇒ Matlantis ◦ 家庭内走行動画とセグメンテーション ⇒ Kachaka シミュレーションによる学習データの自動生成
15. 15 • 「サーバ故障のための深夜対応を避けたい」 ◦ 故障時に可能な限り自動復旧できること ◦ 多少の故障からデータを保護できること • 「いつでも安定した性能を提供してほしい」 ◦ データノード間で I/O アクセスを均等に分散できること ◦ データ使用量を均等に分散できること • 「データノードをいつでも追加したい」 ◦ 水平スケール（容量・帯域の拡張）が容易であること 自社ストレージに求める要素
16. 16 • レプリケーション: データノードにデータを複製して配置する • 自己回復機能: データノードが落ちてもレプリカ数を規定値に復旧できる レプリケーションによるデータ保護 #1 #2 #1 #3 #1 #2 #3 #2 #3 #1 #2 #3 #2 #3 #1 #1 #3 #2 #1 #2 #3 再複製 再複製 データノード1 データノード2 データノード3 データノード4 データノード1 データノード2 データノード3 データノード4
17. 17 • 負荷分散機能: 書き込み・読み込みでデータノード間の負荷を均一にする ◦ Write: ノード毎のデータ使用量が均等になるようにデータを配置する ◦ Read: ノード間でリクエストが分散するように読む I/O アクセス分散 1 1 1 2 データ配置ポリシ 4 2 2 cost = 1 cost = 2 cost = 2 cost = 1 3 3 3 cost = 2 cost = 1 1 1 1 2 2 2 3 3 3 1 を3人が読む を書く 4 4 4 2 を3人が読む 使用量の集計・更新とフィードバックを適切な頻度で行う 4 Rack A Rack B Rack C
18. 18 バランサーが データを移動する • 再バランス機能: 使用量の偏りを修正する ◦ 使用量の偏りが発生する機会は少なくない ▪ 空き容量確保のためにクラスタを拡張する （データノード追加） ▪ 故障したディスクを新品に交換する ◦ 偏りがあると特定のデータノードに負荷が集中する 水平スケール (容量と帯域) の容易性 データノード 追加 平均使用量 データノード
19. 19 PFN では HDD が 2,160 枚。 故障率 0.1% としても 2.16 枚は壊れる計算。 • 故障ドメインを想定して対策する • サーバは壊れる ◦ データ用ディスク (HDD) ◦ ブート用ディスク ◦ NIC、トランシーバ、ケーブル ◦ マザーボード ◦ 電源ユニット 物理故障・障害対策
20. 20 • ラックのブレーカートリップ ◦ CPU 負荷増大 → 想定電力超過 → ラックのブレーカー断 ◦ 事前想定の消費電力を大幅に超過 • 複数台ダウン → データロス発生 ◦ シナリオの考慮漏れ ◦ レプリカの配置ポリシを変更 サーバラックのブレーカーは落ちる 起動時の消費電力が定常時の二倍だった
21. 21 • Raft [ATC’14] ◦ 状態を多数決で確定する。一度確定できた状態は失われない ◦ ノードが故障しても正しい唯一の状態を確定できる ◦ ネットワークが分断されてもパラレルワールドが発生しない ◦ 故障したはずのノードが突然戻ってきても正しい状態に遷移できる • Apache Ozone の場合は Apache Ratis で Raft を実装 ◦ Write コマンドは全て Raft で合意を取る ◦ データノード ⇔ メタデータサーバ ◦ データノード ⇔ データノード 状態を保証する仕組み (論理)
22. 22 • ストレージ運用で必要な要素について ◦ レプリケーション、リバランス、負荷分散 • フォールトトレラントなストレージシステムに必要な要素について ◦ サーバは壊れる ◦ ラックごと電源が落ちる ◦ Raft による状態の保証 ◦ ソース電源も停電しうる • では安定性は十分あるということにして、性能については？ ◦ 演算器が暇にならないようにデータを運ぶ方法とは？ ここまでのまとめ
23. 23 • ストレージクラスタ (HDD 構成) の理論性能 ◦ HDD の性能は最良で 200 MB/s (シーケンシャルリード) ◦ 構成#1 … 200 MB/s * 36 bays/node * 36 nodes = 259 GB/s ◦ 構成#2 … 200 MB/s * 12 bays/node * 72 nodes = 173 GB/s • アクセラレータ毎に使えるストレージの理論帯域は？ ◦ 259 GB/s / 1,444 = 179 MB/s ◦ 173 GB/s / 1,444 = 120 MB/s • 細かいランダムリードなので実効性能は 1/100 くらい ◦ < 2.0 MB/s になる ◦ 全然足りない！！！ V100 x1024、A100 x168、 A30 x252 … 計 1,444 枚 MN-Core … 計 192 枚 A100 の HBM2e は 2.0 TB/s なので 帯域差は 104～106 倍くらい 性能は？
24. 24 < 100 ms, 10 PB+, (～3 GB/s) 性能ギャップ < 100 us, 1.5 TB, (4 GB/s) < 1 us, 80 GB, (2.0 TB/s) Compute Node (Local) Storage (Remote) HBM2e NVMe SSD (local) HDD (remote) DDR4 < 15 ns, 1 TB, (～400GB/s) GPU ローカルストレージ オブジェクトストレージ (Apache Ozone) RAM
25. 25 • 計算とオブジェクトストレージの性能ギャップ ◦ オブジェクトストレージは HDD ベース ◦ 大容量だがランダムアクセスには弱い • 分散キャッシュシステムを内製して提供 ◦ NVMe SSD ベース ◦ 容量はそこそこ、ランダムアクセス性能改善 ◦ Consistent-Hashing によるデータ分散 ◦ HTTP REST API で PUT/GET をサポート ◦ LRU で古いデータは無効化される 性能ギャップの解消 詳細は下記のスライド・ブログを参照 https://tech.preferred.jp/ja/blog/distributed-cache-for-deep-learning/ https://speakerdeck.com/pfn/k8s-tokyo-60-distributed-cache-system
26. 26 < 100 ms, 10 PB+, (～3 GB/s) 現在のストレージ階層 < 2 ms, 66 TB+, (～50 GB/s) < 100 us, 1.5 TB, (4 GB/s) < 1 us, 80 GB, (2.0 TB/s) Compute Node (Local) Storage (Remote) HBM2e NVMe SSD (local) NVMe SSD (remote) HDD (remote) DDR4 < 15 ns, 1 TB, (～400GB/s) GPU ローカルストレージ 分散キャッシュシステム (内製) オブジェクトストレージ (Apache Ozone) RAM 性能ギャップ改善
27. 27 ファイルシステム API インタフェース抽象化 Python Application PFIO Jupyter Notebook S3 NFS HDFS HTTP Cache Local Cache import pfio backend_fs = pfio.v2.from_url('ozone://bucket/'); with pfio.v2.HTTPCachedFS(url = ’http://cache/’, fs = backend_fs) as fs: with fs.open('bin-1m.dat', 'rb') as fp: buf = fp.read() print(len(buf)) % python3 ./example.py 1048576 0.12042808532714844 % python3 ./example.py 1048576 0.017198801040649414 https://github.com/pfnet/pfio https://pfio.readthedocs.io/en/latest/index.html [ozone] scheme = s3 endpoint = ... 図: キャッシュによるレスポンスタイム改善 図: 分散キャッシュと S3 API の抽象化
28. 28 • オブジェクトストレージの性能改善・機能向上 ◦ Tail-latency 改良 ▪ RPC & Raft のリトライ処理最適化 ▪ メタデータ処理のジャイアントロック ◦ データノード使用量偏りの解消 ◦ Kubernetes 連携強化 • そのほか ◦ 複数拠点間データ移動の最適化 （スケジューラ連携検討） ◦ 次世代ストレージの検討 （高容量 HDD） ◦ 形式手法によるレプリケーション実装の検査 今後やっていきたいこと
29. 29 • 「ステートフル」であるところ (⇔ ステートレス) • ステートレスアプリケーション … 例: 計算ノードや計算ジョブ ◦ 状態が揮発しても大丈夫 ◦ 困ったときは別のインスタンスでリトライできる • ステートフルアプリケーション … 例: ストレージ、データベース ◦ 状態が揮発してはいけない ◦ 別のインスタンスでのリトライはコストが高い ◦ 状態管理を正しく実装する難しさ （フォールトトレランス） ▪ 上記を守った上で負荷分散と運用容易性を両立する まとめ: ストレージの面白く、難しいところ
30. 30 • こんな環境に興味のある人を募集しています！！！ ◦ 大規模計算クラスタ・ストレージクラスタの設計・構築および運用 ◦ 独自アーキテクチャを持つアクセラレータのクラスタ化および商用化 ◦ Kubernetes や Apache Ozone など OSS コミュニティへの貢献 • 計算基盤関連のポジション ◦ ストレージエンジニア (ストレージの企画設計監理運用) ◦ 機械学習プラットフォームエンジニア (クラスタのサービス化) ◦ 大規模計算基盤エンジニア/リサーチャー (クラスタの物理設計、ファシリティ管理) • その他の採用情報についても採用ページをご確認ください ◦ コンパイラ、ASIC 設計、サービス開発、・・・ 新卒採用もあります！！ （さいごに） 採用情報
31. Making the real world computable