반응형
반응형
🌏 인트로
✅ Acknowledgement(acks)가 필요한 이유
Kafka에서 메시지는 이렇게 흘러갑니다
Producer → Broker(Leader) → Follower(Replication) → Consumer
Broker = 메시지를 직접 들고 있는 Kafka 서버 1대
- Producer가 메시지를 보내면 Broker가 Topic의 Partition에 저장합니다.
- Consumer는 Broker로부터 메세지를 가져가서 처리합니다
- 여러 Broker가 모이면 Kafka Cluster가 되고, 여기서 Partition들을 서로 나눠서 저장하거나 복제(Leader/Follower)도 합니다.
Producer (애플리케이션) 입장에서는 “내가 보낸 메시지가 진짜 카프카 서버(=브로커)에 안전하게 저장됐을까?”를 알고 싶습니다.
- 만약 메시지가 네트워크 중간에 날아가면?
- 만약 Broker Leader가 디스크에 기록하기도 전에 죽어버리면?
- 만약 아직 Follower에 복제되지 않았는데 Leader가 장애 나면?
이런 상황에서 “어느 수준까지 저장됐을 때 성공으로 인정할지”를 정해야 하고 그게 바로 acks 설정입니당
✅ acks 의미
acks = Producer가 Broker로부터 받는 “확인 응답(Acknowledgement)” 수준
acks=0→ 확인 필요 없음acks=1→ Leader Broker까지만 확인받기acks=all→ Leader + Follower(동기화된 모든 Replica)까지 저장 확인해야 성공으로 정하겠음
🌏 acks 설정
✅ 1. acks=0 (응답 안 받음, Fire-and-Forget)
- Producer는 메시지 전송 후 확인 안 기다림
- Broker가 받았는지, 디스크에 썼는지 알 수 없음
네트워크에서 UDP와 같이 그냥 잘 갔는지 확인 안함
장점: 제일 빠름
단점: 메시지 유실 위험 높음
예: 로그, 모니터링 등 일부 손실 허용 가능한 경우
✅ 2. acks=1 (Leader 확인, 기본값)
- Leader Broker가 메시지를 디스크에 저장하면 OK 응답
- Follower 복제는 아직 안 됐을 수 있음
장점: 속도와 안정성의 균형(이 적절한 느낌)
단점: Leader가 저장 직후 죽으면, Follower에는 아직 데이터가 없을 수 있음 (데이터 유실 가능)
예: 대부분의 서비스 이벤트 처리
✅ 3. acks=all (모든 ISR 확인)
- Leader + In-Sync Replica(ISR, 최신 동기화된 Follower)까지 저장이 끝나야 OK
- (= 복제까지 확인 후 성공 처리)*
장점: 가장 안전 (리더 장애 시에도 데이터 복구 가능)
단점: 속도 느려짐 (팔로워 복제 기다려야 함)
예: 결제, 금융, 재고 등 절대 유실되면 안 되는 경우
🌏 acks / 전송 보장 방식의 관계
- acks=0 → 보통 At most once (빠르지만 유실 가능)
- acks=1 → At least once (유실은 거의 없지만 중복 가능)
- acks=all → At least once ~ Exactly once (Idempotent Producer/트랜잭션을 추가해야 Exactly once 달성)
도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!
반응형
