[AWS] Amazon SQS (Simple Queue Service) 쉽게 개념과 특징 정리 (Producer, Consumer, Queue, Short & Long Polling)

◇  공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇

 

 

 

AWS SQS

 

Fully managed message queuing for microservices, distributed systems, and serverless applications

SQS  (Simple Queue Service)

 

 

SQS (Simple Queue Service)는 완전 관리형 메시지 큐 서비스이다.

      → 컴퓨터 시스템(서버) 간에 메시지를 주고받는데 도움을 주는 서비스.

 

 

👨‍🍳 SQS 사용 예시: 주문 처리 시스템

• 주문 접수:
  고객이 온라인에서 물건을 주문하면, 이 주문 정보를 SQS 큐에 넣는다. SQS 큐는 주문 정보를 안전하게 저장해둔
• 주문 처리:
  백엔드 시스템에서 SQS 큐를 주기적으로 확인하면서 새 주문이 있는지 확인. 주문이 있으면 상품을 포장한다.
• 배송 및 알림:
  상품이 포장되면 SQS 큐에 다시 메시지를 보낸다. ("상품이 출고되었습니다!") 이 메시지는 다른 시스템(서버)에서 확인되어 고객에게 배송 알림 등을 보낸다.

 

👨‍🏫 SQS 사용 이유

애플리케이션 서비스가 커질수록 서버 한대로는 처리가 힘들어진다.😰😫
따라서 자연스럽게 여러 서버를 사용하고, 애플리케이션의 기능에 따라 작은 독립적인 서버스로 나누게 되었다.

결과적으로 서버들끼리 주고 받는 메세지를 잃어버리지 않고 정확하게 처리하는 것이 중요해졌다.

    → SQS는 서버들끼리 주고받는 메세지를 정확하고 안전하게 처리해준다.

 

 

 

💬 메시지 큐 (Message Queue)

메시지 큐는 시스템 간에 데이터를 안전하게 전송하고 처리하는 데 사용되는 통신 방법이다.

이는 비동기적(Asynchronous)으로 메시지를 주고 받는다. → 실시간(Real-time) 통신이 아니다.

⁕ 큐는 한국말로 대기열

안전 > 속도

 

 

메세지 큐 사용하지 않을 경우: 동기적 메세지 전송

큐를 사용하지 않을 경우 (동기 메세지 전송)

 

 

메세지 큐 를 사용할 경우: 비동기 메세지 전송

큐를 사용할 경우 (비동기 메세지 전송)

 

Amazon SQS 특징

왜 SQS를 사용하는가?

👥 비동기 처리

대량의 메시지를 처리할 경우여도 시스템에 지장을 주지 않는다.

왜냐하믄 큐를 사용해서 비동기 처리하기 때문에

📈 스케일링 및 확장성

SQS는 필요에 따라 자동으로 큐 크기를 확장하여 유연하게 대응할 수 있다.

🙏🏻 신뢰성(Reliability) & 내구성(Durability)  & 가용성 (Availability)

기본적으로 SQS는 메시지 손실 없이 전달 가능

• 내구성: 메시지의 안전을 위해 SQS는 메시지를 여러 서버에 저장한다. → 메시지 복제본 저장
• 신뢰성: SQS는 처리 중인 메시지는 Lock을 걸기 때문에 여러 생산자와 소비자가 동시에 메시지를 전송 및 수신 가능.
• 가용성: SQS는중복 인프라(분산 아키텍처)를 기반으로 메시지 생성 및 소비에 대한 고가용성을 제공.

🔒 보안성

SQS는 메시지를 암호화하여 안전하게 전송한다.  

AWS Key Management Service(KMS)를 사용하여 암호화 한다.

 

 

Amazon SQS 단점

🚄 속도의 한계

SQS는 비동기적으로 동작하기 때문에 살짝 느릴 수 있다.

 

📐 제한된 메시지 크기

메시지의 최대 크기가 256KB로 제한 되어 있다.

 

⌛ 메시지 보존 시간 제한

메시지는 일정 기간 동안만 보존되므로 이를 초과하면 메시지가 삭제된다.

 

🌍단일 지역 제한

각 SQS 큐는 특정 AWS 지역에 속해 있어 다른 지역 간 통신이 필요한 경우에는 다른 방법을 고려해야 한다.

 

 

 

Amazon SQS 작동 방식

 

프로듀서 (Producer)

메세지를 제공하는 쪽

메시지를 SQS 큐에 전송하는 애플리케이션 or 서비스를 프로듀서라고 합니다.

컨슈머 (Consumer)

메세지를 받는 쪽

큐에서 메시지를 가져와 처리하는 애플리케이션 or 서비스를 컨슈머라고 합니다.

큐 (Queue)

SQS의 역할

SQS는 프로듀서와 컨슈머를 연결시키며, 큐는 메시지를 관리하기 위한 박스와 같다. 

폴링 (Polling)

• polling은 Consumer가 새로운 메시지가 큐에 왔는지 주기적으로 확인하는 프로세스를 의미한다.
  • (이는 우리가 상대방으로 부터 카톡의 답장이 오는 것을 기다리는 것과 같다.)
  • polling은 메시지를 받을 때까지 주기적으로 큐를 확인한다. (주기는 우리가 설정할 수 있다)
• SQS에는 2개의 방시의 polling이 있다.
  1. Short Polling
  2. Long Polling

 

 

Short Polling와 Long Polling

Short Polling (default)

메시지가 큐에 없으면 요청을 즉시 응답
(큐를 계속 바로 바로 확인한다 → 비용이 많이 든다)

Long Polling

메시지가 큐에 없으면 요청이 지정된 대기 시간 동안 (예: 최대 20초) 대기
(큐에 확인하고 일정 시간 동안 기다렸다가 메시지가 생기면 응답 → 비용이 short polling 보다 덜 든다)

 

 

SQS 의 큐 종류

1. Standard Queue (표준 큐): 순서가 바뀔 수도 있다.
2. FIFO Queue (FIFO 큐, First In, First Out): 순서를 잘 지킨다.

	Standard Queue	FIFO Queue
메시지 전송 횟수	1회 이상	오직 1회만
메시지의 전송 순서	Best-Effort Ordering (최선을 다해서 정렬) 가끔 메시지가 전송된 순서와 다르게 전달된다. 즉, 순서가 바뀔 수도 있다.	First-In-First-Out Delivery (선입선출) 메시지가 전송되고 수신되는 순서가 엄격하게 지킨다. 즉, 순서는 바뀌지 않는다.
처리량	거의 무제한	1초당 최대 300 메시지

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-types.html

 

 

Dead Letter Queue (DLQ, 데드 레터 큐)

Dead Letter Queue는 시스템에서 어떠한 오류로 인해 메시지 전송을 실패하면 임시로 메시지를 보관/저장하는 특수한 메시지 큐이다.

Dead Letter Queue는 어떤 이유로든 처리되지 못한 메시지를 (메시지를 잃어버리지 않고) 나중에 분석하거나 재처리할 수 있도록 별도의 큐에 보관한다. 

https://aws.amazon.com/blogs/compute/introducing-amazon-simple-queue-service-dead-letter-queue-redrive-to-source-queues/

• Dead Letter Queue는 SQS의 Queue와는 별도로 존재하는 독립적인 큐이다. 
• SQS Queue에서 일정 횟수 이상(Maximum Receive) 처리되지 않은 메시지를 Dead Letter Queue로 이동한다.
  • Maximum Receive의 값이 3으로 설정되어 있으면, 한 메시지가 세 번 읽혔지만 여전히 처리되지 않았다면 그 메시지는 DLQ로 이동한다.
• 메시지가 DLQ에 들어오면, 실패한 이유를 분석하거나 수동으로 재처리할 수 있다.

 

참고) https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

Using dead-letter queues in Amazon SQS - Amazon Simple Queue Service

 

 

 

Delay Queues(지연 큐)와 Message Timers(메시지 타이머)

메시지의 Producer가 송신한 메시지를 지정된 시간이 지난 후에 Consumer에게 수신하게 하고싶을 때, "지연 큐(Delay Queue)" 또는 "메시지 타이머(Message Timer)"를 사용한다. (보내는 Producer가 설정한다)

큐에 투입된 메시지는 지정된 시간이 경과한 후에 수신할 수 있게 됩니다.

• "지연 큐(Delay Queue)"는 큐 전체에 적용된다.
• "메시지 타이머(Message Timer)"는 특정 메시지에 적용된다.

예시) Delay Queue를 5분으로 설정하면, 큐에 들어온 메시지는 5분 동안 대기한 후에 Consumer가 받을 수 있다.

예시) Message Timers를 통해 어떤 메시지는 10분 후에 처리하고, 다른 메시지는 1시간 후에 처리할 수 있다.

 

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html

 

Visibility Timeout

Visibility Timeout는 SQS의 메시지를 수신하는 여러 개의 애플리케이션이 있을 경우에 필요하다.

 

예를 들어, 메시지를 처리하는 애플리케이션이 4개 있을 경우, 4개 중 하나만 수신한 메시지를 받아 처리하면 된다 하자.

이 때, 하나의 애플리케이션이 이미 메시지를 받아 처리 중인데, SQS Queue에 메시지가 남아있다면, 다른 애플리케이션이 그 메시지를 받아 쓸데없이 또 처리 할수도 있다.

 

Visibility Timeout은 이렇게 메시지를 중복으로 처리되지 않도록 보장하기 위해, 한 번 애플리케이션이 메시지를 수신받으면 일정 시간(Visibility Timeout에 지정된 시간)이 경과할 때까지 그 메시지가 다른 애플리케이션에게 보이지 않도록 숨긴다.

일정 시간 동안 처리가 실패한 경우에는 다시 재처리될 수 있도록 한다.

 

 

 

SQS Queue Prioritization

SQS는 기본적으로 메시지에 우선순위를 자동으로 부여하는 기능이 없다.

그래도 우선순위를 구현하려면 여러 개의 큐를 활용해서 애플리케이션 쪽에서 우선 순위를 부여하는 시스템을 만들어서 Polling 해야된다.

• 여러개의 SQS 큐 사용: 여러개의 큐를 만든다. 예를 들어:
  1. high-priority-queue (높은 우선순위)
  2. medium-priority-queue (중간 우선순위)
  3. low-priority-queue (낮은 우선순위)
• 애플리케이션쪽에서 우선순위에 따라 처리: 먼저 high-priority-queue를 폴링하고, 그 다음 medium-priority-queue, 마지막으로 low-priority-queue를 폴링하는 방식으로 우선순위를 부여한다.