[System Design Interview] 10장. 알림 시스템 설계

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

시스템 요구 사양

• 지원해야 하는 알림 종류 : 푸시 알림, SMS 메시지, 이메일
• 연성 실시간 시스템
• 알림은 가능한 빨리 전달 되어야 한다. 다만 시스템에 높은 부하가 걸렸을 때 약간의 지연은 무방하다.
• IOS, 안드로이드, 랩톱, 데스크톱을 지원해야 한다.
• 사용자에게 보낼 알람은 클라이언트 또는 서버 측에서 스케쥴링 할 수 있다.
• 사용자가 알림을 받지 않도록 설정 가능해야 한다.
• 하루에 천만 건의 모바일 푸시 알림, 백만 건의 SMS 메시지, 5백만 건의 이메일을 보낼 수 있어야 한다.

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

알림 유형별 지원 방안

IOS 푸시 알림

• 알림 제공자 : 알림 요청을 만들어 애플 푸시 알림 서비스(APNS)로 보내는 주체다. 알림 요청을 만들려면 다음과 같은 데이터가 필요하다.
  • 단말 토큰 : 알림 요청을 보내는 데 필요한 고유 식별자다.
  • 페이로드 : 알림 내용을 담은 JSON 딕셔너리다.
• APNS : 애플이 제공하는 원격 서비스다. 푸시 알림을 IOS 장치로 보내는 역할을 담당한다.
• IOS 단말 : 푸시 알림을 수신하는 사용자 단말이다.

안드로이드 푸시 알림

안드로이드 푸시 알림도 비슷한 절차로 전송된다. APNS 대신 FCM을 사용한다는 점만 다르다.

SMS 메시지

SMS 메시지를 보낼 때는 보통 트윌리오, 넥스모 같은 제3 사업자의 서비스를 많이 이용한다.

이메일

많이 사용하는 이메일 서비스로듣 샌드그리드, 메일침프가 있다.

연락처 정보 수집 절차

• 알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다.
• figure 10-7과 같이 사용자가 우리 앱을 설치하거나 처음으로 계정을 등록하면 API 서버는 해당 사용자의 정보를 수집하여 데이터베이스에 저장한다.

알림 전송 및  수신 절차

개략적 설계안(초안)

figure 10-9는 개략적 설계 초안이다.

• 1부터 N까지의 서비스 : 이 서비스 각각은 마이크로서비스일수도 있고, 크론잡일 수도 있고, 분산 시스템 컴포넌트일 수도 있다.
• 알림 시스템 : 알림 전송/수신 처리의 핵심이다.
• 제3자 서비스 : 사용자에게 알림을 실제로 전달하는 역할을 한다. 제3자 서비스와의 통합을 진행할 때 유의할 것은 확장성이다. 쉽게 새로운 서비스를 통합하거나 기존 서비스를 제거할 수 있어야 한다는 뜻이다.
• IOS, 안드로이드, SMS, 이메일 단말 : 사용자는 자기 단말에서 알림을 수신한다.

이 설계에는 몇 가지 문제가 있다.

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

개략적 설계안(개선된 버전)

개선 방향은 아래와 같다.

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

figure 10-10은 개선된 시스템을 보여준다.

• 1부터 N까지의 서비스 : 알림 시스템 서버의 API를 통해 알림을 모낼 서비스들.
• 알림 서버 : 다음 기능을 제공한다.
  • 알림 전송 API : 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용 가능하다.
  • 알림 검증 : 이메일 주소, 전화번호 등에 대한 기본적 검증을 수행한다.
  • 데이터베이스 또는 캐시 질의 : 알림에 포함시킬 데이터를 가져오는 기능이다.
  • 알림 전송 : 알림 데이터를 메시지 큐에 넣는다.

다음은 이메일 형태의 알림을 보내는 데 사용하는 API 예제다.

• 캐시 : 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시한다.
• 데이터베이스 : 사용자, 알림, 설정 등 자양한 정보를 저장한다.
• 메시지 큐 : 시스템 컴포넌트 간 의존성을 제거하기 ㅜ이해 사용한다.
• 작업 서버 : 메시지 큐에서 전송할 알림을 꺼내서 제3자 서비스로 전달하는 역할을 담당한다.
• 제3자 서비스
• IOS, 안드로이드, SMS, 이메일 단말

컴포넌트들이 협렵하여 알림을 전송하게 하는 과정

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

3단계 상세 설계

안정성

데이터 손실 방지

• 알림 전송 시스템의 가장 중요한 요구사항 가운데 하나는 어떤 상황에서도 알림이 소시뢷면 안 된다는 것이다.
• 이 요구사항을 만족하려면 알림 시스템은 알림 데이터를 데이터베이스에 보관하고 재시도 메커니즘을 구현해야 한다.
• figure 10-11과 같이 알림 로그 데이터베이스를 유지하는 것이 한가지 방법이다.

알림 중복 전송 방지

• 같은 알림이 여러 번 반복되는 것을 완전히 막는 것은 가능하지 않다.대부분의 경우 알림은 딱 한 번만 전송되겠지만, 분산 시스템의 특성상 가끔은 같은 알림이 중복되어 전송되기도 할 것이다. 그 빈도를 줄이려면 중복을 탐지하는 메커니즘을 도입하고, 오류를 신중하게 처리해야 한다. 다음은 간단한 중복 방지 로직의 예이다.
• 보내야 할 알림이 도착하면 그 이벤트 ID를 검사하여 이전에 본 적이 있는 이벤트인지 살핀다. 중복된 이벤트라면 버리고, 그렇지 않으면 알림을 발송한다.

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

알림 템플릿

• 알림 템플릿은 유사성을 고려하여 알림 메시지의 모든 부분을 처음부터 닷 ㅣ만들 필요 없도록 해 준다.

알림 설정

• 사용자는 너무 많은 알림을 받으면 피곤함을 느낀다. 따라서 사용자가 알림 설정을 상세히 조정할 수 있도록 한다.
• 이 정보는 알림 설정 테이블에 보관되며, 이 테이블에는 다음과 같은 필드들이 필요할 것이다.

전송률 제한

• 사용자에게 너무 많은 알림을 보내지 않도록 하는 한 가지 방법은, 한 사용자가 받을 수 있는 알림의 빈도를 제한하는 것이다.

재시도 방법

• 제3자 서비스가 알림 전송에 실패하면, 해당 알림을 재시도 전용 큐에 넣는다.
• 같은 문제가 계속해서 발생하면 개발자에게 통지한다.

푸시 알림과 보안

• IOS와 안드로이드 앱의 경우, 알림 전송 API는 appKey와 appSecret을 사용하여 보안을 유지한다.

큐 모니터링

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

이벤트 추적

• 알림 확일율, 클릭율, 실제 앱 사용으로 이어지는 비율 같은 메트릭은 사용자를 이해하는데 중요하다.
• 데이터 분석 서비스는 보통 이벤트 추적 기능도 제공한다. 따라서 보통 알림 시스템을 만들면 데이터 분석 서비스와도 통합해야만 한다.

수정된 설계안

figure 10-14는 최종 수정된 설계안이다.

• 알림 서버에 인증과 전송률 제한 기능이 추가 되었다.
• 전송 실패에 대응하기 위한 재시도 기능이 추가되었다. 전송에 실패한 알림은 다시 큐에 넣고 저장된 횟수만큼 재시도한다.
• 전송 템플릿을 사용하여 알림 생성 과정을 단순화하고 알림 내용이 일관성을 유지한다.
• 모니터링과 추적 시스템을 추가하여 시스템 상태를 확인하고 추후 시스템을 개선하기 쉽도록 하였다.