🚋

쿼리 튜닝 여행

생성일

2022/10/02

태그

Spring

JPA

MySQL

배경

저희 프로젝트의 서비스 로직 개발과 배포가 어느정도 마무리 되었습니다. 열심히 테이블을 설계하고 코드를 작성했지만, 쿼리의 성능과 인덱스에 대한 정리는 하나도 되어 있지 않은 상태였습니다. 무엇보다 어떤 쿼리가 성능이 잘 나오고, 어떤 쿼리가 성능이 잘 나오지 않는지에 대한 정보가 없었습니다. 마침 스프린트 5의 요구 사항 중 쿼리를 확인하고 공유하는 것이었기때문에 쿼리에 대한 실태를 조사하고 개선하고자 하였습니다.

도메인 정보

간단하게 저희 프로젝트 도메인의 ERD 그림을 그려보았습니다.

실제 컬럼은 더 많지만 쿼리에서 주로 사용되는 컬럼만 넣었습니다. 저희 서비스는 ‘그룹’ 을 기반으로 하다보니, 멤버와 팀이 대부분의 도메인에 연관 관계 설정이 되어 있는 것을 알 수 있습니다. 투표 도메인은 1:N:N^2 의 형태(투표:투표 항목:투표 결과)로 테이블을 설계하였고, 약속잡기 도메인은 1:N 의 형태로 설계된 상태입니다.

더미 데이터 정보

기존 테스트에 사용하던 데이터 수로는 쿼리 상태가 아무리 나빠도 눈에 잘 띄지 않기때문에, 어느정도의 부하를 위해 더미 데이터를 삽입하였습니다.

•

멤버: 500

•

팀: 1000

•

팀 멤버: 2996

◦

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

•

투표: 30000

◦

각 팀당 30개의 투표 생성

•

투표 항목: 90000

◦

투표당 3개의 투표 항목

•

투표 결과: 180000

◦

투표 항목당 2명 투표

•

약속잡기: 30000

◦

각 팀당 30개의 약속잡기 생성

•

약속 가능 시간: 960000

◦

하루 4시간, 4일 선택

◦

하나의 row 가 30분이기때문에 4 * 2 * 4 * 30000

멤버와 팀이 적은 이유

실제 서비스를 가정한 더미 데이터이기때문에 한 팀에 수만명이 들어간 상황은 고려하지 않기로 하였습니다. 이에 따라 멤버와 팀의 수는 더미 데이터용으로 필요한 최소한의 수를 삽입하였습니다.

테스트 DB 환경

spring:
	datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:~/perform;MODE=MYSQL;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE
YAML
복사

테스트 DB는 h2로 구성하였습니다. 운영 서버에서 사용하는 MySQL 이면 가장 좋았겠지만, 옵션으로 MODE=MySQL 을 추가하여 쿼리 생성 방식이 MySQL 과 크게 다르지 않아 굳이 docker 환경을 세팅하여 버전을 맞출 필요성을 느끼지 못했습니다. 또한 데이터 저장 방식은 in-memory 대신 디스크에 실제로 쓰는 환경으로 설정하였습니다. in-memory 를 사용하지 않은 이유는 두 가지가 있습니다.

•

실제 환경과 유사하게 만들기 위해  

•

더미 데이터 삽입 방식

앞서 언급한대로, 운영 서버는 MySQL 을 사용하기때문에 in-memory 보다는 disk 쓰기 방식이 더 적절하다고 판단하였습니다. 또한 현재 더미 데이터 삽입 방식은 for 문을 돌면서 JPA 를 이용하여 삽입하기때문에 in-memory 를 사용하면 out of memory 가 발생하였습니다.

테스트 방식

테스트 방식으로는 현재 이용 가능한 모든 API 요청을 보내고 응답을 받는 형태입니다. 이 과정에서 각각 API의 요청 처리 시간, 쿼리 개수, 쿼리 시간을 측정합니다.

•

요청 처리 시간

◦

interceptor 에서부터 측정하였습니다. filter 에서 측정하기보다는 스프링 컨텍스트로 요청이 들어온 이후부터 측정하는 것이 더 적절하다고 판단하였습니다. 서비스 로직 처리 이후 interceptor 에서 응답 로직인 postHandle() 에서 소요 시간을 계산하고 로그로 출력합니다.

•

쿼리 개수

◦

PreparedStatement 에서 executeQuery() 또는 executeUpdate() 와 같은 쿼리 관련 메서드를 실행할 때 AOP 를 이용하여 메서드가 실행된 개수를 측정합니다. 쌓인 쿼리 개수는 interceptor 에서 로그로 출력되고 초기화됩니다.

•

쿼리 시간

◦

쿼리 시간 역시 위의 쿼리 개수와 같이 PreparedStatement 에서 쿼리 관련 메서드가 실행될 때 측정됩니다. 하나의 API 에서 발생한 쿼리가 여러개라면 각각의 쿼리마다 측정하여 누적합니다. 누적된 쿼리 시간은 interceptor 에서 로그로 출력되고 초기화됩니다.

위와 같이 측정 대상을 설정한 뒤 테스트를 돌려 보았습니다.

====== 더미 데이터 추가 start ======
더미 데이터 추가 시간: 54.592000
====== 성능 테스트 start ======
[팀 & 멤버 성능 테스트]
uri: '/api/groups', method: 'POST', 요청 처리 시간: 793.211833 ms, 쿼리 개수: 3, 쿼리 시간: 25.323343 ms
uri: '/api/groups/vsvRh4dC/invitation', method: 'POST', 요청 처리 시간: 173.947751 ms, 쿼리 개수: 3, 쿼리 시간: 27.280218 ms
uri: '/api/groups/in/cPUfheEe', method: 'GET', 요청 처리 시간: 79.536458 ms, 쿼리 개수: 3, 쿼리 시간: 0.972297 ms
uri: '/api/groups/in/cPUfheEe', method: 'POST', 요청 처리 시간: 33.633054 ms, 쿼리 개수: 5, 쿼리 시간: 12.546666 ms
uri: '/api/groups', method: 'GET', 요청 처리 시간: 6699.832034 ms, 쿼리 개수: 1002, 쿼리 시간: 308.643746 ms
uri: '/api/groups/vsvRh4dC/members', method: 'GET', 요청 처리 시간: 262.447658 ms, 쿼리 개수: 5, 쿼리 시간: 48.182770 ms
uri: '/api/groups/default', method: 'GET', 요청 처리 시간: 28.185598 ms, 쿼리 개수: 2, 쿼리 시간: 14.102089 ms
uri: '/api/groups/out/vsvRh4dC', method: 'DELETE', 요청 처리 시간: 113.129437 ms, 쿼리 개수: 3, 쿼리 시간: 28.408655 ms
[약속잡기 성능 테스트]
uri: '/api/groups/code1/appointments', method: 'POST', 요청 처리 시간: 418.059500 ms, 쿼리 개수: 5, 쿼리 시간: 15.378402 ms
uri: '/api/groups/code1/appointments', method: 'GET', 요청 처리 시간: 1043.489309 ms, 쿼리 개수: 3, 쿼리 시간: 932.268314 ms
uri: '/api/groups/code1/appointments/K5HWZoJ0', method: 'GET', 요청 처리 시간: 24.979690 ms, 쿼리 개수: 4, 쿼리 시간: 0.557007 ms
uri: '/api/groups/code1/appointments/K5HWZoJ0', method: 'PUT', 요청 처리 시간: 5575.911353 ms, 쿼리 개수: 8, 쿼리 시간: 5305.979040 ms
uri: '/api/groups/code1/appointments/K5HWZoJ0', method: 'PUT', 요청 처리 시간: 3576.951226 ms, 쿼리 개수: 11, 쿼리 시간: 3511.593918 ms
uri: '/api/groups/code1/appointments/K5HWZoJ0', method: 'PUT', 요청 처리 시간: 3804.372983 ms, 쿼리 개수: 8, 쿼리 시간: 3720.919665 ms
uri: '/api/groups/code1/appointments/K5HWZoJ0/recommendation', method: 'GET', 요청 처리 시간: 3020.213268 ms, 쿼리 개수: 9, 쿼리 시간: 2897.717361 ms
uri: '/api/groups/code1/appointments/K5HWZoJ0/close', method: 'PATCH', 요청 처리 시간: 34.156669 ms, 쿼리 개수: 6, 쿼리 시간: 4.635747 ms
uri: '/api/groups/code1/appointments/K5HWZoJ0', method: 'DELETE', 요청 처리 시간: 2457.826639 ms, 쿼리 개수: 38, 쿼리 시간: 2421.609196 ms
[투표 성능 테스트]
uri: '/api/groups/code2/polls', method: 'GET', 요청 처리 시간: 8237.231234 ms, 쿼리 개수: 4, 쿼리 시간: 8102.479655 ms
uri: '/api/groups/code2/polls', method: 'POST', 요청 처리 시간: 297.653430 ms, 쿼리 개수: 7, 쿼리 시간: 6.980373 ms
uri: '/api/groups/code2/polls/Rvt2DhpS', method: 'GET', 요청 처리 시간: 1246.616450 ms, 쿼리 개수: 4, 쿼리 시간: 1217.621209 ms
uri: '/api/groups/code2/polls/Rvt2DhpS/items', method: 'GET', 요청 처리 시간: 49.178156 ms, 쿼리 개수: 7, 쿼리 시간: 4.100732 ms
uri: '/api/groups/code2/polls/Rvt2DhpS', method: 'PUT', 요청 처리 시간: 90.324972 ms, 쿼리 개수: 11, 쿼리 시간: 1.794396 ms
uri: '/api/groups/code2/polls/Rvt2DhpS', method: 'PUT', 요청 처리 시간: 913.480279 ms, 쿼리 개수: 13, 쿼리 시간: 881.921218 ms
uri: '/api/groups/code2/polls/Rvt2DhpS', method: 'PUT', 요청 처리 시간: 789.068342 ms, 쿼리 개수: 12, 쿼리 시간: 762.083852 ms
uri: '/api/groups/code2/polls/Rvt2DhpS/result', method: 'GET', 요청 처리 시간: 660.966086 ms, 쿼리 개수: 8, 쿼리 시간: 624.053410 ms
uri: '/api/groups/code2/polls/Rvt2DhpS/close', method: 'PATCH', 요청 처리 시간: 22.404780 ms, 쿼리 개수: 6, 쿼리 시간: 6.660639 ms
uri: '/api/groups/code2/polls/Rvt2DhpS', method: 'DELETE', 요청 처리 시간: 682.985367 ms, 쿼리 개수: 14, 쿼리 시간: 641.630130 ms
YAML
복사

한 눈에 봐도 대부분의 API 에서 문제가 발생하는 것을 알 수 있습니다. 하나씩 뜯어보면서 개선해 보도록 하겠습니다.

문제 1 - 불필요한 조인

uri: '/api/groups/vsvRh4dC/members', method: 'GET', 요청 처리 시간: 262.447658 ms, 쿼리 개수: 5, 쿼리 시간: 48.182770 ms
Java
복사

위의 API 는 그룹에 속한 멤버 목록 조회 API 입니다. 해당 API 에서는 다음과 같은 4개의 로직이 수행됩니다.

팀 코드로 팀 조회

요청한 멤버가 그룹에 속해있는지 팀멤버 확인

1번에서 조회한 팀 id 로 팀멤버 목록 조회

조회한 팀멤버 목록의 for 문을 돌면서 Member 조회

•

이 로직으로 인해 N+1 문제도 함께 발생합니다. 팀당 2명의 멤버가 있기에 2개의 쿼리가 발생하였습니다. 이 문제는 아래에서 다루겠습니다.

왼쪽이 2번 로직으로 인해 발생한 쿼리이고, 오른쪽이 3번 로직으로 인해 발생한 쿼리입니다. 이상하게도 left outer join 이 나타나고 있습니다. join 문은 비용이 많이 소요되는 쿼리 중 하나입니다.

외래키로 테이블에 존재하는 id 로 조회를 했는데 왜 join 문이 발생한 것일까요? 해당 로직을 수행하는 메서드를 살펴보았습니다.

// 2번 로직(TeamMemberRepository#existsByTeamIdAndMemberId)
boolean existsByTeamIdAndMemberId(Long teamId, Long memberId);

// 3번 로직(TeamMemberRepository#findAllByTeamId)
List<TeamMember> findAllByTeamId(Long teamId);
Java
복사

해당 쿼리는 위의 JPA 메서드로 생성한 쿼리입니다. 현재 DB 상에서 직접 참조로 맺어져있는 그룹, 팀멤버, 멤버 테이블은 외래키가 서로의 id 로 저장되어 있지만 애플리케이션 상 객체 엔티티는 서로의 객체로 연관관계를 맺고 있습니다. 이에 따라 JPQL과 SQL을 헷갈려 위와 같은 메서드로 작성하는 경우가 생겼습니다. TeamMember 라는 entity가 갖고있는 객체는 team_id가 아닌 team이고, 따라서 team이 갖고 있는 id 를 기반으로 조회하고자 위와 같은 쿼리가 나가게 되는 것입니다. 조금 더 쉽게 생각하면 findAllByTeamName 과 유사한 로직인 것입니다.

개선 방법은 간단하게, entity를 기반으로 조회하도록 변경하는 것입니다.

// TeamMemberRepository#existsByTeamAndMember
boolean existsByTeamAndMember(Team team, Member member);

// TeamMemberRepository#findAllByTeam
List<TeamMember> findAllByTeam(Team team);
Java
복사

불필요한 join 쿼리 없이 저희가 의도한대로 곧바로 where 절로 접근할 수 있게 되었습니다. 개선된 쿼리의 실행 소요 시간도 확인해 보겠습니다.

uri: '/api/groups/zev3uwpO/members', method: 'GET', 요청 처리 시간: 18.582039 ms, 쿼리 개수: 4, 쿼리 시간: 0.983328 ms
SQL
복사

개선 전과 후 쿼리 소요 시간의 차이는 약 50배(48ms → 0.98ms)인데요, 이는 join 할 데이터가 많아지면 많아질수록 차이는 더 크게 날 것으로 예상합니다.

문제 2 - N+1 문제

uri: '/api/groups', method: 'GET', 요청 처리 시간: 6699.832034 ms, 쿼리 개수: 1002, 쿼리 시간: 308.643746 ms
Java
복사

위의 API 는 소속된 그룹 목록을 조회하는 API 입니다. 정확하게 N+1 문제가 발생한 것을 짐작할 수 있습니다.

DBMS 툴을 이용해 직접 쿼리문을 만들어 조회할 때는 N+1 문제가 발생하기 힘듭니다. 사람이 직접 치니 굳이 N+1 만큼의 쿼리를 만들어 낼 필요가 없기 때문입니다. 하지만 저희 모락 프로젝트는 JPA를 사용하고, JPA 에 의해 자동화된 쿼리문들을 사용하면 필연적으로 발생하는 문제입니다. 물론 EAGER 옵션 또는 JdbcTemplate 으로 N+1 문제가 발생하지 않도록 할 수 있지만, JPA 의 영속성 컨텍스트를 이용하며 얻는 효율이 더 크기때문에, 다른 방법으로 해결책을 찾아야 합니다.

위의 API 에서는 아래의 3가지 로직이 수행됩니다.

Member 조회 (1번) 

select * from member where id = ?

Member가 속해 있는 TeamMember 목록을 조회 (1번) 

select * from team_member where member_id = ?

TeamMember 목록에서 각각의 Team을 조회 

select * from team where id = ? * 1000

3번 로직을 수행하면서 아직 프록시 객체로 있던 TeamMember 객체의 Team 에 대해 for 문을 돌면서 조회를 요청하여 1000번의 쿼리가 발생한 것입니다.

fetch join

이 문제는 TeamMember 를 조회할 때 team 에 대한 정보까지 프로젝션으로 가져와 JPA 에서 Team 객체에 매핑하기만 하면 해결할 수 있고, 이는 fetch join 으로 구현이 가능합니다.

// TeamMemberRepository#findAllByMember
@Query("SELECT tm FROM TeamMember tm JOIN FETCH tm.team WHERE tm.member = :member")
List<TeamMember> findAllByMember(@Param("member") Member member);
Java
복사

위와 같이 JPQL 을 직접 작성하여 fetch join 을 설정하였습니다. Team 에 join 을 걸고, TeamMember 데이터를 조회하면 조회 시 Team 에 대한 정보를 inner join 으로 함께 가져와 N+1 문제를 해결할 수 있습니다.

@EntityGraph 는?

@EntityGraph 을 사용하면 query 를 작성하지 않고도 해당 N+1 문제를 해결할 수도 있습니다.

@EntityGraph(attributePaths = {"team"})
List<TeamMember> findAllByMember(Member member);
Java
복사

하지만 @EntityGraph 로 로직을 구성하면 EAGER 가 기본이기때문에, 이미지와 같이 left outer join 으로 연관 객체를 가져옵니다. 이에 따라 @EntityGraph 보다는 inner join 을 사용하는 fetch join 을 사용하는 것으로 결정하였습니다.

언제나 left outer join 이 나쁜 것은 아닙니다. inner join 은 연관된 객체가 있을 때만 모든 객체를 가져오기 때문에, 연관된 객체가 없다면 아무것도 가져오지 않습니다. 이에 비즈니스 정책에 따라 적절한 해결 방법을 선택해야 합니다.

문제 3 - 단건 업데이트

uri: '/api/groups/code1/appointments/K5HWZoJ0', method: 'DELETE', 요청 처리 시간: 2457.826639 ms, 쿼리 개수: 38, 쿼리 시간: 2421.609196 ms
Java
복사

약속잡기 삭제 API 입니다. 해당 API 의 로직은 다음과 같습니다.

멤버, 그룹 조회

멤버가 그룹에 속하는지 확인 

약속잡기 조회 

3번의 약속잡기에 해당하는 약속 가능 시간 삭제

약속잡기 삭제

4번 로직에서는 한번에 삭제하기 위해 deleteAllByAppointment 를 활용하였습니다. 이에 따라 4번 로직에서 약속 가능 시간 삭제 시, delete from 약속_가능_시간 where 약속잡기_id=? 처럼 한 번에 삭제할 것으로 예상하였고, 예상되는 쿼리의 개수는 6개였지만 38개가 발생했습니다. 왜일까요? 확인해보기 위해 테스트를 다시 돌려 쿼리를 확인해 보았습니다.

JPA 의 delete 는 update 와 함께 쓰기 지연 저장소에 저장되는 대표적인 쿼리 중 하나입니다. 그리고 delete 메서드는 호출될 때 삭제할 데이터의 id 를 찾기위해 추가적인 조회 쿼리가 한 건 더 발생합니다. 위의 쿼리가 이에 해당하는 조회 쿼리입니다.

그러면 1건이 추가되어야 하는데, 왜 삭제할 데이터 수만큼의 쿼리가 추가로 발생했는지 확인하기 위해 해당 메서드를 찾아보았습니다.

// SimpleJpaRepository

	@Override
	@Transactional
	public void deleteAll(Iterable<? extends T> entities) {

		Assert.notNull(entities, "Entities must not be null!");

		for (T entity : entities) {
			delete(entity);
		}
	}
Java
복사

저희 프로젝트는 Repository 인터페이스를 사용하고 있고, 새롭게 작성한 JPA 메서드가 호출되면 SimpleJpaRepository 의 메서드가 호출됩니다. 이 레포지토리에서 deleteAll 은 위와 같이 구현되어 있는데, 해당 메서드의 delete 메서드가 for 반복문을 돌면서 삭제하고 있습니다. 이에 따라 삭제할 데이터의 수만큼 쿼리의 개수가 추가가 되었던 것입니다.

하나씩 삭제중,,,

이에 따라 4번 로직에서만 삭제할 id 를 위한 조회 쿼리 1 + 각각의 선택 가능 시간 삭제 쿼리 32, 총 33 건이 발생하였습니다.

이를 해결하기 위해서는, deleteAllByAppointment 에서 삭제할 쿼리가 각각 나가는 것이 아니라 Appointment 와 일치하는 약속 가능 시간 데이터 모두를 삭제하는 쿼리인 where appointment_id=? 가 만들어지도록 해야 합니다.

batch_size 설정

spring:
  jpa:
    properties:
      hibernate:
				jdbc:
          batch_size: 1000
YAML
복사

의도한 쿼리 방식인 벌크 연산을 실행하기 위해서는 설정 파일에서 batch_size 를 지정하여 사용할 수 있습니다. 해당 옵션으로 설정하면 deleteAll 과 같은 벌크 연산 쿼리에서 하나의 쿼리만 발생할 수 있도록 합니다.

uri: '/api/groups/code1/appointments/ZnV6dgZQ', method: 'DELETE', 요청 처리 시간: 23.783192 ms, 쿼리 개수: 7, 쿼리 시간: 1.168170 ms
Java
복사

삭제할 데이터를 조회하는 쿼리 1건 + 데이터 삭제 쿼리 1건 총 2건이 되었습니다.

콘솔에는 삭제할 데이터 N 건이 쿼리로 찍힙니다. 하지만 실제로 connection 으로 연결하여 보내는 쿼리는 1개입니다. 쓰기 지연 저장소에 저장 후 connection 을 연결하여 보낼 때, batch 처리하여 보내기 때문입니다.

주의점!
식별자 생성 방식이 identity 일 때는 saveAll 과 같은 삽입 벌크 연산 쿼리에서는 동작하지 않습니다. 해당 식별자 생성 방식은 실제 데이터를 insert하기 전까지 식별자를 알 수 없습니다. JPA 는 이에 대해 쓰기 지연 저장소에 해당 insert 문을 저장하지 않고, 바로 id 를 확인한 뒤 저장하고 영속화시킵니다. 만약 save 시에 id 를 알아도, JPA 의 save 관련 메서드는 merge 를 통해 id 가 DB 에 존재하여 update 하는 쿼리인지, 없는 id 여서 insert 해야하는지 확인하는 과정을 거칩니다. 이에 따라 saveAll 에서는 해당 설정이 유효하지 않습니다.

직접 JPQL 쿼리 생성

조금 더 직관적인 방식은 JPQL 로 쿼리를 생성하는 방식입니다.

@Modifying
@Query("DELETE FROM AvailableTime at WHERE at.appointment = :appointment")
void deleteAllByAppointment(@Param("appointment") Appointment appointment);
Java
복사

기존에 의도한대로 해당 약속잡기에 연관된 약속 가능 시간을 쿼리 하나로 생성하여 보낼 수 있습니다.

이 방식은 SimpleJpaRepository 에 구현된 deleteAll 메서드를 이용하지 않기에 조회 쿼리도 발생하지 않습니다.

uri: '/api/groups/code1/appointments/bs7yRVR3', method: 'DELETE', 요청 처리 시간: 16.464075 ms, 쿼리 개수: 6, 쿼리 시간: 0.737359 ms
Java
복사

해당 방식은 직관적이기도 하고, 쿼리 하나로 해결할 수 있는 장점이 있지만, 쓰기 지연 저장소 내의 쿼리가 모두 flush 가 되어 영속성 컨텍스트를 효율적으로 이용할 수 없다는 단점도 있습니다.

하지만 저희 프로젝트에서는 해당 로직 이후 약속 잡기를 삭제하는 로직만 존재하기때문에 더이상 영속성 컨텍스트를 이용할 필요가 없기때문에 직접 JPQL 쿼리를 생성하는 방법을 선택하였습니다.

개선 결과

위의 개선점을 모두 적용하고 다시 테스트를 돌려 보았습니다.

====== 더미 데이터 추가 start ======
더미 데이터 추가 시간: 50.185000
====== 성능 테스트 start ======
[팀 & 멤버 성능 테스트]
uri: '/api/groups', method: 'POST', 요청 처리 시간: 422.165153 ms, 쿼리 개수: 3, 쿼리 시간: 5.968536 ms
uri: '/api/groups/zev3uwpO/invitation', method: 'POST', 요청 처리 시간: 82.152895 ms, 쿼리 개수: 4, 쿼리 시간: 3.153968 ms
uri: '/api/groups/in/5umvRypX', method: 'GET', 요청 처리 시간: 62.108510 ms, 쿼리 개수: 4, 쿼리 시간: 0.621550 ms
uri: '/api/groups/in/5umvRypX', method: 'POST', 요청 처리 시간: 24.226459 ms, 쿼리 개수: 5, 쿼리 시간: 0.683008 ms
uri: '/api/groups', method: 'GET', 요청 처리 시간: 3307.468467 ms, 쿼리 개수: 2, 쿼리 시간: 30.841726 ms
uri: '/api/groups/zev3uwpO/members', method: 'GET', 요청 처리 시간: 18.582039 ms, 쿼리 개수: 4, 쿼리 시간: 0.983328 ms
uri: '/api/groups/default', method: 'GET', 요청 처리 시간: 19.181545 ms, 쿼리 개수: 3, 쿼리 시간: 0.585053 ms
uri: '/api/groups/out/zev3uwpO', method: 'DELETE', 요청 처리 시간: 44.477059 ms, 쿼리 개수: 4, 쿼리 시간: 2.583553 ms
[약속잡기 성능 테스트]
uri: '/api/groups/code1/appointments', method: 'POST', 요청 처리 시간: 303.981287 ms, 쿼리 개수: 5, 쿼리 시간: 8.983311 ms
uri: '/api/groups/code1/appointments', method: 'GET', 요청 처리 시간: 119.911311 ms, 쿼리 개수: 4, 쿼리 시간: 10.794138 ms
uri: '/api/groups/code1/appointments/dNDYqbwJ', method: 'GET', 요청 처리 시간: 18.493118 ms, 쿼리 개수: 4, 쿼리 시간: 0.404567 ms
uri: '/api/groups/code1/appointments/dNDYqbwJ', method: 'PUT', 요청 처리 시간: 324.034765 ms, 쿼리 개수: 8, 쿼리 시간: 58.265959 ms
uri: '/api/groups/code1/appointments/dNDYqbwJ', method: 'PUT', 요청 처리 시간: 53.977844 ms, 쿼리 개수: 8, 쿼리 시간: 21.545514 ms
uri: '/api/groups/code1/appointments/dNDYqbwJ', method: 'PUT', 요청 처리 시간: 20.860797 ms, 쿼리 개수: 8, 쿼리 시간: 1.450300 ms
uri: '/api/groups/code1/appointments/dNDYqbwJ/recommendation', method: 'GET', 요청 처리 시간: 133.874309 ms, 쿼리 개수: 6, 쿼리 시간: 3.223964 ms
uri: '/api/groups/code1/appointments/dNDYqbwJ/close', method: 'PATCH', 요청 처리 시간: 28.091637 ms, 쿼리 개수: 6, 쿼리 시간: 4.466337 ms
uri: '/api/groups/code1/appointments/dNDYqbwJ', method: 'DELETE', 요청 처리 시간: 35.646286 ms, 쿼리 개수: 6, 쿼리 시간: 2.481070 ms
[투표 성능 테스트]
uri: '/api/groups/code2/polls', method: 'GET', 요청 처리 시간: 149.432977 ms, 쿼리 개수: 4, 쿼리 시간: 8.202648 ms
uri: '/api/groups/code2/polls', method: 'POST', 요청 처리 시간: 155.059860 ms, 쿼리 개수: 7, 쿼리 시간: 5.191256 ms
uri: '/api/groups/code2/polls/4pAWaj7K', method: 'GET', 요청 처리 시간: 19.399535 ms, 쿼리 개수: 4, 쿼리 시간: 0.521628 ms
uri: '/api/groups/code2/polls/4pAWaj7K/items', method: 'GET', 요청 처리 시간: 33.917882 ms, 쿼리 개수: 6, 쿼리 시간: 0.785569 ms
uri: '/api/groups/code2/polls/4pAWaj7K', method: 'PUT', 요청 처리 시간: 70.055507 ms, 쿼리 개수: 7, 쿼리 시간: 2.187549 ms
uri: '/api/groups/code2/polls/4pAWaj7K', method: 'PUT', 요청 처리 시간: 78.458004 ms, 쿼리 개수: 9, 쿼리 시간: 11.105353 ms
uri: '/api/groups/code2/polls/4pAWaj7K', method: 'PUT', 요청 처리 시간: 25.122040 ms, 쿼리 개수: 8, 쿼리 시간: 1.730743 ms
uri: '/api/groups/code2/polls/4pAWaj7K/result', method: 'GET', 요청 처리 시간: 20.945816 ms, 쿼리 개수: 6, 쿼리 시간: 0.908424 ms
uri: '/api/groups/code2/polls/4pAWaj7K/close', method: 'PATCH', 요청 처리 시간: 43.715838 ms, 쿼리 개수: 6, 쿼리 시간: 26.530988 ms
uri: '/api/groups/code2/polls/4pAWaj7K', method: 'DELETE', 요청 처리 시간: 26.516415 ms, 쿼리 개수: 13, 쿼리 시간: 1.701012 ms
YAML
복사

대부분의 API 에서 성능이 개선된 것을 확인할 수 있습니다.

개선 전/후 각각 항목의 평균을 계산해보면 다음과 같습니다.

	요청 시간	쿼리 개수	쿼리 시간
개선 전	1522.85	44.59	1166.77
개선 후	208.48	5.7	7.85

요청 시간은 87%, 쿼리 개수는 88%, 쿼리 시간은 148배(퍼센테이지가 무의미) 가량 개선되었습니다.

마무리

fetch join, batch_fetch_size 등을 이용하여 불필요한 쿼리가 발생하는 것을 방지하고 쿼리 성능을 개선해 보았습니다. 사실 개선 수치는 테스트 환경, 더미데이터 수, 개선 전 로직 상태 등 많은 부분에서 영향을 받을 수 있어 크게 유의미하다고 생각하지는 않습니다. 이러한 개선점에서 중요한 것은 어떤 부분에서 문제가 발생할 수 있는지, 어떻게 문제 상황을 인지하고 다시 만들어낼 수 있는지, 어떤 해결 방법들이 있고 서비스 정책에 맞는 최적의 해결책을 적용할 수 있는지라고 생각합니다.

참고

https://techblog.woowahan.com/2695/