Skip to content

Latest commit

 

History

History
31 lines (24 loc) · 2.56 KB

File metadata and controls

31 lines (24 loc) · 2.56 KB

Batch pattern

Usecase

  • リアルタイムまたは準リアルタイムで推論する必要がないとき
  • 過去のデータにまとめて推論を実行したいとき
  • 夜間、毎時、毎月等、定期的にデータを推論したいとき

Architecture

推論をリアルタイムに実行する必要がない場合、バッチ・パターンで定期的に推論を行うことが可能です。バッチ・パターンでは溜まったデータを夜間等、定期的に推論し、結果を保存することができます。もちろん夜間実行である必要はなく、ユースケースによって1時間毎・1ヶ月毎の実行も可能です。バッチ・パターンではバッチ・ジョブを起動するジョブ管理サーバが必要になります。ジョブ管理サーバは決められたルール(時間や他の条件)をトリガーにして推論のバッチ・ジョブを起動します。推論サーバはバッチ・ジョブの起動時のみに稼働します。基盤にクラウドやKubernetesを使用している場合、サーバの停止・起動をコントロールすることでコスト最適化も可能になります。

Diagram

diagram

Pros

  • サーバのリソース管理を柔軟に行うことが可能。
  • 何らかの理由で推論に失敗しても再度推論することが可能。

Cons

  • ジョブ管理サーバが必要。

Needs consideration

  • 一回のバッチ・ジョブでどの範囲のデータを推論するか、ジョブの起動条件が必要になる。
  • 推論結果を得るまでの期限が決められている場合、推論バッチ・ジョブの実行スケジュールや稼働する推論サーバ数を調整する必要がある。夜間バッチ等であれば、翌朝までに推論完了することが要件になる場合が多い。
  • バッチ・ジョブが失敗したときの方針が必要がある。
    • 全件リトライ:失敗した場合は再度推論バッチ・ジョブを実行し、全件を推論する。
    • 一部リトライ:失敗したデータのみ再度推論する。
    • 放置:失敗してもリトライを起動せず、次のバッチ・ジョブで推論する。
  • 毎月や毎年等、推論バッチ・ジョブを起動する時間が大きく離れる場合、機械学習モデルの有効性(Out-of-date)やサーバ自体の稼働可否をモニタリングする必要がある。

Sample

https://github.com/shibuiwilliam/ml-system-in-actions/tree/main/chapter4_serving_patterns/batch_pattern