Wayfair、サプライ チェーン サイエンスに MLOps ツールとプロセスを導入

※この投稿は米国時間 2023 年 8 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

前回のブログ投稿では、Wayfair の MLOps のビジョンと、データ サイエンスと ML を担当する部門内で Vertex AI を使用してそのビジョンを実現した方法をご紹介しました。それを支えたのは、社内開発のツールと最新の MLOps プロセスでした。また、Vertex AI を活用するために構築した共有 Python ライブラリを含む MLOps のリファレンス アーキテクチャと、Vertex AI ソリューションの継続的な構築およびデプロイを支援する CI / CD アーキテクチャについてもお伝えしました。

今回のブログ投稿では、影響力の大きい実際のプロジェクトに前述のツールとプロセスをどのように適用したのかをご説明します。具体的には、サプライ チェーン サイエンス チーム内でプラットフォーム再構築に取り組むことで、古い技術に起因する問題を解決し、技術スタックとプロセスをモダナイズしました。

当社のサプライ チェーン サイエンス チームは、お届け日数の予測、インシデント対応費用の予測、サプライ チェーンのシミュレーションなど、最高レベルのカスタマー エクスペリエンスをもたらすさまざまなユースケース向けの予測機能を実現するために、ML を活用した複数のプロジェクトに取り組んでいます。特に力を入れているのがお届け日数予測プロジェクトで、ML を活用して商品がサプライヤーからお客様に届くまでにかかる時間を予測することを目指しています。

このプロジェクトを Vertex AI に移行したのはやや遅い段階でしたが、ML モデルのさらに迅速な開発を実現するうえで Vertex AI は重要な役割を果たすことがわかりました。また、メンテナンスにかかる労力が大幅に削減され、データの取り込み、モデルのトレーニング、モデルの推論など、中核的なシステムの信頼性が向上しました。

世界水準の ML モデルを構築するサイエンティストを支援

Wayfair のデータ サイエンティストは、ノートブック環境でのアドホックのデータ分析とテストの実施に加え、最も重要な業務としてモデル、テスト、データ パイプラインのオーケストレーションも行っています。従来、オーケストレーションは、社内の全データ サイエンス チーム間で共有された中央の自己ホスト型 Apache Airflow サーバーで処理されていました。この方式では、時間のかかるデリバリー プロセスやノイジー ネイバーなどの複数の問題が発生していたため、サイエンティストは ML モデルの構築ではなくこれらの問題への対処に膨大な時間を割かねばなりませんでした。

この問題を緩和すると同時に新機能を導入するために、オーケストレーションを目的として Kubeflow ベースの Vertex AI Pipelines に移行ました。また、ユーザビリティを改善し既存のシステムと問題なく統合できる社内ツールを Vertex AI 上に構築して活用しました。データの取り込み、モデルのトレーニング、モデルの評価、モデルの推論などのチームのすべてのパイプラインを Vertex AI Pipelines に移行する一方で、Kubeflow の機能を活用してカスタム コンポーネントを作成し、パイプライン間で共有しました。これにより、チーム内で一元的に共通業務用のカスタム コンポーネントを構築して管理し、それらのコンポーネントを使用してパイプラインを組み立てることができるようになりました。たとえるなら、レゴの箱を取り出し、同じブロックをそれぞれが創造的な方法で組み立てて素晴らしい作品の数々を完成させるようなものです。このように共通のパイプライン コンポーネントを確立して再利用することで、効果的にコードの重複を削減し、保守性を改善し、さまざまなプロジェクトやチーム間での連携を強化できました。

Vertex AI Pipelines に移行したことで、サイエンティストが古い Airflow ベースのソリューションで直面していた、時間のかかる手動のリリース プロセスという最大の課題が解決されました。チームのサイエンティストは、共有の「monorepo」でプロセスを進めるのではなく、リリースを自律的に管理できるようになりました。承認とその後のマージが済んだリリースに対して、lint チェック、テスト、コンパイル、デプロイが自動的に行われます。これによって価値創出までの時間が大幅に短縮され、非常に高速なイテレーション サイクルが実現しました。さらに、Vertex AI Pipelines の実行環境は独立しているため安定性と信頼性に優れ、パイプライン間でコンピューティング インフラストラクチャを共有する一元的な古いソリューションでよく発生していたノイジー ネイバーの問題を回避できます。

また、当社はこれを好機と捉え、プロジェクトに固有のニーズを収集して全社で汎用ツールに改良を加えました。たとえば、リポジトリあたり 1 つの Vertex AI パイプラインを用意するのではなく、Vertex AI で活用しているものと同じ CI / CD 機能を使って 1 つのモデル リポジトリ内ですべてのプロジェクトのパイプラインを一元的に管理するようにしました。

当社のお届け日数予測プロジェクトに固有のもう一つの問題は、システムのコンポーネント間でバージョニング基準が異なることに起因する、トレーサビリティと再現性の欠如でした。パイプライン コードのどのバージョンでモデルコードのどのバージョンが実行され、どのモデル アーティファクト セットが生成されたかを追跡することは本質的に不可能でした。Vertex AI Pipelines を利用して「統合セマンティック バージョニング」のコンセプトを導入することで、この根本的な問題を解決できました。プロジェクト内で異なるバージョニング基準を使用する（またはまったく使用しない）のではなく、すべてのコードとすべてのアーティファクトで一貫したバージョニングを行い、同じセマンティック バージョンが共有されるようにしました。コードとアーティファクトの間に明確なリンクが作成されるため、詳細な変更ログと組み合わせることで、それらを遡って任意の時点におけるシステムの状態を確信をもって推測できます。

統合セマンティック バージョニングを実現できたのは、そもそも Vertex AI Pipelines が継続的インテグレーションや継続的デリバリーなどの MLOps プロセスとの適合性を備えていたためです。つまり、パイプライン定義、コンポーネント、ベースイメージの組み合わせが 1 つの JSON アーティファクトにコンパイルされたものを簡単に CI / CD ワークフローに統合できるのです。

最後に、プラットフォーム再構築の一環として、その他のアーキテクチャ変更をいくつか行い、ベスト プラクティスを導入しました。たとえば、デプロイ環境と本番環境を明確に分離する、一般化可能なモジュールを切り離してチーム全体で共有されたリポジトリに保管するなどです。

学んだ教訓

技術的な観点から言えば、最終的に Wayfair の MLOps 機能を拡張して 1 つのプロジェクト リポジトリで複数の Vertex AI パイプラインに対応したということです。これにより、追加された構築済み Vertex AI Pipeline コンポーネントを社内の全員が使用できるようになり、すべてのコードとアーティファクトを統一された共通の方法でバージョニングすることで、トレーサビリティと再現性を核としたシステム アーキテクチャを実現できました。Vertex AI にプラットフォームを再構築することで当社のワークフローは大幅に効率化、強化され、サイエンティストはパイプラインとリリース プロセスを完全に自律的に管理できるようになりました。これによって、他のチームや外部プロセスに依存することがなくなり、チームのアジリティが改善されて価値創出までの時間が短縮されました。

MLOps のツールとベスト プラクティスを適用したことにより、チームに直接的な効果があっただけでなく、開発がさらに促進され、社内調達された全社規模のツールとプロセスを活用できるようになりました。その結果、できることが増え、Vertex AI による開発が進化しました。

当社は現在、この方向性を維持するために Vertex AI Feature Store のオンボーディングに取り組んでいます。これによってチームが特徴パイプラインとストレージを自律的に管理できるだけでなく、Model Registry やエンドポイントといったその他の Vertex AI サービスの評価を継続できます。

この移行がデータ サイエンティストの日々の業務に及ぼした影響について詳しくは、サプライ チェーン サイエンスにおける Vertex AI の活用に関する次回のブログ投稿で取り上げます。

- Wayfair、シニア ML エンジニア Christian Rehm 氏