영문 독해 연습을 위해 번역한 글이라 의역, 오역이 있을 수 있습니다.
잘못된 부분이 있다면, 댓글로 알려주시면 감사하겠습니다🙏
Redis vs Kafka vs RabbitMQ
마이크로서비스 환경에서 비동기 통신을 할 때, 메세지 브로커를 사용하는 것이 일반적입니다.
메세지 브로커는 서로 다른 마이크로서비스 간 신뢰성, 안정성을 보장하며, 시스템 내에서 메세지를 관리하고 모니터링 하고 메세지가 손실되지 않도록 합니다.
다양한 규모와 데이터 수용력에 따라 선택할 수 있는 몇개의 메세지 브로커가 있는데요.
이 글에서는 가장 유명한 3개의 메세지 브로커를 비교할 것 입니다.(RabbitMQ, Kafka, Redis)
Microservices Communication: Synchronous and Asynchronous
마이크로서비스 통신: 동기와 비동기
마이크로서비스 간 서로 통신할 때 일반적으로 2가지 방법이 있습니다.(동기, 비동기)
동기 통신에서는 호출자는 다음 메세지를 보내기 전에 응답을 기다리는데, HTTP 위에서 동작하는 REST 프로토콜이 이와 같이 동작합니다.
반대로, 비동기 통신에서는 메세지를 보내고 응답을 기다리지 않습니다.
이는 분산 시스템과 어울리는 방식이고 대부분의 경우 메세지를 관리하기 위해 메세지 브로커를 필요로 합니다.
선택한 통신 종류(동기, 비동기)는 다양한 요소에 따라 고려해야 하는데, 예를 들어 마이크로서비스를 어떻게 구성할 것인지, 어떤 인프라를 갖추고 있는지, 응답지연, 확장성, 의존성 그리고 통신의 목적 등을 을 고려해야 합니다.
비동기 통신은 설정하기 더 어려울 수 있고 더 많은 컴포넌트를 필요로 할 수 있지만, 마이크로서비스에 비동기 통신을 사용하는것은 단점보다 장점이 더 많습니다.
Asynchronous Communication Advantages
비동기 통신의 장점
정의에 따르면 비동키 통신은 논-블로킹이고, 동기 통신보더 다 나은 확장성을 지원합니다.
그리고 마이크로서비스에 문제가 발생했들 때, 비동기 통신 메커니즘은 다양한 복구 기술을 제공하고 일반적으로 문제상황과 관련된 에러를 더 잘 처리합니다.
추가로, REST 프로토콜 대신 브로커를 사용할 때, 통신을 받는 서비스는 서로를 몰라도 됩니다.
오랜기간 레거시 서비스가 실행된 후에도 새로운, 더 나은 디커플링 서비스를 도입할 수 있습니다.
마지막으로, 비동기 작업을 선택하면, 중앙 검색, 모니터링, 로드밸런싱, 정책 수행기 등을 생성하는 기능이 향상됩니다.
이는 당신의 코드와 시스템 구성에 유연성, 확장성, 수용력을 제공할 것 입니다.
Choosing the Right Message Broker
올바른 메세지 브로커 고르기
비동기 통신은 대게 메세지 브로커를 통해 관리됩니다.
aysncio 라는 다른 방법도 있지만, 이는 조금 부족하고 제한적입니다.
당신의 비동기 작업을 실행할 브로커를 선택할 때, 다음 항목을 고려해야 합니다.
- 브로커 규모 - 초당 시스템에서 보내는 메세지 수
- 데이터 지속성 - 메세지를 복구하는 능력
- 소비자 수용력 - 브로커가 일대일 또는 일대다 소비자를 수용할 수 있는지 여부
One-to-One
One-to-Many
위 3가지 항목에 대해서 어떤 공급자가 가장 강력한지 확인하기 위해 최신의 최고의 서비스들을 확인했습니다.
Comparing Different Message Brokers
메세지 브로커 비교
RabbitMQ(AMQP)
- 브로커 규모 : 설정이나 하드웨어 자원에 따라 초당 약 50,000개의 메세지
- 데이터 지속성 : 지속성 메세지와 일시적 메세지를 모두 지원함
- 일대일 / 일대다 : 둘 다 지원
RabbitMQ 는 2007년에 배포된 최초의 메세지 브로커 중 하나입니다.
AMQP(향상된 메세지 큐잉 프로토콜)을 구현하여 지점간, 게시-구동 기능을 제공하는 오픈소스 입니다.
이는 복잡한 라우팅 로직을 위해 설계되었습니다.
Saas 로 관리되고 있는 일부 서비스가 있지만, 주요 클라우드 공급자에 스택에 포함되진 않습니다.
RabbitMQ 는 Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift 등의 주요 언어들을 지원합니다.
지속 모드로 사용했을 때, 성능 이슈가 발생할 수 있습니다.
Kafka(AMQP)
- 브로커 규모 : 초당 최대 1,000,000 메세지
- 데이터 지속성 : 지원함
- 일대일 / 일대다 : 오직 일대다 만 지원(언뜻 보기에는 이상해 보이죠?)
Kafka 는 높은 처리량과 낮은 응답 지연 처리를 위해, 2011년 Linkedin 에 의해 만들어 졌습니다.
분산 스트리밍 플랫폼인 Kafka 는 게시-구독 서비스를 복제합니다.
이는 데이터 지속성을 제공하고, 품질 메세지를 교환할 수 있는 레코드 스트림을 저장합니다.
Kafka 는 Azure, AWS, Confluent 에 관리형 Saas 가 있습니다.
이들은 모두 Kafka 프로젝트의 제작자이자 기여자 입니다.
Kafka 는 Python, Java, C/C++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift 등 모든 주요 언어를 지원합니다.
Redis
- 브로커 규모 : 초당 최대 1,000,000 메세지
- 데이터 지속성 : 기본적으로 지원 안함. 메모리 저장소 이기 때문
- 일대일 / 일대다 : 둘다 지원
Redis 는 다른 메세지 브로커들과는 조금 다릅니다.
Redis 의 핵심은 고성능의 키-값 저장소 혹은 메세지 브로커로 사용할 수 있는 메모리 내 데이터 저장소 입니다.
또 하나 다른점은 Redis 는 데이터 지속성을 지원하지 않고 Disk/DB 로 덤프한다는 것 입니다.
이는 실시간 데이터 처리에도 적합합니다.
원래, Redis 는 일대일, 일대다 방식이 아니었습니다.
하지만 Redis 5.0 부터 도입된 게시-구독 기능이 포함어 기능이 향상되어, 일대다가 실제 사용할 수 있는 옵션이 되었습니다.
Message Brokers per Use Case
메세지 큐 별 사용 사례
Short-lived Messages: Redis
짧은 생명 주기의 메세지 : Redis
Redis 의 메모리 데이터베이스는 데이터 지속성이 필요하지 않은 짧은 생명주기의 메세지와 완벽하게 잘 맞습니다.
아주 빠른 서비스와 인메모리 기능을 제공하기 때문에, Redis 는 지속성이 중요하지 않고 약간의 손실을 용인할 수 있는 짧은 생명주기의 메세지를 위한 완벽한 후보입니다.
5.0 에서 배포된 Redis steams 와 함께 일대다 케이스의 후보도 될 수 있습니다.
이 기능은 이전의 한계와 오래된 게시-구독 기능 때문에 반드시 필요했습니다.
Large Amounts of Data: Kafka
대용량 데이터 : Kafka
Kafka 는 장기간의 대용량 데이터를 저장하기 위해 구성된 높은 처리량 분산 큐입니다.
Kafka 는 데이터 지속성이 필요한 일대다 상황에 이상적입니다.
Complex Routing: RabbitMQ
복잡한 라우팅 : RabbitMQ
RabbitMQ 는 오래되었지만, 복잡한 라우팅을 지원하는 많은 특징과 기능을 가진 성숙한 브로커 입니다.
이는 높은 처리 속도를 필요로 하지 않을 때 복잡한 라우팅 통신을 지원합니다(초당 몇 만 메세지)
Consider Your Software Stack
당신의 소프트웨어 스택을 고려하라
당연히 마지막 고려사항은, 당신의 현재 소프트웨어 스택입니다.
만약 당신이 상대적으로 쉽게 적용할 수 있는 프로세스를 찾고 있고 스택에서 다른 브로커를 유지하고 싶지 않다면, 스택에서 이미 지원하는 브로커로 작업하는 편이 더 나을 수 있습니다.
예를 들어 RabbitMQ 를 사용하고 있는 시스템에서 Celery(Python Task Queue) 를 사용한다면, 지원되지 않거나 다시 쓰기 작업이 필요한 Kafka 와는 다르게 RabbitMQ 나 Redis 와 함께 작업하는 이점을 가질 것 입니다.
RabbitMQ 와 함께 사용할 수 있다는 이점이 있습니다.
우리 Otonomo 는 우리의 플랫폼 진화와 성장을 위해 위의 모든 것들과 그 이오의 몇가지를 사용했습니다.
도구는 각자 장단점을 가지고 있고, 도구에 대한 이해와 작업에 맞는 도구, 특정한 순간, 상황과 요구사항에 따라 선택하는 것이 중요합니다.