Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Behind The Scenes: Cloud Native Storage System ...

UENISHI Kota
December 12, 2023

Behind The Scenes: Cloud Native Storage System for AI

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

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

UENISHI Kota

December 12, 2023
Tweet

More Decks by UENISHI Kota

Other Decks in Technology

Transcript

  1. 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) ◦ 社内ストレージ
  2. 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 ストレージサーバ
  3. 8 クラウドネイティブ技術は、パブリッククラウド、プライベートク ラウド、ハイブリッドクラウドなどの近代的でダイナミックな環 境において、スケーラブルなアプリケーションを構築および 実行するための能力を組織にもたらします。 このアプローチ の代表例に、コンテナ、サービスメッシュ、マイクロサービス、 イミュータブルインフラストラクチャ、および宣言型APIがあり ます。 これらの手法により、回復性、管理力、および可観測性のあ

    る疎結合システムが実現します。 これらを堅牢な自動化と 組み合わせることで、エンジニアはインパクトのある変更を 最小限の労力で頻繁かつ予測どおりに行うことができます。 DEFINITION.md クラウドネイティブ?(恣意的な切り取り) • スケーラブルなアプリケーショ ンを構築できる • 回復性などがあり疎結合
  4. 12 ~2018年 • ChainerMN 開発・発表の前後 • MN-1 (NTT) やさくらインターネットのGPU環境を利用していた •

    Kubernetes導入前夜 • いくつかのストレージサーバーやシステムが運用されていた ◦ 古式ゆかしいRAID6 (だった気がする)のLinux NFS ◦ GPUサーバー100台以上にNFSをマウントしていた ◦ マウントさえすれば誰でも簡単に使えた
  5. 14 ストレージサーバ(NFS)+ローカルストレージ APIを叩けばすぐにデータを読み書きできる △マウントさえされていれば。しかし学習で使う にはローカルにコピーが必要だった 回復性などがあり疎結合 🤔Soft mount であってもストレージ側が再起 動や切断、ハングがあるとクライアント側が

    D のまま固まる(※) いくらでもデータを置ける 🙅置けない。一杯になったらおかわりして新し いサーバーに引っ越していた 計算機をいつでもフル回転させられる 🙅ボトルネックになりがち。ノードローカルスト レージにめいめいがコピーしていた ※See also: PFN の Kubernetes クラスタにおける Uninterruptible Sleep との付き合い方
  6. 16 • ストレージの満杯が近くなるとエンジニア・リサーチャーが一斉に引っ越しをし ていた ◦ 季節の風物詩となっていた ◦ データを移すわけではなく、新しいデータは新しいストレージに書かれる • その度にパスが変更され、古いコードはどんどん動かなくなっていく

    • ビジネスの拡大とともにデータ量とIO負荷が増えていった • 無停止でスケールアウト可能、運用コストの比較的かからないシステムとして Hadoopを選定、クラスタを構築した Apache Hadoop (HDFS) 導入の経緯
  7. 19 • リアルCircuit Breaker ◦ DataNodeの追加起動 ◦ ラック分電盤の許容電力を瞬間的に超過 • 複数台同時ダウン

    → データロス発生 ◦ 7バイトのファイル1つ ◦ シナリオの考慮漏れ ◦ Rack awareness設定を実施 サーバーはまとめて落ちる 起動時の消費電力が定常時の二倍だった
  8. 21 HDFS APIを叩けばすぐにデータを読み書きできる △実質的にJava Client一択でありポータビリ ティはいまいち 回復性などがあり疎結合 🙆Cloudera Manager が強力であらゆる故障

    を隠蔽できていたが、Small File Problemは あった いくらでもデータを置ける 🙆サーバーの調達がボトルネックになってい た。毎年サーバーとHDDを買い足した 計算機をいつでもフル回転させられる 🙅PythonとJVMの相性が悪くレイテンシもよく なかった。PFIOを開発してキャッシュできない か頑張った(※) ※See also: Distributed Deep Learning with Chainer and Hadoop
  9. 22 • Apache Hadoopで有名になった問題だが、遍くファイルシステムに潜在的に 存在する問題 • 個別のファイルサイズが小さいと、blob量に対して相対的にメタデータが増え すぎ、メタデータ関連の処理がボトルネックや障害の原因になる • Apache

    Hadoopにおいては以下の影響が出た ◦ NameNodeにおけるメタデータの永続化や読み出しのパフォーマンスが 低下した ◦ NNの再起動にかかる時間がメタデータ数に比例して数時間〜かかるよう になった(⇒回復性) Small File Problem (早口解説)
  10. 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 問題(早口解説)
  11. 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)
  12. 30 Apache Ozone APIを叩けばすぐにデータを読み書きできる ◎ AWS S3互換APIで簡単にアクセスできるよ うになった 回復性などがあり疎結合 🙆

    HTTPベースのAPIなのでService Discoveryさえ適切なら故障をほぼ隠蔽できる in theory いくらでもデータを置ける 🙆サーバーの調達がボトルネックになってい た。毎年サーバーとHDDを買い足した 計算機をいつでもフル回転させられる △ HTTP/1.1ベースのAPIになり応答性は改善 したがGPUカーネルを埋められるほとではな かった
  13. 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 枚
  14. 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
  15. 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 深層学習のための分散キャッシュシステム
  16. 38 Apache Ozone + 分散キャッシュ APIを叩けばすぐにデータを読み書きできる ◎ AWS S3互換APIで簡単にアクセスできるよ うになった

    回復性などがあり疎結合 🙆 HTTPベースのAPIなのでService Discoveryさえ適切なら故障をほぼ隠蔽できる in theory いくらでもデータを置ける 🙆サーバーの調達がボトルネックになってい た。毎年サーバーとHDDを買い足した 計算機をいつでもフル回転させられる 🙆キャッシュがある状態でジョブを起動すると 初回からほぼフル回転できた
  17. 40 • 社内でエンジニアやリサーチャが学習を回せていればそれでよかった • しかし、実際に社内のチームが計算基盤上に開発したシステムを顧客に直接デリバリ するケースが増えてきた • 一定以上のダウンタイムがそのままビジネスに影響を与えることが増えてきた 対処 •

    高いSLが要求されるコンポーネントのパブリッククラウドへの移行 • アーカイブデータをクラウドへ退避 • 不要なデータの削除 • 2クラスタ運用 • 安定化タスクの優先度を高く設定 • NFSストレージの完全撤廃 社内向けだったストレージに求める要件の変化
  18. 41 • 「ステートフル」であるところ (⇔ ステートレス) • ステートレスアプリケーション … 例: 計算ノードや計算ジョブ

    ◦ 状態が揮発しても大丈夫 ◦ 困ったときは別のインスタンスでリトライできる • ステートフルアプリケーション … 例: ストレージ、データベース ◦ 状態が揮発してはいけない ◦ 別のインスタンスでのリトライはコストが高い ◦ 状態管理を正しく実装する難しさ (フォールトトレランス&整合性) ▪ 上記を守った上で負荷分散と運用容易性を両立する 自社運用の強み・楽しみ
  19. 45 • クラウドサービスを開発中 • これまで社内で培われたAI向け機械学習基盤を一般提供したい • オブジェクトストレージは… ◦ これまでは社内向けなのでSLI, SLO

    がなかった 採用 ◦ ストレージエンジニア (ストレージの企画設計監理運用 ) ◦ 機械学習プラットフォームエンジニア (クラスタのサービス化 ) ◦ 大規模計算基盤エンジニア/リサーチャー (クラスタの物理設計、ファシリティ管理 ) Special Thanks: Slides (@k5342), 分散キャッシュ (@y1r96) 今後の展開