# SQS

By [Primrose](https://paragraph.com/@primrose) · 2023-03-04

---

SQS
===

Amazon SQS(Simple Queue Service)는 텍스트 메시지를 간편하게 생성, 저장 및 검색할 수 있는 신뢰할 수 있으며 확장 가능한 메시징 프레임워크이다.

SQS는 Amazon Web Services 기반 애플리케이션을 통합하기 위한 기본 프레임워크로 사용할 수 있다.

메시지 사용량을 기준으로 비용을 지불하게 된다.

전체 큐잉 프레임워크는 Amazon 데이터 센터의 안전한 환경 내에서 실행된다.

…

한 마디로 메세징 큐다. 큐는 일반적으로 애플리케이션 간의 Coupling을 끊어주는 역할을 한다.

프로듀서가 메시지를 보내서 Queue에 메시지를 저장하고, 이를 컨슈머가 가져가서 프로세싱 하는 방식이다.

![Producer, Consumer](https://storage.googleapis.com/papyrus_images/7dd42b245db1a197449ee85561db1ee801a38fb61f555d4e8927c575c43d1c49.png)

Producer, Consumer

정리를 위해 핵심만 짚어보자.

*   서버들끼리 사용할 수 있는 메세지 큐를 제공하는 서비스
    
*   해야할 일을 나중에 처리하거나, 다른 시스템이 처리할 수 있도록 하기 위한 비동기 메세징 서비스
    
*   시스템이 처리해야 할 TODO List와 같다.
    

서비스가 커질 수록 서버 한 대로는 점점 처리가 어려워진다.

자연스럽게 기능을 나누어가지게 되고, 이 때 서버끼리 주고받는 메세지를 잃어버리지 않고 정확하게 처리해야하며, 정합성 / 원자성 등을 보장해야한다.

* * *

SQS 유형
------

SQS에는 두 가지 유형이 있다.

첫 번째는 `Standard`, 두 번째는 `FIFO`이다.

![FIFO, Standard](https://storage.googleapis.com/papyrus_images/ba8f04f36ddcea27092f4266f5e9e3ff23502bd5e6bfc20cceb5686cb950db8a.png)

FIFO, Standard

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

---

*Originally published on [Primrose](https://paragraph.com/@primrose/sqs)*