Kafka와 Redis의 차이점은 무엇인가요?
Redis는 인 메모리 키-값 데이터 스토어이고 Apache Kafka는 스트림 처리 엔진입니다. 하지만 두 기술 모두 게시/구독(pub/sub) 메시징 시스템을 구축하는 데 사용할 수 있으므로 두 기술을 비교할 수 있습니다. 최신 클라우드 아키텍처에서는 애플리케이션이 서비스라고 불리는 더 작고 독립적인 빌딩 블록으로 분리됩니다. 게시/구독 메시징은 이러한 분산 시스템을 위한 즉각적인 이벤트 알림을 제공합니다. Kafka는 게시자와 구독자가 공통 메시지 대기열을 공유하여 구독자가 필요에 따라 메시지를 가져오는 풀 기반 시스템을 지원합니다. Redis는 이벤트 발생 시 게시자가 모든 구독자에게 메시지를 배포하는 푸시 기반 시스템을 지원합니다.
작동 방식: Kafka vs. Redis 게시/구독
Apache Kafka는 여러 애플리케이션이 서로 독립적으로 데이터를 스트리밍할 수 있게 해주는 이벤트 스트리밍 플랫폼입니다. 생산자 및 소비자라고 하는 이러한 애플리케이션은 주제라고 하는 특정 데이터 파티션에 정보를 게시하고 구독합니다.
한편 Redis는 애플리케이션 간 지연 시간이 짧은 데이터 전송을 지원하는 인 메모리 데이터베이스로 설계되었습니다. 모든 메시지를 하드 디스크 대신 RAM에 저장하여 데이터 읽기 및 쓰기 시간을 줄입니다. Kafka와 마찬가지로 여러 소비자가 Redis 스트림을 구독하여 메시지를 검색할 수 있습니다.
게시/구독 메시징에 둘 다 사용할 수 있지만 Kafka와 Redis는 다르게 작동합니다.
Kafka 워크플로
Apache Kafka는 컴퓨팅 클러스터를 통해 생산자와 소비자를 연결합니다. 각 클러스터는 서로 다른 서버에 있는 여러 Kafka 브로커로 구성됩니다.
Kafka는 다음과 같은 목적으로 주제 및 파티션을 생성합니다.
- 이메일, 결제, 사용자, 구매 등 관심 주제에 속하는 유사 데이터를 그룹화하는 주제
- 데이터 복제 및 내결함성을 위해 여러 브로커에 걸쳐 파티셔닝
생산자는 브로커에게 메시지를 게시합니다. 브로커는 메시지를 수신하면 데이터를 주제로 분류하고 데이터를 파티션에 저장합니다. 소비자는 관련 주제에 연결하여 해당 파티션에서 데이터를 추출합니다.
Redis 워크플로
Redis는 클라이언트-서버 아키텍처를 사용하여 NoSQL 데이터베이스 시스템으로 실행됩니다. 생산자와 소비자는 서로 긴밀하게 연결되어 있기 때문에 메시지를 보낼 때 서로를 알 필요가 없습니다.
Redis는 다음과 같은 목적으로 키와 기본-보조 노드를 사용합니다.
- 유사한 메시지를 그룹화하는 키. 예를 들어 '이메일'은 이메일 메시지만 보관하는 데이터 스토어를 가리키는 키입니다.
- 메시지 복제를 위한 기본-보조 노드.
생산자가 특정 노드에 메시지를 보내면 Redis는 메시지 키를 확인하여 연결된 모든 가입자에게 메시지를 전달합니다. 소비자는 메시지를 수신하기 위해 항상 Redis 서버와의 활성 연결을 시작하고 유지해야 합니다. 이를 연결된 전송 체계라고 합니다.
메시지 처리: Kafka vs. Redis 게시/구독
Apache Kafka는 개발자에게 확장성이 뛰어난 분산 메시징 시스템을 제공합니다. 한편 Redis는 애플리케이션이 데이터를 여러 노드로 신속하게 푸시할 수 있도록 하는 풍부한 데이터 구조를 제공합니다. 두 시스템 모두 메시지 대기열 메커니즘에 몇 가지 차이점이 있습니다.
메시지 크기
Kafka와 Redis는 소비자와 구독자 간에 작은 크기의 데이터 패킷을 전송할 때 가장 잘 작동합니다.
특히 Redis는 대규모 데이터를 처리할 때 처리량에 영향을 주도록 설계되었습니다. 또한 RAM은 디스크 스토리지보다 용량이 작기 때문에 많은 양의 데이터를 저장할 수 없습니다.
한편, Kafka는 특별히 제작되지 않았음에도 불구하고 상당히 큰 메시지를 지원할 수 있습니다. Kafka는 메시지를 압축하고 계층형 스토리지용으로 구성한 경우 1GB 이내의 메시지를 처리할 수 있습니다. 모든 메시지를 로컬 스토리지에 저장하는 대신 원격 스토리지를 사용하여 완료된 로그 파일을 저장합니다.
메시지 전송
Kafka 소비자는 메시지 대기열에서 데이터를 가져옵니다. 각 Kafka 소비자는 읽은 메시지를 오프셋과 함께 추적하고, 오프셋을 업데이트하여 후속 메시지를 검색합니다. 소비자는 중복 메시지를 감지하고 추적할 수 있습니다.
반면 Redis는 연결된 구독자에게 메시지를 자동으로 푸시합니다. Redis 구독자는 서버에서 수신되는 메시지를 수동적으로 기다립니다. 최대 1회 전송으로 설정되었으므로 Redis 구독자는 중복 메시지를 감지할 수 없습니다.
메시지 보존
Kafka는 소비자가 메시지를 읽은 후에도 메시지를 보관합니다. 따라서 클라이언트 애플리케이션에서 검색된 데이터가 손실되는 경우, 해당 데이터를 구독하는 파티션에서 다시 요청할 수 있습니다. 메시지 보존 정책을 설정하여 사용자는 Kafka가 데이터를 보관하는 기간을 결정할 수 있습니다.
반대로 Redis는 메시지가 전송된 후에는 메시지를 저장하지 않습니다. 스트림에 연결된 구독자가 없는 경우 Redis는 메시지를 삭제합니다. 삭제된 메시지는 구독자가 나중에 Redis에 연결하더라도 복구할 수 없습니다.
오류 처리
Kafka와 Redis는 모두 애플리케이션이 신뢰할 수 없는 메시지 전달을 완화할 수 있게 해주지만, 작동 방식은서로 다릅니다.
Redis에서의 오류 처리는 클라이언트 애플리케이션과 Redis 서비스 간의 상호 작용에 중점을 둡니다. Redis를 통해 개발자는 클라이언트 타임아웃, 메모리 버퍼 초과, 최대 클라이언트 제한 등과 같은 상황을 해결할 수 있습니다. 키-값 쌍 데이터베이스 아키텍처 때문에 Redis는 Kafka처럼 강력한 메시지 오류 처리를 제공할 수 없습니다.
Kafka 개발자는 오류가 있는 이벤트를 배달 못한 편지 대기열에 저장하고 이를 재시도하거나 리디렉션하여 클라이언트 애플리케이션에 일관된 메시지 전달이 가능하도록 할 수 있습니다. 또한 개발자는 Kafka Connect API를 사용하여 특정 오류가 발생하면 커넥터 작업을 자동으로 다시 시작할 수 있습니다.
성능 차이: Kafka vs. Redis 게시/구독
전반적으로 Apache Kafka는 게시/구독 메시징에서 Redis를 능가합니다. Kafka는 데이터 스트리밍을 위해 특별히 설계되었기 때문입니다. Redis에는 Kafka를 사용할 수 없는 여러 가지 사용 사례가 있습니다.
병렬 처리
병렬 처리란 여러 사용자가 동일한 메시지를 동시에 수신할 수 있는 기능입니다.
Redis는 병렬 처리를 지원하지 않습니다.
반면 Kafka를 사용하면 동일한 메시지를 여러 소비자에게 동시에 배포할 수 있습니다. 일반적으로 Kafka 소비자 그룹의 소비자는 교대로 파티션에서 새 메시지를 검색합니다. 여러 소비자 그룹에 소비자가 한 명뿐인 경우 모든 메시지를 검색합니다. 이러한 설정 및 분할 영역 복제를 활용하여 각 분할 영역 복제본에서 각 소비자 그룹에 한 명의 소비자를 할당할 수 있습니다. 이를 통해 모든 소비자는 비슷한 메시지 시퀀스를 검색할 수 있습니다.
처리량
처리량은 각 시스템이 초당 처리할 수 있는 메시지 수를 측정합니다.
Kafka는 일반적으로 Redis 게시/구독보다 처리량이 높습니다. Kafka는 각 구독자가 다른 구독자로 이동하기 전에 메시지를 수신할 때까지 기다릴 필요가 없기 때문에 훨씬 더 많은 양의 데이터를 처리합니다. 대신 현재 메시지를 메모리 캐시와 스토리지에 저장하여 읽기 속도를 최적화합니다.
그러나 소비자가 메시지를 충분히 빨리 검색하지 않으면 캐시에서 읽지 않은 메시지가 결국 제거되므로 Kafka의 성능이 저하될 수 있습니다. 이 경우 소비자는 디스크에서 읽어야 하므로 속도가 느려집니다.
한편 Redis는 각 소비자의 승인을 기다려야 하므로 연결된 노드가 많을수록 처리량이 크게 감소합니다. 해결 방법은 파이프라이닝이라는 프로세스를 사용하여 여러 요청을 보내는 것이지만, 이렇게 하면 메시징 지연 시간이 줄어듭니다.
지연 시간
Kafka와 Redis는 모두 지연 시간이 짧은 데이터 처리에 적합합니다. Redis는 밀리초 단위의 낮은 메시징 시간을 제공하는 반면 Kafka의 메시징 시간은 평균 수십 밀리초입니다.
Redis가 주로 RAM에서 데이터를 읽고 쓰는 것을 고려하면 속도면에서 당연히 Kafka를 능가합니다. 하지만 Redis는 대용량 메시지를 처리할 때 지연 시간이 매우 짧은 데이터 작업을 계속해서 진행하지 못할 수 있습니다. 한편, Kafka는 데이터 지속성을 위해 서로 다른 물리적 드라이브에 파티션을 복제하는 데 더 많은 시간이 필요하기 때문에 메시지 전송 시간에 오버헤드가 가중됩니다.
Redis와 Kafka의 지연 시간을 최적화하는 것은 가능하지만 신중히 해야 합니다. 예를 들어 Kafka 메시지를 압축하여 지연 시간을 줄일 수 있지만 생산자와 소비자는 메시지를 압축 해제하는 데 더 많은 시간이 필요합니다.
Redis의 지연 시간은 운영 환경, 네트워크 운영, 느린 명령 또는 포크를 비롯한 여러 요인으로 인해 발생할 수 있습니다. 포크 지연을 줄이기 위해 Redis는 하드웨어 가상 머신(HVM) 기반의 최신 EC2 인스턴스에서 게시/구독 전송 시스템을 실행할 것을 권장합니다.
내결함성
Kafka는 모든 데이터를 주요 브로커의 스토리지 디스크에 쓰고 여러 서버에 복제합니다. 서버에 장애가 발생하면 여러 가입자가 백업 파티션에서 데이터를 검색합니다.
Kafka와 달리 Redis는 기본적으로 데이터를 백업하지 않으므로 사용자가 이 기능을 수동으로 활성화해야 합니다. Redis는 전원이 꺼지면 모든 데이터가 손실되는 인 메모리 데이터 스토어를 사용합니다. 이를 방지하기 위해 개발자는 Redis Database(RDB) 지속성을 켜서 RAM 데이터의 스냅샷을 주기적으로 캡처하여 디스크에 저장합니다.
사용 시기: Kafka vs. Redis 게시/구독
Apache Kafka는 대규모 데이터 세트를 스트리밍하고 높은 복구 성능이 필요한 애플리케이션을 구축하는 데 더 적합합니다. 전달되는 수조 개의 메시지를 처리할 수 있는 단일 분산 데이터 파이프라인으로 처음에 개발되었습니다. Kafka는 여러 서버에 파티션을 복제하여 노드 장애 시 데이터 손실을 방지합니다. 조직은 Kafka를 사용하여 애플리케이션, 모바일 사물 인터넷(IoT) 장치 및 마이크로서비스 간의 실시간 통신을 지원합니다. 또한 로그 집계, 스트림 처리, 기타 클라우드 기반 데이터 통합 작업을 위한 더 나은 선택입니다.
한편 Redis는 즉각적인 데이터 전송이 필요하지만 데이터 손실이 적은 애플리케이션을 위해 지연 시간이 매우 짧은 이벤트 배포를 제공합니다. 일반적으로 Redis는 자주 액세스하는 데이터를 저장하거나 긴급 메시지를 전달하는 세션 캐시로 사용됩니다. 또한 게임, 전자 상거래 또는 소셜 미디어 데이터를 저장하여 보다 원활한 사용자 경험을 제공하는 데에도 적합합니다.
차이점 요약: Kafka vs Redis 게시/구독
| Apache Kafka |
Redis |
|
| 메시지 크기 |
압축 및 계층형 스토리지로 최대 1GB의 메시지 크기를 지원합니다. |
더 작은 메시지 크기를 지원합니다. |
| 메시지 전송 |
구독자는 대기열에서 메시지를 가져옵니다. |
Redis 서버는 연결된 가입자에게 메시지를 푸시합니다. |
| 메시지 보존 |
검색 후 메시지를 보존합니다. |
메시지를 보관하지 않습니다. |
| 오류 처리 |
메시징 수준에서의 강력한 오류 처리. 배달 못한 편지 대기열, 이벤트 재시도 및 리디렉션. |
제한 시간, 클라이언트 제한 및 메모리 버퍼 용량을 사용하여 애플리케이션 수준에서 Redis 예외를 처리해야 합니다. |
| 병렬 처리 |
Kafka는 병렬 처리를 지원합니다. 여러 소비자가 동일한 메시지를 동시에 검색할 수 있습니다. |
병렬 처리를 지원하지 않습니다. |
| 처리량 |
비동기 읽기/쓰기로 인해 처리량이 더 높습니다. |
Redis 서버가 다른 구독자에게 메시지를 보내기 전에 회신을 기다려야 하기 때문에 처리량이 줄어듭니다. |
| 지연 시간 |
짧은 지연 시간. 기본적으로 데이터 복제로 인해 Redis보다 약간 느립니다. |
작은 크기의 메시지를 배포할 때 지연 시간이 매우 짧습니다. |
| 내결함성 |
파티션을 다른 브로커에 자동으로 백업합니다. |
기본적으로 백업되지 않습니다. 사용자는 Redis 지속성을 수동으로 활성화할 수 있습니다. 소규모 데이터 손실 위험. |
AWS는 Kafka 및 Redis 요구 사항을 어떻게 지원할 수 있나요?
Amazon Web Services(AWS)는 게시-구독 메시징 요구 사항을 지원하는 확장 가능한 관리형 인프라를 제공합니다.
Amazon Managed Streaming for Apache Kafka(Amazon MSK)을 사용하면 대용량의 데이터를 실시간으로 쉽게 수집하고 처리할 수 있습니다. 사설 액세스 데이터 버스를 구축하여 대규모로 고가용성 스트리밍 노드를 제공할 수 있습니다. 또한 AWS IoT Core, Amazon Virtual Private Cloud(Amazon VPC), Amazon Managed Service for Apache Flink 등 다른 AWS 서비스에도 원활하게 연결할 수 있습니다.
Amazon MemoryDB를 사용하면 Redis 워크로드에 고가용성 인 메모리 스토리지를 제공할 수 있습니다. 동시성이 높은 스트리밍 데이터 피드를 실행하여 사용자 활동을 수집할 수 있습니다. 또한 미디어 및 엔터테인먼트 애플리케이션에 대한 하루 수백만 건의 요청을 지원할 수 있습니다.
Redis 또는 Kafka 대신 Amazon Simple Notification Service(Amazon SNS)를 사용하여 게시/구독 메시징 시스템을 구축할 수도 있습니다. 확장 가능하고 비용 효율적인 방법으로 애플리케이션에서 고객 또는 애플리케이션으로 메시지를 직접 전송할 수 있습니다. Amazon SNS는 다음과 같은 몇 가지 기능을 제공합니다:
- 분산된 시스템, 마이크로서비스 및 이벤트 중심의 서버리스 애플리케이션 간의 스루풋이 높은 푸시 기반의 다대다 메시징.
- 메시지 암호화 및 트래픽 프라이버시.
- AWS 카테고리 전반의 팬아웃 기능. 여기에는 분석, 컴퓨팅, 컨테이너, 데이터베이스, 사물 인터넷(IoT), 기계 학습(ML), 보안 및 스토리지가 포함됩니다.
지금 바로 계정을 만들어 AWS에서 게시/구독, Redis 및 Kafka를 시작해 보세요.
