Amazon Web Services ブログ

Amazon SQS FIFO キューのスループットの増加とデッドレターキューの再処理サポートを発表

Amazon Simple Queue Service (Amazon SQS) を利用すると、ソフトウェアコンポーネント間において、任意の量のメッセージを送信、保存、受信できます。11月27日、Amazon SQS では、先入れ先出し (FIFO) キュー用の 2 つの新機能を導入しました。

  • 選択した AWS リージョンでは、最大スループットが API アクションあたり 70,000 件のトランザクション/秒 (TPS) まで増加し、バッチ処理を使用して最大 700,000 件のメッセージ/秒の送受信がサポートされるようになりました。
  • デッドレターキュー (DLQ) の再処理サポートは、標準キューで既に利用可能であったものと同様の方法で、特定の回数にわたって再試行しても消費されないメッセージを処理します。

これらが実際にどのように機能するかをさらに詳しく見てみましょう。

FIFO キューのスループットが最大 70K TPS に増加
FIFO キューは、メッセージを送信された順序で 1 回だけ処理する必要があるアプリケーション向けに設計されています。標準キューのスループットは無制限ですが、FIFO キューには API アクションごとの TPS 数について、上限としてのクォータが設定されています。

標準キューと FIFO キューは、1 回の API 呼び出しで最大 10 件のメッセージを送受信できるバッチアクションをサポートしています (最大合計ペイロードである 256 KB まで)。これは、FIFO キューが、最大スループットの 10 倍のメッセージを 1 秒あたりに処理できることを意味します。

2016 年にリリースされた際、FIFO キューは API アクションあたり最大 300 TPS (バッチ処理を使用した場合は 1 秒あたり 3,000 件のメッセージ) をサポートしていました。多くのユースケースにはこれで十分でしたが、一部のお客様はより多くのスループットを求めていました。

2021 年にリリースされた高スループットモードにより、FIFO キューでは最大スループットが 10 倍に増加し、リージョンに応じて API アクションあたり最大 3,000 TPS を処理できるようになりました。1 年後、そのクォータは 2 倍になり、API アクションあたり最大 6,000 TPS になりました。

今年、Amazon SQS は、既に FIFO キューのスループットクォータを 2 回増加しており、8 月には API アクションあたり最大 9,000 TPS、10 月には API アクションあたり最大 18,000 TPS に増加しました (リージョンに応じて異なります)。

本日、Amazon SQS チームは FIFO キューのスループットクォータを再び増加しました。これにより、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) リージョンで API アクションあたり最大 70,000 TPS (バッチ処理を使用した場合は 1 秒あたり最大 700,000 件のメッセージ) を処理できるようになりました。これは、リリース時の最大スループットの 200 倍超です。

FIFO キューの DLQ 再処理サポート
Amazon SQS を利用すると、特定の回数にわたって再試行されても消費されなかったメッセージを自動的に DLQ に移動できます。そこでメッセージを分析して、メッセージが正しく処理されなかった理由を理解できます。コンシューマーアプリケーションにバグや設定ミスがある場合があります。また、メッセージにソースアプリケーションからの無効なデータが含まれている場合もあります。この場合にメッセージを再処理するには、このデータを修正する必要があります。

いずれの方法でも、これらのメッセージを再処理する計画を定義できます。例えば、コンシューマーアプリケーションを修正し、すべてのメッセージをソースキューに再処理できます。または、カスタムアプリケーションがメッセージを受信し、その内容を修正してからソースキューに送信する専用のキューを作成することもできます。

メッセージをソースキューまたは別のキューに簡単に戻すために、Amazon SQS では再処理タスクを作成できます。再処理タスクは標準キューで既に利用可能です。本日より、FIFO キューでも再処理タスクを開始できるようになりました。

Amazon SQS コンソールを使用して、DLQ として使用する最初のキュー (my-dlq.fifo) を作成します。メッセージを再処理してソース FIFO キューに戻すには、キューのタイプが一致しなければならないため、これも FIFO キューになります。

その後、ソース FIFO キュー (my-source-queue.fifo) を作成して、通常どおりメッセージを処理します。ソースキューを作成する際には、最初のキュー (my-dlq.fifo) を DLQ として設定し、[最大受信数] 条件として 3 を指定します。この条件に基づいて、メッセージはソースキューから DLQ に移動されます。

コンソールのスクリーンショット。

この条件で指定された回数を超えてメッセージがコンシューマーによって受信されると、Amazon SQS はメッセージを DLQ に移動します。元のメッセージ ID は保持され、メッセージを一意に追跡するために使用できます。

この設定をテストするために、コンソールを使用してメッセージをソースキューに送信します。その後、AWS コマンドラインインターフェイス (AWS CLI) を使用して、メッセージを削除せずに複数回受信します。

aws sqs receive-message --queue-url https://sqs.eu-west-1.amazonaws.com/123412341234/my-source-queue.fifo
{
    "Messages": [
        {
            "MessageId": "ef2f1c72-4bfe-4093-a451-03fe2dbd4d0f",
            "ReceiptHandle": "...",
            "MD5OfBody": "0f445a578fbcb0c06ca8aeb90a36fcfb",
            "Body": "My important message."
        }
    ]
}

同じメッセージを複数回受信するには、キュー可視性タイムアウトで指定された時間が経過するまで待ちます (デフォルトは 30 秒)。

4 回目以降、メッセージは DLQ に移動されているため、ソースキューには存在しません。ソースキューからメッセージを受信しようとしても、リストは空です。

aws sqs receive-message --queue-url https://sqs.eu-west-1.amazonaws.com/123412341234/my-source-queue.fifo
{
    "Messages": []
}

メッセージが移動されたことを確認するために、DLQ をポーリングしてメッセージがそこに存在しているかどうかを確認します。

aws sqs receive-message --queue-url https://sqs.eu-west-1.amazonaws.com/123412341234/my-dlq.fifo  
{
    "Messages": [
        {
            "MessageId": "ef2f1c72-4bfe-4093-a451-03fe2dbd4d0f",
            "ReceiptHandle": "...",
            "MD5OfBody": "0f445a578fbcb0c06ca8aeb90a36fcfb",
            "Body": "My important message."
        }
    ]
}

メッセージが DLQ に移動されたので、メッセージが処理されなかった理由を調査し (今回は理由がわかりました)、Amazon SQS コンソールまたは数か月前に導入された API を使用して DLQ からメッセージを再処理するかどうかを決定できます。この例では、コンソールを使用します。Amazon SQS コンソールに戻り、DLQ キューを選択して、[DLQ 再処理の開始] を選択します。

[再処理の設定] で、メッセージをソースキューに再処理することを選択します。オプションで、別の FIFO キューをカスタムの宛先として指定できます。[速度コントロール設定][システム最適化] を使用して、Amazon SQS によって最適化された 1 秒あたりの最大メッセージ数でメッセージを再処理します。オプションで、DLQ 内に多数のメッセージがある場合、コンシューマーの過負荷を避けるために 1 秒あたりのメッセージのカスタム最大レートを設定できます。

コンソールのスクリーンショット。

再処理タスクを開始する前に、[メッセージを検査] セクションを使用してメッセージをポーリングし、チェックします。何をするかは既に決めているので、[DLQ 再処理] を選択してタスクを開始します。処理するメッセージは 1 件だけなので、再処理タスクは非常に早く完了します。

コンソールのスクリーンショット。

想定どおり、メッセージはソースキューに戻り、再度処理できる状態になっています。

コンソールのスクリーンショット。

留意点
FIFO キューのデッドレターキュー (DLQ) サポートは、GovCloud リージョンと中国に拠点を置くリージョンを除き、Amazon SQS が提供されているすべての AWS リージョンで現在ご利用いただけます。

DLQ 設定では、最大受信数は 1~1,000 である必要があります。

高スループットモードまたは DLQ の使用に追加コストはかかりません。すべての Amazon SQS アクションはリクエストとしてカウントされます。1 件のリクエストで、最大合計ペイロードである 256 KB まで、1~10 件のメッセージを送受信できます。リクエスト数に基づいて料金が発生し、標準キューと FIFO キューではリクエストの料金が異なります。

AWS 無料利用枠の一部として、標準キューで 1 か月あたり最初の 100 万件のリクエスト、FIFO キューで 1 か月あたり最初の 100 万件のリクエストについては料金は発生しません。詳細については、「Amazon SQS の料金」をご覧ください。

これらの更新とスループットの増加により、FIFO キューを使用してほとんどのユースケースに対応できます。

Amazon SQS FIFO キューを使用して、高スループット、1 回限りの処理、先入れ先出し配信を実現しましょう。

Danilo

原文はこちらです。