バッチ処理とは #308日目
普段、既に作られたバッチを何となく使っていますが、自分で一から作ろうとしたら全く何もできないことに気が付き、せめて基礎的な概念だけでも抑えておこうと思いアウトプットします。
バッチ処理とは
バッチ処理とは、一言で言うと、データをまとめて処理するプログラム方式のことです。大規模なデータを一括処理するのが目的のため、バッチ処理とはそもそも時間がかかる前提のものです。そのため夜間や休日などに定期実行するよう設定されていることが多いです。
ただし処理の量によっては日中までに終わり切らず、システムの本稼働に影響を与えてしまうことがあります。これは”突き抜け”と呼ばれる事態で、実行タイミングを調整するだけではこの突き抜けを防ぎきることができません。
そのためバッチ処理の構造をよく理解して、お互いに影響し合わない箇所を並行処理する、といった工夫が必要になります（同時に複数のバッチ処理をするとメモリを逼迫するのでその点は注意ですが）。
バッチ処理の基本構造
まず、バッチ処理は大きく3つの工程に分解できます。
入力 → 加工 → 出力
それぞれの工程の要素は以下のようなものがあります。
入力：
ファイルから入力、DBから入力
加工：
データの抽出、削除、加工、集計、マージ
出力：
ファイルへの出力、DBへの出力
バッチの起動タイミングは大きく2つあります。
トリガー起動
定時起動
トリガー起動は、データの閾値やAPIへのリクエスト等を元に設定できます。定時起動はその名の通り、夜間や休日などバッチを走らせたい時間を指定して設定しておくものです。
設計時に考慮すること
バッチ処理の設計時に留意することとして、以下のものがよく挙げられていました。
並行処理できるポイントの見極め
突き抜けを防ぎ、システムの本稼働に影響を出さないために工夫できるところはしておく必要があります
バッチ処理の開始と終了時刻の記録
パフォーマンスの変化を計測していくために開始終了を記録しておくことは重要です
実行ログの記録
障害が発生した際の原因究明に必須のものです
データライフサイクルを定義して不要なデータは削除
ストレージを必要以上に使用しているとパフォーマンス低下の要因になるため、不要なものは自動削除されるようになっていることが望ましいです
バッチ処理のアンチパターン
割けるべきアンチパターンとして以下が挙げられていました。
ログローテーションされないログファイル
ストレージの問題もありますし、必要なログが探しにくくなるというのもありますね。
ログローテーションとは、システムが残す時系列の記録データ（ログ）が際限なく増えることを防ぐために、一定の容量や期間ごとに古いログを削除したり新しいログで上書きすること。また、そのような機能。
更新されたタイミングが分からないDB
DB設計としてcreated_atやupdated_at等のカラムが入っていた方が障害発生時の調査が簡単になります。
何でも通知するバッチ
不要なerror通知が形骸化するとオオカミ少年になってしまいます。
以上、基本概念の整理でした。
ここまでお読みいただきありがとうございました！！
参考
この記事が気に入ったらサポートをしてみませんか？