Amazon SQS 에 대해 알아보자
이번에는 SQS의 내용에 대해 자세히 다뤄보도록 하겠습니다.
SQS 큐의 종류
1. Standard Queue
스탠다드 큐는 메시지 순서가 중요하지 않고, 높은 처리량을 필요로 하는 애플리케이션에 적합합니다. 예를 들어, 대량의 이벤트 데이터를 처리하거나, 로깅 시스템에서 다수의 메시지를 신속하게 처리해야 할 때 사용됩니다.
성능
고처리량: 스탠다드 큐는 초당 수십만 개의 메시지를 처리할 수 있습니다.
비순차적 배달: 메시지가 전송된 순서와 다를 수 있습니다. 즉, 가끔씩 메시지 순서가 바뀔 수 있습니다.
비용
SQS는 전송된 메시지 수에 따라 요금을 부과합니다. 스탠다드 큐는 FIFO 큐에 비해 단가가 낮습니다.
2. FIFO Queue
FIFO 큐는 순서를 유지하면서 메시지를 처리해야 하는 애플리케이션에 적합합니다. 예를 들어, 은행 거래처리나 주문 처리 시스템에서는 실행 순서가 매우 중요합니다.
성능
순서 보장: 메시지는 정확히 한 번만 전달되며, 보낸 순서대로 처리됩니다.
중복 없음: 메시지가 중복 없이 전달됩니다.
비용
FIFO 큐는 스탠다드 큐에 비해 비용이 더 높습니다. 이는 순서 보장 및 중복 방지 기능 때문에 추가적인 내부 관리가 필요하기 때문입니다.
SQS 세부 설정
1. Visibility Timeout: 표시 제한 시간
메시지가 큐에서 소비자에 의해 받아지면, 해당 메시지는 'Visibility Timeout' 동안 다른 소비자에게는 보이지 않습니다. 이 시간이 지나면 메시지는 다시 큐에서 보이게 되어 다른 소비자가 받을 수 있습니다.
설정 근거
처리 시간 추정
메시지를 처리하는 데 예상되는 시간을 기반으로 설정합니다. 예를 들어, 각 메시지를 처리하는 데 평균적으로 30초가 걸린다면, Visibility Timeout은 30초 이상으로 설정하는 것이 좋습니다.
재처리 여부
메시지 처리가 실패할 경우 재시도할 시간을 고려하여 설정합니다. 너무 짧으면 동일 메시지가 중복 처리될 수 있습니다.
2. Message Retention Period : 메시지 보존 기간
메시지가 큐에 유지되는 최대 시간입니다. 이 기간이 지나면 메시지는 큐에서 자동으로 삭제됩니다. 메시지가 큐에 유지되는 최대 시간을 설정할 수 있습니다. 일반적으로 1분에서 최대 14일까지 가능합니다.
설정 근거
메시지 유효성
메시지가 얼마동안 유효한지에 따라 결정합니다. 예를 들어, 실시간 트랜잭션 처리 시스템에서는 몇 시간 내에 처리되지 않은 메시지는 무효가 될 수 있습니다.
백업과 복구
메시지 처리 시스템에 장애가 발생했을 때 복구 시간을 고려하여 설정합니다. 예를 들어, 시스템 복구에 최대 3일이 걸린다면, 최소 3일은 유지되어야 합니다.
3. Maximum Message Size : 최대 메시지 크기
큐에 전송될 수 있는 메시지의 최대 크기를 설정합니다. 메시지의 최대 크기는 256KB까지 가능합니다. 이 크기를 초과하는 메시지는 거부됩니다.
설정 근거
애플리케이션 요구사항
전송해야 할 데이터의 크기를 고려합니다. 대부분의 경우 기본값인 256KB가 적합하지만, 큰 사이즈의 데이터를 다루는 경우, 여러 메시지로 나누어 보내야 할 수도 있습니다.
Maximum Message Size와 S3 사용
Amazon SQS의 Maximum Message Size는 기본적으로 256KB로 제한되어 있습니다. 이를 초과하는 크기의 메시지를 처리해야 할 경우, 일반적으로 Amazon S3와 함께 사용하는 패턴을 적용할 수 있습니다. 이 패턴에서는 다음과 같은 절차를 따릅니다
메시지 저장
실제 데이터를 Amazon S3에 저장하고, 해당 S3 객체의 위치를 가리키는 링크나 메타데이터만 SQS 메시지로 전송합니다.
메시지 처리
소비자는 SQS 메시지를 받아, 메시지 내에 포함된 S3 링크를 사용하여 실제 데이터를 S3에서 검색합니다.
비용 및 성능
이 방식은 메시지 크기 제한을 우회할 수 있으며, 대용량 데이터를 효율적으로 처리할 수 있습니다. 하지만, S3 사용에 따른 추가 비용과 약간의 지연 시간이 발생할 수 있습니다.
4. Delivery Delay : 전송 지연
메시지가 큐에 도착한 후 소비될 때까지 대기하는 시간을 지연시킵니다. 이를 통해 일시적으로 처리를 지연시킬 수 있습니다. 최대 15분까지 가능합니다.
설정 근거
배치 처리
일정 시간 간격으로 메시지를 모아서 처리하고자 할 때 유용합니다. 예를 들어, 매 5분마다 배치로 처리하기 위해 5분의 지연을 설정할 수 있습니다.
시스템 부하 조절
고부하 시간에 메시지 처리를 지연시켜 시스템의 부하를 분산시킬 수 있습니다
5. Receive Message Wait Time - 메시지 수신 대기 시간
이 설정은 SQS의 폴링 방식을 어떻게 처리할지 결정하며, 특히 Long Polling 방식에서 중요한 역할을 합니다
메시지 수신 대기 시간이란?
SQS에서 메시지를 수신할 때 사용할 수 있는 두 가지 방식은 Short Polling과 Long Polling입니다. '메시지 수신 대기 시간'은 Long Polling을 설정하는데 사용되며, 이는 SQS가 응답을 반환하기 전에 새 메시지를 기다리는 시간을 지정합니다. 이 값은 0초에서 20초 사이로 설정할 수 있으며, 기본값은 0초입니다. 0초는 Short Polling을 의미하며, 이보다 긴 시간을 설정하면 Long Polling이 활성화됩니다.
Long Polling의 이점
비용 효율성
Long Polling을 사용하면 SQS가 메시지를 검색할 때 더 긴 시간 동안 요청을 유지합니다. 이는 빈 응답의 수를 줄여주어 API 호출 수를 감소시키고, 결과적으로 비용을 절감할 수 있습니다.
성능 향상
메시지의 도착과 거의 동시에 메시지를 받을 수 있도록 해주기 때문에 애플리케이션의 반응 시간이 개선됩니다.
리소스 사용 최적화
리소스를 더 효율적으로 사용할 수 있습니다. 불필요한 폴링으로 인한 네트워크 트래픽과 CPU 사용을 줄일 수 있습니다.
설정 근거
트래픽 패턴 분석
애플리케이션의 메시지 생성 및 소비 패턴을 분석하여 최적의 '메시지 수신 대기 시간'을 설정해야 합니다. 메시지가 빈번하게 발생하지 않는 경우, 최대한 긴 대기 시간을 설정하는 것이 효과적일 수 있습니다.
반응성과 비용 사이의 균형
시스템의 반응성을 유지하면서 비용을 최소화하기 위한 균형을 찾아야 합니다. 너무 짧은 대기 시간은 더 많은 폴링을 초래하여 비용이 증가할 수 있으며, 너무 긴 대기 시간은 메시지 처리 지연을 초래할 수 있습니다.