메시지 처리 비교 - 최신 기술 뉴스 정보 모두

분산 아키텍처에서는 시스템 간의 통신이 전체 인프라의 기초를 형성합니다. 인프라의 성능, 확장성 및 안정성은 이벤트/메시지/데이터가 교환되고 지속되는 방식에 따라 크게 달라집니다.

Kafka와 NATS는 스트리밍 및 메시징을 처리하는 데 널리 사용되는 두 가지 도구입니다. 그들은 서로 다른 아키텍처와 서로 다른 성능 특성을 가지고 있습니다. 특정 사용 사례에 적합합니다. 이 글에서는 NATS와 Kafka의 기능을 비교하고 제가 직장에서 다룬 사용 사례를 설명하겠습니다.

1. 아키텍처와 복잡성

NAT

NATS 인프라에는 두 가지 주요 구성 요소가 있습니다.

핵심 NAT

Core NATS는 기본 메시징 프레임워크입니다. 이는 게시-구독(메시지를 여러 구독자에게 브로드캐스트할 수 있음), 요청-응답(동기 통신 활성화) 및 대기열 그룹(그룹 내 여러 구독자 간의 로드 밸런싱을 용이하게 함)을 지원합니다.

이는 단순성, 낮은 대기 시간, 고성능 및 확장성을 위해 설계되었습니다. 낮은 대기 시간과 높은 처리량이 필요한 시나리오에서 매우 잘 작동합니다. 그러나 Core NATS만으로는 보장되지 않는 전달만 제공합니다. 즉, 메시지는 활성 가입자에게만 전달됩니다. 구독자가 오프라인이면 데이터가 손실됩니다. Core NATS는 내구성보다 속도와 규모가 우선시되는 경우 좋은 옵션입니다.

제트스트림

JetStream은 Core NATS의 최고 수준에 지속성 기능을 제공합니다. 이는 메시지 내구성과 신뢰성을 제공하는 데 도움이 되었습니다. 이를 통해 메시지나 이벤트가 지속되고(디스크 또는 메모리) 재생될 수 있습니다. 지속형 메시지는 신규 구독자나 복구 구독자에게 재생될 수 있습니다. JetStream을 사용하면 사용자는 다음과 같은 추가 기능을 얻을 수 있습니다.

스트림 보존: 메시지가 보관되는 기간입니다. 이는 크기, 시간 또는 소비자 제한을 기반으로 할 수 있습니다.
소비자 내구성: 소비자가 중단한 부분부터 다시 시작할 수 있도록 합니다.
메시지 확인: 배송의 신뢰성을 보장합니다.

JetStream은 Core NATS에 복잡성 계층을 추가합니다. 그러나 이는 보장된 전달, 지속성 및 재생 가능성의 사용 사례를 지원하는 중요한 기능을 제공합니다.

카프카

Kafka는 로그 기반 브로커 아키텍처를 기반으로 구축된 분산 메시징 시스템입니다. Kafka의 데이터는 주제로 정렬되며 여러 파티션을 가질 수 있습니다. 소비자는 이러한 파티션에 연결됩니다. 이 아키텍처를 통해 Kafka는 단일 주제에 대한 메시지 소비를 병렬화할 수 있습니다. 데이터는 주제/파티션에 순차적으로 추가됩니다. Kafka는 파티션 순서를 보장합니다. Kafka 클러스터에는 각각 주제 및 파티션 목록을 관리하는 여러 브로커가 있을 수 있습니다. 고가용성을 달성하고 데이터 손실을 방지하기 위해 Kafka는 파티션이 여러 Kafka 브로커에 복제되는 복제 요소를 사용합니다. 보시다시피 높은 처리량, 내결함성, 데이터 보존 및 수평 확장성을 달성하기 위해 관리해야 하는 여러 구성 요소가 있습니다. 이로 인해 Kafka의 아키텍처 복잡성이 증가합니다.

2. 고가용성 및 성능

NAT

클러스터의 모든 노드는 메시로 상호 연결되며 클라이언트는 모든 노드에 연결할 수 있습니다. 이 구성은 단일 실패 지점을 방지합니다. 한 노드에 장애가 발생하면 클라이언트는 수동 개입 없이 자동으로 다른 노드에 연결됩니다. 이를 NATS에서는 자가 치유라고 합니다. JetStream 지원 노드는 모든 노드에 스트림을 배포합니다. 스트림은 메쉬 클러스터 내의 JetStream 지원 노드 전반에 걸쳐 고도로 관리되고 부하 분산됩니다.

JetStream은 또한 여러 클러스터 또는 노드에 걸친 데이터 미러링을 지원합니다. JetStream에서는 스트림별로 리더가 선출됩니다. 각 스트림의 복제를 구성할 수 있습니다. 이 모든 것이 NATS의 내구성과 가용성을 보장합니다.

카프카

Kafka의 고가용성은 복제를 기반으로 합니다. 모든 주제에는 하나 이상의 파티션이 있을 수 있습니다. 각 파티션은 Kafka Broker를 통해 복제됩니다. 이는 데이터 중복성과 가용성을 보장합니다. Kafka는 Leader-Follower 복제 메커니즘을 따릅니다. 리더는 읽기와 쓰기를 담당합니다. 그리고 Follower는 데이터를 복제하는 작업을 합니다.

Kafka는 각 파티션에 대해 ISR(In Sync Replicas)이라는 것을 유지 관리합니다. 리더가 실패하면 ISR 중 하나가 리더가 됩니다. 클러스터 메타데이터 관리 및 리더 선택을 위해 Kafka는 Zookeeper(최신 버전에서는 KRaft)를 사용합니다.

성능 및 확장성
특징	NAT	카프카
처리량	높거나 낮은 지연 시간. 작은 메시지에 최적화됨	높은 처리량 및 대용량 메시지에 최적화됨
스케일링	클러스터링을 통해 수평 확장 가능	파티셔닝을 통해 수평 확장 가능
숨어 있음	밀리초 미만	밀리초

복구 및 FAILOver
특징	NAT	카프카
장애 조치 시간	1초 미만(클라이언트 재연결 속도 향상)	느림(리더 선출 과정에 따라 다름)
원활한 복구	클라이언트는 중단 없이 자동 연결됩니다.	리더 선출 중 일부 다운타임
데이터 손실 위험	복제 시 최소(JetStream)	복제 및 ISR이 구성된 경우 최소

3. 메시지 패턴

NAT

NATS는 주제 기반 메시징을 사용합니다. 이를 통해 서비스와 스트림이 Pub-Sub, 요청-응답 및 대기열 구독자 패턴을 사용할 수 있습니다. NATS의 주제는 계층 구조와 와일드카드를 사용하여 구성될 수 있습니다. 단일 NATS 스트림은 여러 주제를 저장할 수 있으며 클라이언트 애플리케이션은 서버 측 필터링을 사용하여 관심 있는 주제만 수신할 수 있습니다. NATS의 연결은 양방향이며 클라이언트가 동시에 게시하고 구독할 수 있도록 합니다. NATS는 RabbitMQ와 매우 유사한 대기열도 지원합니다.

카프카

Kafka의 스트림은 Pub-sub 및 주제 기반 메시징을 지원합니다. 로드 밸런싱은 소비자 그룹 및 주제 분할을 통해 달성할 수 있습니다.

4. 배송 보증

NAT

NATS는 다양한 배달 보장을 지원합니다. NATS만으로도 최대 1회 전달 보장을 지원할 수 있습니다. JetStream이 활성화된 NATS 서버는 추가로 두 가지 유형의 보장을 지원할 수 있습니다. 이는 “적어도 한 번” 및 “정확히 한 번”을 보장합니다. NATS는 개별 메시지에 ‘ack’을 보낼 수 있습니다. 지원하는 다양한 ‘ack’에 대해서는 NATS 공식 문서를 참조하세요. NATS는 ‘acks’ 유형에 따라 메시지를 다시 전달할 수 있습니다.

카프카

Kafka는 최소 한 번, 정확히 한 번 보장을 지원합니다. 메시지 순서는 파티션 수준에서 보장됩니다. Kafka에서는 글로벌 주문이 불가능합니다.

5. 메시지 보존 및 지속성

NAT

NATS는 메모리 및 파일 기반 지속성을 지원합니다. 메시지를 재생하는 데는 여러 가지 옵션이 있습니다. 메시지 재생은 시간, 개수 또는 시퀀스 번호별로 이루어질 수 있습니다.

카프카

KAFKA는 파일 기반 지속성만 지원합니다. 메시지는 최신, 최초 또는 특정 오프셋에서 재생할 수 있습니다. KAFKA에서는 로그 압축이 지원됩니다.

6. 언어 및 플랫폼

NAT

48개의 알려진 클라이언트 유형. GOLANG을 지원하는 모든 아키텍처는 NATS 서버를 지원할 수 있습니다.

카프카

18개의 알려진 클라이언트 유형. Kafka 서버는 JVM을 지원하는 플랫폼에서 실행될 수 있습니다.

사용 사례

사용 사례 1

요구사항

우리는 스트리밍 파이프라인을 갖춘 데이터 플랫폼을 보유하고 있습니다. 플랫폼은 실시간 스트리밍을 위해 Apache Flink 엔진을 사용하고 분석 파이프라인을 작성하기 위해 Apache Beam을 사용합니다. 주요 요구 사항은 다음과 같습니다.

높은 처리량 및 짧은 대기 시간 메시지 처리
체크포인트 및 배압 처리 지원
MB 단위로 메시지 처리
메시지 내구성 및 지속성

비교

카프카의 장점에스:

높은 처리량
구성 가능한 보존 정책을 통한 데이터 보존 및 내결함성을 위한 데이터 복제
하나 이상의 메시지 전달 보장 지원
가장 빠른/최신/특정 오프셋에서 메시지 읽기
안정적인 전달을 위한 서버측 ‘ack’
대규모 데이터 스트림과 대용량 메시지 처리
압축 주제 지원

카프카 단점:

리소스 사용량이 높습니다. 우리 클러스터는 온프레미스였으며 리소스가 제한되어 있었습니다.
Kafka는 실시간에 가깝습니다.

NATS의 장점:

최소한의 리소스 사용으로 고성능을 구현합니다. 우리 클러스터는 리소스 제약이 있는 온프레미스 클러스터입니다.
적어도 한 번은 지원하십시오. 우리는 적어도 한 번은 보증을 찾고 있었습니다.
지연 시간이 짧은 메시지 처리

NATS의 단점:

Flink/Beam용 커넥터가 없어 통합이 어려웠습니다.
메시지 크기에 따른 성능 저하

최종 결정

신중한 분석 끝에 Kafka가 선택되었습니다. 우리는 리소스 사용량과 Kafka가 제공하는 다른 이점, 특히 Apache Beam 및 Flink와의 우수한 통합 사이에서 균형을 맞춰야 했습니다. Kafka의 또 다른 장점은 큰 메시지 크기와 높은 처리량의 메시지 처리를 처리한다는 것입니다.

사용 사례 2

요구사항

온프레미스 클러스터(예: 감사 로그)에서 생성된 이벤트를 처리합니다. 이벤트는 낮은 지연 시간으로 처리되어야 합니다. 그리고 마이크로서비스 통신을 지원합니다. 내구성과 지속성은 요구 사항이 아니었습니다. 메시지 크기가 작았습니다. 이벤트에 대한 분석을 수행할 필요가 없습니다. 우리는 제한된 환경에 있었습니다. 리소스 사용량과 메모리 공간은 최소화되어야 합니다.

결정

NATS를 선택한 이유:

효율적인 자원 활용
낮은 대기 시간 이벤트 처리.
Go 애플리케이션이므로 메모리 사용량이 매우 낮습니다.
작은 메시지 크기를 처리하는 능력
마이크로서비스 통신에 도움이 될 수 있는 요청-응답 지원
JetStream이 구성되지 않으면 메시지가 저장되지 않습니다

카프카가 선택되지 않은 이유:

기본적으로 메시지는 디스크에 저장됩니다.
NATS에 비해 리소스 사용량이 높습니다.
JVM이 필요하기 때문에 메모리 공간이 매우 높습니다.

요약

Kafka와 NATS 사이의 선택은 아키텍처 및 복잡성, 성능 및 확장성, 메시지 전달 보장이라는 세 가지 주요 영역의 특정 요구 사항에 따라 달라집니다. Kafka는 강력한 이벤트 스트리밍, 내구성 있는 스토리지 및 고급 처리 기능이 필요한 시스템에 이상적이지만 복잡성이 더 높습니다. 반면 NATS는 가볍고 관리하기 쉬우며 메시징 요구 사항이 더 간단하고 대기 시간이 짧고 처리량이 많은 시나리오에서 탁월합니다.

분산 메시징 시스템을 설계할 때 이러한 영역을 신중하게 평가하여 선택 사항이 애플리케이션의 목표 및 제약 조건에 부합하도록 하십시오. Kafka와 NATS는 모두 강력한 도구이므로 사용 사례에 따라 올바른 선택이 달라집니다.

Kafka와 NATS 중에서 선택하기 전에 고려해야 할 주요 영역은 다음과 같습니다.