バッチ処理とは｜まとめると22.00秒が2.04秒、巻き戻りは1件から500件に

まとめると22.00秒が2.04秒、巻き戻りは1件から500件に

まとめる数を変えて数えました。速くなる効果は早い段階で頭打ちになり、巻き戻る件数だけが増え続けます。

バッチ処理でまとめる数を変えると何が変わるのかを、実際に走らせて数えました。1000件を送り、1回の呼び出しに20ミリ秒、1件あたり2ミリ秒かかる想定です。

この20ミリ秒がまとめることで節約できる部分です。認証や接続にかかる固定の手間だと考えてください。

for (const size of [1, 10, 50, 100, 500]) {
  const calls = Math.ceil(N / size);
  const ms = calls * PER_CALL + N * PER_ITEM;
  // calls が呼び出し回数、ms が全体の時間
}

まとめる数  呼び出し回数  かかる時間  1回失敗したときにやり直す件数
      1件         1000回      22.00秒                            1件
     10件          100回       4.00秒                           10件
     50件           20回       2.40秒                           50件
    100件           10回       2.20秒                          100件
    500件            2回       2.04秒                          500件

上の表を見てください。1件ずつだと22.00秒、500件ずつだと2.04秒です。10倍以上の差があります。

早い段階で頭打ちになる

注目したいのは50件の行です。すでに2.40秒まで来ています。

そこから500件まで10倍に増やしても、縮むのは0.36秒だけです。1件あたりの2ミリ秒は、まとめても減らないためです。

巻き戻りは増え続ける

一方、右端の列はまとめた数と同じだけ増えます。500件ずつなら、1回の失敗で500件が戻ります。

つまり50件から先は、ほとんど速くならないのに巻き戻りだけが10倍になります。増やす理由が薄くなる地点です。

バッチ処理でなぜ速くなるのか

1回の呼び出しにかかる固定の手間を、多くの件数で割るからです。件数に比例する部分は減りません。

バッチ処理は、処理をまとめて一度に実行する作り方です。まとめる理由は速さと費用の両方にあります。

2種類の手間

処理にかかる時間は2つに分かれます。1回の呼び出しごとにかかる固定の手間と、1件ごとにかかる時間です。

まとめて減らせるのは前者だけです。前の節の計測でも、1件あたりの2ミリ秒は1000件ぶんで2.00秒残り続けました。2.04秒という下限はここから来ています。

費用の面

呼び出し回数で課金される仕組みでは、まとめると費用が下がります。前の節では1000回が2回になりました。

呼び出し回数に上限が決まっていることもあります。Google Cloudも、夜間のバッチ処理が1日1テーブルあたり1,500件という既定の上限に当たらないようにすることを推奨するとしています。

まとめられない場合

1. すぐ結果が要る。まとまるまで待てない処理
2. 1件ごとに結果が違う。まとめた返り値から切り分けられない
3. 順番が意味を持つ。まとめると順序が崩れる
4. 1件が大きい。まとめると1回の大きさの上限に当たる

1番目が実務では効きます。利用者が画面の前で待っている処理は、まとめる前に返す必要があります。

バッチ処理でよくある失敗

まとめる数を大きくすればするほど良いと考えることです。失敗したときの戻り方を決めていないと、まとめた数がそのまま被害になります。

バッチ処理でいちばん危ないのは、失敗したときにどうなるかを決めないまま数を増やすことです。

総量は変わらない

まとめる数  失敗する呼び出しの見込み  やり直す件数の見込み
      1件                 20.0回                   20件
     10件                  2.0回                   20件
     50件                  0.4回                   20件
    100件                  0.2回                   20件
    500件                  0.0回                   20件

右端の列を見てください。どのまとめ方でも20件です。やり直す総量は変わりません。

変わるのは一度にどれだけ戻るかです。1件ずつなら20回に分散し、500件ずつなら一度に500件が戻ります。

全部入るか、全部入らないか

まとめた処理が途中で失敗したとき、どこまで反映されているかは仕組みによります。

Google Cloudの読み込み処理は結果が不可分であり、全件が挿入されるか1件も挿入されないかのどちらかになると明記されています。この保証があるなら、やり直しは単純です。

保証がない場合は途中まで入った状態が残ります。やり直すと二重になるので、冪等性が必要になります。詳しくは冪等性の記事で扱っています。

決める順番

1. 固定の手間と1件あたりの時間を測る。まとめる効果はここで決まる
2. 頭打ちになる数を出す。それ以上は増やさない
3. 失敗したときの状態を確かめる。全部戻るのか、途中まで残るのか
4. やり直せる作りにする。二重にならないこと

3番目を確かめずに数を増やすと、まとめた数がそのまま被害の大きさになります。