nGrinder로 로컬환경 서버에 부하 테스트하기(feat. 회원가입 api)

🔎 신규 회원 가입 이벤트를 선정한 이유

신규 회원 가입 이벤트를 실행하는 것은 대부분의 핀테크 회사에서 하는 이벤트이기 때문에 신규 회원 가입 이벤트로 선정하게 되었다.

 

🔎  기대하는 목표

이 이벤트로 인해 발생하는 트래픽 문제를 처리해보고,  좀 더 효율적인 방법을 찾아보고 싶다.

또한 트래픽을 처리하는 과정을 글로 작성함으로써, 개발 직군의 모든 분들에게 유의미한 정보를 제공하고 싶다.

 

 

그럼 출발해보자!!

 

 

🔎 nGrinder로 부하 테스트 해보기

nGrinder로 로컬환경에서 요청이 잘 가는지 테스트 해보려고 한다. 회원가입을 하는 API를 테스트 하고자 한다.

 

 

참고로 로컬 환경에서 테스트 하기 위해선, URL 입력란에 localhost가 아닌 127.0.0.1을 입력해 주어야 Invalid Input에러가 발생하지 않는다.

 

127.0.0.1에 포트번호까지 포함해서, 127.0.0.1:8080을 입력해주어야 한다.(포트 번호까지 같이 입력해주어야 한다.)

 

회원가입 하는 api를 호출하는데 성공했다.

지표를 분석해보자..!!

Total Vusers : 테스트한 유저 수

TPS : 초당 트랜잭션 개수(Transaction Per Second)
Peak TPS : 최고점 TPS

Mean Test Time : 개별 테스트 시간, 작성한 스크립트의 @Test 함수의 평균 수행시간을 의미한다.

Executed Tests : 실행한 테스트 수

Successful Tests : 성공한 테스트 수

Errors : 에러 발생 수

Run time : 실행 시간

 

test함수는 다음과 같다.

 

🔨  따로 공부한 부분

QPS : Query Per Second

QPS가 급격하게 증가하면 데이터베이스가 더 많은 트랜잭션을 처리해야 하기 때문에, CPU를 포함한 리소스 사용량도 급증하게 된다.

 

QPS가 증가하면 어떠한 문제가 발생하는가?

CPU 사용량 급증, 병목 현상, IO 및 메모리 사용량 증가, Lock 및 Deadlock 와 같은 문제들이 발생할 수 있다.

 

QPS가 증가함으로 인해 발생하는 DB CPU 증가 문제를 어떻게 해결할것인가?

다음과 같은 방법이 존재한다.

(1) 쿼리 최적화 - 쿼리 분석, 복잡한 조인 최소화, 배치 처리

(2) 인덱스 튜닝 - 적절한 인덱스 설계, 과도한 인덱스 제거

(3) 데이터베이스 샤딩 - 수평분할(DB 트래픽 분산하기)

(4) 캐싱 - 캐싱 레이어 추가, DB 쿼리 결과 캐싱

(5) 데이터베이스 클러스터링 및 리플리케이션 - 읽기 전용 서버 추가, 로드 밸런싱

(6) DBMS 업그레이드

 

🔎  쿼리문 DB 반영이 잘 되는지 확인

nGrinder를 실행한 후, 쿼리문이 잘 날라가는지 확인해보았다.

쿼리문이 훨훨 잘 날아간다. 😘

 

DB에 저장이 잘 되었는지 확인!

 

계정이 중복되서 저장되는 문제 발생🚫

 

 

🔎  로그인 중복 문제 해결하기

이 문제를 해결하고자 중복된 계정을 확인하는 로직을 추가해주었다.

아래 코드는 회원 가입시 사용하는 로직이다.

public Long createMember(final MemberCreateRequest request) {

        Member member = request.toEntity();

        if(checkAlreadyExistedUser(member)) {
            throw new AlreadyExistedUserException();
        }
        
        return memberRepository.save(member).getId();
    }

 

아래 코드는 유저의 이메일이 DB에 이미 존재하는지 확인하는 로직이다.

private boolean checkAlreadyExistedUser(Member member) {
    return memberRepository.findByEmail(member.getEmail()).isPresent();
}

 

postman으로 결과가 잘 반영이 되었는지 확인해보자

 

첫번째 API 요청하기

 

두번째 API 요청하기

 

🔎  nGrinder로 회원가입 요청시 발생하는 문제

기존에 nGrinder에 사용한 script는 동일한 계정으로 회원가입 api를 호출해주는 방식이였다.

회원가입 중복을 방지하기 위해 로직을 추가해주었으므로, nGrinder를 통한 api호출은 첫번째 api 호출만 성공한 후, 나머지 api 호출을 실패하게 될 것이다.

 

nGrinder Test결과

 

 

🔎  nGrinder 회원가입 요청시 발생하는 문제 해결하기

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

/**
* 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 test
	public static HTTPRequest request
	public static Map<String, String> headers = [:]
	public static String body = "{\n  \"email\": \"abc@abc.com\",\n  \"password\": \"abc123\",\n  \"name\": \"abc\"\n}"
	public static List<Cookie> cookies = []

	@BeforeProcess
	public static void beforeProcess() {
		HTTPRequestControl.setConnectionTimeout(300000)
		test = new GTest(1, "127.0.0.1")
		request = new HTTPRequest()

		// Set header data
		headers.put("Content-Type", "application/json")
		grinder.logger.info("before process.")
	}

	@BeforeThread
	public void beforeThread() {
		test.record(this, "test")
		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")
	}

	@Test
	public void test() {
		HTTPResponse response = request.POST("http://127.0.0.1:8080/api/members", body.getBytes())

		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 static String body = "{\n  \"email\": \"abc@abc.com\",\n  \"password\": \"abc123\",\n  \"name\": \"abc\"\n}"

 

이 부분을 test메서드를 호출할 때마다 변경되는 임의의 값으로 적용시켜주자!

 

UUID를 사용해 아래와 같이 test코드를 변경해주었다.

@Test
public void test() {
	
	String uniqueEmail = "user" + UUID.randomUUID().toString() + "@example.com";
	String uniqueName = "user" + UUID.randomUUID().toString();
	String uniquePassword = UUID.randomUUID().toString(); // 간단한 무작위 문자열 생성

	String body = String.format("{\"email\": \"%s\", \"name\": \"%s\", \"password\": \"%s\"}", uniqueEmail, uniqueName, uniquePassword);

	HTTPResponse response = request.POST("http://127.0.0.1:8080/api/members", body.getBytes())

	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))
	}
}

 

🔎 nGrinder로 테스트가 잘 실행되는지 확인하기

계정을 확인해주는 로직 하나만 추가했을 뿐인데, TPS가 267 ➡ 110으로 떨어지게 되었다.

 

회원 가입을 하기 위한 매번의 쿼리 요청마다 가입하고자 하는 계정에 대한 유저의 존재여부를 파악하기 위해 select 쿼리문을 날려주고 있다.

 

로컬 환경에서 nGrinder로 스트레스 테스트해보기 완료..!