• 알림 시스템: 모바일 푸시 알림, SMS 메시지, 이메일

문제 이해 및 설계 범위 확정

  • 연성 실시간 시스템: 가능한 한 빨리 전달되어야 하지만 시스템에 높은 부하가 걸렸을 떄 약간의 지연은 무장
  • 지원 단말: iOS, 안드로이드, 랩탑/데스크탑
  • 알림을 만드는 대상: 클라이언트 애플리케이션 프로그램, 서버 측의 스케줄링
  • 사용자가 알리믕 받지 않도록 설정 가능
  • 하루에 천만 건의 모바일 푸시 알림, 백만 건의 SMS 메시지, 5백만 건의 이메일

개략적 설계안 제시 및 동의 구하기

알림 유형별 지원 방안

  • iOS 푸시 알림
    • 세 가지 컴포넌트가 필요하다.
      • 알림 제공자: 알림 요청을 만들어 애플 푸시 알림 서비스(APNS)로 보내는 주체
        • 알림 요청을 만들려면 다음과 같은 데이터가 필요하다.
          • 단말 토큰: 알림 요청을 보내는 데 필요한 고유 식별자
          • 페이로드: 알림 내용을 담은 JSON 딕셔너리다.
      • APNS: 애플이 제공하는 우너격 서비스다. 푸시 알림을 iOS 장치로 보내는 역할을 담당한다.
      • iOS 단말: 푸시 알림을 수신하는 사용자 단말이다.
  • 안드로이드 푸시 알림
    • iOS와 유사하지만 APNS 대신 FCM(Firebase Cloud Messaging)을 사용한다.
  • SMS 메시지
  • 이메일

연락처 정보 수집 절차

  • 알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다.
  • API 서버는 사용자의 정보를 수집하여 데이터베이스에 저장한다.

알림 전송 및 수신 절차

개략적 설계안 (초안)

  • 1부터 N까지의 서비스: 마이크로 서비스, 크론잡, 분산 시스템 컴포넌트 등
  • 알림 시스템: 알림 전송/수신의 핵심.
    • 서비스에 알림 전송을 위한 API를 제공해야 하고, 제3자 서비스에 전ㄷ날할 알림 페이로드를 만들어 낼 수 있어야 한다.
  • 제3자 서비스: 사용자에게 알림을 실제로 전달하는 역할
  • iOS, 안드로이드, SMS 이메일 단말
  • 해당 설계의 문제점
    • SPOF: 알림 서비스에 서버서가 하나밖에 없다.
    • 규모 확장성: 한 대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로, 데이터베이스나 캐시 등 중요 컴포넌트의 규모를 개별적으로 늘릴 방법이 없다.
    • 성능 병목: 알림을 처리하고 보내는 것은 자원을 많이 필요로 하는 작업일 수 있다. 따라서 모든 것을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에는 시스템이 과부하 상태에 빠질 수 있다.

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

  • 데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리한다.
  • 알림 서버를 증설하고 자동으로 수평적 규모 확징이 이루어질 수 있도록 한다.
  • 메시지 큐를 이용해 컴포넌트 사이의 강한 결합을 끊는다.

상세 설계

  • 안정성
    • 데이터 손실 방지: 알림이 소실되면 안된다.
      • 이 요구 사항을 만족하려면 알림 시스템은 알림 데이터를 데이터베이스에 보관하고 재시도 메커니즘을 구현해야 한다.
      • 알림 중복 전송 방지: 완전히 막는 것은 가능하지 않다. 빈도를 줄이려면 중복을 탐지하는 메커니즘을 도입하고, 오류를 신중하게 처리해야 한다.
        • 중복 방지 사례: 보내야 할 알림이 도착하면 그 이벤트 ID를 검사하여 이전에 본 적이 있는 이벤트인지 살핀다. 중복된 이벤트라면 버리고, 그렇지 않으면 알림을 발송한다.
  • 추가로 필요한 컴포넌트 및 고려사항
    • 알림 템플릿: 파라미터나 스타일, 추적 링크를 조정하기만 하면 사전에 지정한 형식에 맞춰 알람을 만들어 내는 틀
    • 알림 설정: 사용자가 너무 많은 알림을 받고 있어서 피곤함을 느끼지 않도록 하기 위해, 알림 설정 테이블에 아래와 같은 데이터를 보관한다.
      • user_id(bigint), channel(varchar), opt_in(boolean)
    • 전송률 제한: 사용자에게 너무 많은 알림을 보내지 않도록 하기 위해 제한한다.
    • 재시도 방법: 제 3자 서비스가 알림 전송에 실패하면, 해당 알림을 재시도 전용 큐에 넣는다.
    • 푸시 알림과 보안: iOS와 안드로이드 앱의 경우, 알림 전송 API는 appKey와 appSecret을 사용한다.
    • 큐 모니터링: 큐에 쌓인 알림의 개수를 메트릭으로 모니터링하여, 작업 서버들이 미벤트를 빠르게 처리하고 있는지 확인해야 된다.
    • 이벤트 추적: 알림 확인율, 클릭율, 실제 앱 사용으로 이어지는 비율 같은 메트릭을 수집하여 사용자를 이해하는데 사용한다.