설계 범위

• 알림 지원 유형
  • 푸시 알림: 천만 건 / 일
  • SMS 메시지: 백만 건 / 일
  • 이메일: 5백만 건 / 일
• 연성 실시간 시스템: 가능한 빨리 전달되어야 하지만, 약간의 지연 무방
• 지원해야하는 단말: iOS, 안드로이드, 랩톱/데스크톱
• 알림 생성: 클라이언트 애플리케이션
• 알림 on/off 설정

설계안

알림 유형별 지원 방안

iOS 푸시 알림

1. 알림 제공자: 알림 요청을 만들어 애플 푸시 알림 서비스로 보내는 주체

• 단말 토큰: 알림 요청을 보낼 때 필요한 고유 식별자
• 페이로드: 알림 내용

{
    "aps": {
        "alert": {
            "title": "Game Request",
            "body": "Bob wants to play chess",
            "action-loc-key": "PLAY"
        },
        "badge": 5
    }
}

1. APNS: 푸시 알림을 iOS 장치로 보내는 역할
2. iOS 단말: 푸시 알림을 수신하는 사용자 단말

안드로이드 푸시 알림

iOS에서 APNS 대신 FCM(Firebase Cloud Messaging) 사용

SMS 메시지

보통 상용 서비스(트윌리오, 넥스모 등) 이용

이메일

보통 상용 서비스(샌드그리드, 메일침프 등) 이용

이메일 서버를 구축하는 건 어렵지 않지만, 전송 성공률과 데이터 분석 서비스가 잘 되어 있기 때문

연락처 정보 수집 절차

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

위처럼 한 사용자가 여러 단말을 가질 수 있고, 알림은 모든 단말에 전송되어야 한다는 점을 고려해 필요한 정보를 저장

알림 전송 및 수신 절차

1부터 N까지의 서비스

각각은 마이크로서비스, 크론잡, 분산 시스템 컴포넌트 등일 수 있다.

ex) 사용자에게 납기일을 알리고자 하는 과금 서비스, 배송 알림을 보내려는 쇼핑몰 등

알림 시스템

알림 전송/수신 처리의 핵심

이 시스템은 N개의 서비스에 알림 전송을 위한 API를 제공하고, 제3자 서비스(APNS, FCM..)에 전달할 알림 페이로드를 만들어 내야한다.

제3자 서비스

이 서비스들은 사용자에게 알림을 실제로 전달하는 역할

유의할 점

• 항상 외부 서비스를 이용할 땐 “확장성” 고려
• 다른 시장에서 사용할 수 없는 서비스도 존재
  - ex) 중국 시장에서는 FCM 사용 불가
  

설계안

위 설계의 문제점

• SPOF: 알림 서비스에 서버(알림 시스템)가 하나 밖에 없다는 점
• 규모 확장성: 하나의 서비스로 푸시 알림에 관계된 모든 것을 처리하고 있어, DB나 캐시 등 중요 컴포넌트 규모를 개별적으로 늘릴 방법 X
• 성능 병목: 알림 기능은 자원을 많이 필요로 하는 작업, 시스템이 과부하 상태에 빠질 수 O

개선된 설계안

• 데이터베이스와 캐시를 알림 시스템의 주 서버와 분리
• 알림 서버를 증설하고, 자동을 수평적 규모 확장이 가능하도록
• 메시지 큐 이용 → 시스템 컴포넌트 사이의 결합 끊기

알림 서버

• 알림 전송 API: 인증된 클라이언트만 이용 가능(스팸 방지)
• 알림 검증: 이메일 주소, 전화번호 등에 대한 검증 수행
• 데이터베이스 or 캐시 질의: 알림에 포함시킬 데이터 조회
• 알림 전송: 알림 데이터 큐에 전송

상세 설계

안정성

데이터 손실 방지

알림 전송 시스템의 중요한 요구사항은?

→ 어떤 상황에서도 알림이 소실되면 안된다

알림 데이터를 데이터베이스에 보관하고, 재시도 매커니즘이 있어야 한다

알림 중복 전송 방지

분산 시스템 특성상 같은 알림이 중복되어 전송될 수도 있다.

그 빈도를 줄이기 위해 중복 탐지 매커니즘 도입이 필요

• 보내야 할 알림 도착 시, 그 이벤트 ID 검사

추가 컴포넌트 및 고려사항

• 알림 템플릿
• 알림 설정
• 전송률 제한
  • 너무 많은 알림을 전송할 수 없도록
• 재시도 방법
  • 알림 전송 실패시, 해당 알림을 재시도 전용 큐에 넣는다.
• 푸시 알림과 보안
• 큐 모니터링

  • 큐에 쌓인 알림의 개수가 많다면, 이벤트를 빠르게 처리하지 못하고 있다는 뜻

    → 작업 서버를 증설하는 게 바람직

• 이벤트 추적
  • 알림 확인율, 클릭율, 실제 앱 사용으로 이어지는 비율 등 메트릭 중요
  • 보통 제3 알림 서비스에서 제공하는 데이터 분석 서비스가 이러한 이벤트 추적 서비스 제공

최종 설계안

• 안정성: 메시지 전송 실패율
• 보안: 인증된 클라이언트
• 이벤트 추적 및 모니터링
• 사용자 설정: 알림 수신 설정
• 전송률 제한: 알림 빈도 제한