[가상 면접 사례로 배우는 대규모 시스템 설계 기초]10. 알림 시스템 설계

https://product.kyobobook.co.kr/detail/S000001033116

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고

1장 사용자 수에 따른 규모 확장성 : https://inhyeok-blog.tistory.com/40
2장 개략적인규모추정 : https://inhyeok-blog.tistory.com/41
3장 시스템 설계 면접 공략법 : https://inhyeok-blog.tistory.com/42
4장 처리율제한장치의설계 : https://inhyeok-blog.tistory.com/43
5장 안정해시설계 : https://inhyeok-blog.tistory.com/44
6장 키-값저장소설계 : https://inhyeok-blog.tistory.com/45
7장 분산시스템을위한유일 ID 생성기설계 : https://inhyeok-blog.tistory.com/46
8장 URL 단축기설계 : https://inhyeok-blog.tistory.com/47
9장 웹크롤러설계 : https://inhyeok-blog.tistory.com/48
10장알림시스템설계 : https://inhyeok-blog.tistory.com/49
11장뉴스피드시스템설계 : https://inhyeok-blog.tistory.com/50
12장채팅시스템설계 : https://inhyeok-blog.tistory.com/51
13장검색어자동완성시스템 : https://inhyeok-blog.tistory.com/52
14장유튜브설계 : https://inhyeok-blog.tistory.com/53
15장구글드라이브설계 : https://inhyeok-blog.tistory.com/54

 

이 챕터를 읽으면서 호환성과 확장성이 좋은 프로그램을 오픈소스로 만들어보고 싶다는 생각이 들었다. 알람시스템은 언제나 필요하기 때문에 완성도 있는 프로그램을 만들어둔다면 두고두고 잘 쓰지 않을까?

 

 요구사항

- 푸시알림, SMS메시지, 이메일을 지원해야한다.

- 연성 실시간(soft real-time)이어야 한다.

- 푸시알림은 iOS, 안드로이드, 랩톱/데스크톱을 지원해야 한다.

- 알림은 클라이언트 애플리케이션 프로그램이 만들수도, 서버에서 스케줄링 할 수도 있다.

- 사용자가 알람 수신을 거부할 수 있다.

- 하루에 천만 건의 모바일 푸시 알림, 백만 건의 SMS 메시지, 5백만 건의 이메일을 보낼 수 있어야 한다.

 

아래에서는 다음과 같은 내용을 다룬다.

- 알림 유형별 지원 방안

- 연락처 정보 수집 절차

- 알림 전송 및 수신 절차

 

알림 유형별 지원 방안

iOS는 APNS라는 애플이 제공하는 푸시 알림을 iOS장치로 보내는 열할을 담당하는 원격 서비스가 필요하다. 

안드로이드는 APNS 대신 FCM(Firebase Cloud Messaging)을 사용한다.

SMS는 다양한 제3 사업자의 서비스를 사용한다.

이메일 역시 다양한 제3 서비스를 사용한다. 물론 직접 메일 서버를 구축해도 좋지만, 전송 성공률도 높고 데이터 분석도 제공하는 제 3자 서비스가 선호된다.

 

연락처 수집 절차

사용자가 직접 입력해줘야 한다.

 

알림 전송 및 수신 절차

알림 시스템에게 요청을 보내면 알림시스템이 각각의 알림 유형별로 알림보내기 위한 초안이다. 하지만 알림 시스템이 하나의 서버로 이루어져 있어서 몇가지 문제를 발생시킨다. 알림 시스템은 SPOF가 될 것이며, 규모의 확장성(DB나 캐시 등 컴포넌트의 규모를 개별적으로 늘릴 수 없다)이 부족하다. 또한 성능 병목이 될 것이다.

 

 

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

DB와 캐시를 분리하고, 메시지 큐를 통해 컴포넌트들 사이의 강한 결합을 끊었다.

 

상세 설계

앞서 살펴본 개략적인 설계에서 다음과 같은 세부 설계를 살펴보쟈ㅏ

- 안정성

- 추가 컴포넌트 및 고려사항

- 개선된 설계안

 

안정성

- 데이터 손실 방지

각 작업서버에서 알림 로그 데이터 베이스를 둬서 어떤 상황에서도 알림이 소실되지 않게 만들 수 있다.

 

- 알림 중복 전송 방지

중복을 완벽하게 막는 것은 불가능하다. 분산 시스템의 특성상 가끔 같은 알림이 중복 전송되기도 할 것이다. 하지만 그 빈도를 줄이기 위해 중복 탐지 알고리즘을 적용할 수 있을 것이다. 그 대표적인 방법으로 이벤트 ID를 검사해서 이전에 본 적이 있는 이벤트인지 살필 수 있다.

 

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

- 알림 템플릿

대형 알림 시스템은 하루에도 수백만 건 이상의 알림을 처리한다. 하지만 대부분 형식이 같으므로 템플릿을 만들어두면 편하게 알림을 보낼 수 있고, 알림들의 형식을 일관성 있게 유지하며, 오류를 줄이고 시간을 아낄 수 있다.

 

- 알림 설정

사용자가 알림을 받고자 하는 채널과 알림 전공 여부를 설정해 줄 수 있다. 이 정보는 알림 설정 테이블에 보관한다.

 

- 전송률 제한

사용자가 너무 많은 알림을 받지않도록 하는 한가지 방법은 사용자가 받을 수 있는 알림의 빈도를 제한하는 것이다. 사용자는 너무 알림이 많으면 알림을 꺼버리기 마련이다.

 

- 재시도 방법

실패한 알림을 재시도 전용 큐에 넣고 재시도 하며, 같은 문제가 반복적으로 발생하면 개발자에게 통지한다.

 

- 푸시 알림과 보안

iOS와 안드로이드는 appKey와 appSecret을 사용하며 보안을 유지한다. 따라서 인증된(또는 승인된) 클라이언트만해당 API를 사용해서 알림을 보낼 수 있다.

 

- 큐 모니터링

큐에 쌓인 알림의 갯수를 모니터링 해서 서버 증설을 계획할 수 있다.

 

-이벤트 추적

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

 

수정된 설계안