Kinesis vs MSK vs SQS: 스트리밍과 큐 선택 기준
이벤트 데이터를 받아 넘기는 AWS 서비스를 고를 때, SQS·SNS·EventBridge 사이의 선택은 메시징 3종 비교에서 다뤘습니다. 이 글은 그다음 갈림길입니다. 결론을 먼저 적으면, “한 번 처리하고 끝"인 작업 전달은 SQS, 여러 소비자가 같은 데이터를 다시 읽어야 하는 스트림은 Kinesis, 그리고 Kafka 프로토콜·생태계가 요건일 때만 MSK입니다. 스트림이 필요 없는데 Kinesis를 고르거나, Kafka 요건이 없는데 MSK를 고르는 것이 이 영역의 흔한 과설계입니다. 요금은 us-east-1 기준입니다.
한눈에 보는 비교 #
| 구분 | SQS | Kinesis Data Streams | MSK |
|---|---|---|---|
| 모델 | 큐 (소비하면 삭제) | 스트림 (보존 기간 내 재읽기) | 스트림 (Kafka) |
| 순서 보장 | FIFO 큐 한정 | 샤드 내 보장 | 파티션 내 보장 |
| 다중 소비자 | 부적합 (SNS 조합 필요) | 기본 지원 | 기본 지원 |
| 과금 | 100만 건당 약 $0.40 | 샤드 시간당 약 $0.015 또는 GB당 | 브로커 인스턴스 시간 + 스토리지 |
| 유휴 비용 | 0 | 프로비저닝드는 샤드 유지비 | 클러스터 상시 비용 |
| 운영 부담 | 거의 없음 | 샤드 관리 (온디맨드면 완화) | 가장 큼 (Express·서버리스로 완화) |
| 생태계 | AWS 통합 | AWS 통합 (Lambda·Firehose) | Kafka 생태계 전체 |
모델 차이: 소비하면 사라지는가, 다시 읽는가 #
SQS의 메시지는 한 소비자가 처리하고 삭제하면 끝입니다. 작업 전달, 부하 평준화, 비동기 처리라는 용도에 정확히 맞고, Step Functions와의 역할 구분에서 다룬 대로 백엔드 처리의 기본 부품입니다. 요금도 100만 건당 약 $0.40으로 가장 단순합니다.
Kinesis와 MSK의 스트림은 다릅니다. 데이터가 보존 기간(기본 24시간, 연장 가능) 동안 남아 있고, 여러 소비자가 각자의 위치에서 같은 데이터를 독립적으로 읽습니다. 클릭스트림을 실시간 대시보드와 S3 적재와 이상 탐지가 동시에 읽는 구성, 장애 후 특정 시점부터 다시 읽는 재처리가 스트림의 고유 영역입니다. 반대로 소비자가 하나뿐이고 재읽기 요건이 없다면, 스트림의 이 능력은 쓰지 않는 기능에 요금과 운영을 내는 것이 됩니다.
판단 질문은 두 개입니다. 같은 데이터를 읽는 소비자가 둘 이상인가? 지나간 데이터를 다시 읽어야 하는가? 둘 다 아니오면 SQS로 끝이고, 하나라도 예면 스트림 계열로 넘어갑니다.
Kinesis: AWS 네이티브 스트림의 두 모드 #
Kinesis Data Streams는 AWS 통합이 강점입니다. Lambda 트리거, Firehose를 통한 S3·웨어하우스 적재가 설정 수준에서 붙습니다. 과금 모드가 둘입니다.
- 프로비저닝드: 샤드 시간당 약 $0.015. 샤드당 쓰기 1MB/s·읽기 2MB/s 한도가 있어 처리량에 맞춰 샤드 수를 관리합니다. 샤드 2개면 월 약 $22로, 처리량이 예측되는 상시 스트림에서 가장 쌉니다.
- 온디맨드: 처리량 관리 없이 GB 단위 과금입니다. 표준 모드 기준 수신 GB당 약 $0.08이고, 2025년 말 추가된 Advantage 모드는 수신 약 $0.032·송신 약 $0.016으로 단가를 크게 내렸습니다(모드·단가는 도입 시점 재확인). 스파이크가 크거나 처리량 예측이 안 서면 온디맨드로 시작해, 사용 패턴이 잡히면 프로비저닝드와 비교하는 순서가 안전합니다.
주의할 함정은 샤드 수와 소비자 수의 곱입니다. 소비자가 늘면 샤드당 읽기 한도를 나눠 쓰므로, 소비자가 많은 구성은 팬아웃 소비자(enhanced fan-out, 추가 요금)나 샤드 증설이 필요해집니다. 소비자 서너 개 수준까지는 문제가 없지만, 그 이상을 계획한다면 설계 단계에서 계산해 둡니다.
MSK: Kafka가 요건일 때만 #
MSK는 관리형 Kafka입니다. 선택 이유는 성능이 아니라 생태계와 이식성입니다. 기존 Kafka 클러스터에서 이전하는 경우, Kafka Connect·Streams·Flink 같은 생태계 도구를 그대로 쓰려는 경우, 멀티 클라우드·온프레미스 이식성이 요건인 경우, 파티션 수천 개 규모의 대형 스트림 플랫폼을 만드는 경우가 정당한 이유입니다. 이 요건이 없다면 같은 스트림 모델을 훨씬 적은 운영으로 주는 Kinesis가 기본값입니다.
MSK 안에서도 갈래가 있습니다. 표준 브로커는 브로커 인스턴스 시간 + EBS 스토리지 과금에 브로커 크기·수·스토리지를 직접 운영하는 전통 구성입니다. Express 브로커는 스토리지 관리를 없애고 브로커당 처리량을 높인 세대로, 표준 대비 처리량·복구 속도가 크게 개선되어 신규 프로비저닝드 클러스터의 권장 기본값이 되었습니다. MSK 서버리스는 클러스터 시간당 약 $0.75 + 파티션·전송량 과금이라 바닥이 월 약 $550부터 시작합니다. 서버리스라는 이름과 달리 유휴 비용이 0이 아니므로, 소규모 워크로드라면 서버리스 MSK보다 Kinesis 온디맨드가 구조적으로 쌉니다.
선택 순서 #
- 큐로 충분한지부터 봅니다: 다중 소비자·재읽기 요건이 없으면 SQS입니다. 스트림은 필요할 때 도입해도 늦지 않습니다.
- 스트림이 필요하면 Kinesis를 기본값으로 놓습니다: AWS 안에서 완결되는 파이프라인이면 Lambda·Firehose 통합이 운영을 대부분 흡수합니다.
- Kafka 요건을 명시적으로 확인합니다: 기존 Kafka 이전, 생태계 도구, 이식성, 초대형 규모 중 해당 항목을 적어 봅니다. 없으면 MSK를 고를 이유도 없습니다.
- Kinesis 모드는 처리량 예측으로 가릅니다: 예측 가능하면 프로비저닝드 샤드, 불확실하면 온디맨드로 시작해 실측 후 재평가합니다.
- MSK로 간다면 Express 브로커부터 검토합니다: 신규 클러스터의 기본값이고, 소규모인데 MSK가 필요하다면 서버리스 바닥 비용(월 약 $550)과 Kinesis를 반드시 비교합니다.
정리 #
- 판단 질문은 두 개입니다. 소비자가 둘 이상인가, 다시 읽어야 하는가. 둘 다 아니오면 SQS, 하나라도 예면 스트림입니다.
- 스트림의 기본값은 Kinesis입니다. AWS 통합이 운영을 흡수하고, 프로비저닝드 샤드(시간당 약 $0.015)와 온디맨드 두 모드로 규모에 맞춥니다.
- MSK는 Kafka 생태계·이식성·초대형 규모라는 명시적 요건이 있을 때만 선택합니다. 요건 없이 고르면 가장 비싼 운영을 사는 것입니다.
- MSK 프로비저닝드는 Express 브로커가 신규 기본값이고, 서버리스는 바닥이 월 약 $550이라 소규모에서는 Kinesis 온디맨드가 쌉니다.
- 소비자 수 × 샤드 읽기 한도, 온디맨드 GB 단가 같은 수치는 설계 단계에서 계산하고, 도입 시점에 현행 요금을 재확인합니다.