1. 문제 이해 및 설계 범위 확정
•
하루에 백만 건 이상의 알림을 처리하는 시스템
•
지원해야 하는 시스템의 종류
◦
푸시, SMS, 이메일
•
연성 실시산 시스템 (soft real-time) 시스템일것
◦
가능한 빨리전달 하돼 시스템 부하가 높을 경우 약간의 지연은 무방
•
IOS, 안드로이드, 데스크탑/랩톱 단말을 지원할 것
•
사용자가 알림을 받지 않도록 설정할 수 있을 것
•
천만 건 이상의 푸시 알림, 백만건의 SMS, 5백만 건의 이메일을 보낼 수 있어야함
2. 개략적 설계안 제시 및 동의 구하기
2.1. 알림 유형별 지원 방안
2.1.1. iOS의 푸시 알림
•
알림 제공자
◦
알림 요청을 만들어 애플 푸시 알림(APNS) 서비스로 보내는 주체다.
◦
알림을 보내는데 단말 토큰과 페이로드가 필요하다.
•
APNS
◦
애플이 제공하는 원격 서비스로 푸시 알림을 iOS 장치로 보내는 역할을 담당한다.
2.1.2. 안드로이드 푸시 알림
•
아이폰과 유사하나 APNS가 아닌 FCM을 이용한다.
2.1.3. SMS 메세지
•
SMS 메시지를 보낼 때는 보통 Twilio, Nexmo 같은 제3사업자의 서비스를 이용한다.
2.1.4. 이메일
•
대부분의 회사는 고유 이메일 서버를 구축할 역량은 갖추고 있지만 상용 이메일 서비스를 많이 이용한다.
2.2. 연락처 정보 수집 절차
•
알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다.
•
앱을 처음 설치하거나 처음 계정 등록시 API 서버를 통해서 사용자의 정보를 저장한다.
2.3. 알림 전송 및 수신 절차
2.3.1. 설계안 초안
•
1부터 N까지의 서비스
◦
이 서비스 각각은 마이크로서비스일수도 있고, 크론잡일 수도 있고, 분산 시스템 컴포넌트일 수도 있다.
•
알림 시스템
◦
알림 시스템은 알림 전송/수신 처리의 핵심이다.
◦
이 시스템은 서비스 1~N에 알림 전송을 위한 API를 제공해야 하고, 제 3자 서비스에 전달할 알림 페이로드를 만들어 낼 수 있어야 한다.
•
제3자 서비스
◦
이 서비스들은 사용자에게 알림을 실제로 전달하는 역할을 한다.
◦
제 3자 서비스와의 통합을 진행할 때 유의할 것은 확장성이다.
▪
쉽게 새로운 서비스를 통합하거나 기존 서비스를 제거할 수 있어야 한다는 뜻이다.
•
알림을 받는 단말
◦
사용자는 자기 단말에서 알림을 수신한다.
2.3.2. 설계 초안의 문제점
•
SPOF
◦
알림 서비스에 서버가 하나밖에 없다는 것은, 그 서버에 장애가 생기면 전체 서비스의 장애로 이어진다는 것
•
규모 확장성
◦
한 대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로 DB나 캐시 등 중요 컴포넌트를 개별적으로 늘릴 방법이 없다.
•
성능 병목
◦
알림을 처리하고 보내는 것은 자원을 많이 필요로 하는 작업일 수 있다.
◦
모든 것을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에는 시스템이 과부하 상태에 빠질 수 있다.
2.3.3. 개선된 설계 초안
•
데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리
•
알림 서버를 증설하고 자동으로 수평적 규모 확장이 이뤄질 수 있도록 함
•
메시지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊는다.
•
알림 서버의 제공 기능
◦
알림 전송 API
▪
스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용 가능하다.
◦
알림 검증
▪
이메일 주소, 전화번호 등에 기본적 검증을 수행한다.
◦
데이터베이스 또는 캐시 질의
▪
알림에 포함시킬 데이터를 가져오는 기능이다.
◦
알림 전송
▪
알림 데이터를 메세지 큐에 넣는다.
▪
해당 설계안의 경우 하나 이상의 메세지 큐를 사용하므로 알림을 병렬적으로 처리할 수 있다.
•
캐시
◦
사용자 정보, 단말 정보, 알림 템플릿 등을 캐시한다.
•
데이터베이스
◦
사용자, 알림, 설정 등 다양한 정보를 저장한다.
•
메세지 큐
◦
시스템 컴포넌트 간 의존성을 제거하기 위해 사용한다.
◦
다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할도 한다.
•
작업 서버
◦
메세지 큐에서 전송할 알림을 꺼내서 제 3자 서비스로 전달하는 역할을 담당하는 서버다.
3. 상세 설계
3.1. 안정성
•
분산 환경에서 운영될 알림 시스템을 설계할 때는 안정성을 확보하기 위한 사항 몇 가지를 반드시 고려해야 한다.
3.1.1. 데이터 손실 방지
•
가장 중요한 요구 사항 중 하나로 어떤 상황에서도 알림이 소실되면 안된다.
•
알림을 데이터베이스에 보관하고 재시도하는 매커니즘을 구현해야 한다.
•
알림 로그 데이터베이스를 유지하는 것이 한 가지 방법이다.
3.1.2. 알림 중복 방지 전송
•
같은 알림을 여러 번 반복되는 것을 완전히 막는 것은 가능하지 않다.
◦
분산 시스템 특성 상 가끔은 알림이 중복되기도 한다.
•
중복을 방지하기 위한 간단한 매커니즘
◦
보내야 할 일림이 도착하면 ID를 검사해 이전에 보낸 이벤트인지 확인한다.
▪
중복이면 버리고 아니라면 전송한다.
3.1.3. 추가로 필요한 컴포넌트 및 고려사항
•
알림 템플릿
◦
대형 아림 시스템은 하루에도 수백만 건 이상의 알림을 처리한다.
▪
대부분의 메시지는 형식이 비슷하다.
◦
알림 인자나 스타일, 추적 링크를 조정해 사전에 지정한 형식을 만들어 내면 된다.
•
알림 설정
◦
사용자가 알림을 켜 두었는지 확인하여 전송해야 한다.
•
전송률 제한
◦
사용자에게 너무 많은 알림을 보내지 않도록 하는 한 가지 방법은, 한 사용자가 받을 수 있는 알림의 빈도를 제한하는 것
•
재시도 방법
◦
제3자가 서비스 알림 전송에 실패한다면 재시도 전용큐에 넣는다.
◦
문제가 반복된다면 개발자에게 통지한다.
•
큐 모니터링
◦
큐에 쌓인 알림의 개수를 확인하여 이벤트 처리율을 모니터링한다.
▪
빠르게 처리 못하면 증설을 고려해볼 수 있다.
