개요

  1. 성능 테스트란
  2. 성능 테스트의 목적
  3. 성능 테스트의 필요성
  4. 성능 지표 (Metrics)
  5. 성능 테스트 유형 (Testing Types)
  6. 성능 테스트 계획 수립
  7. 다양한 성능 테스트 도구
  8. 부록 1. Response Time, Latency, Processing Time
  9. 부록 2. Little’s Law : TPS를 통한 동시 접속자 수 예상

해당 글을 통해서 성능 테스트를 왜 해야하는지, 어디서부터 어떻게 해야하는지를 알아보도록 하자

성능 테스트란?

  • 앱이나 시스템이 주어진 조건에서 얼마나 효율적이고 안정적으로 동작하는지 평가하기 위한 테스트 과정

  • 시스템의 성능을 다양한 관점에서 측정하여, 실제 운영 환경에서 발생할 수 있는 문제를 미리 파악하고 해결하는 데 목적이 있음

    Testing

성능 테스트의 필요성

2017년 구글이 발한 자료 내용을 살펴보자 [참고]

  • 모바일 환경에서 페이지 로드 타임이 1초에서 3초 가까이 되면 서비스 사용자 이탈률이 32%까지 증가
  • 5초 이상 이탈률이 90% 증가
  • 6초이상 이탈률이 106% 증가
  • 10초 이상 이탈률이 120% 증가

Response Time

성능 테스트의 목적

  • 설정한 목표치 달성

    • 목표 : 초당 1000건의 요청 처리, 모든 조회 요청을 1초 이내로 응답

      → 배포 전 성능 테스트를 통해 목표치를 만족하는지 확인

    • 어떤 지표를 확인해야할까요?

      • 초당 1000건의 요청 처리 → Throughput (처리량)
      • 모든 조회 요청을 1초 이내로 응답 → Response Time(응답 시간)
  • 성능 병목 현상 파악

    • 응답 시간, 처리량 등 성능 지표를 통해 시스템의 병목 현상을 발견하고 해결
  • 가용성

    • 시스템이 서비스를 정상적으로 제공할 수 있는 상태
  • 기타

    • 확장성 확인
      • 시스템이 사용자 수나 데이터의 증가에 따라 잘 확장될 수 있는지를 확인
    • 안정성 검증
      • 시스템이 장시간 동안 안정적으로 운영될 수 있는지를 확인
    • 복구 능력 평가
      • 시스템이 장애 상황에서 얼마나 빠르고 신속하게 복구될 수 있는지를 평가
    • 최적화
      • 시스템의 자원 사용을 최적화하여 비용을 절감하고 성능을 향상

성능 지표 (Metrics)

성능 테스트의 결과를 정량적으로 평가하는 기준

  • 응답 시간(Response Time) : 사용자가 요청을 보낸 시점부터 응답을 받기까지의 시간

    • 평균 응답 시간 : 모든 요청에 대해 평균적으로 걸리는 시간을 계산
    • 최대/최소 응답 시간 : 특정 시점이나 특정 조건에서 발생하는 최고 및 최저 응답 시간을 파악
    • 백분위 응답 시간 : 예를 들어 95퍼센트 응답 시간은 전체 요청 중 95%가 그 시간 이내에 응답되었음을 의미

    Response Time

    Response Time

    • 응답 시간 = 150 + 200 + 100 = 450 ms
  • 처리량(Throughput) : 시스템이 단위 시간당 처리할 수 있는 요청이나 트랜잭션의 수

    • 초당 요청 수 (Requests per Second, RPS) : 시스템이 초당 처리할 수 있는 HTTP 요청의 수를 측정하여, 웹 앱의 처리 능력을 평가

      Throughput

      Throughput

      • 현재 시스템에서 처리량은 얼마일까요?
        • 100 rps → 서브 시스템 중 가장 처리량이 낮은 부분으로 계산할 수 있음
      • 병목 구간 : 하위 시스템 중 가장 낮은 처리량을 가지는 부분
        • 병목 구간이 아닌 곳을 성능 개선한다면 → 전체적인 성능 개선 실패 500rps를 700rps라고 해도 mysql에서 100 rps라면 여전히 100 rps
    • 트랜잭션 수 (Transactions per Second, TPS) : DB나 앱에서 초당 처리되는 트랜잭션 수를 평가하여, 시스템의 처리 능력을 파악

    • 데이터 전송량 : 네트워크를 통해 초당 전송되는 데이터 양(예: MB/s)을 측정하여, 대용량 데이터 전송 시의 성능을 평가

  • 자원 사용량(Resource Utilization) : CPU, 메모리, 네트워크 대역폭 등의 자원 사용률

  • 오류율(Error Rate) : 처리된 요청 중 실패한 요청의 비율

성능 테스트 유형 (Testing Types)

성능 테스트의 구체적인 방법을 나타내며, 각각의 유형은 특정한 목적을 달성하기 위해 사용됨

Testing Types

  • 부하 관련 테스트 (Load Testing)

    • 부하 테스트**(Load Testing)** : 예상되는 최대 사용자 수나 트래픽 조건에서 시스템 성능을 평가, 목표값에 해당되는 부하를 견딜 수 있는지 확인

      Load Testing

      Load Testing

    • 고정 부하 테스트 : 예상되는 최대 부하를 일정 시간 동안 유지하여 안정성 평가

    • 스파이크 테스트(Spike Testing) : 짧은 시간 동안 급격하게 부하를 증가시켜 시스템이 어떻게 대응하는지 평가, 사용량이 급증하는 상황에서 시스템이 견디고 성능에 문제가 없는지 확인

      Spike Testing

    • 피크 테스트(Peak Testing) : 예상되는 최고 부하 상태에서 시스템 성능을 평가

  • 한계점 및 회복력 테스트

    • 스트레스 테스트(Stress Testing) : 시스템이 최대치에 해당되는 부하를 받았을 때 성능과 회복 능력을 평가

      Stress Testing

      Stress Testing

      Stress Testing

      • 부하 테스트 대비 50% 혹은 그 이상의 부하를 주어 테스트
      • 한계점 파악: 시스템 성능 저하, 오류, 다운타임 발생 시점을 확인
      • 자원 소진 테스트: 자원이 소진될 때의 시스템 반응 평가
      • 복구 능력 테스트: 한계 초과 후 시스템이 얼마나 빠르게 정상 상태로 복구되는지 평가
    • 중단점 테스트(Breakpoint Testing) : 시스템이 감당할 수 있는 최대 부하 수준을 찾기 위해 점진적으로 부하를 증가시키며 테스트

      Breakpoint Testing

    • 회복 테스트 : 시스템 장애 이후 정상 상태로 회복하는 능력을 평가

  • 지속성 및 안정성 평가

    • 내구 테스트 (Endurance/Soak Testing) : 장시간 동안 평균 사용률로 일정한 부하를 가하여 시스템 성능과 안정성을 평가

      Endurance/Soak Testing

      • 지속적인 부하 테스트 : 장시간 동안 부하를 가해 성능 변화를 모니터링
      • 리소스 누수 확인 : 메모리 누수, 핸들 누수 등 장시간 테스트에서 발생하는 문제를 확인
    • 안정성 테스트 : 시스템이 오랜 시간 동안 지속적인 부하에서 얼마나 안정적으로 동작하는지 평가

  • 데이터 처리 관련 테스트

    • 볼륨 테스트

      : 대량의 데이터를 처리할 때 시스템 성능이 어떻게 변화하는지 평가

      • 대량 데이터 입력 : 시스템에 대량 데이터를 입력하여 성능 변화를 평가
      • 데이터베이스 성능 평가 : 대용량 데이터 처리 시 데이터베이스의 성능을 집중적으로 평가
  • 기본 기능 확인 테스트

    • 스모크 테스트(Smoke Testing) : 시스템의 주요 기능이 정상적으로 동작하는지 간단히 확인하는 초기 테스트

      Smoke Testing

  • 내구 테스트 (Endurance/Soak Testing) : 장시간 동안 시스템의 안정성을 평가

  • 볼륨 테스트 (Volume Testing) : 대량의 데이터를 처리할 때 시스템 성능을 평가

성능 테스트 계획 수립

1. 응답의 최소 Response Time 정하기

  • 목표 응답 시간을 설정하여 사용자 경험을 최적화
  • 예를 들어, 금융 거래 시스템의 경우 0.3초 이하로 설정

2. 서비스가 Peak일 때의 사용자 수 구하기

  • 과거 데이터와 성장률을 반영하여 피크 타임 사용자 수를 추정하고, 예상보다 20~50% 더 여유 있게 설정

3. 시스템 자원 한계 파악

  • CPU, 메모리, 네트워크 대역폭 등의 자원 사용량을 모니터링하여 시스템이 처리할 수 있는 최대 부하를 파악
  • 자원 한계점을 넘지 않도록 계획을 세움

4. 테스트 시나리오 다양성 확보

  • 다양한 시나리오를 통해 실제 환경에서 발생할 수 있는 모든 상황을 테스트
  • 정상적인 사용 패턴뿐만 아니라, 비정상적인 트래픽이나 장애 상황도 포함시킴

다양한 성능 테스트 도구

테스트 도구LocustJMeterk6nGrinder
개발 조직Locust 오픈소스 커뮤니티Apache FoundationGrafana LabsNHN
언어PythonJavaJavaScriptJython, Groovy
사용자 시나리오 정의코드 기반GUI 또는 코드 기반다양한 GUI (Grafana 호환)GUI 또는 코드 기반
설치 및 시작pip install locustJava 설치 및 GUI 또는 명령행으로 실행패키지 설치, CLI 실행Java 설치 및 실행
분산 테스트마스터-워커 구조 지원분산 테스트 지원분산 테스트 지원
(클라우드 유료)
분산 테스트 지원
유연성 및 확장성Python 코드로 유연성이 높음플러그인 아키텍처로 확장 가능코드 기반으로 높은 유연성 제공플러그인으로 확장 가능
학습 곡선Python 개발자 친숙GUI 사용으로 비전공자도 가능코드 작성 필요로 중급 이상Java 친숙 필요
메모리 사용량약 50 ~ 150 MB약 512MB ~ 1GB약 128~ 256MB약 300 ~ 500MB
비고단일 코어에서 실행 시 메모리 소비가 적은 편 분산 테스트 시 사용되는 워커의 수에 따라 메모리 사용량이 증가JVM의 특성상 메모리 사용량이 비교적 높은 편, 많은 스레드를 생성할 때 메모리 소모가 크며, 대규모 테스트에서 성능에 영향Go 언어 기반의 경량 도구로, 메모리 사용량이 비교적 적음, 이로 인해 클라우드 환경에서 매우 효율적으로 작동-

부록 1. Response Time, Latency, Processing Time

Response Time (응답 시간)

  • 사용자가 어떤 요청을 보내고, 시스템이 해당 요청에 대한 응답을 전송하는 데 걸리는 시간
  • 일반적으로 밀리초 단위로 측정
  • 시스템 또는 네트워크의 성능에 대한 전반적인 인식을 제공

Latency (지연 시간)

  • 데이터가 네트워크를 통해 이동하는 데 걸리는 시간

Processing Time(처리 시간)

  • 시스템이 요청을 받은 후, 해당 요청을 처리하는 데 소요되는 시간

  • 일반적으로 응답시간보다 짧은 시간으로 측정

  • 시스템이 얼마나 효율적으로 요청을 처리하고 있는지를 나타내는 중요한 지표

    Response Time

Response Time

부록 2. Little’s Law : TPS를 통한 동시 접속자 수 예상

Little’s Law

  • 그래서 TPS 가 어떠한 의미가 있는가 → 이를 통해 동시 접속자 수를 예상할 수 있음
  • TPS (Repsonse Time + Think Time) = 600 (0.08 + 0.5) = 대략 350명
    • Think Time : 요청을 보내고 두번째 요청을 보낼 때 걸리는 시간
profile
소프트웨어 엔지니어

0개의 댓글