Kafka

이벤트를 토픽의 여러 파티션에 나누어 저장하고 순서대로 읽는 과정을 살펴봅니다.

파티션 내부의 기록 순서는 유지되지만 서로 다른 파티션 사이에는 하나의 전체 순서가 없습니다.

키와 분배 설정이 파티션을 정합니다. 같은 순서로 처리할 이벤트는 같은 키로 묶고, 파티션을 나누어 병렬 처리량을 확보합니다. 보존 중인 이벤트는 여러 그룹이 다시 읽을 수 있습니다.

이벤트 키와 파티션 수를 정하거나 처리량과 순서 보장의 범위를 이해할 때 사용합니다.

컨슈머 그룹이 파티션을 나누어 읽고 처리 위치를 관리하는 과정을 살펴봅니다.

한 그룹에서는 파티션 하나를 한 컨슈머가 맡고, 서로 다른 그룹은 각자의 오프셋을 사용합니다.

컨슈머 수가 바뀌면 리밸런싱으로 파티션을 재할당합니다. 새 담당자는 커밋된 위치에서 이어 읽으며, 마지막 커밋 뒤의 이벤트는 다시 처리될 수 있습니다.

컨슈머 병렬 처리, 장애 복구, 독립적인 서비스가 같은 이벤트를 읽는 구조를 이해할 때 사용합니다.

이벤트 처리와 오프셋 커밋의 순서에 따라 장애 후 결과가 어떻게 달라지는지 비교합니다.

처리 전 커밋은 처리를 놓칠 수 있고, 처리 후 커밋은 중복 처리가 발생할 수 있습니다.

at-least-once 방식에서는 커밋 전에 장애가 나면 완료한 이벤트를 다시 읽을 수 있습니다. 식별자로 중복을 확인하는 등 같은 이벤트가 반복되어도 결과가 중복 반영되지 않도록 설계합니다.

소비 처리의 복구 위치를 정하고 이벤트 유실·중복과 멱등 처리의 관계를 이해할 때 사용합니다.

프로듀서의 acks 설정에 따라 어떤 확인 응답을 기다리는지 비교합니다.

acks=0은 응답을 기다리지 않고, acks=1은 리더의 기록을, acks=all은 현재 ISR의 복제를 확인합니다.

복제 확인을 기다리면 지연이 추가될 수 있지만 리더 장애 시 데이터 보존에 도움이 됩니다. 실제 내구성은 복제 계수와 min.insync.replicas 등의 설정에도 영향을 받습니다.

전송 확인 수준을 정하고 처리 지연과 데이터 내구성을 함께 검토할 때 활용합니다.

리더의 로그를 팔로워에 복제하고 리더 장애 후 처리를 이어가는 과정을 살펴봅니다.

ISR은 리더와 충분히 동기화된 복제본을 관리하는 목록입니다.

복제가 지연된 팔로워는 ISR에서 제외될 수 있습니다. 이 예제는 동기화된 복제본 중 새 리더를 선출해 이미 복제한 레코드를 유지합니다.

복제 지연 감시, 리더 선출, acks와 복제 설정의 관계를 이해할 때 사용합니다.

컨슈머 구성이 바뀔 때 eager와 cooperative 방식의 파티션 재할당을 비교합니다.

eager는 전체 할당을 해제하고, cooperative는 이동이 필요한 파티션을 점진적으로 재할당합니다.

최종 파티션 배치가 같아도 재할당 중 처리 중단 범위는 달라질 수 있습니다. cooperative 방식에서는 담당자가 바뀌지 않는 파티션의 처리를 계속할 수 있습니다.

컨슈머 배포·증설 시 일시적인 처리 중단을 이해하고 리밸런싱 방식을 검토할 때 사용합니다.

같은 키의 최신 레코드를 보관하는 로그 컴팩션 과정을 살펴봅니다.

기존 레코드를 수정하지 않고 변경을 추가한 뒤, 정리 과정에서 오래된 값을 제거합니다.

오프셋은 다시 매기지 않아 정리 후 번호에 간격이 생길 수 있습니다. 삭제는 null 값의 툼스톤으로 표시하며, 실제 정리는 설정과 실행 시점에 따라 진행됩니다.

키별 최신 상태를 복원하는 토픽, 프로필 변경 기록과 상태 저장 구조를 이해할 때 활용합니다.