이 글은 카프카, 데이터 플랫폼의 최강자 고승범/공용준 님의 책을 공부하며
정리하는 글입니다.

[Kafka]카프카의 특징-2

리플리케이션, 리더, 팔로워, 지노드에 대해서 상세히 알아보자

리플리케이션

• 리플리케이션: 토픽 자체를 리플리케이션(복제)하는 것이 아니라, 토픽을 이루는 각각의 파티션을 리플리케이션 한다.
• 리플리케이션 팩터: 기본값은 1
• 리더와 팔로워: 리플리케이션 된 것 중 하나는 리더, 하나는 팔로워
• 리더: 읽기 쓰기에 모두 관여(실제로 리더만 행하는 동작이다)
• 팔로워: 리플리케이션 된 것만 가지고 있다. 리더에 문제가 생기면 팔로워가 읽기, 쓰기를 대신한다. 즉 리더를 포함하는 파티션이나 브로커가 죽었을 때)
• 리플리케이션을 사용하는 경우는 토픽을 가진 브로커가 죽었을 때를 대비해서 사용하는데 목적이 있다.

리플리케이션 적용해보기

• $ vi /home/호스트명/kafka/config/server.properties

default.replication.factor=2 #항목이 없다면 맨 아래 코드를 추가하자(난 없었다)
클러스터 내 모든 브로커에 동일하게 설정하기  
1대씩 재시작하기(카프카가 띄워져 있다면)  

• 주키퍼/카프카가 안띄워져 있다면 주키퍼 카프카를 실행합니다.
• 토픽 생성하기(브로커 한대에서 하세요)

$ /home/shalee729/kafka/bin/kafka-topics.sh \
--zookeeper zookeeper-01:2181,zookeeper-02:2181,zookeeper-03:2181/shalee729-kafka \
--topic peter --partitions 1 --replication-factor 2 --create
Created topic "peter".

생성한 peter 토픽의 리더와 팔로워를 확인하자

$ /home/shalee729/kafka/bin/kafka-topics.sh \
--zookeeper zookeeper-01:2181,zookeeper-02:2181,zookeeper-03:2181/shalee729-kafka \
--topic peter --describe

• describe 옵션을 사용하면 아래와 같이 정보를 알 수 있습니다.

• 출력내용 해석
  • Leader: 1 은 ‘peter 토픽의 0번 파티션 리더’가 1번 브로커에 있다.
  • Relicas: 1,3 은 peter 토픽이 리플리케이션 되고 있으며, 브로커1과 브로커3에 위치하고 있다.
  • 결과적으로 Replication 값을 2를 주었으므로 두 곳에 복제되었고, 1번은 리더이고 3번이 팔로워가 된다.
• 그래서 어떻게 진행되는데? 만약에 리더가 다운이 된다면?
  • 프로듀서는 peter 토픽으로 요청 -> 브로커1의 peter 토픽이 해당 요청에 응답하는 형식으로 진행
  • 1번 브로커(리더를 가진)가 다운이 된다면, 3번이 리더역할을 하게되면서 프로듀서가 메시지를 끊김없이 보낼 수 있다.
  • 그래서 카프카에서는 ISR이라는 그룹을 만들어 리플리케이션 그룹으로 관리된다
  • ISR은 peter란 토픽이 1(리더), 3(팔로워)에 구성됐다면 peter ISR 그룹은 1,3이 되며 리더가 다운으로인해 읽기, 쓰기를 못 할 경우에 자동으로 ISR 그룹 내 팔로워가 리더로 승격되서 서비스를 유지하는 리플리케이션의 신뢰성을 높이고 있다.
  • ISR 그룹 내 권한은 리더가 기본적으로 가지고 있다.

리플리케이션을 사용한다면 저장소 크기와 수를 고민해라

• 만약 토픽의 데이터가 1GB이라면 리플리케이션팩터를 3으로 준다면 총 3GB가 필요하다
• 브로커를 3대를 돌린다면 각각 1G + 1G + 1G >= 3G 가 필요하다
• 리플리케이션이 많아지면 리소스를 잡아먹게되며, 따라서 토픽(데이터)의 중요도에 따라서 2 또는 3으로 관리해라.

모든 브로커가 다운되는 상황이라면 p123

• (1)마지막 리더가 살아나기를 기다린다
  • 리더와 팔로워가 죽은 상황에서 리더가 살아날 때까지 기다린다
  • 운이 나쁘면 서비스가 재시동 되는데 오래걸리지만 서비스가 유지되는 동안은 메시지 유실율을 최소화 할 수 있다.
• (2)어떠한 하나의 브로커가 살아난다면 리더로 승격시킨다
  • a(리더) b(팔로워) c(팔로워) 에서 c가 먼저 죽고 a, b가 죽은 상황이다
  • c가 빠르게 살아나서 리더로 승격된다면 문제점이 있다
  • c가 죽은 이후로 a, b 가 서비스되는 동안 저장된 메시지를 유실된다.
  • 그렇지만 빠르게 서비스를 정상화하는데 좋다

$ vi /home/호스트명/kafka/config/server.properties
unclean.leader.election.enable = false # (1)마지막 리더를 기다린다.
unclean.leader.election.enable = true  # (2)메시지 손실을 감소하고 살아난 브로커를 리더로 승격한다.

토픽, 리플리케이션 팩터, 카프카 클러스터 한눈에 정리

주키퍼 지노드(znode) 역할

• 현재 나는 지노드를 shalee729-kafka 로 지정한 상태
• $ /home/shalee729/kafka/bin/zkCli.sh
• 아래는 지노드 접속 후

[zk: localhost:2181(CONNECTED) 0] ls /
[zookeeper, shalee729-kafka]
[zk: localhost:2181(CONNECTED) 1] ls /shalee729-kafka
[cluster, controller_epoch, controller, brokers, admin, isr_change_notification, consumers, log_dir_event_notification, latest_producer_id_block, config]

• 아래는 지노드 중 중요한 몇 가지만 나타낸 것
  (/peter-kafka 를 /shalee729-kafka 로 생각)

• /shalee729-kafka/controller
  • 현재 카프카 클러스터의 컨트롤러 정보를 확인
  • 컨트롤러는 모든파티션의 리더 변경을 책임진다.
  • 만약 컨트롤러인 브로커가 다운된다면, 남아 있는 브로커 중 하나가 새로운 컨트롤러가 된다.
• /shalee729-kafka/brokers/*
  • broker.id 를 확인할 수 있다.(/ids)
  • 토픽의 파티션 수, ISR 구성 정보, 리더 정보 등 토픽관련 정보를 확인할 수 있다(/topics/)
• /shalee729-kafka/consummers
  • 컨슈머 관련 정보가 저장된다. 컨슈머가 각 파티션들에 대해서 어디까지 읽었는지에 대한 오프셋 정보가 저장된다.
  • 향후 컨슈머 주키퍼에 오프셋을 저장하는 방법은 서비스가 종료.(0.9버전 카프카에서 토픽의 저장으로 변경 및 권장)
• /shalee729-kafka/config
  • 토픽의 상세 설정 정보를 알 수 있다.

참고: 카프카, 데이터 플랫폼의 최강자

용어정리
주키퍼의 영구 지노드: delete를 호출하여 삭제가능
주키퍼의 임시 지노드: 클라이언트의 연결이 끊어지거나 장애가 발생하면 삭제된다.