실전 카프카 - 4장 내부 동작 원리와 구현

[ 리플리케이션 ]

안정성을 확보하기 위해 카프카 내부에서는 리플리케이션이라는 동작을 실행합니다.

토픽의 리플리케이션(복제)를 통해 데이터의 유실을 방지하며, 

토픽 생성시 필수로 입력해야 합니다. ( replication-factor 옵션 )

# 토픽 생성
/kafka/bin/kafka-topic.sh --bootstrap-server server1.name.com:9020 \
--create --topic test01 --partitions 1 --replication-factor 3

# 생성된 토픽 정보 확인하여 replication 여부 확인
/kafka/bin/kafka-topic.sh --bootstrap-server server1.name.com:9020 \
--topic test01 --describe

이후 producer로 메세지를 전송 후에,

복제 대상에 해당하는 모든 브로커에 접속해 세그먼트가 복제되는 것을 확인할 수 있습니다.

 

 

[ 리더와 팔로워 ]

- 내부적으로 동일한 리플리케이션들을 리더와 팔로워로 구분합니다.

- 모든 읽기와 쓰기는 리더를 통해서 가능하므로 프로듀서는 리더에게만 메세지를 전달합니다.

- 팔로워들은 리더가 새로운 메세지를 받았는지 확인하고 리더로부터 복제합니다.

 

 

[ 복제 유지와 커밋 ]

- 리더와 팔로워는 ISR(InSyncReplica)라는 논리적 그룹으로 묶여 있습니다.

- 해당 그룹 안에 속한 팔로워들만이 새로운 리더의 자격을 가질 수 있습니다.

- 리더는 팔로워가 리플리케이션을 위해 특정 주기마다 확인 요청하지 않는다면 ISR 그룹에서 추방합니다.

- 리더는 팔로워들이 보내는 리플리케이션의 요청 오프셋을 보고, 팔로워들이 어느 위치까지 복제했는지 파악합니다.

- ACK 통신을 줄이면서(팔로워가 pull하는 방식) 신뢰성은 유지하면서 속도는 높임니다.

 

- ISR의 모든 팔로워가 복제했다면 리더는 커밋표시를 합니다.

- 커밋 메세지만 컨슈머가 읽어 갈 수 있도록하여 데이터의 일관성을 유지합니다.

- 마지막 커밋된 메세지의 오프셋위치를 하이워터마크라 합니다.

- 로컬 로그파일 경로인 replication-offset-checkpoint에서 하이워터마크를 확인할 수 있습니다.

cat /kafka-logs/replication-offset-checkpoint
# output
test01 0 2

 

 

[ 리에더포크와 복구 ]

- LeaderEpoch는 파티션들이 복구 동작을 할 때 일관성 유지를 위한 용도로 사용됩니다. 

 

 

[ 컨트롤러 ]

- 클러스터 중 하나의 브로커가 컨트롤러 역할을 하며, 리더의 선출에 관여합니다.

- 파티션의 ISR 리스트에서 리더를 선출하며, 가용성 보장을 위해 해당 데이터는 주키퍼에 저장됩니다.

- 주키퍼는 카프카 브로커와 주기적으로 Heartbeat 신호를 교환합니다.

- 파티션마다 리더를 선출하므로, 파티션이 많으면 리더 선출 시간이 늘어납니다.

- 제어된 종료일 경우 모든 로그를 디스크에 동기화하므로, 다운타임을 최소화 할 수 있습니다.

 

 

[ 로그 세그먼트 ]

- 로그 세그먼트 최대 크기는 1GB ( 기본값 )

- 세그먼트 크기가 1GB를 넘으면 새로운 세그먼트를 생성하는 롤링(rolling)전략을 적용합니다.

- 로그 세그먼트를 생성할 때 오프셋 시작 번호로 파일이름을 생성합니다. ( ex. 000001.log )

- 로그 세그먼트 컴팩션을 통해 세그먼트 사이즈를 효과적으로 관리하는 정책도 있습니다.