[AWS] Amazon SNS 쉽게 개념과 특징 정리 (Simple Notification Service, Topic, Fan Out 구조)

◇  공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇

 

Amazon SNS

Simple Notification Service

Amazon SNS

• 완전 관리형(Fully managed)의 Pub/Sub 서비스이다.
• SNS를 사용하여 AWS 내부의 서비스(ex. SQS, Lambda) 또는 외부의 시스템(ex. email)에 메시지를 보낼 수 있다.
• Decoupling 아키텍처로서 유용하다. (loose coupling)

 

SNS 구조: Pub/Sub

Publisher는 메시지를 보내는 쪽이고, Subscriber는 메시지를 받는 쪽이다.

 

 

A2A 와 A2P: 메시지를 전송하는 대상

Aplication to Aplication (A2A)

• SQS, Lambda, Kinesis Data Firehose에 메시지를 보낼 수 있다.
• HTTP/HTTPS로 다른 리소스에 메시지 보낼 수 있다.

Aplication to Person (A2P)

•  SMS(문자 텍스트), 모바일 Push 알림, 이메일(Json 형식)로 유저에게 메시지를 보낼수 있다.

https://docs.aws.amazon.com/ko_kr/sns/latest/dg/welcome.html

지원하는 프로토콜과 AWS 서비스

• HTTP/HTTPS
• SMS (모바일: iOS, Android)
• Email, Email-JSON
• Amazon SQS
• AWS Lambda

위의 그래프와 지원하는 프로토콜&AWS서비스를 이해해두면 SAA 시험에서 SNS관련 문제를 맞출 수 있다.

SNS로 이메일을 유저에게 보낼 수 있지만 이 때 첨부 파일과 함께 보낼 수 없다.
참고: AWS 공식 문서

 

 

SNS의 UseCase

1. 여러 사용자에게 일괄적으로 알림을 보내는 경우
   새로운 알림이나 유지보수의 공지가 있을 때, SNS를 사용하여 여러 구독자(사용자)에게 동시에 알림을 보낼 수 있다.
2. 이벤트 발생을 계기로 실시간으로 처리하고 싶은 경우
   이벤트가 발생했을때 실시간으로 알려줄 수 있다. 예를 들어, CloudWatch에서 이상을 감지했을 때 즉시 알림을 보내거나, 온라인 사이트의 상품의 입출고 이벤트가 생겼을 때 다음 처리를 시작해야 하는 경우에 유용하다.
3. 시스템 내의 컴포넌트를 느슨한 결합도로 연동하고 싶은 경우 → Decoupling
   메시지를 만든 사람은 구독자가 어떤 프로토콜로 메시지를 받을지, 어떤 구독자가 있는지 등을 신경 쓸 필요 없이 메시지를 발행할 수 있다. 새로 구독자를 추가해도 발행자에게 영향을 주지 않으므로, 컴포넌트 간의 결합도를 낮춰서 시스템을 구축할 수 있다.
4. 여러 컴포넌트에서 병렬로 처리를 수행하는 시스템
   하나의 메시지를 여러 구독자(컴포넌트)가 수신할 수 있으므로, 예를 들어 사용자 이미지 게시를 계기로 데이터베이스에 등록하는 처리, 썸네일을 생성하는 처리, 이미지를 분석하는 처리 등을 독립적으로 병렬로 진행할 수 있는 시스템을 구현할 수 있다.

 

 

Topic (토픽)

SNS는 토픽이라는 기능을 통해 메시지를 보낸다.

이런 구조를 통해 비동기통신(Asynchronous)을 실현시킨다

 

Publisher → 토픽 →  Subscriber

 

다음은 Console에서 SNS에서 Topic 만드는 예시이다.

https://aws.amazon.com/tutorials/filter-messages-published-to-topics/

 

 

 

📨 Publisher (발행자)

Publisher는 Amazon SNS에서 메시지를 발신하는 애플리케이션 등을 의미한다. Publisher는 메시지를 발행하고자 하는 Topic을 선택하여 메시지를 배포한다. Subscriber의 존재나 프로토콜의 종류 등은 신경 쓸 필요가 없다.

 

다음은 Console에서 메시지를 발신하는 예시이다.

 

 

📩 Subscriber (구독자)

Subscriber는 메시지를 수신하는 (구독하는) 애플리케이션이나 사용자이다.

Subscriber는 알림을 받고 싶은 1)Topic ARN과 사용할 2)프로토콜을 선택하고 등록한다.

 

프로토콜 종류

1. Amazon SQS
2. AWS Lambda
3. Email
4. HTTP/HTTPS
5. JSON
6. SMS

다음은 실제 Subscription 등록 화면의 예시이다.

 

 

 

 

토픽을 정해두면 하나의 토픽에 구독된 서비스(유저)에게 함꺼번에 메시지를 전송하게 된다. 
이러한 구조를 Fan Out 구조라고 한다.

 

Fan Out 구조

https://betterprogramming.pub/how-to-fan-out-to-different-sqs-queues-using-sns-message-filtering-84cd23ed9d07

[자주 사용되는 SNS와 SQS 조합의 구조]

 

 

Topic의 종류

SNS에서 토픽을 생성할 때는 "FIFO (First In, First Out)" 또는 "Standard (표준)" 중 하나를 선택해야 한다.

1. FIFO
   • 순서 보장: 즉, 메시지가 1, 2, 3의 순서로 발행되면, 수신자는 이 메시지를 1, 2, 3 순서로 받게 된다.
   • 중복 제거: FIFO 토픽은 메시지 중복 제거 기능을 지원합니다. 같은 메시지가 중복 발행되더라도, 중복 제거 기능이 활성화되어 있으면 중복된 메시지는 수신자에게 한 번만 전달된다.
     
   • FIFO 큐와의 통합: FIFO 토픽은 Amazon SQS FIFO 큐와 통합되어 있으며, 프로토콜로 SQS FIFO만 사용할 수 있다. 메시지는 FIFO 큐를 통해 전달되며, 큐에서도 메시지 순서와 중복 제거가 적용된다.
2. Standard
   • 순서 비보장: Standard 토픽은 메시지의 순서를 보장하지 않는다. 
   • 중복 가능성: Standard 토픽은 메시지 중복 제거 기능을 제공하지 않는다. 이로 인해, 메시지가 여러 번 전달될 가능성이 있다.
   • Standard 토픽에서는 메시지가 "최소 1회" 배포되지만, 중복 제거를 활성화하면 메시지가 반드시 1회만 배포되도록 할 수 있다.
   • FIFO 토픽은 이벤트가 발생한 순서대로 처리하거나 처리가 중복되지 않아야 하는 경우에 사용한다.

https://docs.aws.amazon.com/sns/latest/dg/fifo-example-use-case.html

 

 

 

전송 실패시 SQS 데드레터 큐(DLQ, dead letter queue)의 활용

SNS에서는 SNS 토픽에서 메시지 전송에 실패하면 일반적으로 메시지를 삭제한다.

메시지 삭제를 방지하려면, 전송 실패 메시지를 Amazon SQS의 데드레터 큐(dead letter queue)로 전송하도록 구독(subscribe)을 설정해야 한다.

 

예를 들어, 구독(subscribe)이 Lambda 함수인 경우, 데드레터 큐에 저장된 메시지를 Lambda 함수가 폴링하여 SNS 토픽에서 전송된 모든 메시지가 Lambda 함수에서 처리되도록 할 수 있다.

 

 

 

---

SAA 문제 예시

😁 1. 문제

Amazon SNS의 유스케이스로 적절한 것을 3가지 선택하십시오.

 

1. 스트리밍 데이터를 수집하고 처리하는 시스템
2. 자택 개인 PC에서 VPC로 안전하게 접근하는 시스템
3. 시스템 내의 컴포넌트를 낮은 결합도로 연계하는 시스템
4. 이벤트가 발생할 때 다음 처리를 시작하는 실시간 시스템
5. 24시간 365일 지속적으로 가동되어야 하는 미션 크리티컬 고가용 시스템
6. 여러 컴포넌트에서 병렬로 처리하는 시스템

정답

정답. 3, 4 ,6

 

3번: 시스템 내의 컴포넌트를 낮은 결합도(loose coupling)로 연계하는 시스템

시스템 내의 컴포넌트를 낮은 결합도(loose coupling)로 연계하는 경우 메시지 Publisher는 Subscriber가 어떤 프로토콜로 메시지를 받을지, 어떤 구독자가 있는지를 신경 쓰지 않고 메시지를 발행할 수 있다. 새로운 Subscriber가 추가되더라도 Publisher에게 영향을 미치지 않으므로, 컴포넌트 간의 결합도를 낮게(느슨하게) 시스템을 구축할 수 있다.

 

4번: 이벤트가 발생할 때 다음 처리를 시작하는 실시간 시스템

이벤트 발생을 계기로 실시간 처리를 하고 싶은 경우 푸시 알림은 이벤트 발생을 실시간으로 알릴 수 있다.
예를 들어, CloudWatch에서 이상을 감지했을 때 즉시 알림을 보내거나, 상품의 입고나 출고 등의 이벤트를 추적해 다음 처리를 시작하고 싶은 경우에 활용할 수 있다.

 

6번: 여러 컴포넌트에서 병렬로 처리하는 시스템

하나의 메시지를 여러 Subscriber(컴포넌트)가 받을 수 있으므로, 예를 들어 사용자가 이미지를 업로드했을 때, 데이터베이스에 등록하는 처리, 썸네일을 생성하는 처리, 이미지를 분석하는 처리 등 독립된 각각의 처리를 병렬로 진행하는 시스템을 구현할 수 있다.

오답

 

• 1번: 스트리밍 데이터를 수집하고 처리하는 시스템 스트리밍 데이터를 수집 및 처리하는 서비스로는 Amazon Kinesis가 있다. SNS는 푸시 알림을 수행하는 시스템이므로 오답이다.
• 2번: 자택의 개인 PC에서 VPC로 안전하게 접근하는 시스템 SNS는 네트워크 연결을 제공하는 서비스가 아니다. 자택의 PC에서 VPC로 안전하게 접근하는 대표적인 서비스로는 AWS Client VPN이 있다.
• 5번: 24시간 365일 가동되어야 하는 미션 크리티컬 고가용 시스템 미션 크리티컬 시스템이란 매우 높은 신뢰성, 가용성, 내장애성을 요구하는 시스템을 말한다. 금융 계열의 핵심 시스템이나 철도 및 항공의 운항 관리 시스템 등 24시간 365일 정상적으로 가동되어야 하는 시스템이 이에 해당한다.
  SNS는 메시징 서비스로, 이상이나 장애를 감지했을 때 즉시 알림을 보내는 운영은 가능하지만, 가용성이나 신뢰성을 높이는 기능은 없다.

---

😁 2. 문제

 

대형 소매 체인이 온라인 주문의 상태 업데이트를 고객, 배송 파트너, 매장 간에 공유하는 시스템을 개발하고 있습니다. 고객이 온라인으로 주문을 하면, 해당 주문의 준비, 출하, 배송 상태가 실시간으로 업데이트되어 모든 관련자에게 신속하게 알림이 전송되어야 합니다. 이 시스템은 날마다 성장하는 고객 기반과 전국에 분포된 다수의 매장 및 새로운 배송 파트너를 신속하게 추가할 수 있는 유연성이 필요합니다. 주문의 각 상태 변경은 고객에게는 이메일로, 배송 파트너와 매장에는 HTTP 엔드포인트를 통해 효율적으로 알림을 보내고, 적절한 관계자에게 실시간으로 정보를 제공하기 위해 가장 효율적인 방법은 무엇일까요?

 

1. Kinesis Data Streams를 사용하여 주문 상태 업데이트를 스트리밍 데이터로 처리하고, Lambda 함수를 사용하여 고객, 배송 파트너, 매장에 각 상태 업데이트에 따라 이메일 또는 HTTP 알림을 전송한다.
2. AWS Lambda를 사용하여 주문 데이터베이스(DynamoDB)에서 상태를 읽고, 각 업데이트에 대해 관련 고객에게 이메일로, 배송 파트너와 매장에는 HTTP 엔드포인트를 사용하여 알림을 보낸다.
3. 주문 상태 변경을 Amazon S3에 저장하고, 이 변경을 트리거로 AWS Step Functions를 시작한다. Step Functions는 상태 변경마다 관련 고객에게 이메일을 보내고, 배송 파트너와 매장에는 HTTP 엔드포인트를 통해 알림을 전송한다.
4. 주문 상태 업데이트용 SNS 토픽을 생성한다. 고객은 이메일 프로토콜로, 배송 파트너와 매장은 HTTP로 토픽에 구독하며, 주문 상태가 업데이트되면 각각 설정된 통신 방법으로 실시간으로 알림을 전송한다.

정답

정답. 4

Amazon Simple Notification Service(SNS)는 완전 관리형 메시징 서비스로, 시스템 간에 알림이나 데이터를 교환하는 수단으로 사용됩니다. 이 서비스는 이메일, SMS, Lambda 함수, Amazon SQS, HTTP/HTTPS 등 다양한 프로토콜을 통해 여러 애플리케이션이나 사용자에게 동시에 메시지를 전송할 수 있습니다. 또한, SNS는 푸시형 서비스이기 때문에 구독자의 상태에 관계없이 실시간으로 메시지를 전달할 수 있습니다. 이 즉시성은 온라인 주문의 상태가 변경될 때 즉시 알림을 보내야 할 필요가 있을 때 유용합니다. 더불어 SNS는 매우 높은 확장성을 제공하여 새로운 구독자를 추가해도 시스템을 쉽게 확장할 수 있으므로, 급속히 성장하는 비즈니스의 요구에 유연하게 대응할 수 있습니다.

오답

• "AWS Lambda를 사용하여 주문 데이터베이스(DynamoDB)에서 상태를 읽고, 각 업데이트에 대해 관련 고객에게 이메일로, 배송 파트너와 매장에는 HTTP 엔드포인트를 사용하여 알림을 보낸다."
  Lambda 함수를 생성하는 데는 시간이 걸리며, 주문이 많이 발생하는 경우 각 주문 상태 업데이트마다 Lambda 함수가 실행되어 실행 비용이 높아질 수 있습니다. SNS는 비용 효율적으로 알림을 보낼 수 있으므로, 이 방법은 잘못된 선택입니다.
• "Kinesis Data Streams를 사용하여 주문 상태 업데이트를 스트리밍 데이터로 처리하고, Lambda 함수를 사용하여 고객, 배송 파트너, 매장에 각 상태 업데이트에 따라 이메일 또는 HTTP 알림을 전송한다."
  Kinesis Data Streams는 대량의 데이터를 실시간으로 수집하고 처리하는 서비스로, 주문 상태 업데이트와 같은 이벤트 중심보다는 지속적인 데이터 흐름에 적합합니다. 따라서 이 방법은 부적절합니다.
• "주문 상태 변경을 Amazon S3에 저장하고, 이 변경을 트리거로 AWS Step Functions를 시작한다. Step Functions는 상태 변경마다 관련 고객에게 이메일을 보내고, 배송 파트너와 매장에는 HTTP 엔드포인트를 통해 알림을 전송한다."
  S3와 Step Functions를 조합하여 주문 상태 업데이트에 대한 알림 처리를 구현할 수 있지만, SNS에 비해 설정이 복잡하고 수신자 추가 및 변경에 대한 유연성이 낮습니다. 따라서 이 방법은 적합하지 않습니다.