영감을 (inspire) 주고픈 개발 블로그

[성능테스트 시리즈 - 3] 소프트웨어 지표와 성능 테스트를 하기 위해 알아야할 지식들 본문

개발/시스템 안정성 flow

[성능테스트 시리즈 - 3] 소프트웨어 지표와 성능 테스트를 하기 위해 알아야할 지식들

inspire12 2024. 11. 3. 03:14

소프트웨어에서 성능과 테스트 그리고 지표 수집에 대해 정리를 해본 글입니다. 

 

성능 테스트의 목적과  정의

소프트웨어 성능 테스트는 시스템이 특정한 조건에서 요구사항을 만족하는지를 평가하는 과정입니다. 

 

어떤 조건인지 그리고 어떤 기준치를 만족하는지가 핵심이고 이건 비즈니스와 시스템 설계에 따라 달라집니다. 

만명이 쓰는 시스템과 100만명이 쓰는 시스템은 같은 기능이더라도 시스템 설계와 주요 성능 지표 등 목표가 완전히 달라집니다. 

  • 비즈니스 요구사항과 목표 설정: 성능 테스트의 목적은 시스템이 빠르게 작동하는지를 확인하는 것 뿐 아니라, 비즈니스 목표와 일치하는 성능을 발휘할 수 있는지 평가하는 것입니다. 예를 들어, 특정 트래픽을 감당할 수 있는지, 피크 시간대에도 안정성을 유지할 수 있는지가 중요합니다.
  • 유스케이스에 따른 목표: 시스템의 유스케이스에 따라 성능 기준은 달라져야 합니다. 예를 들어, 실시간 처리가 중요한 시스템은 응답 속도가 우선이지만, 배치 처리 시스템의 경우 처리량이 우선될 수 있습니다. 평소에는 요청이 없지만 특정 시간에 요청이 몰리는 서비스와 꾸준히 요청이 유지되는 서비스는 중요시하는 지표가 다를 수 있습니다.

테스트 환경 설정 및 고려사항

  • 모니터링 도구: 리소스 사용률, 응답 시간, 에러 로그 등을 모니터링할 수 있는 툴을 준비하여 테스트 중 발생하는 문제를 실시간으로 파악할 수 있어야 합니다. 이를 위해 서버로부터 모니터링을 위한 지표를 주기적으로 수집을 하는 시스템이 필요합니다. 
  • 데이터 준비: 테스트에 사용하는 데이터는 실제 운영 환경에서 사용될 데이터와 유사해야 합니다. 샘플 데이터가 현실과 차이가 클 경우 성능 결과가 왜곡될 수 있습니다.

지표 선정 및 해석

소프트웨어 성능에서 일반적인 관심사는 다음과 같습니다. 

  • 응답 시간
  • 에러율: 시스템의 안정성
  • 처리량(throughput)
  • 자원 사용률(CPU, 메모리, 디스크I/O 네트워크)

응답 시간 (response time)

사용자가 요청을 보낸 시점부터 시스템이 응답을 완료하는 시점까지의 시간입니다. UX 와 밀접한 관련이 있어 프론트 혹은 API 서버와 관련이 큽니다. 만약 응답시간 오래 걸리는 경우 캐시나 비동기 혹은 배치 형태로 UX를 개선합니다

주요 지표:

  • 평균 응답 시간: 전체 응답 시간의 평균 값.
  • 최대 응답 시간: 가장 오래 걸린 응답 시간.
  • 백분위수 응답 시간 (Percentile): 95th, 99th와 같은 백분위수를 기준으로 응답 시간을 측정합니다. 

백분위수에 대해서도 알면 좋습니다. 평균은 함정이 있습니다. 95% 이상은 100ms로 처리되도 몇 개의 극단적인 값 때문에 데이터가 왜곡될 수 있습니다. (극단적으로 느린 케이스는 DB 나 I/O 이슈로 충분히 생길 수 있습니다)

유저 입장에서 일관적인 응답 속도가 아닌 극단적으로 느린 경우가 생긴다면 UX 적으로 좋지 않습니다. 

백분위수는 50th, 95th, 99th 등으로 설명하는데 95th 같은 경우 95%는 기준을 만족한다는 개념으로 사용자 품질 보장에 유용합니다.  백분위 수 간의 차이가 크다면 응답시간 편차가 크다는 의미이고 성능 최적화가 필요함을 알 수 있습니다. 

처리량 (Throughput)

일정 시간 동안 시스템이 처리할 수 있는 작업의 양을 의미합니다. 시스템이 특정 시간 내에 얼마나 많은 요청을 안정적으로 처리할 수 있는지 평가하며, 시스템의 용량과 관련된 성능을 측정합니다.

주요 지표:

  • 초당 요청 수(QPS/RPS): 초당 처리하는 개별 요청(쿼리/Request)의 수 입니다. 웹 서버, API 서버 등 다양한 서비스의 성능을 평가하는 지표로 사용됩니다.
  • 초당 트랜잭션 수(TPS): 초당 처리하는 트랜잭션의 수 입니다.트랜잭션은 일반적으로 다수의 요청을 포함한 단위 작업으로, 하나의 트랜잭션이 여러 개의 개별 요청을 처리할 수 있습니다.트랜잭션의 처리 성능은 DB의 I/O 성능, 락(lock) 경합, 인덱스 최적화 등과 관련이 깊습니다.

자원 사용률 (Resource Utilization)

시스템이 CPU, 메모리, 디스크, 네트워크 등 자원을 사용하는 비율입니다.

  • 주요 지표:
    • CPU 사용률: 애플리케이션의 CPU 사용 비율.
    • 메모리 사용률: 애플리케이션이 사용하는 메모리 비율 및 누수 여부.
    • 디스크 I/O 사용률: 데이터 읽기/쓰기 속도와 대기 시간.
    • 네트워크 사용률: 네트워크 대역폭 사용 비율.

성능 최적화 및 대응 방안

성능 테스트 결과를 바탕으로 시스템 성능을 최적화하고 병목을 해결하기 위해 여러 가지 조치를 취할 수 있습니다. 대표적인 성능 최적화 방법은 다음과 같습니다.

  • 캐싱(Cache): 자주 조회되는 데이터를 캐싱하여 응답 시간을 줄이고, 데이터베이스와 같은 주요 자원에 대한 부하를 줄입니다.
  • 데이터베이스 튜닝(Database Tuning): 인덱스 최적화, 쿼리 최적화 등을 통해 데이터베이스 성능을 향상시킵니다.
  • 로드 밸런싱(Load Balancing): 여러 서버로 부하를 분산하여 특정 서버의 과부하를 방지합니다.
  • 비동기 처리(Asynchronous Processing): 응답 시간이 중요한 경우 비동기 방식으로 처리하여 사용자 경험을 개선할 수 있습니다.
  • 코드 최적화(Code Optimization): 주요 기능에 대해 코드 최적화를 수행하여 전체 성능을 향상시킵니다.
  • 자동 스케일링(Auto-scaling): 클라우드 환경에서는 사용자가 증가할 때 자동으로 서버 인스턴스를 늘리거나 줄여 시스템 성능을 유지할 수 있습니다.

 

모니터링 시각화 도구인 grafana 에서 자주 사용하는 부하 성능측정(load testing) 템플릿에 적용된 지표도 같이 참고하면 이해하기 좋습니다.