失敗しやすいバッチ処理を安定化する改善手順
夜間バッチが途中で止まっていて、朝出社したエンジニアが手動でリカバリから一日を始める——。「バッチが落ちてました」の一言で、当日の予定が全部吹き飛ぶ現場を何度も見てきました。集計が翌朝までに終わらずレポートが遅延する、請求バッチが一部だけ実行されて金額がずれる、といった相談も少なくありません。この記事では、失敗しやすいバッチ処理をなぜそうなるのかから整理し、安定化までの具体的な手順を解説します。
なぜバッチは「気づいたら壊れている」のか
Webアプリの障害は画面やAPIのエラーとしてすぐ表面化しますが、バッチ処理は違います。深夜に人が見ていない時間帯に動き、失敗しても誰も気づかないまま翌朝を迎えることが珍しくありません。しかも失敗の影響範囲が分かりにくく、「どこまで処理が進んで、どこから止まったのか」を調べるだけで午前中が終わることもあります。
さらに厄介なのは、バッチ処理は事業が成長するほど扱うデータ量が増え、当初は数分で終わっていた処理が気づけば数時間かかるようになっている点です。設計時の前提(データ量・処理時間・依存サービスの応答速度)が崩れているのに、コード自体は当時のまま、というギャップが失敗の温床になります。
よくある失敗原因を洗い出す
バッチ処理が不安定な現場では、次のような原因が複合していることがほとんどです。1つずつ確認してみてください。
- 冪等性がない: 同じ処理を2回実行すると、データが重複したり金額が二重計上されたりする。失敗後の再実行が怖くて手動でDBを直すしかない
- エラーで全体が止まる: 1件のデータ不備・1件のAPI呼び出し失敗で処理全体が例外停止し、正常に処理できたはずの残り9,999件も含めて未完了になる
- リトライの仕組みがない: 外部APIやDBへの一時的な接続エラーで即座に失敗し、数秒待てば成功したはずの処理までやり直しになる
- 監視・通知がない: バッチが失敗しても誰にも通知が飛ばず、気づくのは翌朝の担当者か、もっと悪い場合は顧客からの問い合わせが最初
- 処理が巨大で分割されていない: 数百万件を1つのトランザクション・1つのプロセスで処理しており、途中で落ちると最初からやり直しになる。処理時間も長く、夜間バッチの時間枠に収まらなくなりつつある
これらは独立した問題ではなく、たいてい絡み合っています。冪等性がないから再実行が怖い、再実行が怖いから全件やり直す設計になっている、全件やり直すから処理時間が長い、処理時間が長いから時間枠を超えて後続バッチとぶつかる、という悪循環です。
安定化の第一歩は「今どこで何件失敗しているか」を見えるようにする
原因を直す前に、まず現状を可視化します。可視化なしに手を入れると、直したつもりの箇所が実は主要因ではなかった、ということが起こります。
- 各バッチの開始・終了・処理件数・成功件数・失敗件数をログまたはDBに記録する
- 失敗時にSlack等へ即座に通知する仕組みを入れる(この考え方は監視がない本番システムを改善する最初の一歩でも詳しく解説しています)
- 直近数週間分の実行ログを集計し、「どのバッチが」「どのくらいの頻度で」「どの処理ステップで」失敗しているかを一覧化する
この段階だけでも、体感で「よく落ちる」と思っていたバッチが実は別のバッチの後始末をしていただけだった、といった発見があります。感覚ではなく数字で優先順位をつけることが、限られた工数を正しい箇所に投じる前提になります。
冪等化: 再実行を「怖くない」ものにする
安定化の中で最も効果が大きいのが冪等化です。冪等性とは、同じ処理を何度実行しても結果が変わらない性質のことです。これがあると、失敗した箇所から気軽に再実行できるようになり、深夜の緊急対応や手動でのデータ修正が不要になります。
具体的な実装方法はいくつかあります。
- 処理済みフラグ・処理済みIDの記録: 各レコードに処理済みかどうかを記録し、再実行時は未処理分だけを対象にする
- ユニークキー制約による重複防止: 請求や決済のような「二重実行されると実害が出る」処理には、DB側で重複を機械的に弾く制約を設ける
- UPSERT(あれば更新・なければ挿入)の活用: 集計系バッチは新規INSERTではなくUPSERTにすることで、再実行しても結果が変わらない設計にできる
冪等化は一度に全バッチへ適用する必要はありません。まず「失敗頻度が高い」「失敗時の被害が大きい(請求・在庫など)」バッチから着手するのが現実的です。
分割・リトライ・監視で「止まらない・気づける」仕組みにする
冪等化と並行して、次の3つを整えます。
- 単位を小さく分割する: 数百万件を1トランザクションで処理するのではなく、数千件単位のチャンクに分割して処理する。1チャンクの失敗が全体を止めなくなり、失敗箇所の特定も「どのチャンクで止まったか」まで絞り込める
- 一時的なエラーはリトライ、恒久的なエラーはスキップして記録: 外部API呼び出しやDB接続エラーなど一過性の失敗は指数バックオフ付きで数回リトライする。一方でデータ不備などリトライしても直らないエラーは、その1件だけスキップして処理を継続し、後で確認できるよう記録に残す。この「止めるべきエラー」と「止めるべきでないエラー」の切り分けが、全体停止を防ぐ鍵になります
- 失敗・遅延・異常な処理件数をアラート化: 失敗件数が閾値を超えた、処理時間が普段の2倍を超えた、想定件数と大きく乖離している、といった異常を検知したら即座に通知する
この3つが揃うと、バッチは「1件の不備で全滅する脆いもの」から「一部が失敗しても自動でリトライ・継続し、深刻な異常だけ人に知らせるもの」に変わります。
進め方: 全部を一度に直そうとしない
バッチ処理の改善で失敗しやすいのは、「全バッチを理想形に作り直す」という計画を立てて、着手する前に息切れすることです。実務的には次の順番で進めるのが現実的です。
- まず可視化(ログ・通知)を入れ、失敗の実態を数字で把握する
- 失敗頻度・被害の大きさで優先順位をつけ、影響が大きいバッチから冪等化する
- 冪等化したバッチから順に、分割・リトライ・アラートを整備する
- 落ち着いたら、処理時間が時間枠に収まらなくなりつつあるバッチを設計から見直す
外部の目で改善する場合も、いきなり全体を作り直すのではなく、まず現状のバッチ構成とログを確認し、どこから着手すべきかを診断するところから始めます。バッチ処理は障害と違って画面に出ないぶん後回しにされがちですが、既存プロダクトの改善、外部チームが最初に見る観点で挙げているような「運用中に実際に問題が起きている箇所」を優先する考え方は、バッチ改善にもそのまま当てはまります。
まとめ
- バッチ処理が頻繁に失敗する背景には、冪等性なし・全停止しやすい設計・リトライなし・監視なしが複合していることが多い
- まず可視化で失敗の実態を数字にし、被害が大きい・頻度が高いバッチから冪等化、続いて分割・リトライ・アラートを整備するのが現実的な順番
- 全バッチを一度に理想形へ作り直そうとせず、優先順位をつけて段階的に安定化させる
夜間バッチの失敗リカバリに毎朝時間を取られている場合、torcheees では「既存プロダクト改善 診断」として、現状のバッチ構成・失敗傾向を確認し、安定化の優先順位と概算費用をご提示します。保守・運用のサービスとして継続的な改善支援も行っています。まずはお問い合わせフォームからご相談ください。