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

gokartの運用と課題について

 gokartの運用と課題について

以下の『MLOps勉強会』 の資料です
https://m3-engineer.connpass.com/event/159721/

vaaaaanquish

February 05, 2020
Tweet

More Decks by vaaaaanquish

Other Decks in Technology

Transcript

  1. 【MLOps勉強会】

    gokartを利用した

    ワークフロー運用と課題について


    エムスリー株式会社 AI・機械学習チーム 河合 俊典 (@vaaaaanquish)

    https://m3-engineer.connpass.com/event/159721/

    View full-size slide

  2. Profile

    ● 河合 俊典 - ばんくし @vaaaaanquish
    ● エムスリー株式会社 AI・機械学習チーム
    ● 調べてないけど多分この会場で一番フォロワーが多い

    View full-size slide

  3. Agenda

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

    View full-size slide

  4. gokartとは


    View full-size slide

  5. gokart

    ● エムスリーが作成している
    luigi wrapper
    ○ 簡易でテストの行い易い class設計
    ○ パラメータhashによるデータ管理
    ○ 自動ログによる再現性
    ○ InstanceをPrameterとして扱えるようサポート
    ○ 外部ライブラリ
    ■ cookiecutter-gokart : gokartプロジェクトテンプレート
    ■ redshells : 機械学習モデル task群
    ■ thunderbolt : データ管理
    ■ luigi_completion : CLI補完ツール
    ● 現状どの機械学習ワークフローライブラリより扱い易く
    機械学習プロジェクトの事を考えて作られたライブラリ(だと思っている)

    View full-size slide

  6. 本当にベストか調べた

    View full-size slide

  7. 本当にベストか調べた
    ● 技術書展8
    ○ Day2 お-46
    ○ エムスリーテックブック 2
    ○ 『機械学習ワークフローライブラリ選定と運用事例』
    ○ ワークフロー比較と選定のコツとか 20ページ書きました

    View full-size slide

  8. エムスリーテックブック2より
    一部かいつまんで紹介します!

    View full-size slide

  9. 機械学習ワークフローの分類
    ● 主目的で概ね以下のどこかに分類される
    ○ 機械学習モデリング
    ○ モデルバージョニング
    ○ クラウド、データストレージ管理、規格化
    ○ 特徴量生成自動化、学習自動化
    ○ パラメータ最適化
    ○ 機械学習モデル本番運用
    ○ 分散処理、インフラオーケストレーション
    ○ クラウドサービス、Function as a Service
    ○ データサイエンス、ETLプラットフォーム
    ● luigi, gokart, metaflow, kedro,
    mlflow, sklearn pipline ...等

    View full-size slide

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

    View full-size slide

  11. gokartがサポートしている所
    ● データ、特徴量加工の冪等性、再現性
    ○ 全てのタスクをパラメータから生成した hash値を付けて保存
    ○ ログにも情報保存して実行を再現可能に
    ○ pandasのcolumn型チェック、入出力フォーマットの制約などの機能
    ● MLモデルの保守性
    ○ cookiecutterによるプロジェクト構成共通化
    ○ 拡張パラメータによる管理と実験結果の保持
    ○ Thunderboltによるデータ管理
    ○ Redshellsによる学習アルゴリズムの共通化
    ○ Gitリポジトリとデータを自動保存している作業ディレクトリ ($TASK_WORKSPACE_DIRECTORY)
    を共有すれば他メンバーがすぐ再現できる高い保守性

    View full-size slide

  12. gokartがサポートしていない所
    ● MLモデル間の依存性
    ○ Feature Store管理ツールのような、ある MLモデルが生成した特徴量の管理等は強く行っていない
    ○ 複数プロジェクトで複数 $TASK_WORKSPACE_DIRECTORYが更新されるような状態は考慮していない
    ○ 1プロジェクト1モジュール
    ● MLモデルのスケーラビリティ
    ○ 本番環境でpredictの度にオンライン学習といった状態には不向き
    ○ batchでもhadoop, spark等の分散学習サポートは強くない
    ■ luigiが一部サポートはしている
    ● MLモデルの説明可能性
    ○ DAG可視化ツールは luigiのものは使える
    ○ 特徴量の可視化や EDAは別途必要

    View full-size slide

  13. 外部評価
    ● 先日公開されたPipeline比較記事
    でも良い評価
    ● nishikaコンペで入賞(審査中)
    ○ 自然言語処理とMLのコンペ
    ○ コードも公開予定
    ● (GitHub Star数が少ない…)
    PythonのPipelineパッケージ比較:Airflow, Luigi, Gokart, Metaflow, Kedro, PipelineX

    @Minyus86 2020/2/4 - https://qiita.com/Minyus86/items/70622a1502b92ac6b29c より引用


    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  18. gokartタスクを走らせる
    ● python hoge.py [task_namespace].[ClassName] --local-scheduler
    ○ luigi_completionを使うと補完してくれるので便利
    ● モジュールバージョン、実行時間、ログ、パラメータ
    TaskA、TaskB、TaskCの結果がパラメータに応じた
    ハッシュ値付きで ./resource 配下に全て保存されている
    ● パラメータ変えれば勝手に保存してくれるので
    手を加えてunittest書いて実行を繰り返すだけ!
    DDD!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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
    たくさん

    View full-size slide

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

    View full-size slide

  24. エムスリーにおけるgokart開発
    ● 基本的には1人1プロジェクト
    ○ gokartでMLモデルと結果を生成する Batchを書く
    ○ AWS ECS Batch / GCE / GKE
    ○ BigQuery / GCS / S3
    ● cookiecutter-m3gokart, 共通タスクライブラリ を別途独自に作成
    ○ 各プロジェクトのディレクトリ構成が同じ
    ○ GCPやAWS周りの社内向けタスク、 SQLなど共通化

    View full-size slide

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

    View full-size slide

  26. エムスリーにおけるgokart開発の前提
    ● Dailyでの学習・推論Batchがメイン
    ○ オンライン学習、分散処理、画像認識などの大規模 Taskはない
    ○ 利用クラウドサービスも増えているが現状多くはない
    ■ 今後Elasticsearch等をサポートしていく事になるとは思われるが
    ○ ターゲットユーザが医療業界に絞られている
    ■ サービス要件が急激に増減しない
    ■ ドメイン、データ分布が急変しない
    ● 全員がgokartを利用し、周辺のツールをメンテしていく
    ○ プロジェクト、class設計、unittestが統一的に
    ○ 機械学習モデルのオフライン評価、 KPIのためのデータ出力まで gokartで通す
    ■ メンテナンス、reviewがかなり楽

    View full-size slide

  27. gokartにおける課題
    ● タスクごとにリソースがスケールしない
    ○ gokartのタスク粒度の設計が難しい
    ○ 例:
    ■ あるTaskA:メモリは1GBしか使わないが長時間かかる前処理タスク
    ■ あるTaskB:メモリを10GB使うモデル学習タスク
    ■ gokartのrequiresで接続するとTaskAとTaskBが同じDaily Batchに含まれる
    ● Airflowなどで適切なクラウドサービスを使えれば良いが …
    ● 可視化が個人に委ねられている
    ○ 他ワークフローライブラリのようなタスク入出力、統計量の可視化はサポートしていない
    ○ あくまでThunderboltのようなツールでのコード管理を徹底
    ○ タスク結合の結果壊れている事に気付きにくい
    ■ 一応pandasのcolumn型チェックが最近入りました

    View full-size slide

  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は動作

    View full-size slide

  29. おわりに

    View full-size slide

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

    View full-size slide

  31. 買ってね!
    ● 技術書展8
    ○ Day2 お-46
    ○ エムスリーテックブック 2
    ○ 『機械学習ワークフローライブラリ選定と運用事例』
    ○ ワークフロー比較と選定のコツとか 20ページ書きました

    View full-size slide