第28回: バッチ処理の分割と再開戦略 — 「途中で止まったバッチ」をゼロから再実行していませんか?
100万件のデータを処理するバッチが、90万件まで進んだところでメモリエラーで止まった——残り10万件のためにゼロから再実行するのは、時間もコストもかかります。
現代のWeb開発者へ。基礎文法からアーキテクチャまで、体系的に学べる技術ガイド。
# User.php
public function init() {
$this->role = 'Architect';
return 'Ready to build';
}
100万件のデータを処理するバッチが、90万件まで進んだところでメモリエラーで止まった——残り10万件のためにゼロから再実行するのは、時間もコストもかかります。
定期バッチが何らかの理由で二重起動された場合——同じデータが2回送信される、請求が重複する、集計値がずれる——こうした事故が起きた経験はありませんか?
新機能を本番に出した瞬間、全ユーザーに影響が広がる——問題が起きてからロールバックするには遅すぎます。
Sentry を導入したものの、通知が大量に飛んできて結局スルーしている——こういった状況になっていませんか?
本番障害の対応中、ログを grep で探し回っても欲しい情報が見つからない——そんな経験はありませんか?
開発中、意図しないクエリが走っている、ジョブがどこかで失敗している、例外が静かに飲み込まれている——こうした問題をログファイルを grep しながら追っていませんか?
ユーザーから「動作が重い」と報告を受けても、どのエンドポイントが、どのタイミングで、どれくらい遅いのか——数値で答えられない状況になっていませんか?
Octaneはworkers数やmax-requestsの設定が指数関数的に性能に影響します。「とりあえず4」で動いている場合、本来のもっと出せるスループットを見逃しているかもしれません。
人気ランキングのキャッシュが失効した瞬間、100件のリクエストが同時にDBへ走ったとしたら——あなたのアプリは耐えられますか?
「茇くて導入」のキャッシュは、数日後に「古いデータが返る」「更新したはずなのに反映されない」といった整合性問題の源になります。キャッシュは設計するものです。