🛠️ [refactor] 출석 요청 응답 지연 개선

[binary-ho]

🛠️ 리팩토링이 필요한 부분

테스트 결과 출석 과정에서 강의 정보를 가져오는 상황과 동일하게, 출석 또한 응답 시간을 줄이면 좋겠다는 판단이 들었다.
출석 요청에서 DB 커넥션은 두 상황에서 일어난다.

1. 출석하기 위해 DB에서 "수강신청"정보를 가져온다.
   여기서 수강생은 맞는지, 수업은 열려있는지 확인 가능하다.
2. 각종 검증 이후, DB에 출석 객체를 저장한다.

1. 수강신청 정보 캐시 활용

1번 사항은 이미 수강생 캐싱이 되어 있어서, 그걸 활용하면 될 것 같다!
캐싱을 도입할 때 함께 활용했으면 더 좋았을 것 같다.
그리고 테스트 결과에 따라 2번 사항도 응답 시간을 줄여볼 수 있으면 좋을 것 같다.

도입 이후 14.725초에서 6.481초로 줄어들었다.

2. 저장 부하 줄이기

처음에는 부하를 줄이기 위해 큐 같은 곳에 출석 데이터들을 저장해서 n초마다 polling해 한번에 여러 데이터를 저장하려 했다.
분명히 이런 방식은 분명 DB의 부하를 줄여줄 수 있다.

하지만,

1. 저장에 실패한 데이터의 로깅이나 추적이 어렵다.
2. 이벤트 비동기 처리시 스레드 풀을 기본 SimpleAsyncTaskExecutor에서 ThreadPoolTaskExecutor로 변경하면,
   스레드 풀 사이즈와 큐 사이즈를 조절할 수 있는데, 적절하게 활용하면 구현하려는 기능과 비슷한 효과를 낼 수도 있을 것 같다.
   요청이 몰려도 결국 큐에서 대기하게 된다.

그리고, 더 중요한 것은 응답 지연을 줄이는 것이라고 생각했다.
따라서 위에서 언급한 복잡한 insert를 구현하지 않고, 이벤트를 발행해서 응답 지연을 줄이겠다.

문제는 최근 출석 조회 기능인데, (#117 )
스레드 풀 사이즈의 문제로 유저 출석이 밀리게 되는 경우 제대로 출석 여부를 확인하기 어려울 수 있다.
예를 들어 실제 출석 이벤트를 발행하고, DB에 저장되는 사이에 유저가 자신의 출석을 확인한다면 어떻게 보여줘야 하는가?
이후 실제로 반영된 것은 어떻게 알 수 있는가?

이 문제를 해결하기 위해 아래와 같은 과정을 따르겠다

1. 출석시 이벤트를 발행하고 빠르게 유저에게 응답해준다.
2. 이때 출석 번호가 일치한다면, 이벤트 발행과 같이 출석 신청을 캐싱한다.
   유저에게는 "출석 시도 중.."과 같이 보여지면 될 것 같다.
3. 이후, 이벤트 처리 과정에서 DB에 데이터를 저장하고, 성공 응답이 오는 경우 캐싱된 출석 신청 데이터에 출석이 반영 되었음을 표시한다.
   -> 유저에게는 "출석 성공"과 같이 보여지면 될 것이다.

☑ Refactoring TODO

• 출석 시도시 수강 여부를 확인할 때, 캐싱된 데이터를 활용
• Async 설정 변경
• 캐싱될 "출석 요청 기록" 객체 생성
• 출석시 이벤트 발행 + 캐싱 구현
• 이벤트 처리 성공시 (DB 저장) 캐싱 데이터 변경 구현