ML System Design Pattern

ML System Design Pattern#

Serving patterns#

推論サーバを稼働させ運用するパターン。

Synchronous pattern#

概要：

  • REST APIなどで同期的に提供するパターン

Usecase：

  • アプリのワークフローが推論結果に依存するとき

Asynchronous pattern#

概要：

  • Pub-subモデルなどで非同期的に提供するパターン

Usecase：

  • アプリのワークフローが推論結果に依存しないとき

  • 推論に時間がかかるモデルで、Synchronousだとユーザーを長時間待たせてしまうとき

Batch pattern#

概要：

  • 定期的に推論しておき、DBなどに保存しておく方法

Usecase：

  • リアルタイムで推論する必要がないとき

  • 推論に時間がかかるモデルのとき

例：note.comのレコメンド

読者の行動データを用いたnote記事レコメンドのMLパイプラインツアー｜むっそ

  • モデルロードパターン：機械学習モデルはS3に保存してあり、SageMakerのBatch Transformで起動するDockerコンテナにロードして推論する

  • バッチ推論パターン：EventBridgeの定期実行により、対象のデータ群に対してバッチ推論を実行する。

  1. モデル学習/作成プロセス

    • EventBridgeにより定期的に起動 → Glueで情報抽出 → SageMaker training jobで学習

  2. モデルのバッチ推論プロセス

    • SageMaker BatchTransformでユーザーごとのレコメンド内容をまとめて推論

  3. バッチ推論結果のDynamoDB登録プロセス

    • 推論結果はSQSに送信され、LambdaからDynamoDBに投入

Data cache pattern#

概要：

  • 前処理済みの入力結果や推論結果をキャッシュしておく

  • 推論時、キャッシュ済みのinputに対してはRedisなどからキャッシュを取り出し、モデルの推論を回避する

Usecase：

  • 同一データの入力が多く発生するとき

  • 前処理や推論に時間がかかるとき

例：

  • Bernardi et al. (2019). 150 successful machine learning models: 6 lessons learned at booking.com

    • A/Bテストで新旧モデルを比較したところ、推薦においてOffline evaluationによる予測精度の改善はビジネスのKPIに対し無相関だった

    • しかしA/Bテストでユーザーの待ち時間（latency）を比較したところ、待ち時間が長いほどCVRが悪化する負の相関がはっきり出た

    • そこですべての推論結果をkey-value-storeに保存しておくcache patternを使いlatencyを縮めた（他にもインフラ的な冗長性確保やアルゴリズムの計算量削減なども行っている）

Prediction circuit break pattern#

概要：

  • 急増したリクエストに対し、サービス全体が停止しないようにするため、リソースの増加が完了するまでの間だけ一部のリクエストを遮断する

Usecase：

  • 推論へのアクセスが急激に増減し、増減に推論サーバやインフラが対応できない場合

  • 全リクエストへレスポンスを返す必要がない場合

QA patterns#

機械学習のモデルおよび推論器を評価するためのパターン。

参考文献#