멀티 서버 Socket 통신에 Message Queue 사용하기

멀티 서버, 그러니까 서버가 1개를 초과하는 서비스에서 Socket 통신을 이용하고 싶었다.

단순하게 생각하면 서버가 n개가 존재할 때 각 클라이언트가 서로 겹치지 않는 서버에 연결되어 있다면

서버1에 연결된 클라이언트는 n개의 서버와 전부 소켓이 연결되어있어야 한다.

 

말이 안 된다고 생각했다..^^ 분명 더 좋은 방법이 있을 것이다..

그래서 Message Queue 에 관하여 찾아보게 되었다.

Message Queue

• Message Broker (kafka, Redis 등) 을 추가하여 프로세스나 시스템 간에 데이터를 전달함.
• 애플리케이션끼리 서로 메시지를 보내 통신할 수 있음.

기본 아키텍쳐

• 메시지를 생성.
• 생산자 클라이언트 애플리케이션이 메시지 대기열에 전달.
• 소비자 애플리케이션이 대기열에 연결, 처리할 메시지를 가져옴.
• 대기열에 배치된 메시지는 소비자가 해당 메시지를 검색할 때까지 저장 됨.
• 메시지 생성자와 소비자를 분리하여 서로 동시에 메시지 대기열과 상호작용할 필요 없음.

그래서 어떤 Message Broker 를 사용할 것인가?

각각 Redis, RabbitMQ, Kafka 가 있다고 하는데..

Redis

장점

• 높은 성능 : 낮은 지연 시간과 높은 처리량을 제공
• 간단함 : 설정 및 사용이 쉬움.
• 데이터 구조 : 다양한 데이터 구조 지원.
• 인메모리 저장소 : 매우 빠른 데이터 접근 및 메시지 전달 제공

단점

• 지속성 : 주로 인메모리를 저장하여 적절하게 지속성 설정이 안 되면 충돌 시 데이터 손실 발생
• 확장성 : Kafka 에 비해 설정이 필요하고 수동적임.
• 제한된 메시지 처리 : 확인, 재시도 기능 제공하지 않음.

사용 사례

• 실시간 분석
• 캐싱
• 간단한 pub/sub 시스템

RabbitMQ

장점

• 고급 메시징 기능 : 복잡한 라우팅이나 확인, 재시도 및 지속성 지원
• 프로토콜 지원 : AMQP, MQTT, STOMP 등 다양한 프로토콜 지원
• 신뢰성 : 전달을 보장하고 메시지 내구성 옵션 제공
• 유연성 : 교환, 큐, 바인딩 가능

단점

• 성능 : 일반적으로 Redis 나 Kafka 에 비해 느림. (특히 부하가 심할 땐 더)
• 복잡성 : Redis 에 비해 설정이나 관리가 복잡함.
• 확장성 : 클러스터링이 가능. 그러나 Kafka 에 비해 수평 확장은 어려움.

사용 사례

• 복잡한 라우팅 및 메시지 처리
• 보장된 전달이 필요한 시스템
• 작업 큐 및 백그라운드 작업 처리

Kafka

장점

• 높은 처리량 : Kafka 는 높은 처리량을 위해 설계 됨. 대량의 데이터 처리에 적합.
• 확장성 : 수평 확장이 용이, 많은 메시지와 소비자 처리 가능.
• 내구성 : 메시지가 디스크에 지속되어 데이터 내구성과 신뢰성 보장.
• 스트리밍 기능 : 실시간 데이터 스트리밍 및 이벤트 소싱에 매우 적합.

단점

• 복잡성 : 설정, 관리가 복잡하고 학습이 좀 어려움.
• 지연 시간 : Redis 에 비해 지연 시간이 김. 초저지연 실시간 메시징에는 적합하지 않음.
• 브로커 오버헤드 : Redis 에 비해 오버헤드가 높아 더 많은 리소스 필요.

사용 사례

• 실시간 데이터 스트리밍
• 이벤트 소싱
• 로그 집계

처음엔 Redis 를 사용하려고 했었다. 이유는,,

• 간단한 알림 기능 정도만 사용할 것인데, 실시간 알림이다.
• 셋 중에 제일 지연 시간이 낮다면 실시간 알림 기능에 적합할 것 같다.
• 이미 우리 서비스가 Redis 를 사용하고 있어서 구성이 어렵지 않다.

하지만 Kafka 사용을 좀 더 고려해보려고 한다.

• 많은 회사에서 사용 중이라고 한다. 해보면 도움 되겠지..
• 학습은 하면 된다. 사이드 프로젝트 이러려고 하는 게 아닌가?
• Redis 는 알람 전달 보장이 안 된다고 해서..좀 생각해야할 부분이고
• 컴퓨팅 리소스가 좀 필요하다고 하여 그게 맘에 걸린다.
• 항상 서비스가 확장을 염두에 두고 개발해야한다고 한다면..kafka 가 맞을 수도 있겠다.