Google Cloud Platform 上でのデータサイエンス、第2版

第10章. バーテックスAIでMLOpsの準備をする

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第9章では、TensorFlowモデルをJupyterノートブックで開発した。モデルをトレーニングし、エンドポイントにデプロイし、ノートブック環境から予測値を得ることができた。開発中はこれでうまくいったが、スケーラブルなワークフローではない。

JupyterノートブックでトレーニングしたTensorFlowモデルをVertex AIにデプロイしても、数百のモデルや大規模なチームにはスケールしない。再トレーニングは難しいだろう。なぜなら、運用チームは、実に不格好で合計が最小でないものの上に、運用と監視とスケジューリングのすべてをセットアップしなければならないからだ。

機械学習モデルを本番稼動させるためには、以下の要件を満たす必要がある：

• モデルはバージョン管理下にあるべきである。gitのようなソースコード管理システムは、テキストとバイナリが混ざったファイル（.ipynbファイルなど）よりも、テキストファイル（.pyファイルなど）の方がずっとうまくいく。

• データセットの作成からトレーニング、デプロイまでのプロセス全体は、コードによって駆動されなければならない。これは、GitHubアクションやGitLab継続的インテグレーションを使えば、新しく変更されたコードがチェックインされるたびに、トレーニングの実行を自動的に再トリガーすることが簡単にできるようにするためだ。

• 再トレーニングは、Cloud Storageバケットへの新しいデータの到着など、コード以外の変化でトリガーできるように、プロセス全体は単一エントリポイントから起動できるようにする。

• モデルやエンドポイントのパフォーマンスをモニターし、モデルコードを修正することなく、発生した問題のサブセットを修正するための対策を講じることは容易であるべきだ。例えば、GPUが飽和しつつある場合、トレーニングやサービングのためにリソースを追加することは容易であるべきだ。モデルを継続的に 評価し、入力特徴の分布が変化したり、評価メトリックが特定の閾値を下回ったりした場合は、モデルの再トレーニングをトリガーできるようにすべきである。

これらの基準を合わせてMLOpsと呼ぶ。一般化すればGoogle Cloud、特にVertex AIは、多くのMLOps機能を提供している。しかし、これらの内蔵機能を活用するためには、モデルコードとオペレーションコードを明確に分離し、ノートブックではなくPythonですべてを表現した方が良い。

Pythonを使った開発とデプロイ

Jupyterノートブックは開発には最適だが、Vertex AIがそれを可能にしてくれるとはいえ、これらのノートブックを本番環境に直接置くことは強くお勧めしない。

私がお勧めするのは、初期化したプロトタイピング・モデルのコードをPythonファイルに変換し、その中ですべての開発を続けることだ。Jupyterノートブックは捨てる。Pythonファイルはあなたのコードリポジトリにあり、今後維持されるコードベースになる。

本書のコードリポジトリにあるmodel.pyと train_on_vertexai.pyのファイル内のコードを見て、それらに従う。

JupyterLabのローカルPythonモジュールを使う

開発を行ったJupyterノートブックを捨ててしまったら、将来のアドホックな作業やデモはどうすればいいのだろうか？私がお勧めするのは、将来の実験やアドホックなデータ分析、デモのために、新しいノートブックから抽出した（そしてメンテナンスした）Pythonコードを呼び出すことだ。例えば、 ...