[대규모 시스템 설계] 알림 시스템 설계

알림 시스템은 고객들에게 중요한 정보를 비동기적으로 제공하기에 애플리케이션에서 많이 사용하는 기능 중 하나이다. 모바일 푸시 알림이나 SMS, 이메일 등의 알림 시스템은 이미 우리 일상 속에 아주 익숙하고 중요한 부분으로 자리 잡았다.

애플리케이션의 규모가 클수록, 또 사용자가 많을수록 알림 시스템에 걸리는 부하가 커지기 때문에 확장성과 안정성이 중요해진다. 어떻게 확장성과 안정성을 모두 갖춘 알림 시스템을 구축할 수 있을까?

알림 유형별 지원 방안

알림 유형에는 모바일 푸시 알람, SMS, 이메일 등이 있다.
우선 각 알림 유형에서 알림 메커니즘이 어떻게 동작하는지 대략적으로 알아보자.

• iOS 푸시 알림
  • 알림 제공자 - 알림 요청을 만들어 애플 푸시 알림 서비스(APNS)로 보내는 주체
  • APNS(Apple Push Notification Service) - 푸시 알림을 iOS 장치로 보내는 애플이 제공하는 원격 서비스
  • iOS 단말 - 푸시 알림을 수신하는 단말

 

• AOS 푸시 알림
  • FCM(Firebase Cloud Messaging) - 푸시 알림을 AOS 장치로 보내는 원격 서비스

• SMS 메시지
  • SMS 메시지는 제3 사업자의 서비스를 많이 이용한다. 대부분이 상용 서비스라 이용요금이 부과된다.

 

• 이메일
  • 이메일 서비스 - 이메일 서버를 직접 구축하거나 상용 이메일 서비스를 사용한다.

 

이러한 알림 유형을 하나의 시스템으로 묶으면 다음과 같이 나타낼 수 있다.

 

연락처 정보 수집 절차

알림을 보내기 위해서는 모바일 단말 토큰이나 전화번호, 이메일 주소 등의 정보가 필요하다.
대부분의 서비스는 사용자가 회원가입할 때 사용자의 정보를 수집하여 데이터베이스에 저장한다.

 

알림 전송 및 수신 절차

개략적인 알림 전송/수신의 절차는 다음과 같다.

여기서 알림 시스템은 알림 전송/수신 처리의 핵심이다.
각 서비스에서 보낸 요청들을 알림 시스템에서 처리하고 서드파티 서비스로 전달하는 역할을 하기 때문이다.

이러한 시스템 구성에서 중요한 부분은 서드파티 서비스의 확장성이다.
보다 쉽게 기존 서비스를 통합하거나 제거할 수 있어야 한다. 그 이유는 특정 서비스를 사용하지 못하는 환경에서 강하게 결합되어있는 서드파티 서비스를 제거하기가 어렵기 때문이다.

가령 예를 들면, 중국 시장에서는 FCM을 사용할 수 없기 때문에 Jpush 같은 서비스를 사용해야 한다. 이때 서드파티 서비스의 확장성이 부족하다면 중국에서 AOS 푸시 알림 서비스를 사용할 수 없게 된다.

 

문제점

위와 같은 설계 방안은 하나의 알림 시스템에 의존하고 있으므로 단일 장애 지점(SPOF)이 된다는 문제가 있다.
또한, 한 대의 서버로 알림에 관련된 모든 것을 처리하므로 데이터베이스나 캐시 등 규모 확장에 취약하다. 따라서 시스템 과부하 상태가 발생할 확률이 높아진다.

 

해결 방안

위와 같은 문제점을 해결하기 위한 방안은 다음과 같다.

• 데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리
• 알림 서버를 증설하고 수평적 확장이 이루어지도록 변경
• 메시지 큐를 이용해 컴포넌트 간 결합 제거

이와 같은 해결 방안을 적용하면 다음과 같은 시스템을 구성할 수 있다.

• 데이터베이스와 캐시는 사용자 정보나 단말 정보, 알림 템플릿 등을 저장하고 조회한다.
• 메시지 큐는 시스템 컴포넌트 간 의존성을 제거하고 단일 장애 지점 발생을 방지한다.
• 작업 서버는 메시지 큐에 쌓인 작업들을 처리하고 서드파티 서비스로 알림을 전달한다.

 

알림 전송 시스템의 안정성 올리기

확장성있는 시스템을 설계했다면, 이제 안정성을 더 올릴 필요가 있다.
여기서 말하는 안정성이란 데이터의 손실 방지나 알림 중복 전송 방지 등 말 그대로 알림 전송 시스템에서 중요한 기능들의 안정성을 나타낸다.

 

데이터 손실 방지

알림 자체가 지연되거나 전송 순서가 틀려도 상관은 없지만, 소실되면 안 된다.
알림 시스템의 알림 소실에 대한 안정성을 올리기 위해서는 알림 데이터를 데이터베이스에 보관하고 재시도 메커니즘을 구현해야 한다. 알림 로그 데이터베이스를 유지하는 것이 아주 좋은 방법이 될 수 있다.

 

알림 중복 전송 방지

중복 탐지하는 메커니즘을 도입해야 한다.
일반적으로 알림 이벤트 ID를 검사하고 중복인지 확인한 후, 중복된 이벤트라면 버리고 아니라면 알림을 발송하는 메커니즘이다.

 

추가 고려사항

• 알림 템플릿 사용하기
  • 반복적인 처리를 제거할 수 있다.
• 알림 설정
  • 사용자가 알림에 대한 자세한 설정할 수 있도록 필드를 설계해야 한다.
• 전송률 제한
  • 너무 많은 알림을 한 명의 사용자에게 보내지 않도록 빈도수를 제한해야 한다.
• 재시도 방법
  • 서드 파티 서비스에서 알림 전송 실패 시 재시도 큐에 이벤트를 발행하고 반복되면 개발자에게 전달한다.
• 이벤트 추적
  • 알림 확인율, 클릭률 등 유의미한 매트릭 정보를 추적하여 데이터 분석 서비스와 통합하자.

 

개선된 설계안

알림 서버에 인증과 전송률 제한 기능이 추가되고, 전송 실패에 대응하는 재시도 기능도 추가되었다.
또한, 알림 템플릿과 추적 시스템, 모니터링 등의 기능을 추가해 추후 시스템 개선을 쉽게 할 수 있게 되었다.