Study/대규모 시스템 설계 기초

알림 시스템 설계

각각의 서비스 :
- 마이크로서비스, 크론잡, 과금서비스와 같은 다양한 서비스다.
알림 시스템 :
- 알림 시스템은 알림 전송/수신 처리의 핵심으로 현재는 서버 1개만 사용하는 시스템이라고 가정했다.
  - 제3자 서비스에 전달할 알림 페이로드를 만들어 낼 수 있어야 한다.
  - 이 시스템은 서비스 1~N에 알림 전송을 위한 API를 제공해야 한다.
제3자 서비스(third party services) :
- 이 서비스들은 사용자에게 알림을 실제로 전달하는 역할을 한다.
IOS, 안드로이드, 이메일 단말 :
- 사용자의 단말은 알림을 수신한다

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

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