📓 10장. 알림 시스템 설계

1단계. 문제 이해 및 설계 범위 확정

1. 알림 종류: 푸시 알림, SMS 메세지, 이메일
2. 연성 실시간(soft real-time) 시스템이라고 가정
3. IOS, 안드로이드(android) 단말, 그리고 랩톱/데스크톱을 지원해야 함.
4. 알림: 클라이언트 애플리케이션 프로그램이 만들수도 있고, 서버에서 스케줄링 할수도.
5. 사용자가 알림 끄기도 가능해야함.
6. 하루에 천만 건 모바일 푸시 알림, 백만 건의 SMS 메세지, 5백만 건의 이메일

2단계. 개략적 설계안 제시 및 동의 구하기

알림 유형별 지원 방안

1. IOS 푸시 알림

1. 알림 제공자(provider)
   알림 요청(notification request)을 만들어 애플 푸시 알림 서비스(APNS)로 보내는 주체

   알림 요청을 만들기 위해서는...
   단말 토큰(device token): 알림 요청을 보내는 데 필요한 고유 식별자
   페이로드(payload): 알림 내용을 담은 JSON 딕셔너리(dictionary)
   가 필요하다.

2. APNS
   애플이 제공하는 원격 서비스. 푸시 알림을 iOS 장치로 보내는 역할

3. iOS 단말(iOS device)
   푸시 알림을 수신하는 사용자 단말

2. 안드로이드 푸시 알림
비슷한 절차로 전송. APNS 대신 FCM(Firebase Cloud Messaging)을 사용.

3. SMS 메세지
트윌리오(Twilio), 넥스모(Nexmo) 같은 제 3 사업자 서비스를 많이 이용 - 당연 유료

4. 이메일
보통 상용 이메일 서비스를 사용하며 샌드그리드(Sendgrid), 메일침프(Mailchimp)를 많이 사용.
전송 성공률도 높고, 데이터 분석 서비스(analytics)도 제공.

요약

연락처 정보 수집 절차

앱 설치 혹은 계정 등록 시 api 서버가 해당 사용자의 정보를 수집하여 DB에 저장

알림 전송 및 수신 절차

초안: 개략적 설계안

이 설계의 문제점
1. SPOF(Single-Point-Of-Failure): 단일 서버 - 하나 고장나면 전체 장애로 이어짐
2. 규모 확장성: 마찬가지로 단일 서버 - DB나 Cache 등 중요한 컴포넌트의 규모를 개별적으로 늘릴 방법이 없음
3. 성능 병목: 단일 서버 - 사용자 트래픽이 몰리는 시간에는 시스템 과부하 우려

개선된 버전: 개략적 설계안

개선 방향

1. DB와 Cahce를 알림 시스템의 주 서버에서 분리
2. 알림 서버를 증설하고 자동으로 수평적 규모 확장이 이루어질 수 있도록...
3. 메세지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊자

1. 알림 서버(notification server)의 기능
   알림 전송 API: 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용 가능
   알림 검증(validation): 이메일 주소, 전화번호 등에 대한 기본적 검증 수행
   DB 또는 Cache 질의: 알림에 포함시킬 데이터를 가져오는 기능
   알림 전송: 알림 데이터를 메세지 큐에 넣음. 병렬적 알림 처리 가능.

정리

1. API를 호출하여 알림 서버로 알림을 보냄
2. 알림 서버는 사용자 정보, 단말 토큰, 알림 설정 같은 메타데이터(metadata)를 캐시나 DB에서 가져옴
3. 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 해당 이벤트를 한 큐에 넣는다.
4. 작업 서버는 메세지 큐에서 알림 이벤트를 꺼냄
5. 작업 서버는 알림을 제3자 서비스로 보냄
6. 제3자 서비스는 사용자 단말로 알림을 전송함

3단계. 상세 설계

안정성(reliability)

데이터 손실 방지

알림 중복 전송 방지

간단한 중복 방지 로직의 사례
: 보내야 할 알림이 도착하면 그 이벤트 ID를 검사하여 이전에 본 적이 있는 이벤트인지 살핀다. 중복된 이벤트라면 버리고, 그렇지 않으면 알림 발송

중복 전송을 100% 방지하는 것이 불가능한 이유

추가로 필요한 컴포넌트 및 고려사항

알림 템플릿, 알림 설정, 이벤트 추적, 시스템 모니터링, 처리율 제한 등...

개선된 설계안

---

짝짝짝 👏