Skip to content

06 ‐ 08 ‐ Notification 모듈

Jump to bottom
Ryu(Paul) edited this page Feb 9, 2024 · 1 revision

알람 모듈 아키텍처 문서

목차

  1. 비즈니스 요구사항
  2. 아키텍처 설계
  3. API 엔드포인트 설계
  4. 다른 모듈과 상호작용 포인트

비즈니스 요구사항

목적

  • 온라인 상태에서 각각의 행동에 맞춰서 알람을 전달해준다.
  • 오프라인 상태에서는 PWA를 통해 실시간에 가깝게, 개인화된 설정에 따라 알림 메시지가 전달된다.
  • 알림의 유기적 연계를 통해, 온-오프라인 상황에서 전달되는 알람이 사용자 경험을 해치지 않으면서 적절하게 생성, 전달, 삭제가 되어야 한다.

요구사항

기능정의

  • 주 서버 : 'spring boot' 기반의 서버
  • 부 서버 : 'NestJS' 기반의 서버
  • 프록시 : NGINX 로 구현된 서버끼리 소통을 위한 프록시 서버

기능명세

  • 각 모듈에서 알람이 필요시 간단하게 등록이 가능하다.
  • 온라인, 오프라인 상태를 파악하고, 이에 따라 알람을 PWA로 전달할지 여부를 정하고 전달이 가능하다.
  • 긴급도에 따라 선택적으로 전달 여부가 파악되며, 여기서 사용자의 알림 설정 동의 여부를 파악해 전달이 가능하다.
  • 알람 개별의 삭제를 지원한다.
  • 알람 전체 삭제를 지원한다.
  • 알람을 유저 한명에게 전달이 가능하다.
  • 알람을 특정 유저에게 전달이 가능하다.
  • 알람을 전체 유저에게 전달이 가능하다.
  • 알람을 유저에게 전달할 때, 페이지네이션이 지원 된다.
  • 주 서버에서 알림 이벤트 발생에 대하여 처리 후, 이를 부 서버에 알리며, 프록시는 이 요청과 결과를 반환해줄 수 있도록 지정된다.
  • (PWA) 알림이 전달되고, 사용자가 하드웨어에서 리다이렉션이 이루어지면, 알람 데이터베이스에서 해당 알람이 자동 삭제가 되어야 한다.
  • (PWA) 유저가 구동을 승인하면, 이에 대응하여 주 서버에서 해당 목록에 사용자ID와 pwa를 위한 키를 등록할 수 있다. (중복 등록이 허용된다.)
  • (PWA) 유저가 구독을 취소하면, 이에 대응하여 주 서버에서 해당 목록에서 대상을 삭제한다.

성능명세

  • 구현 후 고민할 예정

아키텍처 설계

모듈 구성

클라이언트

  • app.js
  • manifest
  • HTTPS 환경

NGINX

  • HTTPS 환경 : PWA 표준을 지키기위한 HTTPS 표준 보안 키 발급 및 적용
    • 프론트 엔드 : 구성 완료
    • 백 엔드(주 서버) : 구성 완료
    • (예정) 백 엔드(부 서버) : CICD 이후 구성 예정
  • PWA proxy 설정 : client에서 PWA 구독과 함께, 앱 알림, 구독하여 백그라운드 동기화가 있을시 동작 할 수 있도록 설정한다. 구성 예정
  • 주-부 서버 proxy 설정 : 백엔드 서버 간의 통신을 위한 설정 구성 예정

주 서버(Spring Boot)

  • Socket Gateway : 사용자 온라인 여부를 추적하기 위한 소켓을 활용한 헬스 체크용도
  • Socket Service : 사용자 온라인 여부를 의존성 주입을 통해 사용할 수 있다.
  • Alarm Controller : 알람의 API 를 맵핑한 컨트롤러
  • Alarm Control Service : 알람의 제어, 부 서버와의 통신 등을 담당한다.
  • Alarm CRUD Service : 알람의 작성, 데이터베이스와 관련된 작업들을 담당한다.

부 서버(NestJS)

  • Alarm Controller : PWA 관련된 기능과, 주서버에서 전달하는 통신을 수신하는 역할을 한다.
  • Alarm Service : DB 읽기 접근을 하고, PWA 앱 푸시 기능을 담당한다.

데이터 베이스

  • Alarm-List Table : 실제 작성된 알람 데이터
  • Alarm-Deleted-All Table : 알람 중 전체 공지사항인 알람에서, 삭제를 요청받은 경우 관리를 위해 기록하는 용도, 특정 알람이 전체 공지사항일 때, 해당 테이블에 삭제를 요청한 사람의 데이터 수가 가득 차면, 그때 해당 공지사항 메시지가 삭제 된다.
  • Alarm-subscription Table : PWA 구독시 발생하는 키와 내용을 담는 테이블

데이터 모델

  1. push server DTO : 푸시 서버에 보내야 할 것들
  • title : 알람 제목
  • body : 알람 본문
  • icon : 알람 표시용 아이콘의 URL
  • badge : 알림 배지에 사용될 작은 아이콘 URL
  • data : 추가 데이터를 포함할 수있는 객체(URL, 알림 관련 기타 정보 등)
  • dir : 텍스트 방향 지정
  • lang : 알림 언어
  • tag : tag 알림 그룹화용 식별자
  • vibrate : 진동 패턴 정의 숫자 배열
  1. AlarmListnotification
  • id : LONG, 알림 이벤트에 대한 고유 키
  • title : String, 메시지 제목
  • message : String, 메시지 본문
  • targetType : Enum, 메시지 종류(전체, 일정 부분)
  • target : List, userId 리스트, 대상목록을 가리키며, 전체 메시지인 경우 null 이 된다.
  • List targets : 대상 목록
  • linkData : String, 리다이렉션을 위한 URL 데이터
  • sended : Enum, PWA로 보내졌는지 여부 확인용
  • priority : Enum, 우선순위를 통해 스케쥴링, 강제우선, 당장 보내야 하는 것을 구분하는 용도
    • immediate : 사용자의 동의여부에 근거하여 메시지를 즉시 전달한다.
    • scheduled : 사용자의 동의여부에 근거하여 메시지를 일정하게 전달한다.
    • force : 사용자의 동의여부에 근거하지 않고 메시지를 즉시 전달한다.
  • messageType : String 알림의 Tag 기능을 할 예정
  • scheduledTime : 예상되는 전달 시간, 입력시 한국 기준으로 넣고 내부 동작은 UTC 기준으로 진행되어야 한다.
  • totalCount : Long, 알람을 보내야할 전체 인원수를 지정한다.
  • deleteCounter : Long, 전체 또는 1명 초과의 알람의 경우 삭제 요청이 올 경우, 여기에 카운팅 된다.
  • createdAt(BaseEntity)
  • updatedAt(BaseEntity)
  1. AlarmDeletedAllnotification-target
  • id : AlarmId + UserId : 복합키로 생성하는 ID, 삭제 요청이 왔을 경우 기록하는데 사용한다.
  • alarmId : 연결되는 알람과 연결시킴
  • id
  • notificationId
  • userId
  1. AlarmSubscriptionnotification-subscription
  • id : 고유키
  • userId : 사용자 계정
  • subscriptionKey : 구독하는데 사용되는 고유 키
  • createdAt(BaseEntity) : 생성날짜만 등록

알림 대상 목록

immediate 알림

  • 쪽지 알림
  • 스터디 / 프로젝트 승인 알림 & 거절 알림
  • 스터디 / 프로젝트 참여 신청 알림 & 취소 알림
  • 스터디 / 프로젝트 종료 알림
  • 피어로그 & 쇼케이스 작성 알림
  • 팀 페이지 공지 업데이트 알림

schedule 알림

  • 관심 키워드 알림
  • 피어로그 & 쇼케이스 작성 알림
  • 쇼케이스 '좋아요', '댓글' 알림
  • 운영팀 공지

force 알림

  • 운영팀 공지
  • 수동 알림

사용 시나리오 정리

기본 알림 프로세스 : PWA 구독이 필요없는 상황

  1. 유저가 회원가입을 통해 계정 생성이 이루어진다.
  2. 유저에게서 알림에 해당하는 이벤트가 발생한다.
  3. 해당 이벤트를 담당하는 모듈에서 DI 되어 있는 알람모듈에서 알람을 작성한다.
  4. 유저가 온라인 상태를 확인하면 PWA 로 전달하지 않으며, 알림 메시지 DB에 저장만 이루어진다. (이때 scheduled, force는 무조건 PWA로 진행된다)
  5. 유저가 알람을 요청하는 API를 호출하게 되는 경우, 해당 요청에 해당하는 메시지를 전달한다.
  6. 유저에게 메시지가 전달되면 sended 에 true로 바뀌며 메시지가 update 된다.

알림 삭제 프로세스(전체삭제) : 받은 알람 리스트에 대한 삭제

  1. 알람 리스트에서 삭제가 발생한다.
  2. 전체 삭제 API가 호출되면서 DB를 비운다.
  3. 성공 했음을 전달하고 마무리 시킨다.

알림 삭제 프로세스(일부)

  1. 알람 리스트에서 삭제가 발생한다.
  2. 삭제하는 대상에 대해 파악을 하고(id) 해당 삭제를 진행한다.
  3. 성공 했음을 전달하고, 새로운 리스트를 갱신하여 전달한다.(이때 프론트엔드는 의도적으로 로딩시간을 추가한다)

전체, 또는 1명이 아닌 부분 알람인 경우의 삭제에서 로직

  1. 요청이 들어온 삭제의 이벤트가 하나의 유저를 위한게 아닌것이 검증되면
  2. 전체 알람인 경우에 AlarmDeletedAll 테이블에 해당 내용을 기록한다.
  3. 일부 알람인 경우에는 AlarmDeletedAll 테이블에 해당 내용을 기록하지는 않는다. 대신 List 에서 해당하는 userId를 삭제한다.
  4. deleteCounter를 증가 시킨다.
  5. 이때 deleteCounter == totalCount 인 경우 해당 알람을 삭제하고, 전체 알람시 AlarmDeletedAll 테이블의 대상이 있다면 이 역시 삭제한다.

PWA 알림 프로세스

  1. 알림이 필요한 이벤트가 발생하고, 알림이 생성된다.
  2. 유저가 오프라인 상태가 되었다는 것을 파악한다.
  3. 주서버에서 부서버로 알림에 대한 처리를 요청한다. 이때, 해당 관련하여 어디서부터 어디까지의 이벤트 처리를 해놓아야 하는지를 전달한다(알람 Id의 리스트?)
  4. 부서버는 DB를 일괄 읽어서, 처리해야하는 것들만을 모두 분석 한다. 이에 대한 리스폰스를 전달하면서 이에 대해 작업을 진행한다.
  5. 작업을 마치면 아이들 상태로 돌아간다.
  6. 주 서버는 리스폰스 값을 받은 뒤, 만약 사용자가 리다이렉션을 통해 지정된 link로 가게 된다면 request를 통해 pathvalue 를 기존 URL 뒤에 붙여주며, 주 서버는 이를 커스텀 어노테이션을 통해 인지. 이미 redirection으로 알람을 수령했으므로 DB에서 알람을 삭제한다.

특수 케이스 관련 내용

  • 고민중

에러 처리 전략

  • 알림 삭제 요청 시 보안 문제는 없는지? (JWT, 온라인 여부 등을 종합 고려할 것, 비동기 처리 필요할지도?)

API 엔드포인트 설계

Web Push 를 위한 서비스 고민

웹 푸시 알림을 위한 각 서비스의 특징과 비용을 다음과 같이 정리할 수 있습니다:

Firebase Cloud Messaging (FCM)

  • 특징: Android, iOS, 웹 기기를 통해 푸시 알림을 보내는 기능을 제공합니다. 크로스 플랫폼 솔루션으로, 다양한 운영 체제와 장치를 지원합니다 (출처).
  • 비용: Firebase Cloud Messaging은 완전히 무료로 사용할 수 있습니다 (출처).

OneSignal

  • Free Plan: 제한된 개인화, 무제한 API 전송, 지능적인 배송, A/B 테스팅, GDPR 준수 기능 제공 (출처).
  • Growth Plan ($9/월 시작): 표준 개인화, 고급 인앱 메시징, 메시지 제한, 확인된 배송 등을 추가로 제공 (출처).
  • Professional Plan ($99/월 시작): 고급 개인화, 저니 접근, CSV 내보내기, 사용자 정의 결과 추적 등을 추가로 제공 (출처).
  • Enterprise Plan: 맞춤 계약 및 추가 기능, 볼륨 기반 할인 제공. 고급 개인화, 사용자 정의 계약, 온보딩 및 지원, 고급 사용자 권한 등을 포함 (출처).

Amazon Simple Notification Service (SNS)

  • 특징: 미리 정해진 최소 약정이나 장기 계약 없이 사용한 만큼만 비용을 지불합니다 (출처).
  • Standard topics: 월간 API 요청 수와 다양한 엔드포인트로의 배송 수에 기반한 요금제 (출처).
  • FIFO topics: 발행된 메시지 수, 구독된 메시지 수, 각각의 페이로드 데이터 양을 기반으로 한 요금제 (출처).
  • 메시지 필터링: 속성 기반 메시지 필터링은 무료이며, 페이로드 기반 필터링은 전송된 페이로드 데이터 양에 따라 비용이 부과됩니다 (출처).
  • 메시지 보관 및 재생: 저장된 데이터 양과 저장 기간에 기반한 요금제 (출처).
  • 메시지 데이터 보호: 검사된 페이로드 데이터 양과 생성된 감사 보고서 데이터 양에 따라 비용이 부과됩니다 (출처).
  • 전 세계 SMS: 200개 이상의 국가에 SMS 메시징을 제공합니다. 전송 요금은 목적지 국가에 따라 다르며, 일부 국가에서는 전송을 위해 전용 발신자 ID를 구입해야 할 수도 있습니다 (출처).
Clone this wiki locally