알람 시스템 설계

• 최신 뉴스, 업데이트 정보, 이벤트, 선물 등 고객에게 중요할 만한 정보를 비동기적으로 제공한다.
• 단순히 모바일 푸시 알림에 한정되지 않는다.

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

• 하루에 백만건 이상의 알림이 처리하는 확장성 높은 시스템을 구축한다.
• 푸시알림, SMS 메시지 등으로 구성되어 있다.
• 실시간 타임이라고 가정한다. 알림은 가능한 빨리 전달한다.
• ios + 안드로이드 + pc 등을 지원한다.
• 사용자가 알림을 받지 않도록 설정할 수 있어야 한다.
• 천만건의 푸시 알림, 백만 건의 sms 메시지, 5백만 건의 이메일을 보낼 수 있어야 한다.

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

유형별 알림 지원 방안

• ios
  필요로 되는 구성은 구성은 아래와 같다.

  1. provider : 알림요청을 만들어서 애플 푸시 알림 서비스(APNS)로 보낸다. 구성은 단말 토큰 + 페이로드 로 구성되어 있다.
  2. APNS : 애플이 제공하는 원격 서비스이다.
  3. Device

• Android

  FCM(Firebase Cloud Messaging)을 활용한다.

• SMS

  트윌리오 넥스모 같은 제 3 사업자의 서비스를 이용한다.

• email

  상용 이메일 서비스를 이용한다. 대표적으로 메일 침프 ㅔㄴ드그리드 등이 있다.

위 서비스들을 묶어서 제 3 사업자 제공 서비스로 칭한다.

연락처 정보 수집 절차

• 알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다. 데이터베이스의 사용자 정보를 저장하는 간단한 아키텍처를 구성한다 (로드밸런서 + API 서버 + 데이터베이스)

알림 전송 및 수신 절차

• 서비스 구성 내용

특정 서비스들 --- 알림 서버 ----- 제 3자 제공 서비스 ----- 엣지 디바이스(알림)

• 서비스 : 알림 시스템 서버를 통해 알림을 보낼 서비스들을 의미한다.

• 알림서버 : 아래와 같은 기능을 제공해야한다.

  1. 인증과 인가
  2. 알림 검증
  3. 데이터 베이스 또는 캐시 : 알림에 포함시킬 데이터를 가져오는 기능
  4. 알림 전송

• 캐시 : 사용자의 정보, 단말 정보, 템플릿 등을 캐시한다

• 데이터베이스 : 사용자, 알림, 설정 등 다양한 정보를 저장한다.

• 메시지 큐 : 시스템 간의 의존성을 제거하기 위해 사용한다. 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할을 하기도 한다.

• 작업 서버 : 메시지 큐에서 전송할 알림을 꺼내서 제 3자 서비스로 전달한다.

• 제 3자 서비스 : 앞에서 설명

• 엣지 디바이스

3단계 - 상세 설계

안정성

• 분산 환경에서 운영될 알림 시스템 설계 할 때에는 안정성을 확보하기 위해서 고려할 사항들이 존재한다.

  1. 데이터 손실 방지
  2. 알림 중복 전송 방지

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

• 알림 템플릿

  중복된 메시지를 위해서 알림 메시지를 템플릿으로 고려하여 데이터베이스 및 캐시에 저장하여 사용한다.

• 알림 설정

  사용자는 너무 많은 알림을 받곤 한다. 따라서 스스로 조정할 수 있도록 선택권을 유지해줄 필요가 있다.

• 전송률 제한

  사용자에게 메시지 빈도를 제한하는 방법이 있다.

• 재시도 방법

  재시도 메시지 큐를 만들어서 개발자에게 문제가 발생시 통보할 수 있도록 한다. (로그 등등)

• 큐 모니터링

  메트릭을 활용해서 메시지 큐에 쌓인 알림의 개수들을 활용한다. 이 수가 너무 크면 작업 서버들이 이벤트를 빠르게 처리하고 있지 못하는 뜻이므로(sub) 해당 경우에는 작업 서버를 증설하는 것이 맞다. 이를 고려하여 메시지 큐의 토픽이나 파티션등을 고려하면 더 좋을 것 같다.

• 이벤트 추적

알림 확인율, 클릭율, 실제 앱 사용으로 이어지는 비율 등을 반영하여 데이터 분석 서비스를 활용하는 것이 좋다.

개선된 설계안