独自コンシューマーがSQS Standardキューを受信し、通常90秒で処理する。VisibilityTimeoutは30秒で、処理成功後にDeleteMessageを呼ぶ。
ログで、30秒の期限切れ後に別コンシューマーが同じメッセージを受信していることを確認した。失敗時の再試行を残しつつ、この再受信を抑えたい。
最も適切な対策はどれか。
通常処理を覆うVisibilityTimeoutと期限前の延長で、期限切れによる再受信を減らす。成功後の削除と冪等性を維持する。
詳細解説
保持期間はキュー内で保存する期限であり、受信後の非表示期間を延ばさない。
配信遅延は新しく投入されたメッセージの初回可視性に作用し、受信済みメッセージの処理中の期限を延ばさない。
先に削除すると処理失敗時にキューから再試行できなくなり、今回の再試行を残す要件に合わない。
受信後の非表示期間を処理時間に合わせ、成功後に削除する。Standardの重複配信に備える冪等性も引き続き必要である。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料で可視性期限、ChangeMessageVisibility、成功後の削除、Standardの少なくとも1回の配信を確認する。
参考にした公式資料
確認できる内容
120秒の設定が30秒の期限切れを防ぐ理由と、それでも重複処理対策が必要な理由を説明できる。
理解のポイント
- VisibilityTimeout
- 重複取得
- SQSコンシューマー
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
処理時間と再試行の待ち時間を合わせる
通常90秒なら、例として120秒の可視性期間で処理を覆う。長い処理は現在の期限が切れる前にChangeMessageVisibilityで延長し、成功後に受信時のreceipt handleで削除する。長すぎる期限は失敗後の再試行を遅らせる。受信からの最大12時間という上限も延長ではリセットされない。
非表示と重複の完全排除を区別する
Standardキューは少なくとも1回の配信であり、可視性期間中でも重複配信が起こり得る。期間の調整は今回確認した期限切れへの対策で、重複ゼロの保証ではない。注文IDなどで処理済み状態を判定し、再受信しても副作用を重ねない冪等な処理を設計する。