RabbitMQ vs Kafka vs Redis

마이크로서비스 통신 : 동기 vs 비동기

마이크로서비스가 서로 통신하는 방법은 크게 동기식과 비동기식이 있습니다.

동기식

요청을 보내면 응답이 올 때까지 기다리고 처리합니다.
HTTP 위에서 REST 프로토콜을 사용합니다.

비동기식

응답과 상관없이 요청을 보냅니다.
분산형 시스템에 적합하고, 메시지 브로커를 통해서 메시지를 관리합니다.

• 메시지 브로커: 송신자의 메시지 프로토콜 형식에서 수신자의 메시지 프로토콜 형식으로 변환하는 중간 모듈

동기식 vs 비동기식 무엇을 선택?

마이크로서비스를 구성하는 방법과 인프라, 대기시간, 규모, 종속관계 등 다양한 환경을 고려해서 선택해야합니다.
비동기식 통신이 설정하기 더 복잡하고, 더 많은 기술스택을 사용해야합니다.
하지만 마이크로서비스에서 더 많은 장점을 갖고 있습니다.

비동기식 통신의 장점

• 논블로킹: 기다리지 않고 다른 작업 수행가능하니 효율이나 반응속도가 뛰어남
• 확장성: 동기식 보다 결합도가 떨어지기 때문에 확장성이 좋음

메시지 브로커

비동기 통신으로 한다면 일반적으로 메시지 브로커를 통해 관리됩니다.
그렇다면 메시지 브로커를 선택하는 기준은 무엇일까요?

• Broker Scale: 초당 보내는 메시지 수
• Data Persistency: 메시지 복구 기능
• Consumer Capability: 한개의 브로커가 관리할 수 있는 소비자 수
  • 일대일
    
    
  • 일대다
    
    

RabbitMQ

• Broker Scale: Configuration 과 Resource에 따라 달라짐, 대충 1초에 메시지 5만개 전송
• Data Persistency: 지속성 메시지, 일회성 메시지 둘다 지원
  • 다만 지속성 메시지를 사용할 경우 성능 문제 발생 가능
• Consumer Capability: 일대일, 일대다 모두 가능
• 추가 설명
  • Rabbit MQ는 2007년 처음으로 만들어진 메시지 브로커입니다.
  • point to point, pub-sub 방식으로 메시지를 전달합니다.
  • 복잡한 라우팅을 지원하도록 설계되었습니다.

Kafka

• Broker Scale: 1초에 메시지 100만개 전송
• Data Persistency: 지속성 메시지
• Consumer Capability: 일대다만 가능
• 추가 설명
  • Kafka는 높은 처리량, 짧은 대기 시간 처리를 위해 2011년 Linkedin에서 만들었습니다.
  • 분산 스트리밍 플랫폼인 Kafka는 pub-sub 서비스를 복제합니다.

Redis

• Broker Scale: 1초에 메시지 100만개 전송
• Data Persistency: 메모리 내 데이터 저장소이기 때문에 휘발성임
• Consumer Capability: 일대일, 일대다 모두 가능
• 추가 설명
  • Redis는 Key-Value를 사용하는 In-Memory 데이터 저장소입니다.
  • 데이터를 지속성있게 하려면 디스크나 DB에 덤프를 해야합니다.
  • 원래 일대다를 지원하진 않았지만 Redis5.0이 pub-sub을 도입하면서 일대다방식도 지원하게 되었습니다.

그럼 어떤 메시지 브로커가 적합할까요?

단기 메시지: Redis

Redis의 인메모리 데이터베이스는 지속성이 필요하지 않은 단기메시지를 사용할 때 적합합니다.
매우 빠른 인메모리 기능을 제공하기 때문에 단기 메시지를 처리할 때 최고의 성능을 보여줍니다.

대용량 데이터: Kafka

Kafka는 대용량 데이터를 장기간 저장하기 위해 구축된 처리량이 많은 분산 스트리밍 플랫폼입니다.

복잡한 라우팅: RabbitMQ

RabbitMQ는 복잡한 라우팅을 지원하는 많은 기능을 갖췄습니다.
메시지 큐에 도착하기 전에 exchange를 통해 라우트됩니다.