읽을때 마다 새로운 지식을 알게되는 책이지만, 다음 챕터로 넘어 갈수록 너무 어려워져서 손이가지 않는 책으로 최대한 많이 이해하고 완독을 목표로 정리를 하기위해서 글을 작성하게 되었다.
처음에는 2부 부터 읽다가 왜 1을 읽지 않느냐는 질문을 받고 1부를 읽게되었고 1부 부터 읽는게 필수라고 할정도로 난이도 차이가 있다.
잘근잘근 씹어먹듯, 많은 지식을 남길 수 있도록 열심히 정리해보자!
가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24
알림시스템은 모바일, 푸시, sms 알림 등 비동기적으로 정보를 전달하기 위해 사용합니다.
각각 알림 유형별 지원 방안을 확인해보자.
IOS 푸시알림
- 알림제공자 (provider)
- 알림 요청을 만들어 애플 푸시 알림서비스(APNS) 로 보내는 주체
APNS 는 [APPLE Push Notification Service] 의 줄임말이다.
단말토큰과 페이로드를 APNS 로 전달하여 알림요청을 보냅니다.
각각 단말토큰(device token)은 알림요청을 보내는데 필요한 고유 식별자값을 의미하고,
페이로드(payload)는 알림 내용을 담고 있으며, json 형태로 구성되어 있습니다.
페이로드의 형식으로 전달되는 데이터는 아래와 같은 형식으로 되어있다.
{
"API" : {
"alert" : {
"title": "Game Request",
"body":"Bpb wants to paly chess",
"action_loc_key":"play"
},
"bedge": 5
}
}- APNS : 애플이 제공하는 원격서비스
- ios 단말: 푸시 알람을 받는 단말이다.
Android 푸시 알림
IOS 와 비슷한 절차로 전송됩니다. APNS 대신 FCM 을 이용합니다.
SMS 메세지 / 이메일 전송
- SMS 메세지 전송은 상용 서비스를 이용해 보통 전송합니다.
- 이메일 서비스는 대부분의 회사에서 구축하여 적용할 수 있지만, 보통 상용시스템을 이용해서 적용합니다. 이렇게 적용시 전송 성공률과 데이터 분석서비스도 적용됩니다.
각각 서비스는 아래와 같은 모양으로 정리할 수 있습니다.
제 3자 사용자 제공서비스로 구성 요청 알림을 사용자에게 전달합니다.
연락처 정보 수집절차
- 알람을 보내려면 모바일 단말 토큰, 전화번호, 이메일 등의 정보가 필요합니다. 프로그램 설치, 계정 등록시 정보를 수집하여 DB 에 저장합니다.
기기 저장시 회원당 단말기가 여러개가 될 수 있으므로 해당부분을 고려해서 DB 를 구성해야합니다. 세부 DB 를 구성하는 방법을 생각해보면 회원 테이블과 별개의 테이블로 구성되고, 조인되어서 적용되어야 한다고 정리할 수 있습니다.
세부적으로 구성해보면 다음과 같습니다.
추가된 항목을 기준으로 보면,
- 서비스
- 1부터 N개까지 알람전송이 필요한 서비스들이 있습니다.
- 알림시스템
- 알림을 보내고자 하는 서비스들이 알림시스템에 전송합니다. 알림시스템은 API를 제공하고 각각 알림을 보내고자 하는 단말에 따라 알림전송 payload를 생성합니다.
이 알림시스템에는 문제점이 있습니다.
- 알림 시스템 서버가 하나밖에 없다는 점으로, SPOF 문제가 발생할 수 있고 한대의 서비스이므로 DB 나 캐시등 중요 컴포넌트를 개별적으로 늘릴 수 없다는 부분이 있습니다.
또한 제 3자 서비스에 대해서 응답을 기다려야하므로 성능에 대한 병목현상이 생길 수 있습니다.
해당 부분을 보강한 방법입니다.
각각 큐와 캐시, DB를 새로 추가하고 알림서버 증가하는 방식으로 적용할 수 있습니다.
추가 변경된 부분을 정리하면 다음과 같습니다.
- 알림서버
- 전송 API 를 구현 했습니다.
- 알림정보에 대한 기본적 검증을 하는 기능을 추가합니다. DB와 캐시정보에 있는데이터를 기준으로 알림에 포함시킬 데이터를 확인 및 추가합니다.
- 각각 서비스에 전송되어야할 요청을 기반으로 큐에 알림 정보를 추가합니다.
- 메세지 큐
- 다량의 알림 전송을 위한 버퍼의 역활을 합니다. 또한 의존성을 제거하기 위해 사용합니다.
- 작업서버
- 메세지 큐에서 전송할 알람을 꺼네어 제 3자 서비스로 전달하는 역할을 합니다.
- 만약 전송이 실패한다면 다시 메세지 큐로 실패한 요청정보를 전달하여 재시도 할 수 있도록 합니다.
해당하는 알림시스템의 전송구조를 흐름도에 따라서도 정리할 수 있습니다.
- 각각 알림을 보내고자하는 서비스는 API 를 이용하여 알림서버로 알림요청을 보낸다.
- 알림서버는 사용자정보, 단말 토큰, 알림 설정 과 같은 메타 데이터를 캐시나 DB 에서 호출합니다.
- 알림서버는 전송할 알림에 맞는 이벤트를 만들어서 해당하는 이벤트를 위한 큐를 추가합니다.
- 작업서버는 메세지 큐에서 알림이벤트를 꺼냅니다.
- 작업서버는 꺼낸 알림이벤트를 확인하여 제 3자 서비스로 보냅니다.
- 제 3자 서비스는 사용자 단말로 알람을 전송합니다.
- 전송성공한 데이터는 전송완료되어 마무리되고, 전송 실패된 데이터는 작업서버를 통해 다시 전송될 수 있도록 적용합니다.
정리
알림 서비스의 요청은 소실되면 안되므로 재시도 메커니즘과 중복 발송에 대한 고려도 함께 필요 합니다. 또한 요청이 너무 과도하게 있다면 사용자가 알람을 꺼버릴 수 있는 현상 또한 고려해야 합니다.
해당 부분에 대해서 제 3자 서비스의 문제로 인한 재시도의 방법, 이벤트가 실질적인 행동이 될 수 있게끔하는 고려 또한 필요합니다.
추가되는 부분은 책을 보면 더욱 자세하게 확인할 수 있습니다.
