메세징! Kafka vs SQS

1. Kafka vs SQS 핵심 비교

항목	Kafka	SQS
메시지 보존	소비 후에도 retention 기간까지 보존	소비하면 삭제
컨슈머	여러 컨슈머 그룹이 같은 메시지를 독립 소비	하나의 컨슈머가 가져가면 끝 fanout은 SNS+SQS 조합 필요
순서 보장	파티션 단위 보장	Standard: 없음 / FIFO: 있으나 처리량 제한
처리량	초당 수십만~수백만 건	거의 무제한이나 건당 비용 발생
비용 모델	인프라 운영 비용 (브로커 수 기반)	요청 수 기반 과금 (API call 당)
운영 부담	직접 운영 또는 MSK	완전 관리형, 운영 부담 없음
재처리 (replay)	offset 되감기로 재처리 가능	불가 (DLQ로 실패건만 재처리)

2. 언제 뭘 쓸까

Kafka가 유리한 경우

• 같은 로그를 여러 곳에서 소비해야 할 때 (모니터링, 분석, 알림 등)
• 장애 시 offset 되감기로 재처리가 필요할 때
• 로그 볼륨이 커서 건당 과금이 부담될 때

SQS가 유리한 경우

• 컨슈머가 하나이고 단순히 받아서 처리만 하면 될 때
• 브로커 운영 부담을 없애고 싶을 때
• 로그 볼륨이 적어서 건당 과금이 부담 없을 때

3. 다중 컨슈머 구조 비교

Kafka는 메시지를 소비해도 삭제하지 않기 때문에 컨슈머 그룹별로 각자의 offset을 관리하면서 같은 메시지를 독립적으로 읽을 수 있다.

Kafka

[Airflow DAG 로그] → Kafka topic: "dag-logs"
                        ├─ 컨슈머 그룹 A: ELK 적재
                        ├─ 컨슈머 그룹 B: Slack 알림
                        └─ 컨슈머 그룹 C: 메트릭 집계

세 그룹 모두 동일한 메시지를 각자 소비한다. A가 읽었다고 B가 못 읽는 게 아니다.

SQS로 같은 구조를 만들려면

[로그] → SNS → SQS-A (ELK)
              → SQS-B (Slack)
              → SQS-C (메트릭)

SNS fanout + 큐 N개 구성이 필요하다. 컨슈머가 늘어날 때마다 SQS 큐를 추가하고 SNS 구독을 연결해야 한다.

4. 결론

로깅 중앙 집중화는 보통 다중 컨슈머(ELK 적재, Slack 알림, 메트릭 집계 등)가 필요하고 장애 시 재처리 가능성도 있어서 Kafka가 자연스러운 선택이다. SQS로 동일한 구조를 만들려면 SNS → 여러 SQS fanout 구성이 필요해서 오히려 복잡해진다.

다만 컨슈머가 하나뿐이고 볼륨이 적다면, 운영 부담 없는 SQS가 합리적일 수 있다.