脱バッチ化のススメ

その昔、大型コンピュータを自前で持つには相当な金額が必要なので、利用者がセンターに端末を繋いで、シェアしながら使っていました。メインフレーム等の大型コンピュータは、CPUの使用時間で課金されていました。当然、データのInput/Outputに時間が掛かるわけですが、その時間もCPUを必要とするのであれば課金されてしまいます。高額になるCPU使用料をなるべく減らすために、データを一括で入れて一括で出すプログラムを書いていました。いわゆるバッチプログラムです。

いわゆる集計等は大量のデータも必要となるので、バッチ化されて動いていました。業務の締めという概念にもマッチしていました。また、科学技術計算などでもバッチで動作していました。私の父が港湾施設の設計をやっていたのですが、複雑な面を持つ部分の応力の計算などは、数百に及ぶ計算式で値を求めなければならず、それを端末を専有して人が一つ一つ計算させるのは非効率で利用料も跳ね上がるので、まさにバッチにして一気に計算させていました。

そういう過去もあってか、メインフレームに限らず、オープンアーキテクチャにおいてもバッチプログラムをやたらと目にします。オンラインバッチ、５分毎のバッチ、定時バッチ、日次バッチ... 業務的に意味があるのであればよいのですが、「昔からそうしていたから」という理由でやっているのであれば、止める方向で考えませんか？
バッチ処理の欠点として、下記が挙げられます。

• 一度に多くのデータを扱うので多くのメモリ領域を必要とする

• バッチ処理のピークに合わせたハードウェアを用意する必要がある

• 夜間はバッチ処理でフル稼働しているが昼間のCPU利用率が少ない

• 業務量の増大に従い、夜間バッチが翌朝の業務開始までに終了せず、営業に影響が出る

• 夜間バッチの失敗時に備えて夜間にオペレータを雇わなければならない

• SQLでバッチ処理を行っており、細かな仕様変更に耐えられない

一方でバッチ処理の必要性として、下記が挙げられます。

• 業務の締めが必要で、夜間に走らせる必要がある

• オンラインの性能を後続処理で犠牲にしたくないため、DBのレプリケーションを行ったうえで処理をさせている。DBのレプリケーションのタイミングに合わせバッチ処理を走らせている

オンラインの性能を犠牲にせずに後続処理をさせるには、DB起点での処理ではなく、Queueを利用すると良いです。オンラインでのDB書き込みの直前にQueueに書き込ませ、完全同期が必要ならDB書き込み、ほぼ同期でよいのであればQueue書き込みでオンライン処理は呼び出し元へ戻し、DB書き込みを非同期で行います。Queueに書き込まれたデータは、DBへの書込みをするサブスクライバと後続処理を行うサブスクライバへと、データを複製して使えばよいのです。

業務で必要な締めは確実にあり、ここだけは確かにバッチ処理が必要になりますが、データのチェックや前段の集計などまでも夜間バッチにする必要はありません。「業務の締め」とは、一日の売上の集計等を「確定」するものであり、チェックや集計自体は非同期処理で昼間に行うことができるはずです。昼間の処理でエラーが出た場合、対応する人員（特に業務側）もいらっしゃるはずで、業務終了までにデータの修正もできるはずです。
システム負荷の平準化にも繋がり、コストダウンだけではなく、本当にやりたいことに資源を割当てることも可能です。

Queueを使った脱バッチのススメ、本当にオススメです！
是非ご検討ください。