AWS 이벤트 기반 아키텍처 완벽 가이드: SQS, SNS, EventBridge 제대로 파헤치기

오늘날의 클라우드 애플리케이션은 거대하고 복잡합니다. 이 복잡성을 관리하고 시스템을 더욱 유연하고 안정적으로 만들기 위해 이벤트 기반 아키텍처(Event-Driven Architecture)가 핵심적인 설계 방식으로 떠오르고 있습니다. AWS(Amazon Web Services)는 이러한 아키텍처를 구축하기 위한 강력한 도구들을 제공하는데, 그 중심에는 SQS, SNS, EventBridge가 있습니다.

이 세 가지 서비스는 모두 이벤트를 처리하는 역할을 하지만, 각각의 목적과 통신 방식에는 미묘한 차이가 있습니다. 이 글에서는 이벤트 기반 아키텍처의 기본 개념부터 SQS, SNS, EventBridge의 역할과 차이점, 그리고 실전에서 어떻게 이들을 조합하여 사용하는지 상세히 알아보겠습니다.

---

1. 이벤트 기반 아키텍처란 무엇인가요? - 마이크로서비스의 핵심 🧩

이벤트 기반 아키텍처는 시스템 구성 요소들이 서로 직접 호출하는 대신, '이벤트'라는 메시지를 주고받으며 비동기적으로 통신하는 방식입니다.

• 결합도 분리(Decoupling): 전통적인 방식에서는 서비스 A가 서비스 B를 직접 호출해야 했습니다. 이는 서비스 A와 B가 서로에 대해 알고 있어야 한다는 것을 의미하며, 만약 B가 다운되면 A도 영향을 받게 됩니다. 이벤트 기반 아키텍처에서는 A가 단순히 '이벤트'를 발행하고, B는 그 이벤트를 구독하여 처리합니다. 이로써 두 서비스는 서로의 존재를 알 필요 없이 독립적으로 작동할 수 있게 됩니다.
• 비동기 통신(Asynchronous Communication): 이벤트를 발행한 서비스는 이벤트가 처리될 때까지 기다리지 않습니다. 이는 시스템의 전반적인 성능을 향상시키고, 지연 시간을 줄여줍니다.
• 확장성과 탄력성: 이벤트 발행자는 이벤트 소비자의 수에 관계없이 작동합니다. 필요에 따라 이벤트 소비자를 늘리거나 줄일 수 있어, 시스템의 확장성과 탄력성이 높아집니다.

---

2. SQS (Simple Queue Service): 메시지를 담는 우편함 📬

SQS는 AWS의 완전 관리형 메시지 큐(Message Queue) 서비스입니다. 큐는 메시지를 저장하는 임시 공간이며, 메시지 발행자와 소비자 사이의 결합도를 낮추는 역할을 합니다.

• 비유: SQS는 마치 편지를 보관하는 우체통과 같습니다. 발신자가 편지(메시지)를 우체통(SQS 큐)에 넣으면, 수신자는 언제든지 우체통을 열어 편지를 꺼내갑니다. 발신자는 수신자가 편지를 언제 가져갈지 기다릴 필요가 없습니다.
• 주요 특징:
  • 메시지 안정성: 메시지가 삭제되기 전까지 여러 개의 서버에 복제되어 저장되므로 유실될 염려가 거의 없습니다.
  • 폴링(Polling) 방식: SQS 큐의 메시지는 구독자에게 자동으로 푸시되지 않습니다. 메시지 소비자는 큐에 메시지가 있는지 주기적으로 확인(폴링)하여 메시지를 가져가야 합니다.
  • 두 가지 유형:
    • Standard SQS: 최대 처리량(throughput)을 제공하며, 메시지가 순서대로 도착하지 않을 수 있고, 메시지가 중복 처리될 수 있습니다. 대부분의 경우에 적합합니다.
    • FIFO SQS: 메시지가 엄격하게 '선입선출(First-In-First-Out)' 순서로 처리되며, 정확히 한 번만 처리되도록 보장합니다.
• 주요 사용 사례:
  • 백그라운드 작업 처리: 웹 서버가 복잡한 작업을 SQS 큐에 넣고, 백그라운드 워커가 큐에서 작업을 꺼내 처리합니다.
  • 느슨한 결합: 마이크로서비스 간에 직접적인 의존성을 제거합니다.

---

3. SNS (Simple Notification Service): 알림을 보내는 방송국 📢

SNS는 메시지를 다수의 구독자에게 푸시(Push)하는 완전 관리형 게시-구독(Publish/Subscribe) 서비스입니다. SQS가 1:1 또는 1:N의 비동기 작업 큐라면, SNS는 1:N의 알림 및 배포에 특화된 서비스입니다.

• 비유: SNS는 마치 방송국과 같습니다. 방송국(SNS Topic)이 뉴스를 방송(메시지 발행)하면, 라디오나 TV를 켠 모든 청취자(구독자)에게 뉴스가 즉각적으로 전달됩니다.
• 주요 특징:
  • 주제(Topic): 메시지는 '주제(Topic)'에 게시됩니다.
  • 다양한 구독자: SNS 토픽에는 SQS 큐, Lambda 함수, 이메일 주소, HTTP/S 엔드포인트 등 다양한 유형의 구독자가 연결될 수 있습니다.
  • 푸시 방식: SQS와 달리 메시지가 발행되면 즉시 모든 구독자에게 푸시됩니다.
• 주요 사용 사례:
  • 시스템 알림: 중요한 시스템 이벤트(예: 서버 다운)가 발생했을 때, 여러 관리자에게 이메일이나 SMS로 알림을 보냅니다.
  • 팬아웃(Fan-out) 아키텍처: 하나의 이벤트로 여러 개의 분산된 시스템을 동시에 트리거해야 할 때 SNS를 사용합니다.

---

4. EventBridge: 시스템을 연결하는 똑똑한 중앙 허브 🧠

EventBridge는 AWS의 서버리스 이벤트 버스(Event Bus) 서비스입니다. AWS 서비스, 커스텀 애플리케이션, 그리고 외부 SaaS 애플리케이션의 이벤트를 통합하고, 규칙 기반으로 필터링 및 라우팅하는 데 특화되어 있습니다.

• 비유: EventBridge는 똑똑한 중앙 정보 허브와 같습니다. 모든 곳(AWS 서비스, 다른 앱)에서 쏟아져 나오는 정보를 한 곳에 모아, "이런 정보는 저기(Lambda)로, 저런 정보는 저기(SQS)로 보내줘"와 같이 정교한 규칙에 따라 분류하고 배분합니다.
• 주요 특징:
  • 규칙 기반 라우팅: EventBridge의 가장 강력한 기능입니다. 이벤트의 내용(JSON 페이로드)을 기반으로 특정 이벤트만 선택하여 특정 대상으로 보낼 수 있습니다.
  • 다양한 이벤트 소스: AWS 서비스뿐만 아니라, Shopify, Zendesk, PagerDuty 등 외부 SaaS 애플리케이션의 이벤트도 통합할 수 있습니다.
  • 스키마 레지스트리: 이벤트의 구조를 관리하고 유효성을 검사하는 기능을 제공하여 개발 프로세스를 간소화합니다.
• 주요 사용 사례:
  • SaaS 애플리케이션 연동: 외부 서비스의 이벤트(예: Zendesk에 새로운 티켓이 생성됨)를 AWS 서비스(예: SQS)로 전달하여 워크플로우를 자동화합니다.
  • 복잡한 마이크로서비스 통합: 여러 마이크로서비스 간의 이벤트 흐름을 중앙에서 관리하고 제어합니다.
  • AWS 서비스 이벤트 처리: EC2 인스턴스가 중지되거나, S3 버킷에 파일이 삭제되는 등 AWS 서비스의 변화를 감지하고 다른 작업을 트리거합니다.

---

5. SQS, SNS, EventBridge: 어떤 것을 선택해야 할까요?

구분	SQS	SNS	EventBridge
핵심 목적	메시지 큐 (비동기 작업 처리)	푸시 알림 (1:N 분산)	이벤트 라우팅 (스마트 허브)
통신 방식	폴링(Polling)	푸시(Push)	푸시(Push)
주요 기능	메시지를 안정적으로 저장하고, 소비자가 가져감	메시지를 즉시 구독자에게 배포	이벤트 내용 기반으로 필터링 및 라우팅
이상적인 사용 사례	- 웹 서버와 백엔드 워커 간 작업 큐<br>- 느린 API 요청을 비동기적으로 처리	- 시스템 알림 및 경고<br>- 하나의 이벤트로 여러 마이크로서비스 트리거	- SaaS 앱과 AWS 연동<br>- 복잡한 워크플로우 구축<br>- 중앙 집중형 이벤트 버스
가격	메시지 큐에 따른 비용	푸시 알림 및 전송량 기반	이벤트 버스 규칙 및 이벤트 수 기반

Sheets로 내보내기

---

6. 실전 아키텍처 예시: 3가지 서비스를 함께 사용하기 🛠️

이 세 가지 서비스는 서로를 대체하는 것이 아니라, 함께 사용했을 때 시너지를 발휘합니다. 예를 들어, 온라인 쇼핑몰의 주문 처리 시스템을 구축한다고 가정해 봅시다.

1. 사용자가 상품을 주문합니다.
2. 결제 서비스는 OrderCompleted라는 이벤트를 EventBridge의 이벤트 버스로 발행합니다.
3. EventBridge는 이벤트의 내용(예: product_type: digital)을 분석하여 정의된 규칙에 따라 이벤트를 두 곳으로 라우팅합니다.
   • 즉각적인 알림이 필요한 경우: 고객에게 이메일 또는 SMS를 보내는 SNS 토픽으로 이벤트를 보냅니다.
   • 장시간이 소요되는 작업: 재고를 차감하고 배송 정보를 처리하는 백엔드 서비스가 큐에서 작업을 가져가도록 SQS 큐로 이벤트를 보냅니다.
4. SNS 토픽은 즉시 배송 서비스(HTTP 엔드포인트)와 재고 관리 서비스(Lambda 함수) 등 여러 구독자에게 알림을 푸시합니다.
5. SQS 큐에 담긴 주문 정보는 다른 워커 서비스가 원하는 시간에 가져가서 안정적으로 처리합니다.

이처럼 SQS, SNS, EventBridge는 각각 메시지 저장, 분산, 라우팅이라는 고유한 역할을 수행하며, 이들을 조합하여 강력하고 유연한 이벤트 기반 아키텍처를 완성할 수 있습니다.

결론: 현대 클라우드 애플리케이션의 필수 요소

AWS의 이벤트 기반 서비스들은 현대 클라우드 애플리케이션의 설계에 있어 필수적인 구성 요소입니다. SQS는 비동기 작업 처리의 안정성을, SNS는 메시지 분산의 효율성을, EventBridge는 복잡한 이벤트 라우팅의 유연성을 제공합니다. 이들을 적재적소에 활용하여 시스템의 결합도를 낮추고, 확장성과 안정성을 극대화하는 것이 바로 클라우드 아키텍처 전문가의 역량입니다.