MLOps理解したい
MLOpsという単語を聞かない日はないくらいだけど、世の中にMLOpsのためのツールが溢れているせいかツール使っていればMLOpsしているみたいな気持ちになってしまっている。
結局何ができていればMLOpsができていると言えるのか理解しておきたい。
AIエンジニアのための機械学習システムデザインパターンでは以下のようにMLOpsが定義されている。
www.shoeisha.co.jp
昨今のソフトウェアエンジニアリングではクラウドとWeb技術の発展により、システムの開発と運用を同一のライフサイクル、同一のチームで実施し、高速に開発とフィードバックループ(ユーザからプロダクトの使い心地や意見を得て、改善に繋げるプロセスを繰り返すこと)を回す文化やツール、開発プロセスとしてDevOps(DevelopmentとOperationsを繋げた略語。「デブオプス」と読む)が誕生し、盛んに用いられています。DevOpsでは開発チームと運用チームを統合し、全員がプロダクトのEndtoEndに責任を持ちます。継続的インテグレーション(CI=ContinuousIntegration)や継続的デリバリー(CD=ContinuousDelivery)を維持し、フィードバックループを回すことでプロダクトの修正を行います。特にWebやスマホアプリ業界では、ユーザが直接使うアプリケーションを提供するため、ユーザのアプリケーション内での行動やフィードバック、障害をもとに自社プロダクトの修正、更新をスピーディに実行することが求められます。修正や更新されないアプリケーションは使われなくなると言っても良いくらい、変化の激しいビジネスになっています。こうしたDevOpsで用いられるプラクティスを機械学習に適用したのがMLOps(MachineLearningとOperationsを繋げた略語。「エムエルオプス」と読む)です。
ということでMLOps=DevOps+ML(継続的なトレーニング)と考えて良さそう。
なのでまずはDevOpsの考え方を理解しておきたい。
そこで以下の本を読む。
www.nikkeibp.co.jp
この書籍を読んで自分としてDevOpsは結局どんなものなのかを言葉にすると以下のような感じ。
- 顧客の要望を達成するための一連の作業(書籍内ではITバリューストリームと呼んでいる)のリードタイムを短くすること、そのために仕事のバッチサイズを小さくすること
- 改善のカタを作り上げるために、慣習的に日々業務改善を実践すること
上記を達成するための3の原則として
- 開発->運用->顧客の流れを高速にすること。そのために仕事の可視化、作業のバッチサイズ、作業間インターバルを削減する。また、作業の品質を高めて下流に不良品を渡さないこと。
- 運用->開発への素早いフィードバックフローを構築すること。問題解決のためのフィードバックを最重要視すること。
- 実験とリスクテイク(リスク受容)によって得られる成功と失敗から学習・改善ができる組織文化を構築すること
これにMLが入ってきたとしても考え方に大きな違いはないように思う。
- モデリングを担当するDSがオフラインでの検証を回すためにほか作業に影響されない環境を作ること
- 作られたモデルをアプライドするエンジニアが、DSに依存せずに機能改善を行えること
- システムに以上があった際に、エンジニア側からDSに高速にFBができ、DSがも即時に対応できること
- オフラインからオンラインへの壁を取り除き、高速な実験とFBが受けられる環境を作ること
などなど...
この解釈のもとで昨今のMLOpsを果たすための各種ソフトウェアなどを見ていくと、道具としては多少の違いはあっても必要なものは揃っている状況にあると思う。
ただ、道具を入れただけだと本来DevOpsによって達成されるべきものが完全には果たされない印象もある。
- DSとエンジニアが互いの状況を把握しておらず、作業間インターバルが多く発生する
- まともにテストがされていないモデルがデプロイされ、運用負荷が増大するというDSとエンジニアのテストへの意識の違い(ロールバックを素早く行える環境を作ることでカバーすることもできるかもしれないが、いずれにしてもプロダクションに入れるタイミングではテストが徹底されている必要はある)
- うまく行かなかったことを組織内で共有・改善に繋げられる組織風土
このあたりを意識しながらMLOpsを推進していかないと道具だけ入ってできた気になってしまいそう。
自分が関与しているところでは前提となるDevOpsや取り組みに対する組織的な理解が追いついていない感じもあるので、このあたりを意識できるような働きかけを意識していけると良さそう(難しそうだが)。