[AWS] SNS vs SQS 차이점

💙베하💙 누구든 탑승할 수 있는 유임승차 팀입니다!!💨😉

지난주에 이어 이번 주에는 aws의 SNS와 SQS에 대해서 알아보았습니다!

SNS, SQS 이름도 비슷하고 얼핏 보면 하는 일도 비슷한 것 같아 보이는 서비스들이라 정리를 해보았습니다.

SNS	SQS
Simple Notification Service	Simple Queue Service
Publisher(게시자)가 Subscriber(구독자)에게 메세지를 전송하는 관리형 서비스	마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전관리형 메세지 대기열 서비스
Publisher는 Topic(주제)에 메세지를 발행한다. Topic은 수많은 Subscribers(구독자들)에게 전달될 수 있다.(fan out) 이때 전달 방식은 다양하다.(Lambda, SQS, Email ...)	시스템은 Queue로부터 새로운 이벤트를 실시할 수 있다. Queue에 있는 메세지들은 한 명의 consumer(고객) 또는 하나의 서비스에서 실행된다.
다른 시스템들이 이벤트에 신경쓰는가? Topic에 메세지를 publish(발행)하고 싶어하고, 사람들에게 발행되었다고 알리고 싶을 때	이 시스템이 이벤트에 신경쓰는가? 내가 이벤트의 수신자일 때

 

 

사용자가 웹사이트에서 물건을 구매했다고 가정하겠습니다. 이때 웹서비스가 갖는 결제 정보를 활용해서 서비스를 만든다고 가정해보면, 우리는 이 결제정보를 publish(발행)할 것입니다. 이때 우리는 SNS를 사용할 수 있습니다. 사용자가 웹사이트에서 물건을 구매했고 해당 결제 정보는 다음과 같습니다!! 를 알리며 결제 정보를 메시지에 담아 SNS Topic에 발행합니다. 우리는 이 메시지를 활용하여 각각 다른 서비스들을 만들어 볼 것입니다.

첫 번째, Lambda에 전달해볼 것입니다.

Lambda는 사용자에게 결제정보를 이메일로 보내주는 역할을 합니다.

두 번째, SQS Queue에 전달해볼 것입니다.

하루 동안 웹사이트에서 일어난 거래를 분석하는 서비스를 만들어볼 것입니다. 하루에 총 몇 건의 결제가 이루어졌는지, 총금액은 얼마인지 등등을 분석하려고 합니다. 결제가 이루어질 때마다 결제 정보를 SNS Queue에 저장한 후, EC2를 사용하여 Queue에 있는 메시지를 꺼내와서(poll) 분석을 진행합니다.

세 번째도 SQS Queue에 전달해볼 것입니다.

이번에는 거래 정보가 사기인지를 탐색하는 서비스를 만들어볼 것입니다. 결제건에 대하여 정상적인 결제인지, 사기인지를 판단하는 서비스입니다. 이 서비스도 마찬가지로 결제 정보를 SNS Queue에 저장한 후, EC2를 사용하여 Queue에 있는 메시지를 꺼내와서(poll) 분석을 진행합니다.

세 서비스는 각자 다른 일을 하지만, 결제 정보라는 동일한 이벤트를 기반으로 운영됩니다. 서로 다른 사용자(서비스)들이 동일한 하나의 이벤트에 관해 각각의 동작을 진행하는 방식이다. 이때 우리는 SNS가 필요합니다.

위의 세 가지 서비스중에서 Lambda는 서비스에 문제가 생겼을 때 해당 결제건에 대해 이메일 발송이 안될 수 있습니다. 하지만 SQS Queue에 들어온 메세지는 삭제하기 전에는 지워지지 않는다는 장점이 있기에 최소한 한 번은 꼭! 실행이 보장됩니다.

만약, 이 서비스들을 한 번에 실행하게 되면 어떻게 될까요? 사용자가 결제를 진행한 후, 해당 결제 정보를 통해 사용자에게 이메일을 보내고, 해당 거래건에 대해 분석을 하고, 해당 거래건이 사기인지 아닌지 판단하는 서비스를 순차적으로 진행한다고 생각해보면, 이건 매우 비효율적이고 좋지 않은 방식입니다. 그 이유는, 순차적으로 진행하면서 오류가 발생할 수 있는 구간이 너무 많기 때문입니다. 이메일을 보내다가 오류가 발생되면, 처음부터 다시 실행해야 합니다. 그럼 사용자는 결제를 다시 해야 하는 말도 안 되는 상황이 벌어질 수 있습니다. 따라서 서비스를 최대한 쪼개어(decouple) 독립적으로 실행될 수 있도록 하는 것이 중요합니다.

키워드로 정리를 해보면 다음과 같습니다.

SNS	SQS
Topic(Pub/Sub)	Queue
Push: 사용자에게 메세지 전송	Pull: 사용자가 메세지를 가져온다
Fanout: 같은 메세지를 여러 방향으로 발행	Decouple: 여러 서비스로 분리하여 병렬식 비동기 처리
메세지를 받는 사용자가 없으면 몇 번 시도하다가 삭제된다.	메세지는 일정 기간동안 유지된다.
하나의 메세지를 사용자들이 각각 다른 방식으로 활용	하나의 메세지를 사용자들이 동일한 방식으로 활용

 

그렇다면 애플리케이션 디커플링은 왜 필요할까?

애플리케이션 분리는 기본적으로 애플리케이션을 더 작고 독립적인 구성 요소로 분할하는 프로세스를 나타냅니다. 그 접근 방식의 반대는 대규모 모놀리식 애플리케이션을 유지하는 것입니다. 디커플링이 필요한 이유는 시스템 간 의존성을 제거하여 하나의 시스템 오류 시 다른 시스템에 영향을 주지 않고, 각자 병렬적으로 스스로 알아서 작동하여 서비스의 성능을 유지할 수 있습니다.

AWS에서 애플리케이션 디커플링을 위한 서비스는 다음 3가지가 있습니다.

• SQS : 큐잉 서비스
• SNS : Pub / Sub 모델
• Kinesis : 실시간 데이터 스트리밍

웹을 통해 사용자의 요청이 들어왔을 때, 그 응답을 만들기 위한 프로세스는 웹 서버와 다른 별도의 시스템에서 실행되며 매우 길고 복잡하다고 가정해보겠습니다. 사용자의 요청이 연달아 들어오는 경우, 이를 어딘가에 쌓아두었다가 차곡차곡 전달해야 하는 경우가 발생하며 이에 맞는 컴포넌트가 바로 Queue입니다. RabbitMQ나 Kafka 같은 서비스가 잘 알려진 큐잉 서비스입니다. 여기에선 AWS의 SQS를 조금 더 알아보겠습니다.

SQS(Simple Queue Service)

• 서버리스, 애플리케이션 간 디커플링
• 1 메시지/초 ~ 10,000 메시지/초
• 데이터 저장 기간 : 기본 4일, 최대 14일
• 메시지 수는 무제한
• 구독자에게 읽힌 메시지는 삭제됨
• 저지연 (게시 후 <10ms내에 구독됨)

위 이미지에서 예를 들었듯, 사용자가 본인의 비디오 파일을 업로드하면, SQS는 이를 별도의 비디오 프로세싱 시스템으로 전달하여 후속 작업을 진행하도록 합니다.

SQS의 대기열은 표준 방식(Standard)과 FIFO 방식 2가지가 있습니다.

 표준 방식

• 뒷단 시스템의 최소 1회 작업을 전달합니다.
• 메시지 순서는 보장되지 않습니다.

 FIFO 방식 

• 말 그대로 선입선출 방식이라 메시지 순서가 유지됩니다.
• 정확히 1번 처리합니다.

 

SNS(Simple Norification Service)

AWS SNS도 디커플링 서비스가로 볼 수 있습니다. 예를 들어 누군가 서비스를 구매하면 감사 메일을 해당 사용자의 이메일로 보내주는 서비스가 있다고 가정합니다. '서비스를 구매'하는 시스템과 '감사 메일을 발송'하는 시스템은 분리(디커플링) 되어 있으며 중간에서 이를 전달해 주는 역할을 SNS가 합니다.

SNS는 작업을 1:1로 처리하는 Direct Integration 모델과, 작업을 1:N으로 처리하는 Pub/Sub 작업 모델이 있습니다. 예를 들어 내가 Facebook에 뭔가 포스팅을 하면 내 친구들 모두에게 그 내용이 전달되는 것인 Pub/Sub 모델이라 할 수 있겠죠.

​

Pub/Sub 모델의 특징은...

- 게시자는 토픽 기반의 메시지 게시, 해당 토픽 구독자는 메시지 수신

- 토픽 당 최대 10,000,000 구독자. 토픽 개수는 100,000 개로 제한

- 구독자는 HTTP(S), Emails, SMS, Push Notification 등 다양

- SQS도 구독자가 될 수 있다. (fan-out model). 즉 SNS 신호를 받은 SQS가 뒤단의 또 다른 서비스를 호출

- Lambda도 구독자가 될 수 있다. 즉 SNS 신호를 받은 Lambda가 특정 함수를 실행

​

SQS는 대기열로 디커플링, SNS는 주제(Topic)를 생성하여 구독자를 대상으로 디커플링 서비스를 함을 잊지 맙시다. SNS도 표준 방식과 FIFO 방식이 있습니다.

 

길다면 길고 짧다면 짧은 글 읽어주셔서 감사합니다.

다음번엔 더욱 유익한 내용으로 찾아오겠습니다.

날씨가 많이 더워지고 있는데 얼음 나눠먹어요~,~