Kedro+MLflow+GithubActionsでデータ分析環境を構築する

はじめに

• Kedro + MLflow + Github Actions でデータ分析環境を構築したので、感想を書いてみました。

背景

=「ローカル環境で、1ファイルに全て突っ込んだノートブックを実験ごとに作っていた（lightgbm_02_YYYYMMDD.ipynbなど）ときの課題」

• 巨大で複雑なノートブックが出来上がってしまう
  • 前処理、モデル学習、モデル評価...
  • 担当分けが難しい（全部一人でやる場合も多いだろうが）
  • メンテが辛い
  • → 処理ごとに分けると、今度は依存関係が良く分からなくなる
• コードのレビューが辛い
  • ノートブックはdiffが取りにくい
  • ノートブックだとコードフォーマッタやチェッカーをかけられなかったり
• 実験管理が辛い
  • 一覧化したくなる（一々ノートブックを開いて思い出すのは辛い）
  • → 一覧を手動でメンテするのはめんどくさい（試行が多くなればなるほど）
• 他人の環境で（まっさらな環境から作り直すと）動かなかったり結果が変わったりする
  • 人から案件を引き継いで、masterをcloneしたら動かなかったり
  • ローカルにあるコミットしていないデータに結果が依存していたり

やったこと

パイプラインツールとしてKedroを導入した

### Kedroとは・導入方法 * （参考）[Kedroで機械学習パイプライン入門](https://qiita.com/noko_qii/items/2395d3a3dbcd9410e5e7)

よかったこと

• 最初にノード（、データのIn/Out）・パイプラインを定義することで、担当分けがしやすい+メンテがしやすかった
  • 処理ごとのIn/Outの認識合わせを最初にさせられるのが良かった
  • 命名規則も最初に決めて周知できた
• ノートブックと連携させやすかった

$ kedro jupyter notebook --allow-root --port=8888 --ip=0.0.0.0 &

from kedro.framework.context import load_context
proj_path = '../../../' 
context = load_context(proj_path)
# df = catalog.load("XXX")
parameters = context.params

• kedor-vizを使えばパイプラインを可視化できた
• credential.yamlでクレデンシャル情報を管理できた

残課題

• いつパイプライン化するか（スクリプト化するか）が悩ましい
  • データサイエンティストがノートブックでどんどん試行錯誤 → データエンジニアが随時パイプライン化、をしていたが、修正回数が多く負担だった
• パイプラインを途中から再実行したい（できそうだが調べられていない）
• kedro-vizが自動で更新されない（再起動すれば読み込む）
• libをどこかに切り出したい（src側だけでなく、notebook側からの読み込みも想定する）
• ジョブの並列実行をしたい
  • パラメータサーチで、optunaと連携したり

実験管理ツールとしてMLflowを導入した

### MLflowとは・導入方法 * （参考）[MLflowで実験管理入門](https://future-architect.github.io/articles/20200626/)

よかったこと

• 上記リンク参照
• せっかくMLflowに飛ばすように書いても、ノートブックごとボツになることがあった
  • → 最初の最初の混沌としているときはスプレッドシート（、excel）で管理して、ある程度固まってきたらMLflowに移行、が良いかもしれない

残課題

• Kedroとの連携
  • Kedroのparameters.yamlやpipeline.pyの情報を自動で連携したい
  • journal versioningを利用とか？

CIツールとしてGithub Actionsを導入した

### Github Actionsとは・導入方法 * （参考）[GitHubの新機能「GitHub Actions」で試すCI/CD](https://knowledge.sakura.ad.jp/23478/)

よかったこと

• master(main)ブランチの動作担保ができた
• （毎回綺麗な環境で、コミットidも明確な断面で動くので）再現性のあるモデル作成ができた

残課題

• 毎回のビルドが重い。キャッシュをうまく利用すれば良い？
• 学習が重い・GPUを使う場合の構成は要検討

その他

• コードフォーマッタとチェッカーを導入した
  • （参考）pre-commit時にformatterを実行する
  • commitするタイミングでチェックが走るので、はじめから導入することが大事
  • コンテナを利用している場合、コンテナの中にGitと共に入れる（Pythonが必要なため）
  • CI側でのチェックとの使い分けを考える
• AWS Elastic BeanstalkでWebアプリ化した
  • サーバーレスが良かったので、S3 + API Gateway + Lambdaで組みたかったが、ファイルサイズ制限で諦めた
    • EFSを使えばいいが、VPC環境にしないといけないとかでちょっと...。
  • 「サーバーレス（というか、リクエストがないときは寝てて欲しいだけ）でコンテナ」なら、GCPでCloud RunとかGAE?

おわりに

• 課題がまだまだ多いですが、データサイエンティストと伴走しながら早く確実に機械学習のサイクルを回すために、引き続き色々試していきたいと思います。
• ちなみに、この記事の内容は、友達と遊びで競馬のレース結果予測のモデルを開発してみたときについでに試して見たものです。コードは、もう少し綺麗にしたらたぶん公開します。（Kedroのデフォルトのディレクトリ構成からちょっと変えていたり。）