알림시스템 구축을 위한 SQS, SNS, MSK 비교

목차

1. 개요

2. SQS

• 특징
• 장점 / 단점
• Use casse

 

3. SNS

• 특징
• 장점 / 단점
• Use casse

 

4. MSK

• 특징
• 장점 / 단점
• Use casse

 

6. 3가지 서비스 비교

7. 결론

 

 

개요

회사에서 알람 시스템을 구축하게 됐습니다.
시니어 분이 브리핑한 아키텍처에선 AWS MSK 를 활용하여 이벤트 드리븐 알림 시스템을 구축할 예정입니다.
흔히 알림 시스템에서 사용될 수 있는 AWS Service 를 떠올리면 대표적으로 AWS SNS 가 있었는데 MSK 를 사용할 것이란 점에서 두 서비스의 특징과 차이를 이해할 필요가 있다고 느꼈습니다. 더불어 SQS 도 살펴보면서, 각 서비스가 가지는 특징을 비교하여 회사에서 구축할 알림 시스템이 어떤 형태일지 조사했습니다.

 

SQS : Simple Queue Service

이름 그대로 간단한 Queue 서비스이며, Standard 와 FIFO 2가지 유형이 있습니다.

• Standard : 초당 거의 무한히 확장 가능하지만 순서는 보장하지 않습니다. at-least-once 메시지 전달을 지원합니다.
    거의 무제한의 처리량을 허용하는 고도로 분산된 아키텍처 때문에, 둘 이상의 메시지 사본이 순서가 맞지 않게 전달될 수 있습니다.
• FIFO : 선입선출형 메시지 큐로 먼저온 메시지를 먼저 처리할 수 있는 순서형 서비스입니다. 대신 FIFO 형 서비스는 초당 3000개의 트랜잭션만 처리할 수 있습니다.

 

한번 컨슈머에 의해 처리(consume)된 메시지는 큐에서 삭제되며, 하나의 메시지는 하나의 컨슈머에서만 처리될 수 있습니다.

미지원 기능 : 실시간 분석, 한번 사용된(consumed) 메시지 다시읽기(re-read)

 

장점

• 확장 가능성: SQS 는 높은 확장성을 제공합니다. 큐 크기를 늘리거나 메시지 처리량을 증가시킬 수 있으며, 대기 시간을 줄이기 위해 리소스를 추가로 확보할 수 있습니다.
• 유연성: 앞서 말했듯이 FIFO 와 Standard 유형의 큐를 제공하며, 여러 프로토콜(HTTP, HTTPS, Amazon SDK 등)을 사용하여 메시지를 보낼 수 있으므로 다양한 환경에서 사용할 수 있습니다.
• 내결함성: SQS는 AWS에서 호스팅되므로 매우 내결함성이 높습니다. 또한, 복제 및 백업 기능으로 메시지가 손실되는 경우를 방지할 수 있습니다.

단점

• 비용: SQS 는 사용량 만큼 비용이 청구됩니다. 메시지 처리량이 높을 경우, 많은 비용이 발생할 수 있습니다. 때문에 작은 단위의 작업을 처리하는 경우 더욱 비싸집니다.
• 지연시간: SQS 는 비동기 메시징 서비스이므로, 고성능의 실시간 처리를 위해 설계되지 않습니다. SQS 큐에서 메시지를 수신하는 데 최대 몇 초까지 소요될 수 있으므로, 실시간 응답이 필요한 경우에는 다른 대안을 고려해야 합니다.
• 메시지 중복 가능성 : SQS 에서 메시지를 consume 한 후 삭제하지 않을 시, 일정 시간 후 메시지가 다시 큐에 전달되어 동일한 메시지가 중복으로 처리될 가능성이 존재합니다.
• 메시지 크기 제한: SQS 는 메시지 크기 제한이 있습니다. Standard 에서는 256KB, FIFO 에서는 128KB 입니다.

 

유즈 케이스

필자가 개발한 메타버스 공간 Zep 의 캐릭터 움직임을 추적하는 서비스에선, 각 캐릭터의 움직임이 동시다발적으로 서버에 전송됩니다.
이 때 각 캐릭터 행동의 순서보다는 어떤 행동을 하는지 트래킹하는 것이 더 중요하기 때문에, 동시다발적으로 전송되는 메시지의 순서를 고려할 필요는 없습니다.
때문에 이런 경우에는 SQS Standard 서비스를 사용하는 것이 적절하다고 볼 수 있다.

 

 

SNS : Simple Notification Service

Pub/Sub 모델을 지원하는 완전관리형 메시지 게시/구독 서비스입니다.

SQS 는 Standard 형과 FIFO 형 2가지로 나뉘듯, SNS 는 A2A 와 A2P 2가지 방식으로 나뉠 수 있습니다.

• A2A : Application to Application 으로 분산된 시스템, Micro Service 및 이벤트 중심 애플리케이션 간에 푸시 기반의 대용량 다대다 메시징을 지원합니다. 
• A2P: Application to Person 으로 SMS text, Push 알림, Email 을 통해 고객에게 메시지를 전송할 수 있습니다.

Push 방식으로 메시지를 전달하여 메시지가 전달되는 것을 100% 보장하지 못합니다. 

 

장점

• 스케일 아웃: SNS는 다수의 구독자에게 메시지를 전송할 수 있는 Pub/Sub 구조를 갖추고 있습니다. 이를 통해 메시지 전달 시스템을 확장할 수 있습니다. 
• 다양한 프로토콜 지원: SNS는 여러 프로토콜(HTTP(S), SMS, Email, Lambda 등)을 지원하여 다양한 통신 채널에서 알림을 송신할 수 있습니다.
• 내결함성: AWS 관리형 시스템이기 때문에 내결함성이 높아 안정적으로 메시지를 계속 전달할 수 있습니다.

단점

• 비용: 사용량 만큼 비용이 청구됩니다. 발행 요청, 구독 요청, 메시지 전송 데이터 볼륨 등에 따라 비용이 달라지며, 이는 프로젝트 규모와 종류에 따라 달라집니다.
• 지연 시간: 리전마다 다르지만 전송 지연 시간이 생길 수 있습니다. 이로 인해 실시간 알림이 필요한 시스템에서는 제약이 될 수 있습니다.
• 메시지 크기 제한: SNS는 메시지 크기에 제한이 있습니다. 용량이 클 경우 메시지를 분할하는 추가 작업이 필요합니다.

유즈 케이스

• 시스템 이벤트 알림: 애플리케이션 오류나 업데이트 등의 이벤트 알림을 개발자에게 전달할 수 있습니다.
• 활성화 된 처리 알림: 웹 애플리케이션에서 비동기 처리 작업이 완료될 때 알림을 보낼 수 있습니다.
• 사용자 알림: 휴대폰 번호, 이메일 주소, Slack 등의 채널을 통해 사용자에게 알림을 보낼 수 있습니다. 위에서 언급한 A2P 유형에 해당됩니다.
  
  

 

MSK : Managed Streaming for apache Kafka

완전 관리형의 고가용성 Apache Kafka 서비스로 대용량의 스트림 데이터를 송/수신 할 수 있습니다.

Apache Kafka 위에 구축된 MSK는 고성능 및 확장성을 확보하여 대용량의 데이터를 실시간 처리하는데 적합합니다. 프로비저닝 버전을 사용하면 다른 카프카 제공 서비스에 비해 비용도 낮게 유지할 수 있는 장점이 있습니다.

EC2에 직접 Kafka 를 설치하는 것과 비교했을 때, 시간과 비용을 단축시킬 수 있고 이슈가 발생했을 때 cloudwatch 에서 지표를 확인하기 비교적 수월합니다. 관리형 서비스의 상당한 이점이라 생각됩니다.

 

* 여기서 스트리밍이란, 연속적으로 발생하는 데이터의 흐름을 의미합니다. 게더타운이나 Zep 같은 서비스에서 각 캐릭터들이 움직일 때마다 이벤트를 발생한다고 가정해봅시다. 하나의 맵에 400명 정도의 유저 캐릭터가 존재할 때 1초마다 각 캐릭터가 움직이면 때마다 초당 400개의 이벤트가 발생합니다. 하나의 맵 뿐 아니라 여러개의 맵에서 발생하는 이벤트도 트래킹한다고 가정하면 처리해야할 이벤트가 더 많이 늘어나죠. 이렇게 끊임없이 발생하는 이벤트나 트랙잭션의 흐름을 스트리밍이라 부를 수 있습니다. MSK 는 이런 스트리밍 데이터를  확장성 있게 처리할 수 있는 것이죠. 

 

장점

• Kafka를 사용하여 대용량 데이터 처리에 적합합니다. MSK는 엄청난 양의 데이터를 처리할 수 있습니다.
• 실시간으로 데이터를 수집 및 처리할 수 있어 이벤트 기반 시스템을 강화할 수 있습니다.
• MSK 는 Apache Kafka 커뮤니티의 기존 애플리케이션과 도구 및 플러그인이 지원되기 때문에, 애플리케이션의 기존 카프카 코드를 변경할 필요가 없습니다.
• 높은 확장성과 실시간 데이터 처리 능력 및 Connector 와 라이브러리르 활용하여 다양한 기능에 사용할 수 있습니다.

단점

• MSK를 관리하기 위해 많은 시간과 노력이 필요합니다.
• SQS 나 Kinesis 같은 서비스에 비교해 높은 러닝 커브를 가지며 상대적으로 설정해야할 부분이 많습니다. 
• 비용이 높습니다. 클러스터 노드, EBS 스토리지 및 데이터 전송 비용이 수반됩니다.
• MSK는 Kafka로, 분산 시스템입니다. 이는 Kafka만 사용할 수 있다는 의미가 아닌, 전용 라이브러리와 개발자를 학습해야 한다는 것입니다.

유즈 케이스

• 실시간 알림 시스템: MSK 는 대용량 데이터 처리에 특화된 서비스로 실시간 알림 시스템 구축에 이상적인 기술입니다. 예를 들어, 사용자가 특정 이벤트에 대해 실시간으로 알림을 받고자 하는 경우, Kafka 로 구축된 파이프라인을 따라 데이터 스트림을 처리하면 사용자에게 알림을 전송할 수 있습니다.
• 다중 채널 통합 알림: MSK는 여러 채널(메시지, 이메일, 앱 푸시 등)에 데이터를 송신할 수 있습니다. 커넥터와 스트림 처리 라이브러리로 각각의 채널로부터 데이터를 수신한 뒤 Kafka 파티션으로 분배합니다. 이후 각 채널마다 특정 파티션을 구독하여 필요한 알림을 전송할 수 있습니다.
• 분석 및 모니터링: MSK를 사용하여 알림 데이터를 수집하고 처리한 후, 별도의 분석 시스템으로 전송할 수 있습니다. 또한, 서비스에서 발생하는 이벤트를 모니터링하여, 비정상적인 상황(용량 초과, 부하 문제 등)에 신속히 대응할 수 있는 시스템을 구축할 수 있습니다.

 

3가지 서비스 비교

현재 회사에서 구축할 알림 시스템이 MSK를 선택할 정도로 대용량 데이터 처리가 필요한지 추가적으로 조사해 볼 예정입니다. 우선은 단순 알림 시스템 뿐만 아니라 추가적인 작업도 처리가 필요하여 MSK 를 선택한 것 같습니다.

	SQS	SNS	MSK
서비스 유형	메시지 큐 서비스	알림 메시징 서비스	Managed Apache Kafka
확장성	높음 (큐 크기 및 처리량 조절 가능)	높음 (Publisher, Consumer 쪽에서 확장 가능)	높음 (Cluster 크기 및 파티션 조절 가능)
데이터 전송 방식	비동기 (Standard / FIFO)	주로 비동기 (Pub/Sub 모델)	동기 및 비동기 구성 가능
비용	사용한 만큼 비용 발생	사용한 만큼 비용 발생	클러스터 노드, EBS, 데이터 전송 비용
메시지 크기 제한	Standard queue : 256kb FIFO : 128kb	256kb 제한	Kafka 의 최대 메시지 크기 제한까지 가능 default 1Mb
관리 난이도	낮음	낮음	Managed Service 지만 상대적으로 관리 어려우며, Kafka 이해도 필요
사용 사례	비동기 작업, 간단한 확장성 필요, 분산 처리	비동기 작업, 이벤트 알림, 메시지 확장성 필요(Fan-out)	대용량 데이터 처리, 실시간 스트리밍, 전용 인터페이스 지원.

 

 

결론

 단순 알림 메시징 서비스 구축을 위해서라면 MSK 는 오버스펙이 아닐까 생각이 들었습니다. AWS SNS 를 활용하면 알림 서비스의 역할은 제대로 해낼 것이라 생각하는데요, SNS 사용시 메시지 크기의 제한이 있는 점과 사내 알림 시스템에 어떤 작업이 더 추가될 것인지를 고려하면 MSK 가 적합한 선택이라 생각됩니다. 메시지 전달과 간단한 비동기 작업만 담당하는 경우 SQS 도 좋은 선택이지만, 실시간 처리가 불가능하단 점과 메시지 순서를 보장할 때의 성능을 고려해야 합니다. SQS 의 FIFO 유형을 선택하면 메시지 순서는 보장할 수 있지만, 초당 처리할 수 있는 메시지가 3000개로 제한되는 등 제약이 있을 것으로 예상됩니다.

 물론 MSK 라고 해서 은탄환이 될 순 없습니다. 앞서 비교한 SQS, SNS 보다 성능적 이점을 가질 순 있지만, 브로커, 프로듀서, 컨슈머, 파티션 등 다양한 컴포넌트의 설정과 클러스터 운영 및 용량 관리에 대한 높은 경험치를 요구할 수도 있습니다.  비용 문제도 빼놓을 수 없겠죠.

앞으로 구축해나갈 알림 시스템이 어떤 모습으로 발전할지 지속적으로 기록해보겠습니다. 지금은 맞다고 생각한 포인트가 나중엔 달라질 수도 있는 일이니까요.

 

 

 

ref

https://www.linkedin.com/pulse/sqs-kinesis-msk-supratim-kundu/

https://seohyun0120.tistory.com/entry/AWS-SNS-vs-SQS-%EC%B0%A8%EC%9D%B4%EC%A0%90

https://sharplee7.tistory.com/114

https://techblog.gccompany.co.kr/aws-msk-part1-msk-%EB%8F%84%EC%9E%85-%EC%97%AC%EC%A0%95-b000cbea5c02