Maru's Study Memo

Replication of Partition: 장애를 대비하기 위한 기술

Producer/Consumer는 Leader와만 통신: follower는 복제만

Producer는 Leader만 Write하고 Consumer는 Leader로부터만 Read함
Follower는 Broker 장애시 안정성을 제공하기 위해서만 존재

Follower는 Leader의 Commit Log에서 데이터를 가져오기 위해 요청(Fetch Request)으로 복제

Leader 장애 -> 새로운 Leader를 선출

Kafka 클러스터는 Follower 중에서 새로운 Leader를 선출
Client(Producer/Consumer)는 자동으로 새 Leader로 전환

Partition Leader에 대한 자동 분산: Hot Spot 방지

auto.leader.rebalance.enable: 기본값 enable
leader.imbalance.check.interval.seconds: 기본값 300 sec
. 300초마다 leader 분산에 불균형 여부 check
leader.imbalnce.per.broker.percentage: 기본값 10
. 다른 브로커보다 10% 이상 더 많이 가져가면 불균형으로 판단

Rack Awareness: Rack간 분산하여 Rack 장애를 대비

동일한 Rack 혹은 Available Zone상의 Broker들에 동일한 "rack name" 지정
복제본(Replica-Leader/Follower)은 최대한 Rack 간에 균형을 유지하여 Rack 장애 대비
Topic 생성시 또는 Auto Data Balancer/Self Balancing Cluster 동작 때만 실행

Consuming from Kafka: Partition으로부터 Record를 가져옴(Poll)

Consumer는 각각 고유의 속도로 Commit Log로부터 순서대로 Read(Poll)를 수행

다른 Consumer Group에 속한 Consumer들은 서로 관련이 없으며, Commit Log에 있는 Event(Message)를 동시에 다른 위치에서 Read할 수 있음

Consumer Offset: Consumer Group이 읽은 위치를 표시

Consumer가 자동이나 수동으로 데이터를 읽은 위치를 commit하여 다시 읽음을 방지

__consumer_offsets라는 Internal Topic에서 Consumer Offset을 저장하여 관리

Consuming as a Group: 동일한 group.id로 구성된 모든 Consumer들은 하나의 Consumer Group을 형성

Partition응 항상 Consumer Group 내의 하나의 Consumer에 의해서만 사용됨

Consumer는 주어진 Topic에서 0개 이상의 많은 Partition을 사용할 수 있음

Consumer Group의 Consumer들은 작업량을 어느 정도 균등하게 분할함

동일한 Topic에서 consume하는 여러 Consumer Group이 있을 수 있음

Message Ordering(순서): Key를 사용하여 Partition별 메시지 순서 보장

동일한 Key를 가진 메시지는 동일한 Partition에만 전달되어 Key 레벨의 순서 보장 가능
. 멀티 Partition 사용 -> 처리량 증가

. 운영 중에 Partition 개수를 변경하면? 순서 보장 불가

Record(Message) 구조: Header, Key, Value

Key와 Value는 Avro, Json 등 다양한 형태가 가능

Serializer/Deserializer

Kafka는 Record(데이터)를 Byte Array로 저장

Key와 Value용 Serializer를 각각 설정

Producing to Kafka: High-Level Architecture

Partitioner의 역할: 메시지를 Topic의 어떤 Partition으로 보낼지 결정

Kafka Broker: Topic과 Partition을 유지 및 관리

Kafka Broker는 Partition에 대한 Read 및 Write를 관리하는 소프트웨어
. Kafka Server라고 부르기도 함
. Topic 내의 Partition들을 분산, 유지 및 관리
. 각각의 Broker들은 ID로 식별됨(ID는 숫자)
. Topic의 일부 Partition들을 포함 -> Topic 데이터의 일부분(Partition)을 갖을 뿐 데이터 전체를 갖고 있지 않음
. Kafka Cluster: 여러 대의 Broker들로 구성됨
. Client는 특정  Broker에 연결하면 전체 클러스터에 연결됨
. 최소 3대 이상의 Broker를 하나의 Cluster로 구성해야 함 -> 4대 이상을 권장함

Zookeeper: Broker를 관리

Zookeeper는 Broker를 관리 (Broker 들의 목록/설정을 관리)하는 소프트웨어

. 변경사항에 대해 Kafka에게 알림: 토픽 생성/제거, Broker 추가/제거 등

. Zookeeper는 홀수의 서버로 작동하게 설계되어 있음(최소 3, 권장 5)

. Zookeeper에는 Leader(writes)가 있고 나머지 서버는 Follower(reads)

Zookeeper 아키텍쳐: Leader/Follower 기반 Mater/Slave 아키텍쳐

Zookeeper는 분산형 Configuration 정보 유지, 분산 동기화 서비스를 제공하고 
대용량 분산 시스템을 위한 네이밍 레지스트리를 제공하는 소프트웨어

분산 작업을 제어하기 위한 Tree 형태의 저장소
-> Zookeeper를 사용하여 멀티 Kafka Broker들 간의 정보(변경 사항 포함) 공유, 동기화 등을 수행

. 변경사항에 대해 Kafka에게 알림: 토픽 생성/제거, Broker 추가/제거 등

. Zookeeper는 홀수의 서버로 작동하게 설계되어 있음(최소 3, 권장 5)

. Zookeeper에는 Leader(writes)가 있고 나머지 서버는 Follower(reads)

Zookeeper Failover: Quorum 알고리즘 기반

Quorum(쿼럼)은 "정족수"이며, 합의체가 의사를 진행시키거나 의결을 하는데 필요한 최소 인원을 뜻함

분산 코디네이션 환경에서 예상치 못한 장애가 발생해도 분산 시스템의 일관성을 유지시키기 위해서 사용

Apache Kafka Clients

Producer: 메시지를 생산해서 Kafka의 Topic으로 메시지를 보내는 애플리케이션

Consumer: Topic의 메시지를 가져와서 소비하는 애플리케이션

Consumer Group: Topic의 메시지를 사용하기 위해 협력하는 Consumer들의 집합

. 하나의 Consumer는 하나의 Consumer Group에 포함되며,
  Consumer Group 내의 Consumer들은 협력하여 Topic의 메시지를 분산 병렬 처리함

Producer와 Consumer의 분리(Decoupling)

. Producer와 Consumer는 서로 알지 못하며, 각각 고유의 속도로 Commit Log에 Write 및 Read를 수행

. 다른 Consumer Group에 속한 Consumer들은 서로 관련이 없으며, Commit Log에 있는 Event를 동시에 다른 위치에서 Read할 수 있음

Kafka Commit Log

Commit Log

. 추가만 가능하고 변경 불가능한 데이터 스트럭쳐

Offset
. Commit Log에서 Event의 위치

Kafka Offset: Commit Log에서 Event의 위치

Producer가 Write하는 LOG-END-OFFSET과 Consumer Group의 Consumer가 Read하고 처리한 후에 Commit한 CURRENT-OFFSET과의 차이(Consumer Lag)가 발생할 수 있음

Topic, Partition, Segment: Logical View

Topic: Kafka 안에서 메시지가 저장되는 장소, 논리적인 표현

Partition
. Commit Log, 하나의 Topic은 하나 이상의 Partition으로 구성
. 병렬 처리(Throughput 향상)를 위해서 다수의 Partition을 사용

Segment
. 메시지(데이터)가 저장되는 실제 물리 File

. Segment File이 지저된 크기보다 크거나 지정된 기간보다 오래되면 새 파일이 열리고 메시지는 새 파일에 추가됨

Topic, Partition, Segment: Physical View

Topic 생성 시 Partition 개수를 지정하고, 각 Partition은 Broker들에 분산되며 Segment File들로 구성됨
Rolling Strategy: 특정 용량이나 시간에 따라 Segment 파일을 분리 
. log.segment.bytes(default 1GB)
. log.roll.hours(default 168 hours)

Active Segment: Partition당 하나의 Active Segment

Partition당 오직 하나의 Segment가 활성화(Active) 되어 있음
-> 데이터가 계속 쓰여지고 있는 중

Topic, Partition, Segment의 특징

Topic 생성 시 Partition 개수를 지정 - 개수 변경 가능하나 운영 시에는 변경 권장하지 않음

Partition 번호는 0부터 시작하고 오름차순

Topic 내의 Partition들은 서로 독립적임

Event(Message)의 위치를 나타내는 Offset 이 존재

Offset은 하나의 Partition에서만 의미를 가짐 - Partition 0 의 offset 1은 Partition 1의 offset 1과 연관 없음

Offset값은 계속 증가하고 0으로 돌아가지 않음

Event(Message)의 순서는 하나의 Partition 내에서만 보장

Partition에 저장된 데이터(Message)는 변경이 불가능(Immutable)

Partition에 Write되는 데이터는 맨 끝에 추가되어 저장됨

Partition은 Segment File들로 구성됨 - Rolling 정책: log.segment.bytes, log.roll.hours

Kafka 설정

brocker id : 브로커 인스턴스마다 고유한 값을 가짐

linteners : 브로커에서 참조하는 엔드포인트

advertised.listeners
. 컨슈머/프로듀서에서 참조하는 엔드포인트

. 설정하지 않으면 linteners에 설정된 기본값 적용

** linteners/advertised.listeners가 따로 있는 이유? 내부와 외부 트래픽을 나누기 위해
  . 예를 들어 replication 트래픽은 client의 트래픽을 방해해선 안되기 때문에

  . 외부 트래픽은 프록시나 로드밸런서를 타고 올 텐데, 내부 트래픽은 성능 이점 때문에 직접 브로커로 붙어도 괜찮다

  . 외부 트래픽은 SSL을 적용, 내부 트래픽은 SSL을 미적용할 수 있음

num.network.threads

. 서버가 요청을 받거나 응답을 내보내는 스레드

num.io.threads
. 서버가 클라이언트의 Disk I/O같은 요청을 처리하는 스레드

socket.send.buffer.bytes

socket.receive.buffer.bytes

. 소켓 사이즈를 바이트 단위로 설정 가능

===================================================================

log.dirs
. 브로커가 데이터를 저장하는 디렉토리

num.partitions

. 파티션 개수를 지정하지 않았을 때 기본적으로 사용되는 파티션 수===================================================================

log.flush.interval.messages

. 데이터를 디스크에 쓰기 전에 몇 개 까지의 메시지를 가지고 있을 것인지 설정하는 옵션

log.flust.interval.ms

. 플러시를 하기 전에 얼마까지 적재를 할 지 시간으로 설정 (n초마다 flush)
===================================================================

log.flush.interval.ms

. 리텐션 policy에 따라서 삭제할 수 있는지 여부를 확인하기 위해 log segment를 확인하는 간격
===================================================================

auto.create.topics.enable

compression.type
. 프로듀서가 해당 타입으로 메시지를 압축해서 전송, 브로커가 그대로 디스크에 저장하고 컨슈머가 압축한 상태로 consume

delete.topic.enable

. topic을 삭제하는 것을 활성화

message.max.bytes

. 메시지 payloads 제한

replica.lag.time.max.ms

. follower가 leader한테 이 시간동안 fetch request를 보내지 않는다면, 그리고 leader의 log를 다 소모하지 않았다면

  leader는 ISR에서 해당 follower를 제거

Kafka의 종류

Apache Kafka
  . 오픈 소스, 자유롭게 수정과 배포 가능

Confluent Kafka
  . Community License: 소프트웨어 수정, 재배포 가능하지만 Saas 형태로 서비스 제공하는 것은 금지됨
  . Enterprise License: 연간 구독형

데이터 파이프라인(Data Pipeline)이란?

중간에 사람의 개입 없이
데이터를 오염, 중복, 유실과 같은 결함 없이
수집, 저장, ETL(Extract, Transform, Load)이 가능하도록
일련의 흐름을 만들어 주는 과정

Event는 비즈니스에서 일어나는 모든 일(데이터)를 의미

. 웹사이트에서 무언가를 클릭하는 것

. 청구서 발행

. 송금

. 배송 물건의 위치 정보

. 택시의 GPS 좌표

. 센서의 온도/압력 데이터

Event Stream은 연속적인 많은 이벤트들의 흐름

. BigData의 특징을 가짐

. 비즈니스의 모든 영역에서 광범위하게 발생

. 대용량의 데이터(Big Data 발생)

Apache Kafka의 3가지 주요 특징

. 이벤트 스트림을 안전하게 전송: Publish & Subscribe

. 이벤트 스트림을 디스크에 저장: Write to Disk

. 이벤트 스트림을 분석 및 처리: Processing & Analysis

Apache Kafka의 사용 사례: Event(메시지/데이터)가 사용되는 모든 곳

. Messaging Syetem
. IOT 디바이스로부터 데이터 수집
. 애플리케이션에서 발생하는 로그 수집
. Realtime Event Stream Processing (Fraud Detection, 이상 감지 등)
. DB 동기화(MSA 기반의 분리된 DB간 동기화)
. 실시간 ETL(Extract-Transform-Loda)
. Spark, Flink, Strom, Hadoop과 같은 빅데이터 기술과 같이 사용

요약

. Apache Kafka는 흐르는 데이터를 처리하기 위한 플랫폼(Event-Streaming Platform)

[우선  프로듀서의 idempotence에 대해 알아보자]

** 멱등성(idempotence)
  . 멱등성이란 연산을 여러번 적용하더라도 결과가 달라지지 않는 것.
  . REST API를 예로 들자면 get, put, delete는 멱등성을 가지고 있지만, post는 상태를 변경하기 때문에 멱등성이 없다.

** 카프카에서 멱등성 프로듀서란?
프로듀서가 동일한 데이터를 여러번 보내더라도 브로커 단위에서 1번만 적재하는 것.
  . 프로듀서는 retry 로직에 의해서 동일 ProducerRecord가 브로커에 여러 번 적재될 가능성이 있음

  . 프로듀서는 ProducerRecord를 전송할 때 데이터에 숫자(Sequence)와
    PID(프로듀서 번호)를 보냄으로서 브로커가 중복 처리

[멱등성 프로듀서]

멱등성 프로듀서로 동작하지 않는 기본 프로듀서는 send() 이후에 데이터에 대한 적재 응답을 제대로 못받았을 경우에는 데이터를 다시 보내게 됩니다. 이것은 retry 로직의 자연스러운 데이터 처리 방법인데, 카프카는 기본 옵션으로 사용했을 때 "at least once" 즉 적어도 한 번 이상 데이터를 보내는 로직으로 되어 있기 때문입니다. 이 방식은 데이터를 유실 없이 안정적으로 처리하지만, 중복해서 데이터를 처리할 가능성이 있습니다.

동일한 레코드가 여러 번 들어가는 것을 원치 않을때는 멱등성 프로듀서를 사용하면 됩니다.
브로커는 PID와 Sequence 번호를 토대로 데이터가 중복되어 전송되지 않았는지 확인합니다.

[멱등성 프로듀서의 설정과 장/단점]

** 설정 방법
  . ENABLE_IDEMPOTENCE_CONFIG = true

** 장점
  . 프로듀서와 브로커 사이의 데이터 전송에 있어 레코드가 딱 한번만 적재됨을 보장
  . 딱 한번만 적재(Exactly-once)되므로 데이터 유실이나 중복이 발생하면 안되는 곳에서는 반드시 이 옵션을 켜야 함

** 단점
  . 브로커는 PID(프로듀스 아이디)와 레코드 시퀀스넘버를 가지고 있으면서 계속 모니터링하므로 브로커에 부하가 발생하므로(= 데이터의 처리속도가 느려질 수 있음, 데이터의 처리량이 낮아질 수 있음) 브로커의 CPU나 메모리 사용량을 고려해야 함
  . 프로듀서의 장애애 의해서 프로듀서가 재시작 되는 경우에는 PID가 달라지므로 이에 대한 대응책이 필요함

[트랜잭션이란?]

** 데이터베이스의 상태를 변환시키는 하나의 논리적인 기능을 수행하는 작업의 단위 또는 일련의 연산
  . 커밋, 롤백을 통해 논리적인 수행 단위를 완료 또는 복구 가능

** 카프카에 트랜잭션이란?
  . 여러 파티션에 데이터를 atomic(원자성)하게 보내는 것
  . 여러 작업 단위를 여러 토픽에 보낼 경우 논리적으로 수행한 단위가 완료되었음을 begin과 commit으로 지정할 수 있다.

카프카에서는 스트림 데이터 처리에 있어 트랜잭션 개념을 추가하였습니다.
즉 카프카에서 트랜잭션이란 스트림 트랜잭션에 가깝습니다.

트랜잭션 프로듀서는 beginTransaction()을 호출해서 원자 단위로 묶을 레코드들이 이제 전송된다는 것을 선언합니다. 그리고 트랜잭션 컨슈머는 트랜잭션이 시작된 데이터에 대해서 즉시 가져가지는 않습니다. 왜냐하면 커밋이 되어서 원자 단위로 트랜잭션이 끝나지 않았기 때문입니다.

트랜잭션 프로듀서는 하나의 트랜잭션으로 묶일 레코드를 모두 보내고 난 이후에 commitTransaction()을 호출해서 트랜잭션이 끝났음을 알립니다. 이후 트랜잭션 컨슈머는 커밋이 완료된 데이터를 가져가서 처리하게 됩니다.

스트림데이터에서 트랜잭션이란 여러 레코드를 하나의 단위로 묶어서 처리하는 것이라고 볼 수 있습니다.

[트랜잭션 프로듀서, 컨슈머 설정 방법]

** 트랜잭션 프로듀서
  . 설정
     - TRANSACTION_ID_CONFIG = UUID.randomUUID().toString() -> 유일한 값으로 설정해야 함
  . 트랜잭션 프로듀서를 설정하면 자동으로 멱등성 프로듀서가 설정된다.

** 트랜잭션 컨슈머
  . 설정
     - ISOLATION_LEVEL_CONFIG = "read_committed"
  . 프로듀서가 커밋하기 이전 레코드는 가져가지 않는다
  . 만약 기본 설정값(read_uncommitted)일 경우에는 커밋되지 않은 레코드도 모두 가져가서 처리한다.

[언제 트랜잭션 프로듀서와 트랜잭션 컨슈머를 사용해아 할까?]

** 여러 이벤트가 반드시 동시에 처리되어야 하는 경우

[ 컨슈머 ]

컨슈머는 파티션에서 레코드를 가져와(Subscribe) 데이터를 처리할 수 있습니다.

컨슈머를 역할에 따라 묶은 것을 컨슈머 그룹이라고 부릅니다. 컨슈머 그룹에는 1개 이상의 컨슈머가 있어야 합니다.

컨슈머 그룹은 아래와 같이 어떤 특정 토픽에 대해 데이터를 병렬 처리할 수 있습니다.

단, 아래와 같이 컨슈머가 파티션의 개수보다 많다고 해도 파티션은 최대 하나의 컨슈머에 할당 가능합니다.

[ 목적에 따른 컨슈머 그룹 ]

서로 다른 역할에 따라 컨슈머 그룹을 나누고 데이터를 처리하면, 커플링 약하게 동일한 데이터를 여러 번 처리할 수 있습니다. 둘중 하나의 컨슈머 그룹의 장애가 생기더라도 나머지 컨슈머 그룹이 영향 없이 데이터를 처리할 수 있는 것입니다.
** 엘라스틱 서치는 시간 순서대로 데이터를 검색하던가, 문자열 데이터로 데이터를 검색할 때 사용
** 하둡 적내는 데이터를 오랜 기간 안전하게 적재하기 위한 용도로 사용

[ 컨슈머의 오프셋 커밋 ]

컨슈머는 오프셋 커밋을 통해서 데이터를 어디까지 처리했는지 저장합니다. 예를들어 컨슈머가 파티션#0의 1번 오프셋 레코드를 처리 완료하면, 컨슈머는 "커밋"이라는 명령어를 통해 1번까지 처리했고, 다음 처리할 레코드는 2번이라는 것을 알 수 있습니다. 그리고 2번 오프셋 레코드를 처리하는 도중 이슈가 발생하면, 마지막 커밋이 된 오프셋이 1번임을 보고 2번 레코드부터 다시 처리를 시작합니다.

그러므로 컨슈머를 구현할 때에는 정말로 데이터 처리가 완료되었을 때에 오프셋 커밋을 해야 데이터의 유실 없이 안전하게 처리할 수 있습니다.

[ 어느 오프셋부터 가져갈까? ]

** 기본 설정은 auto.offset.reset = latest
  . 가장 최신 오프셋의 레코드부터 가져감
  . 컨슈머는 파티션#0의 5번 오프셋 레코드, 파티션#1의 3번 오프셋 레코드 부터 가져감
감

** auto.offset.reset = earlist 로 설정하면
  . 각 파티션의 오프셋 중 가장 낮은 숫자부터 가져감
  . 컨슈머는 파티션#0의 0번 오프셋 레코드, 파티션#1의 0번 오프셋 레코드 부터 가져감

이미 데이터들이 토픽에 들어와 있는 상태에서, 새로운 컨슈머를 실행시킨다면 auto.offset.reset = earlist 로 설정해야 모든 데이터를 다 처리할 수 있을 것입니다 ^^;

[카프카 브로커 간의 데이터 복제]

카프카에서는 서버 단위로 데이터를 복제해서 데이터를 안전하게 보관합니다.
리더 파티션은 프로듀서나 컨슈머와 직접 데이터 통신을 하는 단위이고, 나머지 팔로워 파티션이 복제본입니다.

만약 리더 파티션이 있는 브로커 0번에 장애가 났다고 가정하면, 브로커 1번 혹은 2번에 있던 팔로워 파티션이 리더 파티션으로 승급됩니다.

[메타데이터로 리더 파티션을 구별한다]

프로듀서나 컨슈머와 같은 카프카 클라이언트는 직접 데이터를 주고받기 전에 메타데이터를 요청합니다. 이 작업을 통해 브로커가 가지고 있는 메타데이터 캐시를 응답값으로 돌려받습니다. 그럼 클라이언트는 어느 브로커로 데이터를 보내야 할지 알게 되고 통신을 수행하게 됩니다.

그런데 이런 메타데이터가 일부 상황에서 적절히 update되지 않는 오류가 발생할 때도 있습니다. 프로듀서나 컨슈머가 가지고 있는 메타데이터가 적절하게 update되지 않으면 리더 파티션이 존재하지 않는 브로커와 통신을 할 때도 있습니다. 이런 경우에는 NotLeaderForPartitionException이 발생합니다.

[ISR]

프로듀서가 데이터를 리더 파티션으로 보내고 나면 나머지 팔로워 파티션에 데이터가 복제되는데 이 때 모두 데이터가 복제되어 동기화된 상태를 ISR(In-Sync-Replicas)라고 부릅니다. 즉, 모든 리더 파티션의 데이터가 팔로워 파티션에 복제 완료 되었다는 뜻입니다.

데이터를 복제하는 데에는 지연이 발생하게 됩니다. 프로듀서는 리더 파티션에 데이터를 보내고 데이터를 저장하는 동안에 그리고 저장이 완료되는 시점에 팔로워 파티션들에는 그 데이터가 없습니다. 왜냐하면, 리더 파티션에 데이터가 안전하게 저장된 이후에 데이터를 팔로워 파티션에 복제하기 때문입니다.

즉, 어떤 시점에는 리더와 팔로워 간에 데이터가 동기화되지 않은 시점이 존재하고 그럴 때 리더 파티션에 장애가 발생하게 되면 팔로워 파티션이 리더로 승급할 때 일부 데이터가 유실될 수 있습니다.

[min.inssync.replicas]

토픽 단위로 설정 가능한 min.inssync.replicas 옵션은 프로듀서가 데이터를 보낼 때 얼마나 안정적으로 데이터를 보낼지 설정하는 값으로 사용됩니다. 참고로 이 값은 acks라는 옵션을 all로 설정했을 때만 유효합니다.

min.inssync.replicas 값이 2일 때는 데이터가 최소 리더 파티션과 팔로워 파티션 1개에 안전하게 데이터를 저장하는 것을 보장합니다. 때문에 리더 파티션에 데이터가 저장된 직후 데이터가 복제되지 않은 상태에서 브로커 0번에 장애가 발생하면, 프로듀서는 데이터가 정상적으로 보내지지 않았다는 것을 감지하고 다시 데이터를 보내게 됩니다.

min.inssync.replicas 값이 3일때는 리더 파티션과 팔로워 파티션 2개에 모두 데이터가 복제 완료되었을 때 데이터가 정상적으로 전송되었음을 보장합니다. 그리고 브로커 개수만큼 min.inssync.replicas 값을 설정하면 브로커가 한 대라도 죽으면 프로듀서는 더 이상 데이터를 보내지 않습니다. 때문에 min.inssync.replicas 값은 브로커 개수보다 작게 설정해야 합니다.

[unclean.leader.election.enable]

** unclean.leader.election.enable = true: 데이터 유실을 감안해도 지속 운영하겠다
** unclean.leader.election.enable = false: 데이터 유실을 절대 허용하지 않겠다

unclean.leader.election.enable은 만에하나 팔로워 파티션들이 ISR로 묶이지 못한 경우에 설정할 수 있는 값입니다.

브로커급 장애가 발생했을 때, 데이터의 유실을 감수하고서라도 데이터를 지속 처리할지 결정하는 옵션입니다.

unclean.leader.election.enable 값이 false인 경우 리더 파티션이 있는 브로커에 장애가 발생하면,

리더 파티션이 있는 브로커가 다시 정상화될때까지 영원히 기다리게 됩니다.