어플리케이션 성능테스트 고려할 점

Performance Testing Tutorial: What is, Types, Metrics & Example

위 문서 내용을 바탕으로 작성되었습니다.

 

 

서버 어플리케이션 개발 후 운영환경으로 오픈하기 전에는 시스템의 성능 테스트를 할 필요가 있다.

부끄럽게도 회사에서 지난 오픈했던 서비스의 성능테스트는 명목 상으로 진행했던 것 같다. 

 

앞으로 쓸 내용에 들어가는 다양한 기준들, 제약들을 세심하게 고려하지 못하고 그냥 ngrinder로 tps 정도만 봤었다. 

 

꼭 운영환경 기준의 부하 테스트만이 성능테스트라고 할 수 없고, 시스템의 어떤 측면에서의 성능을 테스트하는가 설정하는 부분이 중요하다고 생각한다. 

 

 

성능테스트의 정의, 목적

성능테스트는 특정된 부하를 통해 시스템의 아래 항목들을 체크하고, 성능저하에 영향을 주는 요인(bottleneck)을 찾아내는 테스트이다.

 

속도(speed)

  - 시스템의 속도, 응답속도, 부팅속도 등 전반적인 시스템 성능

응답 시간(response time)

  - 요청에 대한 응답 속도

안정성(stability)

  - 변화하는 load에 대해 시스템(response time, hardware, system metric 등..)이 얼마나 안정적인가에 대한 정도

신뢰성(reliability)

  - 지속적인 load에 대해 시스템이 같은 식으로 작동하고 응답하는지에 대한 정도 

확장성(scalability)

  - 어느정도의 max users 를 감당할 수 있을지에 대한 정도

리소스 사용률(resource usage)

  - 특정 load에 대한 리소스(memory, cpu, disk 등..) 사용률

 

 

성능테스트의 필요성에 대해 원글에서는 좀 흥미로운 예를 들어 설명하고 있다.

 

포춘 500대 기업 중 59%는 매주 평균 1.6시간 정도의 다운타임이 있다고 하는데,

이를 해결하는데 드는 시간비용으로 최소 10,000명의 직원 평균 시급 56달러(한화 67,063원)로 환산했을 시 896,000달러 (한화 약 10억) 정도의 비용이 든다고 있다고 표현하고 있다.

 

구글의 경우 5분의 다운타임 만으로도 545,000달러의 비용이 든다고 한다.

 

그만큼 성능 테스트는 중요하다는 것이다.

 

성능 테스트의 종류

부하 테스트 (load testing)

  - 일반적으로 기대되는 트래픽 조건에서 충분한 성능을 내는지 확인, 성능 병목지점을 찾는 목적

스트레스 테스트 (stress testing)

  - 극도의 높은 트래픽 조건에서 어떻게 처리하는지 확인, 시스템이 버티는 한계(breaking poing)를 측정하기 위함

내구성 테스트 (endurance testing)

  - 긴 시간동안 시스템이 기대하는대로 작동하는지 확인하기 위함

공격성 테스트 (spike testing)

  - 갑자기 높은 부하를 발생시켰을 때 시스템이 어떻게 반응하는지 확인하기 위함

볼륨 테스트 (volume testing)

  - 변화하는 데이터베이스 볼륨에 대해 시스템의 성능을 측정하기 위함

확장성 테스트 (scalability testing)

  - 부하, 트래팩이 늘어났을 때 시스템의 스케일 업 성능을 확인하기 위함.

 

 

아래는 성능에 영향을 주는 주요 요인들이다. 대부분 속도와 관련이 많다.

시스템 성능에 영향을 주는 주요 요인

Long load time

  - 로드 타임은 어플리케이션이 구동될 때 걸리는 시간이다. 수 초 내로 가급적 짧을수록 좋다. 

Poor response time

  - 유저 요청에 대해 응답이 가기까지 걸리는 시간. 유저 이탈에 연관이 있으니 특별히 신경 써야할 지표이다.

Poor scalability

  - 기대한 유저 수만큼 수용하지 못하는 시스템은 poor scalability 로 표현할 수 있는데 이를 개선하기 위해 부하, 확장성 테스트를 통해 개선해야 한다.

Bottlenecking

  - bottleneck(병목지점)이란 시스템의 성능을 떨어뜨리는 장애 요인을 의미한다. 그것은 코드로 인한 것일수도, 혹은 하드웨어로 인한 요인일 수도 있다. 특정 코드블럭이 병목지점이 되는 경우들이 자주 있다고 하는데 이를 찾아내고 개선하는 작업이 필요하다. 몇가지 지표로 병목구간을 확인하고 원인을 찾아야 한다.

• CPU utilization
• Memory utilization
• Network utilization
• Operating System limitations
• Disk usage

 

 

방법론 적이지만 아래 순서에 따라 성능 테스트를 계획하고 진행할 수 있다.

성능 테스트 순서

1. 테스트 환경을 파악

  - 실제 테스트할 환경을 파악하는 단계이다. 실제 라이브될 운영환경인지 특정 테스트를 위한 환경인지? 어떤 테스트 툴을 사용할 수 있는지? (운영에서는 불가한 테스트 툴이 있을 수 있다.) 하드웨어, 소프트웨어, 네트워크 환경 등 파악

2. 성능에 대한 수용 가능한 기준 식별

  - 성능 테스트에 대한 목표를 정하는 단계이다. 어떤 테스트를 하는 것이며 어떤 조건하에 어느정도의 트래픽 하에서 버틸 수 있는지? 어느정도의 속도를 내야 하는지? 이런 수치들은 다른 유사한 서비스들을 밴치마킹 하여 설정해도 좋다.

3. 성능 테스트 계획 수립

  - end user를 어떤 방식으로 가정할건지 설정하고, 테스트 시 어떤 데이터와 지표들을 수집할 것인지 확인하는 단계이다. 몇명의 유저를 어떤식으로 발생시킬지? 등.. 잘 알려진 ngrinder, jmeter 등을 선택하여 설정할 수 있다.

4. 테스트 환경 설정

  - 실제 실행하기 전 테스트 환경을 준비하는 단계이다. 어플리케이션을 준비하고, 제약 조건을 적용하고, 필요한 테스트 리소스를 준비한다.

5. 테스트 실행

6. 분석, 튜닝, 다시 테스트

  - 테스트 결과를 분석하여 성능을 확인하고, 시스템을 개선한다. 테스트를 재시작할 때마다 개선된 지표를 확인할 수 있어야 한다. 

 

 

테스트 케이스 예시

예시 중 일부 모호한 단어들은 구체적인 숫자로 바뀌어야 한다.

 

• Verify response time is not more than 4 secs when 1000 users access the website simultaneously.
  • 동시 1000명의 유저 중 응답시간 4초가 넘지않는 유저 수를 확인
• Verify response time of the Application Under Load is within an acceptable range when the network connectivity is slow
  • 네트워크 연결이 느릴 때 특정한 범위 안에서 응답시간 측정
• Check the maximum number of users that the application can handle before it crashes.
  • 시스템이 버틸 수 있는 최대 유저 수 확인
• Check database execution time when 500 records are read/written simultaneously.
  • 500 레코드가 동시에 read/written 될때 데이터베이스 수행 시간 측정
• Check CPU and memory usage of the application and the database server under peak load conditions
  • 피크 부하 조건 하에서 어플리케이션과 데이터베이스의 cpu, memory 사용량 확인
• Verify response time of the application under low, normal, moderate and heavy load conditions.
  • 트래픽 낮음, 중간, 높음 조건 하에서 응답시간 측정 

 

 

대표적인 모니터링 지표

• Processor Usage – an amount of time processor spends executing non-idle threads.
• Memory use – amount of physical memory available to processes on a computer.
• Disk time – amount of time disk is busy executing a read or write request.
• Bandwidth – shows the bits per second used by a network interface.
• Private bytes – number of bytes a process has allocated that can’t be shared amongst other processes. These are used to measure memory leaks and usage.
• Committed memory – amount of virtual memory used.
• Memory pages/second – number of pages written to or read from the disk in order to resolve hard page faults. Hard page faults are when code not from the current working set is called up from elsewhere and retrieved from a disk.
• Page faults/second – the overall rate in which fault pages are processed by the processor. This again occurs when a process requires code from outside its working set.
• CPU interrupts per second – is the avg. number of hardware interrupts a processor is receiving and processing each second.
• Disk queue length – is the avg. no. of read and write requests queued for the selected disk during a sample interval.
• Network output queue length – length of the output packet queue in packets. Anything more than two means a delay and bottlenecking needs to be stopped.
• Network bytes total per second – rate which bytes are sent and received on the interface including framing characters.
• Response time – time from when a user enters a request until the first character of the response is received.
• Throughput – rate a computer or network receives requests per second.
• Amount of connection pooling – the number of user requests that are met by pooled connections. The more requests met by connections in the pool, the better the performance will be.
• Maximum active sessions – the maximum number of sessions that can be active at once.
• Hit ratios – This has to do with the number of SQL statements that are handled by cached data instead of expensive I/O operations. This is a good place to start for solving bottlenecking issues.
• Hits per second – the no. of hits on a web server during each second of a load test.
• Rollback segment – the amount of data that can rollback at any point in time.
• Database locks – locking of tables and databases needs to be monitored and carefully tuned.
• Top waits – are monitored to determine what wait times can be cut down when dealing with the how fast data is retrieved from memory
• Thread counts – An applications health can be measured by the no. of threads that are running and currently active.
• Garbage collection – It has to do with returning unused memory back to the system. Garbage collection needs to be monitored for efficiency.

새삼 놀랐던 지표는 rollback segment 이다.

생각해보니 롤백이 되면 네트워크 요청이 가니깐 확인이 필요한 부분이기도 하겠구나 싶었다.

 

 

 

정리하면 성능 테스트는 아래와 같은 템플릿에 부합하는 식으로 고안되어야 할 것 같다.

 

A 제약 조건을 두고 (외부 서버는 mock server 등으로 두어 랜덤 1-3초간 지연응답)

B 정도의 부하를 통해 (1000명의 유저가 동시에 요청하되 매초 3번씩 총 5분간, 10분까지 점점 x만큼 늘려서 요청한다.)

C 지표를 확인하여 (jvm, hardware, response time 등)

D 조건에 맞는지 확인하고 (10분간 95% 의 response time avg 는 100ms 이하, 서버가 죽기 직전의 max users 는 3만, 최고 tps 3000) 

병목 지점 E 를 찾아낸다. (특정 query 에 병목발견, 특정 코드블럭에서 효율적이지 못한 부분 발견, 불필요한 io blocking, cpu resource , jvm 메모리 부족 등)

 

 

 

 

성능 테스트 툴

JMeter, gatling, nGrinder 등을 사용한다. 찾아본 바 jmeter를 공부해보는 것이 도움될 것 같다.

 

성능 모니터링 툴 (apm)

prometheus, grafana 등을 이용하여 필요한 데이터를 수집하고 시각화 하여 확인할 수 있다.

•