はじめに
AWSを学習する中で、Amazon SQS（Simple Queue Service）について触れる機会がありました。
その中でも、処理に失敗したメッセージを扱うための仕組みであるDLQ（Dead Letter Queue）が気になったので、実際にメッセージの処理を失敗させて、どのような動きをするのか検証してみました。
今回は自分自身の備忘録も兼ねて、SQSのDLQについて簡単にまとめます。
SQSとは
Amazon SQS（Simple Queue Service）は、アプリケーション間でメッセージをやり取りするためのキューイングサービスです。
送信側がキューにメッセージを登録し、受信側がそのメッセージを取得して処理する、といった使い方ができます。
DLQとは
DLQ（Dead Letter Queue）は、何度処理しても失敗してしまうメッセージを通常のキューから切り離して保持しておくための仕組みです。
例えば、キューから取得したメッセージの処理に失敗すると、そのメッセージは再度処理対象になります。
もし処理に失敗する原因が解消されないまま何度も再処理されると、同じメッセージが繰り返し処理されてしまいます。
そこで、一定回数処理に失敗したメッセージをDLQへ移動させることで、通常の処理から切り離すことができます。
最大受信回数maxReceiveCount について
DLQを設定する際に重要になるのが maxReceiveCount です。
これは、メッセージを何回受信したらDLQへ移動させるかを設定する値です。
今回は検証を簡単にするため、
maxReceiveCount = 2
として検証しました。
実際に検証してみる
今回は以下の流れで検証しました。
- DLQ用のSQSキューを作成する
- 通常のSQSキューを作成する
- 通常のキューにDLQのARNを設定する
- maxReceiveCountを2に設定する
- 通常のキューへメッセージを送信する
- メッセージを受信する
- あえて処理を失敗させる
- 再度メッセージを受信する
- 再び処理を失敗させる
- DLQへメッセージが移動することを確認する
実際に処理を失敗させてみたところ、設定した回数に達した後、メッセージがDLQへ移動することを確認できました。
検証して分かったこと
今回の検証を通して、DLQは単純に「失敗したメッセージを保存する場所」ではなく、
問題のあるメッセージを通常の処理から切り離すための仕組み
ということが分かりました。
例えば、処理に失敗する原因が解消されないままメッセージを何度も処理し続けると、同じ処理が繰り返されることになります。
DLQを利用することで、一定回数失敗したメッセージを通常のキューから切り離し、あとから原因を調査するといった対応ができます。
DLQのイメージ
今回の検証を簡単に図にすると、以下のようなイメージです。
通常キュー
│
│ メッセージ受信
▼
処理
│
├─ 成功 → 処理完了
│
└─ 失敗
│
▼
再度受信
│
├─ 成功 → 処理完了
│
└─ 失敗
│
▼
DLQ
今回は maxReceiveCount = 2 としたため、2回受信した後に処理が失敗するとDLQへ移動することを確認しました。
AWSの仕組みを実際に触ってみて
今回初めてSQSとDLQを検証してみて、個人的に面白いと感じたのが、障害が発生した場合のことまで考えられた仕組みが用意されていることでした。
単純に「処理に失敗したらもう一度処理する」というだけでは、場合によっては同じメッセージを何度も処理し続けてしまう可能性があります。
DLQを利用することで、一定回数失敗したメッセージを別のキューへ退避できます。
実際に処理を失敗させてみることで、ドキュメントを読むだけでは分かりにくかったSQSとDLQの関係を理解することができました。
まとめ
今回は、SQSのDLQについて実際に処理を失敗させながら検証してみました。
今回確認できたポイントは以下です。
- SQSはメッセージを一時的に保持して受け渡すためのサービス
- DLQは処理に失敗したメッセージを通常のキューから切り離すための仕組み
- 最大受信回数
maxReceiveCountでDLQへ移動するまでの受信回数を設定できる - 実際に処理を失敗させることで、DLQへ移動する動きを確認できた
AWSを触り始めたばかりなので、今後も実際に手を動かしながら、学んだことを備忘録として残していきたいと思います。