개요

e-commerce 대용량 서버 프로젝트가 실제로 트래픽을 받았을 때 성능이 어느정도까지 도달할 수 있는지 nGrinder와 pinpoint 툴을 사용하여 측정해보았습니다. 측정 결과를 통해 병목 원인을 파악해보고 해당 병목을 해결할 수 있는 방안이 무엇인지 찾아보고자 합니다.

상품 목록 보기 API 부하 테스트

테스트 환경

centOS 7.3

서버 사양 : [Compact] 1vCPU, 2GB Mem, 50GB Disk [g1]

VUser : 500 부하 테스트

• nGrinder Report
  

• Pinpoint Report

VUser을 500으로 설정한 후 10분동안 테스트를 진행하였는데, CPU 사용율을 100%를 찍다가 8분이 지나니 서버가 다운되었습니다.

지표

평균 TPS : 662

피크 TPS : 921

CPU Usage : 100%

Errors : 2,674

병목 원인 분석하기

실행 시간의 대부분을 Disk I/O 에서 소모하고 있는 것을 발견했습니다.

성능 최적화 방안 생각하기

Disk I/O를 줄이기 위한 방법으로 캐시를 생각했습니다.

제가 최적화 방법으로 캐시에 대해 자세히 고민한 과정은 Redis로 캐싱하기 (← 바로 가기 클릭) 글에서 자세히 다루었습니다.

쿠폰 발급하기 API 부하 테스트

VUser : 500 부하 테스트

• nGrinder Report

• Pinpoint Report
  

VUser을 500으로 설정한 후 10분동안 테스트를 진행해보니, CPU 사용율이 100%찍은 것을 확인할 수 있었습니다.

지표

평균 TPS : 426

피크 TPS : 538

CPU Usage : 100%

Errors : 0

병목 원인 분석하기

실행시간의 대부분을 getConnection() 메소드에서 소모하고 있는 것으르 확인하였습니다. 스레드가 풀에서 Connection을 받는 시간이 오래 걸리는 것입니다.

성능 최적화 방안 생각하기

getConnection()에서의 실행 시간을 줄이기 위한 방법으로 스케일 아웃을 생각했습니다.

스케일 업이 아닌 스케일 아웃으로 선택한 과정은 서버 성능 높이기(← 바로가기 클릭)글에서 자세히 다루었으며,

nginx를 통해 실제 구현한 과정을 로드밸런서 적용하여 Scale-out 하기(← 바로가기 클릭)글에 정리해두었습니다.

후기

nGrinder로만 파악하려 했다면 어디가 문제였는지 로그파일을 하나하나 찾아보는 등 시간이 매우 걸리는 작업이 필요했을 것입니다. Pinpoint와 같이 사용하여 병목지점이 어디인지 쉽게 찾을 수 있었고 CPU사용률 등의 정보를 그래프로 편리하게 확인할 수 있었습니다. 이 후에는 생각한 성능 최적화 방안을 실제로 구현해보고 그 결과를 분석해보고자 합니다.