あるフィンテック企業が、顧客ごとの入出金トランザクションをAmazon SQS Standard QueueとAWS Lambdaで処理するシステムを運用しています。Lambda関数が処理中に失敗してリトライが発生すると

Question

あるフィンテック企業が、顧客ごとの入出金トランザクションをAmazon SQS Standard QueueとAWS Lambdaで処理するシステムを運用しています。Lambda関数が処理中に失敗してリトライが発生すると、同一顧客のトランザクションが順序どおりに処理されないケースや、重複して処理されるケースが報告されています。アーキテクチャの変更を最小限に抑えながら、顧客ごとのトランザクション順序保証と重複排除を実現する方法はどれか。

Accepted Answer

正解: SQS Standard QueueをSQS FIFO Queueに置き換え、MessageGroupIdに顧客IDを、MessageDeduplicationIdにトランザクションIDを設定する。SQS FIFO（First-In-First-Out）Queueは、同一のMessageGroupId内でメッセージが送信された順に処理されることを保証します。顧客IDをMessageGroupIdに設定することで、顧客ごとのトランザクション順序が厳密に維持されます。また、MessageDeduplicationIdにトランザクションIDを設定すると、5分間のデデュプリケーションウィンドウ内での重複メッセージが自動排除されます。Lambda関数のコード変更は不要で、キューの置き換えとプロデューサー側のパラメータ追加のみで両問題を解決できます。

選択肢BのDynamoDBを使った重複チェックはアプリケーション改修が必要なうえ、SQS Standard Queueでは順序保証が提供されないため、順序問題は根本的に解消されません。
選択肢CのKinesis Data Streamsはシャード内の順序保証が可能ですが、SQSとAPIが異なりプロデューサー・コンシューマー双方に大幅な改修が必要で、最小限の変更という要件に反します。
選択肢DのVisibility Timeoutの延長とリトライ無効化は障害時の重複処理を抑制しますが、順序保証も重複排除も解決せず、失敗メッセージのロストリスクを高めます。

Answer

SQS Standard Queueを継続利用し、DynamoDBに処理済みトランザクションIDを保存してLambda関数内で重複チェックを実装する — DynamoDBによる重複チェックはLambda関数の改修が必要。さらにSQS Standard Queueでは順序保証が提供されないため、トランザクション順序の問題は根本的に解消されない。

Answer

SQS Standard QueueをAmazon Kinesis Data Streamsに置き換え、顧客IDをパーティションキーに設定してシャード単位の順序保証を活用する — KinesisはSQSと異なるAPIを持ち、プロデューサー・コンシューマー双方の大幅な改修が必要。最小限の変更という要件に反するうえ、FIFO Queueと比べて構成が複雑になる。

Answer

SQS Standard QueueのVisibility Timeoutを大幅に延長し、Lambda関数のリトライを無効化してデッドレターキューに失敗メッセージを転送する — Visibility Timeoutの延長は同一メッセージの重複処理機会を減らすが排除はできず、リトライ無効化は障害時のメッセージロストリスクを高める。順序保証も重複排除も解決しない。

解説

解説