레디스를 메시지 브로커로 사용하기
모듈 간의 통신에서는 되도록 비동기 통신(async)을 사용하는 것을 권장하며, 동기 통신(sync)의 횟수를 최대한 줄이는 것이 바람직하다. 서비스 간 통신이 불가능한 상황이 바로 장애로 이어지지 않게, 당장 메시지를 처리하지 못하더라도 보낸 메시지를 어딘가에 쌓아 둔 뒤 나중에 처리할 수 있는 채널을 만들어 주는 것. 이것이 메시지 브로커의 핵심 역할이라고 할 수 있다.
메시지 브로커는 크게 메시징 큐와 이벤트 스트림이라는 두 가지 형태로 나눌 수 있다.
메시징 큐 (메시지 큐)
- 생산자(producer) : 주로 데이터를 생성하는 쪽
- 소비자(consumer) : 데이터를 수신하는 쪽
이벤트 스트림
- 발행자 (publisher) : 데이터를 생성하는 쪽
- 구독자 (subscriber) : 데이터를 조회하는 쪽
메시징큐 / 이벤트 스트림 차이점
1. 방향성
메시징 큐의 생산자는 소비자의 큐로 데이터를 직접 푸시한다. 반면 스트림을 이용한다면 생산자는 스트림의 특정 저장소에 하나의 메시지를 보낼 수 있고 소비자들은 스트림에서 같은 메시지를 pull 해 갈 수 있기 때문에 메시지를 복제해서 저장하지 않아도 된다.
2. 데이터의 영속성
메시징 큐에서는 소비자가 데이터를 읽어갈 때 큐에서 데이터를 삭제한다. 하지만 이벤트 스트림에서 구독자가 읽어간 데이터는 바로 삭제되지 않고, 저장소의 설정에 따라 특정 기간 동안 저장될 수 있다.
레디스를 메시지 브로커로 사용하기
레디스에서 제공하는 pub/sub를 사용하면 빠르고 간단한 방식으로 메시지를 전달할 수 있는 메시지 브로커를 구현할 수 있다. 발행자가 특정한 채널에 데이터를 전송하면 이 채널을 듣고 있는 모든 소비자는 데이터를 바로 소비할 수 있다.
레디스의 pub/sub 에서 모든 데이터는 한 번 채널 전체에 전파된 뒤 삭제되는 일회성의 특징을 가지며, 메시지가 잘 전달됐는지 등의 정보는 보장하지 않는다. 따라서 완벽하게 메시지가 전달돼야 하는 상황에는 적합하지 않을 수 있지만 fire-and-forget 패턴이 필요한 간단한 알림 서비스에서는 유용하게 사용될 수 있다.
fire-and-forget 패턴은 비동기 프로그래밍에서 사용되는 디자인 패턴이다. 어떤 작업을 실행하고 그 결과에 대한 응답을 기다리지 않고 바로 다음 코드를 실행하는 것을 의미한다. 주로 성능 향상이나 비동기 작업을 수행할 때 사용되며, 작업의 완료나 결과에 대한 처리가 필요하지 않을 때 유용하게 사용된다.
레디스의 list 자료 구조는 메시징 큐로 사용하기에 알맞다. list의 데이터는 push와 pop이 가능하며 애플리케이션은 list에 데이터가 있는지 매번 확인할 필요 없이 대기하다가 list에 새로운 데이터가 들어오면 읽어갈 수 있는 블로킹 기능을 사용할 수 있다.
레디스의 pub / sub
레디스는 pub / sub 기능을 제공한다. 레디스 노드에 접근할 수 있는 모든 클라이언트는 발행자와 구독자가 될 수 있다. 발행자는 특정 채널에 메시지를 보낼 수 있으며, 구독자는 특정 채널을 리스닝하다가 메시지를 읽어갈 수 있다.
레디스에서 pub/sub는 매우 가볍기 때문에 최소한의 메시지 전달 기능만 제공한다. 발행자는 메시지를 채널로 보낼 수만 있고, 어떤 구독자가 메시지를 읽어가는지, 정상적으로 모든 구독자에게 메시지가 전달됐는지 확인할 수 없다. 구독자 또한 메시지를 받을 수 있지만 해당 메시지가 언제 어떤 발행자에 의해 생성됐는지 등의 메타데이터는 알 수 없다.
한 번 전파된 데이터는 레디스에 저장되지 않으며, 단순히 메시지의 통로 역할만 한다.
레디스 클러스터 구조에서도 pub / sub을 사용할 수 있다. 클러스터는 레디스가 자체적으로 제공하는 데이터 분산 형태의 구조이다.
레디스의 list를 메시징 큐로 사용하기
레디스의 자료 구조 중 하나인 list는 큐로 사용하기 적절한 자료 구조다. 레디스에는 큐의 tail과 head에서 데이터를 넣고 뺄 수 있는 LPUSH, LPOP, RPUSH, RPOP 커맨드가 존재하기 때문에 애플리케이션 특성에 맞는 메시징 큐를 직접 구현할 수 있다는 장점이 있다.