[니꺼, 내꺼] 4주차 - 알림 개선에 Redis pub/sub 를 선택한 이유

1. 배경

 현재 프로젝트에 구현된 '실시간 알림 서비스' 는 '단일 서버' 에서는 잘 작동하지만 '다중 서버' 환경에서는 원래 의도와는 다르게 작동할 것이라는 생각이 들었습니다. '다중 서버' 환경에 대해서 생각하게 된 이유는 하나의 서버로는 수 많은 사용자들에게 서비스를 제공하는 것에 무리가 있다 생각했기 때문입니다.

 

아무리 일 잘하는 은행원이 있어도 해당 은행원이 은행에 찾아오는 모든 고객들의 상대할 수는 없습니다. 그렇기에 여러 은행원들을 고용해 여러 창구를 열어 은행에 찾아오는 고객들에게 서비스를 제공합니다. 마찬가지로 웹 서비스 또한 아무리 성능이 좋은 서버가 있다고 한들 결국 물리적인 한계에 도달하기에, 같은 기능을 하는 서버 여러대를 두고 수 많은 사용자들을 상대해야 할 것 입니다.

 

2. 요구사항

 결국 동일한 서버를 여러개 띄웠을 때도 '실시간 알림 서비스' 가 원래 의도대로 작동할 수 있도록 해야 합니다.

 

3. 처음 든 생각

 일단 다중 서버 환경에서 각 서버가 갖는 'SseEmitter' (들을)를 다른 서버에서 사용할 수 없는 것이 문제라 생각해 "발급한 'SseEmitter' 를 외부에 저장해두고 이를 각 서버가 가져다 써야하지 않을까?" 라는 생각을 하였습니다. 그리고 조회한 'SseEmitter' 와 이벤트 정보를 클라이언트에 전달할 수 있게 "Message Broker 를 사용하면 어떨까?" 라는 생각 또한 가지고 있었습니다.

 

4. 의사결정/사유

 구현에 앞서 학습을 진행하던 도중, 예상과 달리 SSE 가 만능은 아닌지라 설령 외부 저장소에 'SseEmitter' 를 저장하고 다른 서버에서 이를 사용한다고 해도 해당 서버와 클라이언트의 연결이 없다면 클라이언트에게 이벤트 정보를 전달할 수 없다는 것을 알 수 있었습니다.

 

결국 다른 서버에서 발생한 이벤트에 대한 정보를 현재 서버와 연결된 클라이언트에게 전달하기 위해서는 클라이언트와 연결된 서버가 '이벤트 정보' 를 전달받아 클라이언트에게 전달해야 한다는 것을 깨달았습니다. 이와 같은 기능을 수행하는 기술을 'Message Broker(메시지 브로커)' 라 하며 대표적으로 'Apache Kafka', 'RabbitMQ', 'Redis pub/sub' 이 있다는 것을 알 수 있었습니다(더 많은 메시지 브로커가 있겠지만 가장 유명한 저 3개의 메시지 브로커를 선택지로 두게 되었습니다).

 

 각 메시지 브로커 별로 장단점이 있어 이것만으로는 선택하기 어려워, 현재 프로젝트에 구현된 '실시간 알림 서비스' 에 사용하기 적합한 메시지 브로커를 골라야 했습니다.

 

현재 '실시간 알림 서비스' 스는 주가 아니라 부가 서비스로 발생한 이벤트에 대한 정보는 기본적으로 MySQL(RDB)에 저장되어 사용자가 자신의 알림 내역 페이지를 통해 언제든 확인할 수 있도록 구현되어 있습니다. 그리고 사용자가 접속해 있는 경우에만 실시간으로 알림 정보(= 이벤트 정보)를 전달하고 있습니다. 만약 사용자가 접속해 있지 않다면 이를 전달하지 않습니다.

 

그렇기 때문에 'RabbitMQ' 의 메시지 영속성이나 'Kafka' 의 메시지를 디스크에 저장해 데이터 손실을 방지하는 것과 같은 장점은 현재 프로젝트에 크게 필요가 없다는 생각을 하게 되었고 최종적으로 'Redis pub/sub' 을 사용하게 되었습니다.