Singularity と NVIDIA GPU Cloud で作る ハイブリッド機械学習環境の構築 / Building a hybrid environment for Machine Learning with Singularity and NGC

Singularity と NVIDIA GPU Cloud で作る ハイブリッド機械学習環境の構築 / Building a hybrid environment for Machine Learning with Singularity and NGC

July Tech Festa 2018 で発表した内容です。

1e5a15f4dc65c207a04a1e82a3f92e92?s=128

ryo nakamaru

July 29, 2018
Tweet

Transcript

  1. 2.

    中丸 良 @pottava • CTO at SUPINF • DevOps Engineer

    at Rescale Profile !2 • リモートワーカー • 夜はちゃんと温度が下がり、四季が感じられる地方、最高ですよみなさん
  2. 3.

    SUPINF Inc. !3 • クラウド / コンテナ 中心の コンサルティング /

    環境構築 / 受託開発 / 運用 • オンプレ × DGX-1 × Kubernetes 機械学習環境なども • スピンフ、と読みます
  3. 4.

    Rescale, Inc. !4 • クラウド HPC プラットフォームを SaaS で提供 •

    スケーラブルなシミュレーションや機械学習をとても手軽に • Singularity でのジョブ実行もサポート
  4. 6.

    今日お話しすること !6 • 機械学習環境構築時に見られる課題 • コンテナの導入で目指すこと • Singularity と HPC

    周辺技術の応用 • ハイブリッド環境構築の現実 @ SUPINF • オンプレミス + SaaS での解決策 @ Rescale
  5. 7.

    お伝えしたいこと !7 • 環境を作り維持する仕事も、コードを書けないと厳しい! • API を使い慣れておきましょう • Docker /

    Kubernetes だけではない、視野を広げよう • 今後の機械学習は、より HPC の領域に近づく • ハードウェアを正しく意識 する / しない • 長期運用を考えてオンプレ / IaaS / SaaS でバランスを
  6. 13.

    学習環境構築の難しさ !13 • 豊富な選択肢 / 関連技術の早すぎる進展 • HPC 的ノウハウが要求される学習の高速化 •

    既存認証基盤やストレージと新しい技術の統合 • まだデファクト / ベストプラクティスがない
  7. 16.

    !16

  8. 17.

    !17

  9. 25.

    !25 Docker の動き • Docker デーモン に対して要求 • containerd が名前空間などで

    隔離したコンテナを プロセスとして起動 • 実行ユーザーは 実行時の指定がなければ Docker イメージの定義次第
  10. 29.

    Docker の悩ましさ !29 • 現状は依然、デフォルト root レスでは動作しない • 実行ユーザーの扱いがとても難しい ‣

    Dockerfile?コンテナ起動時、動的にユーザー ID を指定? - 共有ストレージへ適切に 読み書きする難しさ • リソース利用上の制限 ‣ privileged やそれに相当する権限が必要になるケースがある ‣ MPI を使った マルチノードでの実行 が容易ではない
  11. 30.

    Better Docker への欲求 !30 もっと計算を速くしたい勢 運用を改善したい勢 IB 使いたい ノード またぎたい

    もっと MPI かんたんに root 渡すの 無理です 既存の  スケジューラ 使いたい
  12. 32.

    !32 Singularity • http://singularity.lbl.gov • Singularity = Docker のいいところ(特に 再現性)+

    HPC サポート ‣ 基本思想は一緒: Build, Ship, and Run any app, Anywhere ‣ 高性能ハードウェアや既存のジョブスケジューラがそのまま使える! • アプリケーションの実行に 特権ユーザーは不要! ‣ singularity run したユーザ のプロセスとしてコンテナが動作する
  13. 33.

    !33 Singularity の動き • Singularity バイナリ に 引数を渡して実行 • その

    Singularity プロセスが execv でコンテナのプロセスに 置き換えられる • 実行ユーザーは Singularity バイナリを 実行したユーザーのまま!
  14. 35.

    !35 Singularity のよさ $ MPI もネイティブにサポート • ChainerMN や uber/horovod

    なども動く(はず) • InfiniBand などもコンテナから問題なく使えます
  15. 38.

    より効率的な実行環境の管理へ !38 • サーバーではなく、イメージを実行環境として管理 ‣ Dockerfile を CI でバージョン管理 ‣

    Docker レジストリには や SaaS を検討 • サーバーそのものはこれまで通り構成管理 ‣ GPU ドライバ、Docker engine、NFS サーバー程度 - ex. シンプルな Ansible Playbook が維持しやすい
  16. 46.

    NGC とは? !46 ・NVIDIA 公式の Docker レジストリ ・Docker イメージは毎月更新される ・CUDA

    やライブラリはもちろん同梱 ・なんと無料 しかも GPU 最適化 されているなど、 自社で作るよりずっと高品質!! ありがたい!
  17. 49.

    より広い選択肢から選べるジョブスケジューラ !49 • Web 界隈の OSS が利用できるように ‣ ジョブスケジューラに特化したもの ではない

    が・・ ‣ Kubernetes(kubeflow など含む)への期待 • 既存の HPC ジョブスケジューラもコンテナ対応進行中! ‣ GPU / MPI 対応の容易な Singularity との併用も ‣ 既存の資産・仕組みをあまり変えずに導入できる
  18. 51.

      Kubernetes !51     計算ノード Tesla V100 社内 DC

    TITAN V 社内 DC • Docker との相性抜群 • NVIDIA さんもサポートを宣言 • 複数 GPU アーキテクチャでも OK Control plane(管理ノード) Kubernetes クラスタ
  19. 52.

      Kubernetes !52 ジョブを定義した YAML を Apply     計算ノード

    Tesla V100 社内 DC TITAN V 社内 DC • 例えば高性能な Tesla で計算したい!  YAML に書いた定義を渡すと・・ Control plane(管理ノード)
  20. 53.

      Kubernetes !53 ジョブを定義した YAML を Apply     計算ノード

    Tesla V100 社内 DC TITAN V 社内 DC • 空きがあり、条件に合うノードに配置 • nvidia-docker v1 / v2 すでに対応済 → コンテナへ適切に GPU 割り当て Control plane(管理ノード)
  21. 54.

      Kubernetes !54       計算ノード Tesla V100 社内

    DC TITAN V 社内 DC Tesla P100 AWS … • クラウドの VM もクラスタに ‣ 専用線 / Federated Cluster / GKE on-orem • Federated という方法もあったり Control plane(管理ノード)
  22. 55.

      Kubernetes !55 ジョブを定義した YAML を Apply      

    計算ノード Tesla V100 社内 DC TITAN V 社内 DC Tesla P100 AWS … • “クラウドで動かしたい” or / and • “Tesla P100 で動かしたい” Control plane(管理ノード)
  23. 57.

    大規模計算向きではない docker & k8s !57 • 仮想ネットワークの利用 ‣ サーバー間通信は DNS

    ベース ‣ MPI を使おうとすると足が引っ張られてしまう • (クラスタではなく)サーバーの “切り売り” 思想 ‣ CPU やメモリの上限値は “最高性能のサーバー” に依存 ‣ クラスタ全体では 10,000 コアあっても、指定はできない
  24. 58.

    ジョブスケジューラの違い !58 Web (Docker) 界隈 ・Singularity 対応なし ・基本ホストリソースの 切り売り scheduler

      GPU GPU GPU …   GPU GPU GPU … 確保! scheduler   GPU GPU GPU …   GPU GPU GPU … 確保! HPC 業界 ・ノードをまたいで リソースを確保できる ・ノード間通信するための設定もしてくれる
  25. 60.

    少なからず必要なインテグレーション !60 • Kubernetes 中心 ‣ Rancher 経由で認証認可や Docker レジストリと連携

    ‣ ジョブ投入時にマニフェストを 動的に生成 • インフラそのものは別途構成管理 ‣ GPU ドライバや nvidia-docker などは Ansible で ‣ ノードの伸縮縮退は k8s / Rancher の API を適切に
  26. 61.

    機械学習環境の CI / CD !61 • パイプライン 1 : ジョブ投入プロセスのバージョン管理

    ‣ k8s マニフェストを動的に作る作り込み部分 ‣ API やインフラそのもののテストも • パイプライン 2 : Docker イメージ ‣ NGC をラップする Dockerfile のバージョン管理 ‣ 脆弱性 / 秘密情報 / 社内レギュレーションのチェック
  27. 69.

    IaaS につきまとう重いインテグレーション !69 • アカウント連携 ‣ ID そのもの ‣ ファイルの共有(セキュリティ

    / パフォーマンス / ログ) • 計算クラスターのチューニング ‣ オンプレ同様の保守 ‣ 設定を最適化したクラスタのライフサイクル管理 • 利用量の測定・予算管理(組織 / ユーザー単位)
  28. 71.

    クラスタのチューニング !71 オンプレ並みに 鬼速く してね!! • CPU コア数、GPU 数、メモリなどのリソース制御 •

    プレースメントグループ(AWS) • ネットワーク / EBS 最適化(AWS) • InfiniBand(Azure) • and a lot more ..
  29. 72.
  30. 73.

    利用量の計測・予算管理 !73 クラスタ B、どこの誰 管理なの .. ? クラスタ A 起動後

    5 時間 クラスタ B 起動後 240 時間 クラスタ C 起動後 150 時間 管理者
  31. 81.

    極力 Jupyter notebook だけの世界に !81 • ソフトウェアの選択 ‣ 使いたいのはソフトウェアであって Docker

    ではない ‣ NGC ? docker login ? pull ? プロキシ設定 ? うーん .. • Jupyter notebook!That’s all I want! ‣ 研究者に必要なのはブラウザと共有フォルダ のみ • 分散学習させる時も、確認項目は予算と計算速度のバランスだけ
  32. 86.

    ご静聴ありがとうございました 参考文献: • Rescale エンタープライズ・ビッグコンピュート・プラットフォーム       https://www.rescale.com/jp/ • ディープ ラーニング

    コンテナー - NVIDIA GPU Cloud (NGC)           https://www.nvidia.com/ja-jp/gpu-cloud/deep-learning-containers/ • Containers for Science, Reproducibility and Mobility SINGULARITY P2      https://www.intel.com/content/dam/www/public/us/en/documents/presentation/hpc- containers-singularity-advanced.pdf • Singularityで分散深層学習(産総研佐藤さん)                 https://www.slideshare.net/htsst/singularity-85959573