AWS SQS ( Simple Queue Service)

여러 애플리케이션이 있을 때

각 애플리케이션이 서로 통신해야한다.

여기서 두 가지 패턴이 있다.

첫번째는 동기식 커뮤니케이션이다.

한 애플리케이션이 다른 애플리케이션에 통신한다.

예를 들어, 무언가 사기위한 서비스를 만들었다면

구매한 것을 배송하는 서비스에 통신해야한다.

구매 서비스와 배송 서비스를 통합하고 싶다.

이들은 직접 통신하므로 동기식이다.

 

 

두번째 방식은 비동기식 또는 이벤트 기반이다.

통신해야하는 대기열이 있다.

예를들어

구매 서비스가 무언가가 구매될 때마다 주문을 대기열에 올린다.

그럼 배송서비스는 대기열에서 주문을 읽는다.

예시에서 볼 수 있듯이 구매서비스와 배송서비스는 직접 통신하지않는다.

이 사이에 대기열이 있고 이를 통해 통신하기 때문이다.

 

 

만약 동기식 커뮤니케이션인 경우 문제가 발생할 수 있다.

갑자기 트래픽이 늘어날 경우이다.

보통 10개의 영상이 있었는데 1000개를 인코딩해야한다면?

통신하는 서비스에 트래픽이 몰려 문제가 생길 수 있고 실패할 수도있다.

이 경우 애플리케이션을 분리하는 것이좋다.

대기열 모델인 SQS, 게시/구독 모델인 SNS,

실시간 데이터 스트리밍에 사용되는 Kinesis가 있다.

 

서비스가 분리되면

애플리케이션을 위해 독립적으로 확장할 수 있다.

 

Amazon SQS

SQS는 Simple Queue Service의 약자이다.

Queue(대기열)이란 무엇일까?

SQS 대기열을 만든다고 해보자.

생산자가 대기열에 메시지를 보낸다.

메시지가 대기열에 저장되면 

소비자가 대기열에서 폴링하여 읽을 수 있다.

소비자가 대기열의 메시지를 폴링하면

작업을 공유해서 메시지를 읽고 수평 스케일링한다.

메시지 처리가 완료되면 대기열에서 메시지를 삭제한다.

 

이 메커니즘에서

생산자는 대기열에 메시지를 보내고

소비자는 대기열에서 메시지를 읽고 각기 다른 속도로 처리하도록

생산자와 소비자는 분리되어있다

 

SQS는 완전 관리 서비스이고 서버리스 서비스이다.

서버를 프로비저닝할 필요없이 애플리케이션을 분리할 수 있다.

애플리케이션 티어 간 분리할 때 사용하는 전통적인 솔루션 아키텍처이다.

 

예를 들어,

요청받는 로드밸런서로 구성된 웹 서버가 있고

사용자가 어떤 영상을 처리하고자 할때

영상 처리 애플리케이션에 직접 보내는 대신,

SQS 대기열에 메시지를 넣을 수 있다.

그러면 오토스케일링 그룹으로 이루어진 영상처리 계층의 EC2 인스턴스가

SQS 대기열로부터 읽어와 영상을 처리할 것이다.

 

여기서 웹 서버 애플리케이션에서 오토스케일링을 하고

별개로 영상처리 애플리케이션에서도 따로 오토스케일링이 가능하다는 점이다.