개요
이 글은 푸시 알림, 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 수신 단말
이메일
알림 제공자 → 이메일 서비스 → 이메일 수신 단말
시스템 아키텍처 설계
알림 전송 과정:
- 클라이언트가 API를 통해 알림 서버로 요청 전송
- 알림 서버가 메타데이터(사용자 정보, 단말 토큰, 설정 등) 조회
- 알림 서버가 알림 이벤트 생성 후 메시지 큐에 삽입
- 작업 서버가 메시지 큐에서 알림 이벤트 추출
- 작업 서버가 제3자 서비스로 알림 전송
- 제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)
- 앱 실행으로 이어지는 비율
- 데이터 분석 서비스와의 통합으로 사용자 행동 패턴 분석
'Architecture' 카테고리의 다른 글
[Architecture]뉴스 피드 시스템설계 (1) | 2024.09.22 |
---|---|
[Architecture]아키텍처 설계와 검토의 핵심 원칙 (0) | 2024.08.31 |
[Architecture]분산 키-값 저장소 설계 (0) | 2024.08.25 |
[Architecture]개략적인 규모를 추정하는 방법 (0) | 2024.08.24 |
[Architecture]처리율 제한 장치 설계(Rate limiting) (0) | 2024.03.31 |