KIP-392 — 컨슈머가 리더 대신 '가장 가까운' 레플리카에서 읽기
Kafka Connect Source EOS(KIP-618) 및 KIP-392 폴로워 페치 공식 문서 종합 (웹 리서치, 2026) — KIP-618: Exactly-Once Support for Source Connectors + KIP-392: Allow consumers to fetch from closest replica KIP-392: Allow consumers to fetch from closest replica
이 모듈을 다 읽으면
- client.rack/rack.id가 어떻게 컨슈머를 '가까운' 레플리카로 안내하는지 설명할 수 있다
- 이 기능이 왜 클라우드 비용 절감과 연결되는지 설명할 수 있다
kafka-learn-40에서 다룬 랙 어웨어니스(브로커 배치 시 랙을 고려하는 것)를 전제로, 컨슈머 쪽에서도 자신의 랙 정보를 브로커에 알려 항상 파티션 리더가 아니라 '자기와 같은 랙(가용영역)에 있는' 레플리카에서 데이터를 읽어올 수 있게 해주는 KIP-392를 정리한다.
기본 동작의 문제 — 항상 리더에서만 읽는다
기본적으로 컨슈머는 항상 파티션의 리더 레플리카에서 데이터를 fetch한다 — 리더가 다른 가용 영역(AZ)에 있으면, 클라우드 환경에서는 AZ 간 트래픽에 별도 네트워크 비용이 부과되는 경우가 많아 이 트래픽 자체가 비용 요인이 된다. 리더가 아닌 팔로워 레플리카가 컨슈머와 같은 AZ에 있어도, 기본 동작으로는 이를 활용할 방법이 없었다.
핵심 포인트
- 기본적으로 컨슈머는 항상 파티션 리더에서만 fetch — 리더가 다른 가용영역(AZ)에 있으면 AZ 간 트래픽 비용 발생
- 같은 AZ에 팔로워 레플리카가 있어도 기본 동작으로는 활용할 방법이 없었음
client.rack — 컨슈머가 자기 위치를 브로커에 알린다
KIP-392는 컨슈머가 client.rack 설정으로 자신의 랙(가용영역) 정보를 매 fetch 요청에 실어 브로커에 전달하게 한다. 브로커 쪽에는 ReplicaSelector라는 플러그인 인터페이스가 도입돼, 어느 레플리카를 컨슈머에게 안내할지 결정하는 로직을 커스터마이즈할 수 있게 됐다 — 기본 제공되는 RackAwareReplicaSelector는 이 rack.id 정보를 이용해 컨슈머와 같은 랙에 있는 레플리카를 우선 선택하려 시도한다. 이렇게 선택된 레플리카 정보가 컨슈머에게 응답으로 전달돼, 이후 fetch 요청은 그 레플리카로 직접 이어진다.
핵심 포인트
- client.rack 설정으로 컨슈머가 매 fetch 요청에 자신의 랙 정보를 실어 보냄
- ReplicaSelector 플러그인(기본: RackAwareReplicaSelector)이 rack.id 기준으로 같은 랙의 레플리카를 우선 선택해 컨슈머에게 안내 — 이후 fetch는 그 레플리카로 직접 이어짐
왜 이게 비용 절감으로 이어지는가
클라우드 환경에서는 같은 리전 안에서도 AZ를 넘나드는 네트워크 트래픽에 별도 비용이 부과되는 경우가 흔하다 — client.rack으로 컨슈머가 같은 AZ의 레플리카에서 읽게 되면, AZ 간 트래픽 자체가 줄어들어 그만큼 네트워크 비용이 절감된다. 이는 kafka-learn-40에서 다룬 브로커 배치 시의 랙 어웨어니스(파티션 복제본을 서로 다른 랙에 분산하는 것)와 짝을 이루는 개념으로, 브로커 쪽 랙 분산과 컨슈머 쪽 랙 인지 fetch가 함께 있어야 완전한 그림이 된다.
핵심 포인트
- 같은 AZ의 레플리카에서 읽으면 AZ 간 트래픽이 줄어 클라우드 네트워크 비용 절감
- kafka-learn-40의 브로커 배치 랙 어웨어니스와 짝을 이루는 개념 — 브로커 쪽 랙 분산 + 컨슈머 쪽 랙 인지 fetch가 함께 있어야 완전한 그림