[가상면접 사례로 배우는 대규모 시스템 설계 기초] Ch10. 알림 시스템 설계

요구사항

- 푸시 알림, SMS 메시지, 이메일 지원해야함 

- soft-real-time 시스템 : 가능한 빨리 전달되어야 하지만 시스템에 높은 부하가 걸렸을때 약간의 지연 가능 

 

 

1차 설계:   알림 전송 시스템에 1개 서버만 제공하는 시스템 

문제점 

- SPOF(Single-Point-Of-Failure) : 알림 서비스에 서버가 하나밖에 없더서 그 서버에 장애가 생기면 전체 서비스 장애로 이루어짐

- 규모 확장성 : 한 대 서비스로 모든 것 처리하므로, 그 안에 데이터베이스나 캐시 등 주요 컴포넌트의 규모를 개별적으로 확장할 수 없음 

- 성능 병목 : 모든 것을 한 서버로 처리하면 사용자 트래픽이 몰리는 시간에 시스템 과부하 빠질 수 있음 

 

 

 

2차 설계:   데이터베이스, 캐시, 메시지 큐 도입한 알림 시스템 

- 데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리한다. 

- 알림 서버를 증설하고 자동으로 수평적 규모 확장이 이루어질 수 있도록 한다. 

- 메시지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊는다. 

 

1. API 호출하여 알림 서버로 알림 보낸다.

2. 알림 서버는 사용자 정보, 단말 토큰, 알림 설정 같은 메타데이터를 캐시나 데이터베이스에서 가져온다. 

3. 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 해당 이벤트를 위한 큐에 넣는다. 가령 ios 푸시 알림 이벤트는 ios 푸시 알림 큐에 넣어야 한다. 

4. 작업 서버는 메시지 큐에서 알림 이벤트를 꺼낸다.

5. 작업 서버는 알림을 제 3자 서비스로 보낸다. 

6. 제3자 서비스는 사용자 단말로 알림을 전송한다.

 

 

최종 설계 : 전송률 제한, 재시도 기능, 전송 템플릿, 모니터링/추적 시스템 추가 

- 알림 서버에 인증과 전송률 제한 기능이 추가되었다.

- 전송 실패에 대응하기 위한 재시도 기능이 추가. 

- 전송 템플릿을 사용하여 알림 생성 과정 단순화 

- 모니터링과 추적 시스템 추가 

 

 

 

 

추가적으로 고려하면 좋은 안전성 이슈

1) 데이터 손실 방지 : 알림 로그 데이터베이스를 생성

2) 알림 중복 전송 방지 : 여러 번 반복되는 것은 불가능하지만, 중복 탐지하는 알고리즘 도입 

ㄴ ex) 보내야 할 알림이 도착하면 이벤트 id 검사하여 이전에 본 적이 있는 이벤트인지 탐지  

ㄴ You Cannot Have Exactly-Once Delivery – Brave New Geek

 

 

참고 블로그 

- 10장. 알림 시스템 설계 (velog.io)