[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 10장: 알림 시스템 설계

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

알림 시스템에 관한 문제가 면접에 출제될 때는 보통 정해진 답이 없고 문제 자체가 모호하게 주어지는 것이 일반적이므로 적절한 질문을 통해 요구사항이 무엇인지 스스로 알아내야한다

 

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

iOS 푸시 알림, 안드로이드 푸시 알림, SMS 메세지 그리고 이메일을 지원하는 알림 시스템의 개략적인 설계안을 살펴보자.

 

1) 알림 유형별 지원 방안

각각의 알림 메커니즘이 동작하기 위해 필요한 컴포넌트를 알아보자

• iOS 푸시 알림 : 알림 제공자 ➡️ APNS ➡️ iOS 단말
  • 알림 제공자 : 알림 요청을 만들어 애플 푸시 알림 서비스를 보내는 주체. 다음 데이터가 필요
    • 단말 토큰
    • 페이로드
  • APNS : 애플이 제공하는 원격 서비스로 푸시 알림을 iOS 장치로 보내는 역할
  • iOS 단말 : 푸시 알림을 수신하는 사용자 단말
• 안드로이드 푸시 알림: 알림 제공자 ➡️ FCM (APNS 대신이다) ➡️ 안드로이드 단말
• SMS 메세지 : 알림 제공자 ➡️ SMS 서비스 ➡️ SMS 수신 단말
  • 보통 트윌리오, 넥스모 같은 제 3사업자의 서비스를 이용하고 요금을 지불함
• 이메일 : 알림 제공자 ➡️ 이메일 서비스 ➡️ 이메일 수신 단말

2) 연락처 정보 수집 절차

사용자가 앱을 설치하거나 처음으로 계정을 등록하면 해당 사용자의 정보를 수집하여 DB에 저장한다.

이때 user 테이블에 이메일 주소와 전화번호를 저장하고, 단말 토큰은 device 테이블에 저장한다. 한 사용자가 여러 단말을 가질 수 있고, 알림은 모든 단말에 전송되어야하기 때문이다.

 

3) 알림 전송 및 수신 절차

• 1차 설계
  • 1부터 N까지의 서비스 : 알림 시스템 서버의 API를 통해 알림을 보내려는 서비스
  • 알림 시스템 : 알림 전송/수신 처리의 핵심. 1~N에 알림 전송을 위한 API를 제공하고 제 3자 서비스에 전달할 알림 페이로드 생성
  • 제 3자 서비스 : 사용자에게 알림을 실제로 전달하는 역할. 확장성(쉽게 새로운 서비스를 통합하거나 기존 서비스를 제거할 수 있어야함)과 다른 시장에서 사용할 수 없을 수도 있음을 고려해야함
• 문제점
  • SPOF : 알림 서비스 서버가 하나 밖에 없으므로 장애가 생기면 전체 서비스 장애로 이어진다
  • 규모 확장성: 한 대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로 DB나 캐시 등 중요 컴포넌트 규모를 갭별적으로 늘릴 방법이 없다
  • 성능 병목 : 모든 것을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에 시스템이 과부하 상태에 빠질 수 있다
• 1차 설계 개선안
  • DB와 캐시를 알림 시스템의 주 서버에서 분리
  • 알림 서버를 증설하고 수평적 규모 확장이 이루어질 수 있도록 함
  • 메시지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊음
• 개선된 설계
  • 1부터 N까지의 서비스 
  • 알림 서버 : 다음 기능 제공
    • 알림 전송 API : 인증된 클라이언트만 이용 가능
    • 알림 검증 : 이메일, 전화번호 등에 대한 기본적 검증
    • DB 또는 캐시 질의 : 알림에 포함시킬 데이터 쿼리
    • 알림 전송 : 알림 데이터를 메세지 큐에 넣음. 하나 이상의 메세지 큐를 사용하는 경우 병렬적 처리 가능
  • 캐시 : 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시
  • DB : 사용자, 알림, 설정 등 다양한 정보 저장
  • 메세지 큐 : 시스템 컴포넌트 간 의존성을 제거하기 위해 사용. 다량의 알림이 전송되어야하는 경우를 대비한 버퍼 역할 가능
  • 작업 서버 : 메시지 큐에서 전송할 알림을 꺼내 제 3자 서비스로 전달하는 역할 담당 서버

 

3단계 상세 설계

안정성

• 데이터 손실 방지 : 알림 시스템은 알림 데이터를 데이터베이스에 보관하고 재시도 메커니즘을 구현해야함. 알림 로그 DB를 유지하는 것이 한가지 방법
• 알림 중복 전송 방지 : 분산 시스템의 특성상 가끔은 알림이 중복되어 전송되기도 하므로 중복을 탐지하는 메커니즘 도입 필요. 100% 보장은 불가

추가로 필요한 컴포넌트 및 고려사항

• 알림 템플릿 : 전송될 알림들의 형식을 일관성 있게 유지 및 오류 가능성과 알림 작성 비용 절감
• 알림 설정 : 사용자가 알림 설정을 상세히 조정할 수 있도록 채널별로 알림 관리
• 전송률 제한 : 너무 많은 알림을 보내지 않도록
• 재시도 방법 : 제 3자 서비스가 알림 전송에 실패하면 해당 알림을 재시도 전용 큐에 넣는다
• 푸시 알림과 보안
• 큐 모니터링
• 이벤트 추적

 

4단계 마무리

• 컴포넌트 사이에 결합도를 낮추기 위해 메시지 큐 적극적 활용
• 안정성 : 메시지 전송 실패율을 낮추기 위한 재시도 메커니즘
• 보안 : 인증된 클라이언트만이 알림 전송 가능
• 이벤트 추적 및 모니터링 : 시스템 상태를 모니터링하기 위해 알림 전송의 각 단계마다 이벤트를 추적하고 모니터링할 수 있는 시스템을 통합
• 사용자 설정 : 알림 수신 설정을 사용자가 조정 가능
• 전송률 제한