[TECH] 서버 API 성능개선기(2)

[티끌] 티끌 서버 API 성능개선기(2)

안녕하세요 티플의 백엔드 개발자 김유정입니다 :)

저번 글에 이어서 오늘은 테스트 스크립트를 작성하고, 티끌 앱에서 발생하는 N+1 문제를 해결하여 성능을 측정하려 합니다.

---

👩‍💻 테스트 스크립트 작성

1. ngrinder을 먼저 실행합니다.

 

java -Djava.io.tmpdir=/Users/kimyujeong/.ngrinder/lib -jar ngrinder-controller-3.5.8.war —port=8300

 

 

2. 부하 스크립트를 작성합니다.

 

import static net.grinder.script.Grinder.grinder
import static org.junit.Assert.*
import static org.hamcrest.Matchers.*
import net.grinder.script.GTest
import net.grinder.script.Grinder
import net.grinder.scriptengine.groovy.junit.GrinderRunner
import net.grinder.scriptengine.groovy.junit.annotation.BeforeProcess
import net.grinder.scriptengine.groovy.junit.annotation.BeforeThread
// import static net.grinder.util.GrinderUtils.* // You can use this if you're using nGrinder after 3.2.3
import org.junit.Before
import org.junit.BeforeClass
import org.junit.Test
import org.junit.runner.RunWith

import org.ngrinder.http.HTTPRequest
import org.ngrinder.http.HTTPRequestControl
import org.ngrinder.http.HTTPResponse
import org.ngrinder.http.cookie.Cookie
import org.ngrinder.http.cookie.CookieManager

import groovy.json.JsonSlurper
import java.util.Random
import groovy.json.JsonOutput

/**
* A simple example using the HTTP plugin that shows the retrieval of a single page via HTTP.
*
* This script is automatically generated by ngrinder.
*
* @author admin
*/
@RunWith(GrinderRunner)
class TestRunner {
	public static GTest test1 // accessToken 얻기
	public static GTest test2 // 
	public static HTTPRequest request
	public static Map<String, String> headers = [:]
	public static Map<String, Object> params = [:]
	public static List<Cookie> cookies = []
	

	@BeforeProcess
	public static void beforeProcess() {
		HTTPRequestControl.setConnectionTimeout(300000)
		test1 = new GTest(1, "POST /login/extraInfo/{id} with accountId")
		test2 = new GTest(2, "GET /participate/challenge/list with token")
		
		request = new HTTPRequest()
		grinder.logger.info("before process.")
	}

	@BeforeThread
	public void beforeThread() {
		test1.record(this, "test1")
		test2.record(this, "test2")
		
		grinder.statistics.delayReports = true
		grinder.logger.info("before thread.")
	}
	

	@Before
	public void before() {
		request.setHeaders(headers)
		CookieManager.addCookies(cookies)
		grinder.logger.info("before. init headers and cookies")
	}

	private String accessToken
	
	
	@Test
	public void test1() {
		List<Integer> idList = [...]
		Random random = new Random()
		int randomIndex = random.nextInt(idList.size())
		int id = idList[randomIndex]
	
		def slurper = new JsonSlurper()
		def toJSON = { slurper.parseText(it) }

		HTTPResponse response = request.POST("http://{ip주소}/login/extraInfo/" + id)

		def body = response.getBody(toJSON);
		
		accessToken = body.result.accessToken

		if (response.statusCode == 301 || response.statusCode == 302) {
			grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", response.statusCode)
		} else {
			assertThat(response.statusCode, is(200))
		}
	}
	

	@Test
	public void test2() {
		headers["X-ACCESS-TOKEN"] = accessToken
		request.setHeaders(headers)
		
		HTTPResponse response = request.GET("http://{ip주소}/participate/challenge/list")

		if (response.statusCode == 301 || response.statusCode == 302) {
			grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", response.statusCode)
		} else {
			assertThat(response.statusCode, is(200))
		}
	}
}

 

groovy언어는 자바 언어와 비슷해서 구글링하면서 작성하면 쉽게 작성할 수 있습니다!

 

필자는 홈화면에서 (1)'사용자가 참여하고 있는 챌린지 리스트 조회' API에 대해서 테스트를 진행하였습니다.

 

QA를 진행하면서 홈화면의 (1) api에서 지연이 발생한 것을 확인하였습니다. 사용자가 앱을 사용하는 데는 문제가 없지만, 사용성을 향상시키기 위해 쿼리를 개선해보고, 이전과 비교해보려 합니다.

 

먼저, 테스트 스크립트에 대해서 간다히 설명해보겠습니다.

 

사용자를 구분하기 위해, '/login/extraInfo/{id} ' 엔드포인트로 JWT 토큰을 받아와서 accessToken 전역변수에 저장했습니다. 

이 값을 통해 앞으로 '/participate/challenge/list'에서 사용자가 참여한 리스트를 조회할 것입니다.. 

 

test1의 idList는 사용자의 고유 id값을 리스트로 저장했습니다. 티끌에서 사용하는 '/login/extraInfo/{id}' URL은 카카오 로그인을 마친 사용자가 추가 정보를 입력하기 위해 사용하는 URL입니다. 따라서 사용자의 고유 id값이 필요하며, 이를 idList에 일일히 저장하였습니다. 총 50명의 사용자의 값을 저장하였는데, 사용자가 더 많아진다면 이 방법은 적절하지 않을 수 있습니다.

 

---

👩‍💻 N+1 문제란?

JPA를 사용해 봤다면, N+1문제에 대해 들어봤을 것입니다.

 

대부분의 경우 x대일 연관관계에서 즉시 로딩으로 설정하면 항상 테이블에서 조인이 발생하기 때문에 성능 튜닝이 어려워집니다. 따라서 연관관계를 지연 로딩으로 설정하는 것이 좋습니다.

기본값이 즉시 로딩이기 때문에, 필요에 따라 지연 로딩으로 수정해야 합니다.

 

@Getter
@Entity
@NoArgsConstructor
@AllArgsConstructor
public class ParticipateChallenge {

	...
    
    	@ManyToOne(fetch = FetchType.LAZY)
    	@JoinColumn(name = "account_id")
    	private Account account;
    
	@ManyToOne(fetch = FetchType.LAZY)
    	@JoinColumn(name = "challenge_id")
    	private Challenge challenge;
    
    	...
    
   }

 

 

사용자가 참여하고 있는 챌린지 리스트 정보를 조회하기 위한 코드는 다음과 같습니다.

 

public List<ParticipateChallengeRes> getParticipateChallengeListByAccountId(CustomUserDetails customUserDetails) {
        Account account = accountRepository.findByEmailAndStatus(customUserDetails.getEmail(), Status.VALID)
                .orElseThrow(() -> new CustomException(CustomExceptionStatus.ACCOUNT_NOT_FOUND));

        List<ParticipateChallenge> list = participateChallengeRepository.findByAccountId(account.getId());
        List<ParticipateChallengeRes> collect = list.stream().map(pc -> new ParticipateChallengeRes(pc.getChallenge().getId(), pc.getChallenge().getTitle()))
                .collect(Collectors.toList());
        return collect;
    }

 

ParticipateChallenge 객체를 조회할 때, Challenge 객체는 Proxy 객체로 반환됩니다.

실제로 Challenge의 제목을 가져오는 pc.getChallenge().getTitle() 시점에서, 데이터베이스 조회가 발생합니다.

 

 

지연 로딩(FetchType.LAZY)는 로딩되는 시점에 LAZY 로딩 설정이 되어있는 Challenge 엔티티를 프록시 객체로 가져옵니다.

이후에 실제 객체를 사용하는 시점에 초기화가 이루어지고, 데이터베이스에 쿼리가 나갑니다.

- getChallenge()으로 Challenge를 조회하면 프록시 객체가 조회된다.

- getChallenge().getTitle()으로 챌린지의 필드에 접근할 때 쿼리가 나간다.

 

 

즉, ParticipateChallenge를 조회할 때는 먼저 Proxy로 된 Challenge 객체를 가져오게 됩니다. 그리고 Challenge의 실제 데이터가 필요한 시점에 초기화되며, 데이터베이스에 쿼리가 발생합니다.

이로 인해, 사용자가 참여하고 있는 챌린지의 개수에 따라 총 3개에서 5개까지의 쿼리가 발생할 수 있는 상황입니다.

 

ParticipateChallenge 입장에서 Challenge는 지연로딩으로 프록시 객체로 조회됩니다. 그러나 문제는 API 스펙에서 Challenge 프록시를 초기화할 때마다, 조회된 ParticipateChallenge만큼 추가적인 쿼리가 발생한다는 것입니다. 이것이 바로 N+1 문제이며 조회된 데이터가 많을수록 성능에 영향을 미칠 수 있습니다.

---

👩‍💻 해결방법

다음과 같이 @Query를 통해 fetch join을 사용하여 해결해 보도록 하겠습니다.

 

@Query(value = "select p from ParticipateChallenge p join fetch p.challenge where p.account = :account")

    List<ParticipateChallenge> findAllFetchJoin(Account account);

위 쿼리를 실행하면 한번의 쿼리로 ParticipateChallenge와 Challenge를 함께 가져오는 것을 확인할 수 있습니다.

 

---

👩‍💻 성능 측정

그렇다면 얼마만큼의 성능 향상을 이뤄낼 수 있을까요?

작성한 테스트 스크립트를 실행하여 운영서버에 쿼리 개선 전과 후를 비교해보겠습니다.

 

Agent는 1, Vuser per aget는 50으로 설정하여 테스트를 진행했습니다.

 

쿼리 개선 전

쿼리 개선 후

TPS(Transaction Per Second)는 서버가 초당 처리 할 수 있는 요청의 개수를 나타냅니다. 

쿼리 개선 전과 후를 비교했을 때 88에서 95로, 약 8% 상승했습니다.

 

---

👩‍💻 마치며

서버 성능개선기(2)에 대한 글을 읽어주셔서 감사합니다!
 
이 글을 통해 API 쿼리의 성능을 향상시키고 N+1 문제를 해결함으로써 성능 개선에 실무적인 능력을 향상시킬 수 있는 의미있는 경험이었습니다.

 

다음 글에도 개발을 진행하면서, 티끌에서 고민했던 부분을 풀어내는 글로 찾아오겠습니다.

감사합니다 😄

 

⬇️ 지금 구글 플레이 스토어에서 티끌 다운 받기

https://play.google.com/store/apps/details?id=com.team7.tikkle&hl=ko-KR

📩 Contact : uuuuujeong00000@naver.com
📲 SNS : https://www.instagram.com/may_u_j__