카프카 프로듀서, 메시지 전송 보장 레벨(acks)

 

 

요약

Kafka acks는 전송 지연·처리량(Throughput) 과 데이터 안정성(Durability) 을 맞바꾸는 가장 직관적인 레버입니다.

• acks=0 : “Fire-and-Forget” — 최저 지연·최고 손실 위험
• acks=1 : “리더 확인” — 균형형, 리더 장애 시 손실 가능
• acks=all(-1) (+ min.insync.replicas) — ISR 전원이 복제 후 성공, 지연·CPU↑ 대신 내구성 최상
  여기에 멱등성 프로듀서(enable.idempotence=true)를 더하면 중복 없는 최소-한-번, 트랜잭션 API까지 쓰면 정확-한-번 처리로 진화합니다.

---

1. acks 파라미터란?

프로듀서가 브로커로부터 몇 개의 확인(ACK) 을 받아야 전송을 성공으로 간주할지 정의하는 설정입니다. 값은 0 | 1 | all(-1) 세 가지이며, “동기화 지점” 을 바꿔 지연·처리량·내구성에 직접 영향을 줍니다.

---

2. acks=0 — 순수 속도 지향

특징 설명

지연	프로듀서가 응답을 기다리지 않아 최저
처리량	CPU context switch 감소로 최고 TPS 도달
데이터 손실	네트워크·브로커 오류 시 확실히 손실 — 장애 복구 불가
실무 용도	Click-stream·메트릭 등 잃어도 되는 텔레메트리 배치

---

3. acks=1 — 리더만 OK

• 프로듀서는 리더 브로커 가 로컬 로그에 기록했다는 ACK만 받으면 성공 처리합니다.
• 팔로워 복제는 비동기 로 진행되므로, 리더 장애 직후에는 일부 메시지 롤백 가능성이 있습니다.
• 지연·처리량은 acks=all 대비 20-40 % 개선되는 벤치마크가 다수 보고됩니다.
• 장애-내성 확보 를 원하면 토픽의 min.insync.replicas ≥ 2 로 높여 리더 단독 운영을 방지해야 합니다.

---

4. acks=all(-1) — ISR 전원 OK

• ISR(In-Sync Replica) 모든 팔로워가 복제 완료 후 ACK → 가장 강력한 내구성.
• 성능 비용: 디스크 FSync + 네트워크 왕복이 증가해 30-60 % 처리량 하락 보고.
• 네트워크 파티션 으로 ISR 수가 min.insync.replicas 미만이면 프로듀서가 TimeoutException 을 받아 쓰기를 차단해 데이터 유실 대신 가용성을 희생 합니다.
• 금융·결제·주문 등 손실 0% 가 필수인 스트림에 권장.

---

5. 멱등성 프로듀서(Idempotent Producer)

요소 효과 키 포인트

enable.idempotence=true	중복 전송 방지 — 재시도·네트워크 재연결에도 로그 1 회 기록	자동으로 acks=all, retries=Integer.MAX_VALUE, max.in.flight.requests.per.connection≤5 로 조정
프로토콜	프로듀서-ID + 시퀀스 번호로 브로커가 중복 필터링	파티션 단위 보장
한계	멀티 파티션 atomic commit 은 불가 → 트랜잭션 API 필요

실전 팁 : enable.idempotence=true 로 전환해도 지연은 수 ms 수준 증가에 그치지만, 장애 시 중복 0 을 얻을 수 있어 비용-대-효과 가 매우 우수합니다.

---

6. 설정 예시

# producer.properties
acks=all               # 내구성 최우선
enable.idempotence=true
retries=Integer.MAX_VALUE
delivery.timeout.ms=120000
max.in.flight.requests.per.connection=5

• 테스트 TPS : 100 k msg/s 이상 트래픽에서 위 구성으로도 CPU 5-10 % 추가 사용에 그쳤다는 실험 결과가 있습니다 .
• 모니터링 : record-send-rate, record-error-rate, request-latency-avg 로 실부담을 확인하세요.

---

7. 결론 — 어떤 조합이 최선인가?

사용 시나리오 권장 설정

로그·메트릭·샘플링 이벤트	acks=0
뉴스 피드·소셜 타임라인	acks=1 (+ min.insync.replicas=2)
결제·재고·주문	acks=all + enable.idempotence=true
다중 토픽 원자성 필요	위 + 트랜잭션 API

Kafka acks 와 멱등성은 “지연 ↔ 안정성” 트레이드오프의 다이얼 입니다. 회복 가능한 손실인가, 절대 안 되는 손실인가? 를 먼저 정의하고, 그에 맞는 acks·idempotence·replication.factor·min.insync.replicas 를 조합하세요. 올바른 설정은 장애 상황에서도 데이터를 잃지 않으면서 서비스 SLA를 만족시키는 시작점이 됩니다.