ML System Design Pattern#

Serving patterns#

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

Synchronous pattern#

概要:

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

Usecase:

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

Asynchronous pattern#

概要:

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

Usecase:

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

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

Batch pattern#

概要:

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

Usecase:

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

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

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#

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

参考文献#