[알림 서비스] 알림 서비스 구조 개선 - 신뢰성 있는 알림 서비스 제공

💡 구조 개선 수행 내용에 대해 정리한 문서입니다.

 

📌 개선 대상

• 알림 생성 처리 구조

 

📌 기존 처리 구조의 문제점 및 보완할 점 파악

*기존 처리 구조 동작 방식

1) 알림 생성 API 호출

2) 알림 서비스 내부에서 알림 데이터 저장 & FCM에 알림 전송을 API 요청 처리 스레드에서 모두 수행함

 

*기존 처리 구조의 문제점

• 알림 전송 지연이 발생할 경우 알림 생성 API 지연응답으로 해당 API를 호출한 유저/트윗 서비스에 장애가 전파됨
• 알림 서비스가 재시작되거나 장애가 발생하여 서버가 다운되면, Firebase에 아직 전달되지 않은 알림 메시지는 유실됨
• Firebase에 장애가 발생하거나 Firebase 전송 오류가 발생하면, 알림 메시지가 유실됨

 

📌 개선 구조

*개선 목적

• 알림 전송 작업으로 인한 API 지연응답 시 연계 서비스로의 장애 전파를 방지하고, FCM에 전송할 알림 메시지의 유실을 방지함

 

*개선 구조 후보

1) 외부 메시지 큐 도입

• 알림 생성 API 요청 시 Producer가 알림 메시지를 발행하고, 해당 토픽을 구독하는 Consumer가 알림 메시지를 가져와 FCM에 알림을 전송함

 

2) 스케줄러 도입

• 알림 생성 API 호출 시, 알림 서버는 전송할 알림 메시지를 데이터베이스에 저장하고, 이후 스케줄러를 사용해 주기적으로 전송할 메시지를 데이터베이스에서 조회해 FCM에 알림을 전송함

 

선택한 방안

• 현재 알림 서비스의 예상 최대 사용자 수와 제공 기능의 규모를 고려했을 때 메시지 큐를 사용하는 것은 오버스펙이라고 생각되어 스케줄러 도입을 선택하였음
• 스프링 스케줄러 선택 이유
  • 스프링에서 배치 작업을 처리할 수 있는 방식으로 Scheduler, Spring Batch를 제공함
  • 현재 여러 Job을 실행하는 것이 아닌 단순 알림 전송 작업만 수행하면 되고, 짧은 주기로 수행되어야 하므로, Spring Scheduler를 선택함

 

*개선 구조 동작 방식

• 알림 생성 API 호출 시, 알림 서버는 전송할 알림 메시지를 데이터베이스에 저장하고, 이후 스케줄러를 사용해 주기적으로 전송할 메시지를 데이터베이스에서 조회해 FCM에 알림을 전송함

 

<API 요청 처리 어플리케이션 서버>

1) 알림 데이터 & 메시지 저장

2) 응답 반환

 

<스케줄러>

• Spring Scheduler
  • 기본적으로 모든 @Scheduled 작업은 Spring에 의해 생성된 사이즈가 1인 Thread Pool에서 실행됨
  • Thread Pool 사이즈를 늘려 스케줄러가 병렬적으로 실행되도록 구성함
• 알림 전송 성공/실패 처리
  • 스케줄러가 DB에서 데이터를 Polling하는 구조이므로, 알림 전송 실패에 대한 처리를 어플리케이션에서 처리해야 함

 

> 새로운 알림 전송 스케줄러

• 실행 주기 : 5초

1) DB로부터 알림 메시지 데이터의 SendStatus 필드 값이 'NEW'인 데이터 조회

2) FCM에 알림 메시지 전송

3) 해당 알림 메시지 데이터의 SendStatus 필드 값 업데이트

• 전송 성공 : 'SUCCESS'로 업데이트
• 전송 실패 : 'RETRY'로 업데이트

 

> 알림 재전송 스케줄러

• 실행 주기 : 3분

1) DB로부터 알림 메시지 데이터의 SendStatus 필드 값이 'RETRY'인 데이터 조회

2) FCM에 알림 메시지 전송

3) 해당 알림 메시지 데이터의 SendStatus 필드 값 업데이트

• 전송 성공 : 'SUCCESS'로 업데이트
• 전송 실패 : 'FAIL'로 업데이트

 

*개선 사항 정리

1) 알림 전송으로 인한 연계 서비스로의 장애 전파 방지

• 스케줄러를 사용해 알림 요청 처리와 알림 전송 작업을 분리하여 알림 전송으로 인한 API 지연응답을 방지함

2) 전송할 알림 메시지 유실 방지

• 전송할 알림 메시지를 데이터베이스에 저장하고, 알림 재전송 스케줄러를 사용해 FCM에 성공적으로 알림 메시지를 전달함

 

💡 참고

https://blog.leocat.kr/notes/2018/10/10/translation-retrying-consumer-architecture-in-the-apache-kafka