확장성 테스트

Scalability testing

확장성 테스트는 소프트웨어 애플리케이션의 비기능적 기능 측면에서 스케일업 또는 스케일아웃 기능을 측정하기 위한 테스트다.

성능, 확장성 및 안정성 테스트는 일반적으로 소프트웨어 품질 분석가가 함께 그룹화한다.

확장성 테스트의 주요 목표는 웹 애플리케이션에 대한 사용자 제한을 결정하고 높은 부하 조건에서 최종 사용자 환경이 손상되지 않도록 하는 것이다.한 가지 예는 제한된 응답 지연으로 적시에 웹 페이지에 접속할 수 있는지 여부다.또 다른 목표는 서버가 대처할 수 있는지 확인하는 것이다.서버가 과부하 상태일 경우 작동이 중단되는가?[1]

테스트 중인 애플리케이션에 따라 다른 파라미터가 테스트된다.웹 페이지를 테스트하는 경우, 가능한 최대 동시 사용자 수를 테스트할 수 있다.[2]또한 테스트되는 애플리케이션에 따라 CPU 사용량, 네트워크 사용량 또는 사용자 환경을 포함할 수 있다.

성공적인 테스트는 네트워크, 데이터베이스 또는 하드웨어/소프트웨어와 관련된 대부분의 문제를 투영할 것이다.[3]

확장성 테스트 생성

새로운 애플리케이션을 만들 때 1, 2년, 심지어 5년 안에 사용자 수를 정확하게 예측하기 어렵다.추정은 할 수 있지만 확실한 숫자는 아니다.사용자 수가 증가하는 문제는 그것이 새로운 실패 영역을 만들 수 있다는 것이다.예를 들어, 10만 명의 새로운 방문자가 있는 경우, 응용프로그램에 대한 액세스만 문제가 될 수 있는 것이 아니라, 새로운 고객의 모든 데이터를 저장해야 하는 데이터베이스에 문제가 발생할 수도 있다.[4]

하중 증가

확장성 테스트를 만들 때 점진적으로 스케일업하는 것이 중요한 이유다.이러한 단계는 소형, 중형, 고부하로 나눌 수 있다.[5]

우리는 각 단계가 다른 측면을 테스트할 때 점진적으로 확장해야 한다.작은 하중은 시스템이 기본 레벨에서 작동하도록 보장한다.중간 하중 시험 시스템이 예상 수준에서 기능할 수 있다.높은 부하 테스트는 시스템이 높은 부하에 대처할 수 있다.[6]

테스트 환경

정확하고 신뢰할 수 있는 결과를 제공하기 위해 테스트 내내 환경이 일정해야 한다.시험이 성공적이라면 실적에 비례하는 변화를 봐야 한다.예를 들어 시스템의 사용자를 두 배로 늘리면 50%의 성능 저하가 나타나야 한다.[7]

또는 시간이 지남에 따라 메모리나 CPU 사용량과 같은 측정 시스템 통계에 대해 사용자가 어느 축에도 플로팅되지 않기 때문에 비례하지 않는 다른 그래프를 가질 수 있다.

확장성 테스트 결과

그림 1.그래프에 시간 경과에 따른 리소스 사용량(메모리)이 표시됨

일단 우리의 다양한 단계에서 데이터를 수집하고 나면, 우리는 결과를 보여주기 위해 다양한 그래프에 결과를 표시하기 시작할 수 있다.그러나 그래프는 플롯되는 내용에 따라 달라질 수 있다.

비비례적 결과

그림 1에서는 시간 경과에 따른 리소스 사용량(이 경우 메모리)을 보여주는 그래프를 볼 수 있다.그래프는 비례하지는 않지만, 시스템이 가동되기 시작할 때 램프업 단계가 있기 때문에 여전히 통과된 테스트로 간주할 수 있지만, 사용자가 추가될수록 메모리 사용량에는 거의 변화가 없다.[8]이는 현재의 메모리 용량이 시험의 3단계 모두에 대처할 수 있다는 것을 의미한다.

비례결과

그림 2.이 그래프는 사용자 수에 대해 표시된 보고서를 실행하는 데 걸린 평균 시간을 보여준다.

그림 2에서는 사용자 수와 보고서를 실행하는 데 걸리는 시간을 비교하여 더 비례적인 증가를 볼 수 있다.20명의 낮은 부하로 평균 5.5초, 중간(40명), 높은 부하(60명)로 부하를 늘리면 평균 시간은 각각 9.5초, 18초로 늘어난다.[7]

서버 소프트웨어나 하드웨어를 변경해야 하는 경우도 있다.필요한 업그레이드가 완료되면 이전에 제기된 문제를 해결하는 데 업그레이드가 효과적이었는지 확인하기 위해 테스트를 다시 실행해야 한다.[9]

우리가 비례적인 결과를 얻었을 때, 시스템이 놓여 있는 부하를 증가시키고 확장하면서 병목현상은 일어나지 않는다.[10]

수직 및 수평 스케일링

확장성 테스트 결과 소프트웨어 및 하드웨어에 대한 업그레이드가 필요할 수 있다.이러한 업그레이드는 수직 또는 수평 확장 방식으로 분할할 수 있다.

수직 스케일업은 스케일업이라고도 하며 일반적으로 보다 강력하거나 개선된 장치로 구성품을 교체하는 과정이다.예를 들어 프로세서를 더 빠른 프로세서로 교체하는 경우.스케일아웃이라고도 하는 수평적 확장은 예를 들어 워크로드를 공유하도록 원본과 병렬로 실행되도록 다른 서버를 설정하는 것이다.[11]

장단점

두 가지 스케일링 방법 모두 장단점이 있다.확장 작업이 더 간단할 수 있지만 하드웨어 자원의 추가는 수익 감소로 이어질 수 있다.[12]이는 예를 들어 프로세서를 업그레이드할 때마다 이전 변경사항과 동일한 수준의 혜택을 항상 받는 것은 아니라는 것을 의미한다.

그러나 수평적 확장은 서버와 같은 전체 시스템의 비용뿐만 아니라, 우리는 그들의 정기적인 유지 보수 비용도 고려해야 한다.[12]

참조

  1. ^ "Planning for Load Testing". docs.oracle.com. Retrieved 2015-10-23.
  2. ^ "Scalability Testing". Performance Blog. Retrieved 2015-10-25.
  3. ^ Joshi, Prateek. "Why Do We Need Performance Testing?". Perpetual Enigma. Retrieved 2015-10-25.
  4. ^ "Discovering the right metrics for scalability testing". www.theserverside.com. Retrieved 2015-10-25.
  5. ^ "SCALING UP VS. SCALING OUT IN A QLIKVIEW ENVIRONMENT". 2012.
  6. ^ 'Cytowski' 'Bernardini', 'Maciej' 'Matteo' (2013). "Prac Scalability Analysis" (PDF). Partnership for Advanced Computing in Europe.
  7. ^ a b "IBM Cognos Proven Practices: Designing a Successful Performance and Scalability Test for IBM Cognos BI". www.ibm.com. 2011-11-17. Retrieved 2015-10-25.
  8. ^ "Enterprise performance and test results" (PDF). Serena. 2011.
  9. ^ "Scalability Testing: Checking Whether a Site Performance Can Scale Up". support.smartbear.com. Retrieved 2015-10-28.
  10. ^ "The Netflix Tech Blog: Benchmarking Cassandra Scalability on AWS - Over a million writes per second". techblog.netflix.com. Retrieved 2015-11-04.
  11. ^ Bondi, André (2014). Foundations of Software and System Performance Engineering: Process, Performance Modeling, Requirements, Testing, Scalability, and Practice. Section 11.2. ISBN 0321833821.
  12. ^ a b "Scalability Testing" (PDF). Comp Nus Education.

외부 링크