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 값보다 우선순위가 높음.