본문
데이터 파이프라인, 뭘 써야 할까? (MSK vs Firehose vs SQS)
AWS/운영 및 관리 2026. 1. 12. 23:01
시스템 간 데이터 전송을 위해 AWS 콘솔을 열면 SQS, Firehose, MSK 사이에서 고민에 빠지게 됩니다. 이들은 겉보기엔 유사한 '메시지 큐'나 '스트리밍' 서비스 같지만, 잘못된 선택은 막대한 운영 리스크로 돌아옵니다.
이번 글에서는 각 서비스의 아키텍처적 특징을 비교하고, 어떤 기준으로 선택해야 하는지 핵심만 요약합니다.
핵심 차이점: 목적과 데이터의 수명
결국 이 세 가지는 "데이터를 어떻게 다루고 싶은가?" 라는 질문으로 귀결됩니다.
1. Amazon SQS (Simple Queue Service): "작업 티켓"
- 한 줄 요약: 마이크로서비스 간의 연결을 느슨하게 풀고(Decoupling), 비동기 작업을 처리할 때 가장 속 편한 선택.
- 핵심 특징:
- 소비 후 삭제: 소비자가 메시지를 가져가서 처리를 완료하면(Ack), 그 메시지는 큐에서 영원히 사라집니다.
- 1:1 처리: 기본적으로 하나의 메시지는 하나의 소비자가 처리합니다.
- 관리 포인트 Zero: 완전 관리형 서버리스 서비스입니다. 확장성이나 인프라를 고민할 필요가 없습니다.
- 선택 기준:
- "이메일 발송", "이미지 리사이징"처럼 한 번 실행되고 끝나야 하는 비동기 작업을 보낼 때.
2. Amazon MSK (Managed Kafka): "중앙 신경망 (이벤트 허브)"
- 한 줄 요약: 대용량 실시간 이벤트를 여러 서비스가 동시에 구독해야 하고, 과거 데이터 재생(Replay)이 필요할 때.
- 핵심 특징:
- 데이터 영속성 & 재생(Replay): 이게 SQS와 가장 큰 차이입니다. 소비자가 데이터를 읽어가도 데이터는 삭제되지 않습니다. 설정한 기간(예: 7일) 동안 보관되며, 필요하면 과거 시점으로 돌아가서 데이터를 다시 읽을 수 있습니다.
- Pub/Sub 모델: 하나의 이벤트 토픽을 여러 컨슈머 그룹이 각자의 속도에 맞춰 동시에 읽어갈 수 있습니다.
- 높은 운영 난이도: 관리형 서비스지만, Kafka 자체에 대한 이해도가 필요하고 클러스터 용량 관리에 신경 써야 합니다.
- 선택 기준:
- MSA 환경에서 도메인 이벤트(주문 발생, 회원 가입 등)를 전파하여 여러 타 서비스가 각자 비즈니스 로직을 수행해야 할 때. CDC(Change Data Capture) 파이프라인의 중심.
3. Amazon Data Firehose: "데이터 배송 파이프"
- 한 줄 요약: 스트리밍 데이터를 분석/저장을 위해 S3나 Redshift 같은 데이터 호수(Data Lake)로 밀어 넣는 가장 쉬운 방법.
- 핵심 특징:
- 배달 전문: 데이터를 잠시 버퍼링했다가 목적지(S3, Redshift, OpenSearch 등)로 '배달'하고 나면 자신의 임무는 끝납니다. 데이터를 자체적으로 저장하고 있지 않습니다.
- 간단한 변환: 데이터가 지나가는 과정에서 Lambda를 붙여 간단한 포맷 변경(ETL)이 가능합니다.
- 서버리스: SQS처럼 인프라 관리 부담이 없습니다. 넣는 만큼 알아서 확장됩니다.
- 선택 기준:
- 애플리케이션 로그나 클릭스트림 데이터를 분석 목적으로 S3에 적재해야 할 때. 고민 없이 Firehose를 선택합니다.
It's up to you
| 특징 | SQS | MSK (Kafka) | Data Firehose |
| 핵심 모델 | 메시지 큐 (Point-to-Point) | 이벤트 스트림 (Pub/Sub) | 스트리밍 전달 (Delivery Stream) |
| 데이터 처리 후 | 삭제됨 (소비 시점) | 보관됨 (설정 기간 동안) | 목적지 전달 후 삭제됨 |
| 과거 데이터 재생 | 불가 | 가능 (핵심 기능) | 불가 |
| 주 사용처 | 비동기 작업, 서비스 디커플링 | 실시간 이벤트 허브, CDC | 데이터 레이크/저장소로 로그 적재 |
| 운영 편의성 | 높음 (서버리스) | 낮음 (클러스터 관리 필요) | 높음 (서버리스) |
현재 해결하려는 문제가 "단순 작업 처리"인지, "복잡한 이벤트 전파와 재생"인지, 아니면 "단순 데이터 적재"인지에 따라 적절한 도구를 선택하는 것이 중요합니다.
AWS 구성도: 사용 패턴 비교
아래 구성도는 세 서비스가 실제 아키텍처에서 어떤 흐름으로 사용되는지 직관적으로 보여줍니다.
- Pattern 1 (SQS): 웹 애플리케이션이 작업을 큐에 넣으면, 워커(Worker)가 메시지를 가져가 처리한 뒤 큐에서 명시적으로 삭제(Process & Delete)하는 흐름을 보여줍니다.
- Pattern 2 (MSK): 주문 서비스가 발행한 이벤트를 분석 서비스와 재고 서비스가 각자의 오프셋(Offset A, B)에 맞춰 서로 다른 속도로 데이터를 소비합니다. 점선 화살표는 새로운 서비스가 도입되었을 때 과거 데이터부터 다시 읽는(Replay) 기능을 표현합니다.
- "Slower"는 Kafka가 시스템 간의 처리 속도를 분리(Decoupling)하여, 느린 시스템이 빠른 시스템에 영향을 주지 않고 각자의 속도로 안정적으로 운영될 수 있음을 보여주는 예시입니다.
- Pattern 3 (Firehose): 로그 데이터를 Firehose가 받아 버퍼링(Batch)한 후 S3로 전송하는 파이프라인입니다. 이 과정에서 Lambda 함수를 이용해 데이터를 선택적으로 변환(Optional Transform)할 수 있음을 함께 보여줍니다.
댓글