Model deployment patterns | Databricks on AWS [2022/10/24時点]の翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
本書では、ステージングからプロダクションにMLアーティファクトを移行する際の2つの一般的なパターンを説明します。モデルやコードに対する変更における非同期的な性質は、ML開発プロセスが従う可能性がある複数のパターンが存在することを意味します。
モデルはコードによって作成されますが、得られるモデルアーティファクトや、モデルを作成するコードは非同期的にオペレーションされることがあります。すなわち、新たなモデルバージョンやコードの変更が同時に発生しないことがあります。例えば、以下のシナリオを考えてみます。
- 不正なトランザクションを検知するために、週次でモデルを再トレーニングするMLパイプラインを開発します。コードは頻繁に変更されないことがあるかもしれませんが、新規データを取り込むためにモデルは毎週再トレーニングされます。
- 文書を分離するために、大規模なディープニューラルネットワークを作成することがあります。このケースでは、モデルのトレーニングは、計算的に高コストで時間を浪費するものであり、モデルの再トレーニングが頻繁に行われないかもしれません。しかし、このモデルをデプロイ、サービング、モニタリングするコードは、モデルを再トレーニングすることなしにアップデートされることがあります。
この二つのパターンでは、モデルのアーティファクト、あるいはモデルアーティファクトを生成するトレーニングコードがプロダクションにプロモーションされるのかどうかという点で異なります。
コードをデプロイ(推奨)
多くのシチュエーションにおいて、「コードのデプロイ」アプローチを推奨します。このアプローチはDatabricksにおけるMLOpsワークフローに組み込まれています。
このパターンにおいては、モデルをトレーニングするコードは開発環境で開発でされます。同じコードがステージング、プロダクションに移行します。モデルはそれぞれの環境でトレーニングされます: 最初はモデル開発の一部として開発環境でトレーニングされ、インテグレーションテストの一部としてステージングで(限定的なデータのサブセットに対して)トレーニングされ、プロダクション環境では最終モデルを生成するために(完全なプロダクションデータに対して)トレーニングされます。
利点:
- プロダクションデータへのアクセスが制限されている企業においては、このパターンを用いることでプロダクション環境のプロダクションデータを用いてトレーニングを行うことができます。
- トレーニングコードはプロダクションに向けてレビュー、テスト、承認されるので、自動モデル再トレーニングはより安全になります。
- サポートするコードはモデルトレーニングコードと同じパターンに従います。両方ともステージングのインテグレーションテストを通ることになります。
欠点:
- 関係者にコードを受け渡すためのデータサイエンティストの学習曲線は急峻なものになります。事前定義済みのテンプレートやワークフローが役立ちます。
また、このパターンにおいては、データサイエンティストはML固有の問題を特定、修正できる知識を持っているので、プロダクション環境からトレーニング結果をレビューできる様になっている必要があります。
このシチュエーションにおいて、ステージングで完全なプロダクションデータセットに対するモデルのトレーニングが必要であれば、コードをステージングにデプロイし、モデルをトレーニングし、プロダクションにモデルをデプロイするハイブリッドなアプローチを使うことができます。このアプローチはプロダクションにおけるトレーニングのコストを削減しますが、ステージングにおける血雨以下のオペレーションコストを発生させます。
モデルのデプロイ
このパターンでは、モデルアーティファクトは開発環境のトレーニングコードによって生成されます。アーティファクトはプロダクションにデプロイされる前に、ステージング環境でテストされます。
以下の条件が一つ以上当てはまる場合には、この選択肢を検討することは可能です。
- モデルのトレーニングが非常に効果、あるいは再現が困難。
- 単一のDatabricksワークスペースで全ての作業が行われた。
- 外部のリポジトリやCI/CDプロセスを使っていない。
利点:
- データサイエンティストへの引き継ぎが簡単です。
- モデルトレーニングが高コストの場合、モデルトレーニングが一回のみで済みます。
欠点:
- 開発環境からプロダクションデータにアクセスできない場合(セキュリティ上の理由からあり得ることです)、このアーキテクチャは実現できません。
- このパターンではモデルの再トレーニングの自動化はトリッキーです。開発環境で再トレーニングを自動化することはできますが、プロダクションにモデルをデプロイする責任を持つチームは、結果得られるモデルをプロダクションレディとして受け入れられないかもしれません。
- 特徴量生成、推論、モニタリングで使用するパイプラインのようなコードは、別にプロダクションにデプロイする必要があります。
以下の図では、異なる実行環境に対して上述のデプロイメントパターンのコードのライフサイクルを対比しています。
図に示している環境はステップが実行される最終的な環境となります。例えば、モデルをデプロイするパターンでは、最後のユニットテストとインテグレーションテストは、開発環境で実行されます。コードをデプロイするパターンでは、ユニットテストとインテグレーションテストは開発環境で実行され、最後のユニットテストとインテグレーションテストはステージング環境で実行されます。
