10. 알림 시스템

💬 알림 전송 방식

알림 제공자(provider): 알림 요청(notification request)을 만들어 애플 푸시 알림 서비스(APNS: Apple Push Notification Service)로 보내는 주체
단말 토큰(device token): 알림 요청을 보내는 데 필요한 고유 식별자다.
페이로드(payload): 알림 내용을 담은 JSON 딕셔너리(dictionary)
APNS: 애플이 제공하는 원격 서비스다. 푸시 알림을 iOS 장치로 보내는 역할을 담당한다.

SPoF 가 발생하지 않도록 알림 서비스에 서버를 여러 대 두어야 한다.
알람 시스템 사용량이 많아졌을 때 쉽게 확장할 수 있어야 하고 성능에 문제가 없어야 한다. 데이터베이스나 캐시 등 중요 컴포넌트 규모를 개별적으로 늘릴 수 있어야 한다.
알림 서버에서는 다음 기능을 제공한다.
- 알림 전송을 위한 API 엔드포인트 제공
- 이메일, 전화번호 등 알림 내용 검증
- DB 혹은 캐시 질의로 알림에 포함될 데이터(사용자 및 단말 정보, 알림 템플릿 등) 조회
- 메시지 큐에 알림 추가

데이터 손실 방지
- 알람이 지연되거나 순서가 틀리는 것보다 손실되지 않는 것이 가장 중요하다.
- 알림을 보낼 수 없는 상황이라면 알림을 데이터베이스에 보관 후 재시도 매커니즘을 구현해야 한다.
알림 중복 전송 방지
- 알림 중복을 탐지하는 매커니즘을 도입하고 오류를 신중히 처리해야 한다.
- 알림의 이벤트 ID를 검사하여 이전에 이미 보낸 알림인지 확인 후에만 발송하도록 할 수 있다.

알림 템플릿
- 알림 메시지의 형식이 대부분 비슷하므로 템플릿을 만들어두고 내용을 채우는 형태로 사용하는 것이 좋다.
알림 설정
- 사용자가 알림 설정을 상세히 조정할 수 있도록 해야 한다.
- 특정 종류의 알람을 보내기 전 사용자가 해당 알림을 켜두었는지 반드시 확인해야 한다.
전송률 제한
- 한 사용자가 받을 수 있는 알람의 빈도를 제한해야 한다.
재시도 방법
- 알림 발송에 실패하면 재시도 전용 큐에 넣고 재시도 처리해야 한다.
푸시 알림과 보안
- IOS, 안드로이드는 appKey, appSecret을 이용해 보안을 유지할 수 있다.
- 인증되거나 승인된 클라이언트만 알림 전송 API를 사용할 수 있어야 한다.
큐 모니터링
- 큐에 쌓인 알림의 개수가 너무 크지 않도록 해야 한다. 만약 큐에 점점 알림 수가 많아진다면 작업 서버를 증설해야 한다.
이벤트 추적
- 알림 확인율, 클릭율 등 사용자가 어떻게 행동했는지 분석하는 것이 중요하다. 따라서 데이터 분석 서비스와 통합해 사용해야 한다.

Last updated 3 months ago