[AWS] Amazon SNS

SNS (Simple Notification Service)

SNS는 publisher(producer)가 subscriber(consumer)에게 메시지를 전달할 수 있는 관리형 서비스 입니다. publisher는 topic에 메시지를 보냄으로써 subscriber와 비동기적으로 통신합니다. 여기서 topic은 논리적 액세스 포인트 면서 publisher와 subscriber 사이의 통신 채널입니다. 따라서 클라이언트는 SNS topic에 대해 subscribe 하고 지원되는 엔드포인트 타입을 사용하여 publish된 메시지를 사용할 수 있습니다. 지원되는 엔드포인트에서는 다음 이미지 처럼 애플리케이션 간(A2A) 또는 애플리케이션과 사용자 간(A2P)에 통신이 가능합니다. 

SNS Delivery Protocols

Fanout Pattern

SNS을 사용하게되면 Fanout Pattern이라는 용어를 접하게됩니다. 그렇다면 Fanout Pattern이 무엇인지에 대해 알아보고 SNS와 SQS를 결합하여 Fanout Pattern이 어떻게 사용되는지 알아보겠습니다. Fanout Pattern이란 이벤트를 발생시키는 송신자(sender)가 있고, 이 이벤트를 여러 수신자(subscriber)에게 병렬로 전파 하는 메시징 패턴을 의미합니다. Fanout Pattern은 이벤트 기반 아키텍처에서 여러 구성 요소(component)가 독립적으로 이벤트에 반응하고 처리할 수 있도록 합니다. 다음은 Fanout Pattern의 일반적인 특징과 동작 방식에 관한 설명입니다.

 

1. 중앙 집중식 이벤트 발생
   송신자는 이벤트를 전체 시스템에 알리기 위해 중앙 집중식 이벤트 메커니즘을 사용합니다.
2. 구독자 등록
   수신자가 송신자의 이벤트에 관심이 있으면 해당 이벤트에 대해 구독합니다. 이를 통해서 각 수신자는 특정 이벤트에 대한 알림을 받을 수 있습니다.
3. 이벤트 전파
   이벤트가 발생하면 송신자는 해당 이벤트를 구독한 모든 수신자에게 동시에 전파합니다. 이때 중앙 집중식 메커니즘이 사용되므로 송신자는 각 수신자에 직접적으로 연결할 필요가 없습니다.
4. 독립적인 처리
   각 수신자는 독립적으로 이벤트를 처리합니다. 이는 시스템 간에 느슨간 결합을 유지하면서도 효과적인 확장이 가능하게 합니다.
5. 확장성
   새로운 수신자를 추가하거나 기존 수신자를 제거하는 데도 상호 간의 영향이 적습니다.

앞서 말한 것처럼 Fanout Pattern은 이벤트 기반 시스템에서 중요하며, 여러 구성 요소 간의 통신이 느슨하게 결합(loose coupling)되어야할 때 유용하게 활용됩니다.

SNS Fanout Scenario

SNS의 Fanout 시나리오는 SNS topic에 publish된 메시지가 복제되어 다양한 엔드 포인트로 push 되는 경우 입니다. 이에 따라 병렬적으로 비동기 처리가 가능합니다. 예를 들어 커머스 서비스에서 고객 주문이 발생했을 때 주문접수 서비스와 이메일 발송 서비스가 있다고 가정해보겠습니다.

 

고객 주문이 결제 완료가될 때 SNS topic에 메시지가 publish되도록 애플리케이션을 개발합니다. 각 SQS queue는 SNS topic을 구독하고 결제 완료 이벤트가 들어오면 이에 대해 동일한 알람을 받습니다. SQS queue 중 하나에 연결된 EC2 인스턴스A(주문 접수 애플리케이션)는 주문을 처리할 수 있도록 합니다. SQS queue 중 하나에 연결된 EC2 인스턴스B(이메일 발송 애플리케이션)는 주문 내역을 고객에게 이메일로 발송합니다. 위 시나리오를 그림으로 표현하면 다음과 같습니다.

 

SNS Fanout Scenario - 정상 케이스

위 시나리오에서 장애 상황에 대한 예를 살펴보겠습니다. 이전과 동일하게 고객 주문이 결제가 완료되면 SNS topic을 통해 메시지가 전달되어 각 SQS에 동일한 메시지가 전달됩니다. 어떤 비즈니스에서는 결제 완료 후 즉시 고객 주문을 처리해야 할 수 있습니다. 그런데 결제 완료 이벤트로 처리해야 하는 서비스 중(주문 접수, 이메일 발송) 이메일 발송 서비스에 문제가 발생했다고 가정합니다. 이메일 발송 서비스 장애로 이메일 발송은 즉시 이루어지지 않았지만, 결제가 완료되었으므로 주문 접수는 정상적으로 처리되어야 합니다.

 

따라서 이런 상황에서는 결제 완료 이벤트에 따라 우선 주문을 접수하여 처리하고, 이메일 발송은 별도로 문제 원인을 파악하여 재처리하여 고객 경험을 헤치지 않도록 할 수 있습니다. 이렇게 하나의 이벤트에 대해 고객에게 다양한 서비스를 제공해야 하는 경우, Fanout Pattern을 사용할 수 있습니다. Fanout Pattern을 적용하면 각 수신자가 독립적으로 이벤트를 처리할 수 있으므로 서비스 간의 의존성을 최소화할 수 있습니다. 위 시나리오를 그림으로 표현하면 다음과 같습니다.

 

SNS Fanout Scenario - 일부 서비스 실패 케이스

Summary

SQS와 SNS는 AWS에서 제공하는 메시징 서비스입니다. SNS를 사용하면 애플리케이션에서 주기적으로 업데이트를 확인하거나 Polling 하지 않고 Push 방식으로 여러 subscriber에 메시지를 보낼 수 있습니다. 또한, SNS와 SQS를 함께 사용하여 Fanout Pattern을 구현할 수 있습니다. Fanout Pattern은 이벤트 기반 시스템에서 중요하게 사용되는 대한 개념입니다.

TIL

AWS 서비스 중 비슷한 이름을 갖고 있는 SNS와 SQS에 대한 차이점을 알았다, SQS를 단독으로 사용하는 것외에 SNS과 SQS를 함께 사용하는 Fanout 시나리오에 대해 알게 되었다. SQS를 사용했을 때 단독으로 사용했을 때의 장/단점과 SNS와 SQS를 결합하여 Fanout Pattern을 구현했을 때의 장/단점을 잘 알고, 비즈니스에서 제공해야하는 기능에 따라 적절한 선택이 필요할 것 같다. 실무에서 좀 더 활발하게 SNS, SQS를 사용하여 AWS 메시징 서비스에 대한 know-how 글을 작성해 보고 싶다는 생각이 들었다.

References

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

https://docs.aws.amazon.com/sns/latest/dg/sns-common-scenarios.html

https://docs.aws.amazon.com/sns/latest/dg/sns-sqs-as-subscriber.html