feat: create index and jpa optimization

[O0oO0Oo]

이슈 개요

다음 설정을 통해 성능 개선

• 인덱스
• DynamicUpdate
• Batch insert, update
• Connection Pool #41

1. 인덱스 설정

멀티 모듈로 분리하면서 다음과 같은 구조가 되어 기존의 엔티티끼리의 매핑이 사라졌다.

modules : common, saga-orchestration, messaging-adapter ...

           +------ Business : 회사 ----...
           |
           +------ ReservableItem : 예약 아이템 ----...
           |
modules  <-+------ Wallet, Payment : 결제 ----...
           |
           +------ Reservation : 예약 기록 ----...
           |
           +------ User : 유저 ----...

외래키의 경우 자동적으로 인덱스가 생성되지만 위의 멀티 모듈의 경우 엔티티끼리의 매핑이 사라져 Long xxxxId 로 대체하였고, 해당 필드에 대해 인덱스를 직접 설정해야 한다.

예를 들어 유저가 예약을 할 때 이전의 예약 기록을 바탕으로 한명의 유저가 동일한 아이템에 대해 n 개 이상 구매하지 못하게 하는 기능이 있다.

이때 복합 인덱스를 {userId, itemId} 설정한다면 인덱스 레인지 스캔을 사용하여 빠르게 조회가 가능하기에 인덱스를 적절히 만드는것은 중요하다.

Grafana - table scan 인 select scan 을 줄여야 한다.

Grafana - 3 초 이상 걸리는 슬로우 쿼리 발생

Grafana - read-rnd-next : table scan 마다 증가 - 줄여야 한다.

2. DynamicUpdate 설정

2.1 Update 쿼리를 보고 DynamicUpdate 엔티티 클래스에 설정

3. batch insert, update 처리

3.1 Reservation 저장 시 TSID 를 사용하는 pk 를 검증하기 위해 Select 쿼리가 나가는 것

insert 는 batch 로 동작하지만, 100개를 넣을때 위의 경우 6번의 batch insert, 100 번의 reservation id 조회가 발생한다.

3.2 Update 쿼리가 배치로 동작을 안함

3.3 Payment 의 batch insert 를 위한 pk 를 IDENTITY 에서 직접 생성 TSID 로 변경

4. 커넥션 풀 수정

41 로 이동

재현 단계

1. 인덱스 생성

Wallet 의 userId 인덱스 생성

생성 전 생성 후

Wallet 외에도 Reservation, Payment 에 인덱스 생성

Grafana 모니터링 인덱스 생성 전,

Grafana 모니터링 인덱스 생성 후

• 첫번째 그림 : Select scan 은 table scan 을 말한다.
• 두번째 그림 : Slow queries 는 3초 이상 걸리는 쿼리를 말한다.
• 세번째 그림 : read_rnd_next 는 table scan, read_next, read_key 는 인덱스를 사용함

같은 10,000 의 요청을 보냈을때, full table scan 이 줄어들고 인덱스를 사용하며, slow query 가 사라졌다

2. DynamicUpdate 설정

설정 전

설정 후

• reservableTime 의 경우 20~30배 가량 개선되었다.
• 테스트라 reservation 의 레코드가 없다, reservation 의 경우 레코드가 증가함에 따라 조회 시간이 증가할 것이다.
• DynamicUpdate 설정 시 Batch update 가 적용되지 않는 문제

3. batch insert, update

• 모두 수정 완료.
• Payment 의 경우 예약할 때마다 결제가 이뤄지기 때문에 Insert 가 필수로 발생한다. 따라서 IDENTITY 에서 TSID 로 변경을 해주었다.

4. 커넥션 풀 수정

• [x] #41

예상 동작

1. 인덱스로 인한 성능 향상
2. 설정들로 인한 최적화

실제 동작

1. 인덱스로 인한 성능 향상
2. 설정들로 인한 최적화

• 최종 Throughput : 1026.6/sec

추가 정보

• DynamicUpdate 설정 시 Batch update 가 적용되지 않는 문제
• Jpa 2차 캐시는 추후 검토 후 도입