🎨

다사다난 도메인 재설계 - 심화편

생성일

2022/12/20

태그

Spring

MySQL

Refactoring

이 포스팅은 앞의 도메인 구조 우아하게 설계하기 내용에 이어서 작성됩니다.

목차

배경

지난 포스팅에서는 상호 객체간 의존도를 낮추고, 비즈니스 로직을 도메인 객체로 넣어 응집도를 높이는 도메인 재설계를 진행하고 적용해 보았습니다. 이러한 과정에서 비즈니스 로직이 서비스 계층의 레포지토리 메서드에서 도메인 객체 내부로 이동하게 되었고, 대부분의 쿼리를 JPA 기능에 맡기게 되었습니다. 이로 인해 과거에 쿼리 튜닝을 진행했던 쿼리들이 사라지게 되었고, JPA 가 자동으로 만들어주는 새로운 쿼리의 성능을 확인해보고자 하였습니다.

테스트 환경

테스트할 도메인은 재설계를 진행했던 투표 도메인으로 테스트를 진행하였고, 더미 데이터는 쿼리 튜닝을 했던 때와 같은 수로 넣어주었습니다.

•

멤버: 500

•

팀: 1000

•

팀 멤버: 2996

◦

1번 멤버는 테스트 편의상 모든 팀에 참여, 이외 499명의 멤버는 4개의 팀에 참여

•

투표: 30000

◦

각 팀당 30개의 투표 생성

•

투표 항목: 90000

◦

투표당 3개의 투표 항목

•

선택 인원: 180000

◦

투표 항목당 2명 투표

성능 개선이 필요한 부분

투표 기능의 모든 API 에 대해서 불필요한 쿼리나 JOIN문이 있는지 성능 테스트로 확인해 보았습니다.

[투표 성능 테스트]
uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 4148.619320 ms, 쿼리 개수: 124, 쿼리 시간: 2123.705562 ms
uri: '/api/groups/00000002/polls', method: 'POST', 요청 처리 시간: 476.378221 ms, 쿼리 개수: 6, 쿼리 시간: 14.347752 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'GET', 요청 처리 시간: 279.455596 ms, 쿼리 개수: 7, 쿼리 시간: 238.463966 ms
uri: '/api/groups/00000002/polls/ZEdlKskY/items', method: 'GET', 요청 처리 시간: 1295.610065 ms, 쿼리 개수: 6, 쿼리 시간: 1235.628151 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'PUT', 요청 처리 시간: 153.095624 ms, 쿼리 개수: 9, 쿼리 시간: 4.681824 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'PUT', 요청 처리 시간: 28.595276 ms, 쿼리 개수: 8, 쿼리 시간: 4.014231 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'PUT', 요청 처리 시간: 92.646055 ms, 쿼리 개수: 9, 쿼리 시간: 6.505827 ms
uri: '/api/groups/00000002/polls/ZEdlKskY/result', method: 'GET', 요청 처리 시간: 68.598734 ms, 쿼리 개수: 8, 쿼리 시간: 2.851347 ms
uri: '/api/groups/00000002/polls/ZEdlKskY/close', method: 'PATCH', 요청 처리 시간: 39.222127 ms, 쿼리 개수: 5, 쿼리 시간: 1.428766 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'DELETE', 요청 처리 시간: 173.856499 ms, 쿼리 개수: 10, 쿼리 시간: 136.763482 ms
Shell
복사

fetch join 을 사용하지 않았기에, N+1 을 예상은 했지만 첫 API인 투표 목록 조회 API부터 만나니까 씁쓸한 기분이 들었습니다. 게다가 124개 쿼리의 개수를 보아하니 단순한 N+1 의 문제가 아니었습니다.

현재 테이블의 연관 관계는 위의 ERD 에서 확인할 수 있듯이, 투표 - 투표 항목 - 선택인원으로 이어지는 1:N:N^2 의 관계입니다.

@Query("select p from Poll p where p.menu.teamCode.code = :teamCode")
List<Poll> findAllByTeamCode(@Param("teamCode") String teamCode);
Java
복사

List<Poll> 스트림을 돌면서 poll.getPollItems() 을 호출하고, 반환된 List<PollItem> 에서 스트림을 돌면서 pollItem.getSelectMembers().keySet() 을 호출하는 로직입니다. 이에 따라 poll 에서 poll item 을 불러올 때 N + 1, poll item 에서 select member 를 불러올 때 N + 1 이 발생하는 로직이었습니다. 이를 수식으로 표현하면 다음과 같습니다.

N(M + 1) + 1 = N * M + N + 1

N 은 투표 데이터의 개수, M 은 투표 항목 데이터의 개수입니다. 계산을 하면, 30 * 3 + 30 + 1 에 기본 검증 로직 쿼리 3개(멤버 조회, 팀 조회, 멤버 팀 소속 확인)를 합쳐 총 124개가 발생한 것입니다. 차라리 테스트에서 쿼리 개수를 잘못 세기를 바랬지만, 불필요하게 정확한 계산을 해버렸습니다.

Fetch Join 사용

이를 해결하기 위해서, 보편적으로 N + 1 을 해결하는 방법인 fetch join 을 가장 먼저 적용해 보았습니다.

투표를 불러올 때 연관 관계를 맺고있는 투표 항목을 join fetch로 불러오면 JOIN을 이용한 하나의 쿼리로 투표와 투표 항목을 불러올 수 있고, 이 때 투표 항목을 불러오면서 선택 인원도 함께 JOIN을 이용한 쿼리로 불러오도록 하였습니다.

@Query("select p "
        + "from Poll p "
        + "join fetch p.pollItems.values pi "
        + "join fetch pi.selectMembers "
        + "where p.menu.teamCode.code = :teamCode")
List<Poll> findAllByTeamCode(@Param("teamCode") String teamCode);
Java
복사

쿼리의 결과와 성능을 살펴보면 다음과 같습니다.

위의 쿼리처럼 inner join 을 두 번 걸어 poll 에서 select member 까지 두 세대에 걸친 데이터를 한번에 가져옵니다.

uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 3009.070515 ms, 쿼리 개수: 4, 쿼리 시간: 1097.437801 ms
Java
복사

성능을 보면 쿼리 시간이 약 50% 가량 개선된 것을 알 수 있고, 쿼리 개수도 해결한 것을 확인할 수 있습니다.

하지만 두 테이블 모두 inner join 으로 조회하면 서비스 정책 상 문제가 발생합니다. 투표를 생성할 때에는 투표 항목은 필수 이지만, 아무도 투표를 하지 않았다면 투표 항목에 대한 선택 인원은 없을 때가 있습니다. 투표를 처음 생성했을 때처럼 말이죠. 이렇게 된다면 두 번째 inner join 인 select member JOIN 문에서 연관된 데이터가 없기때문에 투표는 존재하는데 아무 데이터도 가져오지 못하는 상황이 발생합니다.

그래서 두 번째 JOIN 문인 inner join 을 left outer join 으로 바꾸어, 투표가 아직 진행되지 않았더라도 데이터를 가져올 수 있도록 하였습니다.

@Query("select p "
        + "from Poll p "
        + "join fetch p.pollItems.values pi "
        + "left join fetch pi.selectMembers "
        + "where p.menu.teamCode.code = :teamCode")
List<Poll> findAllByTeamCode(@Param("teamCode") String teamCode);
Java
복사

select member 테이블을 left outer join 으로 바꾸고 다시 테스트를 돌려 보면,

uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 3127.241793 ms, 쿼리 개수: 4, 쿼리 시간: 2025.988033 ms
Java
복사

쿼리 개수는 동일하지만 inner join 대신 left outer join 을 하게 되어 쿼리 처리하는 시간이 아무래도 더 오래 걸릴 수 밖에 없었습니다. 그리고 시간 뿐만 아니라 다른 치명적인 문제도 발생하였습니다.

투표 더미 데이터는 30개인데, 연관된 투표 항목인 3개까지 가져오다보니 투표에 대한 데이터가 90개가 되었습니다. 즉 중복된 투표가 3개씩 생긴 것입니다. 여기서 만약 선택 인원이 있다면, 그 선택 인원 데이터만큼 더 중복된 투표 객체가 생기게 됩니다. 이에 따라 투표에 대해 distinct 옵션을 사용하기로 하였습니다.

@Query("select distinct p "
        + "from Poll p "
        + "join fetch p.pollItems.values pi "
        + "left join fetch pi.selectMembers "
        + "where p.menu.teamCode.code = :teamCode")
List<Poll> findAllByTeamCode(@Param("teamCode") String teamCode);
Java
복사

중복으로 존재하던 투표 객체를 distinct 로 제거하여 데이터가 정확하게 계산된 것을 확인할 수 있었습니다.

uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 1394.154046 ms, 쿼리 개수: 4, 쿼리 시간: 638.585152 ms
Java
복사

하지만 이러한 @OneToMany 에서 join 을 거는 방식은 고질적인 문제가 있습니다. 아무리 애플리케이션 단에서 중복된 객체에 대해 distinct 를 적용한다지만 쿼리를 실행하고 데이터를 가져올 때에는 결국 중복된 데이터가 존재할 수 밖에 없습니다.

DB 에서 조회할 때에는 결국 중복된 데이터가 존재하고, 객체로 매핑 시에 중복된 데이터를 distinct 하는 것이었습니다. 결과적으로 어플리케이션에 불필요한 부하가 발생할 수 밖에 없기에, 다른 방법을 찾아보게 되었습니다.

BatchSize 설정

목록을 조회하는 비즈니스 로직을 스트림을 돌면서 하나씩 꺼내기 보다는 한번에 모든 객체를 벌크 연산으로 조회하는 방식으로 생각해 보았습니다. 이는 BatchSize 옵션을 통해

team_code 로 투표 조회하기

조회한 poll_id 들로 투표 항목 조회하기

조회한 poll_item_id 들로 선택 인원 조회하기 

등 1 + 1 + 1 쿼리로 해결하기로 하였습니다. BatchSize를 적용하면 조회 쿼리에서 in 절을 이용하기 때문에 설정한 개수까지는 하나의 쿼리만을 사용하게 됩니다.

spring:
  jpa:
    properties:
			hibernate:
				default_batch_fetch_size: 100
YAML
복사

uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 3468.259955 ms, 쿼리 개수: 10, 쿼리 시간: 1100.283345 ms
Java
복사

in (?) 으로 가져올 때, 투표 항목을 가져올 때에는 투표 개수가 30개이고, 선택 인원을 가져올 때에는 투표 항목이 3 * 30 총 90개이기때문에 default_batch_fetch_size 를 100 으로 설정하고 결과를 확인해 보았습니다. 예상한 결과는 기본 검증 로직 3개까지 합쳐 총 6개의 쿼리 개수가 발생할 것으로 예상하였는데, 10개가 발생하였습니다. 크나큰 고민을 안고 콘솔로 쿼리를 확인해보니 다음과 같았습니다.

위 쿼리는 ? * 30 을 예상하였지만, ? * 25, ? * 5 두 개로 만들어졌습니다. 예상했던 1 + 1 + 1 으로 쿼리가 만들어지지 않고 쪼개져서 쿼리가 만들어진 것입니다. 쿼리 개수가 총 10개가 발생한 과정은 알게 되었고, 이렇게 되는 원인을 찾아보기로 하였습니다.

이에 관해서 batch size 를 이용할 때에 prepared statement 에서는 (?) 의 개수를 미리 정해놓고, 쿼리를 미리 만들어 캐싱을 사용한다고 합니다. 이러한 방식을 사용하는 이유는, 몇 개의 (?) 를 해야할 지 모르는 상황에서 (?) 의 갯수만큼 동적으로 계속 만들다보면 성능상 불리하기 때문입니다. 그래서 default_batch_fetch_size 의 개수가 100 이라면, (?) 개수가 1~10, 100, 50, 25, 12 이렇게 14개의 쿼리를 미리 만들어 캐싱하여 사용합니다. 그리고 위의 예시에서처럼 in (?) 절로 가져와야 할 데이터가 30개라면 ? * 25 인거 하나, ? * 5 인거 하나 총 2개의 쿼리가 발생하게 된 것입니다. default_batch_fetch_size 로 설정한 수가 아무리 높아도, /2 를 계속하기때문에 미리 만들어놓는 in (?) 절의 개수는 log N 만큼 증가합니다. 그렇다면 이 방식 말고 다른 방식은 어떤게 더 있을까요?

spring:
  jpa:
    properties:
			hibernate:
				batch_fetch_style: padded
YAML
복사

batch_fetch_style 에는 legacy, padded, dynamic 이 있고, 앞서 언급한 방식이 기본값인 legacy 입니다. dynamic 방식은 성능 최적화를 위한 캐싱, 즉 미리 쿼리를 만들지 않고 그냥 동적으로 만드는 방식입니다. 저희가 설정한 padded 는 legacy 와 유사합니다. 성능 최적화를 위해 쿼리를 캐싱하는 것 까지는 같으나 legacy 는 데이터보다 적은 수의 (?) 를 사용하는 반면, padded 는 데이터보다 많은 수의 (?) 를 사용합니다. 위의 예시처럼 데이터가 30개라면 ? * 50 인 쿼리를 가져와서 사용합니다.

그렇다면 남는 ?*20개에는 어떤 데이터를 바인딩할까요?

in (?) 절로 가져올 데이터의 바인딩 파라미터인 poll_id 는 31~60 까지였습니다. 그래서 나머지 20개에는 첫 데이터인 31을 더미로 20를 넣는 것을 확인할 수 있습니다. 이렇게 가져온 20개의 데이터는 distinct 와 유사한 로직으로 같은 객체로 인식하여 구분하는 것 같습니다.

WARN  uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 2671.510999 ms, 쿼리 개수: 6, 쿼리 시간: 733.745199 ms
Java
복사

저희 프로젝트에서는 서비스 특성상 in (?) 절에 들어갈 데이터의 개수가 자주 변하기때문에 dynamic 보다는 padded 를 이용하기로 하였습니다.

둘을 합쳐볼까?

WARN  uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 2798.888614 ms, 쿼리 개수: 5, 쿼리 시간: 1208.678814 ms
Java
복사

poll item 까지는 join fetch 로 가져오고, 선택 인원은 in (?) 절로 가져오도록 해보았습니다. 하지만 결국 join 문에서 발생하는 비용이 더 크다는 것을 알게 되었습니다.

반정규화로 조회 쿼리 성능 개선

모두 in (?) 절로 처리하는 1 + 1 + 1 쿼리가 가장 성능이 좋았지만, 733 ms 는 아무래도 사용자가 답답함을 느끼기에는 충분한 시간이라고 생각했습니다. 그래서 이를 서비스 로직으로 개선할 수 있는 방법들을 생각해 보았습니다.

페이징으로 처리

현재 저희 프로젝트에서는 투표, 약속잡기 등의 기능들의 목록을 불러올 때에는 페이징 처리를 하지 않고 한번에 모든 목록을 가져옵니다. 이에 모든 데이터를 가져오다보니, 오래 걸린다고 판단하여 페이징을 하는 것에 대해 생각해 보았습니다. 하지만 이는 백엔드 팀원들 뿐만 아니라 프론트엔드 팀원들과도 의견을 나누고, 화면 디자인과 세부 사항까지 정해야 합니다. 그리고 무엇보다도 투표, 약속잡기 등의 수보다는 투표 항목, 선택 인원 등 한번에 가져오는 구조상의 문제라고 생각하여 일단 보류하였습니다.

정규화에 집착하지 말자!

다른 방법을 생각해보다가 투표 목록을 조회하는 데에 어쩌다가 모든 선택 인원까지 가져오게 되었을까 라는 의문이 생겼습니다.

모든 선택 인원까지 가져오게 된 이유는 투표 진행 인원을 세기 위해서 였습니다. 투표 목록 조회 로직에서 투표를 진행한 사람의 수(count)를 계산하기 위해, 투표 선택 항목과 선택 인원의 정보까지 모두 조회해오고 있었습니다. 결국 투표 목록 조회 시, 투표 항목을 조회하는 이유는 선택 인원을 조회하기 위해, 선택 인원을 조회하는 이유는 투표를 진행한 사람의 수를 계산하기 위해서 입니다. 이러한 문제점을 파악한 뒤, 굳이 투표 항목, 선택 인원 등 모든 데이터를 가져올 필요가 없다고 생각하였습니다.

이에 따라 투표 테이블에 count 라는 컬럼을 추가하고, 멤버가 투표를 진행하면 count 를 올리는 로직을 만들기로 하였습니다.

투표의 count 는 연관 관계에 있는 선택 인원의 수를 계산한 값과 일치하기때문에, 정보상 중복된다고 볼 수 있습니다. 하지만 서비스를 이용하는 사용자의 경험에 중점을 둘 때, 조회 성능에 부담이 되는 것보다는, 정규화를 조금 포기하고 조회 성능을 높이는 것이 적절하다고 생각하여 반정규화를 하기로 결정하였습니다.

public void doPoll(Long memberId, Map<Long, String> data) {
    validateStatusOpen();

    pollItems.doPoll(memberId, data);
    this.selectedCount = updateSelectedCount();
}
Java
복사

pollItems.doPoll() 에서는 투표를 진행하고, updateSelectedCount() 에서는 투표를 진행한 인원이 재선택한 인원인지 처음 투표하는 인원인지 확인한 뒤 처음 투표하는 인원이라면 selectedCount 를 1 추가합니다.이후 커밋 시점에 JPA 는 dirty checking 을 통해 count 를 update 하는 쿼리를 날립니다. 그리고 투표 목록을 조회할 때는, 단순히 Poll 테이블에 저장된 column 중 하나이기때문에 다른 로직 없이 count 조회가 가능합니다.

uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 130.732916 ms, 쿼리 개수: 4, 쿼리 시간: 15.434725 ms
YAML
복사

요청 처리 시간, 쿼리 개수, 쿼리 시간 등 모든 지표에서 선명하게 성능이 개선된 것을 확인할 수 있습니다.

단점은?

그렇다면 이러한 반정규화를 진행했을 때 어떤 단점이 있을까요?

추가 update 로직

앞서 언급한대로, 새로운 멤버가 투표를 진행하면 count 수가 변경되어, 선택 인원 insert 쿼리와 함께 투표 update 쿼리가 추가로 발생합니다.

하지만 서비스 로직 상 재투표는 있지만, 투표 취소라는 개념은 없기에 update 쿼리가 자주 발생하지 않을 것이라 판단했고, 무엇보다도 투표, 투표 항목 데이터가 많으면 많을 수록 성능 상 큰 차이를 보일 것이라고 생각했습니다.

이에 대해 테스트를 진행해보았고, 실제로 더미 데이터를 각 팀 별로 투표를 30 → 60, 투표 별로 투표 항목을 3 → 5로 변경하고 측정하였을 때 성능 측정을 진행하면 다음과 같은 결과를 보였습니다.

// 반정규화 진행 전
요청 처리 시간: 2157.065458 ms, 쿼리 개수: 10, 쿼리 시간: 1168.891168 ms

// 반정규화 진행 후
요청 처리 시간: 163.363125 ms, 쿼리 개수: 4, 쿼리 시간: 24.577707 ms
YAML
복사

이와 더불어, 조회 비중이 투표 비중보다 더 높기때문에 update 추가 쿼리가 나가는 단점보다는 조회 성능의 효율의 장점이 더 크다고 판단하였습니다.

동시성 문제

처음에는 동시성 문제가 발생할 것을 인지하지 못했습니다. 하지만 MySQL 과 멀티 쓰레드 환경에 대해 조금 더 공부하다 보니 동시성 문제가 발생할 수 있는 것을 인지하게 되었습니다.

현재의 로직은 조회와 더불어 수정하는 로직이 추가되어 여러 트랜잭션에서 동시에 접근할 경우 정합성 문제 뿐만 아니라 심하면 데드락까지 발생할 수 있습니다. 이에 따라 해당 API 는 동시성 문제 해결이 필수적이었고 이는 동시성 문제를 방지해보자(비관적 락, 낙관적 락) 포스팅에서 해결하는 과정을 담았습니다.

인덱스 추가

uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'GET', 요청 처리 시간: 279.455596 ms, 쿼리 개수: 7, 쿼리 시간: 238.463966 ms
YAML
복사

@Query("SELECT p FROM Poll p WHERE p.menu.code.code = :code")
Optional<Poll> findByCode(@Param("code") String code);
Java
복사

현재 저희 로직에서는 투표 조회 시 code를 사용하고 있습니다. code의 경우 각 투표의 고유한 식별자이기 때문에 카디널리티가 매우 높습니다. 그래서 저희는 투표의 식별자인 code에만 인덱스를 추가하기로 결정했습니다.

uri: '/api/groups/00000002/polls/qoZ9oDrz', method: 'GET', 요청 처리 시간: 52.782685 ms, 쿼리 개수: 4, 쿼리 시간: 5.310012 ms
YAML
복사

개선 전/후를 비교해보니 전체적으로 처리 시간이 확연히 개선된 모습을 보였습니다.

Unique 는?

팀, 투표, 약속잡기와 같은 저희 프로젝트의 도메인들은 모두 랜덤으로 생성한 코드를 가지고 있고, 이 코드를 자동 채번 방식으로 생성한 id 대신 url 식별자로 사용합니다. 해당 코드는 8자리의 소문자, 대문자, 숫자 조합으로 구성되고 단순 계산하면 62^8 개의 가지수를 가지기때문에, 중복될 가능성이 거의 없습니다. 이에 따라 DB 제약 조건으로 unique 를 넣는 방법도 생각해 보았습니다.

이에 따라 성능 개선 초기에는 unique 제약 조건을 추가하여 인덱스로 사용하였습니다. 하지만 Real MySQL 8.0 의 인덱스 챕터를 공부하고 나니 생각했던 것과 달랐습니다.

먼저 unique 와 인덱스에서 사용되는 실행 계획은 다른데 조회할 값이 하나라면 크게 차이는 없다고 합니다.

위의 이미지는 unique 제약조건으로 실행 계획을 확인한 이미지이고, 앞서 인덱스를 만들어 실행 계획을 확인한 이미지와 비교해 보면 type 컬럼의 const 와 ref 에서 차이가 있습니다. 이 둘은 PK, unique 와 같이 하나가 확실한 키로 조회하는지, 이외의 index 로 조회하는지의 차이입니다. 그래서 ref로 조회할 컬럼의 카디널리티가 높아 하나의 값만 검색하는 경우라면, 성능에서는 거의 차이가 없다고 합니다.

그리고 유니크 인덱스를 사용하면 새로운 레코드가 insert 되거나 해당 컬럼의 값이 변경되는 경우, 중복된 값이 있는지 없는지 체크하는 과정이 한 단계 더 필요하여 느립니다. 저희가 생성한 코드는 62^8 의 확률, 약 1/210조 이기때문에 굳이 중복된 값을 확인할 필요가 없다고 판단하였습니다.

또한 유니크 인덱스에서 중복된 값을 체크할 때는 읽기 잠금, 쓰기 할 때는 쓰기 잠금이 걸리고, 이 과정에서 예상치 못한 데드락이 발생할 수 있습니다.

이러한 이유들때문에 unique 제약 조건을 떼고 다시 인덱스를 만들어 사용하였습니다.

결과

위의 내용으로 개선한 뒤 다시 테스트를 돌려 본 결과입니다.

[투표 성능 테스트]
// before
uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 4148.619320 ms, 쿼리 개수: 124, 쿼리 시간: 2123.705562 ms
uri: '/api/groups/00000002/polls', method: 'POST', 요청 처리 시간: 476.378221 ms, 쿼리 개수: 6, 쿼리 시간: 14.347752 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'GET', 요청 처리 시간: 279.455596 ms, 쿼리 개수: 7, 쿼리 시간: 238.463966 ms
uri: '/api/groups/00000002/polls/ZEdlKskY/items', method: 'GET', 요청 처리 시간: 1295.610065 ms, 쿼리 개수: 6, 쿼리 시간: 1235.628151 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'PUT', 요청 처리 시간: 153.095624 ms, 쿼리 개수: 9, 쿼리 시간: 4.681824 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'PUT', 요청 처리 시간: 28.595276 ms, 쿼리 개수: 8, 쿼리 시간: 4.014231 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'PUT', 요청 처리 시간: 92.646055 ms, 쿼리 개수: 9, 쿼리 시간: 6.505827 ms
uri: '/api/groups/00000002/polls/ZEdlKskY/result', method: 'GET', 요청 처리 시간: 68.598734 ms, 쿼리 개수: 8, 쿼리 시간: 2.851347 ms
uri: '/api/groups/00000002/polls/ZEdlKskY/close', method: 'PATCH', 요청 처리 시간: 39.222127 ms, 쿼리 개수: 5, 쿼리 시간: 1.428766 ms
uri: '/api/groups/00000002/polls/ZEdlKskY', method: 'DELETE', 요청 처리 시간: 173.856499 ms, 쿼리 개수: 10, 쿼리 시간: 136.763482 ms

// after
uri: '/api/groups/00000002/polls', method: 'GET', 요청 처리 시간: 130.732916 ms, 쿼리 개수: 4, 쿼리 시간: 15.434725 ms
uri: '/api/groups/00000002/polls', method: 'POST', 요청 처리 시간: 92.129583 ms, 쿼리 개수: 7, 쿼리 시간: 6.798292 ms
uri: '/api/groups/00000002/polls/rFdex7qg', method: 'GET', 요청 처리 시간: 52.782685 ms, 쿼리 개수: 4, 쿼리 시간: 5.310012 ms
uri: '/api/groups/00000002/polls/rFdex7qg/items', method: 'GET', 요청 처리 시간: 23.762750 ms, 쿼리 개수: 6, 쿼리 시간: 1.143833 ms
uri: '/api/groups/00000002/polls/rFdex7qg', method: 'PUT', 요청 처리 시간: 87.143708 ms, 쿼리 개수: 9, 쿼리 시간: 7.733458 ms
uri: '/api/groups/00000002/polls/rFdex7qg', method: 'PUT', 요청 처리 시간: 12.067208 ms, 쿼리 개수: 6, 쿼리 시간: 0.728125 ms
uri: '/api/groups/00000002/polls/rFdex7qg', method: 'PUT', 요청 처리 시간: 16.042375 ms, 쿼리 개수: 9, 쿼리 시간: 1.707665 ms
uri: '/api/groups/00000002/polls/rFdex7qg/result', method: 'GET', 요청 처리 시간: 21.225875 ms, 쿼리 개수: 7, 쿼리 시간: 0.516291 ms
uri: '/api/groups/00000002/polls/rFdex7qg/close', method: 'PATCH', 요청 처리 시간: 17.626834 ms, 쿼리 개수: 6, 쿼리 시간: 1.552708 ms
uri: '/api/groups/00000002/polls/rFdex7qg', method: 'DELETE', 요청 처리 시간: 18.157208 ms, 쿼리 개수: 10, 쿼리 시간: 1.686958 ms
Java
복사

각각의 평균을 표로 정리해 보았습니다.

	쿼리 개수	쿼리 시간
before	19.2	376.3
after	6.8	40.5

개선 전과 비교하여 쿼리 개수는 약 3배, 쿼리 시간은 약 10배 정도 개선된 것을 확인할 수 있습니다.