nGrinder를 사용하여 시스템 성능 한계와 최적 부하 지점 분석

nGrinder를 사용하여 시스템 성능 한계와 최적 부하 지점 분석

nGrinder

📌 서론

지난 글에서는 로컬 환경에서만 테스트를 진행해 봤다. 이제 실제 상용 서버에서 부하 테스트를 진행해 보면서 성능 분석을 해보자.

상용 서버에서 부하 테스트 진행

이번 부하 테스트는 nGrinder를 사용하여 다양한 가상 사용자(VUser) 수를 기반으로 하나의 테스트를 진행함으로써, 시스템의 성능 한계와 최적 부하 지점을 파악하기 위함이다. 동작 시간은 전부 1분으로 고정했다.


(이번 테스트에서 사용한 테스트 스크립트는 이전 글에서 작성한 로그인-마이페이지 조회 스크립트다.)

🔻 로그인-마이페이지 스크립트는 아래 링크에 있다. 🔻

nGrinder를 활용한 성능 테스트 - 기본에서 전략까지

 

현재 상용 서버는 EC2 t4g.small 인스턴스를 사용 중이다.

 

VUser 10명 테스트 결과

VUser 10명 부하 테스트 결과

VUser 50명 테스트 결과

VUser 50명 부하 테스트 결과

VUser 99명 테스트 결과

VUser 99명 부하 테스트 결과

VUser 199명 테스트 결과

VUser 199명 부하 테스트 결과

VUser 296명 테스트 결과

VUser 296명 부하 테스트 결과

 

 

VUser와 트랜잭션 처리량(TPS, Transactions Per Second) 사이의 관계

nGrinder를 사용한 부하 테스트 결과를 분석할 때, VUser와 TPS 사이의 관계를 살펴보는 것은 시스템의 성능과 스케일링 능력을 이해하는데 중요하다.

 

위 결과를 통해 도출할 수 있는 분석 결과는 다음과 같다.

 

가상 사용자 수와 TPS 사이의 관계: 가상 사용자 수가 증가함에 따라 TPS가 초기에는 증가하지만, 특정 지점을 넘어서면 TPS가 감소하기 시작하는 것을 관찰할 수 있다. 이는 시스템이 최적의 부하를 처리할 수 있는 한계에 도달했음을 의미한다.

 

최적 부하 지점: vuser가 50명일 때 TPS가 4.4, 99명일 때 4.3으로, 가상 사용자 수가 증가해도 TPS가 크게 변하지 않는 지점이 관찰된다. 이후 사용자 수가 더 증가하면 TPS가 감소하기 시작한다. 이는 시스템의 처리 용량이 해당 사용자 수를 기점으로 포화 상태에 이르렀음을 나타낸다.

 

최고 TPS 값: 각 가상 사용자 구간에서 최고 TPS 값이 얼마나 달라지는지를 보면, 시스템이 순간적으로 더 높은 처리량을 달성할 수 있음을 보여준다. 하지만 이 최고치를 지속적으로 유지할 수 없다는 점에서, 시스템의 한계와 안정성을 고려해야 한다.

 

시스템 리소스 한계: TPS가 최고점에 도달한 후 감소하는 현상은 시스템 리소스(CPU, 메모리, 네트워크 대역폭 등)가 한계에 도달했음을 나타낸다. 이는 서버의 처리 능력이 추가 부하를 감당할 수 없을 때 발생한다.

 

위 분석 결과를 통해 현재 상용 서버의 최적 동시 접속자는 50명이고 생각하면 될 것 같다. 이는 부하 테스트 결과에서 시스템이 사용자 수가 50명일 때 상대적으로 높은 TPS를 유지하면서도 안정적인 성능을 보였기 때문이다.

 

이 결과가 시스템 리소스의 한계인지 파악하기 위해 AWS EC2 t4g.small보다 더 고사양인 로컬 환경에서 테스트도 진행해 봤다.

(VUser를 296명으로 고정하고 모두 동일한 조건에서 진행했다.)

 

M1 16GB 환경에서 테스트 결과

M1 16GB 환경에서 테스트 진행 결과

M2 Max 64GB 환경에서 테스트 결과

M2 Max 64GB 환경에서 테스트 진행 결과

 

(표) 테스트 환경 별 테스트 결과

 

로컬 환경에서의 부하 테스트 결과(M1 16GB, M2 Max 64GB)와 AWS EC2 t4g.small 인스턴스를 사용한 상용 환경 테스트 결과를 비교할 때, 몇 가지 중요한 결론을 도출할 수 있다.

 

이러한 결론은 시스템의 성능, 확장성, 그리고 최적화 전략에 대한 이해를 도와준다.

 

하드웨어 사양의 중요성: M1 16GB와 M2 Max 64GB 환경에서 더 높은 TPS 값을 기록한 것은, 하드웨어 리소스가 시스템 성능에 큰 영향을 미친다는 것을 보여준다. 특히, M2 Max 64GB 환경에서의 매우 높은 TPS와 최고 TPS 값은, 충분한 리소스가 있을 때 시스템이 처리할 수 있는 부하의 양이 현저히 증가함을 의미한다.

 

성능 병목의 이동: 상용 환경(EC2 t4g.small)에서의 낮은 TPS 값과 비교했을 때, 로컬 환경에서의 테스트 결과는 성능 병목이 주로 하드웨어 리소스의 한계에 기인한다는 것을 시사한다. 이는 성능 최적화를 진행할 때, 단순히 애플리케이션 코드의 최적화를 넘어서 하드웨어 리소스의 확장 또는 업그레이드도 중요한 고려 사항임을 나타낸다.

 

확장성과 비용 효율의 균형: M2 Max 64GB와 같은 고사양 환경에서 높은 성능을 달성할 수 있지만, 이는 더 높은 비용을 수반한다. 상용 환경에서 비용 효율적인 리소스 선택은 성능 요구 사항과 예산 사이의 균형을 맞추는 것을 의미한다. 따라서, 성능 목표를 달성하면서도 비용을 최적화하는 인스턴스 유형과 구성을 선택하는 것이 중요하다.

 

성능 최적화의 다양한 방법: 하드웨어 리소스를 늘리는 것 외에도, 성능 최적화에는 애플리케이션 수준에서의 최적화(예: 코드 최적화, 비동기 처리, 캐싱 전략)와 인프라 수준에서의 최적화(예: 로드 밸런싱, 오토 스케일링)가 포함된다. 이러한 다양한 최적화 방법을 통해, 상용 환경에서도 더 높은 성능을 달성할 수 있다.

 

결론적으로, 로컬 환경에서의 테스트 결과는 시스템의 최대 성능 가능성을 보여주며, 상용 환경에서의 성능 한계를 극복하기 위한 방향성을 제시한다. 이를 바탕으로, 상용 환경에서의 성능 향상을 위해 필요한 리소스 확장, 인프라 최적화, 그리고 애플리케이션 수준에서의 성능 최적화 전략을 수립할 수 있다.

 

 

🔥 결론

이번 부하 테스트를 통해 우리 프로젝트의 시스템이 직면한 성능 한계를 알 수 있었다. 테스트 결과는 우리에게 중요한 두 가지 포인트를 명확히 해주었다.

첫 번째로, 우리의 상용 서버(EC2 t4g.small)가 처리할 수 있는 최적의 동시 사용자 수는 대략 50명임을 확인했다. 이는 시스템이 높은 트랜잭션 처리량(TPS)을 유지하며 안정적인 성능을 보이는 지점이다. 두 번째로, 로컬 환경에서의 테스트 결과는 시스템 성능에 하드웨어 사양이 얼마나 큰 영향을 미치는지 보여주었다. 특히 고사양인 M2 Max 64GB 환경에서의 높은 TPS는 충분한 리소스가 주어졌을 때 시스템이 처리할 수 있는 부하량이 상당히 증가함을 의미한다.

이 발견은 우리에게 시스템을 더 잘 만들기 위한 명확한 방향을 제시해 준다. 우선, 우리의 서비스가 더 많은 사람들을 원활하게 수용하려면, 코드적인 부분뿐만 아니라, 서버의 능력도 업그레이드해야 한다는 것을 깨달았다. 또한, 우리 프로젝트의 예산을 염두에 두면서도, 서비스의 질을 높이기 위해 어떤 서버를 선택할지 신중하게 결정해야 한다는 것을 배웠다. 마지막으로, 서비스가 계속 성장할 수 있도록 미래를 생각하며 계획하는 것의 중요성을 알게 되었다.

따라서, 이번 테스트와 분석을 통해 얻은 교훈을 바탕으로, 우리는 사용자에게 더 좋은 경험을 제공하고, 우리 서비스가 앞으로 나아갈 방향에 대해 더 명확하게 계획할 수 있게 되었다. 이는 우리가 지속적으로 서비스를 모니터링하고, 필요한 조치를 취함으로써, 우리 서비스의 성능을 개선하고 미래의 성장을 준비할 수 있는 튼튼한 기반을 마련해 준다.

 

 

 

 

같은 팀원인 "개발자의 서랍"님의 블로그도 한번 방문해 보세요! 좋은 글이 많이 있습니다 :)

개발자의 서랍