[BE] 캘린더 배포 기능 리팩터링 - 배포 대기큐 구현

[pilyang]

구현기능

현 상황

팀생성, 캘린더배포중이 아닌 팀의 배포캘린더 url요청시

• 바로 ics파일 생성 및 배포 진행

동일한 팀플레이스에서 1시간동안 온 요청이 n(10)회 이하인 경우 바로 배포 진행 동일한 팀플레이스에서 1시간 이내 온 요청이 10회를 넘어가면 1시간이 지나는 시점에서 일괄적으로 배포 1회만 진행 대기 상태는 1시간마다 밀린 배포 후 모두 초기화

ex) 한 팀플레이스에서 1시간 이내 15회의 일정변동이 있어 15회 업데이트가 필요하다면 첫 10회는 매번 반영 + 배포 진행 이후 요청은 대기하다가 다음 1시간 주기에 해당 팀플레이스에서 일정 배포 1회만 진행

리팩터링 방향

일정 변경등의 ics재배포 요청이 오면 작업큐에 삽입 작업큐는 중복 삽입이 안되도록 처리 (같은 팀플레이스의 요청은 1개만 들어가도록) ->LinkedHashSet사용 고려

변경 고려 이유

한팀에서의 많은 요청도 있지만, 갑자기 많은 팀에서의 요청이 들어오게 될때의 문제 상황 방지

• 기존 처리의 스레드풀 설정도 가능한데 이러한 방식 적용 이유
  • 구현이나 의미적으로 좀 더 깔끔하게 처리를 해보고 싶은 욕심
  • 하지만 스레드풀 설정변경도 할 예정 (마찬가지로 작업대기큐에 집어넣는것도 부하가 걸릴 수 있으므로 해당 작업을 할 스레드풀 설정 필요)
• 스레드풀로 설정하면, 많은 팀플레이스에 대한 처리와 하나의 팀플레이스에 대한 처리로 해결이 나눠짐
• 통합적으로 많은 수의 요청에 대한 처리 해결로 해결할 수 있도록 변경
• 기존 방식은 진행 플로우를 따라가기 힘들어서 더 간결하고 이해하기 쉬운 해결 방법 필요하여 변경 고려

변경시 고려할 점

배포 대기큐에서 작업을 가져오는 주기

1. 대기큐가 안비어있으면 계속 처리를 하기

• 바로 생각나는 간단한 구현이 애매함
  • 2번 방법보다는 구현의 복잡도가 있어보임
  • 자료조사 & 공부 해보고 구현 가능할것같으면 해도 좋을 것 같음
• 2번 방법보다는 바로바로 업데이트가 되야하는 경우 업데이트가 더 빠르게 진행이 됨
  • 하지만 요청이 많은 경우 마찬가지로 신규생성 팀에 대해서는 따로 처리 필요할 수 있음
  • 신규생성에서 바로 안보인다면 서비스에 대한 첫인상에 영향을 미치는거고 사용자를 잡아두기 불리해짐

2. 일정 주기별로 (10 ~ 20분) 배포 처리

• 가능한 이유 : 어차피 calendar application (client)에서 매번 새롭게 요청을 하는게 아님
• 클라이언트마다 다르지만 주로 1시간 주기로 요청하기도 하고 1일 주기로 요청하기도 한다고
  • 따라서 우리 서버에서 매번 실시간으로 업데이트를 보장해 줄 필요 없음
  • 어차피 우리가 실시가 해도 클라이언트에서 안가져감
• 구현이 좀 더 편하고 간단함
  • 위의 1번 방식보다 스케줄링을 통해서 쉽게 구현 가능
• 최초 배포(팀플레이스 최초 생성 등)시에 바로 업데이트를 하기 위해서는 해당 케이스들은 따로 처리 필요
  • 해당 부분에서는 구현의 복잡도가 높아짐

업데이트큐에서 꺼내서 작업을 할 스레드 수 고려해보기 (1개로도 충분할까 추가적으로 multi-thread 필요할까)

• 일단 지금수준에서는 1개도 충분하지 않을까 생각중

주의사항

팀플레이스 초기 생성 또는 url초기 조회등 아직 생성/배포되고 있는 ics파일이 없는 경우 대기큐로 이동이 아닌 바로 생성을 해야할 수 있음 해당 조건에 대해서 더 생각 + 구현 시 고려