10. 알림 시스템 설계

1. 문제 이해 및 설계범위 확장

• 어떤 종류의 알림을 지원?

  • 푸시 알림, SMS, 이메일

• 실시간 시스템?

  • soft real-time

    • 알림은 가능한 빨리 전달, 시스템에 높은 부하가 걸렸을 때 약간의 지연은 무방

• 어떤 종류 단말?

  • IOS, 안드로이드, 랩톱/데스크압

• 사용자에게 보낼 알림은 누가 만들어야함?

  • 클라이언트 어플리케이션

  • 서버 측에서도 가능

• 사용자가 알림을 받지 않도록 설정(opt-out) 가능?

  • yes

• 하루에 몇건의 알림?

  • 천만건 모바일 푸시

  • 백만건 SMS

  • 5백만건의 이메일

2. 개략적 설계안 제시, 동의 구하기

IOS 푸시 알림

![[Pasted image 20251004135518.png]]

• APNS : 애플이 제공하는 원격 서비스, 푸시 알림을 IOS 장치로 보내는 역할을 담당

  • Apple Notification Service

안드로이드

![[Pasted image 20251004135606.png]]

• FCM : Firebase Cloud Messaging

SMS 메세지

• Twilio, Nexmo 같은 상용 서비스 이용함. 이용 요금 필요함

이메일

• Sendgrid, Mailchimp 상용 서비스

연락처 정보 수집 철자

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

![[Pasted image 20251004135754.png]]

• 사용자가 여러개의 단말을 가질 수 있음.

• 알림은 모든 단말에 전송되어야함.

개략적인 설계 (초안)

![[Pasted image 20251004135852.png]]

• 문제

  • SPOF : 알림 서비스가 서버 하나. 알림 시스템이 장애면 전체 서비스 장애임.

  • 규모 확장성 : 한 대의 서비스로 푸시 알림에 관계된 모든 것을 처리. 데이터베이스나 캐시등의 중요 컴포넌트의 규모를 개별적으로 늘릴 방법이 없음.

  • 성능 병목 : 트래픽이 몰리면 알림 서비스가 병목일 수 있음.

개략적 설계안 (개선)

![[Pasted image 20251004140046.png]]

• 데이터베이스오와 캐시를 알림 시스템의 주 서버에서 분리

• 알림 서버 증설, 자동으로 수평적 규모 확장이 이뤄질 수 있도록

• 메세지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊음

• 알림 서비스는 다음 기능을 제공

  • 알림 전송 API : 사내 서비스, 인증된 클라언트가 사용가능하도록 API 제공

  • 알림 검증 : 이메일 주소, 전화번호 등에 대한 기본적 검증 수행

  • 데이터베이스 또는 캐시 질의 : 알림에 포함시킬 데이터를 가져오는 기능

  • 알림 전송 : 알림 데이터를 메세지 큐에 넣음

3. 상세 설계

안정성

• 데이터 손실방지 :

  • 알림 전송 시스템의 가장 중요한 요구사항, 어떤 상황에서도 알림이 소실되면 안된다.

  • 지연, 순서가 틀려도 괜찮지만, 사라지면 안된다.

  • 이를 위해서는 알리 시스템은 알림 데이터를 데이터베이스에 보관하고, 재시도 매커니즘을 구현해아힘

• 중복 전송 방지 :

  • 분산 시스템 특성상 가끔은 같은 알림이 중복되어 전송.

  • 그 빈도를 줄이려면 중복을 탐지하는 매커니즘을 도입해야함

추가 고려사항

• 알림 템플릿

• 알림 설정

• 전송률 제한

• 재시도방법

• 푸시 알림과 보안

• 큐 모니터링

  • 큐의 쌓인 알림 개수가 많으면... 알림 오도록

• 이벤트 추적

수정된 설계안

![[Pasted image 20251004141152.png]]

• 전송 실패 대응 -> 재시도 기능 추가

• 전송 템플릿 사용 -> 알림 생성 과정 단순화, 알림 내용 일관성 있게

• 모니터링, 추적 시스템 추가 -> 시스템 상태 추적. 시스템 개선

4. 마무리