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

SageMakerで試行錯誤する推論パイプライン

5d90d49b09141ca005a0db171fe18ed0?s=47 moajo
August 21, 2020

 SageMakerで試行錯誤する推論パイプライン

5d90d49b09141ca005a0db171fe18ed0?s=128

moajo

August 21, 2020
Tweet

Other Decks in Programming

Transcript

  1. SageMakerで試⾏錯誤する 推論パイプライン moajo SoftwareEngineer DeNA

  2. ⾃⼰紹介 2 • moajo • 新卒2年⽬ • 普段はmlops的な仕事をしている • 趣味はフリークライミング

  3. 3 とあるプロジェクトにて

  4. プロジェクト要件 • 「試合」の動画を撮影 • 翌⽇までにいい感じに解析して「チーム」にフィードバック • 「チーム」が強くなる! 4

  5. 当初のつらみ • 今までPoC段階でずっと⽣EC2上でモデル実装、検証してきていた • 推論パイプラインはjobがSQSに投げられると、ベタ書き推論処理⼊りのAMIが EC2上にオートスケールしてそれを捌くというだけの質素なものだった • そしてじわじわと近づく限界 • パイプラインの全ステップが密結合

    →バージョン管理困難 • ⼀番リソースを⾷うステップに合わせてインスタンス選択 →リソースの無駄 • 依存関係が分離できてない →ライブラリバージョンが固定しづらい 5
  6. Amazon SageMaker • AWSのマネージド機械学習基盤 • GCPでいうAI platform? • 学習、推論、データセット管理など⾊々な機能が⼊ってる 6

  7. 7 とりあえず導⼊してみた

  8. とりあえず作ってみた構成 • SageMaker Batch Transformで推論 • Batch推論はAirflowからキック • Airflowでは短いスパンでSQSをポーリングしてdagをトリガーする •

    sagemakerは `[model_name]/[timestamp]` みたいなpathに書き出し 8 ポーリング 順序の管理 書き出し
  9. とりあえず作ってみた構成はどうだったか • Airflowの管理がちょっと⾯倒くさい • composerとか使うともっと楽なのかなぁ・・・ • 書き出し先のpathが分散しててイケてなかった • ⼀回のdag実⾏の結果が分散してて⼀覧性が低かった •

    BatchTransformへの書き換えが⾟い • BatchTransformは `model_fn`、`predict_fn`のような特定の名前の関数 を定義しておくといい感じに呼び出されるという仕組み • 今までベタ書きだった学習推論コードを書き換えないといけない • BatchTransform⾃体もちょっとイケてなかった(後述) 9
  10. BatchTransformのイケてなさ • SageMaker Endpointという推論エンドポイントホスティング機能がある • BatchTransformとEndpointは同⼀コードを使い回せるようになってる • 実はBatchTransformでは内部的にはendpointを建ててそこにhttp経由でリク エストしてる •

    データサイズがデカすぎたりするとhttpレイヤーから 例外が⾶んできてつらい(デフォルト設定だと) • 設定をちゃんと管理するのはそれはそれで⾯倒くさい・・・ • たぶん「もともとEndpointを普段使ってるけど、たまにそのモデルでバッチ推 論もしたい」みたいなユースケースを想定してるのでは? • 今回のケースではそもそもバッチ処理しかしない 10
  11. 修正した構成 • BatchTransformの代わりにProcessingを使う • Processingは前処理、後処理⽤サービスで、任意のコードを実⾏できる • GCPのai platform training jobとだいたい⼀緒

    • 逆にモデルはマネージドじゃなくなるので、⾃分でロードしたりバージョ ン管理しないといけない • 書き出し先pathをdag_idでまとめた • [run_id]/[model_id]/にした • めちゃくちゃ快適になった。絶対こっちのほうが良い 11
  12. 修正した構成はどうだったか • コードの修正は最⼩限になった • ベタ書きコードをそのまま実⾏できる • データサイエンティストの負担減 • 割とUXは良くなったが、お⾦が結構掛かるのがつらい •

    スポットインスタンス未対応 12
  13. コスト最適化の検討 • AWS Batchを使う? • ECSでバッチ処理を実⾏できる • スポットインスタンスも使える • もはやSageMakerじゃないが・・・

    • SageMaker Training jobを使う • 学習jobとして「推論」する • いいのか、こんな使い⽅して・・・ • でもスポットインスタンスも使える • 地味にProcessingより使えるインスタンスタイプが多い 13
  14. 最終的な構成 • Training jobで推論 • trainjobのマネージドな出⼒は丸ごと1ファイルに圧縮された上でs3に吐か れる • しかも出⼒なしに設定することもできない •

    推論結果は1ファイルに勝⼿に圧縮してほしくないので、推論処理の⼀部と して⼿動upload • 出⼒はダミーのパスに書き捨てる • 「70% saving」とか表⽰されるのでとてもお得感がある • Processingと⽐べてデータのマウント先が制約されるが、manifest fileは使い 回せた 14
  15. 未だ残るつらさ • manifest fileがローカルモードに対応してない • ローカルでの動作検証ができない • せめて出⼒を⾮圧縮で書き出すオプションがほしい 15

  16. 16 まとめ

  17. まとめ • 動画を⼊⼒とする推論パイプラインをSageMakerで作った • BatchTransformは純粋なバッチ処理には実は適してない • Processingは任意処理の実⾏環境として使い勝⼿が良い • Training jobはちょっと癖があるが、学習以外の⽤途にも使える

    • 若⼲余分な機能と制約が付いてるがほぼ任意コードを実⾏できる • 現状sagemakerでスポットインスタンスが使えるのはtraining jobのみ • 完全マネージドで従量課⾦なので、定常コストゼロで運⽤できていい感じ 17