🛠️ [refactor] 인덱싱을 통해 출석 과정에서 학생이 강의 정보를 가져오는 시간 단축

[binary-ho]

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

결국 트래픽이 모이는 타이밍은, 출석 당시이다.
아주 짧은 시간 안에

1. 로그인을 하고 (회원가입 할 수도 있다)
2. 수강 신청 승인되었으며, 현재 OPEN 상태인 자신의 강의를 가져온 다음
3. 출석 번호를 보내어 출석 신청을 한다.

전엔 3번 과정을 줄이기 위해 redis를 이용해 DB 접근을 한번 줄였다.
하지만, 수강 신청 데이터가 4천개일때, 1000명의 회원이 동시에 데이터를 조회하면 11.1830초가 소요 되었다.
그리고, 10만개의 데이터가 있을 때는 1000명 동시 조회시 650건 이상 타임아웃으로 실패하였다.

이번엔 2번 과정에서 시간을 줄이기 위해 강의 정보를 가져오는 과정을 인덱싱을 통해 줄이겠다.

1. 자신의 강의이며
2. 수강 신청이 승인 되었고
3. 현재 OPEN 상태인 강의를 가져와야한다.

처음에는 수강신청 데이터의 컬럼인 학생 id와 승인 여부에 복합 인덱스를 적용하는 것을 고려했으나, 다시 공부해 보니 바보 같은 생각이였다.

왜냐하면, 승인 여부는 단 3개의 종류만 있고, 대부분 "승인"이기 때문에 속도 개선은 극히 작은 대신 용량은 단일 인덱스에 비해 1.5배 늘어났다.

그래서 단일 인덱스로 다시 변경하였고, 자바 동시성 컬렉션을 사용해 직접 성능 차이와 인덱스 용량 테스트 했다.
결론적으로 단일 인덱스를 걸고, 쿼리를 수정했다.

jpa 쿼리에서 그냥 JSQL을 통해 가져왔다. 쿼리를 수정하면서 jpa에 의한 outer join 하나가 줄었고, 사소하지만 바로 원하는 객체로 가져오면서 객체 변환 과정도 줄어들었다.

1만명의 회원 10만개 수강 신청 데이터, 1000건 동시 조회 - 성능이 크게 개선
30초 이상, 650건 이상실패(Time Out) -> 6.4638 초 소요 + 실패 0건

2천명의 회원 4천개의 수강 신청 데이터, 1000건 동시 조회 - 약 4배 정도의 성능 개선이 있었다.
11.1830초 -> 2.9257초
(물론 RDS의 상태에 따라 차이가 있는 정확도가 떨어지는 측정)

자세한 과정은 PR에 적겠다. -> #58

리팩토링 작업 브랜치

feature/enrollment_indexing

☑ Refactoring TODO

• Enrollment Info 테이블에 인덱싱
• 학생이 출석할 강의를 가져올 때 Lecture를 가져오도록 쿼리 변경
• Lecture Service의 Student Open Lecture를 가져오는 메서드 수정