gokartの運用と課題について

Transcript

1. 1.

   【MLOps勉強会】
 gokartを利用した
 ワークフロー運用と課題について
 
 エムスリー株式会社　AI・機械学習チーム　河合 俊典 (@vaaaaanquish)
 https://m3-engineer.connpass.com/event/159721/

2. 2.

   Profile
 • 河合 俊典 - ばんくし @vaaaaanquish • エムスリー株式会社　AI・機械学習チーム •

   調べてないけど多分この会場で一番フォロワーが多い
3. 3.

   Agenda
 • gokartとは • gokartを用いた実際の機械学習モデル開発工程 • エムスリーでの運用と実課題

4. 4.

   gokartとは


5. 5.

   gokart
 • エムスリーが作成している luigi wrapper ◦ 簡易でテストの行い易い class設計 ◦ パラメータhashによるデータ管理

   ◦ 自動ログによる再現性 ◦ InstanceをPrameterとして扱えるようサポート ◦ 外部ライブラリ ▪ cookiecutter-gokart : gokartプロジェクトテンプレート ▪ redshells : 機械学習モデル task群 ▪ thunderbolt : データ管理 ▪ luigi_completion : CLI補完ツール • 現状どの機械学習ワークフローライブラリより扱い易く 機械学習プロジェクトの事を考えて作られたライブラリ（だと思っている）
6. 6.

   本当にベストか調べた

7. 7.

   本当にベストか調べた • 技術書展8 ◦ Day2 お-46 ◦ エムスリーテックブック 2 ◦

   『機械学習ワークフローライブラリ選定と運用事例』 ◦ ワークフロー比較と選定のコツとか 20ページ書きました
8. 8.

   エムスリーテックブック２より 一部かいつまんで紹介します！

9. 9.

   機械学習ワークフローの分類 • 主目的で概ね以下のどこかに分類される ◦ 機械学習モデリング ◦ モデルバージョニング ◦ クラウド、データストレージ管理、規格化 ◦

   特徴量生成自動化、学習自動化 ◦ パラメータ最適化 ◦ 機械学習モデル本番運用 ◦ 分散処理、インフラオーケストレーション ◦ クラウドサービス、Function as a Service ◦ データサイエンス、ETLプラットフォーム • luigi, gokart, metaflow, kedro, mlflow, sklearn pipline ...等
10. 10.

    機械学習ワークフローがサポートすべき要素 • 機械学習モデルとは外的要因に強く影響を受けるアルゴリズムである • ソフトウェアパターン、デザインパターンの課題を除いて 機械学習ワークフローがサポートすべき機械学習のための要素 ◦ データ、特徴量加工の冪等性、再現性 ◦ MLモデル間の依存性

    ◦ MLモデルのスケーラビリティ ◦ MLモデルの保守性 ◦ MLモデルの説明可能性
11. 11.

    gokartがサポートしている所 • データ、特徴量加工の冪等性、再現性 ◦ 全てのタスクをパラメータから生成した hash値を付けて保存 ◦ ログにも情報保存して実行を再現可能に ◦ pandasのcolumn型チェック、入出力フォーマットの制約などの機能

    • MLモデルの保守性 ◦ cookiecutterによるプロジェクト構成共通化 ◦ 拡張パラメータによる管理と実験結果の保持 ◦ Thunderboltによるデータ管理 ◦ Redshellsによる学習アルゴリズムの共通化 ◦ Gitリポジトリとデータを自動保存している作業ディレクトリ ($TASK_WORKSPACE_DIRECTORY) を共有すれば他メンバーがすぐ再現できる高い保守性
12. 12.

    gokartがサポートしていない所 • MLモデル間の依存性 ◦ Feature Store管理ツールのような、ある MLモデルが生成した特徴量の管理等は強く行っていない ◦ 複数プロジェクトで複数 $TASK_WORKSPACE_DIRECTORYが更新されるような状態は考慮していない

    ◦ 1プロジェクト1モジュール • MLモデルのスケーラビリティ ◦ 本番環境でpredictの度にオンライン学習といった状態には不向き ◦ batchでもhadoop, spark等の分散学習サポートは強くない ▪ luigiが一部サポートはしている • MLモデルの説明可能性 ◦ DAG可視化ツールは luigiのものは使える ◦ 特徴量の可視化や EDAは別途必要
13. 13.

    外部評価 • 先日公開されたPipeline比較記事 でも良い評価 • nishikaコンペで入賞（審査中） ◦ 自然言語処理とMLのコンペ ◦ コードも公開予定

    • (GitHub Star数が少ない…) PythonのPipelineパッケージ比較：Airflow, Luigi, Gokart, Metaflow, Kedro, PipelineX
 @Minyus86 2020/2/4 - https://qiita.com/Minyus86/items/70622a1502b92ac6b29c より引用

14. 14.

    gokartを用いた 機械学習モデル開発工程

15. 15.

    cookiecutter-gokartでのproject生成 対話形式による設定 実行可能なディレクトリができる # task run $ python main.py sample.Sample

    --local-scheduler # unittest run $ python -m unittest discover -s ./test/unit_test/
16. 16.

    cookiecutter-gokartでのproject生成 ・“sample output” 文字列を保存するtask ・データやログの自動保存先は./resource 　＞ S3やGCSを設定可能 　＞ $TASK_WORKSPACE_DIRECTORY でも可

    ・loggingの設定は./conf/logging.iniを使う
17. 17.

    gokartでTaskを書く sampleパラメータを dictに含んだものを保存する TaskA あるtaskの結果dictを元に 値を更新し結果を保存する TaskB TaskBのパラメータとしてTaskAを設定 TaskAのパラメータとして”hoge”を設定 TaskBの結果を読み込み更新して保存する

    TaskC
18. 18.

    gokartタスクを走らせる • python hoge.py [task_namespace].[ClassName] --local-scheduler ◦ luigi_completionを使うと補完してくれるので便利 • モジュールバージョン、実行時間、ログ、パラメータ

    TaskA、TaskB、TaskCの結果がパラメータに応じた ハッシュ値付きで ./resource 配下に全て保存されている • パラメータ変えれば勝手に保存してくれるので 手を加えてunittest書いて実行を繰り返すだけ！ DDD！
19. 19.

    thunderboltによる結果確認 pandas.DataFrameでデータを一覧管理 Thunderbolt.get_data(“Task”) 最新の ”Task” の結果を取得 Thunderbolt.load( task_id ) tbが設定するidに応じたTask結果をロード

20. 20.

    luigiとの比較 task instanceは渡せないので runの中でyieldして動的にTaskBを生成 する必要がある input, outputメソッドを書き連ねる形で ファイルI/O部分を記述する必要がある outputを設定 パラメータを自ら管理する記述が必要

21. 21.

    redshellsに流す OptunaによるLightGBM最適化 Optunaで最適化したパラメータを利 用してLightGBM学習

22. 22.

    redshellsがサポートしているモデル • XGBoost • LightGBM (#PR 49) • CatBoost (#PR

    49) • Factorization Machine • Graph Convolutional Neural Network • pairwise similarity • GCMC • LDA • SCDV • TF-IDF • doc2vec • fasttext • word2vec たくさん
23. 23.

    gokartを用いた プロダクション運用と課題

24. 24.

    エムスリーにおけるgokart開発 • 基本的には1人1プロジェクト ◦ gokartでMLモデルと結果を生成する Batchを書く ◦ AWS ECS Batch

    / GCE / GKE ◦ BigQuery / GCS / S3 • cookiecutter-m3gokart, 共通タスクライブラリ を別途独自に作成 ◦ 各プロジェクトのディレクトリ構成が同じ ◦ GCPやAWS周りの社内向けタスク、 SQLなど共通化
25. 25.

    エムスリーにおけるgokart運用 cookiecutter プロジェクト作成 gokart, redshells モデル作成 Thunderbolt モデル検証 Daily Batch化

    Storage :共通化
26. 26.

    エムスリーにおけるgokart開発の前提 • Dailyでの学習・推論Batchがメイン ◦ オンライン学習、分散処理、画像認識などの大規模 Taskはない ◦ 利用クラウドサービスも増えているが現状多くはない ▪ 今後Elasticsearch等をサポートしていく事になるとは思われるが

    ◦ ターゲットユーザが医療業界に絞られている ▪ サービス要件が急激に増減しない ▪ ドメイン、データ分布が急変しない • 全員がgokartを利用し、周辺のツールをメンテしていく ◦ プロジェクト、class設計、unittestが統一的に ◦ 機械学習モデルのオフライン評価、 KPIのためのデータ出力まで gokartで通す ▪ メンテナンス、reviewがかなり楽
27. 27.

    gokartにおける課題 • タスクごとにリソースがスケールしない ◦ gokartのタスク粒度の設計が難しい ◦ 例： ▪ あるTaskA：メモリは1GBしか使わないが長時間かかる前処理タスク ▪

    あるTaskB：メモリを10GB使うモデル学習タスク ▪ gokartのrequiresで接続するとTaskAとTaskBが同じDaily Batchに含まれる • Airflowなどで適切なクラウドサービスを使えれば良いが … • 可視化が個人に委ねられている ◦ 他ワークフローライブラリのようなタスク入出力、統計量の可視化はサポートしていない ◦ あくまでThunderboltのようなツールでのコード管理を徹底 ◦ タスク結合の結果壊れている事に気付きにくい ▪ 一応pandasのcolumn型チェックが最近入りました
28. 28.

    • 中間ファイル、キャッシュの取り扱いが難しい ◦ batchのrerun ≠ gokart task rerun ◦ 例：日割りのデータ

    ▪ 前日分のデータは前日の batchがgokartで生成したファイルで良い • パラメータが同じであれば結果は冪等 ▪ 前日分がバグで空のデータになっている • hash値付データの存在で task.completeと認識されgokart的には動作 • 気付きにくい ◦ 例：他PJで生成されたデータやコード変更の反映 ▪ キャッシュのhash値が変化しない ▪ モデリングした人とデプロイした人の認識があってないと事故 ◦ モデリング時嬉しくても本番で「キャッシュ」のように扱い始めたら注意！ ▪ rerunの確認 ▪ versionなどのParameterの設定 gokartにおける課題 2019/2/1 2019/2/2 2019/2/3 データ破損, rerun必要 ファイル自体は存在し gokartは動作
29. 29.

    おわりに

30. 30.

    まとめ • gokartは機械学習プロジェクトの勘所を抑えたワークフローライブラリ • エムスリーでは小規模ながら統一的で再現性、冪等性の担保された開発が行えている • gokartにもスケール性やオンライン化が難しいなどの課題がある

31. 31.

    買ってね！ • 技術書展8 ◦ Day2 お-46 ◦ エムスリーテックブック 2 ◦

    『機械学習ワークフローライブラリ選定と運用事例』 ◦ ワークフロー比較と選定のコツとか 20ページ書きました