2025년 9월 22일·7분
Kafka란 무엇이며 현대 시스템에서는 어떻게 사용되나요?
Apache Kafka가 무엇인지, 토픽과 파티션이 어떻게 동작하는지, 실시간 이벤트·로그·데이터 파이프라인에서 Kafka가 어떤 역할을 하는지 알아보세요.
Apache Kafka가 무엇인지, 토픽과 파티션이 어떻게 동작하는지, 실시간 이벤트·로그·데이터 파이프라인에서 Kafka가 어떤 역할을 하는지 알아보세요.
Apache Kafka는 분산 이벤트 스트리밍 플랫폼입니다. 간단히 말해, 여러 시스템이 무슨 일이 일어났는지를 게시(publish)하고 다른 시스템이 그 사실을 빠르게, 대규모로, 순서대로 읽을 수 있게 해 주는 공유되고 내구성 있는 "파이프"입니다.
시스템 간에 느슨한 결합으로 안정적으로 데이터가 이동해야 할 때 팀들은 Kafka를 사용합니다. 한 애플리케이션이 다른 애플리케이션을 직접 호출하면 상대가 다운되거나 느릴 때 실패할 수 있지만, 프로듀서는 이벤트를 Kafka에 기록합니다. 컨슈머는 준비되었을 때 읽습니다. Kafka는 이벤트를 설정한 기간 동안 저장하므로 시스템이 장애에서 복구하고 이력을 재처리할 수 있습니다.
이 가이드는 제품 관점을 가진 엔지니어, 데이터 담당자, 기술 리더를 위한 것으로, Kafka에 대한 실무적 멘탈 모델을 제공합니다.
핵심 구성 요소(프로듀서, 컨슈머, 토픽, 브로커), 파티션으로 확장하는 방법, 이벤트를 저장하고 재생성하는 방식, 이벤트 기반 아키텍처에서의 위치를 배우게 됩니다. 또한 일반적인 사용 사례, 전달 보장, 보안 기초, 운영 계획, Kafka가 적절하거나 적절하지 않은 경우도 다룹니다.
Kafka는 공유 이벤트 로그로 이해하면 쉽습니다: 애플리케이션이 이벤트를 쓰고 다른 애플리케이션이 나중에(대개 실시간으로) 그 이벤트를 읽습니다—때로는 몇 시간, 며칠 뒤일 수도 있습니다.
프로듀서는 쓰는 쪽입니다. 예를 들어 "주문 생성(order placed)", "결제 완료(payment confirmed)", "온도 측정" 같은 이벤트를 발행할 수 있습니다. 프로듀서는 특정 앱에 직접 이벤트를 보내지 않고 Kafka에 보냅니다.
컨슈머는 읽는 쪽입니다. 대시보드를 갱신하거나, 배송 워크플로를 트리거하거나, 분석용으로 데이터를 적재할 수 있습니다. 컨슈머는 이벤트를 어떻게 처리할지 결정하며 자신의 속도로 읽을 수 있습니다.
Kafka의 이벤트는 토픽이라는 이름 붙여진 카테고리로 그룹화됩니다. 예:
orders — 주문 관련 이벤트payments — 결제 이벤트inventory — 재고 변경토픽은 해당 이벤트 유형의 “진실의 출처(source of truth)” 스트림이 되어 여러 팀이 일회성 통합을 만들지 않고도 같은 데이터를 재사용하기 쉽게 합니다.
브로커는 이벤트를 저장하고 컨슈머에 제공하는 Kafka 서버입니다. 실제 운영에서는 여러 브로커가 함께 동작하는 클러스터로 실행되어 더 많은 트래픽을 처리하고 머신 장애 시에도 서비스를 유지합니다.
컨슈머는 보통 컨슈머 그룹으로 실행됩니다. Kafka는 그룹 내에서 읽기 작업을 분산시키므로 컨슈머 인스턴스를 늘려 처리량을 확장할 수 있습니다—모든 인스턴스가 동일 작업을 반복하지 않습니다.
Kafka는 관련 이벤트 스트림인 토픽을 만들고, 각 토픽을 더 작은 독립 단위인 파티션으로 나누어 확장합니다.
파티션이 하나뿐인 토픽은 컨슈머 그룹 내에서 한 번에 하나의 컨슈머만 읽을 수 있습니다. 파티션을 늘리면 이벤트를 병렬로 처리할 수 있는 컨슈머도 늘릴 수 있습니다. 이것이 Kafka가 높은 볼륨의 이벤트 스트리밍과 실시간 데이터 파이프라인을 지원하는 방식입니다.
파티션은 또한 부하를 브로커들에 분산시키는 데 도움이 됩니다. 하나의 기계가 토픽의 모든 쓰기와 읽기를 처리하는 대신 여러 브로커가 서로 다른 파티션을 호스팅해 트래픽을 나눕니다.
Kafka는 단일 파티션 내의 순서를 보장합니다. 이벤트 A, B, C가 같은 파티션에 그 순서로 쓰였다면 컨슈머는 A → B → C 순서로 읽습니다.
파티션 간 순서는 보장되지 않습니다. 특정 엔터티(고객, 주문 등)에 대해 엄격한 순서가 필요하면 해당 엔터티의 모든 이벤트가 같은 파티션으로 가도록 설계합니다.
프로듀서가 이벤트를 보낼 때 키(예: order_id)를 포함할 수 있습니다. Kafka는 키를 사용해 관련 이벤트를 동일 파티션으로 일관되게 라우팅합니다. 이렇게 하면 그 키에 대해 예측 가능한 순서를 유지하면서도 전체 토픽은 여러 파티션에 걸쳐 확장할 수 있습니다.
각 파티션은 다른 브로커에 복제될 수 있습니다. 한 브로커가 실패하면 복제본을 가진 다른 브로커가 대신 역할을 맡을 수 있습니다. 복제는 Kafka가 미션 크리티컬한 pub-sub 메시징과 이벤트 기반 시스템에서 신뢰받는 주요 이유 중 하나로, 애플리케이션이 별도의 페일오버 로직을 만들 필요 없이 가용성과 내결함성을 제공합니다.
Apache Kafka의 핵심 아이디어는 이벤트가 단순히 전달되는 것이 아니라 디스크에 순서대로 기록된다는 점입니다. 소비자는 지금 읽을 수도 있고, 나중에 읽을 수도 있습니다. 이 때문에 Kafka는 데이터 이동뿐 아니라 무슨 일이 일어났는지에 대한 내구성 있는 이력을 보관하는 데 유용합니다.
프로듀서가 이벤트를 토픽에 보내면 Kafka는 이를 브로커의 스토리지에 추가합니다. 컨슈머는 저장된 로그에서 자신의 속도로 읽습니다. 컨슈머가 한 시간 동안 다운되어도 이벤트는 남아있어 복구 후 따라잡을 수 있습니다.
Kafka는 다음과 같은 보관 정책에 따라 이벤트를 보관합니다:
보관은 토픽별로 설정하므로 감사 트레일 토픽과 고빈도 텔레메트리 토픽을 다르게 취급할 수 있습니다.
어떤 토픽은 완전한 이력보다 변경 로그 성격이 강합니다(예: "현재 고객 설정"). 로그 컴팩션은 각 키에 대해 최신 이벤트를 최소한으로 유지하고 오래된 대체된 레코드는 제거합니다. 이렇게 하면 최신 상태의 내구성 있는 진실의 출처를 유지하면서 무한한 데이터 증가를 막을 수 있습니다.
이벤트가 저장되어 있기 때문에 다음과 같은 재생이 가능합니다:
실무에서는 컨슈머가 어디서부터 읽기 시작할지(오프셋)로 재생을 제어하므로 시스템이 진화할 때 강력한 안전망을 제공합니다.
Kafka는 시스템 일부가 실패하더라도 데이터 흐름을 유지하도록 설계되었습니다. 이는 복제, 각 파티션의 "책임자"에 대한 명확한 규칙, 그리고 구성 가능한 **쓰기 인정(acknowledgments)**으로 달성됩니다.
각 토픽 파티션에는 하나의 리더 브로커와 하나 이상의 팔로워 복제본이 있습니다. 프로듀서와 컨슈머는 해당 파티션의 리더와 통신합니다.
팔로워는 리더의 데이터를 지속해서 복사합니다. 리더가 다운되면 Kafka는 최신 상태인 팔로워를 승격시켜 새로운 리더로 만들어 파티션의 가용성을 유지할 수 있습니다.
브로커가 실패하면 그 브로커가 리더로 호스팅하던 파티션들은 잠시 이용 불가가 됩니다. Kafka의 컨트롤러가 실패를 감지하고 해당 파티션들에 대해 리더 선출(leader election) 을 트리거합니다.
충분히 따라잡은 팔로워가 있다면 그 팔로워가 리더가 되어 클라이언트는 생산/소비를 재개합니다. 만약 동기화된 복제본(in-sync replica)이 없다면 Kafka는 설정에 따라 쓰기를 중단해 인정된 데이터를 잃지 않도록 할 수 있습니다.
내구성은 주로 두 가지 설정으로 결정됩니다:
개념적으로:
재시도 중 중복을 줄이려면 보통 더 안전한 acks 설정과 멱등 프로듀서, 견고한 컨슈머 처리를 결합합니다.
안전성을 높이면 더 많은 확인을 기다리고 더 많은 복제본을 동기화해야 하므로 지연 시간과 최종 처리량이 늘어날 수 있습니다.
지연 시간을 낮추는 설정은 텔레메트리나 클릭스트림처럼 일시적 손실이 허용되는 데이터에 적합할 수 있지만 결제, 재고, 감사 로그 같은 경우는 추가 안전을 우선시하는 것이 일반적입니다.
이벤트 기반 아키텍처(EDA)는 비즈니스에서 발생하는 사건(주문 생성, 결제 승인, 발송 등)을 다른 시스템이 반응할 수 있는 이벤트로 표현하는 방식입니다.
Kafka는 종종 공유 "이벤트 스트림"의 중심에 위치합니다. 서비스 A가 서비스 B를 직접 호출하는 대신, 서비스 A는 Kafka 토픽에 OrderCreated 같은 이벤트를 발행합니다. 여러 서비스가 그 이벤트를 구독해 이메일 발송, 재고 예약, 사기 검사 등을 수행할 수 있으며, 서비스 A는 이들 존재를 알 필요가 없습니다.
서비스들이 이벤트를 통해 통신하므로 모든 상호작용에 대해 요청/응답 API를 조율할 필요가 없습니다. 이는 팀 간의 강한 의존성을 줄이고 새로운 기능 추가를 쉽게 만듭니다: 기존 프로듀서를 변경하지 않고도 새로운 컨슈머를 추가할 수 있습니다.
EDA는 본질적으로 비동기적입니다: 프로듀서는 빠르게 이벤트를 쓰고 컨슈머는 자신의 속도로 처리합니다. 트래픽 스파이크 시 Kafka는 다운스트림 시스템이 즉시 과부하되지 않도록 버퍼 역할을 합니다. 컨슈머는 스케일 아웃해 따라잡을 수 있고, 하나의 컨슈머가 일시적으로 다운돼도 오프셋부터 다시 이어서 처리할 수 있습니다.
Kafka를 시스템의 "활동 피드(activity feed)"로 생각하세요. 프로듀서는 사실을 발행하고 컨슈머는 자신이 관심 있는 사실을 구독합니다. 이 패턴은 실시간 데이터 파이프라인과 이벤트 기반 워크플로를 가능하게 하면서 서비스들을 단순하고 독립적으로 유지합니다.
Kafka는 많은 작고 독립적인 “발생한 사실(이벤트)”을 여러 시스템 사이에서 빠르고 신뢰성 있게, 여러 소비자가 재사용할 수 있게 전달해야 할 때 자주 사용됩니다.
애플리케이션은 종종 사용자 로그인, 권한 변경, 레코드 업데이트, 관리자 작업 같은 추가 전용 히스토리가 필요합니다. Kafka는 이러한 이벤트의 중앙 스트림으로 잘 작동하여 보안 도구, 리포팅, 컴플라이언스 추출이 동일한 소스를 읽도록 합니다. 이벤트가 일정 기간 보관되므로 버그나 스키마 변경 후에도 감사 뷰를 재구성하기 위해 재생할 수 있습니다.
서비스들이 서로 직접 호출하는 대신 "주문 생성", "결제 수신" 같은 이벤트를 발행할 수 있습니다. 다른 서비스들은 구독해서 각자 처리합니다. 이는 강한 결합을 줄이고 부분 장애 동안 시스템이 계속 동작하도록 돕고, 기존 이벤트 스트림을 소비함으로써 사기 검사 같은 새로운 기능을 쉽게 추가할 수 있게 합니다.
Kafka는 운영 시스템에서 애널리틱스 플랫폼으로 데이터를 옮기는 공통 백본입니다. 팀은 애플리케이션 데이터베이스의 변경을 스트리밍해 웨어하우스나 데이터 레이크로 낮은 지연으로 전달하면서 프로덕션 앱을 무거운 조회로부터 분리할 수 있습니다.
센서, 디바이스, 앱 텔레메트리는 종종 버스트로 도착합니다. Kafka는 버스트를 흡수해 안전하게 버퍼링하고 다운스트림 처리기가 따라잡을 수 있게 해줍니다—모니터링, 알림, 장기 분석에 유용합니다.
Kafka는 브로커와 토픽만 있는 것이 아닙니다. 대부분의 팀은 일상적 데이터 이동, 스트림 처리, 운영을 실용적으로 만들어 주는 도구들을 함께 사용합니다.
Kafka Connect는 데이터를 Kafka로 들여오거나 Kafka에서 내보낼 수 있는 통합 프레임워크입니다(소스와 싱크). 일회성 파이프라인을 직접 만들고 유지하는 대신 Connect를 실행하고 커넥터를 설정합니다.
일반 예로는 DB에서 변경을 끌어오기, SaaS 이벤트 수집, Kafka 데이터를 데이터 웨어하우스나 오브젝트 스토리지로 전달하기 등이 있습니다. Connect는 재시도, 오프셋, 병렬성 같은 운영 이슈도 표준화합니다.
Connect가 통합용이라면 Kafka Streams는 계산용입니다. 애플리케이션에 추가하는 라이브러리로 스트림을 실시간으로 변환(필터, 보강, 조인, 집계)합니다.
Streams 앱은 토픽을 읽고 결과를 다시 토픽에 쓰기 때문에 이벤트 기반 시스템에 자연스럽게 맞고 인스턴스를 늘려 스케일할 수 있습니다.
여러 팀이 이벤트를 발행하면 일관성이 중요합니다. 스키마 레지스트리 같은 스키마 관리는 이벤트의 필드와 진화 방식을 정의해 생산자가 필드를 변경해 소비자가 깨지는 상황을 막습니다.
Kafka는 운영에 민감하므로 기본 모니터링은 필수입니다:
대부분의 팀은 운영 UI와 자동화로 배포, 토픽 구성, 접근 제어 정책을 관리합니다(참고: /blog/kafka-security-governance).
Kafka는 보통 "내구성 있는 로그 + 컨슈머"로 설명되지만, 실제로 팀이 가장 신경 쓰는 건: 이벤트를 각 한 번만 처리할 수 있나? 실패 시 어떻게 되나? 입니다. Kafka는 빌딩 블록을 제공하고 여러분이 트레이드오프를 선택합니다.
최대 한 번(at-most-once): 이벤트를 잃을 수 있지만 중복은 없음. 컨슈머가 위치를 먼저 커밋하고 작업을 마치기 전에 다운되면 발생합니다.
최소 한 번(at-least-once): 이벤트를 잃지 않지만 중복이 발생할 수 있음—가장 흔한 기본 패턴입니다.
정확히 한 번(exactly-once): 손실과 중복을 모두 피하려는 것. Kafka에서는 보통 트랜잭셔널 프로듀서와 호환되는 처리(종종 Kafka Streams)를 통해 달성합니다. 강력하지만 제약이 있고 신중한 설정이 필요합니다.
실무에서는 많은 시스템이 at-least-once를 수용하고 다음과 같은 안전장치를 추가합니다:
컨슈머 오프셋은 파티션에서 마지막으로 처리한 레코드의 위치입니다. 오프셋을 커밋하면 "여기까지 끝냈다"고 표시하는 것입니다. 일찍 커밋하면 손실 위험이 있고, 늦게 커밋하면 크래시 후 중복 처리가 늘어납니다.
재시도는 한정적이고 가시적이어야 합니다. 일반적 패턴:
이렇게 하면 하나의 문제 레코드가 전체 컨슈머 그룹을 막지 않으면서 데이터도 보존합니다.
Kafka는 종종 주문, 결제, 사용자 활동 같은 비즈니스에 중요한 이벤트를 실어나릅니다. 따라서 보안과 거버넌스는 설계의 일부여야 합니다.
인증은 "당신은 누구인가?"를 확인하고 권한은 "무엇을 할 수 있는가?"를 정합니다. Kafka에서는 일반적으로 SASL(SCRAM, Kerberos 등)로 인증하고 ACL(액세스 제어 목록)으로 토픽·컨슈머 그룹·클러스터 수준의 권한을 관리합니다.
실무 패턴은 최소 권한 원칙: 프로듀서는 자신이 소유한 토픽에만 쓸 수 있고, 컨슈머는 필요한 토픽만 읽을 수 있게 해 자격 증명 유출 시 영향 범위를 줄입니다.
TLS는 애플리케이션, 브로커, 도구 간에 이동하는 데이터를 암호화합니다. 내부 네트워크에서도 이벤트가 가로채질 수 있으므로 TLS가 필요하며, 브로커 식별을 검증해 중간자 공격을 막는 데도 도움됩니다.
여러 팀이 클러스터를 공유할 때는 가드레일이 필요합니다. 명확한 토픽 네이밍 규칙(예: <팀>.<도메인>.<이벤트>.<버전>)은 소유권을 분명히 하고 정책 적용을 쉽게 합니다.
네이밍과 함께 쿼터 및 ACL 템플릿을 도입해 한 워크로드가 다른 워크로드를 고갈시키지 않도록 하고, 새 서비스가 안전한 기본값으로 시작하도록 합니다.
Kafka를 이벤트 이력의 시스템 오브 레코드로 취급하려면 의도적으로 하세요. 이벤트에 PII가 포함된다면 데이터 최소화(전체 프로필 대신 ID 전송), 필드 수준 암호화 고려, 민감 토픽 문서화 등을 하세요.
보관 설정은 법적·비즈니스 요구에 맞춰야 합니다. 정책이 "30일 후 삭제"라면 6개월치를 그냥 보관하지 마세요. 정기적 검토와 감사를 통해 설정을 정렬하세요.
Apache Kafka 운영은 "설치하고 잊어버리기"가 아닙니다. 공유 유틸리티처럼 행동하며 많은 팀이 의존하므로 작은 실수도 하류 앱에 영향을 줍니다.
Kafka 용량 계획은 주기적으로 재검토해야 하는 수학 문제입니다. 주요 요소는 파티션 수(병렬성), 처리량(MB/s in/out), 스토리지 증가(보관 기간)입니다.
트래픽이 두 배가 되면 부하 분산을 위해 더 많은 파티션, 보관을 담을 더 많은 디스크, 복제를 위한 네트워크 여유가 필요할 수 있습니다. 실무 습관은 피크 쓰기율을 예측하고 보관 기간을 곱해 디스크 증가량을 추정한 뒤 복제와 예기치 못한 성공을 위한 버퍼를 더하는 것입니다.
서버를 유지하는 것 외에도 다음과 같은 작업이 필요합니다:
비용은 디스크, 네트워크 아웃(egress), 브로커 수/크기로 결정됩니다. 매니지드 Kafka는 운영 부담을 줄이고 업그레이드를 단순화하지만, 자체 호스팅은 경험 있는 운영팀이 있다면 규모에 따라 더 저렴할 수 있습니다. 트레이드오프는 복구 시간과 온콜 부담입니다.
팀은 보통 다음을 모니터링합니다:
좋은 대시보드와 알림은 Kafka를 "미스테리 박스"에서 이해 가능한 서비스로 바꿉니다.
Kafka는 많은 이벤트를 신뢰성 있게 이동시키고, 일정 기간 보관하며, 여러 시스템이 같은 데이터를 각자 처리해야 하고, 이벤트를 재생할 수 있어야 할 때 강력한 선택입니다. 특히 재생 기능이 중요하거나 향후 생산자/컨슈머가 늘어날 것으로 예상될 때 유용합니다.
다음과 같은 상황에서 Kafka는 탁월합니다:
필요가 단순하면 Kafka는 과잉일 수 있습니다:
이 경우 클러스터 용량 계획, 업그레이드, 모니터링, 온콜 등의 운영 비용이 이점을 넘을 수 있습니다.
Kafka는 데이터베이스(시스템 오브 레코드), 캐시(빠른 읽기), 배치 ETL(대규모 주기적 변환)을 대체하는 것이 아니라 보완합니다.
자문해 보세요:
대부분에 '예'라면 Kafka는 보통 합리적인 선택입니다.
Kafka는 다수의 시스템이 사실(주문 생성, 결제 승인, 재고 변경)을 생산하고 다수의 시스템이 그 사실을 소비해 파이프라인, 분석, 반응형 기능을 구동할 때 가장 잘 맞습니다.
초기에는 좁고 가치 있는 흐름 하나로 시작하세요—예: 다운스트림 서비스(이메일, 사기 검사, 이행)를 위한 OrderPlaced 이벤트 발행. 첫날부터 Kafka를 모든 용도의 큐로 만들지 마세요.
다음 사항을 문서화하세요:
초기 스키마는 단순하고 일관되게 유지하세요(타임스탬프, ID, 명확한 이벤트 이름). 스키마를 초기부터 강제할지, 점진적으로 진화시킬지 결정하세요.
Kafka가 성공하려면 누군가가 책임져야 합니다:
즉시 모니터링(컨슈머 라그, 브로커 헬스, 처리량, 에러율)을 추가하세요. 플랫폼 팀이 없다면 매니지드 제공을 사용하고 명확한 한계를 정하세요.
한 시스템에서 이벤트를 생성하고 한 곳에서 이를 소비해 엔드투엔드 루프를 증명하세요. 그 다음 더 많은 컨슈머, 파티션, 통합으로 확장하세요.
아이디어에서 작동하는 이벤트 기반 서비스로 빠르게 이동하고 싶다면 Koder.ai 같은 도구가 주변 애플리케이션(React UI, Go 백엔드, PostgreSQL)을 프로토타입하는 데 도움을 줄 수 있습니다. 채팅 기반 워크플로로 프로듀서/컨슈머를 빠르게 추가하고 내부 대시보드나 경량 서비스에 유용한 기능(플래닝 모드, 소스 코드 내보내기, 배포/호스팅, 스냅샷 및 롤백)을 제공합니다.
이벤트 기반 접근법 매핑은 /blog/event-driven-architecture를 참고하세요. 비용과 환경 계획은 /pricing을 확인하세요.
Kafka는 내구성 있는 추가 전용 로그에 이벤트를 저장하는 분산 이벤트 스트리밍 플랫폼입니다.
프로듀서는 이벤트를 토픽에 기록하고, 컨슈머는 필요할 때(대개 실시간으로, 때로는 이후에) 이를 독립적으로 읽습니다.
여러 시스템이 같은 이벤트 스트림을 필요로 하고, 느슨한 결합(loose coupling)이 필요하며 이력을 재처리(리플레이)할 가능성이 있다면 Kafka를 사용하세요.
특히 다음 경우에 유용합니다:
토픽은 이벤트의 명명된 범주(예: orders, payments)입니다.
파티션은 토픽을 나눈 단위로서 다음을 가능하게 합니다:
Kafka는 단일 파티션 내부의 순서만 보장합니다.
Kafka는 레코드 키(예: order_id)를 사용해 관련 이벤트를 일관되게 같은 파티션으로 라우팅합니다.
실무 규칙: 특정 엔터티(주문, 고객 등)에 대해 순서를 보장해야 하면 그 엔터티를 대표하는 키를 사용해 해당 이벤트가 한 파티션에 모이도록 하세요.
컨슈머 그룹은 토픽의 처리를 나누어 갖는 컨슈머 인스턴스들의 집합입니다.
그룹 내에서는:
서로 다른 애플리케이션이 동일한 이벤트를 각각 받아야 하면 서로 다른 컨슈머 그룹을 사용해야 합니다.
Kafka는 토픽별 정책에 따라 디스크에 이벤트를 보관하므로 컨슈머가 다운되었다가도 따라잡을 수 있고 히스토리를 재처리할 수 있습니다.
일반적인 보관 방식:
보관 정책은 토픽별로 설정해 감사용 스트림과 고용량 텔레메트리의 보관 기간을 다르게 할 수 있습니다.
로그 컴팩션은 각 키에 대해 최소한 최신 레코드를 보존하고, 오래된 중복 레코드는 제거해 갑니다.
이는 전체 변경 이력보다 각 키의 최신 상태(예: 설정, 프로필)를 유지하려는 토픽에 적합합니다—무한히 커지지 않으면서 최신 상태의 신뢰 가능한 소스를 제공합니다.
일반적인 엔드투엔드 패턴은 at-least-once입니다: 이벤트를 잃지 않지만 중복이 발생할 수 있습니다.
안전하게 처리하려면:
오프셋은 각 파티션에서 컨슈머의 ‘북마크’(위치)입니다.
너무 일찍 커밋하면 크래시 시 작업 손실이 날 수 있고, 너무 늦게 커밋하면 재처리로 중복이 늘어납니다.
운영 관점의 일반적 패턴은 제한된 재시도(백오프) 후 실패 레코드를 데드레터 토픽으로 보내는 것입니다. 이렇게 하면 한 개의 문제 레코드가 전체 컨슈머 그룹을 막지 않습니다.
Kafka Connect는 커넥터(소스와 싱크)를 사용해 Kafka로 데이터를 들여오거나(Kafka로) 내보내는 통합 프레임워크입니다. 맞춤 파이프라인 코드를 줄여줍니다.
Kafka Streams는 애플리케이션에 포함해 스트림을 실시간으로 변환(필터, 조인, 집계 등)하는 라이브러리입니다. Streams 앱은 토픽을 읽고 다시 토픽에 쓸 수 있어 이벤트 기반 시스템에 자연스럽게 맞습니다.
요약: Connect는 통합용, Streams는 계산(스트림 처리)용입니다.