아파치 카프카는 2011년 처음 출시된 이후 이벤트 스트리밍을 위한 사실상의 플랫폼으로 자리잡았다. 카프카를 열렬히 지지하는 팀 버글런드는 카프카에 대해 “범용 데이터 기판”이라는 표현을 자주 사용한다. 이런 특성을 가능하게 해주는 주된 요소는 카프카와 외부 시스템을 연결할 수 있게 해주는 카프카 생태계(카프카 커넥트), 그리고 자바 스트림 처리 라이브러리(카프카 스트림)다.

아파치 카프카의 최신 릴리즈는 큐와 비슷한 포인트 투 포인트 메시징 소비 의미 체계를 제공한다. 최근 여러 릴리즈에서 오랜 시간 개발과 테스트를 거친 끝에 카프카 4.2에 정식 버전으로 포함됐다.

우선 이벤트 스트리밍과 메시지 큐를 간단히 비교해 보자. 이벤트 스트리밍은 무제한적이고 연속적인 데이터 스트림의 대용량 실시간 처리를 위한 기술이며, 사용자가 필요에 따라 오래된 이벤트를 재생하도록 허용한다. 사용자 애플리케이션은 카프카가 성공적으로 처리한 마지막 이벤트의 오프셋(각 토픽 파티션의 서수 위치)을 기록한다. 사용자가 종료되거나 재시작되면 마지막으로 커밋된 오프셋부터 할당된 파티션 처리를 재개할 수 있다. 예를 들어 인터넷 광고 어트리뷰션, 승차 공유 상태 업데이트, 신용카드 사기 모니터링 등이 있다. 카프카가 지금까지 번성해온 영역으로, 포춘 100대 기업의 80% 이상이 이벤트 스트리밍을 도입해 사용 중이다.

메시지 큐는 포인트 투 포인트 통신에 사용된다. 메시지는 일반적으로 한 번 소비되고 큐에서 제거된다. 이벤트 스트리밍과 달리 소비하는 애플리케이션 측에서 각 메시지의 수신 확인이 가능하다. 이 메시징 패턴은 모바일 디바이스의 앱 내 알림, 급여 명세서 생성 또는 AI 모델 호출과 같은 작업에서 보장된 일회성 처리를 통해 애플리케이션과 서비스를 분리한다. 널리 사용되는 플랫폼으로는 래빗MQ(RabbitMQ), 액티브MQ(ActiveMQ), IBM MQ가 있다.

이런 메시지 큐 사용례는 그동안 아파치 카프카에서 “원형 구멍에 사각형 막대를 끼우는 것”과 같았다. 왜일까? 우선 “전통적인” 카프카 사용자 그룹의 확장은 토픽 파티션의 수에 의해 제약된다. 무엇보다 카프카 사용자에게는 메시지 수준의 수신 확인 의미 체계가 없다. 사용자 메시지 큐 시스템이 큐에 있는 메시지에 대해 협조적으로 작동할 수 있게 해주는 기능들이다.

이것이 ‘KIP-932: 카프카를 위한 큐‘가 추진된 주된 배경이다. 카프카의 이 메시지 큐 구현이 이벤트 기반 아키텍처에서 어떻게 중요한 툴이 되는지 살펴보자.

카프카 사용자 애플리케이션 확장하기

전통적으로 카프카 토픽 데이터의 병렬 처리는 현재 소비 중인 토픽의 파티션 수에 따라 제한된다. 브로커는 토픽의 각 파티션 소비를 사용자 그룹의 단일 멤버에 할당한다. 사용자 그룹의 멤버 수가 토픽의 파티션 수와 같아지면 그룹에 추가되는 새로운 사용자는 유휴 상태가 된다.

이 다이어그램은 3개의 파티션이 있는 토픽을 구독하는 사용자 그룹의 인스턴스 3개를 보여준다. 즉, 이 토픽에 대한 병렬 처리가 가능한 최대치에 도달한 상태다.

Confluent

KIP-932는 공유 그룹이라는 새로운 유형의 그룹을 추가한다. 생산자 애플리케이션에 의해 카프카에 데이터가 기록되는 방식이나 카프카에 데이터가 저장되는 방식에는 아무런 변화가 없다. 기존 이벤트 스트리밍 사용례는 동일한 토픽에서 계속 작동한다.

공유 그룹에는 새로운 협력적 소비 모델이 사용되는데, 여기서 공유 그룹 사용자의 작동 방식은 메시지 큐 시스템의 사용자 또는 구독자와 비슷하다. 브로커에서 각 토픽 파티션에는 공유 그룹과 관련해서 각 메시지의 수명 주기를 추적하는 공유 파티션이 있다. 이를 통해 공유 사용자를 토픽 파티션 수 이상으로 확장할 수 있다.

이 다이어그램은 새로운 협력적 소비 모델을 보여준다. 사용자 그룹에 속한 복수의 멤버가 하나의 토픽 파티션의 데이터를 처리한다.

Confluent

토픽 파티션에서의 이와 같은 협력적 소비는 곧 “전통적인” 카프카 사용자의 파티션 수준 처리 순서 보장을 잃게 된다는 의미이기도 하다. 확장을 얻는 대신 치러야 하는 대가라고 할 수 있다. 애초에 협력적 소비는 처리 순서보다 처리량과 확장이 우선시되는 사용례를 위해 고안된 기술이다.

메시지 수준 수신 확인

이미 카프카를 사용 중인 개발자에게는 KIP-932를 위한 API가 익숙하게 느껴질 것이다. 우선 카프카 토픽으로 이벤트가 생성되는 방식에는 아무런 변화가 없다. 사용자 측면을 보면, KafkaShareConsumer 인터페이스는 기존 KafkaConsumer와 매우 유사하다. 사용자 애플리케이션은 사용 가능한 메시지를 폴링하고, 결과로 나오는 각 ConsumerRecord 인스턴스를 처리한다.

이제 사용자는 각 레코드의 전달을 개별적으로 수신 확인할 수 있다. 기본적으로 모든 메시지는 성공적으로 처리된 것으로 암시적으로 수신 확인된다. 그러나 특히 오류 처리, 장기 실행 작업과 관련해서 개발자에게 더 세밀한 제어가 필요한 상황이 있다.

사용자 구성의 share.acknowledgement.mode에 대해 explicit 값을 사용하면 각 메시지의 수신 확인 방법을 지정할 책임을 코드가 맡게 된다. 사용 가능한 AcknowledgementType 값은 ACCEPT, RELEASE, REJECT, RENEW다. 이런 값은 공유 그룹과 관련된 각 메시지의 상태에 영향을 미친다. 상태는 AVAILABLE, ACQUIRED, ACKNOWLEDGED, ARCHIVED다.

다이어그램에서 이런 수신 확인 유형을 기반으로 메시지의 수명 주기를 제어하는 상태 머신을 자세히 볼 수 있다.

Confluent

사용자는 상태가 AVAILABLE인 메시지만 가져올 수 있다. 메시지를 가져오면 메시지는 ACQUIRED 상태로 전환되고 해당 메시지의 전달 횟수가 증가한다. 이는 공유 그룹의 다른 멤버가 가져가지 못하도록 메시지를 “잠그는” 효과가 있다.

ACQUIRED 상태가 된 메시지는 정해진 시간 내에 처리돼야 한다. 이 “잠금” 또는 “임대”가 만료되면 메시지는 전달 횟수에 따라 ACQUIRED 상태로 되돌아가거나 ARCHIVED 상태로 이동한다. 각 메시지의 상태와 전달 횟수는 공유 파티션에서 추적된다. 따라서 개발자는 메시지 처리를 재시도할 수 있는 상황에서 사용할 수 있는 기본 재시도 메커니즘을 얻게 되고, 이때 메시지는 RELEASE 유형을 사용해 수신 확인이 가능하다.

메시지 처리가 성공적으로 완료되면 해당 메시지는 ACCEPT 유형으로 수신 확인되고 메시지는 ACKNOWLEDGED 상태로 전환된다.

처리에 비결정적인 시간이 소요되는 경우도 있다. 사용자가 서드파티 또는 파트너 API를 호출하거나, LLM 호출 결과를 사용해 메시지를 보강하는 경우 등을 생각해볼 수 있다. 이런 경우는 “실패”가 아니라 처리 코드를 완료하는 데 더 많은 시간이 필요한 것이다. 이와 같은 경우에는 RENEW 유형으로 메시지를 수신 확인해서 잠금을 재설정한다.

메시징 프로토콜과 인프라 통합

많은 기업에는 이벤트 스트리밍과 메시지 큐 사용례가 모두 있다. 이 경우 운영자는 아파치 카프카와 오래된 메시지 큐 시스템을 모두 유지 관리하고 지원한다. 개발자들은 다양한 메시징 라이브러리와 프로토콜을 사용하는 애플리케이션을 동일한 애플리케이션 코드 베이스에 통합한다. 경영진은 회사가 왜 여러 개의 메시징 솔루션에 비용을 지불하고 있는지 묻는다.

이런 메시징 사용례를 아파치 카프카로 통합하면 생산 애플리케이션의 개발, 배포, 업그레이드와 유지 관리가 더 간편해진다. 또한 처리되는 메시지의 요구사항과 SLA를 충족하도록 사용자 애플리케이션을 확장하는 데에도 도움이 된다.

운영자와 SRE(사이트 안정성 엔지니어)는 대체로 단순함을 선호한다(단순함과 프로덕션 사고 발생 횟수 간의 상관관계 때문일 수 있음). 이런 메시징 플랫폼을 통합한다는 것은 구성, 배포, 패치해야 하는 시스템이 줄어든다는 의미다. 게다가 전체 애플리케이션 인프라의 총소유비용이 낮아지므로 경영진의 우려 사항도 해결된다.

개발팀 관점에서 카프카용 큐의 의미

KIP-932는 사람들이 아파치 카프카에서 오랜 기간 기다려온 포인트 투 포인트 의미 체계를 제공한다. 이는 신생업체부터 대기업까지 모든 환경에서 카프카를 비즈니스의 핵심 인프라로 만들어준 내구성과 확장성, 처리량 위에 큐와 유사한 소비 및 메시지 수준 수신 확인 계층을 덧붙인다.

개발팀에 이는 여러 프로토콜을 오가지 않고 하나의 메시징 API를 기준으로 애플리케이션을 작성하게 된다는 의미다. 운영 팀에는 인프라를 통합하고 복잡성을 줄인다는 의미다. 그리고 기업에는 각 사용례에 필요한 특정 의미 체계를 희생하지 않으면서 총소유비용을 낮추는 것을 의미한다.

KIP-932는 현재 아파치 카프카 4.2와 컨플루언트 클라우드(Confluent Cloud)에서 사용할 수 있으며 향후 컨플루언트 플랫폼 8.2 버전도 지원될 예정이다. 개발자들은 이제 구현을 살펴보고 큐 기반 소비 패턴을 테스트해볼 수 있다. KIP-932 및 기타 이벤트 스트리밍 주제에 대한 자세한 내용은 당사의 전문가 팀이 선별한 컨플루언트 디벨로퍼 무료 학습 리소스에서 볼 수 있다.
dl-itworldkorea@foundryco.com