Til

title: 2026-05-02 author: 강병호 (이름) date: 2026-05-02 (날짜) category: TIL/강병호/2026/05 (파일 경로 : TIL/{이름}/{연}/{월}) layout: post (자유) —

파티션은 카프카 병렬 처리의 핵심 단위입니다. 파티션 개수를 결정할 때는 다음 요소들을 고려해야 합니다.

처리량과 파티션 수: 파티션 하나당 처리할 수 있는 초당 데이터 처리량을 측정하고, 전체 목표 처리량을 이 값으로 나누어 필요한 최소 파티션 수를 산출합니다.

컨슈머 그룹과의 관계: 파티션 수는 해당 토픽을 읽을 컨슈머 그룹 내 최대 컨슈머 개수와 일치시키는 것이 병렬 처리 효율이 가장 좋습니다.

주의사항: 파티션은 한 번 늘리면 다시 줄이는 것이 불가능합니다. 또한 파티션 수가 너무 많으면 브로커의 파일 핸들러 낭비나 장애 복구 시간 증가 등의 부작용이 있으므로 점진적으로 늘리는 것이 권장됩니다.

분산 시스템인 카프카에서 데이터 중복을 방지하고 정확히 한 번(Exactly-once) 처리를 보장하기 위한 메커니즘입니다.

원리: 프로듀서가 메시지를 보낼 때 고유한 PID(Producer ID)와 시퀀스 번호를 함께 보냅니다.

효과: 브로커는 이미 저장된 시퀀스 번호의 메시지가 다시 들어오면 이를 중복으로 판단하여 저장하지 않고 승인(Ack)만 보냅니다. 이를 통해 네트워크 오류로 인한 재시도 시 발생하는 중복 저장을 막습니다.

목적: 여러 토픽에 메시지를 쓰거나, 메시지를 읽고 처리한 후 결과를 쓰는 과정(consume-transform-produce)을 하나의 원자적 단위로 묶습니다.

동작: 모든 메시지가 성공적으로 기록되거나, 하나라도 실패하면 모두 취소(Abort)됩니다. 컨슈머는 isolation.level 설정을 read_committed로 두어 트랜잭션이 완료된 데이터만 읽을 수 있습니다.

카프카는 시간에 따라 오래된 데이터를 삭제하는 것이 기본이지만, 특정 유스케이스에서는 ‘마지막 상태’를 보존해야 할 때가 있습니다.

개념: 동일한 메시지 키를 가진 데이터 중 가장 최신 오프셋의 데이터만 남기고 과거 데이터를 삭제하는 프로세스입니다.

활용: 데이터베이스의 스냅샷 저장, 시스템 설정값 관리 등 현재의 최종 상태가 중요한 경우에 사용됩니다.

데이터 파이프라인 구축 시 매번 프로듀서와 컨슈머 코드를 작성하는 번거로움을 줄여주는 프레임워크입니다.

Source Connect: DB, 파일, AWS S3 등의 데이터를 카프카 토픽으로 가져옵니다. (예: DB의 변경 사항을 실시간으로 카프카에 전송하는 CDC)

Sink Connect: 카프카 토픽의 데이터를 외부 시스템(Elasticsearch, MongoDB, HDFS 등)으로 보냅니다.

장점: 별도의 코딩 없이 설정(JSON 형식)만으로 데이터 이동을 자동화할 수 있으며 확장성이 뛰어납니다.

컨슈머가 메시지를 처리하다가 에러가 발생했을 때 시스템 전체가 멈추지 않도록 하는 설계 패턴입니다.

재시도(Retry): 일시적인 오류라면 지연을 두고 재시도합니다.

분리(DLT): 특정 횟수 이상 실패하거나 로직 오류로 처리가 불가능한 메시지는 별도의 ‘에러 전용 토픽(DLT)’으로 보냅니다.

후속 조치: 메인 로직은 다음 메시지를 계속 처리하고, DLT에 쌓인 메시지는 나중에 원인을 분석하여 수동으로 처리하거나 별도의 로직으로 복구합니다.

results matching ""