こんにちは、技術本部 データシステム部 MLOpsブロックの平田（@TrsNium）です。約2年半ぶりの執筆となる今回の記事では、MLOps向け基盤を「Kubeflow Pipelines」から「Vertex Pieplines」へ移行して運用コストを削減した取り組みを紹介します。

弊社ではML（Machine Learning）のモデル生成や特徴量生成にGKE（Google Kubernetes Engine）上でセルフホストしたKubeflow Pipelinesを使用していました。しかし、構築・運用コストが大きすぎるという課題感がありました。具体的にはKubeflowの依存するIstioやKubernetes Applicationsのバージョンが古く、Kubernetesクラスタのバージョンアップデートをできなかったり、Kubeflowの内部ステートを保持しているMySQLが実際のステートと一致しない状況が発生していました。

詳しくは、中山（@Civitaspo）が過去の記事「KubeflowによるMLOps基盤構築から得られた知見と課題」で、構築や運用に関する課題感を紹介しているので、併せてご覧ください。

このような運用課題へアプローチしていたところ、Google I/O 2021でVertex AIの発表がありました。その後、Vertex AIのコンポーネントの1つであるVertex Pipelinesを調査し、Kubeflow Pipelinesの恩恵を享受しつつ運用コストを大幅に削減できる確信が得られたため、Kubeflow PipelinesからVertex Pipelinesへの移行を開始しました。

Vertex Pipelinesとは

Vertex Pipelinesは、GCPが提供しているKubeflow Pipelinesのフルマネージドサービスです。似たサービスにCloud AI Platform Pipelinesがありますが、明確に違いがあります。

Cloud AI Platform PipelinesではKubeflow PipelinesをGKEやCloud SQLをプロビジョニングして構築するのに対し、Vertex Pipelinesでは構築が不要です1。これにより、GKEやCloud SQLを管理する必要がなくなります。また、ワークフローが動いてない間の待機時間はCloud AI Platform PipelinesではGKEやCloud SQLの料金が必要なのに対し、Vertex Pipelinesではそれらの料金が発生しません。

つまり、構築や運用コストの面でKubeflow PipelinesやCloud AI Platform Pipelinesと比べ、Vertex Pipelinesには大きなアドバンテージがあります。

また、2つ目の違いは、Kubeflow PipelinesのSDK（kfp）のバージョンが異なる点です。Cloud AI Platform Pipelinesや、私たちがこれまで利用していたKubeflow PipelinesではSDKのバージョンがV1だったのに対し、Vertex PipelinesではV2です。なお、Kubeflow Pipelines 1.6以上のバージョンであればSDK V1はSDK V2と互換性がありますが、それ以外はありません。

Vertex Pipelinesへの移行

本章では、Kubeflow PipelinesからVertex Pipelinesへの移行の流れを説明します。

移行前に運用していたKubeflow Pipelinesのバージョンが1.2であり、SDK V2との互換性がないため、SDK V2でワークフローを記述し直す必要がありました。また、Kubeflow Pipelinesは、AWS（Amazon Web Services）やGCP、オンプレミス等で動作するようにKubernetesの様々な機能を駆使して設計されています。

一方、Vertex Pipelinesでは、それらの機能をGCPのサービスに置き換えているため、ワークフロー実行時の挙動が異なることがあります。提供されて間もないサービスなこともあり、Cloud Monitoringで取得可能なメトリクスが多くなく、ワークフローを外部から監視できる仕組みがありません。

これらの課題に対し、移行時にどのように解決していったのか、説明します。

Vertex Pipelinesへ移行するワークフロー

Vertex Pipelinesへ移行するワークフローは、WEARユーザーのコーディネート画像からアイテム特徴量を抽出し、Firestoreへそれを保存するような処理を行っています。対象のコーディネート画像が3000万件以上と膨大にあるため、日次の差分で処理をしています。

下図がワークフローの全体像です。

このワークフローでは、日次の差分データを取得するためにデータ基盤チームが管理するBigQueryからコーディネート情報を全件取得し、前日の全件取得との差分から新規コーディネート情報を一覧化しています。このコーディネート情報には、ユーザーの情報とコーディネート画像のURLが含まれています。

そして、コーディネート画像はAmazon S3に保存されていますが、データ基盤にはCDN経由のURLを格納しているため、S3へ直接取得するためのパス情報がありません。また、S3から直接画像を取得する料金と、CDN経由で画像をダウンロードする料金にさほど差がないため、CDN経由で画像を取得するようにしています。ただし、CDNに大量のリクエストを送ることになるので、DDoSと誤判定されないように固定の外部アドレスを使用しアクセスします。

上記の要件を満たすようにVertex Pipelinesへ移行した結果、ワークフローは以下の構成になりました。

続きはこちら