메시지큐의 용도 & AWS SQS 와 SNS 의 차이점.

먼저, 메시지큐는 어떨때 사용하게 될까? 

A 서버에서 B 서버를 바로 호출하는 경우, B 서버의 상태에 따라 A 서버가 의존적이게 된다. 

즉, B 서버를 재배포하려고 하면, A 서버를 관리하는 담당자에게도 알려주어야 하는데, 이런 형태는 요즘처럼 PO 중심 개발조직에서는 말이 안되는 업무 프로세스가 된다.

 이때, B 서버 앞에 메시지큐를 두어, A 서버에서는 메시지큐에 큐잉을 하고, B 서버에서는 메시지큐로부터 가져다가 처리하게 되면, B 서버의 다운타임동안에 A 서버의 동작에 문제가 없다.

 

 그렇다면 어떤 서비스를 메시지 큐로 이용하는게 좋을까? 

 sqs, sns, kafka, kinesis 등의 대안이 있는데, kafka/kinesis 는 스트리밍을 지원하기 위해 구조가 복잡해지고, 인스턴스를 미리 확보해야 해서 비용도 올라간다. 그래서 이번에는 sqs 와 sns 만을 비교해보았다. sqs 와 sns 는 lambda 처럼, 사용량에 비례해서 돈을 내고, 사용량이 높아지면 자동으로 scale out 을 해 주기 때문에 유지관리가 편리하다.

 

SQS 는 simple queue service 라는 이름이 내포하듯, queue 이다. 즉, consume 하면 해당 데이터는 사라진다.

따라서 point to point 라고도 한다. 

 

SNS 는 simple notification service 이다. notification 이 내포하는 의미는, SNS 는 push 방식으로 메시지를 전달한다는 것이다. 받는 곳이 restful api 서버일수도, mobile device 일수도, slack webhook 일수도 있다. 그리고 여러개가 될 수도 있다.  retry 설정 횟수만큼 데이터는 사라지지 않고 남아있으면서 retry 를 시도한다.

 

이를 응용해서, 메시지를 여러곳에 배포하기 위해 SNS 와 SQS 를 엮기도 한다.

A에서 B, C, D 서버로 메시지를 보낸다고 가정하면, SNS 하나, SQS 3개를 세팅한다. A 에서 SNS 로 보내면, SNS 는 SQS 3 곳으로 메시지를 보내고, SQS 는 각자 메시지를 큐잉하고 있다가, B, C, D 서버가 이를 consume 하게 되는 형태다.

 

sizing 을 하지 않아도 되고, 조합해서 다양한 메시지 흐름을 만들 수 있다는 점은 큰 매력이다.