조용한 개발 노트

3편에서 Partition이 순서와 확장을 동시에 만족시키는 설계 단위라는 이야기를 했다. 이제 그 Partition 위에서 실제 처리를 담당하는 Consumer Group으로 넘어가 보자.Kafka 운영 경험이 있는 팀이라면 한 번쯤 이런 말을 해봤을 것이다.“아무 일도 안 했는데 리밸런스가 일어났다.”이 현상은 우연이 아니다. Consumer Group의 설계 자체가 리밸런스를 전제로 하고 있기 때문이다.Consumer Group은 무엇을 해결하려는 개념인가Consumer Group의 목적은 단순하다.하나의 Topic을 여러 Consumer가 나눠서 처리한다Partition은 오직 하나의 Consumer에게만 할당된다Consumer 수에 따라 처리량을 수평 확장한다이 구조 덕분에 Kafka는 병렬 처..

1편에서 Kafka가 메시지 큐가 아니라 분산 로그라는 점을 이야기했다. 이 관점을 받아들이면, 다음 질문이 자연스럽게 이어진다.“그럼 왜 Kafka는 메시지를 밀어주지 않고, 소비자가 직접 가져가게 만들었을까?”이 선택은 구현 편의가 아니라, Kafka가 해결하려는 문제의 성격에서 나온 필연이다.Push 모델의 직관과 한계Push 모델은 직관적이다. 데이터가 도착하면, 브로커가 소비자에게 즉시 전달한다.이 방식은 단순한 메시징에서는 잘 동작한다.소비자 수가 적고처리 속도가 비슷하며메시지 크기와 빈도가 안정적일 때하지만 Kafka가 다루는 환경은 이와 다르다.Kafka가 마주한 현실적인 문제Kafka의 설계 문서가 전제로 삼는 환경은 다음과 같다.소비자마다 처리 속도가 다르다같은 데이터를 여러 그룹이 읽..

gRPC Flow Control & Backpressure이 글은 gRPC 공식 문서와 HTTP/2 전송 방식을 기준으로, Streaming RPC에서 응답이 에러 없이 지연되거나 멈춘 것처럼 보이는 현상이 왜 발생하는지와, 실무에서 이를 어떻게 설계로 해결하는지에 대해 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/concepts/ , https://grpc.io/docs/guides/performance/ 📌 카테고리: Dev > gRPC1. Streaming RPC에서 자주 겪는 현상에러는 발생하지 않는다연결은 유지되고 있다응답이 일정 시점부터 오지 않는다이 현상은 네트워크 오류나 서버 장애가 아니라, gRPC와 HTTP/2의 흐름 제어 메커니즘에 의해 발생..