[AWS] 유사 서비스인 SNS와 EventBridge의 핵심 차이

 

 

 

 

AWS의 서비스에서 이벤트에 대한 알림을 발송해야 할 때 SNS와 EventBridge를 자주 사용한다.

 

SNS의 경우(https://docs.aws.amazon.com/ko_kr/sns/latest/dg/welcome.html)

 

 

EventBridge의 경우(https://www.megazone.com/techblog_20200309_reducing-custom-code-by-using-advanced-rules-in-amazon-eventbridge/)

 

 

두 가지 서비스를 활용하면 이벤트 기반 아키텍처를 설계할 수 있다.

 

그런데 어떤 상황에서는 EventBridege를 활용해서 알림을 보내기도 하고 SNS로 알림을 보내기도 한다.

이런 상황의 차이는 무엇일까?

 

 

 

 

대상의 차이

SNS 주제의 구독 대상은  상당히 적다.

AWS의 서비스로는 Kinesis, SQS, Lambda 밖에 지원이 안 되고 있다.

 

 

 

 

EventBridge 출시 전에는 SNS와 연동된 Lambda를 통해서 다른 서비스와의 연동을 진행했다고 한다.

이러한 Lambda 코드의 관리 또한 문제가 발생할 수 있는 지점이다.

 

반면 비교적 새로 출시된 서비스인 EventBridge는 대상으로 AWS의 다양한 서비스가 지원된다.

 

 

 

 

HTTP/S와 같은 경우는 SNS가 지원하기 때문에 특정 엔드포인트로 이벤트 정보를 보내고 싶다면 SNS가 적절할 것이고,

더 다양한 AWS 서비스를 대상으로 전송하고 싶다면 Event Bridge가 적절할 것이다. 

 

 

 

 

 

 

 

Event 생성과 전달 차이

 

SNS와 EventBridge둘다 SDK를 통해 이벤트 생성을 지원한다.

SNS와는 다르게 EventBridge는 이벤트 버스로 전송을 하고 Rule을 통해 특정 이벤트에 대해서 알림을 전송할 수 있다.

 

간단히 세팅하고 싶다면 SNS가 좋을 수 있다.

하지만 구독자에게는 특정 이벤트만 전송하기 위해서, 이벤트에 따라 다양한 주제를 생성하고 구독자와 연결해야 한다.

 

 

 

반면, EventBridge는 이벤트 버스로 다양한 이벤트들(EC2의 이벤트까지)을 한 곳으로 수집하고 Rule과 필터링 설정을 통해 특정 이벤트에 따라 조치를 취할 수 있기 때문에 통합적으로 관리할 수 있다.

(SNS는 메시지의 내용에 따른 필터링이 안되기 때문에 Lambda를 통해 코드적으로 필터링을 진행했어야 했다.) 

 

또한 다양한 3rd-party의 이벤트 소스와 연결도 가능하다.

 

 

 

 

 

 

 

 

성능 및 결론

살펴본 것과 같이 전체적으로 Serverless, SaaS 형태의 서비스간의 연결은 EventBridge가 적절해 보인다.

반면 EventBridge는 Rule당 대상은 최대 5개 까지만 설정된다. (Fan-Out이 5개...)

지연시간도 1s 이하로 비교적 느리다.

 

 

SNS의 경우 주제당 무려 12,500,000개의 구독자를 설정할 수 있다. (Fan-Out이 12,500,000개...)
지연시간 또한 100ms 미만으로 EventBridge에 비해 빠르다.

FIFO와 같은 메시지 순서 정렬 기능 등을 활용(SNS가 대상인 경우에)할 수 있어 쿠버네티스와 같은 인프라에서 대규모의 메시지와 이벤트 처리가 필요한 경우 적절할 것이다.

 

 

 

 

 

 

 

 

참조

https://blog.naver.com/sqlpro/223187832290

[번역] SNS 대신 EventBridge를 사용해야 하는 5가지 이유

 

https://www.megazone.com/techblog_20200309_reducing-custom-code-by-using-advanced-rules-in-amazon-eventbridge/

[실습예제] Amazon EventBridge의 고급 규칙을 사용하여 사용자 지정 코드 줄이기