長時間キューワーカーはロックheartbeatだけでなくメッセージvisibilityも延長する
キュー設計
非同期処理
信頼性
判断
運用
排他ロックや処理中状態を持つ長時間キューワーカーでは、アプリ側の heartbeat だけでは正常実行中のジョブを守り切れない。メッセージブローカー側の visibility timeout が切れると、元 worker が生きていても同じ message が再配信され、receive count が進む。redrive 上限が小さいと、正常実行中の message が DLQ に落ち、元 worker がその後落ちたときに復旧用の message が失われる。
判断基準
- 1 回の処理が visibility timeout を超え得る worker は、処理中に現在の receipt handle / delivery token へ visibility を定期延長する。
- DB lock や task heartbeat は「元 worker が生きているか」を判断する材料であり、message の redrive count を止める材料ではない。両方が必要。
- 処理中状態の message が再配信され、既存 heartbeat が新しい場合は、active job と判断して失敗扱いにしない。ただし message を何もせず放置すると receive count が進むため、その再配信分の visibility も延長する。
- active job の再配信 message を削除すると、元 worker が後で落ちたときに再開・失敗確定の入口を失う。削除ではなく visibility 延長を選ぶ。
- visibility timeout や redrive 上限を大きくするだけでは、処理時間上限を仕様化しない限り根本対策になりにくく、障害検知も遅れる。
検証
visibility timeout より長い正常処理を模擬し、処理中に visibility 延長 API が定期実行されることを確認する。さらに、処理中状態の message を再配信として受けたケースで、job を失敗扱いせず、message も削除せず、visibility だけ延長することを確認する。