발표 소개와 목차
발표자 소개와 함께 이번 세션이 카프카를 스프링에서 리액티브하게 사용하는 방법을 다룬다고 밝힌다. 정확하고 우아한 코드를 지향하는 관점에서 서론·본론·결론 구성을 안내한다.
카프카를 스트리밍 플랫폼으로 소개하고, `@KafkaListener` 어노테이션으로 웹 MVC처럼 편하게 컨슘할 수 있지만 한 번에 레코드 하나만 처리하는 제약과 커밋 시점·병목 이슈가 있음을 설명한다.
카프카 클러스터를 가운데 둔 producer·consumer 구조를 하나의 커다란 스트림으로 보고, 이를 Reactor의 Flux/Mono 연산으로 완전히 대체할 수 있다고 해석한다. 카프카 내부는 신경 쓰지 않고 Flux로 받아 처리하는 발상을 제시한다.
reactor-kafka 프로젝트로 드라이버를 추가해 Sender와 Receiver를 만드는 방법을 샘플로 보여준다. Sender는 Publisher 타입을 받아 한 건씩 또는 동시에 발행할 수 있고, Receiver는 `receive`만 호출하면 레코드를 Flux로 받아 이후 카프카를 신경 쓰지 않아도 된다.
다수 서버의 지표를 수집·감시하다 이상 징후 시 담당자에게 즉시 통지해야 하는 NHN 모니터링 시스템을 소개한다. 인스턴스가 수만 대로 늘어나고 최악의 경우 수천 대에서 동시 이벤트가 터지는 상황을 독립적·지연 없이 처리해야 하는 요구를 설명한다.
이중화로 같은 이벤트가 중복 유입되는 문제를 `sampleFirst`로 일정 시간 내 먼저 온 것만 취하고 `groupBy`로 서버별로 구분해 해결한다. 또 SMS 폭주를 막기 위해 `buffer`로 특정 시간 동안 발생한 이벤트를 리스트로 묶어 한 번에 보내는 전략을 코드 몇 줄 수정으로 구현한다.
5천 건이 한꺼번에 쏟아지면 하위 API가 죽을 수 있어 처리량 제어가 필요하다. 리액티브 스트림의 request(n) 흐름을 설명하고, `BaseSubscriber`를 상속한 커스텀 subscriber로 요청 개수를 조절해 워커 n개 효과를 내며 그 수를 유동적으로 바꾸는 방법을 보여준다.
비동기 처리로 메시지 완료 순서가 뒤바뀌면 낮은 오프셋이 나중에 커밋돼 재시작 시 중복 재처리가 생긴다. 이를 막기 위해 새로 들어온 레코드의 오프셋을 기존 값과 비교해 더 클 때만 커밋, 오프셋이 항상 증가하도록 보장하는 로직을 소개하고 결론을 정리한다.