close
프로필 배경
프로필 로고

Ruru's PlayGround :)

AI & Software · 2025. 9. 9. fullscreen 넓게보기

Kafka vs Kinesis: ‘실시간 데이터 처리’의 택배 회사

Kafka vs Kinesis: ‘실시간 데이터 처리’의 택배 회사

회사에서 로그 쏟아지고, 앱에서 클릭이 터지고, 카드 승인 알림이 비처럼 내릴 때… 이 수많은 “작은 소식들”을 안전하게 받고 흘려보내는 친구가 있어요. 그게 바로 메시지 브로커/스트리밍 서비스예요.

겁먹을 필요 없어요. 일종의 택배 분류센터처럼 생각하면 되고, 메시지 브로커는 택배상자들이 흘러가는 컨베이어 벨트라고 생각하면 쉽게 개념이 잡힙니다. 들어오는 상자(이벤트)를 정확히 받아서, 각 목적지(분석, 대시보드, 알림, 저장소)로 빠르고 안전하게 분배하는 시스템이죠.

오늘은 그중에서도 가장 많이 비교되는 Apache Kafka와 Amazon Kinesis를 중심으로, 언제 뭘 고르면 좋은지, 장단점과 성능, 비용, 사용자 평판까지 실전 감각으로 풀어볼게요. “IT 잘 몰라도” 이해 가도록 비유와 사례 위주로 갑니다. 딱딱하게 안 할게요. 대신 핵심만 콕콕.

한 줄 정의 (진짜 쉬운 버전)

  • Kafka: 오픈소스 실시간 데이터 ‘컨베이어벨트’. 내 맘대로 꾸미기 좋고, 초고속 대량 처리에 강함. 직접 운영하거나 관리형(MSK/Confluent Cloud)도 가능.
  • Kinesis: AWS가 운영해주는 ‘관리형 컨베이어벨트’. 설정만 하면 돌아가고, 다른 AWS 서비스랑 찰떡궁합. 대신 AWS 안에서 사는 느낌.

공식 문서 한 번은 꼭 스쳐가자:

이 서비스들이 해주는 일, 생활 비유로

  • 메시지 브로커: “일단 받아줘!”가 핵심. 생산자(앱, 서버, 기기)가 보낸 이벤트를 중간에 받아, 소비자(분석, 알림, 추천 시스템)들이 각자 속도대로 가져가게 해줘요. 밀려도 안 터지게 버퍼 역할을 하고, 순서도 지켜줍니다(일부 조건 하에서).
  • 스트리밍 처리: 들어오는 족족 바로 계산/집계/필터링. 예를 들어 “지금 접속 중인 사용자 수”를 5초 단위로 갱신한다든가, “사기 결제 패턴”을 실시간 탐지한다든가.

Kafka와 Kinesis, 공통점과 결정적 차이

공통점

  • 실시간 이벤트 수집, 저장(일정 기간), 재처리(리플레이) 가능
  • 파티션/샤드 단위로 순서 보장
  • 소비자 그룹으로 스케일 아웃

결정적 차이

운영과 생태계

  • Kafka: 오픈소스, 어디서든 돌릴 수 있고(온프레미스, 멀티클라우드), 생태계가 매우 풍부(Kafka Connect, Kafka Streams, ksqlDB 등).
  • Kinesis: AWS 완전관리형. 셋업이 빠르고, S3/Redshift/Lambda/OpenSearch 등과 바로 집결.

확장 모델

  • Kafka: 토픽을 파티션으로 쪼개고 브로커 늘려서 확장. 최댓값이 하드웨어/네트워크에 의해 크게 열려 있음.
  • Kinesis Data Streams: 샤드(shard) 단위 확장. 샤드당 쓰기/읽기 한도가 명확해서(예: 샤드당 대략 1MB/s write, 2MB/s read, 1,000 records/s) 초과하면 샤드를 늘려야 함. 최근엔 On-demand 모드로 자동 확장도 가능.

전송 보장/재처리

  • 둘 다 “최소 한 번(at-least-once)” 처리가 일반적. Kafka는 idempotent producer + 트랜잭션으로 EOS(exactly-once semantics) 시나리오를 꽤 정교하게 지원. Kinesis는 Flink 같은 프레임워크를 붙이면 유사한 정확성 보장을 구성할 수 있지만, 기본 소비 패턴은 at-least-once에 가깝고, idempotency 설계가 중요.

보관/리텐션

  • Kafka: 시간/용량/압축(compaction) 기반 유연한 정책. 장기간 보관도 흔함.
  • Kinesis: 기본 24시간, 확장해 최대 365일까지(Extended Retention). Firehose는 거의 실시간으로 S3 등에 “전달”하는 역할이라 재생(replay)은 안 됨.

지연 시간과 처리량 감각

  • Kafka: 잘 튜닝하면 초고속(수십수백 MB/s 이상), 지연 수 ms수십 ms. 아주 큰 워크로드에도 스케일이 잘 나옴.
  • Kinesis: 샤드·소비자 설정에 따라 수십~수백 ms 지연. Enhanced Fan-Out을 쓰면 소비자별 읽기 전용 대역폭과 지연이 좋아짐. 초대량이면 샤드/비용 관리가 포인트.

언제 뭘 쓰면 좋은가? (의사결정 빠르게)

  • AWS 안에서 빠르게 시작하고, 인프라 운영 인력 거의 없다 → Kinesis 추천
    • Data Firehose로 S3/Redshift/OpenSearch까지 “배달”만 필요해도 충분히 끝남.
    • Lambda, Athena, QuickSight 같은 AWS 서비스 연동 신세계.
  • 멀티클라우드/온프레미스 병행, Kafka 생태계(Connect/Streams) 적극 활용 → Kafka 추천
    • 커넥터로 MySQL/Oracle/Elasticsearch/S3/BigQuery 등 양방향 연동 쉽게.
    • 데이터 거버넌스, 장기 보관, 파티션 설계의 자유도가 높음.
  • 한 번에 진짜 많이, 진짜 빠르게 → Kafka로 가는 경우가 많음
    • 고성능 하드웨어+적절한 파티션 설계로 폭발적인 처리량.
  • 비용/운영 타협: “Kafka 쓰고 싶은데 운영은 부담” → 관리형 Kafka
    • Amazon MSK나 Confluent Cloud 고려. 관리 부담 줄이고 Kafka 생태계는 그대로.

장단점 요약

Kafka 장점

  • 초고성능, 유연한 아키텍처(파티션/토픽/리텐션/압축).
  • 오픈 생태계: Kafka Connect, Streams, ksqlDB, 모니터링/옵저버빌리티 도구 풍부.
  • 멀티클라우드/온프렘 자유.
  • 정확히-한-번 처리 시나리오 구성 용이(EOS).

Kafka 단점

  • 직접 운영 시 난이도 높음(업그레이드, 파티션 리밸런싱, 스토리지/네트워킹 튜닝). 다만 최신 Kafka는 KRaft로 Zookeeper 의존이 줄어들어 점점 나아짐.
  • 처음엔 개념(브로커/파티션/리플리카/ISR) 진입장벽이 존재.

Kinesis 장점

  • AWS 완전관리형. 몇 분 만에 스트림 열고 쓰기 시작.
  • S3/Redshift/OpenSearch/Lambda 등과 원클릭 연동(특히 Firehose).
  • 샤드/온디맨드/Enhanced Fan-Out 등 선택지 다양.
  • 보안/권한/IAM 모델과 자연스럽게 연결.

Kinesis 단점

  • 샤드당 할당량 한도를 넘기면 스로틀링. 트래픽 패턴이 튀면 샤드/비용 관리가 번거로울 수 있음.
  • 기본 소비는 at-least-once. 정확성 보장 시 애플리케이션/프레임워크 설계 필요.
  • AWS 종속. 멀티클라우드/온프렘 혼합엔 부적합.

성능과 사용자들의 체감

현장에서 자주 듣는 얘기들(제 경험+업계 평판 종합)

  • Kafka는 “큰 물량/높은 TPS/낮은 지연”에서 주로 이깁니다. 파티션 잘 쪼개고 브로커/디스크/네트워크 튜닝하면 무지막지하게 나옵니다. 반대로, 운영·모니터링을 소홀히 하면 밤샘할 확률이 올라가요.
  • Kinesis는 “빠른 시작/운영 무관심/클라우드 네이티브 파이프라인”에서 행복합니다. 특히 Firehose+S3로 로그 레이크 만들고, Athena로 바로 쿼리 날리는 패턴이 미친 효율을 보여줘요. 다만 샤드/소비자 구성 실수를 하면 짜릿한 스로틀링을 맛볼 수 있습니다.
  • 지연: Kafka 튜닝된 환경은 한 자리~수십 ms가 흔하고, Kinesis는 Enhanced Fan-Out으로 좋아졌지만 근본적으로 네트워크+관리형 특성상 Kafka보다 낮게 뽑기는 어렵다는 인상.
  • 리텐션/리플레이: Kafka가 더 유연하고 길게 가져가기 편합니다. Kinesis Data Streams도 365일까지 가능하지만, Firehose는 리플레이가 안 되니 설계 시 주의.

비용 감각(대략의 방향성)

  • Kinesis Data Streams: 샤드-시간, PUT 유닛(25KB 청크), 저장/리텐션, Enhanced Fan-Out, 온디맨드 모드 등 과금. 트래픽이 들쭉날쭉하면 온디맨드가 편하고, 장기적으로는 샤드 기반이 더 싸게 나올 때도.
  • Kinesis Data Firehose: 전송량(GB), 변환/압축/전달 대상 등 옵션별 과금. 운영비 거의 제로인 게 큰 장점.
  • Kafka 자체 운영: 인스턴스/스토리지/네트워크 비용+운영 인력 비용. 규모가 커지면 단가 측면에서 유리해질 수 있지만, 운영 난이도 비용을 과소평가하면 낭패.
  • 관리형 Kafka(MSK/Confluent): 브로커 시간/스루풋/스토리지 과금. “운영비 아껴서 비즈니스 로직에 집중”이라는 전략이면 좋은 선택.

실전 시나리오로 보는 선택

1) 앱 로그/클릭스트림 → S3 적재 → Athena/QuickSight로 분석

  • Kinesis Data Firehose + S3 조합이 압승. 손대는 곳이 없음. 알맞은 버퍼(예: 1분/몇 MB)로 비용/지연 밸런스.
  • Kafka라면 Kafka Connect S3 Sink로 비슷하게 가능하지만 운영 포인트가 늘어요.

2) 마이크로서비스 이벤트 버스(주문→결제→배송)

  • Kafka 추천. 토픽 분리, 파티션 전략, 스키마 진화(Confluent Schema Registry)까지 얹으면 장기적 안정성 Good.
  • AWS 중심이면 Amazon MSK로 타협하는 것도 현실적.

3) IoT 디바이스 수십만대, 가끔 트래픽 폭증

  • Kinesis Data Streams On-demand로 시작하면 확장/축소 자동. Lambda 소비로 알림/가공.
  • 초고성능 복잡 로직+장기 리플레이가 필수면 Kafka도 고려.

4) 실시간 이상 징후 탐지/윈도우 집계

  • Kafka Streams/ksqlDB를 쓰거나, Kinesis Data Analytics(실제로는 Apache Flink 기반)로 SQL/Flink 잡 구성. 엔지니어링 취향과 팀 역량에 따라 선택.

작게 시작하려면 이렇게

Kafka 빠른 맛보기

  • Quickstart: https://kafka.apache.org/quickstart
  • Docker로 한 방에: Confluent Platform cp-all-in-one 예제
  • 토픽 만들고, 콘솔 프로듀서/컨슈머로 보내고 받아보기

Kinesis 빠른 맛보기

개인적인 한마디(경험담)

  • “팀에 데이터 플랫폼 담당 0.5명”이면 Kinesis로 행복해질 확률이 높습니다. 특히 Firehose는 가성비 미쳤어요.
  • “데이터가 회사 핵심 IP고, 멀티클라우드/온프렘 섞여 있고, 커넥터/스트림 처리/리텐션 제어를 손에 쥐고 싶다”면 Kafka가 답입니다. 다만 운영 자동화를 최대한 빨리 깔아야 주말이 편해요.
  • “둘 다 쓰는 것”도 흔합니다. Kinesis로 수집하고, 배치·아카이브는 S3, 실시간 코어 파이프라인은 Kafka… 시스템은 도구가 아니라 조합입니다. 필요에 맞게 섞으세요.

더 읽을거리(참고 링크)

덤: 이럴 땐 Kafka/Kinesis 말고 이거

  • 단순 “작업 큐”가 필요하고 재생/리텐션 필요 없음 → AWS SQS, RabbitMQ
  • GCP 중심 → Pub/Sub, Dataflow
  • Azure 중심 → Event Hubs, Stream Analytics
  • 초경량/인메모리 느낌 → Redis Streams
  • 대규모 멀티테넌시/지리 분산 필요 → Apache Pulsar

도구는 목적에 맞게. “무엇이 더 좋다”보다 “지금 우리 문제를 더 쉽게 푸는가”가 1순위입니다. 선택에 고민이 생기면, 트래픽 패턴(초당 이벤트/레코드 크기), 지연 요구, 리텐션, 재처리 필요성, 운영 인력, 클라우드 전략, 예산 — 이 여섯 가지만 표로 적어 보세요. 답이 생각보다 빨리 나옵니다.

저작자표시 비영리 변경금지 (새창열림)

'AI & Software' 카테고리의 다른 글

GitLab으로 “자동 코드 리뷰” 작업 환경 만들기  (1) 2025.09.30
OpenAI의 새로운 오픈소스 모델 GPT-OSS  (9) 2025.08.15
NAS에 N8N 설치 (ARM CPU 기반 Ubuntu, Odroid)  (5) 2025.08.13
OpenAI - Deep Research - 추론 엔진으로 AI 연구 비서  (0) 2025.02.06
AI & Software 관련 글
더 보기

티스토리툴바