알림 시스템 설계

가상 면접 사례로 배우는 대규모 시스템 설계 기초 "알림 시스템 설계"을 요약한 내용입니다.

• 알림 시스템은 단수히 모바일 푸시 알림에 한정되지 않는다.
• 알림 시스템은 모바일 푸시 알림, SMS 메세지, 이메일 세가지로 분류 할수 있다.

1단계 문제 이해 및 설계 범위 확정

• 모바일 푸시 알림, SMS 메시지, 이메일을 보내야함
• 연성 실시간(Soft Real-Time) 시스템
  • 높은 부하가 걸릴시 약간의 지연은 무방
• 클라이언트 또는 서버에서 알림을 보낼 수 있음
• 사용자가 알림을 받지 않도록 설정 할 수 있어야함
• 하루에 천만건 모바일 푸시, 백만 건의 SMS 메시지, 5백만 건의 이메일 처리 가능

2단계 계략적 설계안 제시 및 동의 구하기

알림 유형별 지원 방안

• iOS 푸시 알림
  • iOS에서 푸시 알림을 보내기 위해서는 세가지 컴포넌트가 필요
    • 알림 제공자: 알림을 만들어 APNS로 보내주는 주체
      • 단말 토큰: 알림 요청을 보내는데 필요한 고유 식별자
      • 페이로드: 알림 내용을 담은 JSON
    • APNS: 애플이 제공하는 푸시 알림 전송 서비스
    • iOS 단말: 푸시 알림 수신
• 안드로이드 푸시 알림
  • iOS와 동일하지만 APNS대신 FCM을 사용한다.
  <aside> 💡 iOS도 FCM을 사용할 수 있다.
• </aside>
• SMS 메시지
  • SMS을 보내기 위해서는 제3 사업자의 서비스를 많이 이용
  • 대부분 사용 서비스라 이용 요금이 발생
    • 트월리오, 네스모 등 서비스
    <aside> 💡 우리 회사는 NCP 서비스 사용
  • </aside>
• 이메일
  • 고유 이메일 서버를 구축 할수는 있으나 사용 이메일 서비스를 많이 사용
    • 전송 성공률이 높고, 데이터 분석 서비스도 제공
  • 센드그리드, 메일침프 등의 서비스</aside>
  • <aside> 💡 우리 회사는 NCP 서비스 사용

연락처 정보 수집 절차

• 알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요
• 앱을 설치하거나 처음으로 계정을 등록하는 과정에서 사용자 정보를 수집
• 이메일, 전화번호는 user 테이블에 저장하고 단말 토큰은 device 테이블에 저장
  • 한 사용자가 여러 단말을 가지고 있을수 있음
  • 알림은 모든 단말에 전송할 경우를 고려

알림 전송 및 수신 절차

• 개략적 설계안 (초안)
  • 1부터 n까지의 서비스: 각각은 마이크로 서비스, 크론잡, 분산 시스템 컴포넌트 등
    • ex) 납기일 알림, 과금 알림, 배송 알림 등을 보내려는 서비스
  • 알림 시스템: 알림 전송/수신 처리의 핵심
    • 알림 전송을 위함 API를 제공
    • 제3자 서비스에 전달할 알림 페이로드를 만들어 낸다
  • 제3자 서비스: 사용자에게 알림을 실제로 전달하는 역활
    • 쉽게 새로운 서비스를 통합하거나 기존 서비스를 제거할 수 있도록 고려 해야함
    • 특정 지역에서 사용할수 없을 경우를 고려 해야함
      • 중국에서는 FCM을 사용할수 없기 때문에 JPush, PushY 같은 서비스를 사용 해야 함
• 단점
  • SPOF(Single Point Of Failure): 알림 서비스에 서버가 하나밖에 없기 때문에 장애가 생기면 전체 서비스의 장애로 이어진다.
  • 규모 확장성: 한 대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로 데이터베이스나 캐시 등 중요 컴포넌트의 규모를 개별적으로 늘릴 방법이 없음
  • 성능 병목: 알림을 처리하고 보내느 것은 자원을 많이 필요로 하는 작업일 수 있음
    • 모든 것을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에는 시스템이 과부하 상태에 빠질 수 있음
• 개략적 설계안 (개선된 버전)
  • 알림 서버 기능
    • 알림 전송 API: 스팸 방지를 위해 사내 서비스 또는 인증된 클라이언트만 이용 가능
    • 알림 검증 : 이메일 주소, 전화번호 등에 대한 기본적 검증
    • 데이터베이스 또는 캐시 질의: 알림에 포함시킬 데이터를 가져오는 기능
    • 알림 전송: 알림 데이터를 메시지큐에 넣는다.
  • API 예제
    • POST https://api.example.com/v/sms/send
    • { "to": [ { "user_id": 123456 } ], "from": { "email": "from_address@example.com" }, "subject": "Hello, World", "content": [ { "type": "text/plain", "value": "Hello, World" } ] }
  • 알림 전송되는 방법
    1. API를 호출하여 알림 서버로 알림을 보냄
    2. 알림 서버는 사용자 정보, 단말 토큰, 알림 설정 같은 메타데이터를 캐시나 데이터베이스에서 가져온다
    3. 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 해당 이벤트를 위한 큐에 넣는다.
    4. 작업 서버는 메시지 큐에서 알림 이벤트를 꺼낸다
    5. 작업 서버는 알림을 제3자 서비스로 보낸다
    6. 제3자 서비스는 사용자 단말로 알림을 전송

3단계 상세 설계

안정성

• 데이터 손실 방지
  • 알림 전송 시스템의 가장 중요한 요구사항 가운데 하나는 어떤 상황에서도 알림이 소실되면 안됨
  • 알림 시스템은 알림 데이터를 데이터베이스 보관하고 재시도 매커니즘을 구형해야함
• 알림 중복 전송 방지
  • 같은 알림이 여러 번 반복되는 것을 완전히 막는 것은 가능하지 않음
    • 분산 시스템의 특성상 가끔은 같은 알림이 중복되어 전송되기도 함
    • 빈도를 줄이기 위해서는 중복을 탐지하는 매커니즘을 도입하고, 오류를 신중하게 처리 해야함

추가로 고려할 컴포넌트 및 고려사항

• 알림 템플릿
  • 알림 메시지 대부분은 형식이 비슷
  • 알림 템플릿은 유사성을 고려하여 알림 메시지 본문을 처음부터 다시 만들 필요 없도록 해줌
  • 알림 템플릿은 인자(Parameter)나 스타일, 추적 링크(tarcking link)를 조정하여 지정한 형식에 맞춰 알림을 만들어 내는 틀
• 알림 설정
  • 사용자가 알림 설정을 상세히 조정할 수 있도록 알림 설정 테이블에 값을 추가
  • 알림을 보내기전 해당 필드를 확인하고 전송
• 전송률 제한
  • 사용자에게 너무 많은 알림을 보내지 않도록 하는 한가지 방법으로 한 사용자가 받을 수 있는 알림의 빈도를 제한하는 것
• 재시도 방법
  • 제3자 서비스가 알림 전송에 실패하면 해당 알림을 재시도 전용 큐에 추가
  • 같은 문제가 계속해서 발생하면 개발자에게 통지
• 푸시 알림과 보안
  • 인증된, 혹은 승인된 클라이언트만 해당 API를 사용하여 알림을 보낼 수 있다.
• 큐 모니터링
  • 큐에 쌓인 아림의 개수가 너무 크면 작업 서버들이 이벤트를 빠르게 처리하지 못하고 있다는 뜻이다.
  • 작업 서버를 증설하는 등의 대응을 하기 위한 모니터링이 필요
• 이벤트 추적
  • 알림 확인률, 클릭률, 실제 앱 사용으로 이어지는 비율 같은 메트릭은 사용자를 이해하는데 중요 함

수정된 설계안

• 알림 서버에 인증과 전송률 제한 기능을 추가
• 전송 실패에 대응하기 위한 재시도 기능 추가
• 전송 템플릿을 사용하여 알림 생성 과정을 단순화하고 일관성을 유지
• 모니터링과 추적 시스템을 추가하여 시스템 상태를 확인 및 개선점을 찾음

4단계 마무리

• 안정성: 메시지 전송 실패율을 낮추기 위해 안정적인 재시도 메커니증 도입
• 보안: 인증된 클라이언트만 알림을 보낼 수 있도록 appKey, appSecret등 메커니즘 이용
• 이벤트 추적 및 모니터링: 알림이 만들어진 후 성공적으로 전송되기까지의 과정을 추적하고 시스템 상태를 모니터링하기 위한 알림 전송의 각 단계마다 이벤트를 추적하고 모니터링할 수 있는 시스템을 통합
• 사용자 설정: 사용자가 알림 수신 설정을 조정할 수 있도록 함
• 전송률 제한: 사용자에게 알림을 보내는 빈도를 제한할 수 있도록 함