この記事は、2020/05/17時点のGCPのMLOps: Continuous delivery and automation pipelines in machine learningの英語版を翻訳したものです。
翻訳元の記事は、Creative Commons Attribution 4.0 Licenseでライセンスされています。
追記(2020/06/21)
本家様が日本語版を公開していました。みんな公式Documentを読もう。
https://cloud.google.com/solutions/machine-learning/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning
この記事を読む前提知識として、機械学習のモデルを作成したことがあり、DevOpsの概念を理解していると頭に入ってきやすいかと思います。
誤訳や解釈間違いがあれば、ご指摘いただけますと幸いです。
以下本文
MLOps: 機械学習における継続的デリバリとパイプラインの自動化
はじめに
データサイエンスとMLは、現実の複雑な問題を解決し、業界を変革し、すべてのドメインで価値を提供するためのコア機能になりつつあります。現在では、効果的なMLシステムを構築をするための構成要素が利用可能となっています。
- 大規模なデータセット
- 安価なオンデマンドコンピューティングリソース
- さまざまなクラウドプラットフォームでのML専用のアクセラレータ
- さまざまなML研究分野（コンピュータビジョン、自然言語処理、AIでの推薦システムなど）の急速な進歩。
このドキュメントは、DevOpsの原則をMLシステム（MLOps）に適用したいデータサイエンティストとMLエンジニアを対象としています。MLOpsは、MLシステム開発（Dev）とMLシステムオペレーション（Ops）を統合することを目的とした
MLエンジニアリングの文化と実践です。MLOpsを実践するということは、統合、テスト、リリース、デプロイ、インフラストラクチャ管理を含む、MLシステム構築のすべてのステップで自動化とモニタリングを提唱することを意味します。
データサイエンティストは、ユースケースに関連するトレーニングデータがあれば、オフラインホールドアウトデータセットの予測パフォーマンスを使用してMLモデルを実装およびトレーニングできます。ただし、実際の課題はMLモデルを構築することではなく、統合されたMLシステムを構築し、それを本番環境で継続的に運用することです。Googleでの本番環境MLサービスの長い歴史により、本番環境でMLベースのシステムを運用することには多くの落とし穴がある可能性があることがわかりました。
これらの落とし穴のいくつかは、「機械学習：技術的負債の高金利クレジットカード」にまとめられています。
図1. MLシステムの要素。機械学習システムの隠された技術的負債 から転載。
この図では、システムの残りの部分は、構成、自動化、データ収集、データ検証、テストとデバッグ、リソース管理、モデル分析、プロセスとメタデータ管理、インフラストラクチャの提供、監視で構成されています。
このような複雑なシステムを開発して運用するには、DevOpsの原則をMLシステム（MLOps）に適用できます。このドキュメントでは、MLでのCI、CD、CTなどのデータサイエンスのプラクティスのためにMLOps環境をセットアップするときに考慮する必要がある概念について説明します。
次のトピックについて説明します。
- DevOps vs MLOps
- MLモデルを開発する手順
- MLOps成熟度レベル
DevOpsとMLOps
DevOps は、大規模なソフトウェアシステムの開発と運用における一般的な手法です。この方法には、開発サイクルの短縮、デプロイ速度の向上、信頼できるリリースなどの利点があります。
これらの利点を実現するには、ソフトウェアシステム開発に次の2つの概念を導入します。
MLシステムはソフトウェアシステムであるため、MLシステムを大規模に構築および運用できることを保証するために、同様のプラクティスが適用されます。1
ただし、MLシステムは、次の点で他のソフトウェアシステムと異なります。
- チームスキル：
MLプロジェクトでは、通常、探索的データ分析(EDA)、モデル開発および実験に重点を
置くデータサイエンティストまたはML研究者がチームに含まれます。
これらのメンバーは、本番環境クラス(production-class)のサービスを構築できる
経験豊富なソフトウェアエンジニアではない可能性があります。 - 開発：
MLは本質的に実験的です。
さまざまな特徴量、アルゴリズム、モデリング手法、およびパラメーター構成を試して2、
課題に対する最適な組み合わせをできるだけ早く見つける必要があります。
課題は、機能したものと機能しなかったものを追跡し、
コードの再利用性を最大化しながらモデルの再現性を維持することです。 - テスト：
MLシステムのテストは、他のソフトウェアシステムのテストよりも複雑です。
通常の単体テストと統合テストに加えて、
データの検証、トレーニングされたモデルの品質評価、モデルの検証が必要です。 - デプロイ：
MLシステムでは、オフラインでトレーニングされたMLモデルを
予測サービスとしてデプロイできるほど、デプロイは単純ではありません。
MLシステムでは、モデルを自動的に再トレーニングしてデプロイするために、
マルチステップのパイプラインをデプロイする必要があります。
データサイエンティストが新しいモデルをトレーニングして検証するために、
デプロイ前に手動で行っていたステップを自動化する必要があります。
このため、パイプラインはどんどん複雑になっていきます。 - 本番環境：
MLモデルは、最適でないコーディングだけでなく、
常に進化するデータプロファイルのために性能が低下することがあります。
言い換えれば、モデルは従来のソフトウェアシステムよりも多くの方法で劣化する可能性があり、
この(MLシステム特有の)劣化を考慮する必要があります。
したがって、データの要約した統計量を追跡し、モデルのオンラインパフォーマンスを監視して、
モデルの出力値が期待している値から逸脱したときに通知したり、
ロールバックしたりする必要があります。
MLと他のソフトウェアシステムは、ソース管理の継続的インテグレーション、ユニットテスト、統合テスト、およびソフトウェアモジュールまたはパッケージの継続的デリバリーにおいて類似しています。ただし、MLでは、いくつかの顕著な違いがあります。
- CI(Continuous Integration)は、もはやコードやコンポーネントのテストや検証だけではなく、
データやデータスキーマ、モデルのテストや検証も重要な要素となっています。 - CD(Continuous Delivery)は、もはや単一のソフトウェアパッケージやサービスではなく、
別のサービス（モデル予測サービス）を自動的にデプロイするシステム
（MLトレーニングパイプライン）のことです。 - CT(Continuous Training)はMLシステムに特有の目新しい項目であり、
モデルを自動的に再トレーニングし、(システムにデプロイすることで)予測サービスを
提供できる状態にすることを目的としています。
| DevOps | MLOpsで追加 | |
|---|---|---|
| CI | コードやコンポーネントのテストや検証 | データやデータスキーマ、モデルのテストや検証 |
| CD | 単一のソフトウェアパッケージやサービスのデプロイ | 別のサービス（モデル予測サービス）を自動的にデプロイするシステム （MLトレーニングパイプライン）のこと |
| CT | 該当なし | モデルを自動的に再トレーニングし、(システムにデプロイすることで)予測サービスを 提供できる状態にすること |
| 表1(翻訳者により追加) MLOpsにおいて、DevOpsから追加された項目 |
以下では，予測サービスとして機能するMLモデルのトレーニングと評価の代表的な手順を説明します．
MLのためのデータサイエンスの手順
どのMLプロジェクトでも、ビジネスユースケースを定義して成功基準を確立した後、
MLモデルを本番環境にデリバリする過程には次の手順が含まれます。
これらの手順は手動で完了することも、自動パイプラインで完了することもできます。
- データ抽出：
MLタスクのさまざまなデータソースから関連データを選択して統合します。 - データ分析：
探索的データ分析 （EDA） を
実行して、MLモデルの構築に使用可能なデータを把握します。
このプロセスにより、次のことが起こります。- モデルが期待するデータスキーマと特性を理解します。
- モデルに必要なデータの準備と特徴量エンジニアリングを特定します。
- データの準備：
データはMLタスク用に準備されます。
データの準備には、データのクリーニングが含まれ、
データをトレーニング用のデータセット、検証用のデータセット、およびテスト用のデータセットに分割します。
また、目的となるタスクを解決するモデルのためのデータ変換と特徴量エンジニアリングを適用します。
このステップの出力は、準備された形式での データ分割 です。 - モデルのトレーニング：
データサイエンティストは、さまざまなMLモデルをトレーニングするために、
準備されたデータを使用してさまざまなアルゴリズム3を適用します。
さらに、適用されたアルゴリズム3にハイパーパラメータチューニングを行って、
最も良い性能のMLモデルを取得します。
このステップの出力は、トレーニング済みモデルです。 - モデル評価：
モデルは、モデルの品質を評価するためのホールドアウトテストセット(holdout test set)
4 で評価されます。
このステップの出力は、モデルの品質を評価するための一連の評価基準です。 - モデルの検証：
モデルが(本番のシステムに)デプロイする基準に達していること、
つまり、予測性能が一定のベースラインよりも優れていることを確認します。 - モデルの提供：
検証されたモデルは、予測値を出力するためにターゲット環境にデプロイされます。
このデプロイ方法は次のいずれかになります。- オンライン予測を提供するREST APIを備えたマイクロサービス。
- エッジまたはモバイルデバイスへの組み込みモデル。
- バッチ予測システムの一部。
- モデルのモニタリング：
モデルの予測性能をモニタリングして、
MLの過程で(予測性能改善のための)新たなイテレーションを実施します。
上記の手順の自動化のレベルによって、MLプロセスの 成熟度 は定義されます、このプロセスは、新しいデータが与えられた新しいモデルのトレーニングまたは新しい実装が与えられた新しいモデルがどれだけ速くトレーニングされるかという速度に直結します。
下記の章では、自動化を含まない最も平凡なレベルから、MLパイプラインとCI / CDパイプラインの両方を自動化するまでの、MLOpsの3つのレベルについて説明します。
MLOps level 0: 手動プロセス
多くのチームには、最先端のモデルを構築できるデータサイエンティストとML研究者がいますが、MLモデルの構築とデプロイのプロセスは完全に手動です。これは、成熟度の 基本 レベル、つまりレベル0 と見なされます。
次の図は、このプロセスのワークフローを示しています。
図2。モデルを予測サービスとして提供するための手動MLステップ。
特徴
次のリストは、図2に示すように、MLOPsレベル0プロセスの特徴を示しています。
- 手動、スクリプト駆動、およびインタラクティブなプロセス：
データ分析(data analysis)、データ準備(data preparation)、
モデルトレーニング(Model Training)、検証(Validation)など、すべてのステップは手動です。
各ステップを手動で実行され、あるステップから別のステップへの移行も手動で行う必要があります。
このプロセスでは、通常、実用的なモデルが作成されるまで、
データサイエンティストによって(Jupyter等の)ノートブックでインタラクティブに記述および実行される
実験的なコードで進められます。 - MLとオペレーションの分離：
このプロセスにおいて、モデルを作成するデータサイエンティストの役割と、
モデルを予測サービスとして提供するエンジニアの役割が分離されます。
データサイエンティストは、トレーニング済みのモデルを成果物(artifact)として
エンジニアリングチームに引き渡し、エンジニアリングチームはインフラ上のAPIにデプロイを担当します。
この引き渡し作業には、次のことが含まれます、
トレーニングされたモデルをstorageに格納すること、
モデルをリポジトリに保存、またはモデル用のレジストリにアップロードすることなどです。
次に、モデルをデプロイするエンジニアは、必要な機能を本番環境で利用できるようにし、
低レイテンシのサービスを提供する必要があります。
これにより、トレーニングとサービスの間での歪み:training-service skew
5 が発生する可能性があります。 - 頻繁でないリリース作業：
このプロセスでは、データサイエンスチームが、頻繁に変更されない少数のモデル
（モデルの実装の変更または新しいデータを使用したモデルの再トレーニング）を
管理することを前提としています。
新しいバージョンのモデルは、年に数回しかデプロイされません。 - CIしない：
実装変更が前提とされていないため、CIは無視されます。
通常、コードのテストはノートブックまたはスクリプトの実行の一部です。
実験ステップを実装されたスクリプトとノートブックはソース管理されており、
それらにより、トレーニングされたモデル、評価指標、可視化などの成果物が生成されます。 - CDしない：
モデルのデプロイが頻繁に行われないため、CDは考慮されません。 - デプロイ≒予測サービス:
このプロセスは、MLシステム全体をデプロイするのではなく、トレーニング済みモデルを予測サービス
（REST APIを備えたマイクロサービスなど）としてデプロイすることのみを考慮しています。 - 能動的な性能監視の欠如:
プロセスがモデルの予測とアクションを追跡したり、ログに記録しません、
これは、モデルの性能低下やその他のモデル挙動のゆらぎを検出するために必要となります。
エンジニアリングチームは、セキュリティ、リグレッション、負荷テスト、カナリアテストを含むAPIの設定、テスト、デプロイメントのための複雑なセットアップを独自に行うことがあります。加えて，MLモデルの新バージョンの本番環境へのデプロイは、通常、モデルがすべての予測リクエストトラフィックに対応するように促進される前に、A/Bテストまたはオンラインで実験されます。
課題
MLOpsレベル0は、ユースケースにMLを適用しようとしている多くの企業で一般的です。モデルがめったに変更されたり、トレーニングされたりすることがない場合には、このような手動のデータサイエンティスト駆動のプロセスで十分かもしれません。実際問題として、モデルが実世界にデプロイされると、モデルが壊れてしまうことがよくあります。モデルは、環境のダイナミクスの変化、または環境を説明するデータの変化に適応できません。詳細については、「機械学習モデルが本番環境でクラッシュして書き込みする理由」を参照してください 。
これらの課題に対処し、本番環境でモデルの精度を維持するには、次のことを行う必要があります。
- 本番環境でモデルの品質を能動的に監視：
監視により、パフォーマンスの低下とモデルの古さを検出できます。
これは、新しい実験の反復と新しいデータに対する
モデルの（手動）再トレーニングの手がかりとして機能します。 - 本番のモデルを頻繁に再トレーニングする：
進化する新しいパターンを取り込むためには、
最新のデータを使用してモデルを再トレーニングする必要があります。
たとえば、アプリがMLを使用してファッション製品を推薦する場合、
その推奨は最新のトレンドと製品に適応する必要があります。 - 新しい実装を伴った継続的な実験：
最新のアイデアや技術の進歩を利用するためには、
特徴量エンジニアリング、モデルアーキテクチャ、ハイパーパラメータなどの
新しい実装を試してみる必要があります。
例えば、顔検出にコンピュータビジョンを使う場合、顔のパターンは固定されているものの、
より良い新しい技術を使えば検出精度を向上させることができます。
この手動でのプロセスの課題に対処するためには、
CI/CDとCTのためのMLOpsのプラクティスが役立ちます。
MLトレーニング・パイプラインをデプロイすることで、CTを有効にすることができ、
CI/CDシステムをセットアップして、
MLパイプラインの新しい実装を迅速にテスト、ビルド、デプロイすることができます。
これらの機能については、次の章で詳しく説明します。
MLOps level1: MLパイプラインの自動化
レベル1の目標は、MLパイプラインを自動化してモデルの継続的トレーニング(Continuous Training)を実行することです。
これにより、モデル予測サービスの継続的な提供を実現できます。新しいデータを使用して本番環境でモデルを再トレーニングするプロセスを自動化するには、パイプラインを起動するときのトリガーとメタデータ管理だけでなく、自動化データとモデルの検証ステップをパイプラインに導入する必要があります。
次の図は、CTのための自動化MLパイプラインの概略図です。
図3. CTのためのMLパイプラインの自動化
特徴
次のリストは、図3に示すように、MLOPsレベル1での体制の特徴を示しています。
- 迅速な実験：
ML実験のステップはオーケストレーションされています。
ステップ間の移行は自動化されているため、実験を迅速に繰り返すことが可能になり、
パイプライン全体を本番環境に移すよりよい準備が整います。 - 本番環境でのモデルのCT：
次の「データとモデルの検証」のセクションで説明するライブパイプライントリガーに基づく最新のデータを使用して、
モデルは本番環境で自動的にトレーニングされます。 - 実験と運用の対称性：
開発環境または実験環境で使用されるパイプラインの実装は、
本番前環境(preproduction environment)と本番環境で使用され、
これは、DevOpsを含んだ概念であるMLOpsのプラクティスの重要なポイントとなっています。 - コンポーネントとパイプラインのモジュール化されたコード：
MLパイプラインを構築するには、コンポーネントが、再利用可能(reusable)、
構成可能(composable)、およびMLパイプライン間で共有できることを前提に作られている必要があります。
そのため、EDA(Exploratory Data Analysis)のコードは引き続きノートブックで使用できますが、
(パイプラインの)コンポーネントのソースコードはモジュール化する必要があります。
さらに、コンポーネントは、理想的には次のことを行うためにコンテナ化する必要があります。- (データサイエンティストの手元にある)ランタイムから実行環境を分離します。
- 開発環境と本番環境のどちらでもコードを再現可能な状態にします。
- パイプラインの各コンポーネントを分離します。
コンポーネントは独自のバージョンのランタイム環境を持つことができ、
(それぞれのコンポーネントは)異なるプログラミング言語とライブラリを持つことができます。
- モデルの継続的デリバリー(Continuous Delivery)：
本番環境のMLパイプラインは、新しいデータでトレーニングされた
新しいモデルを予測サービスとして継続的に提供します。
モデルをデプロイするステップは自動化されています、
このステップは、オンラインでの予測のための予測サービスとして
トレーニングされ、検証されたモデルを提供します。
追加コンポーネント
ここでは，MLの継続的な学習(Continuous Training)を可能にするために，
アーキテクチャに追加する必要のあるコンポーネントについて説明します．
データとモデルの検証
MLパイプラインを本番環境にデプロイすると、「MLパイプラインのトリガー」の章で説明されている1つ以上のトリガーが パイプラインを自動的に実行します。パイプラインは、新しいライブデータを予期して、新しいデータでトレーニングされた新しいモデルバージョンを生成します（図3を参照）。したがって、下記で予期される動作を保証するために、自動化された*データ検証(Data Validation)およびモデル検証(Model Validation)*ステップが本番パイプラインで必要となります。
- データの検証(Data Validation):
モデルのトレーニングを実施する前に、モデルを再トレーニングするか、
パイプラインの実行を停止するかを決定するために、このステップが必要です。
この決定は、以下の項目がパイプラインによって確認された場合に自動的に行われます。- データスキーマが歪んだ場合：
データスキーマの歪みは入力データの異常と見なされます、
つまり、データ処理やモデルのトレーニングを含む下流に流れていくパイプラインステップが、
予期されるスキーマに準拠しないデータを受信します。
この場合、データサイエンスチームが調査できるようにパイプラインを停止するべきです。
チームは、スキーマへの修正または更新処理を適用するために、
パイプラインの修正または更新処理をリリースする場合があります。
スキーマの歪みには、予期しない特徴量の受信、含まれるはずの特徴量が欠如した状態での受信、
異常値を持つ特徴量の受信が含まれます。 - データの値の歪み：
値の歪みは、扱うデータにおける統計的な特性の重要な変化です。
つまり、データパターンが変化していることを意味し、
これらの変化をキャプチャして、再トレーニングのきっかけとする必要があります。
- データスキーマが歪んだ場合：
- モデルの検証(Model Validation)：
このステップは、新しいデータでモデルを正常にトレーニングした後に発生します。
本番環境に昇格させる前に、モデルを評価して検証します。
この オフラインでのモデル検証(offline model validation) の手順は、以下で構成されています。- テストデータセットのトレーニング済みモデルを使用して評価指標値を生成し、
モデルの予測品質を評価します。 - モデルの予測品質を評価するために、トレーニングされたモデルをテスト・データセットを用いて
評価指標値を計算します。 - 新しくトレーニングされたモデルによって生成された評価指標値を現在のモデル
（本番モデル、ベースラインモデル、その他のビジネス要件モデル）と比較します。
新しいモデルを本番環境に昇格させる前に、新しいモデルが
現在のモデルよりも優れたパフォーマンスを発揮することを確認してください。 - モデルのパフォーマンスがデータのさまざまなセグメントで一貫していることを確認します。
たとえば、新しくトレーニングされた顧客解約モデルは、
前のモデルと比較して全体的に予測精度(accuracy)が向上するものの、
顧客の地域ごとの精度(accuracy)には大きなばらつきがあるかもしれません。 - インフラストラクチャの互換性と予測サービスのAPIとの整合性を含めて、
モデルをデプロイするためにテストをしてください。
- テストデータセットのトレーニング済みモデルを使用して評価指標値を生成し、
オフラインのモデル検証に加えて、オンラインでのトラフィック上で予測サービスを提供する前段階において、新たにデプロイされたモデルは、 オンラインでのモデル検証(online model validation) 、カナリアテストのためのデプロイ、またはA/Bテストのためのセットアップを受けます、
特徴量の保管(Feature store)
feature storeは、(MLOps)レベル1でのMLパイプライン自動化での追加コンポーネントです。feature storeは、一元化されたリポジトリであり、これは、トレーニングとサービス提供のための特徴量の定義、ストレージ、アクセスを標準化しています。feature storeは、特徴量を使った高スループットのバッチ処理と低レイテンシのリアルタイム処理の両方にAPIを提供する必要があります、また、トレーニングとサービス提供の両方のワークロードをサポートする必要があります。
feature storeは、データサイエンティストが以下のことを行うのに役立ちます:
- 同一または同様の特徴量のセットを再作成する代わりに、
すでに存在する使用可能な特徴量のセットを見つけて再利用します。 - 特徴量とそれらに関連するメタデータを維持することで、
定義が異なる類似した特徴量を持つことを避けられます。 - feature storeから最新の特徴量の値を提供します。
- 実験、継続的トレーニング(continuous training)、オンラインでの本番サービス提供のための
データの取得源としてfeature storeを使用することで、
トレーニングとサービス提供時の歪みを低減します。
このアプローチにより、トレーニングに使用される特徴量が、
サービス提供時に使用される特徴量と同種であることを確認できます。- 実験の場合、データサイエンティストは、feature storeからオフラインで
特徴量を抽出して実験を実行できます。 - 継続的トレーニング(Continuous Training)の場合、
自動化されたML学習パイプラインは，トレーニングの処理に使用されるデータセットの
最新の特徴量ひとまとまりを取得することができます． - オンラインでの予測の場合、予測サービスは、顧客の人口統計の特徴量、製品の特徴量、
現在のセッションを集約した特徴量などの、要求されたエンティティに関連する
特徴量ひとまとまりを取得します。
- 実験の場合、データサイエンティストは、feature storeからオフラインで
メタデータ管理(Metadata management)
MLパイプラインの各実行に関する情報が記録されており、データや成果物の追跡、再現性、比較に役立ちます。また、エラーや異常のデバッグにも役立ちます。パイプラインを実行するたびに、MLメタデータ・ストアには以下のメタデータが記録されます。
- 実行されたパイプラインとコンポーネントのバージョン。
- 開始日と終了日、時間、およびパイプラインが各ステップを完了するのにかかった時間。
- パイプラインの実行者。
- パイプラインに渡されたパラメーター引数。
- パイプラインの各ステップで生成された成果物への参照情報(pointer)、例を挙げると、
準備されたデータの場所、検証で検出された異常、計算された統計量、
カテゴリごとの特徴量から抽出された語彙などがある。
これらの中間出力を追跡することで、あるステップで失敗したことよってパイプラインが停止した場合に、
すでに完了したステップを再実行することなく、最新のステップからパイプラインを再開できます。 - 以前にトレーニングされたモデルへの参照情報(pointer):
モデルを以前のバージョンにロールバックする必要がある場合や、
モデル検証中においてパイプラインに新しいテストデータが流したときに
以前のモデルバージョンの評価指標を算出する必要がある場合に使用される。 - トレーニングセットとテストセットの両方のモデル評価ステップ中に生成されたモデル評価指標。
これらの評価指標は、モデルの検証ステップ中に、新しくトレーニングされたモデルの性能と
以前のモデルの性能とを比較するのに役立ちます。
MLパイプラインの実行トリガー (ML pipeline triggers)
ユースケースに応じて、新しいデータでモデルを再トレーニングするために、
本番環境でのMLパイプラインを自動化することができます。
- オンデマンド：パイプラインをアドホックに手動実行します。
- 日時指定：MLシステムでは、ラベル付きの新しいデータが毎日、毎週または毎月体系的に利用できます。
再トレーニングの頻度は、データパターンの変更頻度と、
モデルの再トレーニングにかかる費用にも依存します。 - 新しいトレーニングデータの利用可能性：
新しいデータが体系的にMLシステムでは利用できるというわけではなく、
代わりに、新しいデータが収集され、ソースデータベースで利用可能になったときに、
臨機応変に利用可能になります。 - モデルの性能の劣化時：顕著な性能低下がある場合、モデルは再トレーニングされます。
- データ分布の大幅な変化時（時間経過による予測精度の劣化(concept drift) 6）:
オンラインモデルの完全な性能を評価することは困難であるものの、
予測処理に使用される特徴量のデータ分布に大きな変化があると気づくときがあります。
この変化は、モデルが古くなったことを示しており、
新しいデータで再トレーニングする必要があります。
課題
新しい実装がパイプラインに頻繁にデプロイされるわけではなく、少数のパイプラインしか管理していない場合を想定すると、
通常は手動でパイプラインとそのコンポーネントをテストしています。さらに、新規実装をパイプラインに手動でデプロイしています。また、対象環境にデプロイするために、パイプラインに組み込むテスト済みソースコードをITチームに提出します。上記の設定は、新しいMLのアイデアではなく、新しいデータに基づいて新しいモデルをデプロイする場合に適しています。
しかしながら、新しいMLのアイデアを試し、MLコンポーネントの新しい実装を迅速にデプロイする必要があります。本番環境で多数のMLパイプラインを管理する場合、MLパイプラインのビルド、テスト、デプロイを自動化するためのCI/CDセットアップが必要です。
MLOps level2 : CI/CDパイプラインの自動化
本番環境のパイプラインを迅速かつ確実に更新するために、堅牢で自動化されたCI/CDシステムが必要です。この自動化されたCI/CDシステムを使用すると、データサイエンティストは、特徴量エンジニアリング、モデルアーキテクチャ、ハイパーパラメータに関する新しいアイデアを迅速に試すことができます。データサイエンティストは、これらのアイデアを実装し、新しいパイプラインコンポーネントを自動的に構築、テスト、およびターゲット環境へのデプロイを行うことができます。
次の図は、CI/CDを使用したMLパイプラインの実装を示しています、これは、自動化されたCI/CDのルーチンに加えて自動化されたMLパイプラインの仕組みの特徴を備えています。
図4 CI/CDと自動化されたMLパイプライン。
このMLOpsセットアップには、次の構成要素が含まれています。
- ソース管理(Source control)
- テストとビルドのサービス(Test and build services)
- デプロイサービス(Deploy services)
- モデルレジストリ(Model registry)
- 特徴量の保管(Feature store)
- MLメタデータストア(ML metadata store)
- MLパイプラインオーケストレーター(ML pipeline orchestrator)
特徴
次の図は、ML CI/CD自動化パイプライン(ML CI/CD automation pipeline)の段階を示しています。
図5 CI / CD自動化MLパイプラインのステージ
このパイプラインは、下記のステージから構成されています。
- 開発と実験：
実験のステップではオーケストレーションされた状態で、
新しいMLアルゴリズムや新しいモデリングを反復的に試せるようになっています。
この段階での出力は、MLパイプラインの各ステップのソースコードであり、
ソースコードはソースリポジトリにプッシュされます。 - パイプラインの継続的インテグレーション：
ソースコードをビルドし、さまざまなテストを実行します。
この段階での出力は、後のステージでデプロイされるパイプラインコンポーネント（パッケージ、実行ファイル7、および成果物）です。 - パイプラインの継続的デリバリー：
CIステージでの成果物をターゲット環境にデプロイします。
この段階での出力は、モデルにおける新しい実装を含んだデプロイ済みのパイプラインです。 - 自動化されたトリガー：
パイプラインは、予め設定されたスケジュールに基づいて、またはトリガーに応答して、
本番環境で自動的に実行されます。
この段階での出力は、モデルレジストリにプッシュされたトレーニング済みモデルです。 - モデル継続的デリバリー：
トレーニング済みモデルを予測サービスとして提供します。
この段階での出力は、デプロイされたモデルでの予測サービス(model prediction service)です。 - モニタリング:
ライブデータに基づいてモデルの性能に関する統計情報を収集します。
この段階での出力は、パイプラインを実行するか、新しい実験サイクルを実行するトリガーです。
データ分析ステップは、パイプラインが実験の新しい反復を開始する前に行われる、
データサイエンティストがいまだに手動で行うプロセスです。
モデル分析ステップも手動プロセスです。
継続的インテグレーション
このセットアップでは、新しいコードがコミットまたはソースコードリポジトリにプッシュされるとき、パイプラインとそのコンポーネントがビルド、テスト、およびパッケージ化されます。パッケージ、コンテナイメージ、実行ファイル7をビルドすることに加えて、CIプロセスには次のテストを含めることができます。
- 特徴量エンジニアリングに関するロジックの単体テスト。
- モデルに実装されているさまざまなメソッドの単体テスト。
たとえば、カテゴリカルデータ8列を受け入れる関数があり、その関数を
one-hot の特徴量としてエンコードします 。 - モデルのトレーニングが収束することをテストします
（つまり、モデルのlossはイテレーションごとに減少し、
いくつかのサンプルレコードに対して 過学習
していきます。）。 - モデルのトレーニングにおいて、ゼロで除算したり、小さい値または大きい値を操作することで
NaN値を生成しないことをテストします 。 - パイプラインの各コンポーネントが意図した成果物を生成することをテストします。
- パイプラインコンポーネント全体でのテストをします。
継続的デリバリー
このレベルでは、システムは新しいパイプラインの実装をターゲット環境に継続的デリバリーを行い、その結果、新しくトレーニングモデルの本番サービスを次々にデリバリします。パイプラインとモデルを迅速かつ信頼性の高い形で継続的デリバリーするために、以下のことを考慮する必要があります。
- モデルをデプロイする前に、デプロイ対象の環境のインフラとモデルの互換性を検証します。
例えば、モデルが必要とするパッケージが提供環境にインストールされているか、
メモリ、コンピューティング、アクセラレータのリソースが利用可能かどうかを確認する必要があります。 - 予測サービスをテストするには、期待される入力で予測サービスのAPIを呼び出し、
期待されるレスポンスが得られることを確認します。
このテストでは、通常、モデルのバージョンを更新して、
異なる入力を期待したときに発生するかもしれない問題を見つけます。 - 予測サービスのパフォーマンステストを行います、
これには、秒あたりのクエリ(queries per seconds（QPS）)
やモデルのレイテンシなどの性能指標を計測するために、サービスの負荷テストを行うことが含まれます - 再トレーニングまたはバッチ処理での予測のためにデータを検証します。
- モデルがデプロイされる前に、予測性能の目標を満たしているかどうかを検証します。
- テスト環境への自動デプロイできるようにします、 たとえば、
コードを開発ブランチにコードをプッシュすることをトリガーとしてデプロイできるようにします。 - 本番前環境(pre-production environment)への半自動デプロイできるようにします、たとえば、
レビュー担当者が変更を承認した後にコードをマスターブランチにマージすることをトリガーとして
デプロイできるようにします。 - 本番前環境(pre-production environment)でパイプラインを数回正常に実行した後に、
本番環境への手動デプロイします。
要約すると、本番環境にMLを実装することは、モデルを予測用のAPIとしてデプロイするだけではありません。むしろ、新しいモデルの再トレーニングとデプロイを自動化できるMLパイプラインをデプロイすることを意味します。CI/CDシステムを構築することで、新しいパイプラインの実装を自動的にテストしてデプロイすることが可能になります。このシステムを利用することで、データやビジネス環境の急激な変化に対応することができます。すぐにすべてのプロセスをあるレベルから別のレベルに移動させる必要はありません。これらのプラクティスを徐々に導入することで、MLシステムの開発環境と本番環境の自動化を推進することができます。
What's next
- KubeflowとCloud Buildを利用したCI/CDとMLパイプラインのアーキテクチャ について学んでください。
-
Cloud Buildを使用したGitOpsスタイルの継続的デリバリー について学んでください。
データ処理ワークフロー用のCI / CDパイプラインの設定 にういて学んでください。 - YouTube でGoogle Cloudを利用したMLOpsベストプラクティス （Cloud Next '19） をご覧ください。
- 他のGoogle Cloudの機能を自分で試してみてください。チュートリアル を見てください。
翻訳箇所は以上となります。
長い文章を読んでいただきありがとうございました。
訳注5でのリンク先の翻訳
Training-Serving Skew
トレーニング時とサービス提供時の歪み(Training-Serving Skew)は、
トレーニング中のパフォーマンスとサービス提供時の間でのパフォーマンスの差異です。
この歪みは次のような場合に発生します。
- トレーニング時のパイプラインとサービス提供時のパイプラインでデータの扱い方が不一致。
- トレーニング時とサービス提供時でデータの変化。
- モデルとアルゴリズム間でのフィードバック・ループ。
Googleでは、Training-Serving Skewがパフォーマンスに悪影響を与える
本番の機械学習システムをずっと観察してきました。
最良の解決策は、システムやデータの変更が気づかないうちに歪みが入り込まないように、
明示的に監視することです。)