본문 바로가기

Architecture

[Architecture]알림시스템 설계

개요

이 글은 푸시 알림, SMS, 이메일을 통합한 확장 가능한 알림 시스템의 설계와 구현 방법을 다룹니다. 연성 실시간 시스템으로 설계되어 높은 부하에도 대응할 수 있으며, 다양한 단말을 지원합니다.

요구사항 분석

알림 시스템은 다음 요구사항을 충족해야 합니다:

  • 지원 알림 유형: 푸시, SMS, 이메일
  • 성능 특성: 연성 실시간(soft real-time) 시스템, 높은 부하 시 약간의 지연 허용
  • 지원 단말: iOS, Android, 노트북, 데스크톱
  • 사용자 설정: opt-out 기능(사용자가 알림을 받지 않도록하는 기능) 지원
  • 확장성: 천만 건의 모바일 푸시, 백만 건의 SMS, 5백만 건의 이메일 처리 가능

알림 유형별 지원 방안

iOS 푸시 알림

iOS 푸시 알림 흐름:

알림 제공자 → APNS → iOS 단말
  • 알림 제공자(Provider): 알림 요청 생성 및 APNS로 전송. 알림 요청을 보내려면 device token, paload 데이터가 필요
  • APNS (Apple Push Notification Service): Apple push Notification Service, 애플이 제공하는 원격 서비스. 푸시 알림을 IOS 장치로 보내는 역할

Android 푸시 알림

Android는 FCM(Firebase Cloud Messaging)을 사용합니다.

알림 제공자 → FCM → Android 단말

SMS 메시지

알림 제공자 → SMS 서비스 → SMS 수신 단말

이메일

알림 제공자 → 이메일 서비스 → 이메일 수신 단말

시스템 아키텍처 설계

알림 전송 과정:

  1. 클라이언트가 API를 통해 알림 서버로 요청 전송
  2. 알림 서버가 메타데이터(사용자 정보, 단말 토큰, 설정 등) 조회
  3. 알림 서버가 알림 이벤트 생성 후 메시지 큐에 삽입
  4. 작업 서버가 메시지 큐에서 알림 이벤트 추출
  5. 작업 서버가 제3자 서비스로 알림 전송
  6. 제3자 서비스가 사용자 단말로 알림 전달

주요 컴포넌트 상세 설명

알림 시스템 (Notification System)

  • API 제공 및 인증 관리: 스팸 방지를 위해 사내 서비스 또는 인증된 클라이언트만 이용 가능
    • [인증] IOS, 안드로이드 의 경우 인증(appKey, appSecret)되거나 승인된 클라이언트에게만 알림을 보낼 수 있습니다.
  • 알림 페이로드 생성 및 검증
  • 데이터베이스/캐시 조회: 알림에 포함시킬 데이터를 가져오는 기능
    • [Database] 알람 설정 테이블에 opt_in 필드를 사용하여 해당 채널로 알림을 받을 것인지 여부를 확인합니다. 특정 종류의 알림을 보내기 전에 반드시 해당 사용자가 해당 알림을 켜 두었는지 확인해야 합니다.
  • 알림 이벤트 생성 및 큐 삽입
  • 수평적 확장(Scale-out) 지원

제3자 서비스

  • 새로운 서비스 통합 및 기존 서비스 제거가 용이한 설계

캐시

  • 사용자 정보, 단말 정보, 알림 템플릿 등 캐싱

데이터베이스

  • 사용자, 알림, 설정 등 정보 저장
  • 알림 설정 테이블 예시:
  • CREATE TABLE notification_settings ( user_id INT PRIMARY KEY, push_opt_in BOOLEAN, sms_opt_in BOOLEAN, email_opt_in BOOLEAN );

메시지 큐

  • 컴포넌트 간 결합도 감소
  • 부하 분산 및 버퍼링
  • 알림 유형별 독립적인 큐 사용: 알림의 종류별로 별도의 메세지 큐를 사용하여 제 3자 서비스 가운데 하나의 장애가 발생하여도 다른 종류의 알림은 정상 동작합니다.

작업 서버

  • 메시지 큐에서 알림 추출 및 제3자 서비스로 전송
  • 알림 로그 기록 및 재시도 메커니즘 구현:
    • 알림 데이터를 알림 로그 데이터베이스에 보관하고 재시도 매커니즘을 구현한다. 전송에 실패한 알림은 다시 큐에 넣고 지정된 횟수만큼 재시도하여 데이터 손실을 방지합니다.
  • 중복 이벤트 처리
    • 보내야할 알림이 도착하면 이벤트 ID를 검사하여 이전에 있는 이벤트인지 확인한다. 중복된 이벤트라면 버리고, 그렇지 않으면 알림을 발송한다.

알림 템플릿

  • 재사용 가능한 알림 형식 정의
  • 예시 템플릿:
  • { "template_id": "welcome_push", "title": "환영합니다, {user_name}님!", "body": "{app_name}에 오신 것을 환영합니다. 지금 바로 둘러보세요!", "deep_link": "myapp://home" }

확장성과 신뢰성 확보 전략

  • 수평적 확장: 모든 컴포넌트의 Scale-out 설계
  • 비동기 처리: 메시지 큐를 통한 비동기 처리로 시스템 안정성 향상
  • 재시도 메커니즘: 일시적 장애 대응을 위한 알림 재전송 로직
  • 서비스 분리: 알림 유형별 독립적인 처리로 장애 격리

이벤트 추적과 모니터링

알림 확인율, 클릭율 실제 앱 사용으로 이어지는 비율과 같은 메트릭은 사용자를 이해하는데 중요합니다. 따라서 알림 시스템을 만들면 아래와 같이 데이터 분석 서비스와도 통합하는것이 좋습니다.

  • 주요 모니터링 지표:
    • 알림 전송 성공률
    • 알림 확인률
    • 클릭률 (Click-through Rate, CTR)
    • 앱 실행으로 이어지는 비율
  • 데이터 분석 서비스와의 통합으로 사용자 행동 패턴 분석