[Study] 10장) 알림 시스템 설계

Tarte·2025년 12월 10일

[Study] 대규모 시스템 설계 기초 (1)

목록 보기

9/11

서론

알림 시스템 설계

모바일 푸시 알림, sms 메시지, 이메일

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

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

ios 푸시 알림, 안드로이드 푸시 알림, sms 메시지, 이메일 ㅣㅈ원하는 알림 시스템의 개략적 설계안

알림 유형별 지원 방안
연락처 정보 수집 절차
알림 전송 및 수신 절차

알림 유형별 지원 방안

ios 푸시 알림

ios에서 푸시 알림을 보내기 위해서는 세 가지 컴포넌트 필요

[알림 제공자] -> [APNS] -> [ios 단말]

알림 제공자(provider): 알림 요청을 만들어 애플 푸시 알림 서비스(APNS)로 보내는 주체, 알림 요청을 만들려면 다음과 같은 데이터가 필요함
- 단말 토큰: 알림 요청을 보낼 때 필요한 고유 식별자
- 페이로드: 알림 내용을 담은 JSON 딕셔너리

{
  "aps": {
    		"alert": {
            	"title": "Game Request",
              	"body": "Bob wants to plat chess",
              	"action-loc-key": "PLAY"
            },
    		"badge": 5
  
  }

}

APNS: 애플이 제공하는 원격 서비스로 푸시 알림을 ios 장치로 보내는 역할 담당
ios 단말: 푸시 알림을 수신하는 사용자 단말

안드로이드 푸시 알림

ios랑 비슷한데 FCM(Firebase Cloud Messaging)을 사용하는 것만 다름

[알림 제공자] -> [FCM] -> [안드로이드 단말]

SMS 메시지

SMS 메시지를 보낼 땐 보통 트윌리오, 넥스모 같은 제3사업자 서비스를 많이 이용함

[알림 제공자] -> [SMS 서비스] -> [SNS 수신 단말]

이메일

많은 회사가 상용 이메일 서비스를 사용하는데, 유명한 서비스로 샌드그리드, 메일첨프가 있음
전송 성공률이 높고 데이터 분석 서비스도 제공함

[알림 제공자] -> [이메일 서비스] -> [이메일 수신 단말]

연락처 정보 수집 절차

알림 보낼 때 단말 토큰, 전화번호, 이메일 주소 드으이 정보 필요

그림처럼 사용자가 우리 앱을 설치 or 처음으로 계정을 등록하면 API 서버는 해당 사용자의 정보를 수집하여 데이터베이스에 저장함
이 데이터베이스에 연락처 정보를 저장할 테이블 구조는 아래와 같음
이메일 주소, 전화번호 => user 테이블에 저장
단말 토큰 => device 테이블에 저장 (한 사용자가 여러 단말을 가질 수 있고, 알림은 모든 단말에 전송되어야 한다는 점 고려)

알림 전송 및 수신 절차

개략적 설계안 (초안)

1부터 N까지의 서비스: 마이크로서비스, 크론잡, 분산 시스템 컴포넌트일 수 있음
알림 시스템: 1개 서버만 사용하는 시스템이라고 가정 => 이 시스템은 서비스 1~N에 알림 전송을 위한 API를 제공하고, 제3자 서비스에 전달할 알림 페이로드를 만들 수 있어야 함
제3자 서비스: 사용자에게 알림을 설제로 전달하는 역할
ios, 안드로이드, SMS, 이메일 단말: 사용자는 자기 단말에서 알림을 수신

문제점

SPOF: 알림 서버가 하나밖에 없기 때문에 장애가 생기면 전체 서비스의 장애로 이어지는 문제
규모 확장성: 한 대 서비스로 푸시 알림에 관계된 모든 것을 처리하므로 데이터베이스, 캐시 등의 중요 컴포넌트 규모를 개별적으로 늘릴 방법이 없어짐
성능 병목: 알림을 처리하고 보내는 건 자원을 많이 필요로 하는 작업 => 모든 것을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에는 시스템이 과부하 상태에 빠질 수 있음

개략적 설계안 (개선)

개선안

데이터베이스, 캐시를 알림 시스템 주 서버에서 분리
알림 서버를 증설하고 자동으로 수평적 규모 확장이 이뤄질 수 있도록
메시지 큐를 이용한 시스템 컴포넌트 사이의 강한 결합을 끊음
1부터 N까지의 서비스: 알림 시스템 서버의 API를 통해 알림을 보낼 서비스들
알림 서버: 아래의 기능 제공
- 알림 전송 API: 스팸 방지를 위해 보통 사내 서비스 or 인증된 클라이언트만 이용 가능
- 알림 검증: 이메일 주소, 전화번호 등에 대한 기본적 검증 수행
- 데이터베이스 또는 캐시 질의: 알림에 포함시킬 데이터를 가져오는 기능
- 알림 전송: 알림 데이터를 메시지 큐에 넣음 => 하나 이상의 메시지 큐를 사용하므로 알림을 병렬적으로 처리할 수 있음
캐시: 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시
데이터베이스: 정보 저장
메시지 큐: 시스템 컴포넌트 간 의존성을 제거하기 위해 사용
- 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할
- 알림의 종류별로 별도 메시지 큐를 사용하여 장애가 발생해도 다른 종류의 알림은 정상 동작
작업 서버: 메시지 큐에서 전송할 알림을 꺼내서 제3자 서비스로 전달하는 역할을 담당하는 서버

협력을 어떻게 해서 알림을 전송할까?
1. API를 호출해서 알림 서버로 알림 보냄
2. 알림 서버는 메타데이터를 캐시, 데이터베이스에서 가져옴
3. 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 해당 이벤트를 위한 큐에 넣음
4. 작업 서버는 메시지 큐에서 알림 이벤트를 꺼냄
5. 작업 서버는 알림을 제3자 서비스로 보냄
6. 제3자 서비스는 사용자 단말로 알림 전송

3단계 상세 설계

알아볼 내용

안정성
추가로 필요한 컴포넌트 및 고려사항: 알림 템플릿, 알림 설정, 전송률 제한, 재시도 메커니즘, 보안, 큐에 보관된 알림에 대한 모니터링과 이벤트 추적 등
개선된 설계안

안정성

분산 환경에서 운영될 알림 서비스를 설계할 때는 안정성을 확보하기 위한 사항 몇 가지를 반드시 고려해야 함

데이터 손실 방지

알림 전송 시스템의 가장 중요한 요구사항 중 하나 => 어떤 상황에서도 알림이 소실되면 안 됨

이 요구사항을 만족하기 위해 알림 시스템은 알림 데이터를 데이터베이스에 보관하고 재시도 메커니즘 구현 필요
알림 로그 데이터베이스를 유지하는 것도 한 가지 방법

알림 중복 방지

같은 알림이 여러 번 반복되는 걸 완전히 막는 건 불가능 => 빈도를 줄이는 중복 탐지 메커니즘을 도입하고 오류를 신중하게 처리
간단한 중복 방지 로직 사례

보내야 할 알림이 도착하면 그 이벤트 ID를 검사하여 이전에 본 적이 있는 이벤트인지 살핌
중복된 이벤트면 버리고 그렇지 않으면 알림 발송

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

알림 템플릿, 알림 설정, 이벤트 추적, 시스템 모니터링, 처리율 제한 등 필요한 추가 컴포넌트에 대해 알아보자

알림 템플릿

템플릿을 사용해 전송될 알림들의 형식을 일관성 있게 유지할 수 있고 오류 가능성뿐만 아니라 알림 작성에 드는 시간도 줄일 수 있음

알림 설정

많은 웹사이트와 앱에서는 사용자가 알림 설정을 상세히 조정할 수 있게 함

필드	타입	설명
user_id	bigint
channel	varchar	#알림이 전송될 채널, 푸시 알림, 이메일, SMS 등
opt_in	boolean	#해당 채널로 알림을 받을 것인지 여부

전송률 제한

사용자에게 너무 많은 알림을 보내지 않도록 하는 방법 => 한 사용자가 받을 수 있는 알림의 빈도를 제한
=> 알림을 너무 많이 보내기 시작하면 사용자가 알림 기능을 아예 꺼 버릴 수 있어 중요함

재시도 방법

제3자 서비스가 알림 전송에 실패하면 해당 알림을 재시도 전용 큐에 넣음
같은 문제가 계속 발생하면 개발자에게 통지함

푸시 알림과 보안

ios, 안드로이드 앱의 경우 알림 전송 API는 appKey와 appSecret을 사용해 보안 유지
-> 따라서 인증, 승인된 클라이언트만 해당 API를 사용하여 알림을 보낼 수 있음

큐 모니터링

알림 시스템을 모니터링할 때 중요한 메트릭 하나는 큐에 쌓인 알림의 개수
이 수가 너무 크면 작업 서버들이 이벤트를 빠르게 처리하고 있지 못하다는 뜻
-> 이런 경우에는 작업 서버를 증설하자

이벤트 추적

알림 확인율, 클릭율, 실제 앱 사용으로 이어지는 비율 같은 메트릭은 사용자를 이해할 때 중요함

데이터 분석 서비스는 보통 이벤트 추적 기능도 제공 => 따라서 보통 알림 시스템을 만들면 데이터 분석 서비스와도 통합해야 함

수정된 설계안

알림 서버에 인증, 전송률 제한 기능 추가
전송 실패에 대응하기 위한 재시도 기능 추가
전송 템플릿을 사용해 알림 생성 과정을 단순화하고 알림 내용 일관성 유지
모니터링과 추적 시스템을 추가해 시스템 상태를 확인하고 추후 시스템 개선을 쉽도록 함

4단계 마무리

Tarte

기술 블로그

이전 포스트

[Study] 9장) 웹 크롤러 설계

다음 포스트