Amazon SQS FIFO 대기열에 대한 처리량 증가 및 DLQ(Dead Letter Queue) 리드라이브 지원 발표

Amazon Simple Queue Service(Amazon SQS)를 사용하면 볼륨에 상관없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장 및 수신할 수 있습니다. 오늘 Amazon SQS는 선입선출(FIFO) 대기열을 위한 두 가지 새로운 기능을 도입했습니다.

• 일부 AWS 리전에서는 최대 처리량이 API 작업당 70,000TPS(초당 트랜잭션)까지 증가하여, 일괄 처리를 통해 초당 최대 700,000개의 메시지를 보내거나 받을 수 있습니다.
• DLQ(Dead Letter Queue) 리드라이브는 표준 대기열에서 이미 사용할 수 있었던 것과 유사한 방식으로 특정 횟수의 재시도 후에도 소비되지 않는 메시지를 처리할 수 있도록 지원합니다.

이러한 기능이 실제로 어떻게 작동하는지 좀 더 자세히 살펴보겠습니다.

FIFO 대기열 처리량이 최대 7만 TPS까지 증가
FIFO 대기열은 메시지가 전송된 순서대로 정확히 한 번 처리되어야 하는 애플리케이션을 위해 설계되었습니다. 표준 대기열의 처리량은 무제한이지만 FIFO 대기열에는 API 작업당 TPS 수에 상한이 있습니다.

표준 및 FIFO 대기열은 단일 API 호출로 최대 10개의 메시지를 보내고 받을 수 있는 일괄 작업을 지원합니다(최대 총 페이로드 256KB). 즉, FIFO 대기열은 최대 처리량보다 초당 최대 10배 더 많은 메시지를 처리할 수 있습니다.

2016년 출시 당시 FIFO 대기열은 API 작업당 최대 300TPS(일괄 처리 시 초당 3,000개 메시지)를 지원했습니다. 이 정도면 많은 사용 사례에 충분했지만 일부 고객은 더 많은 처리량을 요구했습니다.

2021년에 고처리량 모드가 출시되면서 FIFO 대기열의 최대 처리량이 10배 증가했으며 리전에 따라 API 작업당 최대 3,000TPS까지 처리할 수 있었습니다. 일년 후 이 할당량은 두 배로 늘어 API 작업당 최대 6,000TPS가 되었습니다.

올해 Amazon SQS는 이미 FIFO 대기열 처리량 할당량을 두 번 늘렸습니다(리전에 따라 8월에는 API 작업당 최대 9,000TPS, 10월에는 API 작업당 최대 18,000TPS).

현재 Amazon SQS 팀은 FIFO 대기열 처리량 할당량을 더 늘려 미국 동부(버지니아 북부), 미국 서부(오레곤), 유럽(아일랜드) 리전에서 API 작업당 최대 70,000TPS(일괄 처리로 초당 최대 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로 구성하고 메시지가 소스 대기열에서 DLQ로 이동하는 최대 수신 횟수 조건으로 3을 지정합니다.

소비자가 이 조건에 지정된 횟수를 초과하여 메시지를 수신한 경우 Amazon SQS는 해당 메시지를 DLQ로 이동합니다. 원본 메시지 ID는 유지되며 메시지를 고유하게 추적하는 데 사용할 수 있습니다.

이 설정을 테스트하기 위해 콘솔을 사용하여 소스 대기열에 메시지를 보냅니다. 그런 다음 AWS Command Line Interface(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초).

세 번째 이후에는 메시지가 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 콘솔을 사용하여 DLQ에서 메시지를 리드라이브할지 아니면 몇 달 전에 도입된 새로운 리드라이브 API를 사용할지 결정할 수 있습니다. 이 예에서는 콘솔을 사용해 보겠습니다. Amazon SQS 콘솔로 돌아와 DLQ 대기열을 선택하고 DLQ 리드라이브 시작을 선택합니다.

리드라이브 구성에서는 메시지를 소스 대기열로 리드라이브하기로 선택합니다. 선택적으로 다른 FIFO 대기열을 사용자 지정 대상으로 지정할 수 있습니다. 저는 속도 제어 설정에서 최적화된 시스템을 사용하여 Amazon SQS에 의해 최적화된 초당 최대 메시지 수로 메시지를 리드라이브합니다. 선택적으로 DLQ에 많은 메시지가 있는 경우 소비자 과부하를 방지하기 위해 사용자 지정 최대 초당 메시지 속도를 구성할 수 있습니다.

리드라이브 작업을 시작하기 전에 메시지 검사 섹션을 사용하여 메시지를 폴링하고 확인할 수 있습니다. 무엇을 할지 이미 결정했으므로 DLQ 리드라이브를 선택하여 작업을 시작합니다. 처리할 메시지가 하나밖에 없어서 리드라이브 작업이 매우 빠르게 완료됩니다.

예상대로 메시지가 소스 대기열로 돌아와 다시 처리할 준비가 되었습니다.

주요 사항
FIFO 대기열에 대한 DLQ(Dead Letter Queue) 지원은 현재 Amazon SQS가 제공되는 모든 AWS 리전에서 사용할 수 있습니다. 단, GovCloud 리전과 중국에 기반을 둔 리전은 예외입니다.

DLQ 구성에서 최대 수신 횟수는 1~1,000이어야 합니다.

높은 처리량 모드나 DLQ를 사용하는 데 따른 추가 비용은 없습니다. 모든 Amazon SQS 작업은 요청으로 간주됩니다. 단일 요청으로 1~10개의 메시지를 보내거나 받을 수 있으며, 최대 총 페이로드는 256KB입니다. 요청 수를 기준으로 비용을 지불하며, 요청 요금은 표준 대기열과 FIFO 대기열 간에 다르게 책정됩니다.

AWS 프리 티어의 일부로 표준 대기열의 경우 매월 처음 백만 건의 요청, FIFO 대기열의 경우 매월 처음 백만 건의 요청에 대해 비용이 청구되지 않습니다. 자세한 내용은 Amazon SQS 요금을 참조하세요.

이러한 업데이트와 증가한 처리량을 통해 FIFO 대기열로 대부분의 사용 사례를 처리할 수 있습니다.

Amazon SQS FIFO 대기열을 사용하면 높은 처리량, 정확히 한 번의 처리, 선입선출 전송을 수행할 수 있습니다.

— Danilo