Oh My Algorithm
🪵인프라·DevOps

Kafka 알고리즘

append-only 로그로 흘려보내는 이벤트 스트림. 아래 7개 항목을 인터랙티브 시각화로 단계별로 학습해 보세요.

🪵토픽과 파티션 (Topic & Partition)

카프카의 토픽은 큐가 아니라 덧붙이기만 하는 로그입니다. 토픽은 여러 파티션으로 쪼개지고, 레코드는 파티션 끝에 append 되며 그 자리에 오프셋이라는 번호가 붙습니다. 파티션이 여러 개라서 병렬로 쓰고 읽을 수 있지만, 순서가 보장되는 범위는 토픽 전체가 아니라 파티션 하나 안쪽입니다. 같은 키를 가진 레코드가 늘 같은 파티션으로 가는 이유가 여기 있습니다.

Append-only Log · 순서 보장
🪵컨슈머 그룹 (Consumer Group)

컨슈머 그룹은 여러 컨슈머가 한 토픽을 나눠 읽는 단위입니다. 파티션 하나는 그룹 안에서 정확히 컨슈머 하나에게만 배정되므로, 컨슈머를 늘리면 처리량이 올라가지만 파티션 수를 넘어서면 남는 컨슈머는 놀게 됩니다. 각 컨슈머는 자기가 맡은 파티션의 오프셋을 커밋하고, 그룹이 다르면 같은 데이터를 서로 독립적으로 읽습니다.

파티션 배정 · 병렬 소비
🪵메시지를 잃지 않으려면 (Delivery Guarantees)

어디까지 읽었는지 기록하는 시점을 언제로 잡느냐가 유실과 중복을 가릅니다. 처리하기 전에 먼저 기록하면 중간에 죽었을 때 그 메시지를 다시는 읽지 못하고(at-most-once), 처리한 뒤에 기록하면 죽었을 때 같은 메시지를 한 번 더 읽습니다(at-least-once). 카프카는 대개 후자를 택하고, 중복을 견디도록 처리 쪽을 멱등하게 만듭니다.

at-least-once · at-most-once
🪵프로듀서와 acks (Producer & acks)

프로듀서는 보낸 메시지가 어디까지 저장됐을 때 '성공'으로 칠지 고를 수 있습니다. acks=0 은 응답을 기다리지 않아 가장 빠르지만 브로커가 받았는지도 모르고, acks=1 은 리더만 저장하면 성공이라 리더가 죽으면 잃을 수 있으며, acks=all 은 복제본까지 저장돼야 성공이라 가장 안전하고 가장 느립니다.

acks=0/1/all · 내구성
🪵복제와 ISR (Replication & ISR)

파티션마다 리더 하나와 팔로워 몇 개가 있고, 읽고 쓰는 것은 리더가 전담합니다. 팔로워는 리더를 따라 복사하며, 충분히 따라잡은 복제본들의 목록을 ISR이라고 부릅니다. 리더가 죽으면 ISR 안에서 새 리더가 뽑히므로, ISR에 남아 있는지가 곧 '이 복제본으로 승격해도 안전한가'를 뜻합니다.

리더·팔로워 · ISR
🪵리밸런싱은 왜 멈추나 (Rebalancing)

컨슈머가 들어오거나 나가면 파티션 배정을 다시 계산해야 합니다. 예전 방식(eager)은 모든 컨슈머가 맡은 것을 일단 전부 반납한 뒤 다시 나눠 갖기 때문에, 바뀔 필요가 없던 파티션까지 그 사이 멈춥니다. cooperative 방식은 옮겨야 할 것만 반납해 나머지는 계속 읽습니다.

eager · cooperative
🪵로그 컴팩션 (Log Compaction)

보존 기간이 지나면 오래된 것부터 지우는 것이 기본이지만, 어떤 토픽은 '지금 상태'가 필요합니다. 로그 컴팩션은 같은 키의 오래된 레코드를 지우고 마지막 값만 남겨, 로그가 곧 최신 스냅샷이 되게 합니다. 처음부터 읽으면 모든 키의 현재 값을 복원할 수 있습니다.

키별 최신값 · 스냅샷