[AWS] Amazon SQS

Notice

티스토리 블로그 시작!

Recent Posts

Recent Comments

관리 메뉴

안녕세계

[AWS] Amazon SQS 본문

[AWS] Amazon SQS

Junhong Kim 2023. 11. 30. 22:20

728x90

SQS (Simple Queue Service)

SQS는 분산된 큐(Distributed Queues)에 메시지를 저장하고 전달하는데 사용됩니다. 이때, SQS에서 사용되는 큐가 "분산된 큐" 라는 점이 중요합니다. AWS 분산 메시징 시스템에는 Component, Queue(Amazon SQS 서버들에 분산됨), Message 세 가지로 구성되어 있습니다. 다음 이미지에서 A~E 메시지가 SQS 서버에 저장될 때 동일한 메시지가 다수의 Amazon SQS 서버에 중복 저장하고 있는 것을 볼 수 있습니다. 즉, 분산된 큐란 하나의 메시지를 다수의 SQS 서버에 분산하여 중복 저장되는 것을 의미합니다.

SQS에서 사용되는 Queue(대기열)는 Standard Queue(표준 대기열) 또는 FIFO Queue(FIFO 대기열)를 사용하여 메시지를 대기할 수 있으며 목적에 따라 적절한 대기열을 사용해야합니다.

SQS Message

SQS 큐에 있는 메시지는 `Consumer가 SQS 큐에 메시지를 요청하여 받아가는 방식인 Polling 방식`으로 메시지가 전달됩니다. Consumer가 Poll 방식으로 메시지 받아가서 소비 후 확인 응답을 SQS에 보내주게되면 해당 메시지는 Queue에서 삭제됩니다.

Standard Queue VS FIFO Queue

SQS에서는 큐를 Standard Queue(표준 대기열)와 FIFO Queue(FIFO 대기열) 두 가지 중 하나를 선택할 수 있습니다.

Standard Queue는 일반적인 대기열 방식으로 순서와 상관없이 메시지가 처리됩니다. 따라서, Standard Queue는 처리 순서와 상관없는 애플리케이션에서 주로 사용됩니다. 또한, Standard Queue는 큐에 메시지를 최소 한번 전달하기 때문에 중복 항목이 큐에 삽입 될 수 있습니다. (메시지가 중복 수신되는 케이스는 조금 아래에서 알아봅니다)

반면에 FIFO Queue는 메시지가 들어온 순서대로 처리됩니다. 또한, FIFO Queue는 중복 항목을 큐에 삽입하지 않으므로 메시지가 중복 전달되지 않습니다. 따라서, FIFO Queue는 순서 처리 되어야하고 중복이 발생하지 않아야하는 애플리케이션에서 사용됩니다.

DLQ (Dead Letter Queue)

일반적으로 메시지는 Consumer 요청에 따라 처리될 때 까지 계속 메시지를 보냅니다. 이 경우 앞에 있는 메시지 처리가 안되어 이후 메시지 처리까지 영향을 주게 됩니다. 따라서, 메시지를 계속해서 보냈지만 컨슈머가 메시지 처리 응답을 보내지 않으면 일정 횟수 이상 시도후 처리되지 못한 메시지는 DLQ로 이동되어 보관됩니다.

SQS Visibility Timeout

컨슈머가 큐에서 메시지를 수신하고 처리하는 동안에는 메시지는 큐에 계속 존재합니다. 왜냐하면 네트워크 문제 또는 컨슈머 애플리케이션 이슈로 인해 메시지를 재수신 해야 할 수 도 있기 때문에 컨슈머가 SQS에서 메시지를 수신한 즉시 삭제하지 않습니다. 메시지는 컨슈머가 메시지 수신 후 처리가 완료된 이후 SQS 완료 응답을 보내주면 큐에서 메시지가 삭제됩니다.

다시 돌아와서 컨슈머가 메시지 수신 후 처리 중인 경우 아직 큐에서 삭제되지 않기 때문에, 큐에 아직 메시지가 남아 있습니다. 따라서 이미 한 컨슈머가 메시지를 처리하고 있는 중에 다른 컨슈머가 동일한 메시지를 수신하여 처리하지 못하도록 하기 위해서 Visibility Timeout(표시제한 시간)을 설정하여 메시지가 다른 컨슈머가 볼 수 없게 할 수 있습니다. 메시지의 default 표시제한 시간은 30초이며, 최소 0초 ~ 최대 12시간까지 설정이 가능합니다.

SQS 메시지 중복 수신

SQS Visibility TImeout 까지 알아보았으니 메시지가 중복 수신될 수 있는 케이스에 대해 알아봅니다.

1. 메시지 처리 시간보다 Visibility Timeout이 짧은 경우
한 컨슈머가 메시지를 처리 시간이 길어서 메시지 처리하는 도중 Visibility Timeout을 초과하여 다른 컨슈머에게 메시지가 보여질 수 있습니다. FIFO Queue는 메시지를 중복 저장하지 않지만,Standard Queue는 메시지를 분산 SQS 서버에 메시지를 중복합니다. 또한, Standard Queue는 순차처리 하지 않으므로 운이 좋지 않으면 Visibility Timeout을 초과할 때 다른 컨슈머가 중복된 메시지를 수신할 수 있습니다.

2. Visibility Timeout을 설정하는 순간 다발적으로 요청이 들어온 경우
한 컨슈머가 메시지를 수신하여 Visibility Timeout을 설정하려는 순간에 다른 메시지 전달 요청이 들어와서 메시지가 전달되는 경우 메시지가 중복 수신될 수 있습니다. 이 케이스는 Visibility Timeout의 시간과 상관없이 메시지가 중복 수신될 여지가 있습니다. 이 경우도 역시 분산 SQS 서버에 메시지가 중복 저장되는 Standard Queue에서 드믈지만 발생할 가능성이 있습니다.

따라서, Standard Queue를 사용할 경우 메시지가 중복 수신될 수 있으므로 메시지 중복이 발생하지 않아야한다면 메시지 소비시 컨슈머 애플리케이션에서 방어 로직을 작성하여 중복으로 메시지를 수신하더라도 서비스에 영향이 없도록 해야합니다.

Short Polling VS Long Polling

Polling은 앞서 말한 것 처럼 SQS Queue로부터 메시지를 가져오는 방법입니다. Polling은 Short Polling과 Long Polling 방법이 있으며 default 폴링 방법은 Short Polling 입니다. Short Polling은 컨슈머가 SQS Queue에 폴링 요청시 큐가 비어있으면 컨슈머의 Polling 요청을 즉시 반환하는 방법입니다.

Long Polling은 SQS Queue에 Polling 요청시 큐가 비어있으면 큐에 메시지가 도착할 때까지 또는 메시지 수신 대기시간(Receive Message Wait Time)까지 메시지 요청을 기다립니다. 메시지 수신 대기시간은 최초 1초 ~ 최대 20초까지 설정이 가능합니다. (Short Polling은 대기시간이 0초)

Long Polling을 사용하면 빈 응답의 수를 제거하여 API 요청 수를 감소시켜 Amazon SQS 사용 비용을 절감할 수 있다는 장점과 애플리케이션 지연시간을 감소 시킬 수 있습니다.

Summary

SQS는 일반적인 큐가 아닌 분산된 큐라는 점을 유의합니다.
SQS에서 사용되는 큐는 Standard Queue와 FIFO Queue 중 하나를 선택할 수 있습니다.
서비스 특징에 따라 적절한 Queue 선택이 필요합니다.

TIL

SQS를 단순히 큐라고만 알고 있었는데 이번 기회에 SQS에 대해 살펴보면서 분산된 큐라는 점을 알게 되었다. 또한, SQS 생성시 선택하는 큐가 중요하다는 것을 알게 되었다. 근데 보통은 Standard Queue 보다는 FIFO Queue를 주로 많이 사용하지 않을까 생각이 들었다. 왜냐하면 Standard Queue를 사용하면 메시지 중복 문제에 대비해야하기도 하고, 일반적으로 순차처리가 중요한 기능들이 더 많지 않을까 생각이 들었기 때문이다. 그래도 순차 처리가 필요 없는 서비스에서는 Standard Queue를 사용하면 대용량 처리를 빠르게 처리할 수 있으므로 메시지가 중복 수신에 대해서 애플리케이션 방어로직만 잘 작성한다면 유용하게 사용할 수 있을 것 같다.