MSA 환경에서 SNS + SQS, Apache Kafka를 활용하여 시스템 결합도 낮추기

규모가 어느 정도 있는 웹 서비스들은 대부분 MSA(Micro Services Architecture) 환경으로 운영되고 있습니다. 거대한 서비스를 독립적인 단위로 배포하여 확장성을 높이고, 장애 피해를 최소화하는 데 아주 효과적입니다. 하지만 서비스를 독립적으로 분리한다고 해서 좋은 점만 있는 것은 아니며, 오히려 서비스 간 통신 복잡성이 생기게 됩니다. MSA 환경에서는 TCP 기반 동기 통신으로 서비스들과 데이터를 주고받는데, 여기서 문제가 생깁니다. 예를 들어, 한 서비스가 다른 서비스에게 요청을 보내고 응답이 오지 않는 상황을 가정해 봅시다. 요청을 보냈던 서비스는 RTO 타임아웃과 재전송을 반복하게 되는데, 굉장히 오랜 대기시간을 소요하게 되고, 결국에는 요청을 보냈던 서비스까지 장애 상태가 되어버립니다. 이러한 상황을 방지하기 위해 동기 통신의 위험성을 해결하는 비동기 이벤트 아키텍처를 추가해야 합니다. 이 때 사용하는 것이 바로 Amazon SNS(Simple Notification Service)와 Amazon SQS(Simple Queue Service)입니다. 두 서비스에 대해 자세히 알아보겠습니다.

 

---

목차

1. Amazon SNS(Simple Notification Service)란?
2. Amazon SQS(Simple Queue Service)란?
3. 상황별 사용 예시 (Apache Kafka 비교)
4. 결론

 

---

 

#1 Amazon SNS(Simple Notification Service)란?

<그림 1>. Amazon SNS 작동 방식

Amazon SNS는 게시자(Publisher)에게 메시지를 받아 이를 다른 애플리케이션 구독자(Application-to-Application)나 사용자(Application-to-Person)에게 알림을 보내는 데 사용됩니다. 예를 들어, Amazon CloudWatch에서 로그가 발생하고 상태 변화를 감지하면 CloudWatch Alarm이 SNS 토픽으로 전송하고, 이를 사용자의 이메일, 푸시 알림 등으로 전달이 가능합니다. EventBridge로 특정 이벤트 감지 알림도 가능하고, AWS Lambda에게 전송하여 간단한 요청을 보낼 수도 있습니다. 그러나 SNS의 진짜 장점은 다음과 같습니다.

• 게시자(Publisher)는 SNS Topic에 메시지를 보내기만 하면 되기 때문에 복잡성 및 결합도가 감소
• SNS는 여러 서비스에 병렬로 메시지를 복사하여 팬아웃(Fan-out) 전송이 가능

SNS는 게시자 쪽에서 받을 서비스에 따라 코드를 수정할 필요가 없으며, 여러 번의 메시지를 전송할 필요도 없다는 것이 장점입니다.

 

1-1. 외부에서 들어오는 Inbound 메시지는 어떻게 처리할까?

SNS나 SQS는 모두 회사 내의 VPC 안에 생성되는 것이 아닌 AWS가 관리하는 별도의 네트워크 영역에서 동작하는 서버리스(Serverless) 서비스이기 때문에, 복잡한 네트워크 구성 없이도 외부 시스템과 안전하게 데이터를 주고받을 수 있습니다. 외부에서 들어오는 요청은 AWS가 관리하는 영역에서 모두 처리(TLS 인증, 로드밸런싱)되고, 정제된 데이터만 우리에게 보내줍니다. 이는 내 서버의 IP를 외부에 노출할 필요가 없어 보안상 안전하기도 하다는 장점이 있습니다.

 

1-2. 외부로 내보내는 Outbound 메시지는 어떻게 처리할까?

마찬가지로 내 프라이빗 서브넷에 있는 EC2, 백엔드에서 타사 서버나 고객 이메일로 메시지를 보낼 때, SNS 토픽에게 메시지를 게시(Publish)하면 됩니다. Interface VPC Endpoint를 통해 전송이 되므로 보안상 안전하며, 따라서 NAT 게이트웨이를 열어줄 필요도 없다는 것이 장점입니다. SNS는 HTTP의 Reverse API인 웹훅(Web Hook) 방식으로 HTTP POST 요청을 보내게 되고, 이 요청은 타사나 외부의 URL로 바로 전송하게 해 줍니다. 이외에도, Email이나 SMS 같은 다양한 프로토콜로 데이터를 전송할 수 있습니다.

 

1-3. SNS 사용 시 주의할 점

• SNS 사용 비용은 거의 무료이지만, SMS나 Email 같은 프로토콜을 쓰거나 인터넷망(VPC Endpoint)을 쓰는 웹훅(Web Hook) 프로토콜을 쓰는 경우에는 비용이 꽤 들 수 있습니다.
• 표준 SNS는 병렬 처리 기반이기 때문에 요청이 도착하는 순서를 보장하지 않습니다. 순서가 중요한 프로세스를 사용한다면 타임스탬프를 활용하여 리시버 쪽에서 조합을 하거나, 비용이 부과되는 FIFO 방식의 SNS를 사용해야 합니다.(FIFO는 비용 증가 및 처리량 저하)
• 중복 전송이 되는 경우가 많습니다. 따라서 리시버 쪽에서 중복된 메시지인지 확인하는 로직이 필요합니다.
• 리시버가 오랫동안 Dead 상태인 경우에는 SNS가 재전송을 시도하다가 메시지를 폐기합니다. 중요한 메시지인 경우에는 치명적이므로, DLQ(Dead Letter Queue) 같은 버퍼로 임시 저장해야 합니다.

 

---

 

#2 Amazon SQS(Simple Queue Service)란?

<그림 2>. Amazon SQS 작동 방식

Amazon SQS는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 메시지 대기열(Message Queue) 서비스입니다. 쉽게 말해, Producer가 보낸 메시지를 Consumer가 꺼내갈 때까지 보관해주는 버퍼 역할을 합니다. SQS의 장점은 다음과 같습니다.

• Producer는 Consumer의 상태 고려 없이 메시지를 전송하기만 하면 되기 때문에 추가 로직이 불필요
• 비동기 처리가 가능함
• Producer가 폭주하여 많은 트래픽을 보내도 Consumer는 일정한 속도로 버퍼에서 메세지를 꺼내어 가기 때문에 받는 서버의 과부하를 방지(Flow Control)
• SQS가 보낸 메시지에 Consumer로 부터 응답(Acknowledge)을 받지 못하면, Visible Time-out이 됨에 따라 재전송 준비(Error Control)

 

2-1. 외부에서 들어오는 Inbound 메시지는 어떻게 처리할까?

SNS와 마찬가지로 SQS도 내 VPC가 아닌 AWS가 관리하는 별도의 네트워크 영역에서 동작하는 서버리스(Serverless) 서비스이기 때문에, 복잡한 네트워크 구성 없이도 AWS의 SQS Endpoint로 메시지를 보내기만 하면 됩니다. 내 서버의 IP를 외부에 노출할 필요가 없어 보안상 안전하기도 하다는 장점이 있습니다.

 

2-2. 외부로 내보내는 Outbound 메시지는 어떻게 처리할까?

SQS는 SNS처럼 전송 기능이 있는 것이 아니라, 내부 서비스가 꺼내가는 방식입니다. 프라이빗 서브넷에 있는 EC2나 Lambda는 Interface VPC Endpoint를 통해 SQS에 접근하여 메시지를 폴링(Polling)하여 가져옵니다. 따라서 외부로 내보내려면 SQS에 AWS Lambda나 EC2가 접근하여 메시지를 꺼내고 외부 서버로 전송하는 과정을 거쳐야 합니다. Cousumer는 Flow Control을 사용하여 자신이 처리할 수 있는 속도로만 메시지를 가져오므로, 시스템의 안정성을 극대화할 수 있습니다.

 

2-3. SQS 사용 시 주의할 점

• SQS는 큐에 메시지가 있는지 확인하는 API 요청 횟수마다 비용이 발생합니다. 메시지가 없는데도 계속된 요청을 방지하기 위해, 롱 폴링(Long Polling)을 사용해서 큐가 응답하기 전 까지는 더 오랜 주기로 요청을 하도록 해야 합니다.
• 표준 SQS는 큐에 여러 Consumer가 접근할 수 있으므로 메시지가 도착하는 순서를 보장하지 않습니다. 순서가 중요한 프로세스를 사용한다면 타임스탬프를 활용하여 리시버 쪽에서 조합을 하거나, 비용이 부과되는 FIFO 방식의 SQS를 사용해야 합니다.(FIFO는 비용 증가 및 처리량 저하)
• 중복 전송이 되는 경우가 많습니다. 따라서 리시버 쪽에서 중복된 메시지인지 확인하는 로직이 필요합니다.

 

---

 

#3 상황별 사용 예시

실제 스타트업/중소규모 웹 서비스 환경을 가정하고 비용에 따라 어떤 상황에 어떤 서비스가 어울리는지 분석해보려고 합니다. 먼저 매달 보내지는 메시지는 1,000만 건, 메시지 크기는 대체로 64KB 이하, Region은 AWS 서울 리전(ap-northeast-2), Consumer(SNS는 구독자)가 3개라고 가정해 보겠습니다. SNS와 SQS는 모두 표준 방식입니다.

3-1. SNS만 사용하는 경우

SQS가 존재하지 않기 때문에 메시지를 담을 버퍼가 없습니다. SNS는 병렬적으로 메세지를 퍼블리싱하는 역할 밖에 없기 때문에, 즉각적으로 메세지를 알리는 용도인 푸시 알림, 이메일 발송 등과 같은 곳에만 주로 쓰입니다. 또한, 버퍼가 없기 때문에 구독자(Subscriber) 서비스가 죽어있는 상태라면 Loss가 발생하게 되므로, 리스크가 커 MSA 환경에서는 단독으로 사용되지 않습니다. 비용은 $18(1000만 * 3개 Subscriber * $0.6)에 $5(1000만 게시 비용)으로 총 $23으로 알려져 있습니다.

 

3-2. SQS만 사용하는 경우

SNS가 존재하지 않기 때문에 병렬적으로 메세지를 보낼 수가 없습니다. 1:1 구조로 다른 서비스에게 메시지를 보내야 하기 때문에, 서비스마다 있는 SQS에게 여러번 메세지를 보내줘야 하므로, 효율성과 확장성이 크게 떨어져 MSA 환경에서 단독으로 사용되지 않습니다. 대신, 시간이 오래 걸리는 요청을 SQS에 보내고, 메세지를 다른 처리 서버에 보내서 비동기 처리를 할 때에는 자주 사용됩니다. 비용은 $12(1000만 * 3개 Consumer * $0.4)로 알려져 있습니다.

 

3-3. SNS와 SQS를 동시에 사용하는 경우

<그림 3>. SNS + SQS 하이브리드 작동 방식

SNS의 브로드캐스팅(Fan-out) 병렬 전송 기능과 SQS의 메세지 버퍼링 기능을 결합하면, MSA 환경을 효율적으로 구성할 수 있게 됩니다. 각각을 독립적으로 사용했을 때의 단점을 서로가 보완해 줍니다. SNS와 SQS를 동시에 사용한 경우의 비용은 총 합 $35이지만, 실제 기업은 Consumer가 큐에 요청을 즉시 보내고, 큐에 메시지가 응답이 있을 때만 응답을 꺼내가는 롱 폴링(Long Polling) 방식을 사용하면서 배치(Batch) 처리도 하기 때문에, 실제 비용은 더 줄어드는 경우가 대다수입니다.

 

3-4. Apache Kafka를 사용하는 경우

<그림 4>. Apache Kafka 구조

SNS와 SQS를 합친 하이브리드 방식은 HTTP 기반의 통신이라 메시지 전송량에 따라 네트워크 오버헤드 및 요금이 선형적으로 증가합니다. 따라서 많은 트래픽을 주고받는 대규모 MSA 환경에서는 비용적인 측면에서 너무 많은 요금이 부과될 수 있습니다. 특히 순서 보장을 위해 FIFO 큐를 사용할 경우, 낮은 처리량 한계와 높은 추가 비용 문제에 직면하게 됩니다. Apache Kafka란 대규모 데이터 저장 및 전송이 가능한 이벤트 스트리밍 플랫폼으로, SNS와 SQS의 기능을 가지고 있으면서도 이전 데이터 재활용, 실시간 데이터 분석, 순서 보장, 배치 단위의 TCP 기반 통신으로 오버헤드를 최소화할 수 있는 서비스입니다. SNS와 SQS 방식과는 다르게 고정 비용이며, 여러 기능을 추가적으로 제공하기 때문에 대부분의 대규모 웹 서비스들은 인력을 투자하여 대규모 데이터 정제 및 전송 방식을 사용합니다. On-Premise를 사용하는 기업들은 Kafka를 목적에 따라 클라우드에만, 또는 On-Premise 인프라에만, 심지어 두 군데에 다 설치하기도 합니다. Kafka는 구축과 운영 난이도가 높기 때문에, 기업의 규모와 목적에 따라 신중하게 도입해야 합니다.

 

---

 

결론

MSA 환경의 핵심인 복잡하지 않은 결합도와 시스템 안정성을 확보하기 위해 비동기 아키텍처는 선택이 아닌 필수입니다. 무조건 최신 기술을 쫓기보다, 초기에는 운영 부담이 적고 비용 효율적인 SNS+SQS 조합으로 시작하여 안정적인 기반을 다지는 것이 현명합니다. 이후 트래픽이 폭증하거나 데이터의 재처리가 비즈니스의 핵심이 되는 시점에 Kafka로 전환하는 것이 현명하다고 생각이 드네요. 결국 최고의 아키텍처는 현재 우리 서비스의 규모와 상황에 가장 적합한 도구를 선택하는 것입니다.