조용한 개발 노트

Event-driven은 컴포넌트 간 계약의 문제다Event-driven Architecture를 구성하는 요소는 단순해 보인다.Event를 만드는 쪽Event를 전달하는 쪽Event를 처리하는 쪽하지만 시스템이 복잡해지는 이유는 이 세 요소의 책임 경계가 흐려질 때 발생한다.이 글에서는 각 구성 요소가 무엇을 해야 하고, 무엇을 해서는 안 되는지를 정리한다.Producer의 책임Producer는 Event를 발행하는 주체다.Producer의 핵심 책임은 단 하나다.사실을 정확하게 기록하고 전달한다Producer는 다음을 책임진다.Event가 언제 발생했는지어떤 사실이 발생했는지사실을 왜곡하지 않고 표현했는지Producer는 Event의 의미에만 책임이 있다.Producer가 해서는 안 되는 것Produ..

4편에서 Consumer Group과 Rebalance가 왜 운영 사고의 중심이 되는지 살펴봤다. 그 다음에 반드시 등장하는 질문이 있다.“Offset을 커밋했는데, 왜 중복 처리됐지?”이 질문은 Offset Commit을 무엇으로 이해하고 있는지를 그대로 드러낸다. Kafka에서 Offset Commit은 ‘처리 완료’의 의미가 아니다.Offset이 의미하는 것Offset은 단순히 말하면 로그에서의 위치다.Partition은 append-only log이고, Offset은 그 로그에서 “어디까지 읽었는지”를 나타낸다.Offset = 처리 결과Offset = 비즈니스 상태이 둘은 모두 틀린 해석이다.Offset은 오직 “읽기 진행 상황”만 표현한다.Commit은 무엇을 보장하고 무엇을 보장하지 않는가Of..

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