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

“Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes and Horovod” の紹介と感想

“Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes and Horovod” の紹介と感想

Keigo Hattori

May 28, 2020
Tweet

More Decks by Keigo Hattori

Other Decks in Technology

Transcript

  1. “Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes and

    Horovod” の紹介と感想 MLOps enthusiast, @keigohtr #MLCT
  2. Today’s topic “Cost-efficient and scalable ML-experiments in AWS with spot-instances,

    Kubernetes and Horovod” について、ABEJA Platformの経験を踏まえて、ど こが良いと思ったかを紹介します 2
  3. Who am I Keigo Hattori Software Engineer 3 2009.3 Tohoku

    Univ / M.S. (Information Science) 2009.4~2017.10 Fuji Xerox / ML Engineer (NLP), etc 2017.11~2019.5LINE / Senior Software Engineer / Clova 2019.6~2020.5 ABEJA / Software Engineer / Platform 2020.5~ ??? MLOps 大好きです! @keigohtr
  4. • データをどう持つか? ◦ データセットはEBS、成果物はEFSを使うと良い • リソースとコストをどう最適化するか? ◦ Spot Instancesを使うと良い •

    機械学習ジョブをどう実行するか? ◦ Kubernetes Jobを使うと良い • 分散学習はどうするか? ◦ Horovodを使うと良い Takeaways 5
  5. AWSのストレージと特徴 7 S3 • 安い • 容量無限 • 堅牢性と可用性 が高い

    • ファイル単位でア クセス EFS • 高い • 容量無限 • Multi-AZ • 複数インスタンス からマウント可能 EBS • 安い (S3よりは高い) • 容量は事前申告 • 単一 AZ • 単一インスタンス からマウント可能
  6. “読み込み” にEBSを使うと辛い点 10 本当はこうしたい AZ AZ 学習ジョブ 学習データ O ur

    Experience しかし • EBSはSingle-AZなので Multi-AZなクラスタでマウ ントできない • EBSはk8s PVCで ReadWriteOnce
  7. 文献 (Rosebud AI) ではどうしたか? 11 • ジョブ毎にEBSを作成し、データセットをS3からコピーする • ジョブにマウントしたEBSはReadOnlyとして扱う •

    ジョブが完了したらEBSは廃棄するか、次のジョブで再利用する ◦ EBSを再利用するとデータセットのコピーが省略できる = 次のジョブをすぐに走らせられる
  8. ABEJA Platformではどうしているか? 12 • EBSを使わず、EFSを使っている ◦ EFSはMulti-AZかつMulti-attach ◦ ジョブがデータセットをS3からEFSにダウンロード ◦

    EFSのダウンロード先はデータセット毎に固定し、並列するジョブが協 力してデータセットをダウンロード ※ 学習時にデータセット読み込みが非常に遅いので、見直し中 O ur Experience
  9. “書き込み” にEFSを使う理由 13 成果物のサイズが予想できない • モデルのサイズはパラメータ次第 • 何を成果物に含めるかはユーザー次第 (e.g. ログファイル、ログの内容、中間モデル)

    Disk fullでジョブが死ぬことを避けたい • 成果物のサイズが見積もれない(上記) • インスタンスで複数のジョブが同時に走ることもある = 他のユーザーのジョブでDisk fullになりうる O ur Experience
  10. 文献 (Rosebud AI) ではどうしたか? 15 • 成果物はEFSに置く • チェックポイントを設けて中間出力をEFSに置く •

    ファイルはEFSの決められた場所に置く • 実験が中断したときに、中断したところから再開する • TensorBoardで各ジョブの結果を俯瞰できる
  11. 文献 (Rosebud AI) ではどうしたか?(1/2) 19 • Spot Instancesを使った ◦ Spot

    Instancesで安価な計算資源を確保 ◦ EKSで計算クラスタを構築 • Kubernetes Jobを使った ◦ ジョブのキューイングとスケジューリングはk8s
  12. 文献 (Rosebud AI) ではどうしたか?(2/2) 20 • Kubernetes Jobの突然死に対応した ◦ Spot

    Instancesのインスタンスは取り上げられることがある = KubernetesのJobが突然死する ◦ そこで、少なくとも10分に1度、チェックポイントとして学習の途中経過 をEFSに保存した ◦ Jobが失敗/突然死した場合、KubernetesはJobを再実行する ◦ JobはEFSを参照し、チェックポイントから学習を再開する
  13. ABEJA Platformではどうしているか?(2/3) 22 • インスタンスに使うイメージを固定した ◦ ユーザーがどのCUDAを使うか分からないので、All-in-Oneな機械学 習用のAMIを使う • インスタンスの種類を固定した

    ◦ CPU/メモリをユーザーに選ばせると、インスタンスの利用効率(e.g. Podがうまくハマらない)が悪くなる = ランニングコストが悪くなる ◦ “インスタンスのスペック” ≒ ”Podのスペック” にした O ur Experience
  14. ABEJA Platformではどうしているか?(3/3) 23 • ユーザーのコードはEFS上で動かした ◦ ユーザーのコードサイズが見積もれない = Disk fullで死ぬ可能性がある

    ◦ そこで、PodにEFSをマウントする ◦ EFS上にユーザーのコードをダウンロードし、実行する O ur Experience
  15. 文献 (Rosebud AI) ではどうしたか?(1/2) 26 • Horovodを採用した ◦ 複雑性を回避するため、複数のインスタンスは使わない ◦

    Multi-GPUを搭載したインスタンスで分散学習をする ◦ Horovodが提供するDocker Imageとサンプルコードが大変便利
  16. 文献 (Rosebud AI) ではどうしたか?(2/2) 27 (Spot InstancesによるJobの突然死への対応として) • master-workerに以下を担当させた ◦

    masterが他のworkerの変数を初期化する ◦ チェックポイントの書き出しをする ◦ チェックポイントからの復元をする • 乱数を固定する ◦ シャッフリングやdata splitを再現させるため
  17. • データをどう持つか? ◦ データセットはEBS、成果物はEFSを使うと良い • リソースとコストをどう最適化するか? ◦ Spot Instancesを使うと良い •

    機械学習ジョブをどう実行するか? ◦ Kubernetes Jobを使うと良い • 分散学習はどうするか? ◦ Horovodを使うと良い Retrospective 29
  18. • Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes

    and Horovod • スポットインスタンスを効率的に管理するSpotinstを使おう • 顧客のアプリケーションコードが動くマルチテナント環境における課題と EKSにたどり着くまで Reference 31