확장성 테스트란 무엇입니까? 예를 들어 배우기

⚡ 스마트 요약

확장성 테스트는 사용자 부하, 데이터 볼륨 또는 트랜잭션 속도가 증가하거나 감소할 때 애플리케이션의 동작 방식을 측정하여 성능이 더 이상 확장되지 않는 정확한 지점과 그 원인이 되는 병목 현상을 파악합니다.

  • 🔘 정의: 수요 증가에 따라 시스템이 여전히 허용 가능한 수준으로 작동하는지 확인하는 비기능 테스트입니다.
  • ☑️ 두 방향: 수직 확장은 한 대의 장비에 전력을 추가하는 것이고, 수평 확장은 밸런싱 장치 뒤에 더 많은 장비를 추가하는 것입니다.
  • 주요 측정항목: 응답 시간, 처리량, CPU 및 메모리 사용량, 네트워크 활용률은 다음과 같습니다. trac모든 로딩 단계에서 확인되었습니다.
  • 🧪 방법 : 부하가 계획된 증분으로 증가하다가 특정 지표가 임계값을 넘어서면 확장성 한계에 도달합니다.
  • 🛠️ 압형: JMeterk6, Gatling, Locust 및 LoadRunner는 분산 부하를 생성하고 결과를 자동으로 기록합니다.
  • 📈 결과: 용량 계획이 추측이 아닌 증거 기반으로 이루어지므로 트래픽 급증에도 릴리스가 안정적으로 유지됩니다.

확장성 테스트란 무엇인가요?

확장성 테스트란 무엇인가요?

확장성 테스트 확장성 테스트는 사용자 요청 수의 증가 또는 감소에 따른 시스템 또는 네트워크 성능을 측정하는 비기능 테스트 방법입니다. 확장성 테스트의 목적은 시스템이 예상되는 사용자 트래픽, 데이터 볼륨 및 트랜잭션 빈도의 증가를 처리할 수 있는지 확인하는 것입니다. 즉, 증가하는 수요에 대응할 수 있는 시스템의 능력을 테스트하는 것입니다.

확장성 테스트는 하위 유형입니다. 성능 시험따라서 이 연구는 애플리케이션이 더 큰 시스템에 배포되거나 과부하 상태에서 실행될 때의 동작에 초점을 맞춥니다. 소프트웨어 공학확장성 테스트는 애플리케이션이 더 이상 확장되지 않는 시점을 측정하고 그 원인을 파악합니다.

확장성 테스트를 하는 이유는 무엇일까요?

용량 문제는 기능 테스트 중에 거의 나타나지 않습니다. 이러한 문제는 연중 가장 바쁜 거래일, 마케팅 캠페인이 시작될 때, 또는 2년 동안 조용히 증가해 온 데이터 세트가 마침내 모든 쿼리 속도를 저하시킬 때 드러납니다. 확장성 테스트는 통제된 환경에서 이러한 한계를 먼저 파악하도록 도와줍니다. 구체적으로 다음과 같은 이점을 제공합니다.

  • 애플리케이션의 작업 부하 증가에 따른 확장성과 그 곡선이 평탄해지는 지점을 파악합니다.
  • 웹 애플리케이션의 응답 시간이 허용할 수 없는 수준이 되기 전에 동시 사용자 수 제한을 설정하십시오.
  • 클라이언트 측 성능 저하 및 부하 시 최종 사용자 경험(예: 화면 렌더링 속도 저하)을 파악합니다.
  • CPU 포화, 메모리 누수 및 연결 풀 고갈을 포함한 서버 측 안정성 및 성능 저하를 파악합니다.

이 관계는 곡선으로 시각화하는 것이 가장 쉽습니다. 처리량은 리소스가 포화될 때까지 부하가 ​​증가함에 따라 상승하며, 그 이후에는 추가 사용자로 인해 대기열만 길어질 뿐입니다.

확장성 테스트는 작업 부하가 증가함에 따라 시스템 성능을 측정합니다.

확장성 테스트 유형

확장성은 단일 속성이 아니므로 테스트 계획은 일반적으로 여러 측면을 다룹니다. 아래 네 가지 유형은 대부분의 팀에서 측정하는 요소이며, 처음 두 가지 유형이 테스트 환경의 형태를 결정합니다.

타입 스케일링이란 무엇인가 이 검사가 증명하는 것
수직적 확장성 (규모 확대) 단일 서버에 CPU, 메모리 또는 스토리지 추가 업그레이드된 장비 하나가 얼마나 더 많은 부하를 흡수할 수 있는지, 그리고 단일 노드의 한계는 어디까지인지
수평적 확장성 (확대/축소) 로드 밸런서 뒤에 추가 서버, 컨테이너 또는 노드 처리량이 추가된 노드 수에 비례하여 증가하는지, 아니면 공유 리소스가 처리량을 제한하는지 여부.
기능적 확장성 새로운 기능, 모듈 또는 서비스 추가 기능을 기존 거래의 품질 저하 없이 수용할 수 있는지 여부
관리 확장성 관리할 사용자, 테넌트, 팀 또는 환경 조직 규모가 커짐에 따라 온보딩, 권한 관리 및 모니터링이 원활하게 작동할지 여부

수직 확장은 아키텍처가 거의 변경되지 않기 때문에 더 간단하지만, 단일 머신에는 항상 한계가 있습니다. 수평 확장은 이러한 한계를 없애고 내결함성을 향상시키지만, 네트워크 지연 시간, 데이터 일관성 및 조정 오버헤드가 증가합니다. 이러한 모든 요소는 테스트에서 가정하는 것이 아니라 측정해야 합니다.

확장성 테스트에서 무엇을 테스트해야 할까요?

확장성은 노출이 아닌 측정값을 기준으로 판단합니다. 추세를 파악하고 최종 수치뿐만 아니라 전체적인 변화를 확인하려면 모든 로드 단계에서 다음 속성을 기록하십시오.

속성 그것이 당신에게 말하는 것
응답 시간 사용자 요청과 시스템 응답 사이의 시간 간격은 동시 접속자 수가 증가하더라도 일정하게 유지되어야 합니다.
화면 전환 부하가 걸렸을 때 한 페이지 또는 뷰가 다음 페이지로 넘어가는 속도
맞춤형 설비 단위 시간당 처리되는 요청량; 특정 지점에서 포화 상태에 도달하면 확장성 한계를 나타냅니다.
시간 측정 세션 시간, 재부팅 시간, 인쇄 시간, 트랜잭션 시간 및 작업 실행 시간
사용자 수 대비 성능 동시 접속 사용자 수가 점진적으로 증가함에 따라 각 지표가 어떻게 변화하는지
요청률 초당 요청 수, 초당 트랜잭션 수 및 초당 히트 수
네트워크 사용 계층 간 대역폭 소비량 및 패킷 지연 시간
CPU 및 메모리 사용량 거래당 자원 비용; 지속적으로 상승하는 수치는 종종 정보 유출을 나타냅니다.
웹 서버 카운터 초당 요청 및 응답 수, 큐 깊이 및 거부된 연결 수
부하 하에서의 성능 모든 지표를 피크 시점에 함께 읽어들였을 때의 통합된 동작

확장성 테스트를 위한 테스트 전략

확장성 테스트를 위한 테스트 전략은 테스트 대상 애플리케이션 유형에 따라 다릅니다. 애플리케이션이 특정 리소스에 접근하는 경우, 데이터베이스테스트 매개변수에는 사용자 수 대비 데이터베이스 크기 등이 포함됩니다.

확장성 테스트를 위한 전제 조건

  • 부하 분산 기능 — 부하 테스트 도구가 여러 대의 장비에서 부하를 생성하고 중앙에서 제어할 수 있는지 확인하십시오.
  • Opera팅 시스템 — 무엇을 확인하세요 운영체제 부하 생성 에이전트와 부하 테스트 마스터는 다음 환경에서 실행됩니다.
  • 프로세서 — 가상 사용자 에이전트와 부하 테스트 마스터에 필요한 CPU 유형을 확인하십시오.
  • 메모리 — 가상 사용자 에이전트와 부하 테스트 마스터에 필요한 메모리 용량을 확인하십시오.
  • 테스트 환경 — 다음 사항을 확인하세요 테스트 환경 생산 과정을 충분히 유사하게 모방하여 결과가 그대로 적용될 수 있도록 합니다.

확장성 테스트를 수행하는 방법

  1. 애플리케이션 수명 주기 전반에 걸쳐 확장성 테스트를 실행하기 위한 반복 가능한 프로세스를 정의하십시오.
  2. 확장성에 대한 기준 결정
  3. 부하 테스트를 실행하는 데 필요한 소프트웨어 도구를 선별합니다.
  4. 확장성 테스트에 필요한 테스트 환경 설정 및 하드웨어 구성
  5. 테스트 시나리오와 확장성 테스트를 계획하십시오.
  6. 가상 사용자 스크립트를 생성하고 검증합니다.
  7. 부하 테스트 시나리오 생성 및 확인
  8. 테스트 실행
  9. 결과 평가
  10. 필요한 보고서를 생성하세요

확장성 테스트 계획

실제로 테스트를 작성하기 전에 상세한 테스트 계획을 수립하십시오. 이는 테스트가 애플리케이션 요구 사항을 충족하는지 확인하는 중요한 단계입니다.

잘 정의된 것을 만드는 데 필요한 속성은 다음과 같습니다. 테스트 계획 확장성 테스트용.

  • 스크립트 단계테스트 스크립트에는 사용자가 수행할 정확한 작업을 파악하는 자세한 단계가 포함되어야 합니다.
  • 런타임 데이터테스트 계획은 애플리케이션과 상호 작용하는 데 필요한 런타임 데이터를 파악해야 합니다.
  • 데이터 기반 테스트스크립트 실행 시 데이터가 변경될 필요가 있는 경우, 해당 데이터가 필요한 모든 필드를 이해해야 합니다.

확장성 테스트 예시

계절 세일 기간 동안 동시 접속 고객이 2,000명에 달할 것으로 예상되는 온라인 쇼핑몰을 가정해 보겠습니다. 팀은 먼저 다음과 같은 통과 기준에 동의합니다. 결제 거래는 사용자 95%에게 3초 이내에 완료되어야 하며, 오류율은 1% 미만이어야 합니다.

이 테스트는 250, 500, 1,000, 1,500, 2,000명의 가상 사용자 수를 대상으로 동일한 검색-장바구니-결제 스크립트를 실행합니다. 응답 시간은 1,000명까지는 약 2초를 유지하다가 1,500명에서는 2.8초로 증가하고, 2,000명에서는 9초에 도달하며, 이 시간 동안 데이터베이스 CPU 사용률은 98%에 이릅니다. 따라서 확장성 한계는 대략 1,500명이며, 병목 현상은 팀이 추가하려고 했던 애플리케이션 서버가 아니라 데이터베이스 계층에 있습니다.

확장성 테스트 도구

확장성 테스트를 위해서는 여러 대의 머신에서 동시에 부하를 발생시키고 결과를 중앙에서 보고할 수 있는 도구가 필요합니다. 도구 선택은 일반적으로 팀의 주요 프로그래밍 언어와 테스트 대상 프로토콜에 따라 결정됩니다.

수단 스크립팅 가장 적합
Apache JMeter GUI 및 XML 테스트 계획 Java 기반으로 JDBC, JMS, LDAP 및 SOAP를 포함한 광범위한 프로토콜 지원
그라파나 k6 Java스크립트 또는 TypeScript CI/CD 파이프라인에 통합된 API 및 마이크로서비스 테스트
개틀링 JavaKotlin 또는 Scala DSL 주입기별 높은 가상 사용자 수 및 상세 HTML 보고서
메뚜기 평원 Python Python HTTP를 넘어 클라이언트 기능을 확장해야 하는 팀
LoadRunner VuGen에 기록된 C와 유사한 스크립트 대규모 기업 환경은 레거시 애플리케이션과 패키지 애플리케이션을 사용합니다.

클라우드 호스팅 실행기(예: ...) BlazeMeterLoadView와 Gatling Enterprise는 이러한 엔진들을 기반으로 구축되었으며, 수만 명의 가상 사용자 또는 여러 지역의 트래픽이 필요한 테스트에 고려해 볼 만합니다. 이 범주에 대한 더 자세한 내용은 가이드에서 확인할 수 있습니다. 성능 테스트 도구.

확장성 테스트의 과제와 모범 사례

확장성 측면에서 가장 실망스러운 결과 trac애플리케이션보다는 테스트 환경으로 돌아가 보겠습니다. 이러한 문제들이 반복적으로 발생하며, 이러한 문제들을 예방하는 습관들도 중요합니다.

일반적인 과제

  • 크기가 작은 환경 — 실제 운영 환경의 절반 메모리를 사용하는 테스트 장비에서 실제 운영 환경에서는 존재하지 않는 병목 현상이 보고되었습니다.
  • 비현실적인 작업 부하 모델 — 생각 시간이나 데이터 변동이 없는 스크립트는 실제 사용자가 놓칠 수 있는 캐시를 찾습니다.
  • 노이즈가 많은 결과 자동 스케일링, 가비지 컬렉션 및 공유 클라우드 하드웨어로 인해 동일한 두 실행 결과가 서로 다르게 나타날 수 있습니다.
  • 얇은 관측 가능성 서버 측 메트릭이 없으면 느린 결과는 무언가 문제가 발생했음을 보여주지만 무엇이 문제인지는 알 수 없습니다.
  • 비용 — 매우 높은 동시 접속률을 생성하려면 별도의 부하 발생기 시스템이 필요한데, 이는 예산 부족으로 이어지기 쉽습니다.

모범 사례

  • 첫 실행 전에 응답 시간 백분위수 및 오류율 상한선과 같은 합격 기준을 합의하십시오.
  • 계획된 단계적으로 부하를 증가시키고 시스템이 안정화될 수 있도록 각 단계를 충분한 시간 동안 유지하십시오.
  • 캐싱으로 인해 결과가 왜곡되지 않도록 가상 사용자별로 테스트 데이터를 다르게 설정하십시오.
  • 클라이언트 측 수치와 함께 애플리케이션, 데이터베이스 및 인프라 관련 지표를 수집하십시오.
  • 테스트 스크립트를 버전 관리 시스템에 저장하고, 빌드할 때마다 간단한 확장성 검사를 실행한 다음, 릴리스 전에 전체 실행을 실시합니다.
  • 개별 보고서만 놓고 판단하기보다는 여러 건축물에 걸친 추세를 비교하십시오.

확장성 테스트 vs 부하 테스트

두 가지는 모두 부하를 적용하기 때문에 종종 혼동됩니다. 차이점은 각각 답하는 질문에 있습니다. 확장성 테스트는 시스템이 얼마나 확장될 수 있는지를 묻는 반면, 부하 테스트 이미 예상되는 부하를 감당할 수 있는지 묻습니다.

베이스 확장성 테스트 부하 테스트
초점 이는 증가하는 요구 사항을 충족하기 위해 시스템 규모나 용량이 변경될 때 웹사이트, 소프트웨어, 하드웨어 및 애플리케이션의 성능에 중점을 둡니다. 부하 테스트는 애플리케이션에 과부하가 걸린 상태에서 시스템을 테스트하여 시스템 응답 시간이 한계에 도달하는 시점을 파악하는 데 중점을 둡니다.
부하 패턴 부하는 단계적으로 증가하며, 각 단계 사이에 리소스가 추가될 수 있습니다. 부하가 일정 시간 동안 예상되는 최대치로 유지됩니다.
질문에 대한 답변 이 시스템은 어디까지 성장할 수 있으며, 어떤 제약이 있을까요? 이 시스템은 현재 합의된 목표를 달성하고 있습니까?
일반적인 출력 확장성 한계, 병목 현상 및 용량 계획 응답 시간 및 처리량 목표에 대한 합격 또는 불합격 여부

둘 다 아래에 앉아 있다 비기능 테스트 우산과 함께 스트레스 테스트, 스파이크 테스트, 지구력 테스트 볼륨 테스트일반적으로 완성도 높은 성능 향상 전략은 동일한 스크립트에 대해 여러 개의 테스트를 실행합니다.

자주 묻는 질문

머신러닝 모델은 과거 실행 데이터를 읽어 어떤 지표가 먼저 변동했는지 파악하고, 실제 회귀를 클라우드 노이즈와 구분하며, 리소스가 포화 상태에 이를 부하 수준을 예측합니다. 현재 여러 상용 플랫폼에서 이러한 기능을 자동화된 사후 분석 기능으로 제공하고 있습니다.

네. 부조종사 및 유사 에이전트 초안 k6 Locust 시나리오와 같은 도구를 사용하여 매개변수화된 테스트 데이터를 생성하고 CI 파이프라인 단계를 신속하게 구성할 수 있습니다. 하지만 성능 엔지니어는 실제 운영 환경에서 발생하는 동작을 기반으로 현실적인 사고 시간, 워크로드 구성 및 통과 기준을 설정해야 합니다.

확장성은 리소스가 추가될 때 규모를 키울 수 있는 능력을 의미하며, 추가되는 데 몇 분이 걸리든 몇 달이 걸리든 상관없습니다. 탄력성은 수요 변화에 따라 리소스를 자동으로 추가하고 해제한 다음, 수요 변동이 끝나면 다시 축소된 규모로 돌아갈 수 있는 능력을 말합니다.

스크립트와 모니터링 작업이 제대로 작동하는지 확인하기 위해 예상 최고치보다 10~20% 정도 낮은 값에서 시작하십시오. 목표치까지 그리고 목표치를 넘어서면서 카운트를 단계적으로 높여가십시오. 흥미로운 동작은 특정 수치에서 나타나는 것이 아니라 두 단계 사이에서 나타나기 때문입니다.

단일 사무실 컴퓨터로는 수만 개의 세션을 생성할 수 없으며, 다른 지역에 있는 사용자가 경험하는 지연 시간을 재현할 수도 없습니다. 클라우드 테스트 필요에 따라 여러 지역에 부하 발전기를 공급하고 가동이 완료되면 해제합니다.

빌드할 때마다 간단한 검사를 실행하여 하루 안에 회귀 오류를 발견하고, 아키텍처, 데이터베이스 스키마 또는 트래픽 예상치가 변경되는 릴리스 전에는 전체 단계별 테스트를 반드시 실행해야 합니다. 출시 일주일 전까지 기다리면 테스트에서 발견된 오류를 수정할 시간이 없습니다.

시스템 장애로 인한 거래 손실 외에도, 페이지 로딩 속도 저하는 방문자를 경쟁사로 몰아넣고 검색 순위 하락으로 이어집니다. 소매 및 티켓 판매의 경우, 이러한 장애는 대개 연중 매출이 가장 높은 날, 즉 트래픽이 급증할 것으로 예상되는 날에 발생합니다.

스크립팅 Java스크립트, Python or JavaHTTP 및 데이터베이스 동작에 대한 실무 지식, 서버 및 컨테이너 메트릭을 읽는 능력, 백분위수와 평균을 구분할 수 있는 통계 지식이 필요합니다. 클라우드 및 CI/CD에 대한 이해는 거의 필수적입니다.

이 게시물을 요약하면 다음과 같습니다.