[Refact] 알림 스케줄러 로직 변경 및 최적화

[JunbeomKoreaUniv]

작업 배경

기존에는 매 분마다
Select * from schedule where time=현재시각+5분
위 쿼리를 실행 해 모든 약속을 순회하며 5분뒤의 약속을 조회했었음.
즉, 약속이 없는 시각에도 불필요하게 스케줄링 작업을 실행하여 메모리를 낭비했었음.

따라서 약속 생성 시점에 알림을 동적으로 등록하여 이후에는 따로 약속을 스캔할 필요 없이 스케줄링이 되게 로직을 변경하였고, 그 과정에서 알림테이블 생성, 비동기 처리 등 최적화 작업을 진행하였음.

주요 변경사항

• 알림을 동적으로 스케줄링
  • (변경 전) @scheduled 애너테이션을 활용해 매분마다 모든 약속을 스캔하여 알림 푸시
  • (변경 후) 약속 생성할 때 TaskScheduler를 이용해 알림스케줄링계획을 동적으로 등록해 TaskScheduler가 해당 시각이 되면 자동으로 알림 푸시
  • 불필요한 메모리 낭비, 데이터 스캔이 줄어듦
• NotificationSchedule 테이블 생성
  • TaskScheduler를 통해 동적으로 등록된 알림스케줄은 WAS가 재시작되면 정보가 소실됨. 따라서 WAS가 재시작됐을 때 DB에서 등록된 알림정보를 불러오기 위해 NotificationSchedule 테이블을 생성하였음.
  • 이 때 서버 재시작시 불러온 NotificationSchedule 데이터에 Schedule이 LazyLoading설정 돼있어, LazyInitializationException이 발생할 수 있어 페치조인으로 방지하였음.
• TaskScheduler에는 알림스케줄이 Map형태로 저장됨.
  • 약속을 수정하거나 삭제하면 동적으로 등록됐던 스케줄을 수정해줘야하는데 이 때 Map으로 저장해야만 등록했던 알림스케줄을 가져와 수정/삭제할 수 있음.
• 알림발송메서드 비동기처리 및 TaskScheduler 다중 스레드 설정
  • 특정 시간에 여러 알림스케줄이 몰려 병목이 일어나는 것을 방지하고자 비동기+다중스레드 처리를 하여 병렬로 실행될 수 있게하였음.
  • 이게 작동하는지, 얼마나 시간을 세이브하는지에 대해서는 테스트가 필요함. 차후 반드시 진행할 예정.

Closed #212

[github-actions]

실패하는 테스트코드가 있어 PR이 자동으로 닫혔습니다.
Github Action에서 자세한 실패 로그를 확인하고 코드를 수정하세요.

[jjjh02]

현재 modifySchedule 안에서 notificationschedule 수정하는 로직에서 scheduleTime이 변경되지 않았더라도 항상 알림 스케줄이 취소되고 다시 등록되는 흐름으로 보입니다. 혹시 현재 방식을 선택한 특별한 이유나 고려한 상황이 있을까요?

이렇게 하면 실질적으로 변경이 없는 경우에도 DB 업데이트 및 스케줄러 리스케줄 작업이 매번 발생하게 되어 성능상 불필요한 비용이 발생할 수 있습니다. scheduleTime 변경 여부를 먼저 비교한 후, 변경된 경우에만 NotificationSchedule을 취소/재등록하는 방식으로 최적화하면 좋을 것 같아서요.!

[JunbeomKoreaUniv]

엇 제가 스케줄 수정 API를 수정하는 필드만 보내는것으로 착각했었네요
수정해서 푸시했습니다~

[jjjh02]

이전 로직에 비해 전체적으로 성능과 최적화 측면이 훨씬 개선된 게 느껴지네요~ 수고하셨습니다!!