nGrinder와 Pinpoint로 성능테스트 및 개선하기 (4) - Scale out

1. 성능 개선 방법

이전 포스팅에서 문제점을 파악했고, 다음과 같은 방법으로 성능을 개선하기로 했다. Scale out를 적용해 TPS를 높여보겠다. 

1. connection pool 크기 확장하기
2. scale out을 통해 트래픽을 분산해 TPS 올리기

2. Scale-out

2.1 Scale-out vs Scale-up

Scale-up은 기존 서버나 시스템에 추가 자원을 투입해 성능을 향상시키는 방법이다. 장점은 비교적 빠르게 성능을 향상 시킬 수 있으나 하드웨어의 업그레이드에 비용이 많이 들고 성능 향상이 제한적이라는 단점이 존재한다.

 

Scale-out은 여러 대의 서버를 추가해 시스템의 성능과 용량을 확장하는 방법이다. 분산 시스템을 통해 여러 서버가 협력해 작업을 처리한다. 따라서 높은 확장성을 제공한다는 장점이 있는데 반해서 시스템의 복잡도가 증가한다는 단점이 있다.

 

현재 KBO-Project의 배포 구조는 WAS(Web Application Server) 서버 1대로 모든 요청을 처리하고 있다.

성능 개선 방법을 Scale-out을 선택했는데 이유는 다음과 같다.

1. 높은 확장성 : 이미 WAS 서버 1대로 성능 한계가 도달했고, 여러 대의 WAS 서버를 추가하면 유연한 확장성을 제공할 수 있다.
2. 비용 : 고성능 하드웨어를 구매하는 것도 저렴한 클라우드 서버를 추가하는 것이 더 효율적이라고 생각했다.
3. 신뢰성 : 단일 서버에서 모든 요청을 처리하는 경우 서버가 다운되면 전체 시스템이 중단되는데 Scale-out에서는 여러 서버가 협력해 요청을 처리하기 때문에 장애가 발생해도 다른 서버들이 처리할 수 있다.

2.2 Scale-out 적용

Scale-out를 적용하기 위해 'WAS 서버 1대([Compact] 2vCPU, 2GB Mem [g1])'와 'Nginx 서버를 1대 ([Compact] 1vCPU, 2GB Mem [g1])' 추가 구매했다. 그리고 Nginx를 로드밸런서로 사용하여 2개의 WAS 서버에 요청을 보내도록 하였다. 이때 사용한 알고리즘은 라운드로빈이다. 서버에서 들어온 요청을 순서대로 돌아가면 배정하는 방식이다.

3. Scale-out 적용 후 테스트

이제 Scale-out을 적용한 후에 이전과 똑같은 조건으로 nGrinder 테스트를 해보자.

 

그 전에 Scale-out을 하기전에 좀 더 정확한 부하를 위해서 모니터링 서버의 스펙을 [Standard] 8vCPU, 16GB Mem[g1]로 올렸다.

그리고 기존과 똑같은 조건으로 nGrinder VUser 300명, agent 1개, 실행시간 1분을 고정시키고, warm up을 설정해 테스트했다.

 

1. Scale-out 적용 이전

TPS는 1,546, Mean Test Time 는 87.09ms이다. 즉, 1대의 서버에서 초당 1546번의 API 요청을 처리할 수 있다.

CPU 사용량은 약 80% 였다.

응답시간은 평균 32ms,최대 795ms가 나왔다.

 

2. Scale-out 적용 이후

해당 테스트의 TPS는 2,817, Mean Test Time 는 55.40ms이다. 즉, 1대의 서버에서 초당 2817번의 API 요청을 처리할 수 있다.

CPU 사용량은 약 최대 44%가 나왔다.

응답시간은 평균 11ms와 최대 413ms가 나왔다.

4. 결론

정리하면 Scale-out을 도입함으로써 다음과 같은 성능 개선을 이루었다.

	Scale-out 이전	Scale-out 이후	개선
TPS	1,546	2,817	82.20% 증가
CPU	80%	44%	45% 감소
평균 응답시간	32ms	11ms	66% 감소
최대 응답시간	795ms	413ms	48% 감소

 

지금까지 nGrinder와 Pinpoint를 통해 성능테스트를 수행하고 병목지점을 찾아보고 개선하는 과정을 거쳤다. 이를 통해서 성능 향상에 대한 접근방법을 익힐 수 있었다. 다음에는 코드레벨을 통해서 내 코드의 성능을 개선해보고 싶다.😃