AWS SQS, SNS

이번에 공부한 것은 AWS SQS인데 SQS를 공부하려면 SNS도 같이 공부할 수 밖에 없더라구요. 

 

이번 포스팅에선 AWS SQS와 SNS를 전체적으로 훑어보면서 다른 메세지 브로커와 어떤 점이 다른지 공부해보고 정리했습니다. 

 

AWS SQS만 가지는 강력한 특징

SQS는 Simple Queueing Service (이하 SQS) 의 약자로 메세지를 큐에 담아서 보내는 여타 메세지 브로커와 비슷합니다. 하지만 SQS가 메세지 브로커냐? 하면 SQS만으로는 메세지 브로커라고 하기 조금 애매할 것 같습니다. 

 

왜냐하면 SQS는 정말 말 그대로 메세지 큐잉 서비스이기 때문입니다. 여타 전통적인 메세지 브로커들처럼 Pub/Sub 구조를 가지고 있지 않다는 얘기입니다. 

 

이게 왜 메세지 브로커와 다르냐면 SQS는 Producer와 Consumer가 1대1 관계만을 가지고 있어서 1대다 구조를 가질 수 있는 Pub/Sub과 다르게 작동하기 때문입니다. 

 

때문에 마이크로서비스에선 하나의 서버에서 여러 서버로 메세지를 전송해야할 일이 잦은데 이때 단순히 SQS만 사용해서는 1:N 연결 구조를 가질 수 없습니다. 

 

그래서 SQS와 SNS를 동시에 사용하는 것인데 SNS는 SQS를 알아보고 바로 다음 챕터에서 정리해보겠습니다. 

 

메세지 브로커

일단 메세지 브로커에 대해서는 짚고 넘어가지 않겠습니다. 간략한 내용은 미약하게나마 아래의 링크에 정리가 되어있습니다. 

 

https://coding-review.tistory.com/504

아파치 카프카 (개념)

 

다른 메세지 브로커와 다르게 SQS만 가지는 강력한 특징에 대해서 한번 읊어보겠습니다. 

 

뭐? 메세지를 무한으로 저장할 수 있다고?

제가 처음 문서를 봤을 때 감정입니다. 

 

 

제가 읽은 문서인데 간단하게 요약해보면 "SQS의 큐들은 다른 큐에 영향을 받지 않는다. 이 말은 다른 큐에 의해 메세지를 보내는 큐가 느려지는 일이 절대로 없다는 이야기이다. 또한, 하나의 큐가 다른 큐를 막는 현상은 절대로 일어나지 않는다. 이를 AWS SQS 공식 문서에선 SQS는 무한한 개수의 큐를 저장할 수 있다라고 설명한다."

 

이걸 보고 진짠가..? 싶었습니다. 그렇다고 SQS에 미친 과금을 하면서 테스트를 해볼 수도 없고 참.. 그냥 그렇다니까 그런줄 알고 있어야겠습니다. 

 

아무튼 SQS는 메세지를 무한에 가까운정도로 저장하고 있을 수 있다는 것이 AWS 공식문서의 설명입니다. 

 

 

SQS는 Serverless의 특징을 가진다.

앞선 특징 때문에 SQS는 Serverless의 특징을 가집니다. 그렇다고 Serverless의 Cold Start 같이 신경써야 하는 것이 있는 것은 아닙니다. 

 

해당 문서에서 SQS가 Serverless의 특징을 가진다는 것은 사용자가 큐잉 서비스를 이용할 때 메세지 브로커의 서버 상태를 고려하지 않아도 괜찮다는 이야기인 것 같습니다. 

 

만약 온프레미스에서 카프카를 이용해서 메세지 브로커를 사용한다면 카프카의 오버헤드나 서버 상태를 고려해야 하는데 SQS는 그렇지 않다는것이죠. 

 

 

SQS는 자체적인 failover 기능이 있다.

SQS에는 Dead Letter Queue라는 것이 있습니다. 흔히 DLQ라고 줄여 부르곤 하는데 이 DLQ는 요청에 실패한 메세지들을 따로 모아두는 Queue입니다. 

 

AWS는 이 DLQ를 이용해서 요청에 실패한 메세지를 재요청하는 기능을 제공해줍니다. 때문에 SQS에선 자체적인 Fault Tolerance를 가진다는 말이 됩니다. 

 

 

SQS는 FIFO를 선택할 수 있다. 

SQS는 메세지 옵션 중 FIFO를 선택하면 First In First Out을 구현해줄 수 있습니다. 이 설정을 한 SQS 큐는 순서를 보장받을 수 있고 이는 선착순 이벤트같은 용도로 사용될 수 있습니다. 

 

 

SQS의 Long Polling, Short Polling

SQS는 설정하기에따라 한번에 많은 메세지를 처리할지 조금씩 많이 메세지를 처리할지 선택할 수 있습니다. SQS가 짧게 메세지를 폴링하면 할 수록 데이터를 유실하더라도 최소한으로 유실할 수 있고 그만큼의 데이터 일관성이 보장됩니다. 

 

하지만 짧게 폴링하면 돈이 더 많이 나간다는 사실..!

 

 

그럼 어떤 Side Effect가 있을까?

말로만 들으면 정말 엄청난데 어떤 사이드 이펙트가 있을지 살펴보니 SQS는 메세지 크기가 256KB를 넘을 수 없다고합니다. 또한, Pub/Sub 메세징을 지원하지 않고 간단한 메세지 큐잉서비스를 제공해주기 때문에 제약이 많다는 설명도 덧붙였습니다. 

 

하지만 AWS에서도 이를 해결하기위해 다양한 솔루션들을 제공하고 있습니다. 

 

메세지 크기가 256KB를 넘길 수 없는 문제는 S3에 메세지를 등록하고 이 메세지를 전송할 수 있는 기능을 지원합니다. SQS와 S3를 결합하여 해결한 것인데 서비스간 통합이 쉽다는 클라우드의 장점과 맞물리네요. 

 

또한, Pub/Sub 메세징은 SNS를 결합하면서 해결할 수 있습니다. SNS는 가운데 N이 Notification인데 이 Notification은 SMS나 Email서비스를 엔드포인트로 설정하여 다양한 알람을 받을 수 있는 것입니다. 

 

 

AWS SNS 

SQS를 공부하다보면 꼭 SNS얘기가 따라나옵니다. SNS가 뭐길래 SQS와 같이 얘기가 나오는걸까요? 

 

우선 메세지 브로커의 3요소를 먼저 알아볼 필요가 있습니다. 메세지 브로커의 3요소는

 

• Queue
• Topic
• Event Bus

이렇게가 3요소입니다. 간단하게 살펴보자면

 

• Queue : 큐는 메세지를 서비스간 이동시키는 큐잉 서비스의 본질이며 메세지를 운반하는 매개체가 됩니다. 
• Topic : Topic, 우리말로 주제는 메세지가 어디로 가야할지 방향을 정해줍니다. 
• Event Bus : 메세지 브로커가 Event Driven으로 되어있는 경우 다양한 이벤트에 대한 처리를 진행할 수 있습니다. 

이런 3요소가 AWS에 모두 존재합니다. 그리고 이 세개의 서비스를 같이 사용할 때 비로소 메세지 브로커의 역할을 충실히 수행할 수 있는것이죠. 

 

Queue = AWS SQS

Topic = AWS SNS

Event Bus = AWS Event Bridge

 

이렇게 매칭이 됩니다. Event Bridge는 이번 포스팅에서 다루진 않지만 간략하게 짚고 넘어가자면 AWS CloudWatch의 하위 기능으로서 각종 이벤트들을 처리해주는 역할을 합니다. 

 

뭐 아무튼 SNS는 Topic의 역할을 하기 때문에 메세지가 어디로 가야할지 방향을 제시해준다는 특징이 있습니다. 이런 특징말고 SNS만이 가지는 두드러지는 특징을 한번 살펴봤습니다. 

 

SNS는 천만개 이상의 Subscriber를 가질 수 있다. 

SNS는 다양한 엔드포인트를 가질 수 있습니다. 그 엔드포인트가 AWS Lambda가 될 수 있고, SMS, Email Service, SQS가 될 수 있습니다. 

 

여기서 핵심은 SQS가 될 수 있다는 것입니다. 즉, SNS를 구독한 어떤 애플리케이션에 메세지를 보내면 SQS를 이용해서 다른 서비스로 메세지를 보낼 수 있다는 말이 됩니다. 

 

이때, SNS는 공식문서에 따르면 1250만개의 Subscriber를 가질 수 있다고합니다. 

 

 

굉장히 빠른 메세지 처리 능력

SNS는 메세지 로드밸런서라고 부를 수 있을 정도로 굉장히 빠른 메세지 처리 능력을 보여줍니다. 또한, SNS도 SQS와 마찬가지로 FIFO를 지원하기 때문에 데이터의 순서를 보장받을 수 있습니다. 

 

 

이렇게 좋아보여도 Side Effect는 존재한다. 

SNS는 굉장히 좋아보이지만 SQS와 다르게 자체적인 failover가 존재하지 않습니다. 즉, 메세지의 요청이 실패하면 메세지가 사라지게 되는 것이죠. 

 

공식문서에선 이러한 문제에 대해 "SNS는 반복적이고 동일한 메세지를 처리할 때 용이하다." 라는 언급이 있었습니다. 

 

이것에 대한 AWS의 솔루션은 SQS의 DLQ를 이용하라는 것 같은데 사실 복잡해보여서 패스했고... 저는 두 번째 방법인 애플리케이션에서 자체적인 retry 전략을 가져가는 것이 더 편해보였습니다. 

 

스프링 부트의 경우 @Retryable이라는 어노테이션을 통해 SNS 주제로 메세지를 보낼 때 Exception이 발생하면 특정 패턴에 맞춰 재시도를 할 수 있는 기능을 제공합니다. 이 @Retryable 어노테이션은 스프링 AOP를 이용해 재시도 전략을 제공해주죠. (젠장, 또 AOP야)

 

 

마치며

확실히 SQS와 SNS는 클라우드라서 가지는 장점을 그대로 계승한 것 같이 보였습니다. SQS의 Serverless적인 특징도 그렇고 무한한 메세지를 저장할 수 있다는 것이 바로 그렇죠. 

 

하지만 만약 애플리케이션이 클라우드 환경에 있고 Kafka 서버를 관리하는 리소스를 다른 곳에 투자하고싶다면 SQS와 SNS를 이용하는 것이 좋은 방안이 될 수 있을 것 같습니다. 

 

오늘도 긴 포스팅 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요!

출처

https://blog.consol.de/software-engineering/cloud-native/aws-sqs-vs-traditional-message-brokers/

AWS SQS vs Traditional Message Brokers - ConSol Blog

https://medium.com/towards-polyglot-architecture/aws-sqs-sns-event-bridge-when-to-use-what-bc0b9b0e9f4d

AWS SQS, SNS & Event Bridge — When to use what?

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-s3-messages.html

Managing large Amazon SQS messages using Java and Amazon S3 - Amazon Simple Queue Service

https://stackoverflow.com/questions/31752503/what-are-the-possible-use-cases-for-amazon-sqs-or-any-queue-service

What are the possible use cases for Amazon SQS or any Queue Service?