SQSのローカル開発環境用として構築したElasticEQでデッドレターキューを使ってみよう

前回の記事でSQSのローカル開発環境用としてElasticMQを使ってみました。 今回はElasticMQでデッドレターキューについて学んでみましょう。

デッドレターキューとは

デッドレターキューは、メッセージの処理に失敗した場合に、そのメッセージを別のキューに移動する機能です。

デッドレターキューが必要な理由

デッドレターキューを使用する主な理由は、メッセージの送信に失敗した場合に、そのメッセージを再処理するためです。

メッセージの送信に失敗する理由はさまざまなものがありますが、失敗する理由によっては、何回も再処理しても成功しない場合があります。 キュー型のシステムでは、先頭にあるメッセージから順番に処理されるため、失敗したメッセージが先頭にあると、そのメッセージが再処理されるたびに、他のメッセージが処理されないという問題が発生します。

そのような問題を解決するために、デッドレターキューを使用します。

デッドレターキューの設定

アプリコードで何かしらの分岐や処理を書く必要があるのかと思われるかもしれませんが、elasticmq.confという設定ファイルを使って詳細な設定ができます。

今回は、通常キューとしてtestを作成し、デッドレターキューとしてtest-dead-lettersを作成する例を紹介します。

queues {
    test {
        deadLettersQueue = {
            name = "test-dead-letters"
            maxReceiveCount = 3
        }
    }

    test-dead-letters { }
}

通常キューのtest内でdeadLettersQueue { ... }を使ってデッドレターキューの設定をします。

• name：デッドレターキューの名前
• maxReceiveCount：メッセージを受信した回数がこの値を超えると、デッドレターキューに移動されます

デッドレターキューの動作確認

今回はコンテナを使ってElasticMQを起動するため、compose.ymlを作成します。

services:
  elasticmq:
    image: softwaremill/elasticmq:latest
    ports:
      - "9324:9324"
      - "9325:9325"
   volumes:
     - ./elasticmq.conf:/opt/elasticmq.conf

ファイルの変更が終わったら、コンテナを起動します。

docker compose up -d

コンテナの起動ができたらhttp://localhost:9325/にアクセスして、ElasticMQの管理画面が表示されることを確認します。

次に、デッドレターキューの動作確認を行います。まずは、通常キューにメッセージを送信します。

aws sqs send-message --queue-url http://localhost:9324/queue/test --message-body "ElasticMQ Test Message" --endpoint-url http://localhost:9324

今回は3回取得してデッドレターキューに移動する設定にしているため、3回メッセージを取得してみます。

aws sqs receive-message --queue-url http://localhost:9324/queue/test --endpoint-url http://localhost:9324

1回目の取得

取得後に一時的にメッセージが不可視になるため、キューが復活するまで待ちます。

2回目の取得

3回目の取得

4回目の取得

4回目に取得しようとすると、デッドレターキューに移動されることが確認できます。

おわりに

今回デッドレターキューを設定したことで実際の環境に近い形で開発環境を準備することができました。 これで開発が捗りそうですね。