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