•
알림 시스템은 최신 뉴스, 제품 업데이트, 이벤트 등 고객에게 중요할 만한 정보를 비동기적으로 제공한다.
•
알림 시스템은 단순히 모바일 푸시 알림에 한정되지 않는데, SMS 메시지, 이메일의 세 가지로 분류할 수 있다.
1단계 문제 이해 및 설계 범위 확정
•
알림 시스템을 구현하기 위해 요구사항을 명확히 해야할 때, 다음과 같은 사항들을 질문해볼 수 있다.
◦
이 시스템은 푸시 알림, SMS 메시지, 이메일 중 어떤 알림을 지원해야 하는가?
◦
실시간 시스템이어야 하나?
▪
연성 실시간 시스템의 경우, 가능한 빨리 전달되어야 하지만 부하가 걸렸을 경우, 약간의 지연은 가능하다.
◦
어떤 종류의 단말을 지원해야 하나요?
◦
사용자에게 보낼 알림은 누가 만들 수 있나요?
◦
사용자가 알림을 받지 않도록 설정할 수도 있어야 하나요?
◦
하루에 몇 건의 알림을 보낼 수 있어야 하나요?
2단계 개략적 설계안 제시 및 동의 구하기
알림 유형별 지원 방안
•
우선 각각의 알림 메커니즘이 어떻게 동작하는지 알아보자.
•
iOS 푸시 알림
◦
iOS에서 푸시 알림을 지원하기 위해서는 세 가지 컴포넌트가 필요하다.
▪
알림 제공자
•
알림 요청을 만들어, 애플 푸시 알림 서비스에게 보내는 주체다. 알림 요청을 만들기 위해 다음과 같은 데이터가 필요하다.
◦
단말 토큰 : 알림 요청을 보내는데 필요한 고유 식별자
◦
페이로드 : 알림 내용을 담은 JSON 딕셔너리
▪
APNS
•
애플이 제공하는 원격 서비스로, 푸시 알림을 iOS 장치로 보내는 역할을 수행한다.
▪
iOS 단말
•
푸시 알림을 수신하는 사용자 단말이다.
•
안드로이드 푸시 알림
◦
안드로이드 역시 비슷한 절차로 진행된다. APNS 대신 FCM을 사용한다는 점만 다르다.
•
SMS 메시지
◦
SMS 메시지를 전송할 경우, 보통 트윌리오나 넥스모 같은 제 3 사업자의 서비스를 많이 이용한다.
•
이메일
◦
센드그리드, 메일침프 등의 상용 이메일 서비스를 많이 사용한다.
연락처 정보 수집 절차
•
알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다.
•
이는 사용자가 우리 앱을 설치하거나 회원가입을 진행할 때, API 서버가 정보를 수집하여 데이터베이스에 저장하도록 둔다.
알림 전송 및 수신 절차
•
개략적 설계안
◦
서비스가 알림을 요청한다.
◦
알림 시스템은 알림 전송/수신 처리의 핵심으로, 알림 전송을 위한 API를 제공하며, 제3자 서비스에 제공할 페이로드를 만들어낼 수 있어야 한다.
◦
제 3자 서비스는 사용자에게 알림을 실제로 전달하는 역할을 수행한다.
•
이 설계에는 문제점이 있다.
◦
알림 시스템이 단일 실패 지점이다.
◦
한 대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로 확장성이 떨어진다.
◦
서버가 하나이므로 성능 병목 지점이 될 수도 있다.
•
개략적 설계안 개선된 버전
◦
개요
▪
데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리한다.
▪
알림 서버를 증설하고 자동으로 수평적 규모 확장이 일어날 수 있도록 한다.
▪
메시지 큐를 이용해 시스템 컴포넌트 사이의 강결합을 끊는다.
◦
상세
▪
서비스는 알림 시스템 서버의 API를 이용해 알림을 요청한다.
▪
알림 서버는 다음 기능을 제공한다.
•
알림 전송 API
•
알림 검증
◦
이메일 주소, 전화번호 등에 대한 기초 질의를 수행한다.
•
데이터베이스 또는 캐시 질의
◦
알림에 포함시킬 데이터를 가져온다.
•
알림 전송
◦
알림 데이터를 메시지 큐에 넣어, 작업 서버에게 처리를 위임한다.
▪
데이터베이스
•
사용자, 알림, 수신 설정 등 다양한 정보를 저장한다.
▪
메시지 큐
•
시스템 컴포넌트 간의 의존성을 제거하기 위해 사용한다.
•
다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할도 수행한다.
▪
작업 서버
•
메시지 큐에서 전송할 알림을 꺼내어 제 3자 서비스로 전달하는 역할을 담당한다.
▪
제3자 서비스
•
기존과 같다.
•
알림 전송 절차
1.
API를 호출하여 알림 서버로 알림을 보낸다.
2.
알림 서버는 사용자 정보, 단말 토큰, 알림 설정 같은 메타데이터를 캐시나 데이터베이스에서 가져온다.
3.
알림 서버는 전송할 알림에 맞는 이벤트를 만들어 메시지 큐에 넣는다.
4.
작업 서버는 메시지 큐에서 알림 이벤트를 꺼낸다.
5.
작업 서버는 알림을 제3자 서비스로 전송한다.
6.
제3자 서비스는 알림 요청을 받아 이를 사용자들에게 전송한다.
3단계 상세 설계
안정성
•
데이터 손실 방지
◦
알림이 지연되거나 순서가 바뀌어도 괜찮지만 요청이 사라져서는 안 된다.
◦
이 요구사항을 만족하려면 알림 시스템은 아림 데이터를 데이터베이스에 보관하고 재시도 메커니즘을 구현해야 한다.
◦
알림 로그 데이터베이스를 사용하여 구현하는 것이 하나의 예다.
•
알림 중복 전송 방지
◦
같은 알림이 여러 번 전송되는 것을 완전히 방지하는 것은 불가능하다.
◦
그러나 그 빈도를 줄이려면 중복을 탐지하는 메커니즘을 도입하고 오류를 신중하게 처리해야 한다.
▪
보내야 할 알림이 도착하면 그 이벤트 ID를 검사하여 기존에 전송한 이력이 있는지 살펴본다.
추가로 필요한 컴포넌트 및 고려사항
•
알림 설정
◦
사용자는 이미 너무 많은 알림을 받고 있기 때문에 수신 설정과 관련해 상세한 의사 결정이 필요하다.
•
전송률 제한
◦
한 사용자가 너무 많은 알림을 받지 않도록 제한하는 것도 필요하다.
•
재시도 방법
◦
제3자 서비스가 알림 전송에 실패했다는 결과를 반환하는 경우, 이를 재시도 전용 큐에 넣는다.
◦
반복해서 실패하는 경우, 개발자에게 문의한다.
•
푸시 알림과 보안
◦
제 3자의 알림 전송 API를 사용할 때, 키와 시크릿을 사용해 보안을 유지하자.
•
큐 모니터링
◦
큐에 쌓인 알림의 갯수 또한 중요하다. 이 수가 너무 크면 작업 서버들이 빠르게 쳐내지 못하고 있단 뜻으로 작업 서버를 증설하게 될 좋은 이유가 되어줄 것이다.
•
이벤트 추적
◦
알림 확인, 클릭율, 실제 앱 사용으로 이어지는 비율 등의 메트릭은 사용자를 이해하는데 중요하다.
◦
데이터 분석 서비스는 보통 이벤트 추적 기능도 제공하므로 이를 붙여주는 것도 좋다.
수정된 설계안
•
알림 서버에 인증과, 전송률 제한 기능을 추가할 수 있다.
•
전송 실패에 대한 재시도 로직을 추가할 수 있다.
•
전송 템플릿을 사용하여 알림 생성 과정을 단순화하고 일관성을 확보할 수 있다.
•
모니터링과 추적 시스템을 붙여 시스템 상태를 확인하고 추후 시스템 개선의 자료로 사용할 수 있다.
4단계 마무리
•
개략적 설계안과 더불어 알림 시스템을 구현하는데, 아래 주제에 집중하였다.
◦
안정성 : 메시지 전송 실패율을 낮추기 위한 재시도 로직 도입
◦
보안 : 인증된 클라이언트만이 알림을 보낼 수 있도록 인증 절차 추가
◦
이벤트 추적 및 모니터링 : 알림이 만들어진 후 전송되기까지의 과정을 추적하고 시스템 상태를 모니터링하기 위해 전송의 각 단계마다 이벤트를 추적할 수 있는 시스템을 붙여볼 수 있다.
◦
사용자 설정 : 사용자의 알림 수신 설정을 조정할 수 있도록 제공한다.
◦
전송률 제한 : 하나의 사용자에게 알림을 보내는 빈도를 제한하여 피로도를 낮출 수 있게끔 해줄 수 있다.
