메시지를 발행하는 쪽이 구독하는 쪽으로 직접 보내지 않는 패턴. 사이에 메시지를 받아서 중계하는 브로커(broker)가 있다.
직접 연결에서 중앙 집중화까지
지표를 대시보드로 보여주는 서버를 만든다고 하자. 문제는 단계를 밟아 커진다.
- 프론트엔드 서버가 지표 서버로 직접 요청한다. 발행자와 구독자가 직접 연결된 형태다
- 프론트엔드 서버가 여러 대가 되고 지표 서버도 여러 대가 되고 지표 UI와 DB 서버까지 붙는다. 각 서비스가 직접 연결되어 무엇이 무엇을 부르는지 추적하기 어려워진다
- 지표 발행 구독 서버를 하나 둔다. 모든 애플리케이션에서 지표를 받아 필요한 시스템에 준다
- 그런데 지표 말고도 로그와 사용자 활동에 각각 메시지 큐가 생긴다. 2번보다는 낫지만 여전히 중복이고, 개별 메시지 큐 시스템은 버그도 한계도 제각각이다
여기서 나오는 것이 일반화된 유형의 데이터를 발행하고 구독할 수 있는 중앙 집중화된 시스템이다. 그것이 카프카다.
토픽 이름만 아는 양쪽
발행자는 누가 읽는지 모른다. 구독자는 누가 썼는지 모른다. 양쪽이 아는 것은 토픽 이름뿐이다.
그래서 새 소비자를 추가해도 생산자 쪽을 건드리지 않고, 소비자가 잠시 죽어도 메시지는 브로커에 남아 있으며, 생산 속도와 소비 속도를 따로 조절할 수 있다.
낮은 결합도를 시스템 사이에 적용한 것이다. 클래스 사이에서 하던 이야기를 서버 사이에서 하는 것뿐이다.
읽어도 지워지지 않는 메시지
전통적인 큐 시스템은 하나의 메시지를 하나의 클라이언트만 소비한다. 읽으면 사라진다.
카프카는 다르다. 여러 컨슈머가 서로 간섭 없이 같은 스트림을 읽을 수 있다. 메시지를 읽는다고 지워지지 않기 때문이다. 지우는 것은 보존 정책의 몫이다.
이 하나의 차이에서 카프카의 활용 사례 대부분이 나온다. 하나의 페이지 뷰 스트림을 추천 시스템도 읽고, 분석 시스템도 읽고, 로그 저장소도 읽는다.