10장 : 알림 시스템 설계
알림 시스템은 최근 많은 프로그램이 채택한 인기 있는 기능으로, 모바일 푸시 알림, SMS 메시지, 이메일 세 가지로 분류할 수 있다.
1단계 : 문제 이해 및 설계 범위 확정
2단계 : 개략적 설계안 제시 및 동의 구하기
알림 유형별 지원 방안
iOS 푸시 알림
안드로이드 푸시 알림
위와 비슷한 절차로 전송된다. APNS 대신 FCM(Firebase Cloud Messageing)을 사용한다.
SMS 메시지
SMS 메시지를 보낼 때는 보통 트윌리오(Twilio), 넥스모(Nexmo)같은 제 3사업자의 서비스를 많이 이용한다.
요약
연락처 정보 수집 절차
알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다. 사용자가 앱을 설치하거나 계정을 등록하면 API 서버는 해당 사용자의 정보를 수집하여 데이터베이스에 저장한다.
알림 전송 및 수신 절차
문제점
SPOF
규모 확장성 : 한 대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로, 데이터베이스나 캐시 등 중요 컴포넌트의 규모를 개별적으로 늘릴 방법이 없다.
성능 병목 : 알림을 처리하고 보내는 것은 자원을 많이 필요로 하는 작업이다.
개선된 버전
1부터 N까지의 서비스 : 알림 시스템 서버의 API 를 통해 알림을 보낼 서비스들.
알림 서버
알림 전송 API
알림 검증
데이터베이스 또는 캐시 질의
알림 전송
Email 형태의 알림을 보내는 데 사용하는 API example
POST https://api.example.com/v/sms/send
Request body
캐시 (cache) : 사용자 정보, 단말 정보, 알림 템플릿(template) 등을 캐시한다.
데이터베이스(DB) : 사용자, 알림, 설정 등 다양한 정보를 저장한다.
메시지 큐(message queue) : 시스템 컴포넌트 간 의존성을 제거하기 위해 사용한다. 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할도 한다.
작업 서버(workers) : 메시지 큐에서 전송할 알림을 꺼내서 제 3자 서비스로 전달하는 역할을 담당하는 서버다.
제 3자 서비스(third-party service)
iOS, 안드로이드, SMS, 이메일 단말
3단계 : 상세 설계
안정성
데이터 손실 방지
알림 중복 전송 방지
추가로 필요한 컴포넌트 및 고려사항
알림 템플릿
알림 설정 : 사용자는 이미 너무 많은 알림을 받고 있어서 쉽게 피곤함을 느낀다.
전송률 제한
재시도 방법
푸시 알림과 보안
큐 모니터링
이벤트 추적
수정된 설계안
알림 서버에 인증(authentication)과 전송률 제한(rate-limiting) 기능이 추가되었다.
전송 실패에 대응하기 위한 재시도 기능이 추가되었다. 전송에 실패한 알림은 다시 큐에 넣고 지정된 횟수만큼 재시도한다.
전송 템플릿을 사용하여 알림 생성 과정을 단순화하고 알림 내용의 일관성을 유지한다.
모니터링과 추적 시스템을 추가하여 시스템 상태를 확인하고 추후 시스템을 개선하기 쉽도록 하였다.
Last updated
