Behind The Scenes: Cloud Native Storage System for AI

AI向けクラウドネイティブなストレージシステムの裏側

My talk at https://event.cloudnativedays.jp/cndt2023/talks/1996 .

1. AI向けクラウドネイティブな ストレージシステムの裏側 2023-12-12 Cloud Native Days Tokyo 2023 Kota Uenishi (@kuenishi) Behind The Scenes: Cloud Native Storage System for AI
2. 2 Who Are You? Kota Uenishi @kuenishi • NTT研究所 ◦ HBaseみたいな分散データベースの開発 ◦ Jubatus (分散オンライン学習) • Basho Japan ◦ Riak (分散KVS) ◦ Riak CS (オブジェクトストレージ) ◦ Erlang/OTP • Nautilus Technologies ◦ Mesos を使ったスケジューラ Retz • Preferred Networks, Inc. ◦ ChainerMN ◦ 分散強化学習 (ChainerMN + ChainerRL) ◦ 社内ストレージ
3. 3 PFNの計算機インフラの用途 …and more
4. 4 自社計算基盤 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) 世界1位!! (ISC20, ISC21, SC21) MN-3 MN-Core x192 MN-2a V100 x1024 ストレージサーバ
5. Proposal 大規模な機械学習基盤を支える自社ストレージシステムの裏側について解説します。 1500 枚規模のアクセラレータを支える 10PB規模のクラウドネイティブなストレージとして、少人数 でApache Ozoneを運用してきました。 事業の成長に合わせて変わり続ける要件、増え続けるデータ量、世代ごとにますます高速化 するアクセラレータ、故障するハードウェア、こういった問題に対してどのようにこの 2年間5年 間対処してきたかを振り返ります
6. 6 クラウド？ネイティブ？ ストレージ？AI向け？
7. 7 クラウド？ SE Radio Episode 416 (2014) クラウドはつまりセルフサービス API叩いたら計算リソースがすぐに手に 入るということ
8. 8 クラウドネイティブ技術は、パブリッククラウド、プライベートク ラウド、ハイブリッドクラウドなどの近代的でダイナミックな環 境において、スケーラブルなアプリケーションを構築および 実行するための能力を組織にもたらします。 このアプローチ の代表例に、コンテナ、サービスメッシュ、マイクロサービス、 イミュータブルインフラストラクチャ、および宣言型APIがあり ます。 これらの手法により、回復性、管理力、および可観測性のあ る疎結合システムが実現します。 これらを堅牢な自動化と 組み合わせることで、エンジニアはインパクトのある変更を 最小限の労力で頻繁かつ予測どおりに行うことができます。 DEFINITION.md クラウドネイティブ？（恣意的な切り取り） • スケーラブルなアプリケーショ ンを構築できる • 回復性などがあり疎結合
9. 9 • 学習データを沢山おける • 学習結果を半永久的に保管できる • ストレージよりも計算機が貴重で高価 ◦ GPUやMN-Coreがフル回転できる速度で学習データを供給で きる ◦ 学習するときにダウンしていないこと AI向け？
10. 10 • APIを叩けばすぐにデータを読み書きできる • 回復性などがあり疎結合 • スケーラブルなAIワークロード ◦ いくらでもデータを置ける ◦ 計算機をいつでもフル回転させられる AIクラウドネイティブなストレージの要件まとめ
11. 11 初期
12. 12 ~2018年 • ChainerMN 開発・発表の前後 • MN-1 (NTT) やさくらインターネットのGPU環境を利用していた • Kubernetes導入前夜 • いくつかのストレージサーバーやシステムが運用されていた ◦ 古式ゆかしいRAID6 (だった気がする)のLinux NFS ◦ GPUサーバー100台以上にNFSをマウントしていた ◦ マウントさえすれば誰でも簡単に使えた
13. 13 • 何代目かのNFSサーバー • SATA SSDにして性能はかなり改 善した • 日付からも分かるとおりNFSサー バーは今日に至るまで使い続けて いる NFSサーバーの例
14. 14 ストレージサーバ(NFS)＋ローカルストレージ APIを叩けばすぐにデータを読み書きできる △マウントさえされていれば。しかし学習で使う にはローカルにコピーが必要だった 回復性などがあり疎結合 🤔Soft mount であってもストレージ側が再起 動や切断、ハングがあるとクライアント側が D のまま固まる(※) いくらでもデータを置ける 🙅置けない。一杯になったらおかわりして新し いサーバーに引っ越していた 計算機をいつでもフル回転させられる 🙅ボトルネックになりがち。ノードローカルスト レージにめいめいがコピーしていた ※See also: PFN の Kubernetes クラスタにおける Uninterruptible Sleep との付き合い方
15. 15 オブジェクトストレージ黎明期
16. 16 • ストレージの満杯が近くなるとエンジニア・リサーチャーが一斉に引っ越しをし ていた ◦ 季節の風物詩となっていた ◦ データを移すわけではなく、新しいデータは新しいストレージに書かれる • その度にパスが変更され、古いコードはどんどん動かなくなっていく • ビジネスの拡大とともにデータ量とIO負荷が増えていった • 無停止でスケールアウト可能、運用コストの比較的かからないシステムとして Hadoopを選定、クラスタを構築した Apache Hadoop (HDFS) 導入の経緯
17. 17 • 初期サーバー5台で物理1.4PB ◦ (実効450TB程度) • ユーザーも少なくシステムとしては一年 くらい平和だった • ある日突然データが増え始めた ◦ 動画データ ◦ シミュレーション結果 Hadoop運用始めました
18. 18 • 異なるスペックのHDDサーバーを同じ HDFSにDataNodeとして追加 • ラックに詰めすぎていた • 詰めすぎていたので・・・ ずっとDataNode拡張をしていた
19. 19 • リアルCircuit Breaker ◦ DataNodeの追加起動 ◦ ラック分電盤の許容電力を瞬間的に超過 • 複数台同時ダウン → データロス発生 ◦ 7バイトのファイル1つ ◦ シナリオの考慮漏れ ◦ Rack awareness設定を実施 サーバーはまとめて落ちる 起動時の消費電力が定常時の二倍だった
20. 20 このときは時間がなさすぎて100〜200 台くらいのHDDをドライブキャリアに手作 業でネジ止めした 仕事があるのはありがたいこと！ ずっとDataNode追加をしていた2
21. 21 HDFS APIを叩けばすぐにデータを読み書きできる △実質的にJava Client一択でありポータビリ ティはいまいち 回復性などがあり疎結合 🙆Cloudera Manager が強力であらゆる故障 を隠蔽できていたが、Small File Problemは あった いくらでもデータを置ける 🙆サーバーの調達がボトルネックになってい た。毎年サーバーとHDDを買い足した 計算機をいつでもフル回転させられる 🙅PythonとJVMの相性が悪くレイテンシもよく なかった。PFIOを開発してキャッシュできない か頑張った(※) ※See also: Distributed Deep Learning with Chainer and Hadoop
22. 22 • Apache Hadoopで有名になった問題だが、遍くファイルシステムに潜在的に 存在する問題 • 個別のファイルサイズが小さいと、blob量に対して相対的にメタデータが増え すぎ、メタデータ関連の処理がボトルネックや障害の原因になる • Apache Hadoopにおいては以下の影響が出た ◦ NameNodeにおけるメタデータの永続化や読み出しのパフォーマンスが 低下した ◦ NNの再起動にかかる時間がメタデータ数に比例して数時間〜かかるよう になった（⇒回復性） Small File Problem （早口解説）
23. 23 • MLやAIのプログラムはほぼ100%Pythonでの実装 • Pythonは libc ベースのメモリアロケーションであり、JVMとはメモリモデルが 全く異なる • PythonからHDFSを利用するには、JNIで実装されたlibhdfs経由でJVMを起動 してオブジェクトを受け渡ししていた • ChainerもPyTorchも multiprocessing でデータを読み出すのが主流 ◦ Zero-copy を目指すので execve はしない • 分散学習をするので OpenMPI とNCCLもリンクする • DMA (MPI), JVM, DMA (CUDA, NCCL), Python multiprocessing が相互に データを交換しあう複雑な構成 • パフォーマンスボトルネックやバグの温床になっていた Python-JVM 問題（早口解説）
24. 24 • HDFSで知られていた問題を大胆なアプローチで解決した派生システム ◦ See also: Apache Hadoopの新機能Ozoneの現状 | PPT • 最初はHDFSのサブプロジェクトであったが2019年に独立 • 以下の問題の解決が特にPFNにとってメリットが大きかった ◦ RocksDBによるメタデータ管理 (マスタ起動の高速化) ◦ ポータブルなAPI (AWS S3互換API, Python-JVM問題の解決) ◦ HDFSと同様の認証体系および移行のサポート ◦ 運用関連のものをほぼ流用できた（ JDKやPlaybook） ◦ Prometheus によるモニタリング ◦ etc… Apache Ozone 導入 (2021)
25. 25 • まあまあコミュニティに参加していた ◦ いくつかパッチも提案してマージされた • Upstreamに提案しにくいパッチは独自ビルドで社内だけ適用 • いけてないところは力技で運用解決したりしていた • やっとストレージチームが発足 ◦ それまでは入れ替わりつつ 2~4 人のパートタイムボランティア Apache Ozone 導入当時
26. 26 • 全然レスポンスが返ってこない • そんなにアクセスないはずなのにやけに遅い！ • OzoneManager というメタデータ管理プロセスがやけに燃えていた ListObjectsV2が遅かった問題(1/3)
27. 27 Async ProfilerでFlameGraph取得すると、ListObjectsV2 を受けて RocksDBから 読み出したPBオブジェクトのデシリアライズがボトルネックだった ListObjectsV2が遅かった問題(2/3) Protobuf Protobuf RocksDB RPC
28. 28 • 魔改造ですごく雑に特定のAPIをThrottlingした独自ビルドをデプロイ • +64行 ListObjectsV2が遅かった問題(3/3)
29. 29 1. DataNodeのCPUがやけに燃えている gzip外してデータ移動を速くした話 2. jstackで見てみるとデータ移動のgzip圧縮だったのでとりあえず無効化パッチ 3. HDDS-7622だったらしい (1.4 には入りそう)
30. 30 Apache Ozone APIを叩けばすぐにデータを読み書きできる ◎ AWS S3互換APIで簡単にアクセスできるよ うになった 回復性などがあり疎結合 🙆 HTTPベースのAPIなのでService Discoveryさえ適切なら故障をほぼ隠蔽できる in theory いくらでもデータを置ける 🙆サーバーの調達がボトルネックになってい た。毎年サーバーとHDDを買い足した 計算機をいつでもフル回転させられる △ HTTP/1.1ベースのAPIになり応答性は改善 したがGPUカーネルを埋められるほとではな かった
31. 31 普及＆安定？期
32. 32 • ストレージの容量需要は一定ラインで継続 • 毎日データノードの HDD が数本埋まる (> 20 TB/day) 社内の容量需要
33. 33 これは2つめのApache Ozoneク ラスタのサーバー このときは6ラック分購入した ずっとDataNodeを追加していた3
34. 34 • Ozoneの導入によってS3 APIが使いやすくなりHDFSをスキップしていたユー ザーが徐々に利用開始 • 「おそい」「遅い」「おそすぎる」「重い」「クラスタ重太郎」 社内で普及が始まる
35. 35 • ストレージクラスタ (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 になる ◦ 全然足りない！！！ 計算機をフル回転させられるか？ A100 の HBM2e は 1.9 TB/s ほどなので 帯域差は 104～106 倍くらい V100 x1024、A100 x168、 A30 x252 … 計 1,444 枚 MN-Core … 計 192 枚
36. 36 < 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
37. 37 < 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 性能ギャップ改善 ※See also: PFN Tech blog 深層学習のための分散キャッシュシステム
38. 38 Apache Ozone + 分散キャッシュ APIを叩けばすぐにデータを読み書きできる ◎ AWS S3互換APIで簡単にアクセスできるよ うになった 回復性などがあり疎結合 🙆 HTTPベースのAPIなのでService Discoveryさえ適切なら故障をほぼ隠蔽できる in theory いくらでもデータを置ける 🙆サーバーの調達がボトルネックになってい た。毎年サーバーとHDDを買い足した 計算機をいつでもフル回転させられる 🙆キャッシュがある状態でジョブを起動すると 初回からほぼフル回転できた
39. 39 2023年の増設 これで物理6PBくらい 来年年は+24台おかわり予定 ずっとDataNode拡張をしていた4 2023年の増設 これで物理6PBくらい 来年は+24台おかわり予定
40. 40 • 社内でエンジニアやリサーチャが学習を回せていればそれでよかった • しかし、実際に社内のチームが計算基盤上に開発したシステムを顧客に直接デリバリ するケースが増えてきた • 一定以上のダウンタイムがそのままビジネスに影響を与えることが増えてきた 対処 • 高いSLが要求されるコンポーネントのパブリッククラウドへの移行 • アーカイブデータをクラウドへ退避 • 不要なデータの削除 • 2クラスタ運用 • 安定化タスクの優先度を高く設定 • NFSストレージの完全撤廃 社内向けだったストレージに求める要件の変化
41. 41 • 「ステートフル」であるところ (⇔ ステートレス) • ステートレスアプリケーション … 例: 計算ノードや計算ジョブ ◦ 状態が揮発しても大丈夫 ◦ 困ったときは別のインスタンスでリトライできる • ステートフルアプリケーション … 例: ストレージ、データベース ◦ 状態が揮発してはいけない ◦ 別のインスタンスでのリトライはコストが高い ◦ 状態管理を正しく実装する難しさ （フォールトトレランス＆整合性） ▪ 上記を守った上で負荷分散と運用容易性を両立する 自社運用の強み・楽しみ
42. 42 今後の展望（宣伝）
43. 43 MN-Core2 クラウドサービス構想
44. 44 https://www.preferred.jp/ja/news/pr20231016/ MN-Core クラウドサービス化
45. 45 • クラウドサービスを開発中 • これまで社内で培われたAI向け機械学習基盤を一般提供したい • オブジェクトストレージは… ◦ これまでは社内向けなのでSLI, SLO がなかった 採用 ◦ ストレージエンジニア (ストレージの企画設計監理運用 ) ◦ 機械学習プラットフォームエンジニア (クラスタのサービス化 ) ◦ 大規模計算基盤エンジニア/リサーチャー (クラスタの物理設計、ファシリティ管理 ) Special Thanks: Slides (@k5342), 分散キャッシュ (@y1r96) 今後の展開
46. Making the real world computable