TFX、Kubeflow Pipelines、Cloud Build を使用した MLOps のアーキテクチャ

このドキュメントでは、TensorFlow Extended(TFX)ライブラリを使用する機械学習(ML)システムの全体的なアーキテクチャについて説明します。また、Cloud BuildKubeflow Pipelines を使用して ML システムの継続的インテグレーション(CI)、継続的デリバリー(CD)、継続的トレーニング(CT)を設定する方法についても説明します。

このドキュメントでは、ML システムと ML パイプラインという用語は、モデルのスコアリングや予測パイプラインではなく、ML モデルのトレーニング パイプラインを指します。

このドキュメントは、CI / CD の方法論を適用して ML ソリューションを Google Cloud の本番環境へ移行し、ML パイプラインの品質、保守性、適応性を確保する必要があるデータ サイエンティストと ML エンジニアを対象としています。

このドキュメントでは、次のトピックについて説明します。

  • ML における CI / CD と自動化の理解
  • TFX を使用した統合 ML パイプラインの設計
  • Kubeflow Pipelines を使用した ML パイプラインのオーケストレーションと自動化
  • Cloud Build を使用した ML パイプライン用の CI / CD システムの設定

MLOps

ML システムを本番環境に統合するには、ML パイプラインのステップをオーケストレートする必要があります。さらに、モデルの継続的なトレーニングのためにパイプラインの実行を自動化する必要があります。新しいアイデアや機能をテストするには、パイプラインの新しい実装で CI / CD の方法論を採用する必要があります。次のセクションでは、ML における CI / CD と CT の概要を説明します。

ML パイプラインの自動化

ユースケースによっては、ML モデルのトレーニング、検証、デプロイの手動プロセスで十分な場合もあります。この手動アプローチは、チームが、再トレーニングされていない、または頻繁に変更されていない ML モデルを少数しか管理していない場合に機能します。しかし実際のモデルは、環境のダイナミクスやダイナミクスを記述するデータの変更に適応しないため、現実世界にデプロイするとしばしばブレイクダウンします。

ML システムを変更に適応させるには、次の MLOps 手法を適用する必要があります。

  • ML パイプラインの実行を自動化して、新しいデータで新しいモデルを再トレーニングし、新しいパターンをキャプチャします。CT については、このドキュメントの後半の Kubeflow Pipelines を使用した ML のセクションで説明します。
  • ML パイプライン全体の新たな実装を繰り返しデプロイするには、継続的デリバリー システムを設定します。CI / CD については、後述の Google Cloud での ML の CI / CD 設定のセクションで説明します。

ML の本番環境のパイプラインを自動化して、新しいデータでモデルを再トレーニングできます。パイプラインは、オンデマンド、スケジュール、新しいデータの可用性、モデルのパフォーマンス低下、データの統計的特性の大幅な変更、または他の条件に基づいてトリガーできます。

CI / CD パイプラインと CT パイプラインの比較

新しいデータが利用可能になることは、ML モデルが再トレーニングされる 1 つのトリガーです。ML パイプラインが再実行されるもう 1 つの重要なトリガーは、ML パイプラインの新しい実装(新しいモデル アーキテクチャ、特徴量エンジニアリング、ハイパーパラメータなど)が利用可能になることです。ML パイプラインのこの新しい実装は、モデル予測サービスの新しいバージョン(オンライン サービス用の REST API を備えたマイクロ サービスなど)として機能します。2 つのケースの違いは次のとおりです。

  • 新しいデータを使用して新しい ML モデルをトレーニングするために、以前にデプロイされた CT パイプラインが実行されます。新しいパイプラインやコンポーネントはデプロイされません。新しい予測サービスや新しくトレーニングされたモデルのみがパイプラインの最後に提供されます。
  • 新しい ML モデルを新しい実装でトレーニングするには、CI / CD パイプラインを介して新しいパイプラインをデプロイします。

新しい ML パイプラインを迅速にデプロイするには、CI / CD パイプラインを設定する必要があります。このパイプラインにより、さまざまな環境(開発、テスト、ステージング、本番環境移行前、カナリア、本番環境など)で新しい実装が利用可能になったときに、新しい ML パイプラインとコンポーネントが自動的にデプロイされます。

次の図は、CI / CD パイプラインと ML CT パイプラインの関係を示しています。

CI / CD パイプラインの出力は、CT パイプラインです。

図 1: CI / CD および ML CT パイプライン。

これらのパイプラインの出力は次のとおりです。

  • 新しい実装の場合、CI / CD パイプラインが成功すると、新しい ML CT パイプラインがデプロイされます。
  • 新しいデータの場合、CT パイプラインが成功すると、新しいモデル予測サービスが提供されます。

TFX ベースの ML システムの設計

以下のセクションでは、TensorFlow Extension(TFX)を使用して ML システム用の CI / CD パイプラインを設定する統合 ML システムを設計する方法について説明します。ML モデルをビルドするためのフレームワークはいくつかありますが、TFX は、本番環境の ML システムを開発およびデプロイするための統合 ML プラットフォームです。TFX パイプラインは、ML システムを実装する一連のコンポーネントです。この TFX パイプラインは、スケーラブルで高性能な ML タスク用に設計されています。これらのタスクには、モデリング、トレーニング、検証、推論の提供、デプロイの管理が含まれます。TFX の主なライブラリは次のとおりです。

TFX ML システムの概要

次の図は、さまざまな TFX ライブラリを統合して ML システムを構成する方法を示しています。

TFX ベースの ML システムのステップ。

図 2. 典型的な TFX ベースの ML システム。

図 2 は、典型的な TFX ベースの ML システムを示しています。次のステップは、手動で、または自動パイプラインで実行できます。

  1. データ抽出: 最初のステップは、データソースから新しいトレーニング データを抽出することです。このステップの出力は、モデルのトレーニングと評価に使用されるデータファイルです。
  2. データの検証: TFDV では、予想される(未加工の)データスキーマに基づいてデータが検証されます。データスキーマは、システムのデプロイ前に開発フェーズで作成、修正されます。データの検証のステップでは、データの分散とスキーマのスキューの両方に関連する異常が検出されます。このステップの出力は、異常値(ある場合)、および下流のステップを実行するかどうかの決定です。
  3. データ変換: データは検証後に分割され、ML タスク用の準備として、TFT を使用してデータ変換と特徴量エンジニアリングのオペレーションが実行されます。このステップの出力は、モデルをトレーニングして評価するためのデータファイルで、通常は TFRecords 形式に変換されます。さらに、生成された変換アーティファクトは、モデル入力の構築とトレーニング後の保存されたモデルのエクスポートに役立ちます。
  4. モデルのトレーニングと調整: ML モデルを実装してトレーニングするには、前のステップで生成された変換済みデータで、tf.estimator または tf.Keras API を使用します。最適なモデルにつながるパラメータ設定を選択するには、Keras 用のハイパーパラメータ調整ライブラリである Keras tuner や、Katib などの他のサービスを使用します。このステップの出力は、評価に使用される保存済みモデルと、予測用のモデルのオンライン サービスに使用される別の保存済みモデルです。
  5. モデルの評価と検証: トレーニング ステップの後にエクスポートされたモデルは、テスト データセットで評価され、TFMA を使用してモデルの品質が評価されます。TFMA では、モデルの品質全体が評価され、データモデルのどの部分が実行されていないかが特定されます。この評価により、モデルが品質基準を満たしている場合にのみサービスに利用されることが保証されます。品質基準には、さまざまなデータ サブセット(ユーザー属性やロケーションなど)での適正なパフォーマンスや、以前のモデルやベンチマーク モデルと比較して向上されたパフォーマンスなどがあります。このステップの出力は、一連のパフォーマンス指標と、モデルを本番環境にプロモートするかどうかの決定です
  6. 予測用モデルの提供: 新しくトレーニングされたモデルが検証されると、TensorFlow サービスを使用してオンライン予測に対応するマイクロサービスとしてデプロイされます。このステップの出力は、トレーニングされた ML モデルのデプロイされた予測サービスです。モデル レジストリにトレーニングしたモデルを保存することで、このステップを置き換えることができます。その後、別個のモデル提供 CI / CD プロセスが起動します。

TFX ライブラリの使用方法を示すチュートリアルについては、TensorFlow Extended(TFX)を使用した ML を参照してください。

Google Cloud 上の TFX ML システム

本番環境では、システムのコンポーネントは信頼性の高いプラットフォーム上で大規模に実行する必要があります。次の図は、TFX ML パイプラインの各ステップが Google Cloud のマネージド サービスを使用して実行される方法を示しています。これにより、大規模環境でのアジリティ、信頼性、パフォーマンスが確保されます。

Google Cloud 上の TFX ベースの ML システムのステップ

図 3. Google Cloud 上の TFX ベースの ML システム

次の表に、図 3 に示す主要な Google Cloud サービスを示します。

ステップ TFX ライブラリ Google Cloud サービス
データ抽出と検証 TensorFlow のデータ検証 データフロー
データの変換 TensorFlow 変換 データフロー
モデルのトレーニングと調整 TensorFlow AI Platform Training
モデルの評価と検証 TensorFlow Model Analysis データフロー
予測のためのモデル提供 TensorFlow サービスの提供 AI Platform Prediction
モデル アーティファクトのストレージ NA AI Hub
  • Dataflow は、Apache Beam パイプラインを Google Cloud 上で大規模に実行するための、フルマネージド、サーバーレスで信頼性の高いサービスです。Dataflow は、次のプロセスのスケーリングに使用されます。

    • 統計を計算して、受信データを検証する。
    • データの準備と変換を行う。
    • 大規模なデータセットでモデルを評価する。
    • 評価データセットのさまざまな側面で指標を計算する。
  • Cloud Storage は、バイナリラージ オブジェクトを格納する可用性と耐久性に優れたストレージです。Cloud Storage は、ML パイプラインの実行中に生成された次のようなアーティファクトをホストします。

    • データの異常(ある場合)
    • 変換されたデータとアーティファクト
    • エクスポート済み(トレーニング済み)のモデル
    • モデル評価の指標
  • AI Hub は、人工知能(AI)と ML アセットを検出、共有、再利用するためのエンタープライズ クラスのホスト型リポジトリです。トレーニングと検証を終えているモデルと関連するメタデータを保存するには、AI Hub をモデル レジストリとして使用します。

  • AI Platform は、大規模な ML モデルのトレーニングと提供を行うマネージド サービスです。AI Platform Training は、TensorFlow、Scikit-learnXGboost モデルをサポートするだけでなく、ユーザー指定のカスタム コンテナを使用して任意のフレームワークで実装されたモデルをサポートします。また、スケーラブルなベイズ最適化ベースのサービスを使用して、ハイパーパラメータ調整を行うこともできます。トレーニング済みモデルは、REST API を備えたマイクロサービスとして、AI Platform Prediction にデプロイできます。

Kubeflow Pipelines を使用した ML システムのオーケストレーション

このドキュメントでは、TFX ベースの ML システムの設計方法と、Google Cloud 上でシステムの各コンポーネントを大規模に実行する方法について説明します。ただし、システムのこれらの異なるコンポーネントを接続するにはオーケストレーターが必要です。オーケストレーターは、パイプラインを順番に実行し、定義した条件に基づいてステップ間を自動的に移動します。たとえば、評価指標が事前定義したしきい値を満たしている場合、定義した条件により、モデル評価ステップの後にモデル提供ステップを実行できます。ML パイプラインのオーケストレーションは、開発フェーズと本番環境フェーズの両方で役に立ちます。

  • 開発フェーズにおいて、データ サイエンティストは、各ステップを手動で実行する代わりに、オーケストレーションにより ML テストを実行できます。
  • 本番環境フェーズでは、オーケストレーションにより、スケジュールや特定のトリガー条件に基づいて、ML パイプラインの実行を自動化できます。

Kubeflow Pipelines を使用した ML

Kubeflow は、移植可能な ML ワークロードを開発して実行するための、オープンソースの Kubernetes フレームワークです。Kubeflow Pipelines は、ML システムの作成、オーケストレート、自動化を可能にする Kubeflow サービスです。システムの各コンポーネントは、Kubeflow、Google Cloud などのクラウド プラットフォームで実行できます。Kubeflow Pipelines プラットフォームは、以下で構成されています。

  • テスト、ジョブ、実行を管理およびトラックするためのユーザー インターフェース。
  • マルチステップ ML ワークフローをスケジュールするためのエンジン。Kubeflow Pipelines は、Argo を使用して、Kubernetes リソースをオーケストレートします。
  • パイプラインとコンポーネントを定義して操作するための Python SDK
  • Python SDK を使用してシステムを操作するためのノートブック。
  • 実行、モデル、データセット、その他のアーティファクトに関する情報を保存する ML メタデータ ストア。

Kubeflow Pipelines は、以下で構成されます。

  • 一連のコンテナ化された ML タスク、またはコンポーネント。パイプライン コンポーネントは、Docker イメージとしてパッケージ化された自己完結型のコードです。コンポーネントは、入力引数を受け取り、出力ファイルを生成し、パイプラインで 1 つのステップを実行します。

  • Python ドメイン固有の言語(DSL)で定義された ML タスクのシーケンスの仕様。ワークフローのトポロジは、上流ステップの出力を下流ステップの入力に接続することによって暗黙的に定義されます。パイプライン定義のステップは、パイプライン内のコンポーネントを呼び出します。複雑なパイプラインでのコンポーネントは、ループで複数回実行される場合や、条件付きで実行される場合があります。

  • パイプライン入力パラメータのセット。値はパイプラインのコンポーネントに渡されます。データのフィルタリング条件や、パイプラインが生成するアーティファクトの保存場所が含まれます。

次の図は、Kubeflow Pipelines のサンプルグラフを示しています。

Kubeflow Pipelines を使用した ML パイプラインのグラフ。

図 4. Kubeflow Pipelines のサンプルグラフ。

Kubeflow Pipelines のコンポーネント

パイプラインで呼び出すコンポーネントには、コンポーネント操作を作成する必要があります。component op を作成するには、次のメソッドを使用します。

  • 軽量の Python コンポーネントの実装: このコンポーネントでは、コードを変更するたびに新しいコンテナ イメージを作成する必要はなく、ノートブック環境での迅速なイテレーションを対象としています。kfp.components.func_to_container_op 関数を使用して、Python 関数から軽量コンポーネントを作成できます。

  • 再利用可能なコンポーネントの作成: この機能を使用するには、コンポーネントに、component.yaml ファイル内のコンポーネント仕様の 1 つを含める必要があります。コンポーネント仕様は、引数、実行する Docker コンテナ イメージ URL、および出力について、Kubeflow Pipelines へのコンポーネントを記述します。component op は、パイプラインのコンパイル中に Kubeflow Pipelines SDKComponentStore.load_components 関数を使用して、component.yaml ファイルから自動的に作成されます。再利用可能な component.yaml 仕様を AI Hub と共有して、さまざまな Kubeflow Pipelines プロジェクトでのコンポーザビリティを実現します。

  • 事前定義された Google Cloud コンポーネントの使用: Kubeflow Pipelines は、必須パラメータを指定することで、Google Cloud でさまざまなマネージド サービスを実行する事前定義されたコンポーネントを提供します。これらのコンポーネントは、BigQueryDataflowDataprocAI Platform などのサービスを使用したタスクの実行に役立ちます。これらの事前定義された Google Cloud コンポーネントは、AI Hub でも利用できます。再利用可能なコンポーネントを使用する場合と同様に、これらの component op は、ComponentStore.load_components を通じて事前定義されたコンポーネント仕様から自動的に作成されます。その他の事前定義されたコンポーネントは、Kubeflow などのプラットフォームでジョブを実行するために使用できます。

TFX パイプライン DSLTFX コンポーネントも使用できます。TFX コンポーネントは、メタデータ機能をカプセル化します。ドライバは、メタデータ ストアにクエリを実行してエグゼキュータにメタデータを提供します。パブリッシャーはエグゼキュータの結果を受け入れ、メタデータに保存します。メタデータと同じように統合されるカスタム コンポーネントを実装することもできます。TFX は、パイプラインの Python コードを YAML ファイルにコンパイルし、Argo ワークフローを記述するコマンドライン インターフェース(CLI)を提供します。その後、Kubeflow Pipelines にファイルを送信できます。

次の図は、Kubeflow Pipelines で、コンテナ化されたタスクが、BigQuery ジョブ、AI Platform(分散)トレーニング ジョブ、Dataflow ジョブなどの他のサービスを呼び出す方法を示しています。

Google Cloud での Kubeflow Pipelines のアーキテクチャ。

図 5. Kubeflow Pipelines と Google Cloud マネージド サービスを使用した ML パイプライン。

Kubeflow Pipelines を使用すると、必要な Google Cloud サービスを実行して、本番環境の ML パイプラインのオーケストレートと自動化ができます。図 5 では、Cloud SQL が、Kubeflow Pipelines の ML メタデータ ストアとして機能しています。

Kubeflow Pipelines コンポーネントは、Google Cloud での TFX 関連サービスの実行に限定されません。SparkML ジョブの DataprocAutoML、その他のコンピューティング ワークロードなどの、データ関連サービスとコンピューティング関連のサービスを実行できます。

Kubeflow Pipelines でのタスクのコンテナ化には、次の利点があります。

  • 実行環境とコード ランタイムを分離します。
  • テストの対象は本番環境で同じなため、開発環境と本番環境の間でコードの再現性があります。
  • パイプライン内の各コンポーネントを分離します。それぞれに異なるバージョンのランタイム、異なる言語、異なるライブラリがあります。
  • 複雑なパイプラインの構成に役立ちます。
  • ML メタデータ ストアと統合して、トレーサビリティと再現性を実現します。

Kubeflow Pipelines の概要と TFX ライブラリの例については、Kubeflow Pipelines スタートガイドのブログ投稿をご覧ください。

Kubeflow Pipelines のトリガーとスケジューリング

Kubeflow Pipelines を本番環境にデプロイするには、ML パイプラインの自動化セクションで説明したシナリオに応じて、実行を自動化する必要があります。

Kubeflow Pipelines は、パイプラインをプログラムで操作するための Python SDK を提供します。kfp.Client クラスには、テストを作成し、パイプラインをデプロイし実行するための API が含まれています。Kubeflow Pipelines SDK を使用すると、次のサービスを使用して、Kubeflow Pipelines を呼び出すことができます。

  • Cloud Scheduler を使用したスケジュール。
  • Pub/SubCloud Functions を使用したイベントへの応答。イベントは、たとえば、Cloud Storage バケット内の新しいデータファイルが利用可能になる場合などです。
  • Cloud Composer または Cloud Data Fusion を使用した大規模なデータとプロセスのワークフローの一部。

Kubeflow Pipelines には、定期的なパイプライン用のスケジューラも組み込まれています。

Google Cloud での ML 用 CI / CD の設定

Kubeflow Pipelines を使用すると、データの前処理、モデルのトレーニングと評価、モデルのデプロイなどの複数のステップを含む ML システムをオーケストレートできます。データ サイエンスの探索フェーズで、Kubeflow Pipelines はシステム全体の迅速なテストに役立ちます。本番環境フェーズでは、Kubeflow Pipelines を使用して、ML モデルをトレーニングまたは再トレーニングする新しいデータに基づいて、パイプラインの実行を自動化できます。

CI / CD アーキテクチャ

次の図は、Kubeflow Pipelines を使用した ML の CI / CD の概要を示しています。

Kubeflow Pipelines を使用した ML パイプライン用の CI / CD のアーキテクチャ。

図 6: Kubeflow Pipelines の CI / CD の概要。

このアーキテクチャの中核となるのは、Cloud Build インフラストラクチャです。Cloud Build は、Cloud Source RepositoriesGitHubBitbucket からソースをインポートして、仕様に合わせてビルドを実行し、Docker コンテナや Python tar ファイルなどのアーティファクトを生成できます。

Cloud Build は、ビルド構成ファイルcloudbuild.yaml)で定義された一連のビルドステップとしてビルドを実行します。各ビルドステップは Docker コンテナで実行されます。Cloud Build が提供するサポート対象のビルドステップを使用するか、独自のビルドステップを作成できます。

ML システムに必要な CI / CD を実行する Cloud Build プロセスは、手動で、または自動ビルドトリガーで実行できます。トリガーは、ビルドソースに変更が push されるたびに、構成されたビルドステップを実行します。ビルドトリガーを設定して、ソース リポジトリへの変更時にビルドルーチンを実行するか、変更が特定の条件に一致したときにのみビルドルーチンを実行できます。

さらに、さまざまなトリガーに応じて実行されるビルドルーチン(Cloud Build 構成ファイル)を使用できます。たとえば、次のように設定できます。

  • ビルドルーチンは、開発ブランチに対して commit が行われると開始されます。
  • ビルドルーチンは、マスター ブランチに対して commit が行われると開始されます。

構成変数の置換を使用して、ビルド時に環境変数を定義できます。これらの置換は、トリガーされたビルドからキャプチャされます。これらの変数には、$COMMIT_SHA$REPO_NAME$BRANCE_NAME$TAG_NAME$REVISION_ID があります。他の非トリガーベースの変数は、$PROJECT_ID$BUILD_ID です。置換はビルド時まで値が不明な変数を設定する場合や、既存のビルド リクエストを別の変数値で再利用する場合に役立ちます。

CI / CD ワークフローのユースケース

通常、ソースコード リポジトリには次の項目が含まれます。

  • Kubeflow Pipelines のコンポーネントを実装するための Python ソースコード。データ検証、データ変換、モデル トレーニング、モデル評価、モデル提供などを行います。
  • コンポーネントに実装されたメソッドをテストする Python 単体テスト。
  • Docker コンテナ イメージを作成するために必要な Dockerfile(Kubeflow Pipelines コンポーネントごとに 1 つ)。
  • パイプラインのコンポーネント仕様を定義する component.yaml ファイル。この仕様は、パイプライン定義コンポーネント操作を生成するために使用されます。
  • Kubeflow Pipelines ワークフローが定義されている Python モジュール(pipeline.py モジュールなど)。
  • その他のスクリプトと構成ファイル(cloudbuild.yaml ファイルを含む)。
  • 探索的データ分析、モデル分析、モデルのインタラクティブなテストに使用されるノートブック。
  • パイプライン入力パラメータの構成を含む設定ファイル(settings.yaml ファイルなど)。

次の例では、デベロッパーがデータ サイエンス環境から開発ブランチにソースコードを push すると、ビルドルーチンがトリガーされます。

ビルドステップの例。

図 7. Cloud Build で実行されるビルドステップの例

図 7 に示すように、Cloud Build は次のビルドステップを実行します。

  1. ソースコード リポジトリが、Cloud Build ランタイム環境の /workspace ディレクトリにコピーされます。
  2. 単体テストが実行されます。
  3. (省略可)Pylint などの静的コード分析が実行されます。
  4. テストが合格すると、Docker コンテナ イメージが、Kubeflow Piplelines のコンポーネントごとに 1 つビルドされます。イメージには $COMMIT_SHA パラメータがタグ付けされます。
  5. Docker コンテナ イメージは、Container Registry にアップロードされます。
  6. イメージの URL は、component.yaml ファイルで Docker コンテナ イメージが作成されタグ付けされるたびに更新されます。
  7. Kubeflow Pipelines ワークフローがコンパイルされ、workflow.tar.gz ファイルが生成されます。
  8. workflow.tar.gz ファイルが、Cloud Storage にアップロードされます。
  9. コンパイルされたパイプラインは Kubeflow Pipelines にデプロイされます。これには次のステップが含まれます。
    1. settings.yaml ファイルからパイプライン パラメータを読み取ります。
    2. テストを作成します(または既存のテストを使用します)。
    3. パイプラインを Kubeflow Pipelines にデプロイします(パイプラインの名前を特定のバージョンにタグ付けします)。
  10. (省略可)統合テストまたは本番環境での実行の一部としてパラメータ値を使用してパイプラインを実行します。実行されたパイプラインは最終的に、AI Platform 上の API としてのモデルをデプロイします。

これらのステップの大部分をカバーする包括的な Cloud Build の例については、Kubeflow Piplelines と Cloud Build を使用したシンプルな CI と CD の例を参照してください。

その他の考慮事項

Google Cloud で ML CI / CD アーキテクチャを設定する場合は、次の点を考慮してください。

  • データ サイエンス環境では、ローカルマシンまたはディープ ラーニング VM(DLVM)に基づく Notebooks インスタンスを使用できます。
  • 自動化された Cloud Build パイプラインは、ドキュメント ファイルのみが編集された場合やテストのノートブックが変更された場合などに、skip triggers に構成できます。
  • 統合テストと回帰テスト用のパイプラインはビルドテストとして実行できます。パイプラインをターゲット環境にデプロイする前に、wait_for_pipeline_completion メソッドを使用して、サンプル データセットでパイプラインを実行し、パイプラインをテストできます。
  • Cloud Build を使用する代わりに、Jenkins などの他のビルドシステムを使用することもできます。Jenkins のすぐに使えるデプロイは、Google Cloud Marketplace で使用可能です。
  • さまざまなトリガーに基づいて、開発、テスト、ステージングなどのさまざまな環境に自動的にデプロイするようにパイプラインを構成できます。また、通常はリリース承認後に、本番環境移行前や本番環境など、特定の環境に手動でのデプロイができます。異なるトリガーやターゲット環境ごとに、複数のビルドルーチンを作成できます。
  • 汎用のワークフローとして、一般的なオーケストレーションとスケジューリングのフレームワークである Apache Airflow を使用できます。これは、フルマネージドの Cloud Composer サービスを使用して実行できます。Cloud Composer と Cloud Build でデータ パイプラインをオーケストレートする方法の詳細については、データ処理ワークフロー用の CI / CD パイプラインの設定をご覧ください。
  • 新しいバージョンのモデルを本番環境にデプロイする場合は、カナリア リリースとしてデプロイして、パフォーマンス(CPU、メモリ、ディスク使用状況)を確認します。すべてのライブ トラフィックを処理する新しいモデルを構成する前に、A/B テストを実行することもできます。ライブ トラフィックの 10%~20% を提供する新しいモデルを構成します。新しいモデルのパフォーマンスが現在のモデルよりも優れている場合は、すべてのトラフィックを処理するように新しいモデルを構成できます。それ以外の場合、サービス システムは現在のモデルにロールバックします。

次のステップ