冪等性・ジョブキュー・使用量台帳：繰り返し実行しても結果を守る運用設計

運用サービスには同じリクエストが何度も届きます

ユーザーがボタンを二度クリックしたり、ネットワークが切断されてクライアントがリクエストを再送したりすることがあります。サーバーレス関数も、処理の途中で終了した後に再実行される場合があります。このような環境で、1回のリクエストが2件のジョブや使用量の二重差し引きにつながると、結果を信頼しにくくなります。

冪等性とは、同じ意図のリクエストが繰り返されても、最終的な効果が一度だけ発生する性質です。SAGでは、生成・実行リクエストに論理的な冪等性キーを紐付け、処理中または完了済みのキーであれば既存の結果を返す構成を採用しています。

ジョブの状態を明示的に管理する

時間のかかるチェックはリクエスト内で完了させるより、ジョブキューに渡して状態を管理する方が安全です。

• queued：実行を待機している状態
• running：ワーカーが処理中の状態
• succeeded：結果と精算が完了した状態
• failed：再試行可能な失敗状態
• dead-letter：自動再試行の上限を超え、運用担当者による確認が必要な状態

状態遷移はデータベース内で原子的に処理し、2つのワーカーが同じジョブを同時に取得しないようにする必要があります。再試行回数と次回実行時刻もあわせて記録すれば、一時的な外部障害と継続的なエラーを区別できます。

使用量は数値ではなく台帳に記録します

現在の使用量の数値だけを上書きすると、いつ、どのジョブによって増加したのかを確認しにくくなります。使用量台帳には、予約、確定、取消をそれぞれ個別の記録として残します。ジョブの開始時に使用量を上限枠から予約し、成功したら確定し、実行前に失敗した場合は予約を取り消します。同じジョブキーの精算は一度だけ許可します。

失敗も含めた運用検証

正常に成功するケースに加えて、重複送信、ワーカー間の競合、上限超過、失敗後の再試行、完了後の同一リクエストもテストする必要があります。冪等性と台帳はユーザーから見える機能ではありませんが、「ボタンは一度しか押していないのに、なぜ二回差し引かれたのですか？」といった運用上の事故を防ぐ、重要なアーキテクチャです。

トピック別の技術参考資料

• PostgreSQLのトランザクション分離

この技術をさらに読み進める方法

テナント権限、ジョブの再試行、キャッシュ、承認履歴について確認します。

• 安定した顧客スペースの設計
• 機能案内FAQ