[대규모 시스템 설계 기초] 10장 - 알림 시스템 설계

728x90

10장은 알림 시스템(notification system)에 대해 다룬다.

알림 시스템은 단순 푸시 알림뿐만 아니라, SMS 메시지 그리고 이메일 세 가지로 분류할 수 있다.

요구사항 예시

푸시 알림, 이메일, SMS 메시지 알림 지원
연성 실시간(soft real-time) 시스템
스마트폰, 랩톱/데스크톱 지원
클라이언트에서 만들 수도 있고, 서버 측에서도 스케줄링할 수 있음
알림을 받지 않도록 설정한 사용자에겐 알림 제공 X
하루에 천만 건에 푸시 알림, 백만 건의 SMS 메시지, 5백만 건의 이메일을 보낼 수 있어야 함

개략적 설계

알림 유형별 지원방안

iOS 푸시 알람

iOS에서 푸시 알람을 보내기 위해 알림 제공자(provider), APNS(Apple Push Notification System), iOS 단말(iOS devcie) 컴포넌트가 필요하다.

provider: notification request를 만들어 APNS로 보내는 주체
- device token: 알림 요청을 보내데 필요한 고유 식별자
- payload: 알림 내용
APSN: 애플이 제공하는 원격 서비스로 푸시 알림은 장치로 보내는 역할
device: 푸시 알림을 수신하는 사용자 기기

안드로이드 푸시 알람

APNS 에서 FCM(Firebase Cloud Messaging) 사용하는 것을 제외하곤 절차는 iOS와 비슷하다.

SMS 메시지

메시지를 보낼 때는 Twilio, Nexmo 같은 제3 사업자의 서비스를 많이 이용한다.

이메일

대부분은 회사 이메일 고유 서버를 갖추고 있지만 전송 성공률도 높고, 데이터 분석 서비스도 제공하기 때문에 Sendgrid, Mailchimp 와 같은 상용 서비스를 이용한다.

연락처 정보 수집 절차

사용자가 앱을 설치하거나 회원가입을 하면 알림을 보내기 위한 사용자의 정보를 수집하여 데이터베이스에 저장한다.

알림 전송 및 수신 절차

개략적 설계

알림을 요청하는 N개의 서비스 존재 -> MSA, 크론잡 또는 분산 시스템 컴포넌트일 수 있음
알림 시스템은 알림 전송을 위한 API을 제공해야 하며, 서드 파티 서비스에게 전달할 payload를 만들어 낼 수 있어야 함
서드 파티 서비스 선택 시 확장성과 중국과 같은 폐쇄적인 시장도 고려하여 선택해야 함
SPOF, 규모 확장성, 성능 병목과 같은 이슈도 고려해야 함

사용자 단말 정보를 캐시에 저장
알림 유형별 Message Queue 를 두어 알림 시스템과 worker의 결합을 느슨하게 함
알림 시스템은 다음 기능을 제공해야 함
- 알림 전송 API -> 스팸 방지를 위한 Authentication과 Authorization 이 필요함
- 알림 validation, DB/cahce query, 알림 전송

상세 설계

데이터 손실 방지

알림 내용이 소실되면 안되기 때문에 알림 데이터를 DB에 보관하고 재시도 메커니즘을 구현해야 한다.

-> 대부분 MQ에선 Retry, Dead Letter Queue 기능을 제공하기 때문에 로그 DB를 사용하지 않고 DLQ 기능을 사용해도 될 것 같다.

알림 중복 전송 방지

알림 시스템을 분산 시스템으로 사용할 경우 분산 시스템 특성으로 가끔 알림이 중복된다.

이 중복은 100% 방지하기 어렵다고 한다.

중복을 최대한 방지하기 위해 알림의 이벤트 ID를 검사하는 매커니즘을 사용한다.

추가 고려 사항

알림 템플릿

대형 알림 시스템은 하루에 수백만 건 이상의 비슷한 알림을 처리하기 때문에 알림 템플릿을 만들고 캐시나 DB에 저장하여 재사용하는 것이 좋다.

알림 설정

너무 많은 알림을 받으면 사용자는 피곤함을 느끼기에 알림 설정을 상세히 조정할 수 있도록 한다.

Late limit

사용자에게 너무 많은 알림을 보내는 것을 방지하기 위해 Late limit 도입을 고려한다.

재시도 방법

retry 횟수를 정하고 해당 횟수를 넘어가면 DLQ 에 저장하고 관계자가 확인할 수 있도록 한다.

푸시 알림 보안

알림 전송 API에 Authentication, Authorization 을 도입한다.

큐 모니터링

큐에 쌓인 메시지를 메트릭으로 모니터링 하여 큐에 메시지가 많이 쌓인다면 서버 증설을 한다.

이벤트 추적

사용자 행동을 분석하기 위해 알림 확인율, 클릭률, 실제 앱 사용과 같은 메트릭을 이용한다.

안정성(reliability): 재시도 매커니즘을 도입하여 메시지 전송 실패율을 낮춤
보안(security): API에 authentication 을 붙임
전송률 제한: 사용자에게 알림을 보내는 빈도 제한