간단한 알림 시스템 설계

안녕하세요.

 

오늘은 간단한 알림 시스템을 설계해보겠습니다.

설계 방법은 다양하며 서비스 환경에 따라서 달라질(구체화 될)것이다.

 

요구사항

• 푸시 알림, SMS 메시지, 이메일 알림 제공
• 알림의 종류는 더 늘어날 수 있다.
  
  

고려할 사항

• 알림 유형별 지원 방법
• 연락처 정보 수집 방법
• 알림 전송 및 수신 방법

 

알림 유형별 지원 방법

• iOS 푸시 알림 → APNS (Apple Push Notification Service) 사용
• Android 푸시 알림 → FCM (Firebase Cloud Messaging) 사용
• SMS 메시지 → 트윌리오 같은 써드파티 서비스 사용
• 이메일 → SendGrid 같은 써드파티 서비스 사용

 

연락처 정보 수집 방법

회원가입시에 전화번호, 이메일 등의 정보를 받아야하고 모바일에 푸시 알림을 전송하기 위해서는 단말기의 토큰 정보도 수집해서 데이터베이스에 저장해둬야 한다.

 

1차 개략적 설계안

• 클라이언트(유저일수도 있고, 서비스, 크론잡 일수도 있고)는 api를 통해 알림 서버로 알림을 전송한다.
• 알림 서버는 알림 전송자를 인증하고
• 인증 되었다면 캐시나 데이터베이스에서 알림을 전송하기 위한 정보를 조회한다.
• 알림 전송 서비스(써드파티)를 이용하여 알림을 전송한다.
• 알림 서버는 수평적으로 확장이 가능하다.

2차 개략적 설계한

(1차와 다른점은 알림 서버와 알림 전송 서버를 분리하였다 → 컴포넌트간 의존성 낮춤, 비동기 처리, SPOF 문제 해결)

• 클라이언트(유저일수도 있고, 서비스, 크론잡 일수도 있고)는 api를 통해 알림 서버로 알림을 전송한다.
• 알림 서버는 알림 전송자를 인증한다.
• 인증 되었다면 캐시나 데이터베이스에서 알림을 전송하기 위한 정보를 조회한다.
• 메시지큐에 알림 유형별 알림을 발행한다.
• 알림 전송서버는 메시지큐를 구독하고 있고 알림을 하나씩 알림 전송 서비스(써드파티)를 이용해서 전송한다.
• 알림서버와 마찬가지로 알림 전송서버도 수평적으로 확장이 가능하다.
• 캐시에는 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시할 수 있다.
• 데이터베이스에는 사용자 정보, 알림, 설정 등 다양한 정보를 저장할 수 있다.

메시지 큐는 알림 유형별로 토픽을 나눠서 관리할 수도 있고 유형이 적다면 함께 관리할 수도 있다.

만약, 알림 유형별로 병렬적으로 처리하고 싶다면 알림 유형별로 토픽을 나눠서 큐를 관리하고 유형별로 알림을 발송하는 서비스가 해당 큐를 구독하는 형태로 구성할 수 있을 것이다.

 

알림 전송 과정

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

 

여기서, 더 고려할 수 있는 사항은 아래와 같다.

1. 데이터 손실 방지
   데이터 손실 방지를 위해서 알림 발송 이력을 데이터베이스에 저장해 관리할 수 있다.
2. 알림 템플릿
   알림들의 일관성을 유지할 수 있고 알림 작성에 드는 시간을 줄일 수 있다.
3. 알림 설정
   유저의 알림 설정 상태에 따라서 알림을 전송하거나 전송하지 않는다.
4. 재시도 방법
   알림 전송에 실패할 경우 다시 메시지큐에 넣거나 데이터베이스에 저장해두고 재시도 할 수 있다.
5. 큐 모니터링
   큐에 쌓인 알람의 개수를 파악하고 개수가 많다면 구독 서비스를 늘리고 적다면 구독 서비스를 줄일 수 있다.
6. 이벤트 추적
   알림 확인율, 클릭율을 파악할 수 있다

 

참고

도서, 가상 면접 사례로 배우는 대규모 시스템 설계 기초