コラム

MRIトレンドレビューデジタルトランスフォーメーション

実用化が始まる文章生成AI 第4回:機械学習プロジェクトを成功に導くMLOpsとは

タグから探す

2020.8.20

金融イノベーション本部手塚 央

はじめに

機械学習のモデル開発においては、モデルパラメータやデータ加工方法などの修正・検証を繰り返し、適切なモデルを構築していく。この工程では、開発者だけでなく、機械学習エンジニア、ユーザーなど複数の関係者が関わる。このため、それぞれにとって利用しやすい環境を提供しなければ、円滑な開発ができない。さらに、CPU、GPU、ストレージなどの計算資源も大量に消費する傾向があるため、そちらにも気を配る必要がある。
これらの課題に手作業による運用で対応することは極めて困難であり、自動化、テンプレート化、モニタリングの可視化など、システム的なアプローチが必要となる。
しかし、そもそも従来型のシステム開発においても、ソフトウエアの複雑さを管理するという課題にうまく対応できないジレンマを感じながら、なんとか取り組んでいるのが実情である。そこに機械学習という新たな要素が加わると、複雑度が増し、管理が破綻することが容易に予測できる。特にPoC※1から開発に進む場合、当初の開発・運用はうまくいっても、その後プロセスがうまく回らず、費用が無駄にかさんでいく、欲しいタイミングでの開発が間に合わない、といった状況もありえる。
幸い、このような状況に対していくつかの解決策が提案されており、そのための技術面およびインフラ面での準備も整ってきている。本稿では、機械学習を導入したシステム開発の課題について、その解決の方向性と具体策について紹介する。

機械学習プロジェクトの難しいところ

機械学習を取り巻く周辺部分が大きい

機械学習プロジェクトは、従来のプロジェクトと比して、①大量の計算リソースを消費する傾向が高い、②シーケンシャルな工程でなく、トライアンドエラーのための繰り返しが多く発生する、③その過程において大量のデータを生成、管理する必要がある。このため、基盤的要素の重要度が高く、その管理が大きな負担となる。
これは、開発者が単なる機械学習モデルの開発だけに専念するあまり、それ以外の部分が十分に対応できていないと安定的、継続的なアウトプットを出すことができないことを意味する。
図1 機械学習を取り巻く周辺部分
図1 機械学習を取り巻く周辺部分
出所:三菱総合研究所
機械学習プロジェクト固有の問題点について述べたものとしては、有名なGoogleの論文 “Hidden Technical Debt in Machine Learning Systems”(2015)※2がある。その中で、機械学習のシステムの構築には、モデル開発以外の部分が大きな比率を占めていることが示されている。つまり、一般的に注目される機械学習モデルも重要なのだが、周辺の技術やシステムのマネジメントもより重要で、その部分を軽視して始めると技術的負債※3となってしまい、その後のコスト、開発期間などに大きな負の影響を与えるという。

関係者が多い

通常のシステム開発の場合、関係者はユーザー、開発者、基盤担当といった構成が多いが、機械学習プロジェクトの場合、これらに加えて、機械学習のアルゴリズムに特化したデータサイエンティストや、データの整合性、妥当性を検証するデータアナリストなどの、新たな異なるバックグラウンドを持った関係者が登場する。
関係者が増えるということは、コミュニケーションコストが増大することを意味する。何も対策をとらなければ関係者間ごとに壁ができてしまい、スムーズな開発プロセスの障害となってしまう。
図2 想定される関係者
図2 想定される関係者
出所:三菱総合研究所

アジャイルさを避けられない

機械学習の開発・運用プロセスでは、最初に設計書を書いて、次に開発に移るといった、いわゆるウォーターフォール※4ではうまくいかない。なぜなら機械学習では実際にデータを選び、学習させ、結果を検証し、要件に見合ったモデルを構築するループや、実際に業務適用して運用状況を監視し、ユーザーからフィードバックを得て改善するループなどが不可欠だからだ。
ウォーターフォール型のシステム開発では、後工程で、前工程に引き戻す修正を行うことは禁じられているが、機械学習ではそのようなループが必要であり、いわゆるアジャイル的※5な開発を避けられない。
このことは、プロセスを管理する業務がより複雑かつ高度になることを意味する。
図3 繰り返し作業
図3 繰り返し作業
出所:三菱総合研究所

データが重要、データ管理も重要

機械学習のプロセスにおいて、データを適切に選択し、そのクオリティーを維持し、管理するという作業は重要であり、アウトプットの出来具合を決める要因の一つといえる。
前項で述べたループ作業の中では、入力データの取得、選択、加工、結果データの検証など、データに関わる作業が多く発生する。これらの作業は、多くの時間を消費するが、自動化できる単純作業がほとんどである。これらを手作業で行うと、ミスやデータ消失などが起こることが多い。

計算リソースの適時・適切な確保を

機械学習におけるモデル構築の工程では、計算リソース(CPU、GPU、メモリ、ストレージなど)を大量に消費する傾向にある。その一方、今まで述べてきたように訓練以外のプロセスも多く存在するため、計算リソースを常に大量消費しているわけではなく、リソースへのニーズは変動が大きい。さらに、ループ作業におけるリソース消費量を先読みすることは難しい。
計算リソース=コストのため、安易にリソースを確保すると、多大なコストが発生してしまう。しかし、適切なリソースを適切なタイミングで確保できないと、いつまでも計算が終わらず、貴重な時間を非効率に過ごしてしまうことになる。

解決の方向性

機械学習プロジェクトでは、従来システムの開発・運用と比べて関係者も周辺システムも増えて、やるべきことも増え、その結果、単純作業が急激に増加し、コントロールできなくなる。この問題を解決するために、どのような方策が考えられるか。

コードだけでなくデータセット、パラメータも構成管理する

機械学習の開発プロセスでは、データセット、パラメータ、コードを変えて大量の訓練を実行する。それらの管理を手作業で行うと、作業ミスなどにより貴重なデータやパラメータを消失し、再現できなくなる事態が生じる可能性がある。このため、追跡可能なデータセット、パラメータ、コードの自動的な構成管理が必要となる。

計算リソースの効率的かつ柔軟な利用を提供する

計算リソースやストレージについては、ニーズの変動に応じて、効率的に割り当てられるような仕組みが必要。クラウド、オンプレ※6に関わらず利用できれば、より好ましい。

複数の関係者、複数の計算リソースからのデータアクセスを可能にする

機械学習モデルには複数の関係者が関わるため、それぞれが必要とするデータへのアクセスにコストがかかる環境では、スムーズな連携は実現できない。複数の関係者がアクセス可能で、十分なサイズと性能がある、データ共有インフラが必要となる。

必要なライブラリ・ツールを、必要な時にすぐ使えるようにする

機械学習は、一番活発なソフトウエアの分野である。機械学習のモデル開発、管理、評価などの有用なライブラリ・ツールが、日々数多くリリースされている。関係者にとって、これらのライブラリ・ツールを利用することの価値は大きい。必要な時に必要なツールを、手間をかけずに容易に利用できる環境が必要だからである。

関係者間のコラボレーションを支援する

複数の領域の異なる関係者が関わる開発では、コミュニケーションの壁をどうやって越えるかが問題であり、コラボレーションをサポートするツールが必要となる。

解決策としてのMLOps

これまで述べてきた機械学習プロジェクトを遂行する上での課題に対する具体的な解決策を紹介する。

DevOps

DevOpsとは、従来は分断されていた開発(Development)と運用(Operation)を一体化して、それぞれ依存関係にある工程をパイプライン化、自動化することで、生産性および品質を向上させるという考え方である。
図4 DevOps
図4 DevOps
出所:三菱総合研究所
開発、運用にまたがる各工程を手作業で行っている場合、コストも時間も増大し、ミス、取りこぼしなどの問題が発生する。結果として品質の悪化、スケジュールの遅延を引き起こす。DevOpsは、そのような問題を解決するコンセプトおよび技術といえる。プロセスの自動化、パイプライン化によって継続的な開発・運用を実現できることが要点で、その実現は人間による手作業では困難であり、ソフトウエア技術を活用した徹底的な自動化を目指すこととなる。

MLOps

DevOpsを機械学習プロジェクトに適応できるよう拡張したのがMLOpsである。まさに今まで話してきたように、従来システムに対してより複雑かつ関わる領域・範囲が広い機械学習プロジェクトで、生産性と品質を両立させながらスピードアップするための解決策となりえる。下図のように開発、運用にモデル開発のプロセスを加えた全体工程を、自動化、パイプライン化することで継続的なプロジェクト遂行を目指す。
図5 DevOpsからMLOpsへ
図5 DevOpsからMLOpsへ
出所:三菱総合研究所
MLOpsによって実現を期待される機能は以下の通り。
  • データ処理・訓練・評価処理の自動化、パイプライン化
  • 上記処理の構成情報(ソース、パラメータ、データセット)の管理
  • 工程間のデータ共有のための分散データストレージ
  • データモデル、評価エンジン等の自動デプロイ
  • 効率的な計算リソースの管理
  • 情報共有のためのコラボレーションツール
図6 MLOpsの構成
図6 MLOpsの構成
出所:三菱総合研究所

AIプラットフォーム

MLOpsを実現し高品質の機械学習プロダクトを継続的に供給するための環境を、機械学習プラットフォームまたはAIプラットフォームと呼ぶ。この分野は今まさに日進月歩で進化しているため、全てに対応した正解はまだ無い状態であるが、例えばAWS、 Google Cloud、Microsoft Azureは、それぞれ独自のAIプラットフォームの提供を始めている。その中で提供されるサービスには以下のようなものがある。
  • 機械学習ライブラリ・ツールなどのパッケージ
  • 分散オブジェクトストレージサービス
  • オンデマンドな計算リソース
  • ビッグデータ処理基盤
  • バッジ処理ワークフロー
  • ソースコード管理
  • 自動デプロイ
  • セキュリティー

最後に

現代の情報システムは、肥大化、複雑化し、コスト増大、技術的な負債といった問題を抱えている。そのままの状態で機械学習を導入すると、今まで述べてきたような、より複雑化した機械学習固有の問題も抱えることになる。十分な準備なしに機械学習の導入に突き進めば、期待した成果を得るどころか、大きなリスクを抱えることになりかねない。
MLOpsの導入により、機械学習プロジェクトに適合した基盤を確保できるため、関係者は本質的な作業に専念でき、プロセスを円滑に回すことができる。これはプロジェクトのみならず業務全体の、生産性および品質の向上につながる。
継続的な機械学習プロジェクトの成功にMLOpsの導入は不可欠であるが、全ての要素を最初から構築するのは困難である。MLOpsは現在進行形の技術であるため、まずはクラウドなどを活用しながら、スモールスタートアップでAIプラットフォームの構築に着手して、段階的なアプローチにて取り組むことが現実的である。

※1:PoCとはProof Of Conceptの略称、日本語では概念検証という。新しいアイデアや技術などについて実現可能性や効果などを判定するために事前検証する工程。

※2:D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, and Dan Dennison. 2015. Hidden technical debt in Machine learning systems. In Proceedings of the 28th International Conference on Neural Information Processing Systems - Volume 2 (NIPS' 15). MIT Press, Cambridge, MA, USA, 2503–2511.

※3:技術的負債とは、その場しのぎで不適切なソフトウェアアーキテクチャを採用すると、将来的な改修などに伴う変更コストが肥大化してしまい、まるで借金における利子のようなものがついてしまうことを意味する。

※4:ウォーターフォール型とは、システムの開発を複数の工程に分けて段階的に実施する方法で、前工程が終了してから次工程に移り、前工程には戻しは極力避けることを原則とする。

※5:アジャイル開発とは、イテレーションと呼ばれる短い開発期間を複数設定し、トライアンドエラーで設計と開発を繰り返すことで、品質の向上を確保し、リスクを最小化する手法。アジャイルとは“すばやい” “機敏な”という意味である。

※6:オンプレとは、情報システム機器を自社施設内やデータセンターに設置して、自社で運用すること。自社運用ともいう。

※7:ETLとは、外部のデータソースからデータを抽出(Extract)、利用目的に応じて変換・加工(Transform)、データベースなどに保存する(Load)工程。

連載一覧

関連するナレッジ・コラム

関連するセミナー