SQS 아키텍처

 

소비자가 ASG의 내부에서 EC2 인스턴스를 실행하고

SQS Queue에서 메시지를 폴링하는 사례이다.

 

ASG는 일종의 지표에 따라 확장되어야 하는데

Queue의 길이를 지표로 사용할 수 있다.

CloudWatch로 대기열의 길이를 얻을 수 있고

대기열의 길이가 특정 수준을 넘어가면

CloudWatch Alarm을 설정하여 ASG의 사이즈를 변경하는 아키텍처이다.

 

 

 

두번째는 비디오를 처리하는 애플리케이션이 있다고 해보자.

만약 프론트엔드 서버 밖에 없으면

프론트엔트가 처리까지 한 후 S3 버킷에 삽입해야한다.

이렇게 하면 시간이 오래 걸리고 웹사이트의 속도가 느려질 수 있다.

 

대신 SQS를 사용하여 애플리케이션을 분리(decouple) 하면 

파일 처리 요청과 실제 파일 처리가 서로 다른 애플리케이션에서 발생할 수 있도록 할 수 있다.

 

프론트엔드로 파일 처리 요청을 받을 때마다

SQS 대기열로 메시지를 보내는것이다.

그럼 처리 요청을 할 때 해당 파일은 SQS 대기열에 있게 된다.

 

비디오를 처리할 백엔드 계층을 만들 수 있다.

이 백엔드 애플리케이션이 대기열의 메시지를 받아서

비디오를 처리하고 S3 버킷에 삽입한다.

 

이 아키텍처에서 볼 수 있듯이 프론트엔드를 확장할 수 있고

SQS 대기열에 대기열이 많이 쌓여있으면 백엔드 애플리케이션도 별개로 확장 가능하다.

 

또 다른 장점은

프론트엔드 최적의 EC2 인스턴스 유형을 쓸 수 있고

백엔드는 비디오 처리를 수행하기위해 GPU가 있는 EC2 인스턴스 유형을 사용할 수 있다.