10. 알림 시스템 설계

10. 알림 시스템 설계

개요 #

앱(iOS, Android) 알림, SMS, Email 알림을 보내야 한다.



iOS 푸시 알림 #

iOS에서 Push Notification(푸시 알림)을 보내기 위해서 3가지 컴포넌트가 필요하다.

알림 제공자(Provider), APNS, iOS 단말기(Device)

컴포넌트설명
알림 제공자 (Provider)알림 요청을 APNS에 요청하는 주체이다.

알림 요청을 생성하기 위해 단말 토큰(device token), 내용(payload) 가 필요하다고 한다.
APNS (Apple Push Notification Service)애플이 제공하는 원격 서비스이다.

푸시 알림을 iOS 단말기로 보내는 역할을 담당한다.
iOS 단말기사용자가 사용하는 단말기(장치)이다.

안드로이드 푸시 알림 #

안드로이드 Push Notification(푸시 알림)도 iOS와 비슷하다. APNS 대신 FCM을 사용한다는 점만 다르다.

알림 제공자, FCM, 안드로이드 단말기


SMS 메시지 #

(보통의 경우)제 3사업자의 서비스를 이용해서 SMS 메시지를 보낼 수 있다.

알림 제공자, SMS 서비스(사업자), SMS 수신 단말기


이메일 #

고유 이메일 서버를 구축해도 좋고, 상용 이메일 서비스를 이용해도 된다.

알림 제공자, Email 서비스, 이메일 수신 단말



초안 (Ver1) #

서비스 1    -------------|
                       |                                    |--------- APNS           ----- iOS 단말
                       |                                    |--------- FCM            ----- 안드로이드 단말
서비스 2    -------------|-----------   알림 시스템 ------------| 
                       |                                    |--------- SMS 서비스       ----- SMS 단말
                       |                                    |--------- Email 서비스     ----- Email 수신 단말
                       |
서비스 N    -------------|

문제점

  • SPOF : 알림 시스템 (한 대의 알림 시스템 서비스로 모든 알림을 처리하고 있다.)
  • 확장성 : 한 대의 알림 시스템 서비스로 모든 알림을 처리하고 있어서 확장성이 떨어진다.
  • 성능 병목 : 알림을 요청하는 것은 자원을 많이 필요로 하는 작업일 수도 있다. 하나의 서버(알림 시스템)에서 처리하면 과부하 상태에 빠질 수 있다.



개선 (Ver2) #

서비스 1    -------------|
                       |                                    |--- iOS Queue --- Worker(작업 서버) --- APNS --- iOS 단말
                       |                                    |--- 안드로이드 Queue --- Worker(작업 서버) --- FCM --- 안드로이드 단말
서비스 2    -------------|-----------   알림 시스템 ------------| 
                       |                캐시                 |--- SMS Queue --- Worker (작업 서버) --- SMS 서비스 --- SMS 단말
                       |                DB                  |--- Email Queue --- Worker (작업 서버) --- Email 서비스 --- Email 단말
                       |
서비스 N    -------------|

* Worker 는 
- 실패 시 재시도할 수 있다. (retry)
- 로그(이력)을 저장/관리할 수 있다.

나는 처음에 서비스 - Queue - Worker 구조가 바로 떠올랐다. (즉, 위 그림에서 중간에 알림 시스템이 없는 것)

위와 같이 설계하면,

  • 각 서비스에서 진행해야하는 분기 처리(어떤 Queue에 넣을 건지)를 알림 시스템에서 하게 될 거고 (역할 분리)
  • (본인의 역할에 충실하게 되면서) 알림 시스템에서는 알림 시스템 용도의 DB(+ 캐시)를 통해 성능을 향상할 수 있을 것 같다. (성능 향상)

Ver1 에 비해,

  • 작업(작업 서버)와 알림 시스템의 역할을 분리했다.
    • 알림 시스템에서는 처리(work)하지 않는다.
    • Event 만 발행하므로 과부하(병목) 상태를 방지할 수 있다.
        • 캐시 사용
  • 알림 시스템인 기본적인 검증(Verification) + Event 발행만 담당한다.
  • 알림 시스템 <-> 알림 서비스(APNS, FCM, SMS 서비스, Email 서비스) 결합(의존성)을 분리했다.
    • 서비스, 알림 시스템 입장에서는 알림 서비스를 더 이상 신경쓰지 않아도 된다. (확장성)



최종 (Ver3) #

조금 더 개선해본다. (안정성, 모니터링, 이벤트 추적, 처리율 제한, 알림 템플릿 등)

기능설명
알림 템플릿알림은 대부분 Format이 동일하다.

따라서 고정된 포맷의 템플릿 적극 활용할 수 있다. (변수 값만 받아 처리한다.)
Queue 모니터링큐 사용 시 Lag은 중요한 메트릭이다. 꼭 모니터링한다.
이벤트 추적알림 확인율, 클릭율, 실제 앱 사용 비율 등의 메트릭은 사용자를 이해하는데 중요하다.

데이터 분서 서비스(analytics)는 보통 이벤트 추적 기능도 제공한다.

보통 알림 시스템을 만들면 데이터 분석 서비스와도 통합해야 한다.

알림 서비스 + 데이터 분석 서비스(analytics) 조합을 기억하자.


단순 #


전체 #