SQS
SQS
Amazon SQS(Simple Queue Service)는 텍스트 메시지를 간편하게 생성, 저장 및 검색할 수 있는 신뢰할 수 있으며 확장 가능한 메시징 프레임워크이다.
SQS는 Amazon Web Services 기반 애플리케이션을 통합하기 위한 기본 프레임워크로 사용할 수 있다.
메시지 사용량을 기준으로 비용을 지불하게 된다.
전체 큐잉 프레임워크는 Amazon 데이터 센터의 안전한 환경 내에서 실행된다.
…
한 마디로 메세징 큐다. 큐는 일반적으로 애플리케이션 간의 Coupling을 끊어주는 역할을 한다.
프로듀서가 메시지를 보내서 Queue에 메시지를 저장하고, 이를 컨슈머가 가져가서 프로세싱 하는 방식이다.
정리를 위해 핵심만 짚어보자.
서버들끼리 사용할 수 있는 메세지 큐를 제공하는 서비스
해야할 일을 나중에 처리하거나, 다른 시스템이 처리할 수 있도록 하기 위한 비동기 메세징 서비스
시스템이 처리해야 할 TODO List와 같다.
서비스가 커질 수록 서버 한 대로는 점점 처리가 어려워진다.
자연스럽게 기능을 나누어가지게 되고, 이 때 서버끼리 주고받는 메세지를 잃어버리지 않고 정확하게 처리해야하며, 정합성 / 원자성 등을 보장해야한다.
SQS 유형
SQS에는 두 가지 유형이 있다.
첫 번째는 Standard, 두 번째는 FIFO이다.
FIFO는 우리가 아는 큐의 개념과 동일하다. 선입선출을 따른다.
Standard는 Throughput을 극대화하기 위해서 순서 보장을 하지 않는다.
표준 대기열 (Standard Queue)
장점
무제한에 가까운 메시지 전송 지원 (최대 처리량)
제한이 없는 TPS 최소 1회 전달 보장 (At-Least-Once-Delivery)
단 중복 수신이 될 수 있다.
Best-Effort-Ordering: 최대한 순서를 보장하고자 노력한다. (하지만 신뢰할 수 없다.)
단점
메시지 순서 보장 안됨
반드시 1번만 읽기 보장 안됨 (중복 읽기 가능성 존재)
FIFO 대기열 (First In First Out Queue)
장점
메시지 순서 보장 (First-In-First-Out Delivery)
Exactly-Once Processing: 1번의 전송, 1번의 수신 지켜짐 (중복수신 방지)
Limited Throughput: 초당 300TPS 제한 존재
단점
순서를 위해 느린 퍼포먼스 (초당 300TPS)
SQS, SNS, Amazon MQ, Kinesis Stream
SQS와 비슷한 서비스가 있어서 차이점이 무엇인지 헷갈릴 수 있다.
간단한 하게 정리하면 다음과 같다.
SQS: Simple Queue Service
가벼운 관리형 메시지 대기열
pull(polling) 기반으로 메시지 처리 (즉, 메시지 가져오기 방식)
SNS: Simple Notification Service
push 기반으로 메시지를 실시간 전달
시간이 관건인 메시지 전달
Amazon MQ
On-Promise에서 사용하던 Message Queue 를 이관시 유리
MOM 기반의 서비스 표준은 어떠한 것이라도 Amazon MQ로 이관 가능
Amazon Kinesis Stream
빅데이터 스트리밍을 실시간으로 처리
여러 Amazon Kinesis Application 의 레코드 읽고 응답 가능
Amazon Kinesis Client LIbrary(KCL) 을 이용하여 파티션 키에 대한 모든 레코드를 동일한 레코드 프로세서에 제공
스트림에서 계산, 집계, 필터링 수행 가능
SQS 개념
SQS를 이루는 기본적인 개념들이 있다.
하나씩 살펴보자.
메세지 (Message)
SQS 의 기본 데이터 단위
메세지는 XML, JSON과 같은 텍스트 형태이며 최대 64KB 까지 보낼 수 있다.
유니코드 문자를 사용할 수 있다.
보관 기간을 초 단위로 설정할 수 있다. 기본 보관 기간은 345,600초(4일)이며 60초(1분)부터 1,209,600(14일)까지 설정할 수 있다. 그리고 메세지 보관 기간이 지나면 자동으로 삭제된다.
메세지마다 고유한 ID가 부여된다.
3~4KB짜리 메세지라도 64KB로 책정된다. 따라서 용량이 작은 메세지를 자주 처리하는 것보다 메세지를 모아서 배치 API 로 처리하면 요금을 절약할 수 있다.
큐 (Queue)
메세지를 담는 공간.
리전 별로 생성해야 하며, HTTP 프로토콜을 이용하여 다른 리전끼리도 메세지를 주고 받을 수 있다. -> 그러므로, 큐의 이름은 모든 리전에서 유일해야 한다.
담을 수 있는 메세지의 개수는 무제한.
연속 30일 동안 아무 요청이 발생하지 않으면 AWS가 큐를 삭제할 수 있으므로, 설계 단계에서 이 부분을 고려해야 한다.
컴퓨터 자료형의 큐와 이름이 같지만, 선입선출(FIFO)를 보장하지 않는다.
다양한 접근 권한과 정책을 설정할 수 있으며, AWS 계정 번호를 이용하여 다른 AWS 계정과도 큐를 공유할 수 있음.
같은 리전 안에서는 데이터 전송이 무료이며, 다른 리전에 있는 큐나 EC2 인스턴스와 메세지를 주고 받으면 데이터 요금이 부과됨.
큐 생성 개수는 무제한
배치 API (Batch API)
한 번에 메세지를 최대 10개 혹은 최대 256KB까지 동시에 처리할 수 있음.
여러 메세지를 합쳐서 64KB 이하일 때 배치 API를 이용하면 요청 1개로 청구됨.
보기 제한 시간 (Visibility Timeout)
메세지를 받은 뒤 특정 시간 동안 다른 곳에서 동일한 메세지를 다시 꺼내볼 수 없게 하는 기능.
0초부터 12시간 까지 설정할 수 있음.
큐 하나에 여러 서버가 메세지를 받을 때 동일한 메세지를 동시에 처리하는 것을 방지
Messages Available(Visible) : 내용을 꺼내서 볼 수 있는 상태인 메세지 개수
Messages in Flight(Not Visible): 다른 곳에서 메세지를 보고 있어서 현재는 내용을 볼 수 없는 상태인 메세지 개수. 최대 120,000개 까지이며 최대치를 넘어서면 에러(OverLimit)가 발생.
지연 전송 (Delay Delivery)
특정 시간 동안 메세지를 받지 못하게 하는 기능.
지연되는 시간 동안에는 Messages in Flight에 포함됨.
처리 실패 큐 (Dead Letter Queues)
보통 메세지를 받고 작업이 처리되면 메세지를 삭제한다. 하지만, 설정한 횟수를 초과하여 메세지를 받았는데 삭제되지 않고 남아있다면 처리 실패 큐로 보냄.
메세지를 받는 횟수는 1번부터 1,000번 까지 설정할 수 있음.
일반 큐 하나에 여러 개의 처리 실패 큐를 연결할 수 있음.
처리 실패 큐는 일반 큐와 같은 리전에 생성해야 함.
짧은 폴링 (Short Polling)
메세지 받기 요청을 하면 결과를 바로 받음. 있으면 메세지를 가져오고, 없으면 그냥 빠져나온다.
ReceiveMessage 요청에서 WaitTimeSeconds를 0으로 설정했을 때
큐 설정의 ReceiveMessageWaitTimeSeconds를 0으로 설정했을 때
긴 폴링 (Long Polling)
있으면 바로 가져오고, 없으면 메세지가 올 때까지 기다림. 메세지가 계속 오지 않으면 긴 폴링 시간까지 기다린다.
기본 제한시간은 20초이며, 1초부터 최대 20초까지 설정할 수 있음.
ReceiveMesasge요청의 WaitTimeSeconds가 0보다 크면 큐 설정의 ReceiveMessageWaitTimeSeconds 값보다 우선순위가 높음.
Last updated
