[인프라 공방] 컨퍼런스 신청 - 4. 서비스 성능 진단하기

가용성

• 가용성은 시스템이 서비스를 정상적으로 제공할 수 있는 상태를 의미한다.
• 가용성을 높이기 위해서는 SPOF(Single Point of Failure) 를 없애고 확장성 있는 서비스를 만들어야 한다.

 

1. 성능의 기준 3가지 : users, tps, time

users : 얼마나 많은 사람들이 동시에 사용할 수 있는지
tps : 일정 시간동안 얼마나 많이 처리할 수 있는지
time : 서비스가 얼마나 빠른지

 

[1] user

1. concurrent user & active user
   • concurrent user : 계속해서 요청을 보내지 않는 사용자를 말한다. 즉, 웹 페이지를 그저 띄워두고 있는 사용자를 말한다.
   • active user : 계속해서 요청을 보내는 사용자를 말한다. 성능 테스트에서 VUser 는 Active User 와 유사하다.
2. 유의 사항
   • 성능 테스트는 사용자의 요청이 증대되는 ramp-up 구간이 존재한다. 따라서 실제 트래픽 대응은 테스트 결과보다 더욱 보수적으로 구성하는 것을 권장한다. (보통은 peak time 의 1.5배, 서비스 성격, 비즈니스 임팩트에 따라 3배 넘게 목표 값을 설정하는 경우도 존재한다.)

 

[2] 처리량

1. 처리량??
   • 장비 스펙의 한계로 더 이상 처리하지 못하는 지점이 발생한다. 서비스는 일정 시기까지는 사용자들에게 일정 수준의 응답 시간으로 서비스를 제공하지만 사용자가 많아져 처리해야 할 일들이 스펙에 비해 과할 경우 응답시간이 길어진다.
   • 서버가 처리할 수 없어 대기하는 작업들이 누적되면 응답시간이 급격히 증가한다. 이를 확인하기 위해 필요한 테스트가 스트레스 테스트이다. 스트레스 테스트는 성능의 임계점을 확인하기 위한 테스트이다.
2. 처리량을 늘리기 위해서는 ??
   1. scale up & scale out
      1. 단일 사용자에 대한 응답속도 자체가 느리다면 scale out 하더라도 단일 서버의 스펙은 같으므로 유의미한 개선이 되지 않는다. 이 경우에는 scale up 하는 것이 합리적이다.
      2. 단일 사용자에 대한 응답속도는 괜찮지만 다중 사용자의 요청이 많을 때 응답속도가 느리다면 이 경우에는 scale out 을 통해 대응하는 것이 합리적이다.
   2. 무작정 서버를 늘린다고 처리량을 보장하지 않는다.
      1. WAS 가 증가하여 애플리케이션의 TPS 가 일시적으로 증가하는 듯 보이나 DB의 과부하로 인해 처리하지 못해 대기하는 쿼리가 발생할 수 있다. 이로 인해 지연이 발생하고 결국 TPS(Trasnsaction Per Second) 가 감소하는 현상이 발생한다. 
      2. 그러므로 각 구간별로 병목을 제거하고 성능을 개선해야 한다.

[3] 시간

1. 사용자에겐 응답 시간(response time) 만 존재한다.
   • 사용자 중에서는 화면을 띄우고 있는 사용자도 존재하는데 이 때 화면을 띄우고 있는 시간을 think time 이라 부른다.
2. request time, response time 은 client, network, server 등의 구간의 시간을 포함하고 있다.
   • request time
     • client(TTI 등)
     • network connection open
     • request(network)
   • response time
     • server response
     • response(network)
     • network connection close
     • client(browser rendering 등)
   • 성능 테스트로 주로 개선하는 부분은 server response 구간이다. 원인은 주로 서버 리소스 문제, 프로그램 로직상 문제, DB 혹은 서비스와의 연결 문제 등으로 지연이 발생한다.
3. 진단 방법
   • network connection(인터넷 구간 지연) : 웹페이지 테스트, 페이지 테스트 등
   • server response (서버 구간 지연) : smoke test, load test, stress test
4. 성능 테스트 진행 시 vuser 값을 통제한다. 이 때, 응답시간(time) 을 달성한다면, 대상 시스템은 목표한 처리량(TPS) 를 달성한다고 이해할 수 있다.

 

2. 성능 테스트

성능 테스트 종류 (smoke test, load test, stress test)

 

1. smoke test : 최소한의 부하(VUser 1~2) 로, 테스트 시나리오 오류를 검증한다. 최소 부하상태에서 시스템의 오류(로직)가 없는지 확인한다.
   1. smoke test 에서 응답 시간을 달성하지 못하면 이후의 테스트를 진행하기 이전에, 진단 및 개선을 먼저 해야 한다.
2. load test : 평소 최대 트래픽의 요청에서도 기능이 정상 동작하는지 검증한다.
   1. 서비스 최대 트래픽은 보수적으로 최대 트래픽의 1.5배 정도로 구성한다.
   2. 배포 혹은 인프라 변경(scale out, DB failover 등) 시 처리량 변화, 실패건수 등을 확인한다.
   3. 부하테스트는 30min ~ 2hr 등, QA 를 하는데 필요한 시간을 적절히 할당하도록 한다.
   4. 테스트 중 자원을 효율적으로 사용 여부에 관해서도 파악한다. (CPU/memory 등 리소스, thread 상태, connection 상태 등) 프로그램 로직상 알고리즘 개선, 데이터 캐시, 비동기 처리, 조회 성능 개선, 협력하는 서비스들 관계(서킷 및 다른 서비스에서의 지연) 등에 대한 조치를 하고 다시 테스트를 해보아야 한다
3. stress test : 점진적으로 부하를 증가하도록 구성해 최대 사용자, 최대 처리량 등 한계점이 어디인지를 파악하는 테스트이다.
   1. 만약 각 구간에서 목표 응답시간을 모두 달성하고 있다면, 부하를 더 주어 한계점을 파악해야 한다.
   2. 스트레스 테스트를 통해 확인하고 싶은 정보는 기존에는 VUser 몇까지는 안정적으로 응답했으나, 개선 후 어느 지점까지 안정적으로 운영되었다는 기록을 남기도록 하자. 혹은 현재 몇 대의 서버로 rps 가 몇까지 가능한데, n대 증설시엔 rps가 몇까지 안정적으로 대응 가능하다.

 

[2] 성능 테스트 준비

성능 테스트 준비 과정 : 목표 값 설정 - 시나리오 작성 - 테스트 환경 구성 - 테스트 수행 및 결과 분석

 

 [1] 목표 값 설정

• pinpoint 또는 scouter 등의 apm 도구를 사용하고 있다면 현재 시스템의 rps(response per second) 를 확인한다.
• 신규 오픈 서비스로 수집된 정보가 없다면 경쟁사를 벤치마킹하여 DAU, peak time 집중률(최대 평소 트래픽), 1명당 1일 평균 요청 수 등의 정보를 찾아본다.
• 조회 방법 : 해당 회사 포스트 또는 기사 내용 등등 (e.g. 지하철 노선 조회 : 카카오맵, 서울교통공사...) 설령 못 찾을 경우, 일단 가설을 세우고 테스트를 진행하도록 하자.

(1) 1일 사용자 수(DAU), 1일 평균 rps, 1일 최대 rps
   - DAU * 1명당 1일 평균 접속 수 = 1일 총 접속수
   - 1일 총 접속수 / 86400(seconds per day) = 1일 평균 rps
   - 1일 평균 rps * (최대 트래픽 / 최소 트래픽) = 1일 최대 rps

(2) VUser 설정
   - 특정 시나리오의 요청 수에 따른 응답 시간 = T (VU iteration) = (요청수 * http_req_duration) + a
   - 목표 rrps = (VUser * 요청 수) / 시나리오별 목표 응답시간(T)
   - VUser = (목표 rps * T) *  요청수

만약 시나리오에서 2번의 요청, 요청별 응답 시간 목표 값을 0.2s 라고 가정한다면
T = (2 * 0.2) + 0 = 0.4s
VUser = (1000 * 0.4) / 2 = 200

즉, VUser 값을 200 을 두고 테스트하여 대부분의 요청이 http_req_duration 이 0.2s 를 유지한다면 대상 시스템은 1000 rps 의 처리량을 보장한다고 생각할 수 있다.

 

[2] 시나리오 작성

• 모든 시나리오를 검증하면 좋지만 테스트를 하는데 모두 비용이므로 현재 시스템이 안정적인 가정하에 접속 빈도가 높은 기능, 서버 리소스 소비량이 높은 기능, DB 사용 기능, 외부 시스템과 통신하는 기능을 위주로 테스트하자

[3] 성능 테스트의 어려움

• 테스트 허들
  • 실제 사용자와 접속하는 환경과 유사해야 한다. 만약, 내부 네트워크에서 부하를 발생시킬 경우에는 네트워크 구간에 해당하는 시간이 누락된다.
  • 클라이언트 내부 처리시간 배제하면 안된다. 성능 테스트에서는 클라이언트 내부 처리시간이 배제되어 있다. 운영환경에서 서비스 요청 외에 별도로 수행되는 배치(cron job) 이나 후속 작업이 있다면 서버에 일정 부하를 주어 유사하게 구성하거나 테스트 시나리오에 포함해야 한다.
  • 결제 등으로 외부 요청을 하는 경우 시스템과 분리된 별도의 서버로 구성해야 한다. 이런 여러가지 구성이 어려울 경우, VUser 계산식의 a 값에 예상 지연시간을 두어 도출한다.
• DB 데이터 수준
  • test db 의 경우, 데이터 양이 실제 운영 DB 와 동일한 수준이어야 한다.
    • 웹 서비스의 경우, 처리 성능의 상당 부분을 DB 조회에 영향을 받기 때문이다.
    • 데이터가 소량이라면 disk i/o 가 발생하지 않으므로 모두 메모리에서 로드되어 성능이 빠른 것으로 착각할 수 있다.
  • 추가적으로 test db 는 개인정보동의 항목이 아니므로, 스냅샷을 뜬다면 개인 정보는 모두 마스킹 처리를 해두어야 한다.
    • 테스트 환경 구성할 요소가 너무 많다면 최소한 test db 구성만큼은 해두어야 한다.
    • 저자는 나머지의 경우 alpha 로 생각해서 구성해야 한다고 생각한다.