Kafka·RabbitMQ, 속도보다 소비 방식으로 고르는 법

Kafka와 RabbitMQ를 고를 때는 최고 처리량보다 메시지를 읽은 뒤에도 남겨둘지 먼저 결정해야 한다. 여러 서비스가 같은 이벤트를 독립적으로 읽고 나중에 다시 처리해야 한다면 Kafka의 이벤트 로그가 자연스럽다. 개별 작업을 작업자에게 맡기고 완료 확인과 재전달을 관리해야 한다면 RabbitMQ의 큐가 더 직접적이다.

다만 제품 이름만으로 결론을 내릴 수는 없다. RabbitMQ에는 기록을 다시 읽는 스트림이 있고, Kafka에는 레코드를 작업자들이 나눠 처리하는 share group이 있다. 실제 선택 대상은 제품 전체가 아니라 사용할 저장 구조와 소비 방식의 조합이다.

이벤트를 다시 읽을까, 작업을 완료할까

Kafka의 일반 소비자 그룹은 토픽 파티션을 그룹 구성원에게 할당한다. 같은 그룹 안에서는 한 파티션의 기록을 담당 소비자가 순서대로 읽고, 다른 그룹은 같은 기록을 독립적으로 소비할 수 있다. Apache Kafka 설계 문서는 이 파티션 할당이 순서와 확장을 결합한다고 설명하며, share group에서는 여러 소비자가 같은 파티션의 레코드를 협력 처리하고 레코드별 결과를 확인할 수 있다고 명시한다.

이벤트 로그에서는 소비 위치를 되돌려 보존된 기록을 다시 처리할 수 있다. 그만큼 애플리케이션은 같은 이벤트가 재적용될 때 외부 데이터베이스나 결제 상태에 어떤 일이 생길지도 설계해야 한다. 오프셋을 되돌리는 기능이 이미 발생한 외부 작업을 취소하지는 않는다.

작업 큐의 메시지는 완료를 기다리는 개별 일감에 가깝다. 작업자가 실패하면 재전달할지, 처리할 수 없는 작업을 별도 경로로 보낼지 정해야 한다. 가령 여러 서비스가 주문 상태 변경을 각자 반영하는 요구와 영수증 생성 작업을 한 작업자가 끝내는 요구는 같은 주문을 다루더라도 소비 방식이 다르다. 이는 선택 기준을 보여 주기 위한 가상의 흐름이다.

재처리와 팬아웃은 저장 구조를 바꾼다

RabbitMQ 스트림의 주문 이벤트가 남아 있어 서로 다른 소비자가 다시 읽는 구조

재처리가 필요하다고 해서 Kafka만 후보가 되는 것은 아니다. RabbitMQ 스트림 문서에 따르면 스트림은 추가 전용 로그에 메시지를 남겨 소비자가 원하는 위치에서 다시 읽게 한다. 반면 일반 큐에서는 완료된 작업을 같은 방식으로 되읽지 않는다. 스트림의 재읽기 가능 범위는 설정한 보존 기간이나 저장 용량에 묶인다.

여러 서비스가 동일한 이벤트를 독립적으로 소비한다면 Kafka의 별도 소비자 그룹이나 RabbitMQ 스트림의 별도 소비 위치를 생각할 수 있다. 각 서비스가 자신의 진행 위치를 관리하므로 한 서비스의 느린 처리 때문에 다른 서비스가 같은 위치에서 기다릴 필요는 없다. 반대로 메시지 유형에 따라 정해진 작업 큐로 보내고 그 큐의 작업자들이 일감을 나눈다면 RabbitMQ의 교환기와 바인딩이 라우팅을 맡는다.

어떤 기록을 다시 만들려는지도 구분해야 한다. 과거 이벤트를 다시 실행하려면 그 이벤트가 보존돼 있어야 한다. 키별 최신 값을 이용해 현재 상태를 재구성하려면 Kafka의 로그 컴팩션이 도움이 되지만, 컴팩션 과정에서 오래된 값은 제거될 수 있으므로 모든 변경 이력을 되짚는 요구와는 다르다. 재처리 범위, 보존량, 소비자별 위치, 중복 적용 시의 부작용이 함께 설계 대상이 된다.

순서 보장의 범위가 소비자 수를 정한다

순서가 중요한 대상을 먼저 정해야 병렬 처리 범위도 정해진다. Kafka의 일반 소비자 그룹에서는 같은 키의 이벤트를 같은 파티션에 보내 그 파티션 안의 순서를 다룰 수 있다. 파티션 사이에 전체 순서가 생기는 것은 아니며, 그룹의 소비자를 파티션보다 더 늘려도 해당 파티션을 읽는 작업이 더 잘게 나뉘지는 않는다.

RabbitMQ 큐에서도 큐에 들어간 순서와 작업이 끝난 순서를 구별해야 한다. RabbitMQ 큐 문서는 여러 활성 소비자와 재전달이 소비자가 관찰하는 순서에 영향을 줄 수 있다고 설명한다. 큐의 처리 순서를 엄격히 유지하는 방법으로는 단일 활성 소비자를 제시한다. 주문별 순서와 병렬성이 함께 필요하다면 주문 식별자에 따라 여러 큐로 분할하고 각 큐의 소비 방식을 정할 수 있다.

Kafka share group은 한 파티션을 여러 소비자가 협력해 처리하므로 파티션 수보다 많은 작업자를 둘 수 있다. 개별 레코드의 작업 분배가 목적이라면 유용하지만 일반 소비자 그룹의 파티션별 순서 모델과 동일하게 취급해서는 안 된다. RabbitMQ super stream도 스트림을 분할해 소비를 확장하며, 순서의 경계는 각 분할 스트림이다. 결국 전체 순서, 주문별 순서, 개별 작업의 병렬 처리 가운데 무엇이 필요한지가 확장 방식의 출발점이다.

요구 사항을 점수로 바꾸면 무엇이 남나

다음 점수는 제품의 성능 평가가 아니라 선택할 구성의 적합도를 따져 보는 편집 기준이다. 요구를 해당 소비 방식이 직접 충족하면 2점, 애플리케이션 설계가 더 필요하면 1점, 충족하지 못하면 0점을 준다. 필수 요구에서 0점이 나오면 다른 항목의 합계가 높아도 그 구성을 제외한다.

작업별 완료와 실패 처리: RabbitMQ 큐는 메시지별 확인과 재전달을 기본 흐름으로 삼으므로 2점이다. Kafka share group도 레코드별 확인이 가능하므로 그 요구에는 2점이지만, 서비스에 필요한 지연 재시도나 실패 경로를 별도로 만들어야 한다면 해당 요구에는 1점을 준다.
독립적인 재읽기: 기록 보존을 설정한 Kafka 토픽과 RabbitMQ 스트림은 각각 2점이다. 완료된 작업을 제거하는 일반 RabbitMQ 큐는 과거 이벤트의 반복 소비라는 요구에 0점이다.
순서와 병렬성: 키별 파티션 순서가 요구라면 Kafka 소비자 그룹에, 분할 스트림 단위의 순서가 맞다면 RabbitMQ super stream에 각각 2점을 줄 수 있다. 모든 작업을 하나의 순서로 처리해야 한다면 소비자를 늘리는 방식에는 제약이 생긴다.
메시지별 라우팅: 교환기 규칙으로 서로 다른 작업 큐에 보내야 한다면 RabbitMQ 구성에 2점을 준다. Kafka에서 토픽 설계나 소비 애플리케이션이 분기를 맡아야 한다면 추가 구현 범위에 따라 1점이다.
운영 부담: 이미 운영하는 클러스터와 장애 대응 경험을 활용할 수 있다면 해당 구성에 2점을 준다. 새 저장 구조를 도입하며 보존량, 소비 위치, 장애 대응 절차까지 마련해야 한다면 필요한 인력과 비용을 따로 기록한다.

예를 들어 개별 작업 완료, 실패 재시도, 메시지별 라우팅이 핵심인 가상의 백그라운드 작업 서비스라면 RabbitMQ 큐의 점수가 높다. 여러 서비스가 주문 이벤트를 독립적으로 다시 읽고 키별 상태를 재구성해야 하는 가상의 시스템이라면 Kafka 토픽이 앞설 수 있다. RabbitMQ 스트림과 Kafka share group까지 후보에 넣으면 제품별 점수보다 구성별 점수가 더 유용해진다.

처리량 수치는 같은 조건에서만 의미가 있다

Kafka와 RabbitMQ 스트림의 처리량을 같은 확인·복제 조건에서 비교하는 구성

Kafka 토픽과 RabbitMQ 일반 큐의 최고 처리량을 나란히 놓으면 저장·소비 방식의 차이까지 속도 차이로 읽기 쉽다. 스트리밍 요구라면 Kafka 토픽과 RabbitMQ 스트림을 비교하고, 작업 분배 요구라면 각 제품에서 실제 채택할 소비 방식을 명시해야 한다. RabbitMQ의 기술 비교는 스트리밍 구성에서 두 시스템의 처리량과 지연이 비슷한 범위에 들 수 있다고 설명하면서, 한쪽만 적극적으로 조정한 벤치마크를 경계한다.

메시지 크기와 발행률, 배치·청크 크기, 압축, 복제 수, 발행 확인, 소비자 확인, 디스크와 네트워크 조건을 함께 봐야 한다. 발행 확인을 기다리지 않는 구성과 복제된 기록의 확인을 기다리는 구성을 같은 초당 메시지 수로 비교하면 보장 수준부터 다르다. 평균 지연 외에도 부하가 몰릴 때의 적체와 소비자 장애 뒤 재전달 동작이 서비스 요구에 맞는지 살펴야 한다.

2017년에 제출된 Kafka와 RabbitMQ 비교 연구는 공통 기능의 정성적·실증적 비교와 사용 사례별 선택표를 제시했다. 그 실험 수치를 현재 구성의 절대적인 성능 순위로 옮길 수는 없다. 두 제품 모두 이후 소비 방식을 확장했기 때문이다. 오래된 결과에서도 유효한 질문은 어느 제품이 무조건 빠른가가 아니라 어떤 기능과 워크로드를 같은 조건에 놓고 측정했는가다.

운영 비용까지 넣어 구성을 고른다

두 구성이 필수 요구를 모두 충족한다면 운영 체계가 선택을 가른다. Kafka에서는 파티션 수, 보존 정책, 소비 지연과 그룹 재조정을 관리해야 한다. RabbitMQ에서는 큐 유형, 라우팅 규칙, 미확인 작업과 재전달 정책이 관리 대상이다. RabbitMQ 스트림까지 사용한다면 일반 큐의 작업 완료 관리에 더해 기록 보존량과 소비 위치도 다뤄야 한다.

따라서 필수 소비 방식과 순서의 범위로 후보를 좁힌 뒤, 재처리 기간과 실패 처리에 맞는 구성을 남기는 순서가 합리적이다. 처리량은 그렇게 남은 구성들을 실제 메시지 크기와 발행 패턴, 비교 가능한 확인·복제 조건에서 측정할 때 선택 근거가 된다.

함께 읽기: