AWS 메시징 서비스 훑어보기

이번 포스팅에서는 AWS에 어떠한 이벤트(event) 기반 메시징(messaging) 서비스가 있는지 간단하게 살펴보도록 하겠습니다.

SQS

Amazon Simple Queue Service, 줄여서 SQS는 메시지 대기열(queue) 서비스인데요. EC2, S3와 함께 AWS에서 가장 역사가 깊은 서비스 중에 하나이며 그만큼 Amazon 내부에서도 오래전 부터 사용했었고 여러 해 동안 테스트가 되어서 아주 안정화된 서비스입니다.

SQS는 일반적으로 두 개의 애플리케이션 사이에서 송수신되고 있는 메시지를 중간에서 담아 놓는 일종의 큐(queue) 역할을 수행하는데요. 보통 메시지를 SQS로 보내는 서비스를 Producer라고 하고, SQS로 부터 메시지를 받아오는 서비스를 Consumer라고 하지요. 큐 자료구조처럼 FIFO(First In First Out) 방식으로 메시지 순서를 유지하면서 메시지 유실을 방지해주고 메시지 중복도 제거해주며 대규모로 메시지를 처리할 수 있습니다.

AWS의 방대한 인프라 위에서 운용되는 완전관리형 서비스인 SQS는 이론상 무한대의 메시지를 보관할 수 있으며, 기본적으로 4일동안 보관이 되고, 보관 기간을 최대 2주까지 늘릴 수 있습니다.

특히 SQS는 마이크로서비스(microservices) 아키텍처 상에서 분산 시스템이나 서버리스 애플리케이션을 구축할 때 매우 유용한 서비스인데요. 애플리케이션 간에 느슨하게 결합을 가능하게 하여 각자 독립적으로 확장할 수 있게 해주기 때문입니다.

SNS

Amazon Simple Notification Service, 줄여서 SNS는 게시/구독(pub/sub) 메시징 서비스입니다.

SNS는 어떤 게시자가 여러 구독자에게 문자, 이메일, 모바일 푸시(push)와 같은 알람을 보내고 싶을 때 많이 사용됩는데요. 여기서 게시자는 보통 AWS의 리소스나 AWS에서 돌아가는 어떤 애플리케이션이 되며 구독자는 사람뿐만 아니라 다른 애플리케이션일 수도 있습니다.

SNS에서는 토픽(topic)을 통해서 메시지를 게시하고 구독하게 되는데요. 게시자가 특정 SNS 토픽(topic)에 메시지를 보내면, 그 SNS 토픽을 구독하고 있는 모든 주체들은 이 메시지를 받게 됩니다.

SNS는 AWS의 클라우드 인프라에서 돌아가는 완전관리형 서비스이므로 하나의 SNS 토픽에는 거의 무한대에 가까운 구독자를 설정할 수 있습니다.

Kinesis

Amazon Kinesis는 실시간 스트리밍(streaming) 데이터 처리에 최적화된 서비스인데요. 대규모의 데이터를 매우 짧은 지연시간으로 수집하고, 처리, 분석할 수 있어서 특히 비디오 스트리밍 애플리케이션에서 매우 효과적으로 활용될 수 있습니다.

Amazon MQ

기본에 온프레미스(on-premises) 환경에서 Rabbit MQ나 Active MQ와 같은 오픈 소스 메시지 브로커 제품을 사용하고 있다면 위에서 다룬 AWS의 관리형 메시징 서비스를 사용하기 어려울 수도 있는데요. 이럴 때는 Amazon MQ를 사용해서 안전하게 클라우드 환경으로 애플리케이션을 마이그레이션 할 수 있습니다.

Amazon MQ를 사용하면 간편하게 AWS에서 메시지 브로커를 프로비저닝하고 메시지 브로커에 대한 유지 보수와 보안 관리를 AWS에게 위임할 수 있습니다. 뿐만 아니라 AWS의 클라우드 인프라에서 돌아가는 완저관리형 서비스이므로 고가용성과 메시지 내구성은 덤이겠죠?

마치면서

지금까지 AWS에서 제공하고 있는 다양한 메시징 서비스에 대해서 수박 겉핥기 수준으로 살펴보았습니다.

어느 정도 애플리케이션의 규모가 커지게 되면 자연스럽게 여러 개의 마이크로서비스(microservices) 아키텍처를 고려하고 되죠? 마이크로서비스 간에 실시간으로 요청(request)과 응답(response)을 주고 받게하면 하나의 마이크로서비스에서 갑자스런 과부하가 발생했을 때 전체 애플리케이션에 장애를 유발할 수 있는데요.

본 포스팅에서 소개해드린 AWS의 메시징 서비스를 잘 활용하셔서 이러한 위험을 줄이고 좀 더 확장이 용이한 애플리케이션을 만드실 수 있으셨으면 좋겠습니다.