2025년 3월 23일 일요일

AWS 레소스 중 SNS와 SQS에 대해

AWS (아마존 웹 서비스)에는 정말 많은 레소스가 제공되는데 그 중 현업에서 흔하게 쓰고 있는 것이 있는데 이게 SNS와 SQS다.  

처음에 이걸 쓸때, 도대체 뭔 차이인지 잘 몰라서 헷갈렸었다. 이름도 비슷하다.

SNS는 Simple Notification Service의 약자, SQS는 Simple Queue Service의 약자.

이미지를 찾아봤는데, 아래의 이미지는 https://www.geeksforgeeks.org/amazon-sns-vs-sqs/ 에서 카피한 이미지. 



SNS 는 이름에 notification이 들어가 있고, 이를 통해 유추할 수 있듯이, 어떤 서비스를 실행하다가 통지 (notification)을 보내고 싶을때 SNS를 쓰는거다. 테크니컬리 설명한다면, AWS 콘솔 들어가서 SNS를 생성하던지 아니면 CDK 같은 코드로 SNS를 생성한다.  AWS에 어떤 레소스를 생성하면 ARN이라는 유일한 ID 가 부여되는데 이 ARN (그 SNS의 이름 같은거다)를 가지고 이 SNS에 통보를 보낼 수 있는 것이다.  물론, 이렇게 통보를 보내려면 permission을 가져야 한다.  하여간 통보를 보내면, 이 통보 (notification)을 처리하는 방법은 원하는대로 다양하게 구현할 수가 있는 것이다.

위의 이미지에서 보면, 어떤 경우는 Lamba 함수로 그걸 처리하게 할 수도 있고, SQS로 보낼 수도 있고, 이메일을 보낼 수도 있다. 구현하기 나름이다.

이때 SQS를 활용하는 경우가 많은데, 그래서 SNS와 SQS는 거의 함께 친구처럼 쓰이게 된다.

그럼 SQS는 뭔가? 이건 말 그대로 Queue다.  SQS를 생성하겠다고 버튼을 누르면 이렇게 큐의 종류를 선택할 수 있다. Standard Queue와 FIFO 중 선택이 가능하다.  FIFO는 First-In First-Out이라고 먼저오면 먼저 나가는 거다. Standard Queue는 그 순서를 보장하지 않는다. 먼저왔어도 나중 나가기도 한다는 거다.



내가 처음 SNS와 SQS를 가지고 일을 할때, 헷갈렸던 부분은, SNS에 notification을 보내고, 이걸 그냥 람다로 처리해도 되고, SNS에 SQS를 연결하고 (이걸 subscribe 구독이라고 한다) SQS에 람다를 연결해 메시지를 처리해도 된다.  둘다 마찬가지 결과다. 근데 왜 굳이 SNS에 SQS를 연결하고 람다를 연결하는 구찮은 구조를 가질까?

나름 생각해보건데, my service -> send notification -> SNS -> SQS -> lambda.

이렇게 가져갈 경우, SQS에 메시지를 보낸후, 람다에서 이 메시지를 consume (읽어서) 하여 처리하게 되는데, 이때 만일 뭔가 잘못될 경우, 즉 람다에서 메시지 처리중 exception이 발생한다. 이때 이 메시지는 몇번 다시 consume 되어 람다에 의해 재처리가 되다가, 결국 retrial 갯수가 max에 다다를 경우, 그 메시지는 SQS에 연결된 DLQ (Dead Letter Queue)로 보내지게 된다.  물론, 이때 DLQ를 생성하여 SQS에 연결한 경우에 이렇게 된다.  그러니 꼭 DLQ를 만들어 두도록 해야 함.

DLQ에 메시지가 들어가면, 나중에 알람을 통해, 뭔가 잘못된 메시지가 있음을 알게 되고 뭐가 잘못됬는지 디버깅을 하는 것이다. 만일 SNS와 람다 사이에 SQS가 없다면, 메시지 처리 중 exception 받은 메시지가 어찌될지는 잘 모르겠다.


또 다른 usecase로는, 우리 팀의 서비스가 뭔가 일을 처리했다. 어떤 조건이 만족할때, 예를 들어, 어떤 요청을 처리 시, complete 상태로 바뀔때마다 이것에 관심있는 다른 팀에 이를 알려주고 싶을때, SNS를 생성하여 여기에 notification을 발송한다.


이 정보에 관심 있는 다른 팀이 있다면, 그 팀은 자기네 소유로 SQS를 만든 후, 우리에게 subscription 요청을 한다.  그러면 우리팀의 SNS와 자기네 팀의 SQS를 연결한 후, SQS에 이 관심있는 메시지를 수신하여 자기네 마음에 맞게 처리하는 것이다.

이것은 de-coupling의 좋은 예다.  우리는 그저, requestID와 requestStatus를 담아 해당 SNS로 notification을 발송한다.


연결된 SQS를 통해 메시지를 받은 다른 팀의 서비스가 이를 수신후 자기네들이 원하는대로 이정보를 사용하는 것이다. 




댓글 없음:

댓글 쓰기

AWS 레소스 중 SNS와 SQS에 대해

AWS (아마존 웹 서비스)에는 정말 많은 레소스가 제공되는데 그 중 현업에서 흔하게 쓰고 있는 것이 있는데 이게 SNS와 SQS다.   처음에 이걸 쓸때, 도대체 뭔 차이인지 잘 몰라서 헷갈렸었다. 이름도 비슷하다. SNS는 Simple Notifi...