[서비스 1] [서비스 2] ... [서비스 N]
│ │ │
└──────┬───────┴──────────────
▼
[알림 서버] ─> [캐시] ──> [데이터베이스]
│
│
┌──────┼────────────┬─────────────┬─────────────┐
▼ ▼ ▼ ▼
[iOS 푸시 알림 큐] [안드로이드 푸시 큐] [SMS 큐] [이메일 큐]
│ │ │ │
▼ ▼ ▼ ▼
[iOS 작업 서버] [안드로이드 작업 서버] [SMS 작업 서버] [이메일 작업 서버]
│ │ │ │
▼ ▼ ▼ ▼
[APNS] [FCM] [SMS 서비스] [이메일 서비스]
│ │ │ │
▼ ▼ ▼ ▼
[iOS 단말] [안드로이드 단말] [SMS 단말] [이메일 수신 단말]
## 조건
푸시, SMS 메시지, 이메일
soft real-time
ios, android, pc 지원
알림 거부 설정 가능
하루 1천만 건의 모바일 푸시 알림, 백만 건의 SMS메시지, 5백만 건의 이메일 전송
ios에서 푸시 알림을 보내기 위해서는 세가지 컴포넌트가 필요하다
- 알림제공자 : 알림을 보내는 주체
- APNS : 애플이 제공하는 서비스로, 푸시 알림을 iOS 장치로 보내는 역할
- iOS단말 : 수신 담당
안드로이드의 경우 이와 비슷하지만 APNS대신 FCM이 있다. SMS의 경우 비즈뿌리오같은 제 3자 서비스를 사용할 수 있다. 이메일의 경우도 아마존의 SES같은 외부 서비스를 많이 사용한다.
알림을 보내려면 단말토큰, 전화번호, 이메일 주소 등의 정보가 필요하다. 해당 데이터가 데이터베이스에 저장 되어있어야 한다.
알림 시스템에서 데이터를 가져올때 부하분산을 위해 주 서버로부터 분리한다. 또한 캐시를 적용하여 부하를 분산시킬 수 있다.
다음으로 메시지 큐를 통해 컴포넌트 사이의 강결합을 끊고, 한번에 많은양의 메시지를 보낼때 가해지는 부하를 방지할 수 있도록 메시지큐를 사용한다.
이를 적용하여 설계하면 위와같은 플로우가 된다.
큐를 사용하여 결합을 끊어놓음으로써 각 ios, android, sms, email 서비스중 하나에 장애가 발생해도 다른 종류의 알림은 정상 동작하게 된다.
- 1~N 까지는 알림 시스템에 알림을 보낼 서비스들이다.
- 알림 서버는 다음과 같은 기능을 제공한다
- 알림 전송 api
- 이메일 주소, 전화번호 등에 대한 기본적 검증
- 데이터베이스 또는 캐시로부터 알림에 포함시킬 데이터를 가져옴
- 알림 전송
여기서 빠진 부분이 있다면, 알림이 실패한 경우이다. 이를 위해 모든 발솔한 알림은 DB에 저장해야한다. 또한 알림 서비스에서 재시도 로직이 필요하다.
알림을 중복으로 발송하는것 또한 방지해야한다. 이를 위해 보내야 할 알림이 도작하면 ID또는 특정 로직을 통해 이전에 처리한 이벤트인지 확인해야 한다.
#### 모니터링
알림 시스템을 모니터링 할 때 중요한 메트릭중 하나는 큐에 쌓인 알림의 개수이다. 이 수가 너무 크면 작업 서버들이 이벤트를 빠르게 처리하고 있지 못하다는 뜻이다. 그런 경우에는 작업 서버를 증설하는 게 바람직할 것이다
'Web' 카테고리의 다른 글
| 검색어 자동완성 시스템 설계 (가상 면접 사례로 배우는 대규모 시스템 설계) (0) | 2025.06.02 |
|---|---|
| 채팅 시스템 설계 (가상 면접 사례로 배우는 대규모 시스템 설계) (5) | 2025.05.31 |
| 분산 시스템을 위한 유일 ID 생성기 설계 (가상 면접 사례로 배우는 대규모 시스템 설계) (0) | 2025.05.29 |
| Spring batch란? (1) | 2025.05.29 |
| 키-값 저장소 설계 (0) | 2025.05.28 |