실전 Web Application 부하 테스트 1편

손영수 -

*실전 Web Application 부하 테스트 - 1,2편 통합한  웹∙앱 부하테스트 성능 진단 및 컨설팅 안이 최신 업데이트 되었습니다.
아래 글에서 확인하실 수 있으며, 웹 부하테스트는 20page 부터 확인하시면 됩니다😀

실전 Web Application 부하 테스트 - 1, 2편 통합 본 보러가기

어니컴은 웹 어플리케이션의 다양한 부하 테스트 경험을 가지고 있습니다. 이번 시간은 실제 고객사 사이트에서 얻은 부하 테스트 노하우 경험을 공유하고자 합니다.

웹 어플리케이션을 바라보는 성능의 관점

먼저 웹 어플리케이션의 올바른 부하 테스트를 위해 성능적인 관점으로 어플리케이션과 인프라 스트럭처 간의 상관 관계를 이해할 필요가 있습니다.

사용자 > 트랜잭션 > 자원


고객(사용자)은 웹 사이트를 방문해 트랜잭션을 일으키고, 트랜잭션은 서버의 자원을 사용합니다. 여기서 성능이라는 관점은 크게 두가지로 나누어질 수 있습니다.

  • 사용자 측 : 빠른 응답 시간
  • 서버 측 : 할당된 자원에서, TPS (초당 트랜잭션 수) 처리

사용자는 특정 페이지에 들어가나, 특정 버튼을 누르면, 빠르게 응답이 오는 것을 보고 성능이 좋다고 느낍니다. 반면 개발자 입장에서는 4 Core, 8GB 메모리로 사용자 10만 명(1만  TPS) 은 거뜬히 견디는 것이겠죠. 결국 성능은 이 두 가지 관점을 만족해야 합니다.

최대 TPS를 기준으로 서버의 용량을 산정하고 서비스를 할 경우 (왼)

위쪽 그림과 같이, 최대 TPS를 기준으로 서버의 용량을 산정하고 서비스를 하게 되면, 사용자 입장에는 어떠한 일이 일어날까요?

즉 사용자 중 일부는 매우 늦게 응답을 받을 수 있다는 겁니다. 평균으로는 1.6초에 응답을 받지만, 응답시간 기준으로 하위 90%에 있는 사용자에게는 3.8초, 하위 100% (꼴등) 의 사용자는 20초가 지나서 결과를 받을 수 있죠. 아마 일부 사용자이지만, 웹서비스가 매우 느리다는 생각을 가지게 될 것이며, 다시 접속을 하지 않을 수 있습니다.

그래서 성능을 테스트할 때는 TPS 기준으로 산정하는 것보다는 99%의 사용자가 목표 응답시간 안에 결과를 받느냐와 같은 형태로 측정을 해야 합니다. 또한 이 응답시간은 웹서버에서 머무르는 시간이 아닌, 사용자가 네트워크를 거쳐 서버에서 응답을 받는 사용자 관점에서 측정이 되어야 합니다.

물론 빠른 응답시간이 중요하지 않아 늦게라도 처리만 되면 되는 시스템이라면, 위 임계점 형태로 가도 되겠죠.

부하 테스트를 하는 목적

부하 테스트를 하는 목적은, 우리가 만든 웹 서비스가

  • 목표 응답시간 기준으로 얼마만큼의 동시 접속자 수를 견딜수 있는가
  • 동시접속자 수를 TPS로 환산하여
  • 자원적인 관점으로 사용자 대비 용량 산정 (Capacity Planning)

을 하는 겁니다. 즉 사용자의 추이에 따라 적절한 자원을 배분하는 것이지요. 그리고 더 나아가서 병목구간을 찾아 제거하는 것입니다.

출시 전 대부분의 어플리케이션이 성능 저하를 일으키는 병목구간을 가지고 있습니다. 출시 전에 얼마나 이 부분을 많이 해결하느냐가 매우 중요합니다. 즉 부하를 발생시키는 것도 중요하지만, 병목구간이 무엇인지 찾아내는 것을 고객은 원합니다.

그래서 부하 발생하는 것도 중요하지만, 성능적 병목 구간은 APM (Application Performance Monitoring)과 인프라 모니터링(Infrastructure Monitoring)의 지표들을 읽어내고, 병목 구간의 문제가 코드의 잘못인지, 자원의 부족인지, 세팅값의 잘못인지 찾아내어 개발자 레벨로 설명을 해주는 능력이 필요합니다. 즉 웹 어플리케이션 뿐만 아니라, 웹 서버의 특성까지 잘 이해해야만 가이드가 가능하겠죠.그만큼 매우 기술 지향적인 일이고, 고객에게 제공하는 비용도 매우 높습니다.

부하 테스트의 종류

차량 안정성 테스트처럼 실제 제품 출시전에, 다양한 종류의 부하 테스트를 진행해 웹 어플리케이션의 안정성을 체크해야 합니다. 주로 많이 하는 테스트는 다음과 같습니다.

부하 테스트의 종류
  • 부하 테스트 (Load Test) — 특정한 부하를 제한된 시간을 두어서 웹 어플리케이션에 이상이 없는지 파악하는 테스트
  • 지속성 테스트 (Endurance Test) — Load Test와 유사하나 오랜 기간 부하를 줘서 하는 테스트.  Aging 테스트라고 생각하시면 됩니다.
  • 스트레스 테스트 (Stress Test) — 부하의 임계점을 찾기 위해 점진적으로 부하를 올리면서 진행하는 테스트
  • 최고 부하 테스트 (Peak Test) — 일순간 감당할 수 없을 만큼 부하를 주고, 웹 어플리케이션이 죽지 않고 제대로 동작하고 회복하는지 보는 테스트.  수강신청이나 이벤트 등 대규모 상황을 대비하기 위해 진행

이중 고객들이 요구하는 테스트는 보통 스트레스 테스트 (Stress Test) 입니다.

맺으며

부하 테스트는 왜 필요한지? 그리고 어떠한 것을 측정해야 하는지, 종류는 무엇인지 전체적으로 훑어보는 시간을 가졌습니다.  

다음 글에서는 올바른 부하 테스트를 실행하기 위해 어떠한 부분을 고려해야 하는지 설명드리겠습니다.     실전 웹 어플리케이션 부하 테스트 2편

IMQA와 관련하여 궁금하신 사항은 언제든 아래 연락처로 문의해 주시면 상세히 안내해 드리겠습니다. 이미지를 클릭하시면 1:1 채팅 창으로 이동합니다.

  • 02-6395-7730
  • support@imqa.io