[aws] SQS와 SNS

 

 

 

이 글의 일부는 aws 공식문서의 내용을 참조하였음을 밝힙니다.

 

 

📌 SQS 

 

sqs의 핵심은 대기열이다. 메시지를 담기 위해서는 무언가 SQS 대기열에 메시지를 전송해야 하는데 SQS 대기열에 메시지를 보내는 주체를 생산자라고 한다. SQS 대기열에 메세지를 보내는 주체를 생산자라 하고 생산자는 여러 개 일 수 있으며 여러 생산자가 여러 개의 메세지를 SQS 대기열에 보내게 할 수 있다. 대기열에서는 메세지를 처리하고 수신해야 하는 대상을 소비자라고 할 때 소비자는 대기열에서 메시지를 폴링하는데 이는 대기열에게 소비자 앞으로 온 메세지가 있는지를 물어보는 것이다. 만일 대기열에 메세지가 있으면 소비자는 이 메세지를 폴링해서 정보를 얻는다. 그리고 그 메세지로 처리를 하고 대기열에서 그 메세지를 삭제한다. 여러 소비자가 SQS 대기열에서 메세지를 소비할 수 있도록 할 수도 있다. sqs 서비스는 생산자와 소비자 사이를 분리하는 버퍼 역할을 한다고 생각하면 쉽다.

 

 

 

 

 

 

 

SQS로 인해 얻는 장점 중 하나는 무제한 처리량을 얻을 수 있다는 것이다. 즉 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는만큼 메시지를 포함시킬 수 있다. 처리량에 제한이 없고 대기열에 있는 메세지 수에도 제한이 없다. 메세지는 기본 값으로 4일 동안 대기열에 남아 있고 대기열에 있을 수 있는 최대 시간은 14일이다. 즉 소비자는 해당 보존 기간 내에 메세지를 처리한 후 대기열에서 삭제하지 않으면 보존된 메세지를 잃는다. SQS는 한 메세지당 256KB의 용량을 허용하고 메세지가 두 번 보내는 경우가 있을 수 있으므로 중복을 허용한다. 

 

 

SQS는 액세스 제어를 위해 IAM 정책은 SQS API에 대한 액세스를 규제할 수 있고 S3 버킷 정책과 유사한 SQS 액세스 정책도 있으며,  SQS 보안은 다음과 같다.

 

• HTTPS API를 이용한 전송 중 암호화
• KMS 키를 사용한 암호화
• 클라이언트 측 암호화

 

📌 SQS with ASG 

 

이번엔 ASG(Auto Scaling groups)와 더불어 SQS 를 사용해보자. 소비자가 ASG의 내부에서 EC2 인스턴스를 실행하고 SQS 대기열에서 메시지를 폴링한다고 할 때 ASG는 일종의 지표에 따라 확장되어야 하는데 이 때 지표는 대기열의 길이가 될 수 있다. 이 길이는 ApproximateNumberOfMessages라고 한다. 이는 모든 SQS 에서 쓸 수 있는 CloudWatch 지표로 알람을 설정할 수 있는데 대기열의 길이가 특정 수준을 넘어가면 Cloud Watch Alarm을 설정하여 오토 스케일링 그룹의 용량을 x만큼 증가시킬 수 있다. 

 

 

 

 

 

특정 시간에 트래픽이 몰리는 웹사이트가 있다고 가정해보자. 많은 트래픽으로 인해 데이터베이스에 저장되는 과정은 굉장히 빠른 속도로 쓰여질 것이다. 이럴 경우 데이터베이스가 오버로드 되는 등 특정 트랜잭션의 오류를 유발할 수 있는데 이러한 문제가 있을 때 SQS를 버퍼로 사용할 수 있다. 애플리케이션 요청 즉 트랜잭션을 무한히 확장 가능한 SQS 대기열에 먼저 씀으로써 처리량 문제를 방지하고 모든 트랜잭션이 DB에 쓰이도록 확인할 수 있다.  

 

 

 

 

📌 SQS to decouple

 

비디오를 처리하는 애플리케이션이 있다고 가정하자. 프론트엔드가 파일 처리 요청을 받을 때마다 SQS 대기열로 메세지를 전송한다고 할 때 해당 파일은 SQS 대기열에 있게 된다. 백엔드 어플리케이션은 메세지를 수신하고 비디오를 처리하여 S3 버킷에 이를 삽입한다.  SQS는 무제한으로 메세지를 보관할 수 있고 처리량에 제한이 없기 때문에 안정성이 뛰어나고 프론트 엔드와 백엔드 각자 독립적으로 확장할 수 있다는 점에서 이 이 아키텍처는 훌륭한 안정성을 보장한다. 

 

 

 

 

 

 

 

📌 SQS 메시지 가시성 시간 초과

 

소비자가 메세지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 된다. 이미지와 같이 왼쪽에서 오른쪽으로 흐르는 시간이 있고 소비자가 어떠한 지점에서 ReceiveMessage API 요청을 하게 되면 대기열에서 메세지가 반환된다. 그 시점으로부터 가시성 시간 초과가 시작되며 메세지 가시성 시간 초과의 기본값은 30초이다. 그 말은 주어진 30 초의 시간동안 메세지가 처리되어야 한다는 것을 의미하며 빨간 박스 안에 시간 동안 동일한 혹은 다른 소비자가 메세지를 요청해도 반환되지 않는다. 가시성 시간 초과 기간 내에서는 그 메세지는 다른 소비자들에게 보이지 않으며 가시성 시간 초과가 경과되었는데도 메세지가 삭제되지 않았다면 메세지는 대기열에 다시 넣어지고 그제서야 동일한 소비자 혹은 다른 소비자가 ReceiveMessage API를 호출하였을 때 그 메세지를 받을 수 있게 된다. 

 

 

 

 

 

결국 가시성 시간 초과 안에 메세지를 처리하지 않으면 메세지가 두 번 처리 될 수 있으며 만일 소비자가 적극적으로 메세지를 처리하고 있지만 메세지를 처리하는데 시간이 더 필요할 수도 있는 상황을 가정해볼 수 있다. 이럴 경우 해당 메세지를 두 번 처리하고 싶지 않다면 소비자가 ChangeMessageVisibility API를 호출하여 SQS에 알려 그 메세지를 보이지 않게 처리할 수 있다. 이런 경우를 대비하여 가시성 시간 초과를 길게 설정할 수도 있겠지만 그렇다고 너무 길게 설정할 경우 소비자가 충돌했을 때 이 메세지가 다시 나타날때 까지 즉 SQS 대기열에 보이기까지 너무 오랜 시간이 걸려 메세지를 처리하기 어려워질 수도 있다. 그래서 가시성 시간 초과 기간은 어플리케이션에 맞춰 적당한 시간으로 설정되어야 하며 소비자는 더 많은 시간이 필요하다면 ChangeMessageVisibility API를 호출하도록 프로그래밍 되어 있어야 한다. 

 

 

 

📌 SQS Long Polling

 

 

소비자가 대기열에 메세지를 요청하는데 대기열에 아무것도 없다면 메시지 도착을 기다리면 되는데 이것을 Long Polling 이라 한다. 

이렇게 하는 이유는 두 가지가 있다. 첫 번째는 지연 시간을 줄이기 위함이고 두 번째 이유는 SQS로 보내는 API 호출 숫자를 줄이기 위해서이다. 작동 방식은 다음과 같다. 비어있는 SQS 대기열에 소비자가 폴링하고 있을 때 메세지가 발생하면 즉 메세지가 대기열에 막 도착할 때 소비자가 여전히 롱폴링 중이라면 자동적으로 그 메세지가 소비자에게 전송된다. 이 때 지연시간이 매우 짦으므로 자동으로 최대한 메세지를 빨리 받게 될 수 있을 것이다. 뿐만 아니라 API 호출 수로 줄임으로써 효율이 좋다. 롱폴링의 시간은 1초부터 20초 사이로 구성이 가능하다. 

 

 

 

 

 

📌 SQS - FIFO Queues

 

SQS에서 사용 가능한 다른 종류의 대기열은 FIFO 이다. FIFO 는 First In First Out의 줄임말로 선입 선출을 의미한다. 이는 표준 대기열보다 순서가 더 확실히 보장되어 보낸 메세지의 순서대로 받게 해준다. 하지만 이런 보장 때문에 대기열의 처리량에 제한이 있는데 묶음이 아닐 경우 초당 300개의 메세지를 처리하고 묶음으로 보내면 초당 3000개 까지가 된다. 또한 중복을 제거하는 기능과 SQS로 너무 많은 메세지를 보내지 않도록 처리량에 제한을 할 수 있는 기능이 있다.

 

 

 

 

📌 SNS 

 

 

메세지 하나를 여러 수신자에게 보낸다고 가정해보자 . 직접 통합을 사용하면 어떤 제품을 구매하였을 때, 이메일 알림을 보내고 사기탐지 서비스와 배송 서비스 그리고 SQS 대기열에 메세지를 보낼 수 있다. 하지만 수신 서비스를 새로 추가할 때마다 통합을 생성하고 작성해야 하므로 번거로움이 생기는데 Pub/Sub(게시/구독)이라는 것을 사용하면 구매 서비스가 메세지를 SNS 주제로 전송할 수 있다. 메세지를 주제로 게시하는 것이다. 각 구독자는 SNS 주제에 해당 메세지를 수신하고 이를 보관할 수 있다. 

 

 

 

SNS 서비스를 이용하면 직접 이메일을 보낼 수도 있고 SMS 및 모바일 알림을 보낼 수도 있으며 지정된 HTTPS 엔드 포인트로  데이터를 보낼 수도 있다. 또한 SNS는 SQS와 같은 특정 AWS 서비스와 통합하여 메세지를 대기열로 직접 보낼 수도 있고 메세지를 수신한 후 Lambda가 코드를 수행하도록 할 수 있으며 Firehouse를 통해 데이터를 S3나 Redshift로 보낼 수도 있다.  

 

 

 

 

 

SNS 다양한 AWS 서비스에서 데이터를 수신하기도 한다. SNS로 직접 데이터를 보내는데 CloudWatch 알람 ASG 알림 CloudFormation State Changes Budgets, S3 버킷, DMS, Lambda, Dynamo DB, RDS  이벤트 등이 있다. AWS에서 알림이 발생하면 이러한 서비스가 지정된 SNS 주제로 알림을 보낸다. 

 

 

 

 

 

SNS 게시 방법에도 다양한 종류가 있다. SDK 주제 게시를 사용해 SNS에 메세지를 게시할 수 있는데 먼저 주제를 만든 다음 하나 또는 여러 개의 구독을 만들고 SNS 주제에 게시하면 모든 구독자가 자동으로 해당 메세지를 받게 된다.  보안 측면에서 SNS는 SQS와 동일하다. 

 

 

📌 SNS + SQS : 팬 아웃

 

만약 다수의 SQS 대기열로 메세지를 보내려 할 때  모든 SQS 대기열에 개별적으로 전송하려고 하면 문제가 발생할 수도 있다. 예를 들어 애플리케이션에서 충돌이 발생하여 전송이 실패될 수도 있고, SQS 대기열을 더 추가하게 될 수도 있다.  그래서 Fan Out 패턴을 사용해야 한다. 개념은 SNS 토픽으로 한 번 메세지를 전송하고 원하는 만큼 SQS 대기열을 SNS 토픽에 구독시키는 것이다. SQS들은 구독자이고SNS로 보내진 메세지들을 모두 받을 것이다.

예를 들어, 어떤 물건을 구매했을 때 두 개의 대기열로 메세지를 전송하고 싶은 상황일 때 각각 전송하는 대신 SNS 토픽에 한 개의 메세지를 전송하고 대기열 두 개가 SNS 토픽을 구독하고 있을 경우 Fraud Detector(사기 탐지 서비스) 와 배송 서비스가 각각 자신의 SQS 대기열에서 메세지를 읽을 수 있다. 이는 완벽하게 분리된 모델로 SQS로 데이터 지속성, 지연 처리, 작업 재시도 등의 효과를 얻을 수 있으며 이 패턴으로 시간이 지날 수록 SQS 대기열을 SNS 토픽의 구독자로 더 추가할 수 있다. 

 

 

 

 

 

이런 팬아웃 패턴은 S3 이벤트를 여러 개의 대기열로 보낼 때의 아키텍처도 구상해볼 수 있다. 만약 S3 이벤트 알림을 여러 개의 동일한 SQS 로 보내고 싶다면 S3 버킷에 객체가 생성되어 이벤트가 발생했을 때 SNS 토픽으로 전송하고 여러 개의 대기열이 SNS 토픽에 Fan Out 패턴으로 구독하게 하면 된다. 아니면 이메일이나 Lambda 함수 등 다른 형식의 어플리케이션도 SNS 토픽을 구독하여 S3에 일어나는 이벤트에 대한 메세지를 서로 다른 목적지로 안전하게 전송할 수 있다. 

 

 

 

 

SNS의 중요한 기능 중 하나는 메세지 필터링인데 SNS 토픽 구독자들에게 전송할 메세지를 필터링할 수 있다. 예를 들어 그림과 같이 구매 서비스가 SNS 토픽으로 거래 내용을 전송하고 주문 내용에는 주문 번호, 제품, 수량, 상태 등이 있다. 여기서 SQS 대기열을 생성해 모든 주문이 아닌 발주(placed)된 주문만을 처리하도록 SQS 대기열을 SQS 토픽으로 구독시키고 JSON 필터링 정책을 적용함으로써 정책에 부합하는 메세지 '발주' 상태인 메세지만 SQS 대기열에 들어가게 될 것이다. 이러한 로직은 취소 상태인 메세지로도 아이디어를 확장할 수 있고 다른 SQS 대기열을 따로 마련하면 취소된 주문, 발주된 주문의 각 SQS 대기열들은 같은 메세지를 받지 않게 될 것이다. 또한 주문 필터링 정책을 사용해 취소된 주문을 위한 이메일 구독을 생성할 수 있고 혹은 다른 SQS 대기열엔 거절된 주문을 위한 필터링 정책을 만들거나  필터링 정책이 없는 SQS 대기열을 만들어 SNS 토픽으로부터 모든 메세지를 받도록 할 수 도 있다.  이런 Fan Out 패턴, 메세지 필터링 을 사용하여 다양한 아키텍처를 구성할 수 있다.