[AWS] SQS 소개

개요

서비스가 점점 커질수록 서버 한 대로 처리하기가 힘들어지기 때문에, 자연스럽게 각 기능들을 여러 서버에서 처리하게 된다.

하지만 서버들끼리 주고 받는 메시지를 잃어버리지 않고 정확하게 처리하는 것은 매우 까다로운 기술이다.

SQS 는 서버들끼리 주고 받는 메시지를 정확하게 처리해주는데, 이런 시스템을 개인이나 벤처기업 또는 스타트업과 같은 소규모 사업장에서 구현 및 구축하는 것은 상당한 노력과 시간, 비용이 소모된다.

 

Amazon SQS 는 서버들끼리 사용할 수 있는 메시지 큐 를 제공하는 서비스이다.

SQS 를 사용하면 고가용성 메시지 큐 시스템 구축에 드는 비용과 고가용성과 신뢰성을 유지하기 위해 지속적으로 소모되는 노력과 비용도 절감할 수 있다. 특히 시스템 장애로 인해 발생하는 금전적인 손실도 막을 수 있다.

AWS 에서 SQS 가 가장 먼저 생겼는데, SQS 의 메시지 큐 는 대형 인터넷 쇼핑몰에서 가장 중요한 기능이기 때문이다.

 

예를 들어, 아마존닷컴은 대규모 서비스이기 때문에 상품을 보여주는 웹 서버, 상품 정보를 저장하는 데이터베이스, 결제를 처리하는 서버, 배송을 처리하는 서버 등 여러 부분으로 분리가 되어 있다.

사용자가 상품을 주문하고 결제한 뒤 웹 서버가 중단되더라도 결제 정보는 잃어버리지 않고 정확히 처리되어야 한다.

SQS 는 메시지를 손실 없이 정확하게 처리하고, 고가용성을 제공하기 때문에 대규모 서비스를 구축할 때 필수적인 시스템이다.

 

원리

SQS 는 간단히 말해 다양한 크기의 여러 메시지를 비동기식으로 전송, 저장, 검색하는 관리형 메시지 대기열 서비스이다.

단일 애플리케이션이 다른 애플리케이션을 직접 호출하는 대신 애플리케이션이 대기 중인 대기열로 메시지를 보낼 수 있고, 다른 애플리케이션이 나중에 메시지에 액세스를 할 수 있다.

 

SQS 대기열에는 FIFO 및 표준 Queue 가 있다.

FIFO 대기열

• 메시지 문자열은 원본 메시지를 보내고 받은 순서로 유지
• 초당 최대 300개의 메시지 전송, 수신, 삭제를 지원
• 작업과 이벤트 순서가 중요한 애플리케이션 간의 메시징을 위해 설계됨
• 정확히 한 번 전달

표준 Queue

• 메시지가 원래 전송된 순서대로 메시지 문자열을 유지하려고 시도하지만, 처리 요구사항에 따라 메시지의 원래 순서나 순서가 변경될 수 있음
• 메시지를 일괄 처리하거나 작업을 여러 작업 노드에 할당할 수 있음
• 적어도 한 번 전달

작동 방식은 아주 간단한데, 한 쪽에서 SQS 메시지를 넣고 다른 한 쪽에서 메시지를 꺼내보면 된다.

SQS 작동 방식

요약하면 사용자에게 결과를 빨리 보여줘야 하는 작업과 시간이 오래 걸리는 작업을 분리할 때, 중요한 작업과 중요하지 않는 작업을 분리할 때, SQS 큐 를 유용하게 사용할 수 있다.

 

SQS 기본 개념

• 메시지 : 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 인스턴스 와 메시지 를 주고 받으면 데이터 요금이 부과된다.
  - 큐 생성 개수는 무제한이다.
• 배치(Batch) API : 배치 API 한 번에 메시지를 최대 10개 혹은 최대 256KB까지 동시에 처리할 수 있다. 여러 메시지를 합쳐서 64KB 이하일 때 배치 API 를 이용하면 요청 1개로 청구된다.
• 보기 제한 시간(Visibillity Timeout) : 메시지를 받은 뒤 특정 시간 동안 다른 곳에서 동일한 메시지 를 다시 꺼내볼 수 없게 하는 기능이다. 0초부터 12시간까지 설정 가능하다. 큐 하나에 여러 서버가 메시지를 받을 때 동일한 메시지를 동시에 처리하는 것을 방지.
  - Messages Avaliable(Visible) : 내용을 꺼내서 볼 수 있는 상태인 메시지 개수이다.
  - Messages in Flight(Not Visible) : 다른 곳에서 메시지 를 보고 있어서 현재는 내용을 볼 수 없는 상태인 메시지 개수이다. 최대 120,000개까지 이며, 최대치를 넘어서면 에러가 발생한다.
• 지연 전송(Delay Delivery) : 특정 시간 동안 메시지를 받지 못하게 하는 기능이다. 지연 되는 시간 동안에는 Messages in Flight 에 포함된다.
• 처리 실패 큐(Dead Letter Queues) : 보통 메시지 를 받고 작업이 처리되면 메시지 를 삭제한다. 하지만, 설정한 횟수를 초과하여
  메시지를 받았는데 삭제되지 않고 남아 있다면 처리 실패 큐 로 보낸다.
  - 메시지 를 받는 횟수는 1번부터 1,000번까지 설정할 수 있다.
  - 일반 큐 하나에 여러 개의 처리 실패 큐 를 연결할 수 있다.
  - 처리 실패 큐 는 일반 큐 와 같은 리전 에 생성해야 한다.
• 짧은 폴링(Short Polling) : 메시지 받기 요청을 하면 결과를 바로 받는다. 메시지 가 있으면 메시지 를 가져오고 없으면 그냥 빠져나온다.
  - ReceiveMessage 요청에서 WaitTimeSeconds 를 0으로 설정했을 때
  - 큐 설정의 ReceiveMessageWaitTimeSeconds 를 0으로 설정했을 때
• 긴 폴링(Long Polling) : 메시지가 있으면 바로 가져오고, 메시지가 없으면 메시지가 올 때까지 기다린다. 또는 메시지 가 계속 오지 않으면 긴 폴링 제한 시간까지 기다린다. 기본 제한시간은 20초이며 1초부터 최대 20초까지 설정할 수 있다.
  - ReceiveMessage 요청의 WaitTimeSeconds가 0보다 크면 큐 설정의 ReceiveMessageWaitTimeSeconds 값보다 우선순위가 높다.

- 끝 -