기획

이번 프로젝트는 라이더용 배달 어플로, 주문이 발생하면 가게 근처의 라이더들에게 주문 배달 알림을 전송하는 기능을 구현해야한다. 이 때, 이 알림 기능을 어떤 기술로 구현할지에 대해 고민해보았다.

메시지 큐

우선 이번 알림 서비스 구현은 이벤트 기반의 메시지 큐를 활용하여 구현하기로 결정했다. 메시지 큐 활용시 알림 서비스가 비동기적으로 실행되어 빠르고 안정적으로 처리될 수 있을 뿐만 아니라 시스템 간의 결합도를 낮춰 유지보수와 확장에 용이하기 때문이다.

그렇다면 메시지 큐를 어떤 기술로 구현할 것인가에 대한 고민을 하게 되었는데 가장 일반적인 메시지 큐인 RabbitMQ, kafka와 Redis Pub/Sub까지 함께 고려해보았다.

Redis Pub/Sub

Redis Pub/Sub은 큐에 메시지를 저장하는 형태가 아닌, 메시지 발행과 함께 구독자들에게 즉시 전달 후 소멸되는 형태이다. 메시지가 저장되지 않으므로 메시지 전달에 대한 보장이 약하다. 즉 신뢰성이 떨어진다. 그렇지만 구현이 가장 간단하다.

Redis Pub/Sub은 실시간 처리에만 적합하고 알림 전달 보장이 필요한 시스템에서는 적합하지 않다고 할 수 있다. 우리 서비스는 라이더들에게 배달에 대한 알림 전송의 안정성이 중요하다고 볼 수 있으므로 Redis Pub/Sub은 고려 대상에서 제외하기로 결정했다.

RabbitMQ VS Kafka

RabbitMQ와 Kafka는 둘 다 발행된 메시지를 큐에 저장하는 방식이다. 전송에 실패하더라도 사용자가 알림을 다시 받을 수 있다. 즉 신뢰성 높은 메시지 처리가 가능하다.

RabbitMQ와 Kafka의 가장 큰 차이는 대용량 스트림인데 Kafka는 고용량 대용량 처리에 강하여 메시지 내구성이 매우 좋다. 다만 우리 서비스에서 한 번에 수십만건의 알림을 처리할 것도 아니고 단순 알림 서비스에 Kafka를 적용하기에는 구현 난이도, 비용, 스펙 측면에서 모두 과하다고 생각했기 때문에 RabbitMQ로 결정했다.

클라이언트

원래는 알림 서비스를 Websocket으로 구현하고 싶었는데 우리 서비스는 웹도 앱도 프론트가 없다... 서버만 구현하기 때문에 웹소켓 사용시 알림 테스트가 어려워진다. 그래서 슬랙 또는 카카오톡 메신저로 알림을 전송하는 것으로 구현할 계획이다.