Kafka 파티션 로그, 오프셋, 보존과 소비자 커밋

Apache Kafka 토픽은 하나 이상의 파티션으로 나뉘며, 각 파티션은 순서가 있는 로그입니다. 레코드 순서는 파티션 안에서만 정의되고 서로 다른 파티션 사이에는 전역 순서가 없습니다. 키는 보통 같은 키의 레코드를 같은 파티션으로 보내는 데 사용되지만, 파티션 수나 파티셔너 변경은 매핑과 순서 기대에 영향을 줄 수 있습니다. 오프셋은 파티션 로그의 위치를 나타냅니다. 로그 정리·압축 후 특정 오프셋의 레코드가 사라질 수 있어, 오프셋은 현재 레코드의 영구 ID라고 부르기보다 소비 위치로 이해해야 합니다.

전문가 관점: Kafka는 소비 후 삭제되는 큐와 다른 보존 로그

Kafka 초기 개발자이자 Confluent 공동창업자 Jay Kreps는 Kafka에 데이터를 장기간 저장하는 설계가 가능하다고 설명하며, 디스크 로그와 복제, 이벤트 소싱·재생 활용을 논합니다. 이는 제품 개발자의 아키텍처 관점입니다. 실제 보존은 무기한이 기본이 아니며 토픽의 시간·크기 기반 retention, compact 정책, 복제 설정, 디스크와 운영 한도에 좌우됩니다. 로그 압축은 키별 최신 상태를 남기는 비동기 정리이며, 모든 과거 이벤트를 보존하는 백업과 같지 않습니다. tombstone도 delete.retention.ms가 지난 뒤 제거될 수 있습니다.

내구성은 producer와 브로커 설정에 달림

“Kafka가 레코드를 무손실로 처리한다”는 일반 보장은 성립하지 않습니다. 전송 재시도, acks, 복제 계수, ISR 최소값, 리더 선출 정책, 저장장치의 동작을 함께 보아야 합니다. acks=0, 리더 확인만 받는 설정, 모든 동기 복제본 확인 등은 서로 다른 실패 허용 범위를 가집니다. 성공 응답이 무엇을 의미하는지 설정과 장애 모델로 설명해야 합니다. 소비자가 읽은 레코드의 처리를 마치기 전에 오프셋을 먼저 커밋하면 장애 시 작업이 누락될 수 있고, 처리 후 커밋하면 중복 처리가 가능하므로 일반적인 소비 패턴은 자동으로 exactly-once가 되지 않습니다.

병렬 처리·순서·재처리의 경계

한 소비자 그룹에서는 일반적으로 파티션이 소비자에 할당되어 파티션 단위 병렬성이 생깁니다. 소비자 수가 파티션 수보다 많아도 여분 소비자는 해당 그룹에서 할당받을 파티션이 없습니다. 같은 파티션 내 처리 순서를 보존하려면 비동기 작업의 완료 순서와 커밋 위치도 관리해야 합니다. 재처리는 retention이 남아 있는 위치에서 가능하지만, 애플리케이션의 외부 부작용은 Kafka 오프셋과 하나의 원자 작업이 아닐 수 있습니다. Kafka 트랜잭션은 Kafka 안의 입력 오프셋과 출력 레코드 처리에 활용할 수 있으나 외부 DB·결제 시스템까지 자동으로 원자화하지 않습니다. 운영 설계에서는 보존 기간, 복제 및 커밋 모드, 지연·디스크 경보, 재처리 절차를 함께 정하세요.

참고 자료