실시간 알림 시스템 기술 선택 관한 고민 (2025년 4월 13일)

2025년 4월 13일의 고민 노션에서 옮겨오고 있습니다.

 

고민

 

비밀로그는 젊은 층을 저격한 SNS의 특성상 유행이 빠르게 일어나고 빠르게 사라질 특성을 가진 서비스

유행 탄 초반에는 순간적으로 대량의 알림이 일어날 수 있음

 

롤링페이퍼에 메시지가 달릴때 알림이 발생 친구가 메시지 보낼 때 친구의 친구가 메시지를 보낼 수도 있기 때문에 동시성이 보장되어야 함. 알림은 최대 30개까지 저장되며 개인이 삭제하지 않는 이상 다시 읽을 수 있어야 함.

 

모바일 유저는 백그라운드에서 알림을 받을 수 있어야 함.

 

목표:

1. 1분에 500개의 알림을 처리할 수 있는 성능

2. 동시성 보장

3. 실시간성 보장

4. 유실 방지

5. 모바일 유저만을 위한 전용 알림 기능

---

과정

 

제외 기술

폴링, 롱 폴링 : 계속 Get요청을 보내는 것이 IO자원을 갉아먹어 성능에 좋지 못할 것이라는 판단 1분의 500개라는 목표가 있기 때문에 부하를 줄 수 있는 방식은 지양

 

웹 소켓 : 양방향 통신 기능은 필요하지 않음, 연결 유지 비용이 SSE보다 큼

 

RabbitMQ : 메시지 유실 우려가 없다는 장점은 있으나, Redis를 활용할 예정이기 때문에 추가 도입의 필요성이 낮음

 

카프카 : 고성능이 장점이나, 현재 서비스 규모에 비해 오버엔지니어링 우려

 

선택 기술

 

실시간 통신 - SSE : 단방향 알림 구조에 적합, 웹 소켓 대비 자원 소모 적음, 실시간 푸시 가능

 

메시지 큐 - Redis List : 알림을 큐처럼 저장하고 일정 개수의 과거 알림 제공, Redis를 차후에 캐시 및 세션 등 다른 영역에도 사용할 가능성이 커 기술 통일 가능, Redis Stream은 용도에 비해 무겁고, Pub/Sub은 메시지 유실 우려가 있어 제외

 

푸시 알림 - FCM : 무료로 안드로이드, iOS 모두 지원, 안정적이고 관련 문선 및 예제 풍부, 서버에서 직접 REST API로 발송 가능하여 유연성 확보

 

---

해결

 

SSE, FCM, Redis List

서비스의 실시간성과 확장성, 유지 보수성을 고려하여 가볍고 효율적인 기술 조합을 구성. 서비스 초기에는 Redis 기반의 단순 큐 구조와 SSE를 활용하고, 모바일 확장성은 FCM을 통해 확보하는 방향으로 설계