Fetch Session(KIP-227) — 매번 전체 파티션 목록을 다시 안 보낸다
Kafka Fetch Session(KIP-227) 및 2PC 참여(KIP-939) 공식 문서 종합 (웹 리서치, 2026) — Apache Kafka KIP-227(Introduce Incremental FetchRequests to Increase Partition Scalability), KIP-939(Support Participation in 2PC) Apache Kafka KIP-227: Introduce Incremental FetchRequests to Increase Partition Scalability
이 모듈을 다 읽으면
- 기존 Fetch 요청 방식이 파티션 수에 비례해 왜 비효율적이었는지 설명할 수 있다
- Fetch Session 캐싱이 이 문제를 어떻게 해결하는지 설명할 수 있다
kafka-learn-10에서 다룬 브로커의 Fetch 요청 처리(zero-copy, high watermark 제약)를 전제로, 그 Fetch 요청 자체가 파티션 수가 많아질수록 왜 무거워지는지, 그리고 KIP-227이 이를 어떻게 가볍게 만드는지를 정리한다.
기존 방식의 문제 — 매 요청마다 관심 있는 파티션 전체를 나열한다
기존 Fetch 요청은 컨슈머·팔로워가 관심 있는 파티션 전체 집합을 매번 나열해야 했다 — 심지어 직전 요청 이후로 그 파티션에 아무 변화가 없었어도, 그 파티션의 메타데이터를 매번 다시 주고받아야 했다. 이 비효율은 시스템에 존재하는 파티션 수에 선형으로 비례해서 커진다 — 파티션이 10만 개인 클러스터에서는(대부분 드물게만 새 메시지가 들어와도) 브로커가 여전히 매우 큰 FetchRequest·FetchResponse를 주고받아야 했다. 실제로 토픽이 수천 개인 클러스터에서 이 오버헤드 때문에 브로커의 유휴(idle) CPU가 20% 이상 소모되는 경우가 관측됐다.
핵심 포인트
- 기존 Fetch 요청: 변화가 없는 파티션이어도 매번 관심 파티션 전체 목록·메타데이터를 다시 주고받음 — 파티션 수에 선형 비례해 비효율 커짐
- 토픽 수천 개 규모 클러스터에서 이 오버헤드로 브로커 유휴 CPU가 20% 이상 소모되는 경우 관측됨
Fetch Session 캐싱 — 증분(incremental) 요청으로 바꾼다
KIP-227은 브로커 메모리에 FetchSession을 캐싱하는 방식을 도입했다 — 한 번 세션이 만들어지면, 그다음부터는 클라이언트가 매번 전체 파티션 목록을 다시 보내는 대신 '직전 상태에서 달라진 부분'만 담은 증분(incremental) FetchRequest를 보낼 수 있다. 브로커는 이 세션에 캐싱된 파티션 정보를 바탕으로, 변경이 없는 파티션의 메타데이터는 다시 실어 보내지 않아도 된다 — 이 덕분에 파티션이 수만 개 규모로 늘어나도 매 요청·응답의 크기가 그 규모에 비례해 커지는 문제가 완화된다.
핵심 포인트
- 브로커 메모리에 FetchSession을 캐싱 — 이후 요청은 전체 목록이 아니라 '직전과 달라진 부분'만 담는 증분 FetchRequest
- 변경 없는 파티션의 메타데이터는 재전송 생략 — 파티션 수가 매우 많아져도 요청·응답 크기가 그에 비례해 커지는 문제를 완화