디커플링 SQS, SNS, EventBridge 완벽 비교
아키텍처를 "견고하고 확장 가능하게" 만드는 방법을 묻는 질문에서 정답의 핵심 키워드는 바로 "디커플링(Decoupling, 분리)"입니다.
애플리케이션의 각 구성요소가 서로 꽉 맞물려 있다면, 한 부분이 느려지거나 장애가 날 때 시스템 전체가 멈춰버립니다.
이 문제를 해결하기 위해 AWS는 메시지 기반의 디커플링 서비스를 제공합니다: SQS, SNS, EventBridge.
1. SQS (Simple Queue Service): "작업 대기열"
SQS는 가장 기본이 되는 메시지 큐 서비스입니다.
-
핵심 비유: "주문이 밀려드는 식당의 주문서 대기열"
- 손님(Producer)이 주문을 하면, 점원(Consumer)이 바로 처리하는 게 아니라 주문서(Message)를 대기열(Queue)에 꽂아둡니다.
- 주방(Consumer)은 자신의 처리 속도에 맞춰 대기열에서 주문서를 하나씩 가져가서(Pull) 처리합니다.
- 손님은 주문서만 전달하면 바로 다른 일을 할 수 있고, 주방이 바빠도 주문이 유실되지 않습니다.
-
핵심 개념:
- 1:1 패턴: 하나의 메시지는 오직 하나의 Consumer에 의해 처리됩니다. (여러 Consumer가 있어도 메시지 하나를 두고 경쟁하며, 한 명이 가져가면 다른 Consumer는 못 가져감)
- Pull(폴링) 기반: Consumer가 직접 큐에 가서 "처리할 메시지 있나요?"라고 물어보고(Pull) 가져옵니다.
- 디커플링: 메시지를 보내는 Producer와 처리하는 Consumer가 서로의 존재나 상태를 알 필요가 없습니다. Consumer가 다운되어도 메시지는 큐에 안전하게 보관됩니다.
-
SAA 문제 (Standard vs. FIFO)
- Standard (표준) 큐 (기본):
- "최소 한 번 이상" 전달 (드물게 중복 가능)
- 순서를 최대한 보장
- 성능: 거의 무제한의 처리량
- FIFO (First-In-First-Out) 큐:
- "정확히 한 번만" 전달 (중복 없음)
- 순서를 무조건 보장
- 성능: 초당 트랜잭션 수에 제한이 있음
- (참고: FIFO 큐 이름은 반드시
.fifo로 끝나야 합니다.)
- Standard (표준) 큐 (기본):
SAA 키워드:
- "애플리케이션의 작업을 분리하여..."
- "Consumer의 처리 속도와 관계없이 요청을 안전하게 저장..."
- "데이터베이스 쓰기 작업을 비동기적으로 처리..."
- "순서가 중요하고 중복 처리가 안되는 금융 거래..." (→ FIFO)
2. SNS (Simple Notification Service): "확성기"
SNS는 게시/구독(Pub/Sub) 모델을 따르는 알림 서비스입니다.
-
핵심 비유: "라디오 방송국" 또는 "그룹 확성기"
- 방송국(Publisher)이 "토픽(Topic)"이라는 채널에 "9시 뉴스"라는 메시지를 한 번 보냅니다.
- 이 채널을 구독(Subscribe)하고 있는 모든 청취자(Subscriber)가 동시에 "9시 뉴스"를 수신합니다.
-
핵심 개념:
- 1:N (Fan-Out) 패턴: 하나의 메시지를 다수의 구독자에게 동시에 "Push"합니다.
- 다양한 구독자: SNS의 구독자는 매우 다양합니다.
- SQS: (가장 중요) SNS로 받은 알림을 SQS 큐에 넣어 안정적으로 처리
- Lambda: 알림을 받아 즉시 코드 실행
- Email / SMS: 사용자에게 문자나 이메일 발송
- HTTP/S: 특정 웹 서버(API)로 알림 전송
-
SAA 단골 아키텍처 (SNS + SQS = 안정적인 팬아웃)
- SNS가 여러 SQS 큐에 메시지를 동시에 팬아웃(전송)합니다.
- 각 SQS 큐에 연결된 Consumer(예: 재고 관리, 배송 처리, 로그 분석)들은 동일한 이벤트를 받아 각자의 속도대로 안정적으로 처리할 수 있습니다.
SAA 키워드:
- "하나의 이벤트를 여러 하위 시스템으로 동시에 전송..." (→ Fan-Out)
- "사용자에게 이메일 또는 SMS 알림을 보내야 함..."
- "여러 마이크로서비스가 동일한 이벤트에 대해 반응해야 함..."
- "SQS와 결합하여 안정적인 팬아웃 패턴을 구현..."
3. EventBridge: "스마트 이벤트 라우터"
EventBridge는 SAA 아키텍처의 꽃, 이벤트 기반 아키텍처(EDA)의 핵심입니다. (이전에는 CloudWatch Events라고 불렸습니다.)
-
핵심 비유: "똑똑한 중앙 이벤트 관제 센터"
- SQS/SNS가 "메시지"라는 내용물을 전달하는 데 집중한다면, EventBridge는 "이벤트"라는 사건 자체를 관리합니다.
- AWS 서비스(예: EC2), SaaS(예: Zendesk), 또는 내 앱에서 발생한 모든 이벤트가 "이벤트 버스(Event Bus)"라는 중앙 통로로 모입니다.
- EventBridge는 이 이벤트의 "내용을 검사(Filtering)"하여, 정해진 "규칙(Rule)"에 맞는 이벤트만 골라서 "대상(Target)"으로 라우팅합니다.
-
핵심 개념:
- N:M 라우팅: 수많은 이벤트 소스가 수많은 대상으로 연결됩니다.
- 콘텐츠 기반 필터링 (Rule): SAA가 SNS와 EventBridge를 구분하는 핵심입니다
- SNS (Dumb): 구독자는 모든 메시지를 다 받습니다.
- EventBridge (Smart): 이벤트의 내용(JSON)을 보고 필터링합니다.
- (예:
{"source": "order.service", "detail": {"status": "shipped", "region": "ap-northeast-2"}}이벤트가 발생하면,{"region": "ap-northeast-2"}규칙을 가진 타겟만 이벤트를 받음)
- AWS 서비스 통합: EC2 인스턴스 상태 변경, S3 객체 생성 등 90가지가 넘는 AWS 서비스 이벤트를 기본 소스로 사용합니다.
SAA 키워드:
- "이벤트 기반 아키텍처(EDA)를 구성..."
- "다양한 AWS 서비스에서 발생하는 이벤트에 대응..."
- "이벤트의 내용(콘텐츠)을 기반으로 필터링하여..."
- "SaaS 애플리케이션(예: Zendesk, Datadog)과 통합..."
- "여러 부서가 자신이 관심 있는 이벤트만 구독..."
정리
| 구분 | SQS (Simple Queue Service) | SNS (Simple Notification Service) | EventBridge |
|---|---|---|---|
| 핵심 비유 | 작업 대기열 (Queue) | 확성기 (Megaphone) | 스마트 라우터 (Router) |
| 패턴 | 1:1 (Producer -> Consumer) | 1:N (Publisher -> Subscribers) | N:M (Sources -> Targets) |
| 전달 방식 | Pull (Consumer가 가져감) | Push (구독자에게 밀어줌) | Push (규칙에 맞는 타겟으로) |
| 필터링 | 없음 (모든 메시지 순차 처리) | 없음 (토픽 구독자 전체) | 콘텐츠 기반 필터링 (Rule) |
| SAA 핵심 | 디커플링, 내구성, FIFO | 팬아웃(Fan-Out), 알림 | 이벤트 기반 아키텍처(EDA) |
