株式会社Macbee Planet で3D ADという広告配信プラットフォーム（DSP）を開発・運用しているrami（@rami）です。
3D ADでは、QPS※を最大化するために、クラウド基盤のリアーキテクチャを推進しています。
今回は、広告配信における一部の機械学習の推論をオンライン推論から、バッチ推論構成にリアーキテクチャしました。
具体的には、以下を行いました。
- 予測結果を事前にRedisへ保存
- bigcacheで推論結果のキャッシュ
※QPS（Queries Per Second：クエリ毎秒）とは、1秒間に処理する入札リクエストの数のこと
元の3D ADの広告配信基盤の全体構成
オンライン推論からバッチ推論の構成に変更した理由
広告配信における機械学習の推論について、以下の理由によりオンライン推論からバッチ推論にインフラ構成をリアーキテクチャしました。
- レイテンシを下げたかったため
- クラウドコストを下げたかったため
元の構成の課題
既存の学習・推論構成は、以下の課題を抱えていました。
- リクエストの増加に伴い、機械学習推論サーバも追従して、スケールさせる必要がある
- 推論に掛ける特徴量の組み合わせについて、同じ組み合わせが直近で発生したとしても、キャッシュを用いず逐一推論する
これらの結果として、クラウドコストがリクエスト量に対して指数的に肥大するという問題を抱えていました。
※弊社のプロダクト 3D AD は 広告配信業者として、リクエストに対して100ms以内にレスポンスを返却しなければならないという制約が存在します。
オンライン推論とバッチ推論のメリットとデメリット
それぞれの推論方式について、メリットとデメリットを整理しました。
| 推論方式 | メリット | デメリット |
|---|---|---|
| バッチ推論 | • 低コスト • 事前検証可能 |
• 予測の柔軟性が低い • 更新が遅い（時間/日単位） |
| オンライン推論 | • 任意の入力に対応可能 • ロングテール予測に強い |
• 計算コストが高い • レイテンシの影響大 • シンプルなモデルに限定 • 監視負荷が高い |
※上記の表については、以下にある内容を要約しました。
3D ADがバッチ推論にリアーキテクチャしたことで得られたメリット
- 大部分のリクエストに対する推論について、インメモリのキャッシュ内に閉じて完結するためレイテンシが改善した
- オンライン推論構成では、推論5ms-20msかかっていたところを、1-2ms未満程度に抑えることができた
- リアルタイム推論に伴い、機械学習推論サーバ側でもスケールさせていた分のコストが削減される
- 機械学習推論サーバの1つが構成から丸ごと無くなってしまうことから、その分のコストを1/2にすることができた
今回、広告配信業者としての制約を守りつつ、クラウドコスト及び推論コストの削減を達成するために、以下のようにリアーキテクチャを行いました。
オンライン推論の構成
学習の流れ
学習は、図のような流れで行われています。
推論の流れ
入札から推論は、図のような流れで行われています。
バッチ推論基盤の構成
学習の流れ
学習は、図のような流れで行われています。
推論の流れ
元の構成では、推論に掛ける特徴量の組み合わせが同じだったとしても、逐一推論していましたが、今回の構成では、以下の工夫も加えています。
- Golangでサーバサイドを実装しており、インメモリキャッシュを手軽に実装したい背景から bigcache を導入
- Memorystoreの前段にインメモリキャッシュのレイヤを置くことで、Redisへの問い合わせ回数を大幅に削減
入札から推論は、図のような流れで行われています。
キャッシュヒット時
キャッシュミス時
苦労したところ
VertexAI PipelinesとMemorystore for RedisをVPC経由で接続したところです。
元のオンライン推論の構成では、VertexAI Pipelinesで学習したmodelをGCSにアップロードする構成だったことから、VertexAI PipelinesでVPC経由で何かのサービスに接続する構成ではありませんでした。
今回のリアーキテクチャでは、推論結果を事前にMemorystore for Redisに書き込むのですが、VPC経由で接続する必要があり、元の構成から大きく変わる構成だったことから、調査、検証、QA等に苦労しました。
また、学習に加えて、推論もVertexAI Pipelines上で行なっていることから、検証一回あたりにかける時間が長くなってしまいやすかったところも、より苦労したという感じです。
VPC経由でVertexAI PipelinesとMemorystore for Redisを接続するために必要な設定
CustomContainerTrainingJobで、VPC経由で何かのサービスに接続する時は、networkの設定を与える必要があります。
公式ドキュメントをそのまま記載しておくので、実装する機会があれば参考になれば幸いです。
network
The full name of the Google Compute Engine network to which this CustomTrainingJob should be peered.
Specify the name of the network using the format projects/{project}/global/networks/{network}. Replace {project} with the project number, such as 12345, and {network} with a network name.
Before specifying a network, private services access must be configured for the network. If private services access isn't configured, then the custom training job can't be peered with a network.
引用：https://cloud.google.com/python/docs/reference/aiplatform/latest/google.cloud.aiplatform.CustomContainerTrainingJob#google_cloud_aiplatform_CustomContainerTrainingJob_network
まとめ
以上、VertexAI Pipelines×Memorystore for Redisで機械学習のバッチ推論基盤にリアーキテクチャした背景、構成、学習/推論の流れでした。
今後、機械学習でバッチ推論のアーキテクチャの開発を検討している方にとって、少しでも参考になれば幸いです。
Discussion