Kafka에서 acks 설정은 프로듀서가 메시지를 브로커에 전송한 후 어느 시점까지 응답을 받을지를 결정합니다.
이 설정에 따라 메시지 유실 여부와 전송 속도가 크게 달라집니다.
본 글에서는 acks=0, acks=1, acks=all의 차이와 메시지 흐름을 시각적으로 정리해 쉽게 설명합니다.
Kafka Producer acks 설정 및 동작 이해하기: 데이터 유실 방지
목차
1. Kafka에서 acks란?
Kafka에서 acks는 프로듀서가 보낸 메시지가 브로커에 얼마나 안전하게 저장되었는지를 확인받는 방법입니다.
이 설정은 메시지 전송의 신뢰성(데이터 유실 가능성)과 성능(전송 속도)에 직접적인 영향을 미칩니다.
Kafka는 데이터를 브로커 하나에만 저장하지 않고, 리더 브로커 외에 여러 복제 브로커(ISR)에 복제합니다.
이때 acks 설정에 따라 프로듀서는 어떤 기준까지 저장되었을 때 응답을 받을지를 결정하게 됩니다.
acks 설정이 컨슈머(Consumer)의 메시지 처리 속도에 영향을 준다고 생각하지만, 실제로는 그렇지 않습니다.
Kafka 컨슈머는 리더 브로커뿐 아니라, 모든 복제 브로커(ISR)에 복제된 메시지만을 읽을 수 있습니다.
즉, 프로듀서가 acks=0으로 빠르게 전송하더라도, 해당 메시지가 복제되지 않았다면 컨슈머는 읽을 수 없습니다.
따라서 acks 설정은 컨슈머가 읽는 속도에는 영향을 주지 않습니다.
결론적으로 acks는 프로듀서 측 성능과 신뢰성에만 영향을 미칩니다.
2. acks 옵션별 동작 방식 비교
Kafka 프로듀서의 acks 설정은 다음 세 가지 방식이 있습니다.
각 설정은 데이터 유실 가능성과 처리 속도에서 뚜렷한 차이를 보입니다.
| 설정값 | 동작방식 | 데이터 유실 가능성 | 속도 |
| acks = 0 | 메시지를 전송한 뒤 응답을 기다리지 않고 다음 메시지 전송 | 높음 (브로커 장애 시 유실) | 매우 빠름 |
| acks = 1 | 리더 브로커가 메시지를 저장하면 응답 | 낮음 (리더 장애 시 유실) | 보통 |
| acks = all | 리더 브로커 + 모든 동기화 복제(ISR) 브로커 저장 후 응답 | 없음 | 느림 |
3. acks=0: 빠르지만 불안한 전송
acks=0은 프로듀서가 메시지를 브로커에 전송한 후, 브로커의 저장 여부나 응답을 기다리지 않고 다음 메시지를 바로 보냅니다.
메시지가 브로커에 저장되었는지조차 알 수 없기 때문에 브로커 장애 시 메시지가 유실될 가능성이 매우 높습니다.
◆ 메시지 흐름
Producer ── send ──▶ Broker
Producer ◀─ no ack
Consumer ◀─ fetch (복제 완료된 메시지만 읽음)
◆ 설명
- Producer는 메시지를 브로커에 보내고 확인 없이 바로 다음 메시지를 보냅니다.
- Broker가 메시지를 정상적으로 받지 못해도 Producer는 이를 인식하지 못합니다.
- Consumer는 ISR에 복제 완료된 메시지만 읽을 수 있기 때문에, 복제가 되지 않았다면 해당 메시지는 읽히지 않습니다.
4. acks=1: 성능과 안정성의 절충
acks=1은 메시지가 리더 브로커에만 저장되면 프로듀서에게 응답(ack)을 보냅니다.
이 방식은 속도와 신뢰성의 균형을 제공하지만, 리더가 복제 전에 장애가 발생하면 메시지가 유실될 수 있습니다.
◆ 메시지 흐름
Producer ── send ──▶ Leader Broker
└───▶ Replica (비동기 복제)
Producer ◀─ ack (from Leader)
Consumer ◀─ fetch (ISR 복제 완료된 메시지만)
◆ 설명
- 메시지는 먼저 리더 브로커에 저장됩니다.
- 리더가 복제 브로커로 데이터를 보내는 동안 Producer는 응답을 받습니다.
- 리더 장애 발생 시 복제되지 않은 메시지는 손실될 수 있습니다.
5. acks=all: 완전한 신뢰성과 메시지 보장
acks=all은 **모든 동기화 복제 브로커(ISR)**가 메시지를 저장할 때까지 기다린 후에만 프로듀서에게 응답을 반환합니다.
가장 안전한 메시지 전송 방식으로, 리더가 장애가 나더라도 ISR이 유지되고 있다면 데이터는 보존됩니다.
◆ 메시지 흐름
Producer ── send ──▶ Leader Broker
└───▶ Replica 1
└───▶ Replica 2
(waiting until all ISR replicate)
Producer ◀─ ack (after all ISR sync)
Consumer ◀─ fetch (from ISR)
◆ 설명
- 메시지가 리더뿐 아니라 모든 ISR 브로커에 저장되어야 ack이 반환됩니다.
- 하나의 ISR이라도 저장이 지연되면 Producer는 대기합니다.
- 복제된 데이터만 Consumer가 읽을 수 있어 데이터 유실이 없습니다.
6. 성능과 안정성을 위한 설정
Kafka 클라이언트 프로듀서에서는 3.0 버전부터 acks=all이 기본값으로 설정되어, 보다 안전한 메시지 전송이 기본 동작이 되었습니다.
하지만 acks=all은 모든 복제 브로커의 응답을 기다리기 때문에 성능 저하가 우려될 수 있습니다.
이를 해결하기 위해서는 비동기 프로듀서 방식을 사용하는 것이 중요하며,
Kafka 성능 분석 보고서(An analysis of the impact of max.in.flight.requests.per.connection and acks on Producer performance)에 따르면,
acks=all로 설정하더라도 max.in.flight.requests.per.connection=3으로 조정하고 비동기 방식으로 메시지를 전송하면
acks=1과 동일한 수준의 처리 성능을 유지할 수 있음을 설명하고 있습니다.
최적 설정 예시:
- acks=all
- max.in.flight.requests.per.connection=3
- 비동기 프로듀서 설정 사용 (send() 호출 후 Future 처리)
Kafka의 acks 설정은 프로듀서가 메시지를 얼마나 안정적으로 전송할지를 결정하는 핵심 요소입니다.
- acks=0: 속도 최우선, 데이터 유실 감수
- acks=1: 일반적인 균형, 소폭 유실 가능
- acks=all: 완전한 신뢰성, 약간의 성능 저하
Consumer는 ISR에 복제된 메시지만 읽기 때문에, acks 설정은 Producer 쪽만의 문제입니다.
고성능 Kafka 프로듀서를 구현하려면 acks=all을 기본으로 하고, 비동기 전송 전략을 병행하는 것이 좋습니다.
관련 글 링크
An analysis of the impact of max.in.flight.requests.per.connection and acks on Producer performance - Apache Kafka - Apache Soft
This page is a summary of results on the analysis I did on understanding the optimal value of max.inflight.requests.per.connection as well as the performance impact of acks=all. Test Setup 3 brokers on AWS, d2.xlarge instances: 3x2TB locally attached di
cwiki.apache.org
'1.시스템&인프라 > Apache Kafka' 카테고리의 다른 글
| 9. Kafka 하드웨어 요구사항 및 JVM 옵션 정리: KRaft 모드 (0) | 2025.03.31 |
|---|---|
| 8. Kafka Consumer 동작 이해하기: Polling, Offset, Commit (0) | 2025.03.31 |
| 6. Kafka 프로듀서 파티션 할당 방식(Round Robin vs Sticky 비교) (0) | 2025.03.28 |
| 5. Kafka 리더 장애 발생 시 Failover를 위한 Producer와 Consumer 설정 (0) | 2025.03.28 |
| 4. Kafka 클러스터 다중 파티션 구성 이해: 고가용성과 장애복구 (0) | 2025.03.28 |