第12回全日本コンピュータビジョン勉強会 Machine Learning Operations (MLOps): Overview, Definition, and Architecture 2024/03/03 皆川卓也(takmin)

自己紹介 2 株式会社ビジョン＆ITラボ 代表取締役 皆川 卓也（みながわ たくや） 博士（工学） 「コンピュータビジョン勉強会＠関東」主催 株式会社フューチャースタンダード 技術顧問 略歴： 1999-2003年 日本HP（後にアジレント・テクノロジーへ分社）にて、ITエンジニアとしてシステム構築、プリ セールス、プロジェクトマネジメント、サポート等の業務に従事 2004-2009年 コンピュータビジョンを用いたシステム/アプリ/サービス開発等に従事 2007-2010年 慶應義塾大学大学院 後期博士課程にて、コンピュータビジョンを専攻 単位取得退学後、博士号取得（2014年） 2009年-現在 フリーランスとして、コンピュータビジョンのコンサル/研究/開発等に従事（2018年法人化） http://visitlab.jp

今回読む論文 10  Machine Learning Operations (MLOps): Overview, Definition, and Architecture  D. Kreuzberger, N. Kühl, and S. Hirschl (KIT Germany)  May 2022, doi: 10.48550/arxiv.2205.02302.  以下の手法でMLOpsの概要、定義、アーキテクチャーを まとめたもの。  文献のサーベイ  ツールの調査  インタビュー  入門として適している？と思われる。  「データセット関連読み会」ですが、データの管理の概念 も含むので。。。

弊社の主な事業内容 1. Ｒ＆Ｄコンサルティング 2. 受託研究/開発 3. 開発マネジメント 4. 開発コンサルティング 5. ビジネス化コンサルティング 11

開発マネジメント  コンピュータビジョンやITシステム開発のためのマネジメ ントを代行致します  各種ITシステム構築や，海外のCV技術の実用化などの 実績があります ユーザ Vision & IT Lab 技術者 技術者 技術者 ・・・ 要件定義 基本設計 進捗管理 リスク管理 etc 12

発表のモチベーション 13  MLOpsについて読み物はいくつか読んだことはあるけど、 ちゃんと理解しているわけではない。  そもそも一人会社なのでチームで仕事をする機会が少ない  プロジェクトマネージャーとして技術者や研究者とビジネ スとの間を取り持つことがあり、その中で機械学習モデ ルの管理環境(mlflow)を構築する機会があった  今後も同じような仕事が来た時のために、包括的な知識を身 に着けておきたい  自社サービスを今後育てていくためにも、プロセスを理 解しておきたい。  PRMU/IBISML/CVIM研究会に参加されている機械学習 系の研究者の方にも役に立つ知見があるのでは？

機械学習システムにおける隠れた技術的負債 14  実世界の機械学習システムでは、機械学習のコード部 分は全体のごく一部 Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J. F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. Advances in Neural Information Processing Systems, 2015-January, 2503–2511.

MLOpsとは？ 15  機械学習エンジニアは機械学習（ML）モデルの作成に 集中しがち  製品レベルのものを提供するためには複雑なシステム 構成やインフラとの連携、またその自動化が必要となる。  手作業のMLプロセスを自動化、運用化するためのエン ジニアリングプラクティスがMachine Learning Operations (MLOps)  これまでの研究では、MLOpsをそれぞれ異なる視点から 語られており、総括的な議論が欠けていた。  この論文では「MLOpsとは何か」の明確なガイドラインを 作成する

DevOpsとは？ 16  「開発（Development）」＋「運用（Operations）」=DevOps  Webサービスを提供する際、従来は開発するチームと運 用チームに分かれていた。  例：開発「新機能を導入したい！」 vs 運用「セキュリティと安定 性が下がるからダメ！」  開発と運用を同じライフサイクルの中に組み込んで継続 的に回していくこと。  「開発」→「統合」→「テスト」→「実装」→「監視」の各ステップ を自動化し、連携やフィードバックを簡単にする

調査方法の概要 17  文献調査（Literature Review）、ツール調査(Tool Review)、 インタビューを元に、MLOpsの原則(Princeiples)、構成要 素(Components)、役割(Roles)、アーキテクチャを定義

文献調査 18  “DevOps”、”CICD”、”Continuous Integration”、”Continuous Delivery”という用語をクエリー として、Google Scholar, Web of Science, Science Direct, Scopus, Association for Information Systems eLibraryか ら文献を検索。  取得した1,864件の文献を194件までスクリーニングし、 最終的に27件を選択

ツール調査（オープンソース） 19

ツール調査（市販サービス） 20

インタビュー 21

Principles 22 MLOpsを実現するための９つの原則

Principles 23 MLOpsを実現するための９つの原則 1. CI/CD automation  継続的インテグレーション（CI）  コードのコミット→ビルド→テストを自動化  継続的デリバリー（CD）  CIを拡張した概念  コードのコミットから、ステージング環境へのリリースまでを自動化  本番環境へのリリースも承認一つで

Principles 24 MLOpsを実現するための９つの原則 2. Workflow orchestration  有向非巡回グラフで定義された順番に、タスクを自動で実行 する仕組みを用意する  依存関係等を考慮して作成する  ex. データの前処理→特徴量エンジニアリング→モデルのト レーニングと評価→ハイパーパラメータチューニング 3. Reproducibility  機械学習実験の再現性を確保する

Principles 25 MLOpsを実現するための９つの原則 4. Versioning  学習データ、モデル、コードに対して、バージョン番号の付与 と管理を行う。 5. Collaboration  部署や役割間での協調作業  そのために、データ、モデル、コードに対してアクセス/作業で きる仕組みが必須

Principles 26 MLOpsを実現するための９つの原則 6. Continuous ML training & evaluation  新しい特徴量データに基づいて、定期的にモデルの再学習お よび自動評価を行う。  ワークフローの自動実行や監視、フィードバックの仕組みなど を利用する。 7. ML metadata tracking/logging  機械学習のワークフローごとに、学習日時、期間、モデル固 有のメタデータと性能のメトリクス、データとコードのバージョ ン、などを追跡、記録する。  実験結果とそれに関わる条件が追跡可能となる。

Principles 27 MLOpsを実現するための９つの原則 8. Continuous monitoring  エラーや製品品質に影響するデータ、モデル、コード、インフ ラリソース、性能（予測精度等）を定期的に評価する。 9. Feedback loops  品質評価から得られた知見を、開発プロセスに反映する。  モデルの性能評価等を行う監視コンポーネントから、再学習 を行うためのスケジューラーへのフィードバック。

Principles 28  各原理の関係（私の理解） CI/CD automation Workflow orchestration Reproducibility Versioning Collaboration Continuous ML training & evaluation ML metadata tracking/logging Continuous monitoring Feedback loops

Technical Components 29  MLシステムを構成する９つのコンポーネントとPrinciplesとの 関係  Principlesを目標としたら、Compoentsは手段

Technical Components 30  CI/CD Component • 継続的インテグレーションおよび 継続的デリバリーを実現するため のビルド、テスト、デリバリー、デプ ロイ、およびフィードバックを実現 する機構 • サービス/ツールの例： • Jenkins • Github actions

Technical Components 31  Source-Code Repository • コードの保管とバージョン管理 • 複数の開発者のコードを統合する 仕組み • サービス/ツールの例： • Bitbuckets • GitLab • Github • Gitea

Technical Components 32  Workflow Orchestration Component • 有向非巡回グラフ（DAG）でタスクの実行順序や アーティファクト（モデル、データセット、評価メトリ クス等）の利用を定義する。 • サービス/ツールの例： • Apache Airflow • Kubeflow Pipelines • Luigi • AWS SageMaker Pipelines • Azure Pipelines

例：Kubeflow Pipelines 33

Technical Components 34  Feature Stores • 特徴量のデータベー ス • 実験等に用いるオフ ラインDBと、 Predictionに用いるた めの低遅延なオンラ インDB • サービス/ツールの 例： • Google Feast • Amazon AWS Feature Store • Tecton.ai • Hopswork.ai

Technical Components 35  Model Training Infrastructure • CPU、GPU、RAMな ど学習のための計算 リソース • スケーラブルな分散 アーキテクチャが望 ましい。 • サービス/ツールの 例： • Kubernetes • RedHat OpenShift

Technical Components 36  Model Registry • 学習済みモデルを付随するメタデータと 共にの保管 • サービス/ツールの例： • MLflow • AWS SageMaker Model Registry • Microsoft Azure ML Registry • Neptune.ai

Technical Components 37  ML Metadata Stores • ワークフロー上の各タスクのメタデータの 履歴を管理 • サービス/ツールの例： • Kubeflow Pipelines • AWS SageMaker Pipelines • Azure ML • IBM Watson Studio

Technical Components 38  Model Serving Component • REST APIなどを通してリアルタイム推論やバッチ推 論の機能を提供 • サービス/ツールの例： • KServe • TensorFlow Serving • Microsoft Azure ML REST API • AWS SageMaker Endpoints • Google Vertex AI prediction service • etc

Technical Components 39  Monitoring Component • Model Servingの性能計測 • インフラやCI/CD、オーケストレーションの監視 • サービス/ツールの例： • Prometheus with Grafana • ELK stack • TensorBoard • KubeflowやML Flow、SageMaker等の組み込 み機能

Roles 40  Business Stakeholder  機械学習によって達成したいビジネスの目標を設定  投資対効果のプレゼン等ビジネス側とのコミュニケーション  Solution Architect  どのような技術を採用して、どのようなシステムを構築するか の設計  Data Scientist  ビジネスの問題を機械学習の問題へ落とし込む  アルゴリズムおよびハイパーパラメータの選定も含む機械学 習モデルの開発

Roles 41  Data Engineer  データの管理および特徴量エンジニアリングのパイプライン構築  適切なデータがFeature Store Systemに取り込まれることを保証  Software Engineer  機械学習の問題をデザインパターンやコーディング規約等に基づき 実装  DevOps Engineer  開発と運用の橋渡し役として、CI/CD automation、Workflow orchestration、本番環境へのモデルデプロイ、監視等に責任を持つ

Roles 42  ML Engineer/MLOps Engineer  ML インフラの構築と運用、パイプラインと本番環境へのモデルデプ ロイの管理、モデルと インフラの監視。  Data Scientistや Backend Engineer、DevOps Engineerなど、様々な 分野のスキルが必要 MLOpsにおける役割と相互の関係

Architecture and Workflow 43 MLOpsの主要ワークフロー （関わる役割） A) プロジェクトの立ち上げ  Business Stakeholder, Solution Architect, Data Scientist, Data Engineer B) 特徴量エンジニアリングパイプライン  Data Scientist, Data Engineer C) 実験  Data Scientist, Data Engineer, Software Engineer, DevOps Engineer, ML Engineer D) 自動化されたパイプラインによるモデル提供  Software Engineer, DevOps Engineer, ML Engineer

44

45 プロジェクトの立ち上げ • ビジネス上の課題を基に、ビジネス上の目標設定、 アーキテクチャ設計と技術選定、機械学習で解く 問題の定義、必要なデータの理解と準備までを行 う。

46 特徴量エンジニアリングパイプライン • 生データに対して、データの変換ルール（正規化、 クリーニング等）を定義 • 定義に沿ってデータをパイプライン処理し、 Feature Store Systemに格納 • 変換ルールは実験結果等のフィードバックを受け て、繰り返し調整される

47 実験 • Data Scientistによるデータの確認と、変更が必要な場 合は報告 • パラメータを変えながら繰り返しトレーニングと評価 • 良い評価結果が出たらモデルとコードをRegistryに commit • CI/CDが自動で走り、ビルド、テスト、デリバリーされる

48 自動機械学習ワークフローパイプライン • モデルの精度維持/向上ために、自動でバージョ ン付けされた新しいデータで再学習し、良い評価 結果が出たら終了してモデルやコードをコミット • ステージングから本番環境へ切り替えたら、自動 でモデルとコードがpullされ、ビルド、テスト、デリ バリーされる

概念化 49  文献調査、ツール調査、インタビューを通して、MLOpsを 以下のように概念化

概念化 50  文献調査、ツール調査、インタビューを通して、MLOpsを 以下のように概念化 MLOps（Machine Learning Operations）とは、機械学習製品のエンドツーエンドの 概念化、実装、モニタリング、デプロイメント、スケーラビリティに関して、ベストプラ クティスや一連の概念、開発文化などの側面を含むパラダイムである。最も重要 なことは、機械学習、ソフトウェアエンジニアリング（特にDevOps）、データエンジ ニアリングという3つの貢献する分野を活用するエンジニアリングプラクティスであ るということだ。MLOpsは、開発（Dev）と運用（Ops）のギャップを埋めることで、機 械学習システムのプロダクション化を目指している。基本的に、MLOpsは以下の 原則を活用することで、機械学習製品の作成を促進することを目指している： CI/CDの自動化、ワークフローのオーケストレーション、再現性、データ、モデル、 コードのバージョニング、コラボレーション、継続的なMLのトレーニングと評価、ML のメタデータのトラッキングとロギング、継続的なモニタリング、フィードバックルー プ。

MLOpsを採用するにあたっての課題 51  組織的課題  モデル主導の機械学習から、製品指向へ組織文化を変える  機械学習システムの課題  特に学習時のCPU、GPU、RAMなどのインフラリソースの正 確な見積もりが難しいため、柔軟でスケーラブルなシステム が必要  運用上の課題  繰り返される再トレーニングを実現するための高度な自動化  データ、モデル、コードのバージョン管理

結論 52  文献調査、ツール調査、インタビューを通して、 MLOpsの「原理」、「コンポーネント」、「役割」、 「アーキテクチャ」を明らかにし、それを通して 包括的な概念化を行った。  MLOpsという用語とそれに関連する概念の共 通理解が進み、研究者や専門家が将来MLプ ロジェクトを成功させるための一助となること を期待している。