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

정재익 2025. 8. 7. 16:28

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을 통해 확보하는 방향으로 설계