最終更新日：
※本稿は、MNTSQ株式会社による寄稿です。
今、機械学習の実用性が注目され、さまざまな分野で機械学習の活用可能性が広がっています。あわせて、ピンポイントではなく、幅広い分野で長期的で安定的に機械学習のモデルを開発・運用できるようにMLOpsへの注目が高まっています。
MLOpsでは、機械学習システムの開発や運用にまつわるさまざまな困難を解消するべく、機械学習システムの運用がしやすい開発基盤づくりが目指されています。一方で、このMLOpsには明確な定義はなく、さまざまな要求に応える技術がMLOpsの名の下に乱立している状況です。
この記事では、MLOpsの導入を検討する際に押さえておきたいポイントを5つに分けて紹介します。
目次
ポイント① MLOpsを理解する｜その1：DevOpsとMLOps
MLOpsは、DevOpsを元にした表現で、MLOpsの多くの技術は、従来型のソフトウェアに対するDevOpsの技術や慣習を、機械学習システムならではの課題に拡張したものであるという見方ができます。
諸説ありますが、DevOpsとは、インフラや開発要件、開発人員といった環境とともに変化する開発ファクターとうまく付き合うために練られた、技術的・組織的プラクティスの集合のことを指す言葉です。
MLOpsの重要性は、複雑になるソフトウェア開発の環境によって、さらに高まっています。
複雑性が増し続けるソフトウェア開発を取り巻く環境の上に、さらに上乗せでデータサイエンスという複雑な要素が積み上がってきたという事情があるためです。
本質的にMLOpsを理解するには、DevOps文脈で発展してきた開発運用技術の専門性と、機械学習システムの開発時の課題を理解する専門性の両方が求められます。
DevOpsにおける中心技術としては、バージョン管理（VCS）、継続的インテグレーション（CI）、継続的デリバリー（CD）、システムの監視が挙げられます。MLOpsの文脈では、DevOpsの開発パイプラインに対して以下のような機能を拡張したパイプライン（MLパイプライン）が提供・開発されることが多いです:
- モデルバージョン管理（VCSの拡張）
- データバリデーション・モデル性能テスト（CIの拡張）
- モデルサービングや段階的デプロイ基盤（CDの拡張）
- モデルの継続的再訓練（CTと呼ばれることがある）
- モデルの性能監視
このような要素は、機械学習エンジニアが実験で機械学習モデルを開発し、本番システムにデプロイし、本番環境・本番データで正しく動いてるかを確認・必要に応じて修正するといった一連の作業（モデルライフサイクル）を規格化・自動化するために提供されます。
金融や広告分野といった高頻度更新の分野、また製造業のような物理環境が絡む分野など、機械学習モデルの更新頻度やデータの環境変化が多い業態におけるシステムでは、こういったMLパイプラインを効率化・高信頼化する需要が大きいと言えるでしょう。
単純な機械学習システムの開発運用のコストを減らす側面でもMLOpsは重要ですが、アプリケーションエンジニアやインフラエンジニアの専門性がDevOps文脈である程度繋がれたように、ソフトウェアエンジニアと機械学習エンジニアの専門性を橋渡しするという側面の重要性もあります。たとえば、モデルの動作検証が自動化された場合、運用プロセスでこの作業を巻き取ることが可能になるなどの恩恵があります。
また機械学習が絡む製品では、エンジニアだけでなくビジネス側の分析者や事業ドメインの専門家がデータやシステムにアクセスできることが重要です。この側面はDevOpsの文脈よりも、後述するデータエンジニアリングの側面でよりサポートされます。
DevOpsの歴史は15年近くあり、普及が進むにつれて開発や組織に与えるインパクトと課題が浮き彫りになってきています。経営者と開発者のそれぞれにとってのDevOpsの捉えられ方の違いもまた浮かび上がってきています。これらのインパクトや課題は、MLOpsの導入検討や運用を進める際にもおそらく同様に直面するることが予想される項目が多いです。DevOpsはMLOpsを知るにあたってまずあたるべきテーマであると言えるでしょう。
ポイント② MLOpsを理解する｜その2：機械学習実験とMLOps
DevOps的な側面では本番環境と開発作業を橋渡しするフローの効率化に関心が集まっていました。一方で、機械学習開発で必須になる作業である実験開発のプロセスにおいても、効率化やスケール化の需要が発生します。
その需要の一例として、機械学習の開発では実サービス上の予測時よりも、機械学習モデルの学習時の方が遥かに多くのリソースを必要とするという事情があります。ディープラーニングを用いたモデルではGPUリソースがほぼ必須ですし、場合によっては分散学習を必要とする規模のケースもあります。このリソース需要は、1実験が必要とする計算リソース量（≒データ量やモデルサイズなど）と、探索したい実験設定パターンの量との掛け算で決まります。実験開発目標の難易度によっては、これらのリソース需要が満たされないと達成されないということも、しばしばあり得ます。
そのためMLOpsでは、機械学習のモデルの実験作業を効率化したり、実験のスケール化を可能にする基盤を用意したりする技術が扱われることがあります。DevOpsの項で説明した「モデルの継続的再訓練」などで使われる技術は一部被りますが、この項の話題では多くの計算能力を使いたい、多くの設定を調べたい、実験結果を管理して建設的な考察を効率的に進めたい、といった動機が中心にあります。こういった需要は、機械学習モデルの開発チームや機械学習の研究者など、チームで大規模な実験を大量に・高速に回す必要がある人たちを中心に関心を集めています。
代表的な技術要素を以下に挙げてみます。
- 必要なマシンリソースの自動確保・分散学習（実験インフラ）
- 実験管理（実験設定と使用したデータなどを管理する仕組み）
- 実験ワークフローの管理（データ処理や実験実行自体の自動化）
- ハイパーパラメータ調整（実験設定探索の自動化）
- AutoML（機械学習モデルを選別する作業の自動化）
- 特徴量サービング（開発された特徴量の管理・共有）
- モデル説明・可視化（実験結果の確認の効率化）
AutoMLのような機械学習のモデル構築を自動化する技術を見ると、将来、機械学習技術者はいらなくなるのではないかと思われます。既に解けることがわかっているタスクとデータへの適用はもちろんのこと、未知のデータやタスクでも最初に感触を得るためとりあえず機械学習を試す用途にも便利な技術です。
将来の機械学習エンジニアの仕事は、問題の規格化といった仕様策定、システム化によるコスト削減、依然難易度の高い作業である機械学習システムのデバッグや、タスクのセミカスタマイズなどに中心が移っていくのかもしれません。現在はまだMLOps技術が探索的な発展を続けている状況下でもあるため、自社の機械学習モデルのライフサイクルのどこに効率化の旨味があるかを見極めることが機械学習エンジニアの重要な役割の一つといえるでしょう。あるいは、後述するデータ周りに起因する課題を解決していくことは依然として重要な仕事として残りそうです。
機械学習技術を導入する旨味は、実験開発という大きなコストを払うことで、多くの判断が自動化されるだけでなく、同等の機能を実現するソフトウェアよりもシステムの複雑性が大きく減じ得る点にもあります。実験と実績により簡単に実現できるとわかった機能はなるべく自動化し、投資に対するスケールメリットを積極的に取りに行くのが得策です。
ポイント③ MLOpsを理解する｜その3：データエンジニアリングとMLOps
機械学習システムにおけるデータは、システムの動力源と例えられるほどに重要です。データを適切に整備できるかどうかは機械学習システムの開発が成立する前提となり、自分たちでデータを作成できるかや、分散した各所のデータを集約できるかといった困難な課題を乗り越える必要があることもあるでしょう。データが確保できた後にも技術的な課題がいくつも発生し、データの複雑性と上手く付き合うという側面もMLOpsの文脈で取り扱われることがあります。
データがここまで重要となる機械学習システムですが、データを中心としたシステム開発・保守に関する話題はまだまだ成熟度が低い印象があります。DevOpsなどの従来のシステム開発においてはコードの開発・保守が関心の中心に、近年のMLOpsにおいては機械学習モデルの開発・保守が関心の中心とされてきました。
データを中心にした品質保証技術が未成熟な要因はいくつかあると考えられます。
- 事業領域の数だけデータの意味が存在して、汎用的な技術課題として焦点が合わせにくかった（データへの知見は各組織に埋まっている）
- コードやモデルに比べて、重要なデータほど公開の難易度が高い
- 人間がラベルを付けたり品質を見たりするデータ管理の産業的重要性は、MLで必須となるまであまり存在しなかった（データは自動的に貯まることがほとんどだった）
- 上記のような事情も相まり、研究労力に対する評価が低く、研究コミュニティの関心が相対的に低かった
上記のような事情で、機械学習システムで重要となるデータ管理はまだまだ未成熟な領域です。一方で、機械学習システムとは別文脈の、検索システム分野、データベース分野、大規模データ処理の分野を中心として、データ処理の高速化・大規模化や一般のデータ管理の課題は昔から存在していました。近年ではこういったデータ基盤課題への知見から生まれた技術群を総称して、データエンジニアリングと呼ばれるようになりました。
アプリケーション向けのデータ管理や、分析向けのデータ管理といった話題は、従来データエンジニアリング文脈で進歩してきました。例えば、従来型の基幹システム向けデータベースではRDBMSが使われ、大規模データ分析用途ではDWHのようなシステムが使われるといった区別です。また、機械学習が普及するにつれてデータ規模が大きくなったりデータ変化が頻繁になるという需要が浸透し、スキーマ構造を緩めたり（データレイク）、分散処理を導入したり（Hadoop/Sparkなどの製品）といった製品が開発されてきました。
ビジネス側の分析者や事業ドメインの専門家がデータにアクセスできることが重要だと以前述べましたが、分析用途に適したデータ管理システムは従来BI製品として提供されてきました。BI的なシステムにデータを流す基盤作りは、通常データエンジニアが担うことになります。
上記のように、データ分析・データ量への対応・高速処理という面ではデータエンジニアリングが既に解決していることが多い現状です。一方でMLOpsでもサポートの薄い分野はまだまだ存在し、データ作成の効率化や、データの多様化への対応、データの意味に関わるデータ品質保証面については、今後の発展が期待される分野と言えそうです。
データエンジニアリング的なMLOpsとしては、以下のような技術的話題があります。
- DWH・データレイクのような分析用途のデータ集約
- ETL・データパイプラインの整備（日々生成されるデータの加工や配線管理）
- データバリデーションとデータクレンジング（データの品質保証）
- データバージョン管理・実験データ管理
- アノテーションの作成・管理・効率化（Human-in-the-loopなデータ基盤）
- モデル性能監視（メトリクスだけでなく、データの追跡も必要）
ポイント④ 既存事例への当てはめ
MLOps技術開発をリードする企業は事業を世界展開しているテックジャイアントがほとんどで、自社の事業スケールや技術的需要にはなかなか合わないことも多いです。しかし、MLOps技術の導入事例や導入企業の幅は増えてきているため、自社の事業に近い導入事例を参考にできるケースも徐々に増えてきています。
自社の事例にうまく当てはまる場合は、クラウドベンダーが提供・管理しているサービスを使うことで開発運用コストを抑えられることがあります。先行事例が充実している点は魅力ですし、採用要件にも繋げやすくなる利点もあります。サービス使用コストと得られる効果が即座に分かるため、機械学習システムで常に課題となる投資対効果が見積もりやすい点も魅力です。よほど価値がスケールする機能と事業仮説がない限り、基盤の自社開発に投じた利益が回収できることはまれだと言えるでしょう。既存事例にまず当てはめて、どこまでクラウドサービスを活用し、どこまで自分たちならではの仕組みを構築するべきかを見定めることは重要です。
既存事例に当てはめやすい観点を紹介します。
- タスクとデータセットが既に知られているものと似ているか
- 教師ラベルが集まりやすい状況で、分類システムを作りたいなど
- 自動学習のシステムを既存のマネージド・サービス組んでしまう
- クラウド環境で利用可能か
- ほとんどのマネージドサービスはクラウド提供
- ベンダーによってはオンプレミス環境でも提供してくれることもある
- 必要としているチーム/側面はどこか
- 開発運用チームの負荷を下げたい→DevOps
- 研究開発チームの生産性が上がらない→ML実験
- データの複雑度が高く管理できない・計算力が足りない→データエンジニアリング
ただし、既存事例に当てはまりにくい領域も存在します。
- データ収集・作成の効率化、データ品質の保守
- 医療データや法律データのようにデータ作成コストが高い分野など
- 小〜中規模の組織だが、データやモデルの複雑度が上っている
- オンプレミス環境上の基盤
- 事例は存在するが、たいてい技術的ハードルや管理コストが大きい
ポイント⑤ MLOps人材の採用と支援
MLOpsを導入・運用するにあたっては、基盤を自社開発するかしないかに関わらず、クラウドやインフラ技術と機械学習技術に詳しい人材の採用が必要です。MLOps分野を牽引しているのはクラウドサービスのベンダーであることがほとんどであるため、MLOpsとクラウド・インフラ技術は多くの場合切り離すことができません。MLOps技術を実装・運用する作業への影響度としては、インフラの設計・運用ができるスキルがより重要だと言えるでしょう。こういった職能は近年ではSREと呼ばれていますが、従来のDevOps的なインフラの管理という範囲を超えて役割が広がりつつある印象があります。
また、従来のDevOpsの枠を出たMLOpsの需要は、サービス運用に関わる機械学習技術の困難に端を発しているため、その投資対効果の評価ができる機械学習の専門家も必要です。モデルやデータを自社開発する需要が小さい場合には、機械学習エンジニアの重要度は相対的に下がることもあるかもしれませんが、その場合は十分な機械学習の知識を持つ別の担当者が導入の判断を担うことになります。
両スキルを兼ね揃える人材は非常に稀なので、SREと機械学習エンジニアの両方を採用・協力できる体制が必要となります。また、DevOpsの導入がそうであったように、MLOpsの導入は開発者全員に影響を与える意思決定であるため、担当者に適切な権限を与えることと組織としての後押しが必要となります。導入成果を説得できないままに、特定チームに任せきりで基盤の整備を進めても、開発者全員の協力が得られることはまずないでしょう。
さいごに
以上、MLOpsとはなにか、その導入で必要となる要素はなにかについて解説を試みました。
MLOpsの目的としては、従来のソフトウェア開発論と同じように、保守性や拡張性の向上による生産性の向上、リリース前品質・リリース後品質の向上、という側面に分解されると言えそうです。しかし、機械学習という新しい技術が絡むことから、扱う対象がコードとシステムに加えて、データ、実験、挙動の不確実性、といった新たな要素を扱うコストが上っています。また、データサイエンスやドメイン知識のような開発に関わる背景スキルセットも多様化することから、組織論的・マネジメント面でのコストも上っています。こういった開発コストの上昇から、MLOpsの注目度は高まっているのでしょう。
本記事がMLOps導入の判断の一助となれば幸いです。
お知らせ
MNTSQではVertical AI領域におけるMLOpsをテーマにイベントを行う予定です！ぜひご登録ください！
