아마존 SQS

Amazon Simple Queue Service; Amazon SQS; 아마존 SQS
애플리케이션 구성 요소 사이에서 메시지를 보관했다가 전달하는 AWS의 완전 관리형 메시지 대기열 서비스

SQS는 생산자가 메시지를 대기열에 넣고 소비자가 가져가 처리한 뒤 삭제하는 점대점(point-to-point) 메시징 서비스이다. 생산자와 소비자가 서로를 몰라도 되고 처리 속도가 달라도 대기열이 완충해 주므로 느슨한 결합과 부하 평탄화의 대표 수단이다. 대기열에 저장할 수 있는 메시지 수에는 제한이 없고, 서버나 브로커를 관리할 필요가 없다. 한 메시지를 여러 곳에 동시에 보내야 한다면 아마존 SNS와 함께 쓴다(발행-구독 모델 참고).

핵심 개념

항목	설명
생산자·소비자	생산자는 SendMessage로 넣고, 소비자는 ReceiveMessage로 가져가 처리한 뒤 DeleteMessage로 지운다. 소비자가 지우지 않으면 메시지는 다시 나타난다.
메시지 크기	최대 1MiB. 더 큰 데이터는 S3에 두고 참조만 보내는 확장 클라이언트 라이브러리를 쓴다.
배치	한 번의 요청으로 메시지를 최대 10개까지 보내거나 받거나 지운다. 요청 수 기준 과금이라 배치가 비용을 줄인다.
보존 기간	기본 4일, 60초~14일 사이에서 설정
가시성 제한 시간	받은 메시지를 다른 소비자에게 숨기는 시간. 기본 30초, 0초~12시간
지연	대기열 전체(지연 대기열) 또는 메시지 하나(메시지 타이머)를 0초~15분 동안 숨긴 뒤 노출
보안	SSE-SQS 또는 SSE-KMS로 저장 시 암호화, 대기열 정책(리소스 기반 정책)으로 다른 계정·서비스의 접근 제어

표준 대기열과 FIFO 대기열

구분	표준 대기열	FIFO 대기열
전달 보장	최소 1회 전달. 드물게 중복 전달될 수 있음	정확히 1회 처리. 중복 제거 간격(5분) 안의 재전송은 대기열에 중복으로 들어가지 않음
순서	최선 노력 순서. 보낸 순서와 다르게 올 수 있음	메시지 그룹 안에서 엄격한 선입선출
처리량	거의 무제한	기본 모드에서 파티션당 API 작업별 초당 300건(배치 시 메시지 3,000개). 높은 처리량 모드로 확장 가능
이름	제한 없음	이름이 .fifo로 끝나야 함
소비자 설계	멱등하게 처리, 순서 의존 금지	순서가 중요한 처리를 그대로 구현 가능
적합한 경우	이미지 변환, 주문 접수 버퍼, 작업 분배처럼 처리량이 중요한 경우	결제·재고·가격 변경처럼 순서와 중복 방지가 중요한 경우

SQS FIFO 대기열

메시지 그룹 ID(MessageGroupId): FIFO 대기열에 보낼 때 필수이다. 순서는 같은 그룹 안에서만 보장되고, 서로 다른 그룹은 여러 소비자가 병렬로 처리한다. 고객 ID나 주문 ID를 그룹 ID로 쓰면 고객별 순서를 지키면서 전체 처리량을 늘릴 수 있다.
메시지 중복 제거 ID(MessageDeduplicationId): 같은 ID로 5분 안에 다시 보내면 무시된다. 내용 기반 중복 제거를 켜면 본문의 SHA-256 해시를 ID로 쓴다.
같은 그룹의 메시지는 앞 메시지가 처리(삭제)되거나 가시성 제한 시간이 끝나야 다음 것이 나온다.
높은 처리량 모드에서는 메시지 그룹 수를 늘릴수록 처리량이 올라간다.
순서를 엄격히 지켜야 하는 작업에서 DLQ를 쓰면 실패 메시지가 빠지면서 순서가 깨질 수 있으므로 주의한다.
표준 대기열에서도 메시지 그룹 ID를 붙이면 공정 대기열(fair queue)이 되어, 특정 고객의 메시지 폭주가 다른 고객의 처리 지연으로 번지는 것을 줄인다.

가시성 제한 시간

소비자가 메시지를 받으면 메시지는 대기열에 남아 있지만 가시성 제한 시간 동안 다른 소비자에게 보이지 않는다. 그 안에 처리를 끝내고 삭제하지 못하면 메시지가 다시 보여 다른 소비자가 받는다.

제한 시간은 처리에 걸리는 시간보다 넉넉하게 잡는다. 너무 짧으면 같은 메시지가 중복 처리된다.
처리 시간이 들쭉날쭉하면 처리 중에 ChangeMessageVisibility로 시간을 연장한다.
AWS Lambda를 이벤트 소스로 붙일 때는 대기열 가시성 제한 시간을 함수 제한 시간보다 길게(AWS 권장은 함수 제한 시간의 6배 이상) 잡는다.

짧은 폴링과 긴 폴링

구분	짧은 폴링	긴 폴링
동작	일부 서버만 조회하고 즉시 응답. 메시지가 있어도 빈 응답이 올 수 있음	모든 서버를 조회하고 메시지가 올 때까지 최대 20초 대기
설정	ReceiveMessageWaitTimeSeconds = 0	1~20초
효과	빈 응답이 많아 요청 수와 비용 증가	빈 응답과 거짓 빈 응답이 줄어 비용 절감

특별한 이유가 없으면 긴 폴링을 쓴다.

배달 못한 편지 대기열

배달 못한 편지 대기열(dead-letter queue, DLQ)은 여러 번 처리에 실패한 메시지를 따로 모으는 대기열이다.

원본 대기열의 재처리 정책(redrive policy)에 DLQ와 maxReceiveCount(최대 수신 횟수)를 지정한다. 메시지가 그 횟수만큼 받혀도 삭제되지 않으면 DLQ로 옮겨진다.
표준 대기열의 DLQ는 표준, FIFO 대기열의 DLQ는 FIFO여야 한다.
표준 대기열에서는 DLQ로 옮겨져도 원래 넣은 시각 기준으로 만료되므로, DLQ 보존 기간을 원본보다 길게 잡는다.
원인을 고친 뒤 재처리(redrive) 기능으로 DLQ의 메시지를 원본 대기열로 되돌린다.
문제 메시지 하나가 소비자를 계속 실패시키는 독 메시지(poison pill)를 격리하는 것이 핵심 목적이다.

설계 패턴

버퍼링·부하 평탄화: 웹 계층이 주문을 바로 DB에 쓰지 않고 SQS에 넣으면, 트래픽이 몰려도 작업자 계층이 자기 속도로 처리한다. 쓰기 폭주로 DB가 죽는 문제의 단골 해법이다.
느슨한 결합: 구성 요소가 서로 직접 호출하지 않으므로 한쪽이 장애가 나도 메시지는 대기열에 남아 있다가 복구 후 처리된다.
Auto Scaling 연동: 작업자 EC2 그룹을 인스턴스당 백로그(ApproximateNumberOfMessages ÷ 실행 중 인스턴스 수) 지표로 대상 추적 조정한다(아마존 EC2 Auto Scaling). Lambda 이벤트 소스 매핑은 대기열 길이에 따라 자동으로 동시성을 늘린다.
팬아웃: SNS 토픽에 여러 SQS 대기열을 구독시켜 한 이벤트를 여러 시스템이 각자 처리하게 한다.
요청-응답 분리: 아마존 API Gateway가 요청을 SQS에 직접 넣고 바로 접수 응답을 주면, 오래 걸리는 처리를 비동기로 돌릴 수 있다.

시험 포인트

"구성 요소 분리", "급증하는 요청을 잃지 않고 처리", "작업자가 따라가지 못함"이면 SQS를 사이에 넣는다.
"순서 보장", "중복 처리 금지"가 나오면 FIFO 대기열이다. 단순 처리량이 중요하면 표준 대기열이다.
같은 메시지가 두 번 처리되면 가시성 제한 시간이 처리 시간보다 짧은지 의심한다.
빈 응답이 많고 비용이 높으면 긴 폴링(최대 20초)을 켠다.
실패를 반복하는 메시지를 격리하려면 DLQ와 maxReceiveCount를 설정한다.
1MiB를 넘는 페이로드는 S3에 저장하고 참조만 메시지로 보낸다.
한 메시지를 여러 소비자가 각각 받아야 하면 SQS 단독이 아니라 SNS + SQS 팬아웃이다.

같이 보기

참고 문헌