대규모시스템설계기초 ch10

대규모 시스템 설계 기초 ch10. 알림 시스템 설계¶

적절한 질문을 통해 요구사항이 무엇인지 지원자가 알아낼 것
- 어떤 종류의 알림을 지원?
- real-time? soft-real-time?
- 지원할 단말기?
- 하루 몇건의 알림을 보낼수있어야 하는가?

단말기별 푸시 시스템
- iOS: APNS
- Android: FCM
- SMS: SMS 서비스 (twilio, nexmo)
- 이메일: 이메일 서비스(sendgrid, mailchimp)

개략적 설계안
- 확장성: 쉽게 새로운 서비스를 통합하거나 기존 서비스를 제거할 수 있어야 한다
  - FCM은 중국에서는 사용할 수 없음.
  - 추상화를 잘 해둬야 할 듯
- DB/Cache를 알림시스템의 주 서버에서 분리
- 알림 서버 증설 & 수평적 규모 확장
- 메시지 큐를 이용해 시스템 컴포넌트의 강한 결합 끊기
  - 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 해당 이벤트를 위한 큐에 넣음.
  - ex) iOS 푸시 알림 이벤트는 iOS 푸시 알림 큐에 넣어야 함

안정성
- 데이터 소실 방지
  - 알림이 소실되면 안된다
  - 알림데이터를 데이터베이스에 보관하고, 재시도 메커니즘을 구현할 것
- 알림 중복 전송 방지
  - 분산 시스템의 특성상 가끔은 같은 알림이 중복되어 전송되기도 함
  - 빈도를 줄이기 위해 중복을 탐지하는 메커니즘 도입

추가로 필요한 컴포넌트 및 고려사항
- 알림 템플릿
  - 템플릿을 만들어 특정한 변수만 변경하여 메시지를 생성하도록 템플릿화
  - ex. 알림톡 템플릿
- 알림 설정
  - 알림 설정을 off 한 사용자들에게는 보내지 않도록 해야한다.
  - ex. alimtalk_block
- 전송률 제한
  - 한 사용자에게 너무 많은 알림이 가지 않도록 알림의 빈도 제한
- 재시도 방법
  - retry_count를 통해 재시도 전용 큐에 넣어 재처리
- 푸시 알림과 보안
  - iOS/Android는 인증/인가 알림을 보냄
- 큐 모니터링
  - 큐에 쌓인 알림의 갯수가 너무 많으면 이벤트를 충분히 빠르게 처리하지 못하는 것
- 이벤트 추적
  - 데이터 분석 서비스 + 이벤트 추적 기능 제공
```
시작 -> 발송 대기 -> 알림 발송 -> 사용자 수신 -> 클릭
                                |
                                -------> 알림 수신 거부 설정
```