TIL

10장 알림 시스템 설계

알림 시스템 개략적 설계

• 알림 유형별 지원 방안
• 연락처 정보 수집 절차
• 알림 전송 및 수신 절차

알림 유형별 지원 방안

iOS 푸시 알림

• 세 가지 컴포넌트가 필요
• 알림 제공자(provider)
  • 알림 요청을 만들어 애플 푸시 서비스(APNS)로 보내는 주체
  • 알림 요청엔 다음 데이터가 필요
    • 단말 토큰: 알림 요청을 보내는 데 필요한 고유 식별자
    • 페이로드: 알림 내용을 담은 JSON 딕셔너리
• APNS(Apple Push Notification Service)
  • 애플이 제공하는 원격 서비스
  • iOS 장치로 푸시 알림을 보내는 역할을 담당
• iOS 단말: 푸시 알림을 수신하는 사용자 단말

안드로이드 푸시 알림

• iOS 푸시 알림과 비슷한 절차
• APNS 대신 FCM(Firebase Cloud Messaging)을 사용한다는 점만 다르다.

SMS 메시지

• 보통 트윌리오(Twilio), 넥스모(Nexmo) 같은 제3 사업자 서비스를 많이 이용
• 대부분 상용 서비스라 요금을 내야 한다.

이메일

• 대부분 회사는 고유 이메일 서버를 구축할 역량을 갖추고 있다.
• 그럼에도 상용 이메일 서비스를 많이 이용
  • 센드그리드(Sendgrid), 메일 침프(Mailchimp)
  • 전송 성공룔도 높고 데이터 분석 서비스도 제공

연락처 정보 수집 절차

• 알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요
• 처음 앱을 설치하거나 계정을 등록하며 사용자 정보를 DB에 저장

알림 전송 및 수신 절차

개략적 설계안 (초안)

• 1부터 N까지 서비스
  • 서비스 각각은 마이크로서비스일 수도, 크론잡일 수도, 분산 시스템 컴포넌트일 수도 있다.
• 알림 시스템
  • 알림 전송/수신 처리의 핵심
  • 1개 서버만 사용한다면 이 시스템은 1~N에 알림 전송을 위한 알림 API를 제공해야 한다.
  • 제3자 서비스에 전달한 알림 페이로드를 만들어낼 수 있어야 한다.
• 제3자 서비스
  • 사용자에게 알림을 실제로 전달하는 역할
  • 확장성을 고려하여 쉽게 새로운 서비스를 통합하거나 기존 서비스를 제거할 수 있어야 한다.
  • 또 하나 고려할 것은 어떤 서비스는 다른 시장에서 사용할 수 없다는 것
    • 가령 FCM은 중국에서 사용 불가
• 이 설계의 문제점
  • SPOF: 알림 서비스가 하나밖에 없어 그 서버에 장애가 생기면 전체 장애로 이어진다.
  • 규모 확장성: 한 대 서비스로 푸시 알림을 처리하므로 DB나 캐시 등 중요 컴포넌트 규모를 개별적으로 늘릴 방법이 없다.
  • 성능 병목: 트래픽이 몰리는 시간에 시스템 과부하 상태에 빠질 수 있다.

개략적 설계안 (개선된 버전)

• DB와 캐시를 알림 시스템의 주 서버에서 분리
• 알림 서버 증설 및 자동 수평적 규모 확장이 이루어지도록 한다.
• 메시지 큐를 이용해 컴포넌트 사이 강결합을 끊는다.

• 1부터 N까지 서비스
  • 알림 시스템 서버의 API를 통해 알림을 보낼 서비스들
• 알림 시스템
  • 알림 전송 API: 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용 가능
  • 알림 검증: 이메일 주소, 전화번호 등에 대한 기본 검증 수행
  • DB 또는 캐시 질의: 알림에 포함시킬 데이터를 가져오는 기능
  • 알림 전송: 알림 데이터를 메시지 큐에 넣는다.
• 캐시
  • 사용자 정보, 단말 정보, 알림 탬플릿 등을 캐시
• 데이터베이스
  • 사용자, 알림, 설정 등 다양한 정보 저장
• 메시지 큐
  • 시스템 컴포넌트 간 의존성 제거를 위해 사용
  • 다양한 알림이 전송되어야 할 때 버퍼 역할 수행
• 작업 서버
  • 메시지 큐에서 전송할 알림을 꺼내 제3자 서비스로 전달
• 제3자 서비스
  • 사용자에게 알림을 실제로 전달

알림 시스템 상세 설계

안정성

• 데이터 손실 방지
  • 어떤 상황에서도 알림이 소실되면 안 된다.
  • 알림을 DB 등에 보관하고 재시도 메커니즘을 구현해야 한다.
• 알림 중복 전송 방지
  • 분산 시스템 특성상 가끔 알림이 중복 전송되기도 한다.
  • 중복 전송 빈도를 줄이려면 중복 탐지 메커니즘을 도입해야 한다.
  • ex) 보내야 할 알림이 도착하면 이멘트 ID를 검사하여 본 적 있는 이벤트인지 판별

추가로 필요한 컴포넌트 및 고려사항

알림 템플릿

• 알림 템플릿은 메시지 유사성을 고려하여 메시지 모든 부분을 처음부터 다시 만들 필요 없도록 해 준다.
  • 대형 알림 시스템은 수백만 건 이상의 알림을 처리하지만 메시지 대부분 형식이 비슷하다.
• 알림 탬플릿은 설정 값을 조정하기만 하면 형식에 맞춰 알람을 만들어 낸다.
  • 인자(parameter)나 스타일, 추적 링크(tracking link) 등

알림 설정

• 많은 웹 사이트와 앱에선 사용자가 알림 설정을 조정할 수 있도록 한다.
  • 이 정보는 알림 설정 테이블에 보관
• 알림을 보내기 전 해당 사용자가 알림을 켜 두었는지 확인해야 한다.

전송률 제한

• 한 사용자에게 너무 많은 알림을 보내지 않도록 빈도를 제한해야 한다.
• 사용자가 알림 기능을 아예 꺼버릴 수도 있다.

재시도 방법

• 알림 전송에 실패하면 해당 알림을 재시도 전용 큐에 넣는다.
• 같은 문제가 계속 발생하면 개발자에게 통지(alert)

푸시 알림과 보안

• 인증된 혹은 승인된 클라이언트만 API를 사용하여 알림을 보낼 수 있다.
  • iOS와 안드로이드 앱의 경우 appKey와 appSecret을 사용

큐 모니터링

• 알림 시스템 모니터링 시 중요한 매트릭 하나는 큐에 쌓은 알림 개수이다.
  • 이 값이 너무 크면 작업 서버들이 이벤트를 빠르게 처리하고 있지 못하다는 뜻

이벤트 추적

• 알림 확인율, 클릭율, 실제 앱 사용으로 이어지는 비율은 사용자를 이해하는데 중요
• 데이터 분석 서비스를 통해 이러한 이벤트를 추적할 수 있다.
• 보통 알림 시스템을 만들면 데이터 분석 서비스와도 통합해야 한다.