[System Design Interview] 10. 알림 서버 시스템 설계하기

가상 면접 사례로 배우는 대규모 시스템 설계 기초 (System Design Interview) - 저 : 알렉스 쉬, 역 : 이병준 을 읽고 정리한 글입니다.

 

10장에서는 알림 시스템을 설계합니다.알림시스템이란 모바일 푸시알림 뿐 아니라, SMS 메세지, 이메일 등을 포함합니다.

 

 

[목차]

1. 알림 유형별 지원 방안
2. 개략적인 알림 시스템 설계 해보기

 

 

---

📌 01. 알림 유형별 지원방안

ios, aos, sms, 이메일을 이야기합니다.

 

1) IOS 푸시 알림

IOS 에서 푸시 알림을 보내기 위해서는 3가지 컴포넌트가 필요합니다.

1. 알림제공자 (provider)
   • 알림 요청(notification request)을 만들어 애플 푸시 알림 서비스(APNS) 로 보내는 주체입니다.
   • 알림요청을 만들려면 다음과 같은 데이터가 필요합니다.
     1. 단말 토큰 (device toke) : 알림 요청을 보내는 데 필요한 고유 식별자
     2. 페이로드 (payload) : 알림 내용을 담은 Json 딕셔너리
2. APNS (Apple Push Notification Service)
   • 에플이 제공하는 원격 서비스
   • 푸시 알림을 iOS 장치로 보내는 역할을 담당합니다.
3. iOS 단말기 : 푸시 알림을 수신하는 사용자 단말기

---

2) 안드로이드 푸시알림

안드로이드 푸시알림도 비슷한 절차로 전송되지만, APNS 대신 FCM (Filerbase Cloud Messaging) 시스템을 사용합니다.

---

3) SMS 메세지, 이메일

SMS 메세지나 이메일 서비스는 제 3 사업자의 서비스를 주로 사용하며 유료인경우가 대부분입니다.

 

 

---

📌 02. 알림 서비스 계략적 설계안

1) 초안

각각의 서비스, 1개의 서버를 사용하는 알림 시스템, 사용자에게 알림을 실제로 전달하는 제3자 제공 서비스를 이용한다고 했을 때 아래와 같은 개략적 방식을 이용하여 설계할 수 있습니다.

1. 1~N 까지 서비스 : 마이크로서비스, 크론잡, 과금서비스와 같은 다양한 서비스가 될 수 있습니다.
2. 알림 시스템(notification system) : 알림 시스템은 알림 전송/수신 처리의 핵심으로 현재는 서버 1개만 사용하는 시스템이라고 가정한 설계입니다.
   • 이 시스템은 제3자 서비스에 전달할 알림 페이로드를 만들어 낼 수 있어야합니다.
   • 이 시스템은 서비스 1~N에 알림 전송을 위한 API를 제공해야 합니다.
3. 제3자 서비스(third party services) : 이 서비스들은 사용자에게 알림을 실제로 전달하는 역할을 합니다.
   • 제 3자 서비스와의 통합을 진행할 때는 확장성을 유의해야합니다.
   • 쉽게 새로운 서비스를 통합하거나 기존 서비스를 제가할 수 있어야 합니다.
   • 어떤 서비스는 특정한 국가 서비스 시장에서 사용할 수 없을 수 있기 때문입니다.

 

그러나 이 설계에는 몇가지 문제가 있습니다.

1. SPOF(Single-Point-Of-Failure) : 알림 서비스 서버가 장애가 생기면 전체 서비스 장애로 이어집니다.
2. 규모 확장성 : 한대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로, 데이터베이스 / 캐시 등 중요한 컴포넌트의 규모를 개별적으로 늘릴 방법이 없습니다.
3. 성능 병목 : 알림을 처리하고 보내는 것은 자원을 많이 필요로 한다. 따라서 모든 것을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에는 시스템 과부하 상태에 빠질 수 있습니다.

---

 

2) 개선된 버전

초안의 문제점을 다음과 같은 방향으로 개선을 해보면 아래와 같은 설계안을 도출할 수 있습니다.

• 데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리한다.
• 알림 서버를 증설하고 자동으로 수평적 규모 확장이 이루어질 수 있도록 한다.
• 메시지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊는다.

 

1. 1~N 까지 서비스 : 알림 시스템 서버의 API를 통해 알림을 보낼 서비스들 입니다.
2. 알림 서버 : 다음과 같은 기능을 제공합니다. 
   1. 알림 전송 API : 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용가능하다.
   2. 알림 검증 : 이메일 주소, 전화번호 등에 대한 기본적 검증을 수행한다.
   3. 데이터베이스 또는 캐시 질의 : 알림에 포함시킬 데이터를 가져오는 기능이다.
   4. 알림 전송 : 알림 데이터를 메시지 큐에 넣는다. 하나 이상의 메시지 큐를 사용하므로 알림을 병렬적으로 처리할 수 있다.
3. 캐시 : 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시합니다,
4. 데이터 베이스 : 사용자, 알림, 설정 등 다양한 정보를 저장합니다.
5. 메시지 큐 :
   1. 시스템 컴포넌트 간 의존성을 제거하기 위해 사용합니다.
   2. 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할도 합니다.
6. 작업 서버 : 메시지 큐에서 전송할 알림을 꺼내서 제3자 서비스로 전달하는 역할을 담당하는 서버입니다.

 

📌 해당 컴퍼논트들이 협력하여 알림을 보내는 과정

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

---

 

3) 최종 설계안

지금까지 개략적 설계를 진행했지만 여기서 몇가지 사항을 더 고려하여 최종 설계안을 도출해보고자 합니다.

1. 안정성 : 데이터 손실 방지, 알림 중복 전송 방지
2. 추가로 필요한 컴포넌트 및 고려사항 : 알림 템플릿, 알림 설정, 전송률 제한, 재시도 메커니즘, 보안

 

(1) 안정성

데이터 손실 방지

• 알림 전송 시스템의 가장 중요한 요구사항 중 하나는 어떤 상황에서도 알림이 소실되면 안 된다는 것 입니다.
• 알림이 지연되거나 순서가 보장되지는 않아도 데이터는 유실되어서는 안됩니다.
  • 이 요구사항을 만족하기 위해서는 알림 시스템은 알림 데이터를 데이터 베이스에 보관하고 재시도 매커니즘을 구현해야 합니다.
  • 알림 로그(notification log) 데이터베이스를 유지하는 것이 한가지 방법이 될 수 있습니다.

알림 중복 전송 방지

• 같은 알림이 여러 번 반복되는 것을 완전히 막는 것은 불가능하다 합니다.
• 대부분 알림은 딱 한번 전송되지만 분산 시스템 특성상 가끔은 같은 알림이 중복되어 전송되기도 합니다.
  • 📌 방지 방법 : 보내야할 알림이 도착하면 그 이벤트 ID를 검사하여 이전에 본 적 있는 이벤트인지 살피고 중복이벤트라면 버린다. 그렇지 않으면 알림을 발송한다.

 

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

큐 모니터링

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

 

수정된 최종 설계안

↓

• 안정성(Reliability) : 메시지 전송 실패율을 낮추기 위해 안정적인 재시도 메커니즘을 도입하였습니다.
• 보안(Security) : 인증된 클라이언트만 알림을 보낼 수 있도록 합니다.
• 이벤트 추적 및 모니터링 : 알림이 만들어진 후 성공적으로 전송되기까지의 과정을 추적, 시스템 상태를 모니터링하기 위해 알림 전송의 각 단계마다 이벤트를 추적합니다.
• 사용자 설정 : 사용자가 알림 수신 설정을 조정할 수 있도록 하였다. 알림을 보내기 전 반드시 해당 설정을 확인하고 알림을 보낼 수 있도록 해야합니다.