알림시스템은 단순히 모바일 푸시 알림으로 한정되지 않는다.
모바일 푸시 알림, SMS 메시지, 이메일로 3가지의 분류가 존재한다.
시스템 설계 전 충분한 질문을 통해 문제를 이해하고 범위를 확정짓자.
- Q1: 어떤 종류의 알림을 지원하나요?
- A1: 푸시 알림, SMS 메시지, 이메일 3가지 모두 지원합니다.
- Q2: 실시간 시스템이어야 하나요?
- A2: 약한 실시간으로 평시에는 실시간으로 알림을 지원하지만, 리소스 부하가 있을시에는 약간의 지연도 무관합니다.
- Q3: 어떤 종류의 단말을 지원하나요?
- A3: 안드로이드, ios, pc 모두 지원해야 합니다.
- Q4: 알림을 만드는 주최는 누구인가요?
- A4: 클라이언트 애플리케이션 프로그램이 만들 수도 있으며, 서버측에서 스케줄링 할수도 있습니다.
- Q5: 사용자가 알림을 받지 않도록 설정할 수도 있나요?
- A5: 네 설정 가능해야 합니다.
- Q6: 하루에 몇건의 알림을 보낼 수 있어야 하나요?
- A6: 천만건의 모바일 푸시알림, 백만건의 SMS 메시지, 5백만건의 이메일을 보낼 수 있어야 합니다.
위 질문을 토대로 개략적인 설계안을 도출해야한다.
위 알림 시스템에서는 다음 3가지에 대해서 개략적으로 어떻게 아키텍팅할건지 정해야 합니다.
- 알림 유형별 지원 방안
- 연락처 정보 수집 절차
- 알림 전송 및 수신 절차
알림의 경우에는 중간에 실제로 알림을 푸시하는 서비스들이 존재한다.
각 단말기 및 알림 종류에 따라 서비스들은 아래 그림과 같다.
알림을 보내기 위해서는 사용자와 사용자가 가지고 있는 기기의 정보가 필요하다.
이는 앱 설치 혹은 계정 등록 했을때 수집하여 DB화를 해야 한다.
DB 테이블에는 다음과 같이 1:N 으로 사용자 한명이 여러 기기를 소유할 수 있도록 연관관계를 가져가도록 한다.
아래는 위 내용들을 토대로 만든 개략적인 설계안이다.
하지만 여기에는 몇가지 문제점이 있다.
- SPOF: 알림 서비스에 서버가 하나밖에 없어 서버 장애시 서비스 전체에 장애로 이어지게 된다.
- 규모 확장성: 한대 서비스로 푸시알림에 관계된 모든것을 처리하므로 DB나 캐시 등 중요 컴포넌트의 규모를 늘릴 방법이 없다.
- 성능 병목: 동일하게 서버 한대로 모든것을 처리하면 알림 요청이 몰린 경우 성능 병목이 될 수 있다.
때문에 아래와 같이 개선시키도록 한다.
- 알림서버와 작업서버로 나누어 N개의 서버들을 운용하도록 한다.
- 제 3자 제공 서비스의 실패를 대비하여 중간에 큐를 두어 재시도 할 수 있도록 만든다.
- 알림 핫스팟 대비 알림 특성상 조회가 많아 중간에 캐시를 활용하도록 한다.
상세설계에서는 다음 2가지에 대해서 더욱 디테일하게 다룰 것이다.
- 안정성
- 추가로 필요한 컴포넌트 및 고려사항
서버를 N대인 분산환경으로 가는 경우 데이터 안정은 항상 고려해야 한다.
데이터 손실 방지
알림의 경우 지연되거나 순서가 틀리는것은 괜찮지만 유실이 되서는 안된다.
때문에 다음과 같이 알림 로그를 DB화 하는 방법을 채택할 수 있다.
중복 전송 방지
알림의 중복을 100% 없애는 것은 불가능하다.
다만 빈도는 줄여야 하기 때문에 중복을 탐지하여 제거하는 메커니즘을 도입해야 한다.
보내야 할 알림이 도착하면 이벤트 ID를 검사하여 이전에 본적이 있는 이벤트인지 살핀다.
알림 시스템은 사실상 고려할 부분들이 많다.
고려할 부분들은 다음과 같다.
- 알림 템플릿
- 알림 설정
- 이벤트 추적
- 시스템 모니터링
- 처리율 제한
알림 템플릿
알림의 경우 대부분 형식이 매우 비슷하다.
이를 고려하여 템플릿화를 시킨다면 알림을 생성하는 비용을 크게 줄일 수 있다.
또한 템플릿 가이드를 그대로 따라서 만든다면 오류율 또한 줄게 될 것이다.
알림 설정
모든 알림을 무분별하게 받게하기 보다는 사용자마다 어떤 알림만을 받을 것인지를 설정하는게 좋다.
이는 데이터베이스에 사용유무를 나타내는 컬럼을 추가하여 해결이 가능하다.
전송률 제한
너무 많은 알림이 가지 않도록 중간에 제한을 하도록 해야한다.
재시도 방법
재시도의 경우에는 위 설계안에 있는 큐를 통해 어느정도 커버가 가능하다.
이때 무한 재시도가 되지 않도록 재시도 횟수를 정하여야 하며, 넘는 경우에는 개발자에게 알람을 보내도록 한다.
큐 모니터링
알림 시스템을 모니터링 할때 중요한 메트릭 하나는 큐에 쌓인 알림의 갯수이다.
주기적으로 큐의 데이터(= kafka 라면 lag) 메트릭을 수집하여 상황에 맞는 서버수를 가용하도록 해야한다.
이벤트 추적
보통 알림 시스템을 만들면 데이터 분석 서비스와도 통합해야만 한다.
데이터 분석 서비스에는 대개 이벤트 추적 기능도 제공하고 있어 활용하도록 하자.
위는 알림의 상태를 두어 추적을 하는 과정을 보인 그림이다.
