True ML Talks #13 - ML Platform @ Cookpad

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
True ML Talksの新しいエピソードをお届けします。今回は、世界最大級のレシピサービスプラットフォームの一つであるCookpadのMLアーキテクチャを深く掘り下げます。また、成功する機械学習プラットフォームを構築する上での課題や、Nvidia Triton Inference Serverをどのように利用してモデルを実行しているかについても取り上げます。
今回お話しするのは Jose Navarro
JoseはCookpadのリードMLプラットフォームエンジニアとして、機械学習エンジニアやすべてのML実務者がMLシステムを迅速かつ確実に提供できるよう支援しています。
📌
Joseとの対談では、以下の点について取り上げます。
- CookpadにおけるMLチームの構成
- GPUベースのMLインフラストラクチャ
- Cookpadにおけるモデルの自動デプロイ
- オンライン推論のための特徴量ストアの統合と設定
- モデル実験中のデータソースと特徴量管理
- MLモデルの再学習のためのArgo Workflowsの利用
- Nvidia Triton Inference Serverとその利点
- MLflow Model RegistryとTriton Inference Serverの統合
- CookpadにおけるLLMと生成AIの活用
- ニーズに合わせたMLOpsアーキテクチャのカスタマイズ
全エピソードはこちらからご覧ください。
CookpadにおけるMLチームの構成
- 機械学習エンジニア: MLコアチームは、機械学習とソフトウェアエンジニアリングの両方に専門知識を持つエンジニアで構成されています。彼らは機械学習モデルの開発、トレーニング、デプロイを担当し、プロダクトチームと密接に連携しています。
- プラットフォームチーム: プラットフォームチームは、Kubernetesクラスターを含む基盤インフラストラクチャを管理し、MLエンジニアをサポートしています。彼らはMLシステムのスケーラビリティ、信頼性、パフォーマンスを保証します。さらに、ML開発プロセスを効率化するための内部ツールやフレームワークを開発・保守しています。
GPUベースのMLインフラストラクチャ
- クラウドベースのインフラストラクチャ: クックパッドはMLインフラストラクチャをクラウドで運用しており、主にAWSを使用し、一部のリソースはGCPに置いています。このインフラストラクチャは、クックパッドのグローバルなユーザーベースの規模と要求に対応できるように設計されています。
- データ処理と特徴量抽出: ユーザー生成コンテンツとアクションはKafkaを通じて取り込まれ、ストリーミングサービスで処理されます。特徴量は計算され、Amazon SageMaker Feature Storeに保存され、データウェアハウスとしてはAmazon Redshiftが使用されています。
- マイクロサービスアーキテクチャと推論レイヤー: クックパッドのMLプラットフォームは、Kubernetes上にデプロイされたマイクロサービスアーキテクチャで構築されています。前処理はマイクロサービス内で行われ、ML推論にはNvidia Inference Serverが使用されます。
- MLエンジニア向け実験プラットフォーム: クックパッドはMLエンジニア向けに実験プラットフォームを提供しており、データ探索とモデルトレーニングのためのJupyterサーバーが含まれます。実験の追跡とモデルレジストリにはMLflowが使用されています。
- モデルのデプロイと自動化: MLエンジニアはMLflowにモデルを登録し、自動化プロセスがNvidia Inference Server (Triton) 上でのモデルの変換とデプロイを処理します。
- GPUを多用するユースケース: クックパッドのGPUインフラストラクチャは、多言語モデルや画像エンベッダーなど、さまざまなモデルをサポートしています。多言語モデルは大規模なニューラルネットワークを利用し、画像エンベッダーは計算負荷が高いです。モデルはNvidia Triton Inference Serverを使用して、デフォルトでGPUにデプロイされます。
クックパッドにおけるモデルの自動デプロイ
- 実験用Jupyter Hub: クックパッドのMLエンジニアは、マネージドJupyter Hub環境にアクセスでき、そこで実験を行うことができます。チームは、実験目的でJupyter Hub内のさまざまなカーネルをサポートしています。
- MLflowへのモデル公開: MLエンジニアがモデルを開発し、満足のいく結果が得られたら、そのモデルをMLflowに公開できます。MLflowはモデルレジストリおよび実験追跡プラットフォームとして機能します。
- エンドツーエンドの自動化: クックパッドでは、モデルデプロイメントのためのエンドツーエンドの自動化パイプラインを導入しています。この自動化パイプラインは、MLflowモデルレジストリから引き継ぎ、モデルをデプロイプロセス全体にわたってシームレスに移行させます。
- サポートされているバックエンドフレームワーク: クックパッドの自動化パイプラインは、PyTorch、TensorFlow、ONNXを含む一部のバックエンドフレームワークをサポートしています。これらのフレームワークは、モデルを効果的に最適化し、デプロイするために利用されます。
- PyTorchとTensorFlowをデフォルトとする: クックパッドでは複数のバックエンドフレームワークをサポートしていますが、チームはモデルの開発とデプロイにおいてPyTorchとTensorFlowをデフォルトとして使用する傾向があります。これは、それらが広く使用されており、インフラストラクチャとの互換性が高いためです。
📌
MLflowとバックエンドサポートによるモデルの自動デプロイ:
クックパッドで機械学習エンジニアが実験を行う際、管理されたJupyterハブにアクセスでき、そこで実験を実行し、様々なカーネルを利用できます。モデルを開発したら、モデルレジストリとして機能するMLflowに公開します。そこから先は、プロセスが完全に自動化されます。
クックパッドの自動化パイプラインは、MLflowとTriton Inference Serverの両方と互換性のあるバックエンドのリストをサポートしています。サポートされているバックエンドには、PyTorch、TensorFlow、Onnxなどが含まれます。自動化パイプラインは、互換性に基づいて適切なバックエンドを活用し、登録されたモデルのデプロイを処理します。デプロイのデフォルトの選択肢は通常PyTorchまたはTensorFlowであり、Onnxは特定のニューラルネットワークの最適化に使用されます。
特徴量ストアの統合とオンライン推論のための設定
クックパッドでは、データサイエンティストは実験とオンライン推論の両方に特徴量ストアを利用しています。実験中は、モデルトレーニングのために既存の特徴量をオフラインでクエリできます。新しい特徴量を探索する際には、データウェアハウスからデータを取得し、変換して新しい特徴量を作成します。モデルのパフォーマンスに満足したら、データサイエンティストはリポジトリスキーマを通じて特徴量ストアに新しい特徴量グループを作成するだけです。
データはデータウェアハウスからKafkaを介して特徴量ストアに流れ、新しく作成された特徴量のストリーミングを可能にします。オンライン推論を可能にするために、データサイエンティストはストリーミングサービスを拡張し、関連するイベントを消費して変換を実行します。モデル登録時には、データサイエンティストはモデルの構造と使用される特徴量を指定し、変換コードは名前で特定の特徴量を取得するように設定されます。
特徴量ストア、データウェアハウス、およびストリーミングサービス間のこの統合は、オンライン推論プロセスへの特徴量のシームレスな組み込みを保証し、必要に応じて調整や更新を行う柔軟性を提供します。
モデル実験中のデータソースと特徴量管理
モデル実験中、クックパッドのデータサイエンティストにはデータソースに関して2つの選択肢があります。必要な特徴量がすでに特徴量ストアにある場合、オフラインで直接クエリできます。しかし、新しい特徴量を探索する際には、データウェアハウスにアクセスし、データを取得して、モデルのトレーニングに必要な変換を作成します。
新しい特徴量を特徴量ストアに組み込むのは簡単です。データサイエンティストは特徴量のスキーマ詳細を含むプルリクエスト(PR)を提出し、自動化によってAWSコールを使用して特徴量グループの作成が処理されます。データウェアハウスで使用されるデータはKafkaを介してストリーミングされ、新しく作成された特徴量でのオンライン推論を可能にします。既存のストリーミングサービスは、イベントを消費して変換を適用するように拡張され、特徴量ストアへの特徴量のストリーミングフローを保証します。
特徴量設定を維持するために、データサイエンティストはMLflowにモデルを登録する際に、関連情報を含めます。変換コードは特徴量ストアに直接アクセスし、設定を通じてデータサイエンティストは必要な特徴量名を指定します。この柔軟性により、必要に応じて特徴量設定を簡単に変更できます。
MLモデルの再学習にArgo Workflowsを活用する
クックパッドでは、再学習パイプラインをアーキテクチャに組み込むプロセスが現在進行中です。新しいML機能の迅速な反復に重点が置かれてきましたが、モデルを毎日または毎週置き換えたり再学習したりする成熟した再学習パイプラインの実装はまだ開発中です。クックパッドのレコメンデーションシステムはまだ初期段階にあり、反復的なアプローチにより、迅速な実験とABテストを通じたモデルの置き換えが可能になります。
Argo Workflowsを使用して再現可能なパイプラインを構築する可能性はあるものの、クックパッドは、この実装がまだ初期段階にあることを認識しています。まだ理想的なソリューションではなく、パイプラインの再現性は、彼らが積極的に取り組んでいる課題です。
より小さく、よりシンプルな実験から始め、重要なパイプラインコンポーネントを自動化することで、十分に検討されたアーキテクチャが可能になります。クックパッドは、推論の自動化が重要であると認識し、これを優先しました。今後は再学習パイプラインに注力する計画です。この体系的かつ段階的なプラットフォーム構築アプローチは、その手法の有効性を強調し、聴衆にとって貴重な学習経験となります。
最初からエンドツーエンドのシステムを構築しようとすると、不要なコンポーネントや不適切なコンポーネントが生じることがよくあります。彼は、再現可能なパイプラインのためにArgo Workflowsの代替案を検討することを提案しています。例えば、Pythonラッパーを使用したり、機械学習エンジニアのKubernetesマニフェストへの習熟度により合致し、CI/CDプラクティスによく適合する別のツールを使用したりすることです。
Nvidia Triton Inference Serverとその利点
- Triton Inference Server採用の決定: クックパッドは、Kubernetes内でGPU上で推論を実行する際の課題に対処するため、コストとビジネス価値のバランスを考慮しながら、コストとパフォーマンスを最適化する目的でTriton Inference Serverを選択しました。
- Triton Inference Serverの利点: Triton Inference Serverは、モデルを集約し、GPUリソースを共有し、リクエストをインテリジェントにルーティングすることで、コスト最適化を実現します。デフォルトでモデルをGPUにデプロイすることでパフォーマンスを向上させ、より高速な推論を可能にします。単一のコンフィグマップ行によるデプロイの簡素化と、シームレスなモデルの取得およびロードにより、MLエンジニアのユーザーエクスペリエンスを向上させます。
Nvidia Triton Inference Serverを活用することで、クックパッドはコスト最適化を実現し、モデル推論のパフォーマンスを向上させ、MLエンジニアのデプロイを簡素化します。
MLflow Model RegistryとTriton Inference Serverの統合
クックパッドは、大規模なモデルデプロイメントを効率化するため、MLflow Model RegistryとTriton Inference Serverを統合しました。その方法を以下に示します:
- MLflowモデルの保存: MLflowにモデルが登録されると、MLflowの慣例に基づいた特定のフォルダ構造でS3バケットに保存されます。モデルはTensorFlowまたはPyTorch形式で、それぞれ独自の構造を持っています。
- Tritonのモデル構造: Triton Inference Serverは、設定ファイルを含め、モデルをロードするために異なるフォルダ構造を期待します。この不一致のため、MLflowからTritonにモデルを移動するにはいくつかの調整が必要です。
- サイドカーのデプロイ: クックパッドは、Triton Inference Serverと並行してデプロイされるサイドカーコンポーネントを開発しました。この小さなPythonコンテナは、MLflow APIに毎分クエリを実行し、新しく登録されたモデルを特定します。また、Triton APIにもクエリを実行して、現在ロードされているモデルを確認します。
- モデルの集約: Tritonに存在しない新しいモデルをMLflowで検出すると、サイドカーはS3バケットからモデルファイルを取得します。必要なファイルの移動を行い、Tritonの要件に合うようにフォルダ構造を整えます。
- モデルのロード: サイドカーは、Tritonのボリューム内の適切なフォルダにモデルファイルを配置し、Triton APIを呼び出してモデルをロードします。これにより、サーバーの再起動や手動での介入なしに、モデルはTriton Inference Serverにシームレスにロードされます。
この統合を活用することで、クックパッドはMLflowからTriton Inference Serverへの効率的なモデルデプロイを実現し、進行中の推論操作を中断することなく、スケーラビリティと簡単な更新を可能にします。
クックパッドにおけるLLMと生成AIの活用
クックパッドは、プラットフォーム内での大規模言語モデル(LLM)および生成AI(Gen AI)技術の潜在的なユースケースとアプリケーションを積極的に模索しています。具体的な実装はまだ検討段階ですが、これらの技術を活用する可能性のある分野をいくつかご紹介します。
- レシピ作成の簡素化: クックパッドは、LLMを活用してユーザーがレシピを作成する際の障壁を下げることを目指しています。例えば、ユーザーはスマートフォンで音声認識アプリを使って、料理中にレシピの手順を口述できます。その転写データはLLMを介して整形されたレシピテキストを生成し、レシピを正確かつ効率的に記録する労力を削減します。
- スマートな食材認識: クックパッドは、生成AI機能を統合し、ユーザーが冷蔵庫やパントリーにある食材の写真を撮ってレシピの提案を問い合わせられるようにすることを構想しています。AIシステムは認識された食材を特定し、クックパッドの検索システムを使ってレシピの提案を提供します。
- レシピのアシスタンスとカスタマイズ: LLMを活用し、クックパッドはレシピのアシスタンスとカスタマイズを提供する機能の開発を計画しています。例えば、ユーザーは自分の好みや手持ちの食材に合わせて、食材の代替や変更をリクエストできます。LLMベースのシステムは代替案を提案し、料理プロセスを効率化します。
これらのユースケースの開発と実装において、クックパッドはユーザーデータのプライバシーとコンプライアンスを最優先します。
そのプロセスに従い、セキュリティに準拠していることを確認する必要があります。
ニーズに合わせたMLOpsアーキテクチャの構築
MLOpsでリアルタイム推論スタックを構築する際、万能なアプローチというものはありません。ホセ・ナバロは、企業の特定の要件と機械学習(ML)実践の成熟度レベルに基づいてアーキテクチャを調整することの重要性を強調しています。MLOpsアーキテクチャの必須コンポーネントに関するいくつかの重要な洞察を以下に示します。
- 成熟度を理解する: ML実装の現在の状態は、必須コンポーネントを決定する上で重要な役割を果たします。企業が実験とモデルデリバリーに重点を置いた初期段階にある場合、モデルの提供と推論レイヤーの構築が重視されるかもしれません。一方、MLモデルがすでに本番稼働しており、ビジネスにとって不可欠な企業にとっては、再現可能なパイプライン、特徴量ストア、モデルの可観測性が不可欠なコンポーネントとなります。
- 過度な複雑化を避ける: ホセは、MLOpsスタックに不要なツールやコンポーネントを追加する傾向を避けるよう提案しています。その代わりに、簡素化と「引き算」による問題解決に焦点を当てることが重要です。不要な要素を削除したり、問題を簡素化したりすることで、企業はより早く解決策にたどり着くことができます。このアプローチにより、チームは複雑なツールに時間を費やす前に、価値の構築とMLイニシアチブの影響評価を優先できます。
- アジャイルなツール導入: ホセは、あらかじめ決められた必須リストに従うのではなく、必要に応じてツールを導入することを推奨しています。まずは主要な課題と要件を特定し、それらの特定のニーズに対応するツールを段階的に導入します。例えば、特徴量ストアの調査と統合に多大な時間を費やす代わりに、DynamoDBのようなサービスで簡単なキーバリューストアを構築し、プロジェクトを迅速に開始してその価値を評価することを検討してください。この反復的なアプローチにより、不要な複雑さを最小限に抑えつつ、MLイニシアチブのより迅速な検証が可能になります。
True ML Talksシリーズの過去のブログ記事もぜひご覧ください:
TrueMLの YouTubeシリーズ とTrueMLの ブログシリーズをぜひご覧ください。
TrueFoundry は、Kubernetes上で動作するMLデプロイメントPaaSであり、開発者のワークフローを加速させ、モデルのテストとデプロイにおいて完全な柔軟性を提供しつつ、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームは モデルを15分でデプロイし、監視する ことができ、100%の信頼性、スケーラビリティ、数秒でのロールバック機能を備えています。これにより、コストを削減し、モデルをより迅速に本番環境にリリースし、真のビジネス価値を実現できるようになります。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.















.webp)
.webp)


.png)

.png)














