Skip to main content

10장. 알림 시스템 설계

  • 알림 시스템은 모바일 푸시 알림, SMS 메시지, 이메일의 세 가지로 분류할 수 있습니다.

1단계 문제 이해 및 설계 범위 확정#

  • 요구사항
    • 푸쉬 알림, SMS 메시지, 이메일 모두 지원 필요
    • 연성 실시간 시스템 (가능한 빨리 필요하나, 약간의 지연은 괜찮음)
    • ios, android, 데스크톱을 지원해야함
    • 클라이언트 애플리케이션 프로그램 혹은 서버 측의 스케줄링
    • 사용자가 알림을 받지 않도록(opt-out) 설정할 수도 있습니다.
    • 하루에 첫만 건의 모바일 푸시 알림, 백만 건의 SMS 메시지, 500백만 건의 이메일을 보낼 수 있어야 함.

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

  • 아래와 같은 이야기에 대해 이야기합니다.
    • 알림 유형별 지원 방안
    • 연락처 정보 수집 절차
    • 알림 전송 및 수신 절차

알림 유형별 지원 방안#

iOS 푸시 알림#

  • ios에서 푸시 알림을 보내기 위해서는 세 가지 컴포넌트가 필요합니다.
    • 알림 제공자(provider)
    • APNS: 애플이 제공하는 원격 서비스
    • iOS 단말: 푸시 알림을 수신하는 사용자 단말입니다.

안드로이드 푸시 알림#

  • iOS와 비슷하나 APNS 대신 FCM(Firebase Cloud Messaging)을 사용합니다.

SMS 메시지#

  • 보통 제 3사업자의 서비스를 많이 사용합니다.

이메일#

  • 대부분이 회사는 고유 이메일 서버를 구축할 역량이 있으나 상용 이메일 서비스를 이용합니다.

연락처 정보 수집 절차#

  • 알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요합니다.

알림 전송 및 수신 절차#

개략적 설계안 (초안)#

기초적 설계

  • SPOF(Single-Point-Of-Failure): 알림 서비스에 서버가 하나밖에 없다는 것은, 그 서버에 장애가 생기면 전체 서비스의 장애로 이어집니다.
  • 규모 확장성: 한 대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로, 데이터베이스나 캐시 등 중요 컴포넌트의 규모를 개별적으로 늘릴 수 없습니다.
  • 성능 병목: 알림을 처리하고 보내는 것은 자원을 많이 필요로 하는 작업일 수 있습니다. 즉, 트래픽이 몰리면 과부하 상태에 빠질 수 있습니다.

개선된 버전 (초기버전)#

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

개선된 설계

  • 알림 서버
    • 알림 전송 API
    • 알림 검증
    • 데이터베이스 또는 캐시 질의
    • 알림 전송
  • 캐시: 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시합니다.
  • 데이터베이스(DB): 사용자, 알림, 설정 등 다양한 정보를 저장
  • 메시지 큐(message queue): 시스템 컴포넌트 간 의존성을 제거하기 위해 사용
  • 작업 서버(workers): 메시지 큐에서 전송할 알림을 꺼내서 제3자 서비스로 전달

3단계 상세 설계#

  • 아래의 내용에 대해 더 자세하게 봅니다.
    • 안정성(reliability)
    • 추가로 필요한 컴포넌트 및 고려사항
    • 개선된 설계안

안정성#

  • 데이터 손실 방지
  • 알림 중복 전송 방지

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

  • 알림 템플릿
  • 알림 설정
  • 전송률 제한
  • 재시도 방법
  • 푸쉬 알림과 보안
  • 큐 모니터링
  • 이벤트 추적

수정된 설계안#

수정된 설계안


4단계 마무리#

  • 개략적 설계안과 더불어 각 컴포넌트의 구현 방법과 최적화 기법에 집중했으며, 아래의 주제에 대해 이야기했습니다.
    • 안정성
    • 보안
    • 이벤트 추적 및 모니터링사용자 설정
Edit this page
Last updated on