Future Tech Night KaggleライクなCI環境を構築した話 2021.11.26

今⽇お話しすること 実験コードの品質担保のため、Jupyter NotebookについてもCIを導⼊した際の話をします。 背景やCI環境構成の紹介に加え、MLOpsやMLにおけるCIについてもおさらいします。 2

⾃⼰紹介 l 名前 ヤマノ コウタロウ l 所属 Technology Innovation Group でインフラエンジニア → Strategic AI Group でMLOpsなど 3 最近、CourseraのMLOpsコースを修了しました

MLOpsとは l 「データ前処理、モデル開発、デプロイ、運⽤などを含む機械学習のライフサイクルを管理する技術/知 ⾒。」 （MLOpsコミュニティ） https://mlops.connpass.com l 「機械学習またはディープラーニングのライフサイクルを管理するための、データサイエンティスト、エンジニア、 保守運⽤担当者のコラボレーションおよびコミュニケーションに関する実践⼿法」 （Wikipedia） https://ja.wikipedia.org/wiki/MLOps 4

MLOpsパイプラインの全体像 5 データサイエンティスト 分析環境 ソースコード ソースレポジトリ 実⾏環境 データ前処理 学習 評価 モデル保存 監視 データ基盤/ 特徴量ストア データ前処理 推論 データ後処理 推論結果連携 学習パイプライン 推論パイプライン CI/CD ※バッチ推論パターン 実験管理/メタデータ管理 モデルレジストリ

MLOpsパイプラインの全体像 6 データサイエンティスト 分析環境 ソースコード ソースレポジトリ 実⾏環境 データ前処理 学習 評価 モデル保存 監視 データ基盤/ 特徴量ストア データ前処理 推論 データ後処理 推論結果連携 学習パイプライン 推論パイプライン CI/CD ※バッチ推論パターン 実験管理/メタデータ管理 モデルレジストリ 今回お話しするスコープ

当社のMLOps環境 7 データ サイエンティスト 開発コンテナ 実験管理コンテナ ノートブック閲覧 コンテナ ストレージコンテナ 開発コンテナ CIコンテナ ソースレポジトリ 社内環境 GCP VertexAI, BigQuery, etc AWS SageMaker, ECS, etc Azure Azure Databricks, Cognitive Services, etc PJの要件に応じて、実行環境を選択 （PJの要件によっては、分析環境から利用） PJ横断的に利用する、共通の分析環境 オンプレGPUクラスタ

今回のスコープ 8 データ サイエンティスト 開発コンテナ 実験管理コンテナ ノートブック閲覧 コンテナ ストレージコンテナ 開発コンテナ CIコンテナ ソースレポジトリ 社内環境 今回のスコープ オンプレGPUクラスタ GCP VertexAI, BigQuery, etc AWS SageMaker, ECS, etc Azure Azure Databricks, Cognitive Services, etc

サマリ l KaggleライクなCI環境をシンプルに構築してみた。 l 使⽤した主な技術要素は、 GitLab CI/CD, MLflow, MinIO, jnotebook_reader など。 9

背景と⽬的 l 弊チームでは、PoCフェーズであっても、スクリプト・MLパイプライン実⾏のコードはCIの対象とし、ブランチにコミッ トされているコードの動作を担保していた。 l ⼀⽅で、ノートブックはあくまでも実装のちょっとしたお試し⽤であり、成果物としてGitに残すのはスクリプト、とい う⽴て付けにしてCIの対象とはしていなかった。 l が、実態としてはプロジェクトによってはPoCフェーズにてノートブックをよく使っており、動作するか怪しい野良ノー トブックがGitに⼤量におかれて負債化していた。 l → そこで今回、KaggleのCI環境を参考に、ノートブックのためのCI環境を整備した。 10

今回のポイント l コミットされたノートブックは全てCIの対象に。動かないノートブックの存在は許さない。 l 少量のテストデータで実⾏し、動作担保を⽬的とする。（↔⼤量データでの精度担保は必要に応じて追加で 設定する） l 実⾏結果のノートブックはブラウザから確認できるようにする。レビュワーの負担も軽減する。 11

【⼀般論】なぜ（MLシステムでも）CI/CDを導⼊する必要があるのか(1/2) l MLアプリケーションをビルドし、本番環境にデプロイするには、多くのプロセスを経る必要がある。従来のソフトウェ アを導⼊するよりも、さらに難しい。従来のDevOpsは有効だが、加えてデータについて考慮する必要がある。 12 Why We Need DevOps for ML Data から引⽤ https://www.tecton.ai/blog/devops-ml-data/

【⼀般論】なぜ（MLシステムでも）CI/CDを導⼊する必要があるのか(2/2) ビルド→テスト→デプロイといった、モデル・アプリの本番運⽤に必要なプロセスを⾃動化することで、プロダクトアップデートのためのSpeed・ Reliability・Accuracyを向上させる l Speed l ビルド→テスト→デプロイといった様々な作業をクイックに実⾏することができる l 並列実⾏などスケールもしやすくなる。また、再利⽤性も⾼い。特に、モデルの学習には、数時間~数⽇、数週間かかる場合もある l Reliability l ブランチの動作・精度を担保できる l ローカルでは動いていたようだが、綺麗な環境にcloneしてエンドツーエンドで実⾏して⾒ると、動かない or 精度が聞いていたのと異なることがある。 ローカルにのみあるデータに依存していたり、暗黙的にノートブックの実⾏順序が決まっていたり l また、レビュー時に、ソースだけでなく、データとハイパーパラメータ、推論結果についても断⾯を揃え（バージョンコントロール）、再現性を担保した 上で確認する必要がある l Accuracy l ⾃動化をすることで、上記のような反復的な⼀連の作業を、⼈為的なエラーなく正確に実施することができる 13

KaggleのCIの流れ（ユーザ⽬線） 14 l ユーザはコミットするだけで、CIの仕組みを把握せずとも、CIを実⾏して結果を確認することができる ③実行結果の一覧が確認できる ②実行結果が確認できる ①コミットする コミットをトリガーに⾃動で裏で少量のテストデータにて 処理が流れ、その実⾏結果を確認することができる ⼿動でノートブックをコミットする これまでの実⾏結果を⼀覧で確認することができる

今回作ったCIの流れ（ユーザ⽬線） 15 l ユーザはコミットするだけで、CIの仕組みを把握せずとも、CIを実⾏して結果を確認することができる ③実行結果の一覧が確認できる ②実行結果が確認できる ①コミットする コミットをトリガーに⾃動で裏で少量のテストデータにて 処理が流れ、その実⾏結果を確認することができる ⼿動でノートブックをコミットする これまでの実⾏結果を⼀覧で確認することができる $ git add sample_notebook.ipynb $ git commit –m “update notebook refs #3” $ git push ・実⾏時刻 ・実⾏ファイル名 ・コミットID ・コミットコメント ・実⾏結果ファイル格納先パス

【再掲】構成図 16 データ サイエンティスト 開発コンテナ 実験管理コンテナ ノートブック閲覧 コンテナ ストレージコンテナ 開発コンテナ CIコンテナ ソースレポジトリ 社内環境 オンプレGPUクラスタ GCP VertexAI, BigQuery, etc AWS SageMaker, ECS, etc Azure Azure Databricks, Cognitive Services, etc

処理の流れ①: GitLab CI/CDが、pushをトリガーにCIジョブを起動する 17 データ サイエンティスト 開発コンテナ 実験管理コンテナ ノートブック閲覧 コンテナ ストレージコンテナ 開発コンテナ CIコンテナ ソースレポジトリ 社内環境 オンプレGPUクラスタ GCP VertexAI, BigQuery, etc AWS SageMaker, ECS, etc Azure Azure Databricks, Cognitive Services, etc

l Dockerデーモンを使⽤せずにコンテナをbuildするGoogle発のOSS。Dockerデーモンに依存しないことで、root権限なしで buildできるようになる。 l コマンド例: $ /kaniko/executor --insecure --cache=false --dockerfile ./Dockerfile --destination 192.168.XX.XX:30050/dev/test 処理の流れ①: GitLab CI/CDが、pushをトリガーにCIジョブを起動する 18 l GitLab CI/CDが、pushをトリガーにCIジョブを起動する l ← 予めGitLabのプロジェクトに登録しておいたGitLab runner（コンテナ）が処理を開始する l GitLab runner（コンテナ） がKanikoでDockerfileからコンテナをbuildして、コンテナレジストリにpushする l + コンテナをrunし、処理（ノートブックの実⾏など。後述）を実⾏する 概要 ポイント 補⾜ l GitLab runnerにk8sのPodを利⽤するため、コンテナのbuildにはKanikoを利⽤した （コンテナの中でコンテナのbuild）

処理の流れ②: Papermillでノートブックを実⾏し、MINIOにアップロードする 19 データ サイエンティスト 開発コンテナ 実験管理コンテナ ノートブック閲覧 コンテナ ストレージコンテナ 開発コンテナ CIコンテナ ソースレポジトリ 社内環境 オンプレGPUクラスタ GCP VertexAI, BigQuery, etc AWS SageMaker, ECS, etc Azure Azure Databricks, Cognitive Services, etc

l ノートブックをバッチ実⾏することができるツール。 papermill is a tool for parameterizing, executing, and analyzing Jupyter Notebooks. l コマンド例: $ papermill sample01.ipynb s3://bucket001/outputs/sample01.ipynb l ローカルで動くS3互換のストレージ。AWS CLIで操作できる。 処理の流れ②: Papermillでノートブックを実⾏し、MINIOにアップロードする 20 l Papermill（シェルスクリプトでラップ）でノートブックを実⾏し、MINIOにアップロードする l ← コミットされたノートブックを特定し、ノートブックをPapermillで実⾏する l 実⾏済みノートブックは、MINIOにアップロードする 概要 ポイント 補⾜ l 変更があったノートブックは⾃動で漏れなく特定するようにした。（開発者が都度指定する必要がないように） l 実⾏済みノートブックはS3に格納するPJもあるため、今回のオンプレ環境ではS3互換のMINIOを利⽤した。

処理の流れ③: jnotebook_readerで実⾏済みノートブックをブラウザから確認する 21 データ サイエンティスト 開発コンテナ 実験管理コンテナ ノートブック閲覧 コンテナ ストレージコンテナ 開発コンテナ CIコンテナ ソースレポジトリ 社内環境 オンプレGPUクラスタ GCP VertexAI, BigQuery, etc AWS SageMaker, ECS, etc Azure Azure Databricks, Cognitive Services, etc

l Browse and render Jupyter Notebooks from local, Amazon S3, Google Cloud Storage or MinIO 処理の流れ③: jnotebook_readerで実⾏済みノートブックをブラウザから確認する 22 l jnotebook_readerで、MINIO（、S3）に格納した実⾏済みノートブックをブラウザから確認する 概要 ポイント 補⾜ l MINIO（、S3） に配置したノートブックをブラウザから⾒れるようにした。（特にレビュワーのため） l 以前は類似のツールであるcommuterを利⽤していたが、Python/Flaskで書かれていて（私にとって）中⾝が分かりやすい jnotebook-readerを利⽤することにした。

処理の流れ④: MLflowにメタデータを連携し、実験管理をする 23 データ サイエンティスト 開発コンテナ 実験管理コンテナ ノートブック閲覧 コンテナ ストレージコンテナ 開発コンテナ CIコンテナ ソースレポジトリ 社内環境 オンプレGPUクラスタ GCP VertexAI, BigQuery, etc AWS SageMaker, ECS, etc Azure Azure Databricks, Cognitive Services, etc

l MLflow Tracking: 実験管理をすることができるOSS l The MLflow Tracking component is an API and UI for logging parameters, code versions, metrics, and output files when running your machine learning code and for later visualizing the results. 処理の流れ④: MLflowにメタデータを連携し、実験管理をする 24 l CIジョブとして実⾏されるスクリプトの中で、実験管理に必要なメタデータをMLflowに連携し、⼀覧管理できるようにする 概要 ポイント 補⾜ l 実験の再現性担保に必要な情報を⾃動で連携するようにする l 開発者が各⾃ノートブック内に実装することで追加で⾃由に情報を連携できるようにしつつも、必須の項⽬は⾃動で連携するようにする l 実⾏時刻・実⾏ファイル名・コミットID・コミットユーザ・コミットコメント・実⾏結果ファイル格納先パス、等

まとめ 25 l ユーザ⽬線だと、何も新しく覚えること・対応することなく、いつも通りコミットするだけでCIが動くようにした。 l CIを作って何が嬉しいかというと l ブランチにあるノートブックは、新規構築した環境でも動作することが保証される（Notローカルのみ） l コミットする側も楽に確認できて嬉しい。もちろん他の⼈は動作担保されて嬉しい。 l 実⾏結果のノートブックはブラウザから確認できる。レビュワーの負担も軽減される。 l ソースだけのレビューでなくなる。⼿元で動かす必要もなくなる。