読者です 読者をやめる 読者になる 読者になる

はむはむエンジニアぶろぐ

このブログのコンセプトは"ハッキングの為なら愛する家族を傷つけることをいとわない" 自分にとってエンジニアリングは "手段ではなく生きる目的" である

バッチ処理について

バッチ処理について、色々調べたり経験したことをまとめておく。

オンライン処理とバッチ処理の性質の違い、
オンライン処理とバッチ処理の設計判断軸、

などを整理してみた。

オンライン処理とは

特に説明不要かと思いますが、オンライン処理は要求を受けたらリアルタイムに結果を返すものです。
オンライン処理は、リアルタイム性が求められます。


オンライン処理に時間がかかってしまうとシステムユーザは待ち時間の間、次の操作ができません。
要件で決められたレスポンスタイム内に、結果を返す必要があります。

バッチ処理とは

バッチ処理は、いくつかの作業単位を1つにまとめて一括処理することです。


例えば銀行のような締め作業のあるシステムだと 日中に締め作業の計算という重たい処理をしてしまうとサーバの負荷が高騰し、その他のリアルタイム性が求められているオンライン処理に影響を与えてしまいます。


なので、バッチ処理はコンピュータのリソースに余裕がある時間帯に重い処理をやろうっぜって発想で生まれました。


しかし、Webの世界では24時間サーバが活動するのが当たり前なので、閉店時間はなく深夜にバッチ処理を行ったりします。
Webシステムの性質次第で深夜にアクセスが活発なのであれば、別の比較的負荷が少ない時間帯にバッチ処理をします。


レスポンスタイムの考え方も業務システムとWebシステムで全く異なります。
例えば、業務システムでレスポンスタイムが1分のオンライン処理は許容できるかもしれませんが コンシューマ向けのWebシステムにおいて1分なんて許容できないはずです。


Webシステムでは、コンピュータのリソース的に問題なくてもレスポンスタイムを向上させるため予め計算しておくためにバッチ処理をしておくこともあります。

バッチ処理のメリット

  • 重たい処理をコンピュータのリソースに余裕がある時間帯にシフトできる
  • 1件ごとではなく、大量な件数をまとめて処理することで通信やI/Oの回数が減り効率よくコンピュータのリソースを使うことができる

バッチ処理で注意しておくこと

バッチ処理をすることで、今抱えている問題が解決されるかと思いきや同時に考えないといけないことも増えます。

処理時間

コンピュータのリソースに余裕がある時間帯に重たい処理が出来るという言葉のウラを返せば、コンピュータのリソースに余裕が無い時間帯に重たい処理をすることは出来ないということになります。
ということは、リソースに余裕がある時間帯にバッチ処理を終わらせなければなりません


このリソースがある時間帯にバッチ処理が終わらないことを「 突き抜け 」と言います。
突き抜け の原因は、バッチ処理するデータ量がバッチ設計時よりも増えてしまったからです。
バッチのライフサイクルを考え、どのくらい処理するデータ量が増えるか予測する必要があります。


必要に応じて、スケールアウトやスケールアップということをしなければなりません。

メモリ使用量

オンライン処理を計算するサーバとバッチ処理を計算するサーバを別々で用意していてもメモリのことは気にしなければなりません。
バッチ処理するデータ量が増えてた時にメモリ使用量も比例して増えるアルゴリズムを組んでいた場合、いくつかのバッチ処理が複数競合した場合メモリが足りなくなるかもしれません。


ある程度、メモリを使うのは仕方ありません。
しかし処理するデータ量が増えていくことが、予測されるのであれば富豪プログラミングを自重してメモリを節約するアルゴリズムにするかサーバのスケールアウトかスケールアップが必要です。

再実行

バッチ処理が何かしらの理由で、失敗することはよくあることです。
失敗するのは仕方ないとして、再実行した際に冪等性が守られている必要があります。


当たり前ですが冪等性が守られていなければ、メンテナンスが大変です。
トランザクション処理をするなどして、バッチ処理実行前の状態に戻しましょう。


それから、バッチ処理失敗時に直ちに手動実行が必要なのか?次のバッチ起動まで、待てるのか?という情報が必要です。
エラーログなりにその情報が、記載されていると調査コストが浮きます。

バッチ処理は銀の弾丸ではない

バッチ処理は、使いかたを誤れば別の問題を引き起こしますし、設計が複雑化する原因にもなります。
なので、オンライン処理で済ませれるのであればオンラインで済ませたほうがシンプルだと思います。


しかし、全てオンライン処理で出来るわけがなくバッチ処理も当然、必要です。


ですがオンライン処理とバッチ処理の中間にあるやり方も選択肢に入れたほうが良いです。

例えば

  • 計算結果をキャッシュサーバにストアしておく
  • Ajaxで別スレッドで計算させる
  • 一度計算した結果を、サマリーテーブルにストアしておく

他にも色々ありそう。

データの鮮度

データの鮮度 とは、どれくらいのデータの新鮮さが求められているかということです。
更新されたデータは、1日前でもいいのか?それとも今さっき更新されたデータが必要なのか?


データの鮮度 次第で、設計が変わります。

いろんな選択肢を考えその中で、ベストな落とし所を模索するのが大事だと思います。