MLOps論文 Machine Learning Operations (MLOps): Overview, Definition, and Architecture の要点まとめ

MLOpsを体系的にまとめた論文「Machine Learning Operations (MLOps): Overview, Definition, and Architecture」を読んだので、要点をまとめました。

元論文：https://arxiv.org/abs/2205.02302

TL;DR

• 「MLOpsって何？」に答えた論文
• MLOpsに関わる文献調査・ツール調査・専門家インタビューを行った
• MLOpsに必要な原理・要素・ロール・アーキテクチャをまとめた
• MLOpsの言葉の意味を定義した
• MLOpsの課題をまとめた

本文要点

0 Abstract

MLOpsは今だに漠然とした言葉であり、研究者と専門家間でMLOpsの定義が曖昧となっている。
本論文では文献調査・ツール調査・専門家へのインタビューを行い、MLOpsを調査した。
調査から以下の結果を体系的にまとめた

• MLOpsに必要な原則
• MLOpsの要素
• MLOpsを行う人のロール
• MLOpsのアーキテクチャを一般化

さらにMLOpsの定義を示し、MLOpsで未解決の問題点を明らかにした。

1 導入

研究面では、MLコミュニティはMLモデルの構築に力を注いでいた。一方、信頼性のあるML製品の構築、実世界でのMLシステムの自動化と運用に必要な、複雑なMLシステムの構成要素とインフラの調整には力を注いでこなかった。
その結果、多くのMLプロジェクトは失敗し、PoCから本番運用へ至ることができていない。

本研究の目的は、より多くのMLプロジェクトをPoCから本番運用できるようにするために、手動MLプロセスを自動化・運用させる方法を検討すること。
本研究では「MLOpsとは何か？」というリサーチクエスチョンに応えるために

• MLOpsの重要な原則
• MLOpsの機能的な中心要素
• MLOpsを成功させるために必要なロール
• MLシステム設計のための一般的アーキテクチ ャ

を明らかにした。

2 DevOpsの基礎

2008~2009 年に登場した「DevOps」の概念は，ソフトウェア開発における問題を削減することを目的としている。

DevOpsは純粋な方法論ではなく，ソフトウェア開発に携わる組織の社会的・技術的課題を解決するパラダイム(物の見方や捉え方)を表す。

DevOpsのツールは6つにグループ分けされる。知識共有、ソースコード管理、ビルドプロセス、CI、CD、モニタリングとロギング。

DevOpsの経験がMLの自動化・運用に活かされている。

3 調査方法

3.1 文献調査

(DevOps or CICD or Continuous Integration or Continuous Delivery or Continuous Deployment) and Machine Learning」・MLOps・CD4MLでクエリした、MLOpsに関する論文の中から、27本の査読付き論文を調査した。

3.2 ツール調査

MLシステムに関わるツール・フレームワーク・クラウドサービスを調査した。

調査対象ツール

Table 1. List of evaluated technologies

3.3 インタビュー調査

異なる組織・業界・国・国籍・性別の8人のMLOpsの専門家をLinkedInから選び、インタビューを行った。

Table 2. List of interview partners

4 結果

4.1 原則

論文中では、MLOpsをどのように実現すべきかの指針(ベストプラクティス)を「原則」としている。

MLOpsを実現するために9個の原則をまとめた

1. CI/CD自動化

   継続的インテグレーショ ン、継続的デリバリー、継続的デプロイメントを実現。

2. ワークフローオーケストレーション

   MLパイプラインのタスクを有向非巡回グラフ(DAGs)に従ってまとめる。

3. 再現性

   ML実験の結果を再現できる状態。

4. バージョン管理

   データ、モデル 、コードのバージョン管理により、再現性だけでなく追跡可能性を実現。

5. チーム協調

   データ、モデル、コードで共同作業ができるようになる状態。異なるロール間でのドメインサイロ化(情報が共有されない状態)を減らすための、協力的でコミュニケーションがとりやすい職場環境を実現。

6. 継続的なMLの学習と評価

   新しい特徴データに基づくMLモデルの定期的な再学習を行う。継続的な学習では、モデル品質の変化の評価を毎回行う。

7. MLメタデータの追跡/ロギング

   MLワークフローのタスクごとに、 メタデータを追跡し、ロギングする。ここでのメタデータは、学習ジョブの学習時刻、期間、モデルのハイパーパラメータ、精度指標、使用したデータとコードを含む。

8. 継続的なモニタリング

   プロダクト品質に影響を与える潜在的なエラーや変更を検出するために、データ、モデル、コード、インフラリソース、 推論パフォーマンスを定期的に評価する。

9. フィードバックループ

   品質評価時の知見を、開発やエンジニアリングプロセスに取り入れるために、複数のフィードバックループが必要。

4.2 技術的要素

MLシステム設計の構成要素をまとめた。

1. CI/CD 要素

   継続的インテグレーション ・継続的デリバリー・継続的デプロイメントを実行。特定ステップの成功・失敗を開発者に素早くフィードバックすることで、全体の生産性を向上できる。

   例：Jenkins・GitHub actions

2. ソースコードレポジトリ

   コードの管理とバージョニングを行う。

   例：Bitbucket・GitLab・GitHub・Gitea

3. ワークフローオーケストレーション要素

   有向非巡回グラフ(DAGs)を用いてMLワークフローのタスクオーケストレーションを提供。例：Apache Airflow・Kubeflow Pipelines・Luigi・AWS SageMaker Pipelines・Azure Pipelines

4. Feature Storeシステム

   共通して使われる特徴量データを一元管理するシステム。実験時に使用する通常レイテンシで特徴量データを提供するOfline Feature Storeと、本番予測に使用する低レイテンシで特徴量データを提供するOnline Feature Storeの2つのデータベースで構成される。

   例：Google Feast・Amazon AWS Feature Store・Tecton.ai・Hopswork.ai

5. モデル学習インフラストラクチャ

   CPU 、RAM、GPUなどの基礎的な計算リソースを提供。一般的には、ス ケーラブルな分散型インフラストラクチャが推奨される。

   例：ローカルマシン・クラウドコンピューティング・計算支援のフレームワーク(Kubernets, Red Hat OpenShift)

6. モデルレジストリ

   学習済みのMLモデルをメタデータと一緒に一元管理する。MLモデルの中間生成物の保存と、メタデータの保存の2つのメイン機能を持つ。

   例：MLflow・AWS SageMaker Model Registry・Microsoft Azure ML Model Registry・Nepture.ai・Microsoft Azure Storage・Google Cloud Storage・Amazon AWS S3

7. MLメタデータストア

   MLワークフローのタスクごとに、実行時のメタデータの追跡を可能にする。

   例：Kubeflow Pipelines・AWS SageMaker Pipelines・Azure ML・IBM Watson Studio・MLflow

8. モデルサービンス要素

   リアルタイムオンライン推論や、バッチ推論などの、様々な目的に応じて構成。スケーラブルな分散型のモデルサービングのインフラストラクチャが推奨される。

   例：KServing of Kubeflow・TensorFlow Serving・Seldion.io serving・Apache Spark for batch predictions・Microsoft Azure ML REST API・AWS SageMaker Endpoints・IBM Watson Studio・Google Vertex AI prediction service

9. モニタリング要素

   モデル性能・インフラストラクチャ・CI/CD・ワークフローオーケストレーションの継続的なモニタリングを提供する。

   例：Prometheus with Grafana・ELK stack (Elasticsearch, Logstash, and Kibana) TensorBoard・Kubeflow・MLflow・AWS SageMaker model monitor・cloud watch

原則と構成要素の関係

Figure 2. Implementation of principles within technical components

4.3 ロール

MLOpsを実現するために必要なロール。

本番環境でのMLシステムをデザイン・管理・自動化・運用するためには異なるロール間での協調が必要。

1. ビジネスステークホルダー

   MLで達成すべきビジネス目標を定め、ビジネスサイドとのコミュニケーション面を担当。

   類似ロール：プロダクトオーナー・プロダクトマネージャー

2. ソリューションアーキテクト

   包括的な検証を行い、アーキテクチャデザインと技術選定を担当。

   類似ロール：ITアーキテクト

3. データサイエンティスト

   ビジネス上の問題をMLの問題に落とし込み、最適なアルゴリズム選定やハイパーパラメーターチューニングといったモデリングを担当。

   類似ロール：MLスペシャリスト・MLディベロッパー

4. データエンジニア

   データ・特徴量エンジニアリングのパイプラインの構築・管理、Feature Storeシステムへの適切なデータ取り込みを担当。

   類似ロール：DevOpsエンジニア

5. ソフトウェアエンジニア

   コーディングガイドラインやベストプラクティスなどのソフトウェアデザインパターンを適用し、生のMLプロダクトを技術的に優れたプロダクトとすることを担当。

6. DevOpsエンジニア

   開発と運用間の差をなくし、適切なCI/CD自動化・MLワークフローオーケストレーション・モデルの本番デプロイ・モニタリングを実現することを担当。

7. MLエンジニア/MLOpsエンジニア

   複数のロールの側面を組み合わせ、ドメイン横断の知識を持つ。データサイエンティスト・データエンジニア・ソフトウェアエンジニア・DevOps・バックエンドエンジニアのスキルが含まれる。MLインフラストラクチャの構築・運用、自動化したMLワークフロー・モデルの本番デプロイの管理、モデルとインフラストラクチャ両方のモニタリングを担当。

Figure 3. Roles and their intersections contributing to the MLOps paradigm

5 アーキテクチャ・ワークフロー

原則、構成要素、ロールに基づいて、MLOpsの一般的なエンドツーエンドのアーキテクチャを導出した。MLOpsプロジェクトの開始からモデル導入までの一連のプロセスを4つの段階に分けた。

• MLOpsプロジェクトの開始
• 特徴量エンジニアリングパイプライン
• 実験
• MLワークフローの自動化

A. MLOpsプロジェクトの開始

1. ビジネスステークホルダーがビジネス分析を行い、MLで解決できる潜在的なビジネス課題を見つける。
2. ソリューションアーキテクトが、MLシステム全体のアーキテクチャデザインを決め、十分評価を行った上で使用技術の選定を行う。
3. データサイエンティストが、ビジネス目標から回帰・分類といったML問題へ落とし込む。
4. データエンジニアとデータサイエンティストが協力して、問題解決に必要なデータは何か理解する。
5. データエンジニアとデータサイエンティストが協力して、最初のデータ分析に必要な生データソースを探しに行き、データの分布や品質を確認し検証する。

B1. 特徴量エンジニアリングパイプラインの要件定義

1. データエンジニアが、データを利用可能な形式にするために、変換ルールや前処理ルールを決定する。
2. データサイエンティストとデータエンジニアが協力して、特徴量エンジニアリングルールを決定する。特徴量エンジニアリングはモデル評価のフィードバックに基づいて反復的に調整される。

B2. 特徴量エンジニアリングパイプライン
データエンジニア・ソフトウェアエンジニアが、要件定義に基づいて特徴量エンジニアリングのパイプラインを構築する。 生データへ接続→データ取得→前処理→特徴量生成→データ取り込み

C. 実験
データサイエンティストが、ソトウェアエンジニアのサポートを受けながらモデリング実験を行う。
データ分析→データ準備→モデル学習→モデル評価→モデル出力

D. MLワークフローの自動化
DevOpsエンジニア・MLエンジニアがワークフローの自動化・運用を行う。
データ取得→データ準備→モデル学習→モデル出力→モデルレジストリに保存→CI/CD(モデルデプロイ)→予測(ソフトウェアエンジニアが設計)→監視→フィードバックループ→継続的モデル学習

Figure 4. End-to-end MLOps architecture and workflow with functional components and roles

6 概念化

筆者らは MLOpsを以下のように定義付けた。

「MLOpsは、機械学習プロダクトのエンドツーエンドの概念化、実装、監視、デプロイ、スケーラビリティに関する、ベストプラクティス・集合概念・開発文化などの側面を含むパラダイムにあたる。とりわけ、機械学習・ソフトウェアエンジニアリング(特にDevOps)・データエンジニアリングの 3つの分野を活用するエンジニアリングプラクティスである。MLOps は、開発と運用間のギャップを埋めることによって、機械学習システムをプロダクト化することを目的としている。本質的にMLOpsは、CI/CD自動化、ワークフローオーケストレーション、再現性、データ・モデル・コードのバージョン管理、チーム協調、継続的なML学習と評価、MLメタデータの追跡・ロギング、継続的な監視、フィードバックループの原則を活用して、機械学習プロダクト開発を促進することを目指す。」

7 課題

• 組織課題

「データサイエンス実践の考え方と文化」は、組織環境における典型的な課題。MLプロダクトの開発・運用を成功させるには、モデル指向からプロダクト指向へ文化を変える必要がある。意思決定レイヤーがMLOpsの成熟度とプロダクト指向の考え方が、明確なビジネス改善をもたらすことを確信してる必要がある。

• システム課題

データ数の変化に応じてリソースを変化できるよう、インフラストラクチャのスケーラビリティに関して高い柔軟性が必要になる。

• 運用課題

MLシステムを構成する要素は複雑に絡み合っているため、手動で運用を行うのは難しい。新しいデータが追加されると再学習が必要になるため、ロバストで高レベルな自動化が必要となる。多くの人・機能で構成されるため、根本的な問題発見などによる潜在的なサポートリクエストの解決が困難。

8 結論

機械学習の研究分野では、モデリングとベンチマークに取り組んできていて、機械学習の運用については触れられてこなかった。

この論文ではMLOpsの原則・要素・ロール・アーキテクチャの4つの側面をまとめ、MLOpsの言葉が意味するところを再認識した。

まとめと所感

DevOpsの技術を土台に、ML固有の問題にも対処してるのがMLOpsのカバー範囲という印象を受けました。MLの導入と運用のためには、MLOpsに関わる人のビジネス理解と、意思決定者がMLOpsの価値を理解してることが必要と指摘してる点は、実プロダクトでMLOpsを実践していくための良い教訓だと思います。

MLOpsへの共通理解として役立つ論文だと思います。