알림 시스템 설계

알림 시스템 설계 시 고려 사항

• 어떤 종류의 알림을 지원하는지
  - 푸시 알림, SMS 메시지, 이메일
• 실시간 시스템이어야 하는지?
  - 연성 실시간 시스템이라고 가정. 가능한 한 빨리 전달되어야 하지만 높은 부하가 걸렸을 때 약간의 지연 무방
• 어떤 종류의 단말을 지원하는지?
  - iOS, 안드로이드, 랩톱/데스크톱 지원
• 사용자에게 보낼 알림은 누가 만들 수 있는지?
  - 클라이언트 어플리케이션 프로그램이 만들 수 도 있고 서버 측에서 스케쥴링할 수도 있음
• 사용자가 알림을 받지 않도록 설정할 수 있어야 하는지?
  - 설정할 수 있어야 함
• 하루에 몇 건의 알림을 보낼 수 있는지?
  - 천만 건 모바일 푸시 알림, 백만건 SMS 메시지, 5백만 건의 이메일을 보낼 수 있어야 함

개략적인 설계안

출처 : https://jonghoonpark.com/2023/06/29/notification-system-design

 

• 각각의 서비스 :
  • 마이크로서비스, 크론잡, 과금서비스와 같은 다양한 서비스다.
• 알림 시스템 :
  • 알림 시스템은 알림 전송/수신 처리의 핵심으로 현재는 서버 1개만 사용하는 시스템이라고 가정했다.
    • 제3자 서비스에 전달할 알림 페이로드를 만들어 낼 수 있어야 한다.
    • 이 시스템은 서비스 1~N에 알림 전송을 위한 API를 제공해야 한다.
• 제3자 서비스(third party services) :
  • 이 서비스들은 사용자에게 알림을 실제로 전달하는 역할을 한다.
• IOS, 안드로이드, 이메일 단말 :
  • 사용자의 단말은 알림을 수신한다

개략적인 설계안의 문제점

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

개선된 버전

출처 : https://jonghoonpark.com/2023/06/29/notification-system-design

개선 사항

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

구성 요소 설명

• 각각의 서비스 :
  • 알림 시스템 서버의 API를 통해 알림을 보낼 서비스이다.
• 알림 서버
  • 알림 전송 API : 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용가능하다.
  • 알림 검증 : 이메일 주소, 전화번호 등에 대한 기본적 검증을 수행한다.
  • 데이터베이스 또는 캐시 질의 : 알림에 포함시킬 데이터를 가져오는 기능이다.
  • 알림 전송 : 알림 데이터를 메시지 큐에 넣는다. 하나 이상의 메시지 큐를 사용하므로 알림을 병렬적으로 처리할 수 있다.
• 캐시 :
  • 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시 한다.
• 데이터 베이스 :
  • 사용자, 알림, 설정 등 다양한 정보를 저장한다.
• 메시지 큐 :
  • 시스템 컴포넌트 간 의존성을 제거하기 위해 사용한다. 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할도 한다.
• 작업 서버 :
  • 메시지 큐에서 전송할 알림을 꺼내서 제3자 서비스로 전달하는 역할을 담당하는 서버이다.

추가 고려 사항

• 안정성
  • 데이터 손실 방지
  • 알림 중복 전송 방지
• 추가로 필요한 컴포넌트 및 고려사항
  • 알림 템플릿
  • 알림 설정
  • 전송률 제한
  • 재시도 메커니즘
  • 보안
  • 큐 모니터링
  • 이벤트 추적