夜間バッチはAWSで速くなるのか — 速くなる条件・遅くなる条件

オンプレで8時間かかる夜間バッチはAWSに移すと何時間になるか——答えは「設計次第で3時間にも12時間にもなる」です。無責任に聞こえますが、速くなる条件と遅くなる条件は明確に分かれています。移行前に自分の環境がどちらか判定できるように整理します。

01速くなる条件①：ボトルネックがストレージI/Oだった

オンプレの夜間バッチの多くは、CPUではなくディスクI/Oで詰まっています。HDDのRAIDグループ（実効数百IOPS）で頭打ちだった処理は、gp3やio2に載せ替えるだけでI/O上限が一桁上がり、素直に速くなります。ただしボリューム側のIOPSを上げても、インスタンス側のEBS帯域上限（インスタンスタイプ・サイズに依存）がボトルネックにならないか確認が必要です。まず現行環境で「バッチ中のCPU使用率とI/O待ち」を実測してください。CPUが遊んでいてI/O待ちが長いなら、期待できます。

02速くなる条件②：時間帯だけ大きくする

クラウドの本領はここです。バッチが走る数時間だけインスタンスを大きくし、終わったら戻す（または止める）。オンプレでは「ピークに合わせて買って、昼間は遊ばせる」しかなかった設備投資が、従量課金では時間単位の意思決定になります。ただしインスタンスタイプの変更には対象インスタンスの停止が必要で（無停止のその場リサイズはできません）、SSM Automation＋スケジュールでこの停止→タイプ変更→起動のシーケンスを自動化できます。

03速くなる条件③：並列化できる処理構造

店舗別・支社別・月別のように分割できる処理なら、Step FunctionsのMapステートやAWS Batchで並列実行し、「8時間×1本」を「1時間×8並列」にできます。ただしこれは処理構造の改修を伴うので、移行パターンでいう書き換え系の話です。効果は大きいが、タダではありません。

04遅くなる典型：ハイブリッドの「またぎ」

最も多い劣化パターンは、アプリ（またはバッチ）だけAWSに移してDBがオンプレに残った構成です。1件ごとにSELECT/UPDATEを繰り返すバッチは、往復レイテンシ（10〜20ms）×実行回数がそのまま加算されます。100万回の往復なら、それだけで数時間の悪化です。

05判定の手順

• ① 現行バッチのボトルネック実測（CPU／I/O待ち／DB待ちの内訳）
• ② I/OバウンドならEBS設計で解決見込み。CPUバウンドなら時間帯スケールアップを設計
• ③ データソースとの位置関係を確認（またぎが発生しないか）
• ④ 本番同等データで1周実測してから本番切替を判定——カタログ性能での見切り発車は禁物