10. 알림 시스템

💬 알림 전송 방식

IOS 푸시 알림

• 알림 제공자(provider): 알림 요청(notification request)을 만들어 애플 푸시 알림 서비스(APNS: Apple Push Notification Service)로 보내는 주체

• 단말 토큰(device token): 알림 요청을 보내는 데 필요한 고유 식별자다.

• 페이로드(payload): 알림 내용을 담은 JSON 딕셔너리(dictionary)

• APNS: 애플이 제공하는 원격 서비스다. 푸시 알림을 iOS 장치로 보내는 역할을 담당한다.

안드로이드 푸시 알림

• APNS 대신 FCM(Firebase Cloud Messaging)을 사용한다.

SMS 메시지

• 보통 SMS 서비스를 제공하는 API를 사용한다.

이메일

• 이메일 서버를 구축해 사용하거나 Mailchimp, Sendgrid 등의 서비스를 이용할 수 있다.

💬 알림 시스템

• SPoF 가 발생하지 않도록 알림 서비스에 서버를 여러 대 두어야 한다.

• 알람 시스템 사용량이 많아졌을 때 쉽게 확장할 수 있어야 하고 성능에 문제가 없어야 한다. 데이터베이스나 캐시 등 중요 컴포넌트 규모를 개별적으로 늘릴 수 있어야 한다.

• 알림 서버에서는 다음 기능을 제공한다.

  • 알림 전송을 위한 API 엔드포인트 제공

  • 이메일, 전화번호 등 알림 내용 검증

  • DB 혹은 캐시 질의로 알림에 포함될 데이터(사용자 및 단말 정보, 알림 템플릿 등) 조회

  • 메시지 큐에 알림 추가

안정성 확보를 위한 방법

• 데이터 손실 방지

  • 알람이 지연되거나 순서가 틀리는 것보다 손실되지 않는 것이 가장 중요하다.

  • 알림을 보낼 수 없는 상황이라면 알림을 데이터베이스에 보관 후 재시도 매커니즘을 구현해야 한다.

• 알림 중복 전송 방지

  • 알림 중복을 탐지하는 매커니즘을 도입하고 오류를 신중히 처리해야 한다.

  • 알림의 이벤트 ID를 검사하여 이전에 이미 보낸 알림인지 확인 후에만 발송하도록 할 수 있다.

그 외 컴포넌트

• 알림 템플릿

  • 알림 메시지의 형식이 대부분 비슷하므로 템플릿을 만들어두고 내용을 채우는 형태로 사용하는 것이 좋다.

• 알림 설정

  • 사용자가 알림 설정을 상세히 조정할 수 있도록 해야 한다.

  • 특정 종류의 알람을 보내기 전 사용자가 해당 알림을 켜두었는지 반드시 확인해야 한다.

• 전송률 제한

  • 한 사용자가 받을 수 있는 알람의 빈도를 제한해야 한다.

• 재시도 방법

  • 알림 발송에 실패하면 재시도 전용 큐에 넣고 재시도 처리해야 한다.

• 푸시 알림과 보안

  • IOS, 안드로이드는 appKey, appSecret을 이용해 보안을 유지할 수 있다.

  • 인증되거나 승인된 클라이언트만 알림 전송 API를 사용할 수 있어야 한다.

• 큐 모니터링

  • 큐에 쌓인 알림의 개수가 너무 크지 않도록 해야 한다. 만약 큐에 점점 알림 수가 많아진다면 작업 서버를 증설해야 한다.

• 이벤트 추적

  • 알림 확인율, 클릭율 등 사용자가 어떻게 행동했는지 분석하는 것이 중요하다. 따라서 데이터 분석 서비스와 통합해 사용해야 한다.