バッチ処理

バッチ処理とは

バッチ処理とは、コンピュータが一連の処理を人間の介在なしに自動で行うことです。ワークロード自動化（WLA:WorkLoad Automation）やジョブスケジューリングとも呼ばれます。

バッチ処理は、大量のデータを短時間で処理する非常に費用対効果の高い方法です。エラーや異常が発生した場合のみバッチ処理は中断し、スタッフあるいはマネージャーにその旨を通知します。

バッチ処理の用途

バッチ処理のメリットを活かせるのは以下のような場合です

• 即時の処理やリアルタイム情報が必要ではない場合
• データが大量な場合
• まとまったシステムの休止時間がとれる場合
• 人の入力が不要で、繰り返し実行される処理の場合

典型的なバッチ処理の例として、毎月のクレジットカード会社による請求が挙げられます。カードの請求は買い物単位ではなく、1か月分がまとめられています。その請求は、その月に発生した情報すべてを、ある日に一括してバッチ処理で集計して作られます。

かつて銀行では、一日の終わりの夜間バッチ処理を多用していました。日中の負荷が高い時間帯にコンピューターの計算資源を占有しないためです。現在では、トランザクションは通常、発生後ただちに処理されます。

また、私たちがよく知っているバッチ処理の例として挙げられるのは、電子メールです。ほとんどのプログラムには、電子メールを送信した後、一定期間保存し、バッチとして送信する機能があります。これにより、ユーザーは送信前にメールを削除したり編集したりする時間ができ、例えば添付ファイルを忘れるなどの「誤送信」を避けることができます。

なぜバッチ処理を行うのか

バッチ処理は、コンピューターの歴史のかなり初期から行われてきました。パンチカードのバッチ(かたまり)が一連のプログラムを表しており、それをひとまとめ実行する処理です。バッチは自動で完了するか、エラーによって中断し人手で調整を行っていました。

当時はコンピュータリソースが限られ、現在のような膨大な処理能力がありませんでした。夜間バッチというのは、貴重なコンピュータリソースを占有できる時間帯を使い、マシンが最高速度で大量のデータを処理できる手段だったのです。

現在におけるバッチ処理は、色々と変化しています。従来の「バッチデータ」は必ずしも夜を待つ必要はありません。非同期で実行することも、日中のメインのタスクを中断させることもなく随時バックグラウンドで実行することができます。

しかし、現在の巨大なコンピューティングパワーとクラウドコンピューティングでも、バッチ処理を使うべき局面はまだ残っています。

バッチ処理のメリット

スピードとコスト

バッチ処理の利点は自動化と処理速度です。人による介入が不要なことで運用コストが削減され、データの処理速度が向上します。必要に応じてデータの処理優先順を変えることもできます。

正確性

属人性のない自動処理はエラー防止にもつながります。工数とコストを削減するだけでなく、正確なデータとユーザー満足度を得ることができます。

独立で稼働

バッチ処理システムは単独で実行できるため、日中のサービス時間が終わっても動かすことが可能です。バッチの開始タイミングを調整することで、日中のサービスへの影響を制御することができます。

簡便性

バッチ処理は自動です。人がその都度ログインして何かを確認したり調整する必要はありません。問題が発生して運用スタッフに通知が送信される以外は、信頼できる完全無人化された処理だといえます。

シンプルであること

運用サポートやデータ入力や追加プログラムは必要ありません。自動処理が正しく動いている限りメンテナンスは不要です。データ処理への入り口としてバッチ処理が最も抵抗の少ない手段である理由です。

機械学習と人工知能のための正確なデータ

人工知能における最大の課題の1つは、低品質なデータです。データサイエンティストの労力の多くは、データクレンジングやエラー排除、データの整合のために費やされています。自動化されたバッチ処理の利点は、データエラーを回避できることです。異常が見つかった場合は直ちに通知がくるため、迅速に解決できます。そうして得られた高品質で高精度なデータによって、正確な予測を得ることができます。

既存の計算資源の有効活用

バッチ処理はシステムが低負荷な時間を使ってデータを処理することで、既存システムの計算資源を最大限に活用することができます。追加投資なしに既存のリソースをより効率的に活用する方法です。

バッチ処理の課題

バッチ処理の良さは色々ありますが、すべての企業やケースに当てはまるわけではありません。以下はバッチ処理の制約の例です。

トレーニングと導入

バッチ処理を含めて新技術の導入にはトレーニングが必要です。関係者は、バッチトリガー、スケジューリング、例外通知とエラーの処理方法などを理解する必要があります。

＜解決策＞

シンプルで理解しやすいマニュアルと、十分なトレーニングが必要です。システム変更の必要性は低く、例外処理のトレーニングが重要です。 デバッグの内容がかなり複雑となるため、知見のある専従者がいることが望ましいですが、中には外部コンサルタントを使うケースもあります。

コスト

中小企業ではバッチ処理のためデータ担当や十分なシステムを置けない場合があり、初期投資が割高となってしまいます。

＜解決策＞

これから実装する前に、詳細な費用とROI (投資回収)を見積もります。

バッチ処理の代替となる方式

バッチ処理には2つの代替方式があります。どちらも近年の発明であり、データの接続性とコンピューターの計算力が向上したことで実用的なものになりました。

ストリーム処理

データを送受信する都度ただちに処理する方式で、データが連続して流れる(ストリーム)ものです。ウェブサイト上のアクティビティ、金融取引、交通情報、クレジットカード取引などが典型です。データの絶対量としては大量ではありませんが、つねにある程度のデータが流れています。

ストリーム処理は、発生するさまざまなイベントに応じて、迅速に対応する必要がある場合に役立ちます。株価追跡やクレジットカード不正使用検知などです。

リアルタイムオペレーティングシステム

遅延や中間バッファなしでデータを処理する方式です。データを受信してマイクロ秒単位で処理しなくてはなりません。タイミングが非常に重要な、航空交通管制やマルチメディアシステムに使用されます。どちらも数十分の1秒以内にデータを処理できることは必須です。

これら2つの代替方式は、特定の環境や用途にのみ使われます。システムを実装する際は、どのようなケースでどのようなデータが欲しいかに応じて方式を選択する必要があります。

バッチ処理が合うケース

バッチ処理が合う状況はありますが、唯一の正解はありません。バッチと他の方式のハイブリッドが最適な場合もあります。たとえば医療システムにおいて、糖尿病の血糖値をモニタリングするウェアラブル機器はストリーム処理が必要ですが、請求の発行にはバッチ処理が向いています。 リアルタイム処理が不要で、バッチ処理に適したケースは以下のようなものです。

• 勤怠管理および給与計算
• 締日で取引を集約して作成する請求書
• 銀行取引明細書
• 調査報告
• サプライチェーンにおける補充（在庫反映はリアルタイムベースだが、在庫補充のタイミングは週次・月次の場合も多い）
• 週次または月次単位での請求
• データベースの定期的なアップデート
• 月末のファイルフォーマット変換。例えば月末発行の請求書PDFを作成する

バッチ処理にすべきかどうかを検討する際には、以下の質問も参考にしてみてください。

• 大量の手動タスクがあるか？どのように作業の正確性を担保しているか？作業の正確性や正しい順序を保証するための仕組みを持っているか？
• システム内に待機中のジョブはあるか？各ジョブがいつ完了し、次のジョブがいつ開始されるかを把握できているか？
• 新たなファイルの追加を目視で確認しているか？確認のためのスクリプトは十分な頻度でループしているか？
• ジョブレベルでリトライする仕組みはあるか？リトライの際、他のタスクの遅延や優先順位変更などは発生しているか？サーバー利用は効率的か？

バッチ処理の未来

コンピューティングパワーの増大やクラウドコンピューティングによって、バッチ処理は不要になるでしょうか？データがより複雑で多様になることで、バッチ処理は主役の座から降り、あるいは舞台を去って行くのでしょうか？

バッチ処理には今日でも確固たる役割があり、それは将来も続くでしょう。バッチ処理は人間やインターネットからの割り込みがないことで驚異的な高速処理を行うものです。人間によるリアルタイムや遅いデバイスを待つ必要がないため、バッチ処理はコンピューター資源を非常に有効に使用する方法といえます。

バッチ処理そのものは定型処理ですが、その構築は現在アジャイルなものになっています。かつては手組みだったバッチ処理の品質は必ずしも完璧とは言えませんでしたが、その後の進化でバッチ処理はルールベースのワークフローとプロセスを持ち、より効率的で信頼性が高く一貫性がありアジャイルな構築アプローチが可能になりました。

昨今の企業は、かつてない厳格な規制や法律に直面しています。こうした時代の変化に対応するには、新しい業務シナリオが必要になった時、ただちに適用できるようなバッチプロセスを作り出すための、動的トリガーを備えたポリシードリブンのワークフローが必要になってきます。たとえばデータ侵害が発生した時には、データのロールバックと関連システムの更新を起動するようなシナリオが自動化され、ひとつのバッチ処理として実行できるようになります。

多数の処理を一つにまとめるのもバッチ処理に向いています。倉庫からの出荷などは注文ごとに処理するよりも、ある程度の量がたまった時か出荷の締め時間にまとめて処理するのが効率的です。

また、IoT情報を記録するケースもあります。たとえば、スマートメーターからの情報は分単位である必要はなく、逆に障害や故障が発生した場合は、直ちに対応する必要があります。電気、水、インターネットの通常状態では、たえずデータを送信するのは帯域の無駄遣いにつながります。

データ転送の進化によりリアルタイム処理は可能になりましたが、待ちを許容できる場合にはバッチ処理にもまだまだ利点があります。すべてのシステムをライブで駆動することは魅力的に感じられますが、システムに不要な負荷を与えたり、余分な開発・運用作業が発生したりする可能性もあります。バッチ処理をレガシーな遺物と見る人もいますが、今日でも、そして将来もバッチ処理が有効な場所があります。