バッチ処理を採用する際に考慮したことと実装の諸々

目次

1. はじめに
2. バッチ処理を採用すべきか
3. バッチ処理をどのように設計実装したか
4. 参考にしたサイト

はじめに

バッチ処理を採用・実装する上で考えた事を思考の整理のため、つらつらと書き出しました。

バッチ処理を採用すべきか

バッチ処理を採用するかどうかの観点は、機能要件と非機能要件の2つの観点で考えました。 機能要件の場合、連携するサービスが特定の時間のみ稼働するなどの制約があるケースです。 非機能要件の場合は、処理がオンライン処理では収まりきらない程の時間がかかるケース(ファイル作成・大量データの集計)です。

なので基本的にはオンライン処理もしくはオンラインの非同期処理(イベントソーシング等)を採用して、 これを満たせないケースにバッチ処理を採用しました。

バッチ処理をどのように設計・実装したか

何を考慮するか

まず初めに以下の点を考慮すべき点として考えました。

• 件数
  • 参照するレコード・データの量
• 時間
  • 処理に必要な時間
  • 開始・終了時間の限度が存在するか
• 回復
  • 再実行可能か
  • 再実行した結果、二重で処理されない
  • 失敗したデータの追跡や再処理が可能か
• ステータス
  • バッチの開始・進行中・終了のステータスが確認できる
  • 処理の結果が正常か異常かを判断できる
• その他非機能...

これらに対して以下のような設計・実装方法の検討を行いました。

管理単位

• 名前で管理
• IDで管理

トリガー

• トリガーの決定
  • 定期実行かイベント駆動か
• 入力値
  • 引数

エラーハンドリング

• エラーハンドリングの方式検討
  • 1件でもエラーがあれば処理失敗
  • エラーがあれば該当レコードをスキップ

バックアップ

• バックアップ方式の決定

リトライ

• 冪等性の担保
• 外部連携サービスの考慮

ロールバック

• 同期
• 非同期

直列・並列処理

• 直列実行
• 並列実行
  • マルチスレッド
  • JOBを実行するサーバのスケールアウト

ジョブ管理

• ジョブ管理方法の定義
  • Cronの利用 or ジョブ管理ソフト・サービスの導入
• 二重実行可能かどうか
  • 二重実行不可能な場合の制御方法

ログ

• 計画的にログを吐くよう定義
• 個人情報やメールアドレスなどのセキュリティの担保
  • 出力しない
  • マスク処理をする
• 出力場所を定義する
• ログレベルを定義する
• フォーマットを定義する
  • 開始・終了時間
  • 処理機能・処理対象・対象件数...
  • 処理結果
• 保存期間
• ログローテーションの方式

監視

• 実行結果(正常|終了)が確認できる
• ステータスに基づいて通知する

通知

• 確実に通知できる
• 実行内容の詳細を確認できる

削除

• 実行後の一時作業ディレクトリ削除
• 古いログの削除
• 古いバックアップの削除

参考にしたサイト

• バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
• バッチ処理実装時に考慮すべき事項 | メルカリエンジニアリング
• バッチ処理 プラクティス
• Webのバッチ処理とオンライン処理のポイントとシステムの応答性能を学ぶ#2（社内勉強会）｜TechRacho by BPS株式会社
• バッチプログラムの運用と監視について検討しよう | メルカリエンジニアリング