서버 부하 테스트 전략과 프로세스, 분석 방법

1. 서버 부하 테스트
   
   1. 서버 부하 테스트란?
      • 임계점이 한계에 도달할 때까지 시스템 부하를 증가시켜, 부하 상황에서 서버의 동작을 확인하는 테스트.
      • 서버 부하 상황에서도 안정적으로 서비스가 이루어질 수 있도록 보장하는 활동이다.
      • 이를 통해 얼마나 큰 규모의 인프라를 운영할 지 예측할 수 있고 유저에게 좋은 경험을 제공할 수 있다.
   2. 서버 부하 테스트에서 품질 관리자의 역할
      • 서버 부하 테스트는 서버 개발자에 의해 반드시 테스트 되지만, 서버 자체의 부하만 측정한다는 한계가 있다.
        • 임계값을 산정하고 부하 상황에서 시스템 동작을 예측하여 테스트 방향을 결정해야 한다.
        • 부하 테스트를 통해 관측된 지표를 모니터링하고 결과를 분석하여 scale up/out 을 결정한다.
        • 부하발생 중 서버가 요청을 잘 처리하는 지, 병목 발생 지점이 어디인지 확인 후 개선포인트를 도출한다.
      • 품질 관리자의 서버 부하 테스트는 유저 관점에서 개선 포인트를 도출 및 권고사항을 전달에 목적이 있다.
        
        • 테스트 수행을 위한 부하 테스트 품질 기준을 설정한다.
        • 과거 지표 또는 타사 유사 사례 분석으로 실제 발생할 수 있는 임계값을 산정한다.
        • 유저 패턴과 유사한 테스트 시나리오를 구상한다.
        • 부하 발생 시, 주요 기능과 콘텐츠 등 서비스 라이브러리 기반으로 테스트 방향을 결정한다.
        • 부하 상태에서 실제 제품을 사용함으로써 안정적인 서비스가 제공되는 지 확인한다.
        • 부하로 인한 장애 발생 시 서비스 영향도와 대응이 필요한 지점에 대한 개선 포인트를 도출한다.
        • 개선 포인트의 경우, 명확한 개선 요구사항을 제공한다. (유사 서비스 개선 사례, 서비스 개선을 경험한 기존 서버 이력, 테스트를 통한 성능 검증 지표 및 데이터 기록 등을 참고한다.)
      • 개발자 관점에서만 부하 테스트 진행 시, 유저의 클라이언트 이슈와 서비스 영향도를 고려하지 못할 수 있다.
      • 즉, 안정적인 시스템 관리와 운영 관리를 만족하기 위해 개발과 테스터가 참여해야 한다.
   3. 개발과 테스터가 함께 진행하는 서버 부하 테스트는 언제 진행하는 것이 좋은지
   4. 테스트 종류에는 어떤것이 있는지
   5. 종류별 테스트 목표와 방법은 어떻게 설계할 수 있을지
   6. 모니터링 지표는 어떻게 분석하여 어떤 개선 포인트를 도출할 수 있을지
2. 서버 부하 테스트 진행 시기
   1. 신규 서비스
      • 개발/테스트 환경이 아닌, 라이브에서 실제 사용할 서버가 준비된 시점에 테스트가 수행된다.
      • 개발과 테스트가 마무리되는 시점 또는 라이브 배포 전 스테이징 서버 환경에서 테스트가 진행된다.
   2. 기존 운영중인 서비스
      • 실시간 트래픽 과부하 발생이 예상되는 신서비스 및 이벤트 오픈을 앞두고 있을 때 수행된다.
      • 기존 서비스에서 병목될 가능성이 있는 변경사항이 있을 때 수행된다.
      • 라이브 서버는 실제 운영환경에서 사용중이기 때문에, 스테이징 환경에서 일반적으로 진행된다.
3. 서버 부하 테스트 전략
   1. 서버 부하 테스트 목적과 목표
      • 안정적인 서비스 운영을 위한 안정성 확보, 적합성을 판단하는 데 목적을 둔다.
      • 목표 달성 여부, 서버의 가용성, 확장성, 안정성이 보장되는 지 검증하고 목표 달성까지 테스트를 반복한다.
      • 시스템 최대 성능과 용량을 도출하고 구간별 병목 발생 지점, 성능 저하 요소, 개선 포인트를 전달한다.
      • 테스트 목표 (품질 특성 표준 기준)
        • 효율성 : 적절한 서버 응답 시관과 안정된 리소스 사용률을 사용하여 서비스를 제공한다.
        • 안정성 : 장기간동안 안정적인 서비스가 제공된다.
        • 가용성 : 많은 유저에게 안정적인 서비스를 제공한다.
        • 신뢰성 : 목표 시간동안 정상적인 결과를 반환한다.
        • 확장성 : 서비스 사용량에 따라 시스템 확장성을 보장한다.
        • 연속성 : 장애 발생 시, 서비스의 연속성을 보장한다.
   2. 서버 부하 테스트 품질 기준
      • 응답 시간, 시간당 부하 처리량, 서버 요청 속도, 운영 조건 등이 포함된다.
      • 사용량이 갑자기 급증하는 동적 시스템 품질을 확인하고 최적화하는 데 중요한 요소이다.
      • 테스터는 명확한 품질 기준을 마련하여 정확한 결과 데이터와 수정/개선사항에 대한 의견을 제시해야 한다.
4. 서버 부하 테스트 프로세스
   1. 서버 부하 테스트 절차 설계
      • 서버 품질에 대한 확인이 누락되거나 지연되지 않도록 프로세스를 정립하여 체계적인 업무를 진행한다.
      • 서버/인프라 개발자와의 협업 진행 중에 혼란과 부조화가 발생하지 않도록 수행 단계를 절차화한다.
      • 프로젝트 초반부터 업무가 진행될 수 있도록 절차를 마련한다.
      • 테스트 프로세스는 서버 구성 계획 완료 시점을 고려하여 설계한다.
      • 테스트 수행 기간 및 단계는 서버 인프라 작업 기간을 고려하여 계획한다.
   2. 서버 테스트 과정
      • 경량 프로세스 : 개발자와 협업 과정을 제외하고 테스트 업무에 초점을 둠
        

        성능 테스트 과정	성능 테스트 실행 내용
        성능 테스트 시나리오 구상	시스템의 어느 부분에 어떻게 부하를 줄 것인지 결정
        성능 테스트 환경 구성	부하 상황에서의 시스템 동작을 예측하여 필요한 데이터를 준비
        테스트 스크립트 작성 및 테스트 실행	시나리오에 따라 테스트 코드 작성, 실제 부하를 발생시키면서 성능 테스트 수행
        테스트 결과 지표 분석 및 보고	모니터링 지표를 분석하여 결과를 공유함. 수정 또는 개선 작업이 완료되면 성능 테스트 환경 구성부터 다시 진행.

      • 중량 프로세스 : 개발자와 협업 과정을 포함한 테스트 과정
        

        성능 테스트 과정	성능 테스트 실행 내용
        준비 단계	인프라/서버 개발자는 테스트 시나리오 작성을 위해 서버 구조 및 아키텍처 리뷰 진행. 테스트 담당자는 서버 구조를 분석하여 설계상 오류가 없는지 검증. 테스트 대상과 범위를 선정하고, 서버의 임계값/개선 사항을 확인하여 테스트 준비. 테스트 준비, 수행, 예외상황 대응 기간으로 구분하여 테스트 일정을 설계하고 계획한다.
        테스트 도구 선정	JMeter, Pinpoint, Locust , LoadRunner, nGrinder, apache Bench 등 다양한 도구가 있음 유저 시나리오 기반 테스트가 가능하고 요청을 정확히 시뮬레이션 해야 함. 동시 접속자 수, 요청 관격, 최대 TPS 등 직접 부하를 조정할 수 있어야 함. 시스템 부하를 주는 기능 뿐 아니라 리소스 사용율을 가시화 가능해야 함. 애플리케이션 내부 동작을 분석해주는 기능이 제공되어야 함. 테스트 대상이 되는 서버에 충분한 부하를 발생시킬 수 있는지 확인 부하 테스트 도구 설치 및 가동 장소를 직접 설치할 수 있는지 확인
        테스트 설계 및 구현 단계	과거 지표/기존 서버 또는 유사 사례를 조사해 임계치와 가중치로 품질 기준을 마련. 품질 기준을 토대로 검증 필요 기능과 주요 콘텐츠를 중심으로 테스트 대상 선정 테스트 요구사항을 수집하여 시나리오 설계하고 테스트 코드를 작성 테스트 코드에는 임계값과 부하 시간이 필요한데, 논의를 통해 선정해야 한다.
        부하 테스트 환경 구축	성능 테스트를 위해 Load Agent, Controller, Remote Monitoring System, Profiling Server, Web Server, WAS Server, DB가 필요하다. 라이브 환경과 동일한 환경 또는 실제 운영장비를 대상으로 테스트 환경을 준비. 기존 테스트/라이브 환경과 분리된 독립된 네트워크를 구성하여 부하 발생 및 모니터링 시스템들을 테스트 타깃 시스템들 동일 네트워크에 존재하도록 환경을 구축=. 테스트 환경과 라이브 환경 차이를 최대한 줄이는 것이 좋다.
        통합 테스트 단계	부하 테스트 도구를 활용하여 시나리오에 따라 작성된 테스트 코드를 실행. 목표 달성 여부를 확인하여 목표를 달성할 때까지 반복해서 진행. 테스트 완료 시, 서버 모니터링 지표를 분석. 병목 발생 지점, 응답성, 안정성, 부하에 따른 시스템 동작 처리, 부하로 인해 발생하는 기능 및 사용성 이슈, 개선점을 도출하여 결과를 공유. 결과에 따라 서버 수정 혹은 개선 후 테스트를 반복 수행해 트랜잭션 처리 결과도 공유.

5. 서버 부하 테스트의 종류
   

   출처 : https://abstracta.us/blog/performance-testing/how-to-make-a-performance-test-plan/

   
   
   1. 단위 테스트
      • 서버 단일 구성을 기준으로 테스트 대상 각 기능의 최대 임계 TPS를 측정하고 발생하는 문제를 사전에 찾기 위한 테스트이다.
      • 기능별 최대 성능 도출, 구간별 병목 구간 도출, 목표 성능 만족 여부 검증 및 임계치 확인을 목적으로 한다.
   2. 스파이크 테스트 (PEAK Test)
      • 스트레스 테스트의 하위 집합
      • 테스트 대상 시스템에 최대 부하를 짧은 시간동안 반복적으로 증가시킬 때 시스템 동작을 검증한다.
      • 장애 발생 시, 시스템이 복원하는 과정을 확인한다.
      • 유저 패턴과 유사한 테스트 시나리오를 재현하여 시스템 최대 성능을 측저앟ㄴ다.
      • 시스템 최대 용량을 산정하고, 순간적인 유저 과접속을 재현해 서버 안정성을 검증하는 데 목적을 둔다.
      • 목표 성능은 시스템 구성과 사업 목표, 마케팅 등을 고려해 최대 동시 사용 유저 수로 예상 용량을 산정한다.
   3. 서버 확장성 테스트
      • 유저 예외, 프로세서의 수, 데이터 불륨 등 기능적인 측면에서 축소할 수 있는 기능을 특정하기 위한 테스트
      • 시스템을 병렬로 구성하여 확장 예정인 구간에 대한 확장 가능성과 보장여부 판단을 목적으로 한다.
      • 비즈니스 로직 및 기능별 가중치를 적용한 통합 시나리오로 테스트를 진행한다.
      • 통합 시나리오는 테스트 분석 단계에서 각 구간별 서버 확장에 대한 시나리오를 사전에 정의하고 진행한다.
   4. 예외 처리 (장애 대응)
      • 발생가능한 예외 상황과 유사한 테스트 시나리오를 재현해 부하 상태에서 시뮬레이션을 진행하는 테스트
      • 서비스 운영 중 발생할 수 있는 예외상황에 대한 영향도를 파악하고 안정성 검증을 위해 테스트를 진행한다.
      • fail-over (서버 다운 현상)
        • 서버 다운 순간 데이터 유실이나 접속 불가 같은 문제가 발생하지 않는 지 확인한다.
        • 서버 이중화 처리를 통해 다운된 서버의 유저를 다른 서버로 옮기거나, 자동으로 서버 스펙 확장/축소 처리를 목적으로 한다.
      • look back (병목 지점 도출)
        • 시스템의 논리적 구간 중 특정 지점에 loop back 코드를 삽입하여 병목 지점을 도출할 수 있다.
   5. 롱런 테스트
      • 서버를 장시간 연속 가동 시 서버 처리 능력이나 가동률에 문제가 발생하지 않는지 확인하는 테스트
      • 동접의 부하 수준(80%~100%) 으로 24시간 이상 가동했을 때 안정적인 서비스가 제공되는지 검증한다.
      • 기능에 대한 비즈니스 로직과 기능별 가중치를 적용한 통합 시나리오를 사용하여 테스트를 진행한다.
      • 장시간 서비스 운영 유지 시, 서버다운, 메모리 누수, 규칙적 CPU 사용율에 대한 안정성을 점검한다.
      • 장시간 부하  상황에서 서버 확장성 테스트가 만족하는 수준의 서응이 보장되는지 검증한다.
   6. 사용자 테스트
      • 시스템이 목표 수준의 부하를 처리하는 상태에서 서버에 접속하는 주요 기능 동작을 확인하는 테스트.
      • 부하 상태에서 안정적인 서비스가 제공되는지를 목표로 한다.
      • 성능 테스트 시나리오에 포함되지 않는 기능 및 유저 패턴도 추가하여 테스트를 진행한다.
      • 부하가 없는 상태에서의 기능 테스트 결과와 동일한 수준으로 만족하는지 확인한다.
6. 서버 부하 모니터링 지표 분석 방법
   
   1. 좋은 서버, 나쁜 서버의 성능 지표
      • 좋은 서버 지표는 TPS가 꾸준히 상승하고 목표 시간동안 일정한 수준의 응답 시간을 나타내야 한다.
        
      • 나쁜 서버 지표는 TPS가 임계점에 다다르면 증가폭이 줄어들거나 멈추고, 응답시간 또한 임계점에서 급격히 증가한다. 
        
      • 만약 나쁜 서버라고 판단되면, 임계점을 기준으로 병목현상을 확인하고 결과를 공유한다.
   2. 메모리 성능 지표
      • 좋은 메모리 성능 지표는 동시 접속 부하 유입 시, 장시간 메모리 누수 없이 일정한 수준을 유지한다.
      • 나쁜 지표는 사용완료된 객체에 대한 참조를 해제하지 않아 시스템의 메모리 누수가 지속적으로 발생한다. 
   3. 나쁜 지표의 주요 원인과 개선 포인트
      • 성능 저하가 발생하는 원인
        • 패킷, 캐시, 메모리, DB, 인프라 등에서 발생하는 명목 현상
        • 참조 해제를 하지 않은 상태
        • 코드상 스레드 세이프를 하지 않은 경우 (여러 스레드로부터 동시접근이 이루어져도 안정적인 상태)
        • 서버 로직이나 DB 쿼리의 최적화나 개선 작업이 필요하거나, 네트워크 레이턴시 사용량이 높음
      • 어느 지점에서 성능 저하나 병목 구간이 발생하는지 지표를 지속적으로 관측하고 기록, 분석해야 한다.
      • 병목구간 확인하면  테스트 진행중에 서버에 접속하여 컨테이너 로그를 확인하여 특이점이 없는지 분석함으로써 문제의 요인을 찾을 수 있다.