성능 테스트

◎ 테스트의 목적

• 시스템 확장성을 가졌는지 확인
• 성능을 개선하기 위해 확장해야 하는 시스템이 무엇인지 파악
• 부하가 많이 발생할 때 문제 상황 개선
• 각 시스템의 병목 지점을 예측하고 진단 및 개선

여기서의 가용성과 확장성은 아래와 같다.

■ 가용성

가용성(Availability)이란 시스템이 정상적으로 사용 가능한 정도를 말한다.
정상적인 사용시간(Uptime) / 전체 시간(Uptime + Downtime)으로 계산되며 이러한 가용성의 핵심은 Uptime의 비율을 늘림으로써
단일 장애점(Single Point of Failure)을 없애는 것이다.

고가용성의 경우에는 소실되는 데이터의 방지를 목적으로 한다.

■ 확장성

확장 가능한 시스템이란 요구되는 시스템의 성능에 따라 동적으로 서버 구성이 변경되고, 시스템 처리 능력을 최적화할 수 있는 시스템을 의미한다.

위의 가용성을 고가용성으로 유지하기 위해 필요한 것이 바로 확장성이다.

---

◎ 성능 테스트의 방법

발생할 수 있는 문제 상황

• 응답 속도(Latency) 저하
• 시스템 잠금(Lock) 경합
• 부하 발생시 애플리케이션 또는 서버 에러 발생
• 데이터 일관성 문제와 손실

따라서 성능 테스트는 지표를 통해 시스템을 점검하고 발생할 수 있는 병목 지점을 예측학 진단 및 개선하는 활동이다.

성능테스트의 종류

■ 6가지 성능테스트 유형

▶ Load Test (most common out of the five)

• 적정 부하(= Peak시점의 부하)를 유지하는 테스트

Load Testing은 부하가 임계치(Threshold Value)에 도달할 때까지 시스템의 부하를 지속적으로 증가시키면서 시스템을 확인하는, Performance Testing의 한 유형이다.
동시단말사용자(concurrent users)와 트랜잭션을 증가시키면서 테스트 중인 애플리케이션의 동작을 확인하는 것을 의미합니다.

Load Testing의 주요 목적은 과부하 상태(under heavy load)에서 시스템이 잘 작동될 때, 응답시간과 애플리케이션의 지구력(staying power)을 모니터링하는 것입니다.

Load Testing은 테스트중인 애플리케이션이 견딜 수 있는 부하의 양을 확인하기 위해 수행됩니다.

▶ Stress Test

• 적정 부하의 2배를 유지하는 테스트

Stress Testing은 CPU, Memory, Disk Space 등과 같은 하드웨어 자원이 충분하지 않을 때, 소프트웨어의 안정성을 확인하는 Performance Testing의 한 유형입니다.
Stress Testing의 기본 개념은 시스템의 오류를 확인하고, 어떻게 시스템이 정상적으로 복구되는지를 살펴보는 것입니다.

Stress Testing은 시스템 하드웨어 자원에서 처리할 수 없는 많은 수의 동시단말사용자(concurrent users)/프로세스로 소프트웨어에 부하를 주는 Negative Testing입니다.

Stress Testing의 기본 개념은 시스템의 장애를 확인하고 시스템이 어떻게 정상적으로 복구되는지를 주시하는 것입니다. 이러한 품질 특성을 회복성(recoverability)이라고 합니다.

▶ Endurance Test

• 장시간 부하를 유지하는 테스트

Endurance testing은 시스템의 동작을 확인하기 위해, 장기간에 걸쳐 예상되는 부하량에 기반하여 시스템을 테스트 하는 것을 포함합니다.
예를 들어, 시스템이 3시간동안 작업을 수행하도록 설계되었다면, 동일 시스템이 6시간동안 지속되어도 시스템이 지구력을 유지하는지를 확인하는 것입니다.

가장 일반적인 테스트 케이스는 메모리 누수, 시스템 장애 또는 무작위적인 동작(random behavior)과 같은 시스템의 동작을 확인하기 위해 수행됩니다. 때때로, Endurance testing은 ‘Soak testing’이라고도 합니다.

▶ Spike Test

• 순간적인 대량 부하를 발생시키는 테스트

Spike testing은 Stress Testing의 Subset입니다.
테스트 대상 시스템에 대해, 상용 운영환경에서 예상되는 부하 이상의 Workload를 짧은 기간동안 반복적으로 증가시킬 때 나타나는 성능 특성을 검증하기 위해 수행합니다.

▶ Scalability Testing

• 시스템의 최대치를 확인하는 테스트

Scalability Testing은 사용자 부하, 트랜잭션 수, 데이터 볼륨 등과 같은 비기능 측면에서 확장할 수 있는 역량을 판단하기 위한 소프트웨어 애플리케이션 테스트입니다. 이 테스트의 주요 목적은 더이상 확장(Scaling)하지 못하도록 막는 ‘시스템의 Peak’가 무엇인지 확인하는 것입니다.

▶ Volume testing

• 데이터 효율성 테스트

Volume testing은 처리해야 할 많은 양의 데이터를 가진 애플리케이션의 효율성을 확인하기 위한 테스트입니다. 이 테스트의 주요 목표는 다양한 Database Volumes 하에서 애플리케이션의 성능을 모니터링 하는 것입니다.

---

◎ 성능 테스트 용어

Throughput (처리량)

시간당 처리량으로 데이터 전송량에 포커스를 맞춘 성능 지표로 매우 실용적인 지표이다.
Throughput 성능 지표는 RPS(request per second) 와 TPS(transaction per second)로 구성되며

볼륨의 성능을 측정할 경우에는 IOPS(Input/Output per second)라는 단위를 사용한다.

• 1초에 처리하는 HTTP 요청 수 (rps)
• (동영상 스트리밍 서비스와 같이 대역폭이 중요한 경우) 네트워크로 전송되는 데이터 전송 속도

Latency (처리시간)

요청이 처리되는 시간을 나타낸다.

Response Time (응답시간)

응답을 받기까지의 시간

Network Bandwitdh(대역폭)

네트워크에서 특정 시간 내에 전송 될 수 있는 데이터의 최대 용량
네트워크에서 잠재적으로 동시에 전송될 수 있는 데이터의 최대치

• 실질적인 성능을 나타내는 지표가 아니다.

CPU

컴퓨터에서 수행할 수 있는 모든 작업을 담당하며 소프트웨어의 명령과 함께
시스템 메모리의 프로그램에 대한 명령을 실행한다.

CPU의 핵심 기능은 랜덤 액세스 메모리(RAM)에서 명령을 가져온 다음 명령을 디코딩하고 실행하는 것입니다. 프로세스를 차례로 실행합니다.

CPU의 범용 기능

• 코어 :
  코어는 기본적으로 CPU의 프로세서입니다. 컴퓨팅 고대로 거슬러 올라가면 프로세서에는 단 하나의 코어만 있었습니다. 이제 컴퓨터에는 일반적으로 2개에서 64개의 코어가 있습니다. CPU에 코어가 많을수록 성능과 효율성이 향상됩니다.
• 동시 멀티스레딩/하이퍼스레딩 :
  동시 멀티스레딩(Intel 프로세서에서 하이퍼스레딩이라고 함)은 처리가 단일 코어가 아닌 여러 소프트웨어 스레드에 위임되는 경우입니다. 이를 통해 더 많은 작업을 동시에 수행할 수 있으므로 하나의 코어를 두 개의 "논리적" 코어로 효과적으로 전환할 수 있습니다.
• 캐시 :
  CPU에는 자체 초고속 메모리가 내장되어 있어 RAM이나 SSD 유형 보다 빠릅니다 . CPU 캐시는 L1-L3에서 배열되며 L1이 가장 빠릅니다. CPU는 필요한 정보를 그곳에 빠르게 저장합니다.
• 메모리 관리 장치(MMU) :
  MMU는 모든 메모리 및 캐싱 작업을 담당합니다. 일반적으로 CPU에 통합되어 가져오기-디코드-실행 주기 동안 CPU와 RAM 사이의 중개자 역할을 하여 필요에 따라 데이터를 왕복합니다. 또한 소프트웨어에서 제공하는 가상 주소를 RAM에서 사용하는 물리적 주소로 변환합니다.
• 제어 장치 :
  제어 장치는 CPU 작동을 조율합니다. RAM, 논리 장치 및 I/O 장치에 수신된 명령에 따라 작동하는 방법을 알려줍니다.

GPU

이미지와 비디오를 렌더링하는 컴퓨터 구성요소이다. 자체 RAM이 있거나 통합형 CPU와 메모리를 공유한다.

GPU는 특수 CPU와 같으며 특히 멀티태스킹에 적합하다.
CPU와의 가장 큰 차이는 작업을 순차적으로 처리하는 대신 작업을 분할하여 병렬로 실행한다.

따라서 더 많은 코어를 가지고 있고 이러한 추가 코어를 통해 더 많은 계산 및 작업을 한번에 더 효율적을 처리가 가능하다.
하지만 할 수 있는 일의 범위는 보다 제한적이다.

Graceful Shutdown

프로그램이 종료될 때 최대한 side effect를 내지 않기 위해 로직들을 잘 처리하고 종료하는 것을 의미한다.

---

◎ 응답 성능의 병목 현상 해결 방법

먼저 처리량이 몰리는 병목 지점을 명학히 확인해야 한다. 이후 지연시간에 문제를 발생시키는 요소들에 맞는 해결방법을 진행해야 한다.

아래는 대표적인 예들이다.

• 많은 사용자의 서비스 등록
• 많은 데이터의 저장
  • 1,2번과 같은 경우 DB에 데이터가 증가합니다. secondary 복제본 등을 이용해 읽기/쓰기를 분리하거나,
    검색에 최적화된 인덱스 사용을 고려할 수 있습니다.
• 단기간 동안의 사용자 요청 증가(peak traffic)
  • Auto Scaling이 해결책이 될 수 있습니다. 다만 버스트 성능에 대해 이해해야 합니다.
• 배치 작업을 진행하는 데이터베이스
  • DB가 주기적으로 스냅샷을 만들거나, 데이터 일관성을 위해 레플리카와의 sync 과정을 진행하는 등의
    배치 작업이 이루어질 경우, primary DB는 성능 저하가 발생할 수 있습니다.
    이 때 사용자들의 요청과 맞물려 서비스 수준을 맞추기 어려울 수 있습니다.
• 많은 양의 로그 수집 처리
  • 애플리케이션이 잘 작동할 때에는 로그를 많이 남기지 않지만,
    애플리케이션에 문제가 발생하면 추적을 위해 많은 로그를 남깁니다.
    다만 이러한 상황이 반복적으로 진행될 경우, 에러 로그 수집 그 자체가 애플리케이션 병목을 일으킬 수 있습니다.
• 시스템 재시작 후의 캐시 초기화
  • 큰 문제를 발생시키는 것은 아니지만, 캐시가 초기화되면서 시스템으로 직접적인 요청 횟수가 증가할 수 있습니다.