공통/인프라 & 시스템 설계

[대규모 시스템 설계 기초 정리] 알림 시스템 설계

반응형

알림 시스템 설계


고객에게 중요할 만한 정보를 비동기적으로 제공하는 시스템.

  • 모바일 푸쉬 알림, SMS 메시지, 이메일 등


연락처 정보 수집 절차 & 연락처 테이블 구조

  • 알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다.
  • 사용자가 우리 앱을 설치하거나 처음으로 게정을 등록하면 API 서버는 해당 사용자의 정보를 수집하여 데이터베이스에 저장한다.
    • 한 사용자가 여러 단말을 가질 수 있고, 알림은 모든 단말에 전송되어야 한다는 점을 고려.


단일 알림 시스템의 한계

SPOF

  • 알림 서비스에 서버가 하나밖에 없다는 것은, 그 서버에 장애가 생기면 전체 서비스의 장애로 이어진다는 뜻.


규모 확장성

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


성능 병목

  • 알림을 처리하고 보내는 것은 자원을 많이 필요로 하는 작업이다.
  • 모든 것을 한 서버로 처리함녀 사용자 트래픽이 많이 몰리는 시간에는 시스템이 과부하 상태에 빠질 수 있다.


개선방법

  • 알림 서버를 증설하고 자동으로 수평적 규모 확장이 이루어지도록 구성
  • 메시지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊음.


알림 서버의 역할

알림 전송 API

  • 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용 가능


알림 검증

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


데이터베이스 또는 캐시 질의

  • 알림에 포함시킬 데이터를 가져오는 기능


알림 전송

  • 알림 데이터를 메시지 큐에 넣는다. (하나 이상의 메시지 큐를 사용하며 알림을 병렬적으로 처리할 수 있다)


알림 시스템 Flow

  1. API를 호출하여 알림 서버로 알림을 보낸다
  2. 알림 서버는 사용자 정보, 단말 토큰, 알림 설정과 같은 메타 데이터를 캐시나 데이터베이스에서 가져온다.
  3. 알림 서버는 전송할 알림에 맞는 이벤트를 만들어 해당 이벤트를 위한 큐에 넣는다.
  4. 작업 서버는 메시지 큐에서 알림을 꺼내서 알림을 제3자 서비스로 보낸다.
  5. 제3자 서비스는 사용자 단말로 알림을 전송한다.


상세 설계

 


데이터 손실 방지

  • 알림 시스템은 알림 데이터를 데이터베이스에 보관하고 재시도 매커니즘을 구현해야 한다.
  • 알림 로그 데이터베이스를 유지하는 것은 한 가지 방법이다.


알림 중복 전송 방지

  • 같은 알림이 여러 번 반복되는 것을 완전히 막는 것은 가능하지 않다.
  • 그 빈도를 줄이려면 중복을 탐지하는 매커니즘을 도입하고, 오류를 신중하게 처리해야 한다.
    • 보내야 할 알림으 도착하면 그 이벤트ID를 검사하여 이전에 본 적이 있는 이벤트인지 살핀 후, 중복된 이벤트라면 버리고, 그렇지 않으면 알림을 발송한다.


알림 템플릿

  • 템플릿을 사용하면 전송될 알림들의 형식을 일관성 있게 유지할 수 있고, 오류 가능성뿐만 아니라 알림 작성에 드는 시간도 줄일 수 있다.


알림 설정

  • 사용자가 알림 설정을 상세히 조정할 수 있도록 하고 있다.
    • 이 정보는 알림 설정 테이블에 보관되며, user_id, channel알림이 전송된 채널), opt_in(알림을 받을 것인지 여부) 등의 필드가 필요할 것이다.


전송률 제한

  • 사용자에게 너무 많은 알림을 보내지 않도록 하는 한 가지 방법은 한 사용자가 받을 수 있는 알림의 빈도를 제한하는 것이다.


재시도 방법

  • 제3자 서비스가 알림 전송에 실패하면, 해당 알림을 재시도 전용 큐에 넣는다.
    • 같은 문제가 계속 발생하면 개발자에게 통지한다.


푸쉬 알림과 보안

  • iOS와 안드로이드의 경우, 알림 전송 API는 appKey와 appSecret을 사용하여 보안을 유지한다.
    • 따라서 인증된 혹은 승인된 클라이언트만 해당 API를 사용하여 알림을 보낼 수 있다.


큐 모니터링

  • 알림 시스템을 모니터링 할 때 중요한 메트릭 하나는 큐에 쌓인 알림의 개수이다.
    • 이 수가 너무 크면 작업 서버들이 이벤트를 빠르게 처리하고 있지 못하다는 뜻.
    • 이런 경우 작업 서버를 증설하는 게 바람직할 것.


이벤트 추적

  • 알림 확인율, 클릭율, 실제 앱 사용으로 이어지는 비율 같은 메트릭은 사용자를 이해하는데 중요하다.
  • 데이터 분석 서비스는 보통 이벤트 추적 기능도 제공한다.
  • 따라서 보통 알림 시스템을 만들면 데이터 분석 서비스와도 통합해야만 한다.
반응형