[카프카인액션] 6장(1). 브로커 | 주키퍼의 역할 | 데이터 손실

6.1 브로커 소개 

• 카프카에서는 파티션의 레플키리카가 별도의 렉에 물리적으로 존재하도록 하는 랙 어웨어니스 기능이 있다. 
• 자체 카프카 클러스터를 생성할 때는 또다른 클러스터인 어파치 주키퍼를 알고 있어야 한다. 

 

6.2 주키퍼의 역할 

1. 브로커보다 먼저 실행되고 존재해야 한다.
   
   • 브로커 작동방식에 있어 핵심파트이며 카프카를 실행하기 위한 요구사항이기도 하다.
2. 리더 선출 및 클러스터 관리
   • 주키퍼는 클러스터 내에서 특정 브로커를 리더로 선출하는 역할을 수행합니다.
   • 리더가 장애가 발생하면, 주키퍼가 새로운 리더를 선출하여 Kafka 클러스터가 계속 동작할 수 있도록 보장합니다.
3. 최소한의 숫자가 필요함 (쿼럼, Quorum 개념)
   • 주키퍼는 리더를 선출하고 결정을 내리기 위해 최소한의 숫자가 필요하다. 
   • 쿼럼(Quorum): 클러스터에서 결정을 내리기 위해 필요한 최소한의 노드 수.
     • 예) 3개의 주키퍼 노드가 있다면, 2개 이상이 살아있어야 정상 작동함.
     • 5개의 주키퍼 노드라면, 최소 3개 이상이 살아 있어야 함.
4. 메타데이터 저장
   • 주키퍼 자체는 카프카 클러스터의 토픽과 같은 정보를 보유한다.
5. 브로커 간의 코디네이터 역할
   • Kafka 브로커들은 개별적으로 동작하는 것이 아니라, 주키퍼를 통해 서로의 상태를 공유하고 조정한다.
   • 특정 브로커가 장애가 발생하면 주키퍼가 이를 감지하고, 다른 브로커에게 이 사실을 알린다.
   • 새로운 리더를 선출하고, 데이터 복제 등을 수행할 수 있도록 코디네이션 역할을 수행한다.
   • 주키퍼는 할당과 통지를 코디네이트하여 브로커를 돕는다.
6. 프로듀서와 컨슈머 애플리케이션에 직접 노출되지 않음
   • 일반적으로 주키퍼 클러스터의 세부 정보를 프로듀서와 컨슈머 애플리케이션에 노출할 필요가 없다. 
   • 일반적으로 프로듀서(Producer)나 컨슈머(Consumer)는 직접 주키퍼와 통신하지 않습니다.
   • Kafka 클라이언트는 브로커와 직접 통신하며, 주키퍼의 세부 정보는 알 필요가 없습니다.
   • 카프카 설치의 bin 폴더에 있는 zookeeper-shell.sh 카프카 도구를 사용해, 클러스터의 주키퍼 호스트 연결하고 어떤 데이터 저당되어 있는지 볼 수 있다. 

🔹 주키퍼 쉘 접속 방법

bin/zookeeper-shell.sh localhost:2181

• localhost:2181은 주키퍼가 실행 중인 호스트와 포트

🔹 Kafka 브로커 목록 조회

ls /brokers/ids

• 현재 등록된 Kafka 브로커 ID 목록을 출력

🔹 Kafka의 토픽 정보 조회 

ls /brokers/topics

• 생성된 토픽 목록을 확인

🔹 특정 토픽의 메타데이터 확인

get /brokers/topics/my-topic

• my-topic 토픽의 메타데이터를 출력합니다.

 

6.3 브로커 수준의 옵션

https://docs.confluent.io/platform/current/installation/configuration/broker-configs.html

Kafka broker and controller configuration reference for Confluent Platform | Confluent Documentation

 

중요 옵션 (importance = high)

• advertised.listeners - 클라이언트가 브로커에 접속할 때 사용할 호스트/포트 정보 지정.
• auto.create.topics.enable - 서버에서 토픽을 자동으로 생성할지 여부 설정.
• auto.leader.rebalance.enable - 자동 리더 밸런싱을 활성화하여 파티션 리더의 분포를 조정.
• background.threads - 백그라운드 처리 작업에 사용할 스레드 수 설정.
• broker.id - 해당 브로커의 고유한 ID 지정.
• compression.type - 최종 압축 유형을 지정하여 데이터 압축 방식 결정.
• confluent.balancer.consumer.out.max.bytes.per.second - 리더 브로커당 컨슈머의 초당 최대 출력 바이트 수 제한.

 
 

6.3.1  카프카의 다른 로그 : 애플리케이션 로그 

• 애플리케이션 로그가 저장되는 위치가 레코드 로그의 위치와 다르다. 
• 브로커를 시작하면 카프카 기본 설치 디렉터리 아래에 있는 logs/ 폴더에서 애플리케이션 로그 디렉터리를 찾을 수 있다.
• config/log4j.properties 파일에 있는 kafka.logs.dir값을 편집하면 위치를 바꿀 수 있다.

 

6.3.2 서버 로그 

• 서버 로그 파일 server.log 통해서 브로커가 종료하는 시작 오류 또는 예외가 있는지 확인하는 위치이다. 
• 로그는 기본적으로 한 곳으로 집계되지 않고 각 브로커에 있다. 
• ex, logrotate 로그 로테이트 통해 압축해서  splunk 통해 수집 가능 

 

6.3.3 상태 관리 State Management 

• 각 파티션에는 리더 레플리카가 1개씩 있다. 
• 리더 레플리카는 주어진 시간에 단일 브로커에 상주하게 된다. 
• 브로커는 여러 파티션의 리더 레플리카를 호스팅할 수 있고 클러스터의 모든 브로커는 리더 레플리카를 호스팅할 수 있다. 
• 그러나 클러스터에서 하나의 브로커만 컨트롤러 역할(클러스터 관리, 파티션 재할당 작업 수행)을 수행한다. 
  • 클러스터의 롤링 업그레이드, 한 번에 하나의 브로커 종료 및 재시작을 고려할 때는 컨트롤러를 마지막에 수행하는 것이 가장 좋음. 

 

6.4 파티션 리더 레플리카와 그 역할 

들어가기전에  (2장 복습) 

• 토픽은 파티션으로 구성되며 파티션은 내결함성을 위해 레플리카를 가질 수 있다.
• 파티션은 또한 카프카 브로커의 디스크에 기록된다..
• 파티션의 레플리카 중 하나가 리더 역할을 한다.
• 리더는 해당 파티션에 대한 외부 프로듀서 클라이언트의 쓰기 처리를 담당한다. 
• 리더는 새로 쓰인 데이터가 있는 유일한 레플리카이기 때문에 팔로워 레플리카의 소스 데이터 역할도 한다. 
• ISR 목록은 리더에 의해 유지 관리되기 때문에, 어떤 레플리카가 최신 상태이고 모든 현재 메시지를 보았는지도 알고 있다. 
• 팔로워 레플리카는 리더 파티션의 컨슈머 역할을 하며 메시지를 가져온다. 

[카프카인액션] 2장. 레코드 | 브로커 | 프로듀서 | 컨슈머 | 주키퍼 | 커밋 로그 | 카프카 스트림즈

 
 
 

• 브로커3이 리더이고 브로커2와 브로커1이 팔로워인 3-노드 클러스터 
• ISR 목록 [3,2,1] 에는 첫번째 위치의 리더(브로커3)와 리더의 메시지 사본을 최신 상태로 유지하는 나머지 팔로워(브로커1과 브로커2)가 포함된다. 

• 경우에 따라서는 실패한 브로커가 파티션의 리더 레플리카를 호스팅할 수도 있다. 
• 브로커3을 사용할 수 없으므로 새 리더가 선출된다. 새로운 리더 브로커 2를 보여준다. 
• ISR 목록은 이제 브로커2에서 호스팅되는 새 리더 레플리카를 반영하는 [2,1] 위치에 있다. 

 

---

• 카프카에서 주목해야 할 것 중 하나를 레플리카가 기본적으로 자체 복구되지 않는다는 것.
• 파티션 사본 중 하나가 존재하는 브로커를 잃어버리면 카프카는 새 사본을 생성하지 않는다.
• 우리 시스템의 상태를 모니터링할 때 살펴봐야 할 중요한 항목은 얼마나 많은 ISR이 실제로 우리가 원하는 수와 일치하는 지이다.  
  
  • ISR이 줄어들면, 리더만 데이터를 가지고 있고 팔로워들이 복제되지 않는 상태가 됩니다.
  • 만약 리더가 장애가 발생하면 최신 데이터가 유실될 가능성이 있음.
• 레플리카가 리더에서 메시지를 복사하는 데 너무 뒤쳐지기 시작하면 ISR 목록에서 제거될 수 있다는 점에 유의해야 한다. 

 
 

6.4.1 데이터 손실 

• ISR이 없고 장애로 인해 리더 레플리카가 손실되면 어떻게 될까 ?
  • unclean.leader.election.enable 값이 true이면 컨트롤러는 레플리카가 최신이 아니더라도 시스템이 계속 실행되도록 파티션의 리더를 선택한다 
    • 데이터가 손실될 수 있다. 
    • 이 옵션을 사용하면 손실된 데이터에 대한 비용을 감수하는 대신 클라이언트는 계속 서비스를 제공받을 수 있다. 

 
 
https://www.lostcatbox.com/2022/12/24/AboutKafka/

AboutKafka · lostcatbox