Behind The Scenes: Cloud Native Storage System for AI

Slide 1

Slide 1 text

AI向けクラウドネイティブなストレージシステムの裏側 2023-12-12 Cloud Native Days Tokyo 2023 Kota Uenishi (@kuenishi) Behind The Scenes: Cloud Native Storage System for AI

Slide 2

Slide 2 text

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) ○ 社内ストレージ

Slide 3

Slide 3 text

3 PFNの計算機インフラの用途 …and more

Slide 4

Slide 4 text

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 ストレージサーバ

Slide 5

Slide 5 text

Proposal 大規模な機械学習基盤を支える自社ストレージシステムの裏側について解説します。 1500 枚規模のアクセラレータを支える 10PB規模のクラウドネイティブなストレージとして、少人数でApache Ozoneを運用してきました。事業の成長に合わせて変わり続ける要件、増え続けるデータ量、世代ごとにますます高速化するアクセラレータ、故障するハードウェア、こういった問題に対してどのようにこの 2年間5年間対処してきたかを振り返ります

Slide 6

Slide 6 text

6 クラウド？ネイティブ？ストレージ？AI向け？

Slide 7

Slide 7 text

7 クラウド？ SE Radio Episode 416 (2014) クラウドはつまりセルフサービス API叩いたら計算リソースがすぐに手に入るということ

Slide 8

Slide 8 text

8 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 DEFINITION.md クラウドネイティブ？（恣意的な切り取り） ● スケーラブルなアプリケーションを構築できる ● 回復性などがあり疎結合

Slide 9

Slide 9 text

9 ● 学習データを沢山おける ● 学習結果を半永久的に保管できる ● ストレージよりも計算機が貴重で高価 ○ GPUやMN-Coreがフル回転できる速度で学習データを供給できる ○ 学習するときにダウンしていないこと AI向け？

Slide 10

Slide 10 text

10 ● APIを叩けばすぐにデータを読み書きできる ● 回復性などがあり疎結合 ● スケーラブルなAIワークロード ○ いくらでもデータを置ける ○ 計算機をいつでもフル回転させられる AIクラウドネイティブなストレージの要件まとめ

Slide 11

Slide 11 text

11 初期

Slide 12

Slide 12 text

12 ~2018年 ● ChainerMN 開発・発表の前後 ● MN-1 (NTT) やさくらインターネットのGPU環境を利用していた ● Kubernetes導入前夜 ● いくつかのストレージサーバーやシステムが運用されていた ○ 古式ゆかしいRAID6 (だった気がする)のLinux NFS ○ GPUサーバー100台以上にNFSをマウントしていた ○ マウントさえすれば誰でも簡単に使えた

Slide 13

Slide 13 text

13 ● 何代目かのNFSサーバー ● SATA SSDにして性能はかなり改善した ● 日付からも分かるとおりNFSサーバーは今日に至るまで使い続けている NFSサーバーの例

Slide 14

Slide 14 text

14 ストレージサーバ(NFS)＋ローカルストレージ APIを叩けばすぐにデータを読み書きできる △マウントさえされていれば。しかし学習で使うにはローカルにコピーが必要だった回復性などがあり疎結合 🤔Soft mount であってもストレージ側が再起動や切断、ハングがあるとクライアント側が D のまま固まる(※) いくらでもデータを置ける 🙅置けない。一杯になったらおかわりして新しいサーバーに引っ越していた計算機をいつでもフル回転させられる 🙅ボトルネックになりがち。ノードローカルストレージにめいめいがコピーしていた ※See also: PFN の Kubernetes クラスタにおける Uninterruptible Sleep との付き合い方

Slide 15

Slide 15 text

15 オブジェクトストレージ黎明期

Slide 16

Slide 16 text

16 ● ストレージの満杯が近くなるとエンジニア・リサーチャーが一斉に引っ越しをしていた ○ 季節の風物詩となっていた ○ データを移すわけではなく、新しいデータは新しいストレージに書かれる ● その度にパスが変更され、古いコードはどんどん動かなくなっていく ● ビジネスの拡大とともにデータ量とIO負荷が増えていった ● 無停止でスケールアウト可能、運用コストの比較的かからないシステムとして Hadoopを選定、クラスタを構築した Apache Hadoop (HDFS) 導入の経緯

Slide 17

Slide 17 text

17 ● 初期サーバー5台で物理1.4PB ○ (実効450TB程度) ● ユーザーも少なくシステムとしては一年くらい平和だった ● ある日突然データが増え始めた ○ 動画データ ○ シミュレーション結果 Hadoop運用始めました

Slide 18

Slide 18 text

18 ● 異なるスペックのHDDサーバーを同じ HDFSにDataNodeとして追加 ● ラックに詰めすぎていた ● 詰めすぎていたので・・・ずっとDataNode拡張をしていた

Slide 19

Slide 19 text

19 ● リアルCircuit Breaker ○ DataNodeの追加起動 ○ ラック分電盤の許容電力を瞬間的に超過 ● 複数台同時ダウン → データロス発生 ○ 7バイトのファイル1つ ○ シナリオの考慮漏れ ○ Rack awareness設定を実施サーバーはまとめて落ちる起動時の消費電力が定常時の二倍だった

Slide 20

Slide 20 text

20 このときは時間がなさすぎて100〜200 台くらいのHDDをドライブキャリアに手作業でネジ止めした仕事があるのはありがたいこと！ずっとDataNode追加をしていた2

Slide 21

Slide 21 text

21 HDFS APIを叩けばすぐにデータを読み書きできる △実質的にJava Client一択でありポータビリティはいまいち回復性などがあり疎結合 🙆Cloudera Manager が強力であらゆる故障を隠蔽できていたが、Small File Problemはあったいくらでもデータを置ける 🙆サーバーの調達がボトルネックになっていた。毎年サーバーとHDDを買い足した計算機をいつでもフル回転させられる 🙅PythonとJVMの相性が悪くレイテンシもよくなかった。PFIOを開発してキャッシュできないか頑張った(※) ※See also: Distributed Deep Learning with Chainer and Hadoop

Slide 22

Slide 22 text

22 ● Apache Hadoopで有名になった問題だが、遍くファイルシステムに潜在的に存在する問題 ● 個別のファイルサイズが小さいと、blob量に対して相対的にメタデータが増えすぎ、メタデータ関連の処理がボトルネックや障害の原因になる ● Apache Hadoopにおいては以下の影響が出た ○ NameNodeにおけるメタデータの永続化や読み出しのパフォーマンスが低下した ○ NNの再起動にかかる時間がメタデータ数に比例して数時間〜かかるようになった（⇒回復性） Small File Problem （早口解説）

Slide 23

Slide 23 text

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 問題（早口解説）

Slide 24

Slide 24 text

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)

Slide 25

Slide 25 text

25 ● まあまあコミュニティに参加していた ○ いくつかパッチも提案してマージされた ● Upstreamに提案しにくいパッチは独自ビルドで社内だけ適用 ● いけてないところは力技で運用解決したりしていた ● やっとストレージチームが発足 ○ それまでは入れ替わりつつ 2~4 人のパートタイムボランティア Apache Ozone 導入当時

Slide 26

Slide 26 text

26 ● 全然レスポンスが返ってこない ● そんなにアクセスないはずなのにやけに遅い！ ● OzoneManager というメタデータ管理プロセスがやけに燃えていた ListObjectsV2が遅かった問題(1/3)

Slide 27

Slide 27 text

27 Async ProﬁlerでFlameGraph取得すると、ListObjectsV2 を受けて RocksDBから読み出したPBオブジェクトのデシリアライズがボトルネックだった ListObjectsV2が遅かった問題(2/3) Protobuf Protobuf RocksDB RPC

Slide 28

Slide 28 text

28 ● 魔改造ですごく雑に特定のAPIをThrottlingした独自ビルドをデプロイ ● +64行 ListObjectsV2が遅かった問題(3/3)

Slide 29

Slide 29 text

29 1. DataNodeのCPUがやけに燃えている gzip外してデータ移動を速くした話 2. jstackで見てみるとデータ移動のgzip圧縮だったのでとりあえず無効化パッチ 3. HDDS-7622だったらしい (1.4 には入りそう)

Slide 30

Slide 30 text

30 Apache Ozone APIを叩けばすぐにデータを読み書きできる ◎ AWS S3互換APIで簡単にアクセスできるようになった回復性などがあり疎結合 🙆 HTTPベースのAPIなのでService Discoveryさえ適切なら故障をほぼ隠蔽できる in theory いくらでもデータを置ける 🙆サーバーの調達がボトルネックになっていた。毎年サーバーとHDDを買い足した計算機をいつでもフル回転させられる △ HTTP/1.1ベースのAPIになり応答性は改善したがGPUカーネルを埋められるほとではなかった

Slide 31

Slide 31 text

31 普及＆安定？期

Slide 32

Slide 32 text

32 ● ストレージの容量需要は一定ラインで継続 ● 毎日データノードの HDD が数本埋まる (> 20 TB/day) 社内の容量需要

Slide 33

Slide 33 text

33 これは2つめのApache Ozoneクラスタのサーバーこのときは6ラック分購入したずっとDataNodeを追加していた3

Slide 34

Slide 34 text

34 ● Ozoneの導入によってS3 APIが使いやすくなりHDFSをスキップしていたユーザーが徐々に利用開始 ● 「おそい」「遅い」「おそすぎる」「重い」「クラスタ重太郎」社内で普及が始まる

Slide 35

Slide 35 text

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 枚

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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 深層学習のための分散キャッシュシステム

Slide 38

Slide 38 text

38 Apache Ozone + 分散キャッシュ APIを叩けばすぐにデータを読み書きできる ◎ AWS S3互換APIで簡単にアクセスできるようになった回復性などがあり疎結合 🙆 HTTPベースのAPIなのでService Discoveryさえ適切なら故障をほぼ隠蔽できる in theory いくらでもデータを置ける 🙆サーバーの調達がボトルネックになっていた。毎年サーバーとHDDを買い足した計算機をいつでもフル回転させられる 🙆キャッシュがある状態でジョブを起動すると初回からほぼフル回転できた

Slide 39

Slide 39 text

39 2023年の増設これで物理6PBくらい来年年は+24台おかわり予定ずっとDataNode拡張をしていた4 2023年の増設これで物理6PBくらい来年は+24台おかわり予定

Slide 40

Slide 40 text

40 ● 社内でエンジニアやリサーチャが学習を回せていればそれでよかった ● しかし、実際に社内のチームが計算基盤上に開発したシステムを顧客に直接デリバリするケースが増えてきた ● 一定以上のダウンタイムがそのままビジネスに影響を与えることが増えてきた対処 ● 高いSLが要求されるコンポーネントのパブリッククラウドへの移行 ● アーカイブデータをクラウドへ退避 ● 不要なデータの削除 ● 2クラスタ運用 ● 安定化タスクの優先度を高く設定 ● NFSストレージの完全撤廃社内向けだったストレージに求める要件の変化

Slide 41

Slide 41 text

41 ● 「ステートフル」であるところ (⇔ ステートレス) ● ステートレスアプリケーション … 例: 計算ノードや計算ジョブ ○ 状態が揮発しても大丈夫 ○ 困ったときは別のインスタンスでリトライできる ● ステートフルアプリケーション … 例: ストレージ、データベース ○ 状態が揮発してはいけない ○ 別のインスタンスでのリトライはコストが高い ○ 状態管理を正しく実装する難しさ（フォールトトレランス＆整合性） ■ 上記を守った上で負荷分散と運用容易性を両立する自社運用の強み・楽しみ

Slide 42

Slide 42 text

42 今後の展望（宣伝）

Slide 43

Slide 43 text

43 MN-Core2 クラウドサービス構想

Slide 44

Slide 44 text

44 https://www.preferred.jp/ja/news/pr20231016/ MN-Core クラウドサービス化

Slide 45

Slide 45 text

45 ● クラウドサービスを開発中 ● これまで社内で培われたAI向け機械学習基盤を一般提供したい ● オブジェクトストレージは… ○ これまでは社内向けなのでSLI, SLO がなかった採用 ○ ストレージエンジニア (ストレージの企画設計監理運用 ) ○ 機械学習プラットフォームエンジニア (クラスタのサービス化 ) ○ 大規模計算基盤エンジニア/リサーチャー (クラスタの物理設計、ファシリティ管理 ) Special Thanks: Slides (@k5342), 分散キャッシュ (@y1r96) 今後の展開

Slide 46

Slide 46 text

Making the real world computable