[keyword] 10장 - 알림 시스템 설계

알림 시스템

모바일 푸시 알림
SMS 메시지(=문자)
이메일

알림을 보내려면 ‘모바일 단말 토큰, 전화번호, 이메일 주소 등’이 필요

DB에 저장

기본 설계 구조

서비스 1 ~ 서비스 N
- 마이크로서비스
- 크론잡
- 분산 시스템 컴포넌트
- ex) 과금 서비스(납기일 알림), 쇼핑몰 웹사이트(배송 알림)
알림 서버
- 서비스들에게 알림을 전송할 수 있는 API 제공
- 정해진 형식에 따라 알림 메시지 생성
- 캐시 / 데이터베이스에 질의하여 알림에 포함 시킬 데이터를 가져옴
- 메시지 큐로 알림 전달
캐시 / 데이터베이스
- 알림에 포함시킬 메타 데이터 등을 저장
- 캐시 : 사용자 정보, 단말 정보 등을 캐시
- 데이터베이스 : 사용자, 알림 등에 대한 다양한 정보 저장
메시지 큐
- iOS 푸시 알림 큐, 안드로이드 푸시 알림 큐, SMS 큐, 이메일 큐
- 시스템 컴포넌트 간 의존성 제거
- 알림 메시지에 대한 버퍼 역할
작업 서버
- 메시지 큐에서 알림을 꺼내서 제3자 제공 서비스로 전달
- 오류 발생 시 재시도
제3자 제공 서비스
- 실제 단말로 알림 전송
- APNS : iOS 장치로 푸시 알림을 보내는 애플의 원격 서비스
- FCM : 안드로이드의 푸시 알림 서비스
- SMS 서비스 : 문자 메시지 전송 서비스 (Twilio, Nexmo 등)
- 이메일 서비스 : 데이터 분석(Analytics) 서비스도 함께 제공 (Sendgrid, Mailchimp 등)

설계 구조 보완

개선된 컴포넌트

알림 서버
- 사내 서비스 또는 인증된 클라이언트만 이용 가능하도록 필터링
- 한 사용자에게 너무 많은 알림을 보내지 않도록 전송률 제한
데이터베이스
- 설정 : 사용자별 알림 ON/OFF 관리
작업 서버
- ‘알림 템플릿’에 parameter만 입력하면, 알림 메시지 구조 자동 완성
- 데이터 손실 방지를 위해, ‘알림 로그’를 관리하는 데이터베이스 추가
  추가된 컴포넌트
큐 모니터링
- 큐에 메시지 양이 늘어나는 추세가 지속되면, 작업 서버를 증설
데이터 분석 서비스
- 다음과 같은 이벤트들을 추적하여 유저에 대해 이해
- 알림 확인율
- 클릭율
- 실제 앱 사용으로 이어지는 비율
- 알림 수신 거부 설정
  
  @caffeine-library/readers-system-design-interview

책이 고안한 설계를 보면서, 컴포넌트들이 무슨 퀄리티 속성을 만족하려고 등장한 것일까 생각하게 되었습니다. 뭔가 수필 쓰듯이 쓰게 되었네요.

대학 과제로 안드로이드 앱에서 푸시 알림을 수신하기 위해 그 내용을 팠던적이 있다. 당시 생각해낸 알림 보내기란, 앱이 직접 FCM에 쿼리를 날려 기기가 다시 알림을 수신하는 수준이었다. 알림 전송 기능의 참여자는 앱, 기기, FCM 3개 뿐이다.

하지만 이 책(System Design Interview)에서 설계하는 것은 서비스 수준 즉, 알림 서비스이다. 만족해야 할 퀄리티가 있으며, 이를 위해 10개의 컴포넌트가 식별되었다.

서비스의 뼈대 시나리오는 이렇다.

클라이언트 서비스는 다수 존재한다. 클라이언트는 알림을 수신했으면 하는 유저의 ID와 알림 컨텐츠, 타겟 플랫폼을 HTTP 페이로드에 욱여넣고 알림 서버에 요청한다.

알림 서버는 타겟 정보 데이터베이스, 알림 설정 데이터베이스를 참고하여 타겟 플랫폼 별로 마련된 알림 요청 큐에 작업을 넣는다. 작업 서버가 큐에서 이것을 꺼내고 지정된 플랫폼의 제3자 알림 서비스(FCM 따위)에게 알림을 전파한다. 유저의 기기는 곧이어 알림을 수신하게 된다.

다음과 같은 퀄리티가 고려된다.

Low Coupling
- 생성과 이용의 분리 원칙 초짜 앱은 알림 페이로드를 만들고 FCM에게 부탁하는 일을 하나의 앱에서 처리하였다. 하지만 알림 시스템에서는 알림의 명세를 정의하는 자와, 알림의 실체를 만드는 자, 알림을 기기로 보내는 자가 구분된다. 각각 알림 서버, 작업 서버, 제3자 서비스가 된다.
알림 서버와 작업 서버 간 결합을 낮추기 위해 큐 시스템을 사이에 도입한다. 중국 대상으로 서비스 지역이 확장될 때, 작업 서버는 제3자 서비스 마이그레이션에 영향을 받는다 (Jpush, PushY) 하지만 알림 서버는 이런 변경을 고려하지 않는다.
Reliability (안정성)

큐는 위 역할 뿐만 아니라, 알림 전송이 실패하는 케이스가 발생시, 그 알림을 재전송하도록 하는 윤활제가 된다. 작업 서버가 실패된 알림을 겪으면 큐에다 다시 재인큐 해주면 되기 때문이다. = 폴백 루틴의 설계가 단순해졌다.
Traceability (추적성)

큐가 담고있는 작업의 사이즈는 계속 추적하여 작업 부하량을 판단하는 데 쓸 수 있다. 이 값을 토대로 작업 서버나 알림 서버의 증설을 고려할 수 있다.

알림 로그 데이터베이스는 제3자 알림 서비스에 위탁한 알림이 제대로 처리되었는지 기록한다. 이 값을 토대로 작업 서버는 실패된 알림을 발견하고 다시 재전송을 시도할 수 있다.

시스템의 각 컴포넌트는 추적하고 싶은 상태 메트릭을 데이터 분석 서비스에 전송한다. 추적 지표들은 서비스 개선에 활용될 것이다. 책에서는 알림의 상태를 추적한다.
Security (보안)

알림 서비스는 스팸 따위로 악용될 수 있으므로, 알림 서버는 인증 모듈을 두어 허용된 클라이언트만이 이용하게 한다.
Performance (성능)

알림 템플릿을 만들어 두고 파라미터 값을 조정하는 방식을 쓰면, 작업 서버는 신속하게 알림 메시지를 작성할 수 있다.

영속성 레이어에 캐시들을 배치해 놓았고, DB도 다중화했다. 읽기 지연이 상당히 감소한다.
유저 만족도

유저에게 과한 양의 알림이 수신되거나 동일한 알림이 중복 수신되는 경우 사용성을 크게 떨어뜨린다. 알림 서버는 처리율 제한 장치를 두어 특정 기간 동안 한 유저가 수신할 수 있는 알림 개수를 설정할 수 있으며, 참고 문헌 5의 방법으로 중복 전송 확률을 낮춘다.

유저는 그냥 클라이언트로 가서 알림 수신 설정을 끄는 방식을 쓸 수도 있다. 알림 설정 데이터베이스에 이 정보가 저장된다.
Availability (가용성)

타겟 정보 데이터베이스, 알림 설정 데이터베이스, 캐시, 알림 로그 데이터베이스, 알림 템플릿 캐시, 알림 서버, 작업 서버를 다중화한다.

관점을 역전시켜서 컴포넌트의 존재 의의를 분석할 수 있다.

큐 시스템의 의의

요청 생성자와 요청 처리자를 명시적으로 분리해내는 도구이다. 시스템은 자연스레 응집되고 커플링이 낮아진다.
비동기적인 순차 요청 처리에서 윤활유 역할을 한다. 작업 처리자의 시나리오를 단순하게 만들어주므로 에러 처리 루틴의 설계도 쉬워졌다.
큐 사이즈가 의미있는 메트릭을 제공한다. 추적성이 보장되는 시스템은 변화에 적응하기 쉽다.

처리율 제한기의 의의

처리율 제한기의 흥미로운 점은 시스템에 따라 UX를 강화하거나 훼손하는 데 일조한다는 점이다.
- API 게이트웨이에서 처리율 제한은 서버의 부하를 막는 용도로 사용했다. 이 정책은 유저가 요구하는 서비스를 제때 받지 못 하도록 제한하므로 UX를 저해한다.
- 알림 서비스는 과도한 알림을 수신하지 않도록 제한하여 UX를 향상시킨다.
- 유저가 원하는 것을 통제하느냐, 유저가 원하지 않는 것을 통제하느냐.

caffeine-library / system-design-interview