MLOps入門：なぜ必 要なのか（2/3）
モデル、プロダクトコード、運用が共通の提供基盤を持たずに成長したとき、何が崩れるのか。
2021年9月にCode Chrysalisで行った「Introducing MLOps: Why we need it, and how to apply it in your company」を再録する全3回の第2回です。第1回では、ML、開発、本番運用の3つのフェーズを通してMLOpsを定義しました。今回は、MLプロダクトの成長に伴って、なぜその考え方が必要になるのかを架空の物語でたどります。
内容は2021年当時の講演に基づいています。その後、ツールや一般的な運用方法は変化しています。
なぜMLOpsが必要になるのか
初期のデモであれば、仮想マシン上でモデルを動かすだけでも目的を果たせます。負荷が増えるのは、そのモデルがプロダクトの一部になってからです。データセットとモデルの版を管理し、アプリケーションを継続して変更し、リリース前にテストし、サービスとモデルの状態を確認する必要が生まれます。
課題はモデルサービングだけではありません。研究から実装、実装からデプロイ、本番環境から次の実験へと戻るまで、工程間の受け渡し全体が対象になります。
成長するMauriceとJimのプロダクト
講演では、Mauriceという架空の開発者を例にしました。Mauriceは、食べ物の画像を「ホットドッグ」か「ホットドッグではない」かに分類するノートブックを作っています。これはドラマ『シリコンバレー』へのオマージュです。最初は個人的な実験でしたが、資金と事業案を持つJimが加わり、アプリとして提供する話が進みます。
ユーザーが増え ると、Mauriceの仕事はモデル開発だけでは収まりません。複数のデータセットとモデルを比較し、フィードバックに対応し、フロントエンドとバックエンドも保守します。Colab、Drive、1台のPC、ngrokで公開したサービスの組み合わせでは、本番運用を整理しきれなくなります。
登場人物と結末は、講演用に誇張したフィクションです。「数百万人のユーザー」も実績ではありません。ここで見るべきなのは、一人の記憶だけでは、依存関係、リリース、運用指標を管理できなくなるという状況です。
分類器の元ネタは、ドラマ『シリコンバレー』の一場面です。
システム全体を見る
MauriceとJimは、架空のMLOps担当者Mathieuを迎えます。最初に行うのは、ツール選定ではなく、現在のアーキテクチャを図にすることです。ノートブック、Flaskのサービス、モバイルアプリ、データセット、モデル、デプロイ、本番指標を、一つのシステムとして確認できるようにします。
改善は第1回で紹介した3フェーズに沿って進めます。MLフェーズでは、実験とモデルリリースのパイプラインによって反復作業を減らします。開発フェーズでは、CI/CDとテストでアプリケーションのリリースを支えます。本番フェーズでは、サービスの稼働状況とモデル性能を監視し、アラートを設定します。既存の工程で見つけた弱点に対し、必要な変更を一つずつ当てていきます。
物語から見える実務上の要点
架空のチー ムが行った変更は、次の4点に整理できます。
- データパイプラインとモデル実装を再現可能な形に整える
- ML、開発、本番の各要素を一続きの工程として検証する
- 繰り返しが遅延やミスにつながるデプロイとテストを自動化する
- サービスの稼働状況とモデル性能を監視する
MLの実験性を保ちながら、周辺のプロダクトには安定したソフトウェア開発が求められます。モデルが正常でも、工程間の未検証な受け渡しが一つあれば、パイプライン全体は止まり得ます。ボトルネックを減らし、システムの状態を見えるようにすることで、小さなチームでも毎回のリリースを個別作業にせず改善を続けられます。
実例との比較
講演では、架空の例とあわせてGoogle CloudによるGo-Jekの事例を紹介しました。インドネシアの配車サービスを支える基盤を、少人数のエンジニアリングチームが構築した経緯を扱ったものです。大規模運用との比較材料になりますが、アーキテクチャや数値は事例公開当時の情報として読む必要があります。
Go-Jekの顧客事例を読む。
次回：MLOpsを導入する
今回は、単純化したプロダクト開発の物語を通して、MLOpsが必要になる理由を整理しました。第3回では現在の工程を図にし、制約に合うツールを選び、ノートブックから本番アーキテクチャへ段階的に移行する方法を扱います。
2023年12月23日にMediumで公開した記事を再編集しました。技術的な主旨は維持しつつ、元の講演スライドは素材内のストック画像について再掲載権を確認できないため省略しています。