알림시스템

[InHyeok-J]

기술

• 메시지 큐
  • 알림 서버의 비동기 처리
• 배치 시스템
  • 분리됐을때, 배치 처리 , 처리 주기 ⇒ 효율적으로 알림 전송하려고 하는건가?
• 도달율
  • 메시지 알림 클릭율 → 사용자가 확인하는 과정

기능

1. 도달율 확인을 하기 위한 매트릭 정보 수집 기능

   • 알림 전송 시 Traking이 가능한 ID 부여
   • 알림 이벤트 로깅
   • 알림 전송 / 열람/ 클릭/ 응답 이벤트 기록 -> 사용자 행동 데이터 저장
   • 알림의 상태 실시간 모니터링 기능
     1. 전송 로그 수집
     2. 대시보드 (Ex 키바나) 를 통한 시각화 및 실시간 모니터링

2. 원하는 시간에 알림을 쐇을때 오차 시간 1분 미만 기능(알림 전송 속도 유지)

   1. 부하테스트 기반 알림 시스템 테스트
   2. 비동기 처리를 위한 메시지 큐 도입
   3. 알림 서버 분리

3. 정해진 시간에 수천명에게 동시 알림 ( 배치 )

   • 일간 목표를 체크해서 해당 달성을 하지 않은 사람 수~ 만명에게 알림 처리.

[InHyeok-J]

기능적 요구사항

1. 도달률을 수집할 수 있어야 한다.
2. 정해진 시간내(soft-real-time) 으로 메시지를 보낼 수 있어야 한다.

푸시 알림과 관련한 법률 고려 사항

- 정보통신망 이용촉진 및 정보보호등 관한 법률 참고

• 요약
  • 수신자 사전 동의 필요
  • 오후 9시 부터 오전 8시까지의 푸시를 보내려면 별도 사전 동의 필요
  • 광고성 정보 보낼때 다음과 같은 내용을 구체적으로 밝혀야 함(전송 정보 유형 및 주요 내용 , 전송자의 명칭 및 연락처, 수신 거부 방법)
  • 광고성 메시지라면 '(광고)' 를 필수적으로 붙여야 한다.
  • 수신 동의(거절) 결과를 14일 이내애 알려야 함(전송자의 명칭, 의사 표시 날짜, 처리 결과)
  • 수신 동의를 받은 날 부터 2년마다 수신동의 여부를 확인해야 한다.

도달률

• 알림 창 / Push 알림의 경우 알림창 클릭 시 여부
• 사용자 개인 알림/ 시스템 알림 구분 필요
• API 형식으로 FE에서 요청.

알림 과정

• 알림 생성 및 DB 저장 / 알림 조회로 크게 나뉜다.

단 건 알림 구조

• 어떤 이벤트 발생시 바로 생성되는 알림
• 현재 우리 서비스의 기획적 요구사항은 없다.

배치 알림 구조

• 학습 플랜이 등록된 사용자들의 현재 일간 학습 플랜을 수행중인지 여부를 체크하고 알림을 보내야 한다.
• 즉 주기적인 알림이 필요하기에 고려해야 할 사항은 크게 다음과 같음.
• 필요 기술

1. 스케줄링, 작업 시스템

   • CronJob
   • Task Queue
   • Spring Batch

2. 작업 분할 및 병렬 처리

   • Task Queue
   • 멀티 스레딩 / 멀티 프로세싱

3. 해당 시스템의 모니터링 필요

   • ELK Stack

4. 다량의 알림 생성시 write DB의 부하 예측

   • Write DB 복제

[InHyeok-J]

1. 알림 생성
   1. 스케줄링 기반 알림 생성(일간, 주간)
   2. 비즈니스 로직 검사
   3. 알림 생성 후 DB write
      • 스프링 스케줄러 / 쿼츠 / 스프링 배치
2. 알림 전송
   1. 푸쉬 Token 등록
   2. 푸쉬 Token 조회
   3. 만료 토큰 제거
   4. 푸시 전송
      • FCM/ redis/rabbitmq/kafka
3. 알림 조회
   1. 알림 조회(읽음 처리)

스프링 스케줄러

• @EnableScheduling 만 추가해서 SpringBoot 서버 환경에서 작업 가능
• Cron 표현식으로 작업 가능
• 기본은 싱글 스레드 / 멀티 스레드 , @Async와 함게 비동기 처리 가능

Quartz

• 작업 실패 시 재시작 처리, 애플리케이션 재시작 후 복귀 트랜잭션 등 복잡한 기능을 지원.
• 스프링 부트와 Quartz 스케줄러 연동 가능
• JobStore 제공
  • stateful한 작업 / 진행중인 작업의 상태 등 저장 가능.

SpringBatch

• 대량 데이터 처리: 데이터베이스, 파일 시스템 등 다양한 소스로부터 대량 데이터를 읽고, 처리하고, 저장하는 기능을 제공
• 스케줄러와 연동해서 대량의 회원 정보를 읽고 작업 처리

Redis Pub/Sub

• 단순한 설정으로 쉽게 사용 가능, 낮은 지연 시간
• 메시지 데이터가 구독자가 연결된 경우만 전달된다. (오프라인의 경우 유실)
• Redis 클러스터링을 지원

RabbitMQ

• 큐 기반, 토픽 기반, 라우팅 키 등을 지원.
• 메시지를 디스크에 저장하여 신뢰성을 보장.
• 교환기(Exchange)와 바인딩을 통해 메시지 라우팅을 세밀하게 제어.

Kafka

• 높은 처리량과 낮은 지연 시간, 그리고 수평 확장을 지원.
• 메시지를 디스크에 저장하여 신뢰성을 보장.
• 브로커, 주키퍼, 컨슈머, 프로듀서 등 분산 형태로 구성됨
• Offset 기반의 원하는 위치로부터 읽을 수 있다

[InHyeok-J]

7.15 피드백

배치 플랜이 어긋난 경우 대응이 필요

• ex) 오후 6시 작업 / 푸쉬가 다 안감 / 어떻게 처리할 것인가?

푸쉬를 쏘면 안되는 경우

• 6시 배치 / 6 ~ 9시 점검을 해야 한다 / 어떻게 할 것인가 /
• 푸쉬 처리 시 사용자 정보 DB를 매번 찌를 수 없음 /
• 작업 서버가 카프카/DB/FCM을 다 봐야 하는지 ?

분당 발사 할 수 있는 API 호출이 5000개일때 / 사용자가 천만명인 경우 API 5천이 호출되는 것을 어떻게 보장할 것인가? 작업을 실행하는 서버의 가용성은? late limit 컨트롤?

• 푸쉬 눌렀는지 도달율
• 카프카를 붙여놓으면 batch로 처리가 가능.? (조오금 다르다)

아파치 에어플로(Apache Airflow)

• 특정 시간이나 이벤트가 필요할때 사용 / 데브 옵스

---

TODO

• 클라랑 스펙 합의 보기(앱, 웹)
• 데이터를 어디에 적재할지/인덱스 어떻게 할지
• 모든 경우의 수에 대한 액션 플랜
• 테스트 플랜 작성
• 가상의 비즈니스 목적치 정하기 : 단위 서버당 몇명 까지 푸쉬를 해당 분에 전송할 수 있음.