알림 시스템 설계 - 면접관을 맡게되었다.
이게 알림시스템이다.
1단계 문제 이해 및 설계 범위 확정
오늘도 역시나 면접관과의 대화를 통해 1단계를 진행한다.
면접관과의 대화 예시는 아래와 같다.
지원자: 이 시스템은 어떤 종류의 알림을 지원해야 하나요?
면접관: 푸시 알림, SMS 메시지, 그리고 이메일입니다.
지원자: 실시간(real-time) 시스템이어야 하나요?
면접관: 연성 실시간(soft real-time) 시스템이라고 가정합니다. 알림은 가능한
한 빨리 전달되어야 하지만 시스템에 높은 부하가 걸렸을 때 약간의
지 연은 무방합니다.
지원자: 어 떤 종류의 단말을 지원해야 하나요?
면접관: iOS 단말, 안드로이드(android) 단말, 그리고 랩톱/데스크톱을 지원해
야 합니다.
지원자: 사용자에게 보낼 알림은 누가 만들 수 있나요?
면접관: 클라이언트 애플리케이션 프로그램이 만들 수도 있구요. 서버 측에서
스케줄링 할 수도 있습니다.
지원자: 사용자가 알림을 받지 않도록(opt-out) 설정할 수도 있어야 하나요?
면접관: 네. 해당 설정을 마친 사용자는 더 이상 알림을 받지 않습니다.
지원자: 하루에 몇 건의 알림을 보낼 수 있어야 하나요?
면접관: 천만 건의 모바일 푸시 알림, 백만 건의 SMS 메시지, 5백만 건의 이메
일을 보낼 수 있어야 합니다.요약
| 구분 | 요구사항 |
|---|---|
| 지원 채널 | 푸시 알림, SMS, 이메일 |
| 지원 단말 | iOS, Android, 웹(랩톱/데스크톱) |
| 알림 생성 주체 | 클라이언트 애플리케이션, 서버 측 스케줄링 |
| Opt-out | 사용자가 설정 시 이후 알림 미수신 |
| 실시간성 | 연성 실시간(soft real-time) — 최대한 빠르게 전달, 고부하 시 약간의 지연 허용 |
| 일일 트래픽 | 푸시 1,000만 건 + SMS 100만 건 + 이메일 500만 건 = 총 1,600만 건 |
2단계 개략적 설계안 제시 및 동의 구하기
iOS 푸시 알림, 안드로이드 푸시 알림, SMS 메시지, 그리고 이메일을 지원하는 알림 시스템의 개략적 설계안은
주로 알림 유형별지원방안, 연락처 정보 수집 절차, 알림 전송 및 수신 절차로 나뉘어 설계된다.
알림 유형별 지원 방안
IOS
- 알림 제공자 (provider) : 알림 요청(notification request)을 만들어 애플 푸시 알림 서비스(APNS： Apple Push Notification Service)로 보내는 주체.
알림 요청을 만들려면 다음과 같은 데이터가 필요하다.
- 단말 토큰 (device token) : 알림 요청을 보내는 데 필요한 고유 식별자
- 페이로드 (payload) : 알림 내용을 담은 JSON 딕셔너리
{
"aps": {
"alert": {
"title": "치이카와 극장판",
"body": "9월 30일 개봉예정",
"action-loc-key": "chikawa"
},
"badge": 5
}
}-
APNS
애플이 제공하는 원격 서비스. 푸시 알림을 iOS 장치로 보내는 역할. -
IOS 기기
푸시 알림을 수신하는 사용자 단말.
안드로이드
안드로이드 푸시 알림도 비슷한 절차로 전송된다. APNS 대신 FCM(Firebase Cloud Messaging)을 사용한다는 점만 다르다.
그 외
sms, 이메일
sms서비스와 이메일 서비스를 거쳐 사용자 단말로 알림 전송.
연락처 정보 수집 절차
알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다.
사용자가 우리 앱을 설치하거나 처음으로 계정을 등록하면 API 서버는 해당 사용자의 정보를 수집하여 데이터베이스에 저장한다.
이때, 사용자 정보와 기기는 1:N의 관계를 갖는다.
한 사용자가 여러 단말을 가질 수 있고, 알림은 사용자의 모든 단말로 전송되어야 하기 때문이다.
알림 전송 및 수신 절차
이전 단계들을 토대로 개략적인 설계안을 작성하자.
1. 서비스(1~N): 마이크로서비스/크론잡 등이 알림 시스템 API를 호출해 알림 발송을 요청한다.
- 알림 시스템: 요청을 받아 제3자 서비스 규격에 맞는 페이로드(Payload)를 생성한다.
- 제3자 서비스 및 단말: 확장성과 지역별 제약(예: 중국의 FCM 불가)을 고려해 제3자 서비스(APNs, FCM, JPush 등)를 거쳐 최종 단말(iOS, Android, SMS, Email)로 전달한다.
이 설계에는 문제가 있다.
- SPOF (단일 장애점): 서버 1대 장애 발생 시 전체 알림 서비스 마비
- 규모 확장성 한계: DB, 캐시 등 개별 컴포넌트의 독립적 스케일아웃 불가
- 성능 병목: 페이로드 생성(HTML 등) 및 제3자 연동 대기로 인한 과부하 발생
초안의 문제점을 알아 차린 뒤에는 개략적 설계안을 개선해야 한다.
| 구분 | 기존 초안의 문제점 | 개선 방안 | 개선 효과 |
|---|---|---|---|
| 장애 관리 | SPOF (단일 장애점) - 단일 서버 장애 시 전체 알림 중단 | 알림 서버 증설 및 메시지 큐 도입 - 알림 서버 다중화 - 알림 종류별 별도 큐 분리 | - 단일 서버 장애 시에도 시스템 유지 - 특정 제3자 서비스 장애 전파 차단 |
| 확장성 | 규모 확장성 한계 - DB/캐시 등 독립 스케일아웃 불가 | DB, 캐시, 작업 서버 분리 - DB/캐시 주 서버에서 독립 - 전송 전담 작업 서버 레이어 구축 | - 트래픽 및 데이터 증가 시 컴포넌트별 독립적인 수평 확장 가능 |
| 성능 및 과부하 | 성능 병목 - 페이로드 생성 및 외부 대기로 과부하 | 메시지 큐 기반 비동기 처리 - 알림 서버는 큐에 메시지 발행만 수행 - 작업 서버가 꺼내어 제3자 연동 처리 | - 서버 간 강한 결합 제거 - 대량 트래픽 발생 시 메시지 큐가 버퍼 역할 수행 |
① API를 호출하여 알림 서버로 알림을 보낸다.
② 알림 서버는 사용자 정보, 단말 토큰, 알림 설정 같은 메타데이터(metadata)를 캐시나 데이터베이스에서 가져온다.
③ 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 해당 이벤트를 위한 큐에 넣는다. 가령 iOS 푸시 알림 이벤트는 iOS 푸시 알림 큐에 넣어야 한다.
④ 작업 서버는 메시지 큐에서 알림 이벤트를 꺼낸다.
⑤ 작업 서버는 알림을 제3자 서비스로 보낸다.
⑥ 제3자 서비스는 사용자 단말로 알림을 전송한다.
3단계 상세 설계
안정성 (Reliability)
여러 서버와 시스템이 동시에 동작하는 분산 환경에서는 단일 서버 환경보다 서버 장애, 네트워크 오류, 메시지 중복 및 유실 등이 발생할 가능성이 높다.
따라서 분산환경에서 운영될 알림 시스템을 설계할 때는 안정성을 확보하기 위한 사
항을 고려해야 한다.
1. 데이터 손실 방지
알림은 지연되거나 순서가 틀려도 괜찮지만, 사라지면 곤란하다.
이 요구사항을 만족하려면 알림 시스템은 알림데이터를 데이터베이스에 보관하고 재시도 메커니즘을 구현해야 한다.
알림 로그(notification log) 데이터베이스를 유지하는 것이 한 가지 방법이다.
2. 알림 중복 발송 방지
같은 알림의 중복 전송을 완전히 막을 수는 없다.
알림은 대부분 한 번만 전송되지만, 분산 시스템 특성상 가끔 중복이 발생한다.
빈도를 줄이려면 중복 탐지 메커니즘을 도입하고 오류를 신중히 처리해야 한다.
간단한 방법은, 알림 도착 시 이벤트 ID로 이전에 처리된 적 있는지 확인해 중복이면 버리고 아니면 발송하는 것이다.
추가로 필요한 컴포넌트 및 고려사항
알림 템플릿
대형 알림 시스템은 하루 수백만 건의 알림을 처리하는데, 대부분 형식이 비슷하다.
대형 알림 시스템에서 알림 템플릿이 사용된다.
인자, 스타일, 추적 링크만 조정하면 사전에 정한 형식에 맞춰 알림을 만들어 내는 틀로, 매번 처음부터 만들 필요를 없애 준다. 이를 통해 형식의 일관성을 유지하고, 오류 가능성과 작성 시간을 줄일 수 있다.
본문:
모두가 알고 있는 그 시험이 코앞으로 다가왔습니다.
빅데이터분석기사 필기시험이 [date]에 있습니다! 지금부터 벼락치기 시작하지 않으면 늦습니다!
타이틀 (CTA: Call to Action):
지금 바로 빅분기 필기 벼락치기 시작하세요!
모두가 알고 있는 그 시험이 코앞으로 다가왔습니다.빅데이터분석기사 필기시험이 [date]에 있습니다! 지금부터 벼락치기 시작하지 않으면 늦습니다!
타이틀 (CTA: Call to Action):
지금 바로 빅분기 필기 벼락치기 시작하세요!알림 설정
사용자마다 알림 피로도가 다르기 때문에, 서비스는 사용자가 알림 수신 여부와 방식을 세밀하게 조정할 수 있도록 알림 설정(Notification Settings) 테이블을 별도로 관리한다.
테이블에는 다음과 같은 필드들이 필요할 것이며, 이와 같은 설정을 도입한 뒤에는 특정 종류의 알림을 보내기 전에 반드시 해당 사용자가 해당 알림을 켜 두었는지 확인해야 한다.
그 외
전송률 제한 : 한 사용자가 받을 수 있는 알림의 빈도를 제한하는 것
재시도 방법 : 제3자 서비스가 알림 전송에 실패하면, 해당 알림을 재시도 전용 큐에 넣고,
같은 문제가 계속해서 발생하면 개발자에게 통지한다.
푸시 알림과 보안 : iOS·안드로이드 앱의 알림 전송 API는 appKey와 appSecret을 이용해 인증을 수행하며, 이를 통해 인증되었거나 승인된 클라이언트만 해당 API로 알림을 보낼 수 있도록 보안을 유지한다.
큐 모니터링: 알림 큐에 쌓인 알림의 개수가 너무 많으면 서버들이 이벤트를 빠르게 처리하지 못하는 것. 이런 경우에는 작업 서버를 증설하자.
이벤트 추적 : 알림 시스템에서는 알림 확인율, 클릭률, 실제 앱 사용으로의 전환율으로의 전환율 같은 메트릭(사용자 행동을 수치로 측정한 지표)을 추적하는 것이 사용자를 이해하는 데 중요하며, 이를 위해 데이터 분석 서비스가 제공하는 이벤트 추적 기능과 알림 시스템을 통합하는 것이 일반적이다.
개선된 설계안
지금까지의 내용을 반영하여 수정한 설계안은 다음과 같다.
인증/전송률 제한: 알림 서버에 authentication과 rate-limiting 추가
재시도 기능: 전송 실패 시 큐에 재삽입하여 지정 횟수만큼 재시도
전송 템플릿: 알림 생성을 단순화하고 내용 일관성 유지
모니터링/추적: 시스템 상태 확인 및 향후 개선을 위한 관측 기능 추가4단계 마무리
알림은 사용자 행동을 기반으로 한 서비스 설계 및 수익 창출에 있어 필요불가결한 기능이다.
이번 장을 통해 우리는 좋은 알림 시스템이란 규모 확장이 쉽고, 푸시 알림·SMS·이메일 등 다양한 채널을 지원하며, 컴포넌트 간 연쇄 장애를 예방하기 위해 메시지 큐를 적극 활용하는 구조라는 것을 알게 되었다.
이러한 설계 원칙은 대규모 시스템을 구축할 때 기능성과 효율성을 모두 확보하기 위해 반드시 알아두어야 할 것이다.
시스터디 화이팅~!
+) 잼얘
스터디장에게 남소(?) 가능함.
특징
1. 기본정보 : 나보다 나이많은 남자
2. 취미 : 미술품 감상, 러닝, 독서
3. 거주지: 경기도
4. 기타: 친구를 소개 받고 있음.
5. 친구가 생기면 할 일 : 영화 오디세이 감상
