はじめに
MLOps 成熟度モデル というものをご存知でしょうか。〇〇成熟度モデルというのは他の概念(例：DevOps)についても定義がされており、人、プロセス、テクノロジを定性的に評価するためのフレームワークになります。
近年 機械学習(ML)による意思決定・アプリケーションの高度化が一般化しており、実運用が進められていますが、MLシステムの運用は DevOps のプラクティスだけでは難しいため、ML特有の課題に対処するための MLOps という概念が生まれました。
MLOps 成熟度モデルとは、組織・チームが人・プロセス・ツールの観点から MLOps に対してどの程度成熟しているかを判断するためのフレームワーク になります。このモデルを元に成熟度を計ることで、立ち位置を把握し MLOps の改善につなげることが可能です。
MLOps 成熟度モデルは、Google Cloud、Azure、AWS の各社で定義しており、各社ごとにそれぞれ特色があります。
本記事ではそれら3大クラウド各社それぞれの MLOps 成熟度モデルの概要について整理をした上で比較をし、簡単な考察をしたいと思います。
Google Cloud の MLOps 成熟度モデル
Google Cloud は MLOps: 機械学習における継続的デリバリーと自動化のパイプライン にて MLOps 成熟度について説明しています。以下で簡単に概要を説明します。
序盤では、MLシステムの複雑さの説明があり、その複雑なシステムを開発・運用するために DevOps の原則を適用すればうまくいきますが、MLシステムは他のソフトウェアとは異なる課題・プロセスがあるため、MLOps の必要性も説いています。
Google Cloud では、MLプロジェクトにおける MLモデルを本番環境にデプロイするステップ (データ抽出、データ分析(EDA)、データの準備、モデルの学習、モデルの評価、モデルの検証、モデルのデプロイ、モデルのモニタリング)の自動化具合を MLプロセス(MLOps)の成熟度と定義しています。
続いて各成熟度レベルの説明についてです。
MLOps レベル 0: 手動プロセス
MLOps レベル０は手動プロセスと呼んでいます。具体的には次のようなステップを手動で行っています。
- データ分析からモデルの検証までのステップを Notebook で実行
- モデル作成をするデータサイエンティストとモデルを API にデプロしするエンジニアといったように分離されている
- 新モデルのバージョンリリースの頻度が少ない
- CI/CD 無し
- デプロイが MLシステム全体のデプロイではなく、予測エンドポイントへの学習済みモデルのデプロイを指す
- デプロイしたモデルのパフォーマンスモニタリング無し
レベル０とはいえ、多くの企業で一般的なレベルであり、モデルの再学習が不要な場合このレベルで十分とも書かれています。しかし、機械学習モデルは本番環境ではドリフト（モデル精度が低下）するため、精度を維持する必要があります。具体的には次の作業になります。
- 本番環境でモデルの品質を積極的にモニタリングすることで再学習のタイミングを検出
- モデルを頻繁に再学習する
- 特徴量の追加や新しい実装を継続的にテストして、モデルを生成する
これらの手動プロセスの課題に対処するには、より上位のレベルで CI / CD と CT 向けの MLOps 手法を導入することが必要です。
MLOps レベル 1: ML パイプラインの自動化
レベル 1 の目標は、ML パイプラインを自動化することにより、モデルの継続的学習を実行することです。具体的には、次で説明しますが Continuous Training(CT)が実現されている状態がレベル１になります。
レベル１からは、新しくFeature Store やメタデータ管理といったコンポーネントが出てきますが、特定のトリガーに応じて学習パイプラインが実行され、モデル予測サービスにデリバリーする流れが自動化されている点です。
レベル１では、パイプライン自体のデプロイが自動化されていないと複数のパイプラインの管理コストや頻繁にデプロイができない点が課題として上がっています。そこでレベル２では、MLパイプライン自体をデプロイするときの CI/CD になります。
MLOps レベル 2: CI / CD パイプラインの自動化
このフェーズでは、MLパイプライン自体の CI/CD により、ソースコードリポジトリへの push をトリガーにパイプラインの各ステージのテストやパッケージ化などが走り、本番環境にデプロイされます。CI / CD を設定すると、新しいパイプラインの実装を自動的にテストしてデプロイ可能になり、データやビジネス環境の急速な変化に対応可能になります。
Google Cloud の MLOps成熟度モデルの特徴
筆者が思った Google Cloud の成熟度モデルの特徴は次の通りです。
- MLOps は DevOps の延長であり、自動化に着目。自動化の対象は、学習パイプライン
- アーキテクチャの話がメインであり、人・文化に対するコメントはあまりない
- レベル０と１の間の差が大きいように見える。一方１と２の差はそこまで大きくない
- すべてのプロセスをあるレベルから別のレベルにすぐに移行する必要ない
- Google Cloud の具体的なサービスは登場しない
Microsoft Azure の MLOps 成熟度モデル
続いて、Microsoft Azure は Machine Learning 用の成熟度モデルにて MLOps 成熟度について説明しています。以下で簡単に概要を説明します。
序盤では、Microsoft Azure における MLOps 成熟度モデルの目的について述べられています。具体的には次の目的のための参考として使用するイメージとのことです。
- 新しい契約の作業範囲を見積もる
- 現実的な成功基準を確立する
- 契約終了時に引き渡す成果物を特定する
また各レベルは、ユーザー、モデルの作成、モデルのリリース、アプリケーションの統合という観点からどういう状態であるかについて箇条書きで記載されています。以降、各成熟度レベルについて簡単に説明します。
Level 0:MLOps なし
Level 0:MLOps なしはユーザ間のコミュニケーションはほぼなく、モデルの作成は手動かつトレーサビリティなし、モデルのリリースにおいても手動、ソースコードのバージョン管理なし、アプリケーションへの統合はに関しても手動といったような状態です。モデルの作成、リリース、アプリケーション周りに関してソフトウェアエンジニアが関わっていないような状態でもあると思われます。
Level 1: DevOps あり、MLOps なし
Level 0 から変わっている点を赤枠で示しました。Level 0 と比較するとソフトウェアエンジニアが関わり、DevOps のフレーバーが乗ってきたような状態ですが、MLOps の要素がありません。
Level 2: 学習の自動化
同様に Level 1 から変わっている点を赤枠で示しました。この時点からデータサイエンティストとデータエンジニア間のコミュニケーションが緊密に連携されます。
また MLOps の要素として、実験管理や学習コード、学習済みモデルのバージョン管理などが進められ、学習自体が自動化された状態です。
Level 3: モデル デプロイの自動化
同様に Level２ から変わっている点を赤枠で示しました。アプリケーションへのモデルの統合部分に関してユニットテストや統合テストも含めた CI/CD が整備され、モデルデプロイの自動化が進んだ状態です。
Level 4: MLOps の再学習の完全自動化
同様に Level３ から変わっている点を赤枠で示しました。データサイエンティストとソフトウェアエンジニアが連携します。またモデルの作成においてメトリックに基づいて再学習を自動トリガーする運用になっています。
Azure の MLOps成熟度モデルの特徴
筆者が思った Azure の成熟度モデルの特徴は次の通りです。
- 自動化の対象は、学習パイプライン
- 自動化のステップ(学習・デプロイ)が細かく分割して定義されている
- 成熟度モデルの利用目的が定義されており、新しい契約の作業範囲を見積もりのためといった受託開発などの想定も含まれていること
- Azure は Google 等と比較すると SI が多いのかもしれない
- 人(データサイエンティスト・データエンジニア・ソフトウェアエンジニア)の連携部分についても細かく述べられており、人材または文化に関しても考慮されたモデルである点
- Feature Store やメタデータ管理といったツールや具体的なサービス(例：Azure ML)などの言及がない
- アーキテクチャ例も書かれていない
AWS の MLOps 成熟度モデル
AWS は Amazon SageMakerを利用したエンタープライズのためのMLOps基盤ロードマップ にて MLOps 成熟度について説明しています。以下で簡単に概要を説明します。
本稿では、MLOps 基盤を構築する重要なフェーズや、MLOps基盤上で複数のペルソナがどのように連携するか、Amazon SageMakerのような専用ツール、エンタープライズビジネス全体でMLの採用を加速させる他の AWS サービスとの統合について学びます。
MLOps 成熟度モデルの図は下記になります。
初期 (Initial) フェーズ
初期フェーズにおけるゴールは、セキュアな実験環境を作ることです。いわゆる PoC を行う ML開発環境を提供できているかになると思います。
反復可能 (Repeatable) フェーズ
初期フェーズが終わり、ML によってビジネス課題を解決できることを証明できた後のフェーズです。AWSアカウントの分離方針(マルチアカウント戦略)や、MLパイプラインへの移行、開発環境（リポジトリのブランチとCI/CD）の標準化などについて述べられています。
信頼性フェーズ
信頼性フェーズは、CI/CD を通してモデルをデプロイする具体的な方針について述べられています。
スケーラブルフェーズ
信頼性フェーズまで終え、MLOps基盤と最初のMLユースケース製品化のための開発を終え、次のユースケースを創出するフェーズです。それぞれのチームごとに、それぞれの環境を提供するためのテンプレートなど組織として、ML基盤をスケールさせる方針について述べられています。
AWS の成熟度モデルの特徴
筆者が思った AWS の MLOps 成熟度モデルの特徴は次の通りです。
- レベルではなく、フェーズという用語を使用している
- 自動化だけでなく、標準化という言葉も多用されている
- (あくまで記事の性質上) 具体的なAWS のサービス(例：SageMaker)を利用してどのように実現していくかなどが重視されて書かれている
- 監査・セキュリティという観点についても書かれている
- 登場するロールが多い
各社成熟度モデルの比較
Google Cloud に関しては学習パイプラインの自動化具合、Azure に関しては各ロールのコミュニケーション具合 + 学習パイプラインの自動化具合、AWS に関しては学習パイプラインの自動化具合 + 組織における MLOps基盤の標準化具合 を MLOps 成熟度と定義していると理解しました。
各社のレベルについては、Google の最大レベルである Level２ と Azure の最大レベルである Level４ が同程度の自動化具合を表しているように見えます。よって Azure の成熟度モデルがより細かく定義されているようです。確かに Google の Level０から１の間のステップの差は非常に大きいので、そこをより細かく分割したイメージと捉えるといいのかもしれません。AWS に関しては成熟度モデルの方向性が他２社と異なるため各レベルの比較は難しい印象です。
また、各記事の対象読者についてですが、Google は内部にデータサイエンティスト・MLエンジニアを抱える事業会社向けという印象を受けました。しかし汎用的な解説になっているため、どのクラウドを使っているかに限らずデータサイエンティスト・MLエンジニアであれば読むべき内容に思えます。
Azure に関しては、成熟度モデルの利用目的の記述から、内部にデータサイエンティスト・MLエンジニアを抱えない事業会社や受託開発会社も想定されているようです。Azure に関してはアーキテクチャ図等が存在しないため、単独で記事を読んでも理解が難しいので、アーキテクチャや Azure 上でどう実装するかについて書かれた MLOps Maturity Model with Azure Machine Learning 等で補完すると良いと思います。
AWS に関してはスケーリングが意識されていること・記事内に登場するロールの細かさ等から、大企業向けという印象です。というかそもそもの各社のメインユーザを想定した記事となっているのかもしれません。
| AWS | Azure | Google Cloud |
|---|---|---|
| 初期フェーズ | Level 0: MLOps なし | Level 0: マニュアルプロセス |
| 反復可能フェーズ | Level 1: DevOps はあるが MLOps なし | Level 1: MLパイプライン自動化 |
| 信頼可能フェーズ | Level 2: 学習自動化 | Level 2: CI/CDパイプライン自動化 |
| スケーラブルフェーズ | Level 3: モデルデプロイ自動化 | |
| Level 4: フルMLOps自動化 |
個人の感想
３社の MLOps 成熟度モデルを読んで比較し学んだことについて雑多ですが次にまとめます。
- MLOps 成熟度モデルはあくまで各社(Big Tech)の定義であり、そのまま鵜呑みにして組織に適用するべきではない（単純にレベルを上げればいいわけではない）こと
- Google のレベル１でも多くのコンポーネントが絡んでくるため、このレベルに持っていくだけでも非常に難易度が高い印象
- まずは完全マニュアルでもいいので ML によるビジネスインパクトを出すことに取り組む。その中で、大きな課題となる部分から MLOps 成熟度モデルを参考に段階的に実装を進めるべき
- 当たり前だが、ML によるビジネスインパクトを出すことが目的なので、MLOps 基盤構築自体を目的としないことが重要
- MLOps は DevOps を前提としているため、当たり前だが DevOps にも成熟していく必要がある
- MLOps に関してはツール面が語られがちだが、各種ロール間のコミュニケーションや組織文化の成熟も必要
- まずは Google の記事を読み、あとは会社やプロジェクトで使用しているクラウドの記事を読むのが良さそう
各社の成熟度レベルについて
MLOps 成熟度モデルを参考にして組織・チームの立ち位置を計測している事例は次の通りです。
-
ヤフーのAIプラットフォーム紹介 〜 AI開発をより手軽に
- Google Cloud の MLOps 成熟度モデルを参考に、2021年8月時点で Yahoo はレベル１から２に近い段階
-
検索アルゴリズム改善における機械学習の活用 〜MLOpsについて〜
- Google Cloud の MLOps 成熟度モデルを参考に、2022年4月時点で ぐるなびはレベル２を達成
-
Productionize ML workloads using Amazon SageMaker MLOps, feat. NatWest
- AWS の MLOps 成熟度モデルを参考に、2022年12月時点で 英 Natwest社は信頼性フェーズを達成