Kafka - acks, replication.factor, min.insync.replicas 설정 분석

1. replication.factor (복제 계수)

• 역할: 하나의 토픽 파티션 데이터를 총 몇 개의 복제본으로 저장할지 결정한다.
• 설정 위치: 브로커(서버) 측, 주로 토픽을 생성할 때 지정한다.
• 구성: 계수가 N일 때 복제본은 1개의 리더(Leader)와 N-1개의 팔로워(Follower)로 구성된다.
  • 리더: 모든 읽기(Read)와 쓰기(Write) 요청을 처리한다.
  • 팔로워: 리더의 데이터를 그대로 복제한다. 평상시에는 요청을 처리하지 않다가, 리더 브로커에 장애가 발생하면 팔로워 중 하나가 새로운 리더로 선출된다.

주의: replication.factor는 가용한 브로커 수보다 클 수 없다.

---

2. min.insync.replicas (최소 동기화 복제본)

min.insync.replicas는 "데이터를 보냈다고 성공 처리하기 위해, 최소 몇 개의 복제본에 쓰기가 완료되어야 하는가?"에 대한 설정.

• 역할: 프로듀서의 acks=all 요청을 성공으로 처리하기 위해 필요한 최소 ISR(In-Sync Replicas)의 수.
• 설정 위치: 브로커(서버) 측 (토픽 단위 또는 브로커 설정).
• ISR (In-Sync Replicas)이란? 리더와 차이 없이 데이터를 복제하고 있는 팔로워 그룹을 의미한다. 리더는 항상 ISR에 포함된다.
• 기본값 1

이 설정은 acks=all 옵션과 함께 사용될 때 내구성을 보장.

---

3. acks

acks 옵션은 프로듀서가 보낸 메시지가 "성공"으로 간주되기 위해 리더로부터 어떤 수준의 확인을 받을지 결정한다.

• 역할: 데이터 전송의 내구성과 속도(Latency) 사이의 트레이드오프를 결정한다.
• 설정 위치: 프로듀서(클라이언트) 측.

3-1. acks = 0 (Fire and Forget)

• 프로듀서는 메시지를 보내기만 하고 브로커로부터 어떠한 응답도 기다리지 않는다.
• 장점: 속도가 가장 빠르다.
• 단점: 데이터 유실 가능성이 매우 높다. 메시지가 브로커에 도착했는지조차 보장하지 못한다. (전송 실패, 리더 다운 등)
• 사용처: 약간의 유실이 허용되는 로그 데이터, 메트릭 수집 등.

3-2. acks = 1 (Default)

• 프로듀서는 메시지를 보낸 후, 리더에 데이터가 성공적으로 쓰였는지 확인하는 응답을 기다린다.
• 장점: 적절한 속도와 기본적인 데이터 보장이 이루어진다.
• 단점: 데이터 유실 가능성이 여전히 존재한다. 리더가 "성공" 응답을 보낸 직후, 팔로워가 데이터를 복제하기 전에 리더 브로커에 장애가 발생하면 해당 메시지는 유실될 수 있다.

3-3. acks = all (또는 -1)

• 프로듀서는 메시지를 보낸 후, 리더뿐만 아니라 min.insync.replicas 에 설정된 수만큼 에 데이터가 성공적으로 복제되었음을 확인하는 응답을 기다린다.
• 장점: 가장 강력한 데이터 보장 수준을 제공한다.
• 단점: 속도가 가장 느리다. (팔로워 복제 대기 시간 포함)
• 사용처: 절대 유실되면 안 되는 데이터, 주문 정보 등 핵심 비즈니스 데이터.

---

4. 코드 예시

kafka-python 라이브러리

from kafka import KafkaProducer

producer = KafkaProducer(
    bootstrap_servers=['kafka-broker1:9092', 'kafka-broker2:9092', 'kafka-broker3:9092'],

    # --- 핵심 내결함성 옵션 ---
    # 가장 강력한 데이터 보장을 위해 "all" 또는 -1로 설정
    acks='all', # 또는 -1

    # 재시도 옵션 (acks=all과 함께 권장)
    retries=3,
    enable_idempotence=True # 중복 없는 전송 (권장)
)

# producer.send(...)

 

---

5. 최적값

(가정: Zookeeper 또는 KRaft 컨트롤러 노드는 Kafka 데이터 브로커와 분리되어 안정적으로 운영 중이라는 가정 하에)

5-1. 목표: 최대 내구성 

이 목표를 달성하기 위한 권장 조합은 다음과 같다.

1. Producer: acks = all
   • 프로듀서가 ISR 그룹의 확인을 받도록 강제한다.
2. Broker (Topic): replication.factor = 3 (이상)
   • 데이터를 최소 3곳에 분산 저장하여 1대의 브로커 장애에 대비하고, 롤링 업데이트 중에도 2대의 복제본을 유지할 수 있다.
3. Broker (Topic/Global): min.insync.replicas = 2 (이상)
   • acks=all 요청 시, 리더 외 최소 1대의 팔로워에도 저장이 완료됨을 보장한다.

해당 조합의 동작 방식:

1. 프로듀서가 메시지를 전송한다.
2. 리더가 메시지를 받고, 2개의 팔로워에게 복제를 요청한다.
3. 리더와 최소 1개의 팔로워가 데이터를 성공적으로 저장한다. (총 2개 = min.insync.replicas 충족)
4. 리더가 프로듀서에게 "성공" 응답을 보낸다.
5. 만약 이때 브로커 1대가 다운되어도, 해당 브로커에 있던 파티션 리더들에 대해 이미 데이터가 복제된 팔로워가 새 리더가 되므로 데이터는 유실되지 않는다.

---

5-2. 브로커 수 및 설정에 따른 장애 시나리오 비교

내결함성을 확보하고 장애 상황에서도 쓰기(Write) 서비스 중단 없이 클러스터를 유지하기 위한 최소 브로커 수는 3대이다.

min.insync.replicas에 따라 장애 발생 시 서비스 상태와 데이터 유실 위험이 어떻게 달라지는지 다음 표를 통해 비교한다. (acks=all 기준)

시나리오	Broker 설정 (Topic)	1대 장애 시 (총 3대)	2대 장애 시 (총 3대)	특징 및 위험성
A: 권장 (균형)	Replication=3 min.insync=2	쓰기/읽기 O (정상) (ISR=2, min.insync 충족)	쓰기 X (중단) (ISR=1, min.insync 불충족)	(데이터 무손실) 1대 장애는 서비스 중단 없이 허용. 2대 장애 시, 데이터 보호를 위해 쓰기 차단.
B: 가용성 우선 (위험)	Replication=3 min.insync=1	쓰기/읽기 O (정상) (ISR=2, min.insync 충족)	쓰기/읽기 O (정상) (ISR=1, min.insync 충족)	(데이터 유실 위험 높음) 2대 장애에도 쓰기가 가능하지만, 데이터가 1대에만 저장됨.
C: 내구성 우선 (경직)	Replication=3 min.insync=3	쓰기 X (중단) (ISR=2, min.insync 불충족)	쓰기 X (중단) (ISR=1, min.insync 불충족)	(데이터 무손실) 데이터는 가장 안전하나, 브로커 1대 장애만으로도 쓰기 서비스가 중단됨.

• 브로커 4대 또는 5대 구성 시
  • R=3, min.insync=2 설정을 동일하게 사용한다고 가정한다.
  • 1대 장애: 3대 구성과 동일하게 ISR=2가 되어 정상 서비스된다.
  • 2대 장애: 3대 구성과 동일하게 ISR=1이 되어 쓰기가 중단.(살아있는 브로커에만 있던 운이 좋은 파티션은 쓰기가 가능하겠지만...)
  • 브로커 수를 3대에서 4대나 5대로 늘리는 것은 R=3, min.insync=2 조합의 내결함성 자체를 높여주지는 않는다. (여전히 1대 장애만 허용). 대신, 더 많은 파티션을 분산 수용할 수 있고, 롤링 재시작 등 유지보수 시 더 많은 버퍼를 제공하여 클러스터 전반의 안정성과 처리량을 향상시키는 이점이 있다.