최종 사용자에게 소프트웨어를 출시하기 전에 애플리케이션에 버그가 없고 비즈니스 요구 사항을 충족하는지 확인하기 위해 다양한 테스트를 수행합니다. 우리는 많은 테스트를 하지만 사용자가 실제로 사용하지 않고는 소프트웨어가 안정적인지 확신할 수 없습니다. 최종 사용자가 애플리케이션을 사용하기 시작한 후 다음과 같은 이유로 애플리케이션이 예상대로 작동하지 않을 수 있습니다.
- 사용자 행동은 예측할 수 없습니다.
- 사용자는 여러 위치에 분산되어 있습니다.
- 많은 사용자가 동시에 애플리케이션을 사용할 수 있습니다.
대규모 응용 프로그램의 경우 본격적인 릴리스 전에 이러한 사항을 아는 것이 매우 중요합니다. 애플리케이션이 예상대로 작동하도록 하려면 기능을 출시하는 동안 몇 가지 사항을 고려해야 합니다.
- 단계적 출시 -단계적 출시 동안 모든 사용자가 기능에 액세스하기 전에 일부 사용자가 애플리케이션을 테스트할 수 있습니다. 이는 사용자 행동을 파악하는 데 도움이 됩니다.
- 부하 테스트 -단계적 출시 동안 사용자 행동을 결정할 수 있지만 많은 사용자가 다른 위치에서 동시에 애플리케이션을 사용하는 경우 플랫폼이 어떻게 작동하는지 알 수 없습니다.
부하 테스트란 무엇이며 성능 테스트와 어떻게 다른가요?
다음 세 가지 용어는 비슷하게 들릴 수 있지만 다릅니다.
- 성능 테스트,
- 부하 테스트 및
- 스트레스 테스트.
성능 테스트 응용 프로그램이 주어진 입력으로 수행되는 방식을 평가하는 데 사용되는 일반적인 테스트 메커니즘입니다. 이것은 응용 프로그램을 사용하는 단일 사용자 또는 여러 사용자와 함께 수행할 수 있습니다. 응답 시간 및 CPU/메모리 사용량과 같은 특정 메트릭을 평가하기 위해 수행됩니다. 부하/스트레스 테스트는 성능 테스트의 하위 집합입니다.
부하 테스트 지정된 시간 동안 동시에 응용 프로그램을 사용하는 지정된 수의 사용자와 함께 응용 프로그램이 예상대로 작동하는지 확인하기 위해 수행됩니다. 시스템에서 처리할 수 있는 사용자 수를 결정하는 데 도움이 됩니다.
스트레스 테스트 로드 테스트는 서로 밀접하게 관련되어 있습니다. 스트레스 테스트는 부하 테스트와 유사한 메커니즘으로 수행할 수 있지만 테스트의 목표는 다릅니다. 부하 테스트의 목표는 애플리케이션이 지정된 수의 사용자와 작동하는지 여부를 확인하는 것인 반면 스트레스 테스트는 부하 제한에 도달한 후 애플리케이션이 작동하고 오류를 처리하는 방법을 확인하기 위해 수행됩니다.
램프업 기간에 따라 성능 테스트는 급상승 테스트로 분류될 수 있습니다. 또는 담그기 테스트 . 짧은 시간 동안 사용자가 갑자기 급증하면 스파이크 테스트이고 장기간에 걸쳐 사용자가 느리게 증가하는 것은 소크 테스트입니다.
성능 테스트가 중요한 이유는 무엇입니까?
Rails 프로젝트 중 하나에서 우리는 가까운 장래에 사용자가 많이 증가할 것으로 예상했습니다. 우리는 응용 프로그램이 예상대로 작동하고 사용자 수가 증가함에 따라 중요한 기능이 손실되지 않도록 하고 싶었습니다. 그렇다면 이를 어떻게 보장할 수 있을까요? 부하 테스트를 수행하고 애플리케이션이 주어진 사용자 증가를 처리할 수 있는지 확인했습니다. 성능 테스트는 다른 많은 경우에 중요할 수 있습니다.
- 검은 금요일과 같이 특정 날짜에 애플리케이션의 사용자 수가 급증할 것으로 예상되는 경우 짧은 램프업 기간으로 애플리케이션을 스파이크 테스트하면 시스템에서 잠재적인 문제를 찾는 데 도움이 될 수 있습니다.
- 부하 테스트는 시스템의 버그를 식별하는 데 도움이 됩니다. 이 버그는 눈에 보이지 않거나 소수의 사용자만 사용하는 경우에는 매우 미미합니다.
- 그것을 통해 플랫폼의 속도가 증가된 부하에 의해 어떻게 영향을 받는지 평가할 수 있습니다. 응용 프로그램이 느리면 고객을 잃을 수 있습니다.
- 사용자가 10,000명일 때 부하가 증가할 때 시스템이 작동하는 방식과 CPU 또는 메모리 사용량이 많아 시스템이 충돌하는지 평가하는 데 도움이 됩니다.
- 특정 사용자 수에 대해 애플리케이션을 실행하는 비용은 부하 테스트를 통해 결정할 수 있습니다.
로드 테스트를 수행하는 동안 Rails 앱에서 버그를 찾을 수 있었습니다. 문제를 식별한 유사한 시나리오를 설명하겠습니다. 호텔 예약 앱은 예약 프로세스가 공개되어 있었고 소수의 사용자만 방을 예약하려고 했을 때 모든 것이 괜찮았습니다. 그러나 여러 사용자가 같은 방을 예약하려고 할 때 두 명의 다른 사용자가 성공적으로 예약할 수 있었습니다. 앱의 부하 테스트를 통해 기능을 출시하기 전에 문제를 식별하고 초기 단계에서 수정할 수 있었습니다.
Apache JMeter를 사용하여 Rails 앱 로드 테스트
JMeter는 Apache 2.0 라이선스 오픈 소스 부하 테스트 도구입니다. 스레드 기반 부하 테스트를 제공합니다. 스레드 기반 테스트를 통해 많은 사용자가 동시에 애플리케이션을 사용할 때 시스템이 받는 스트레스를 쉽게 시뮬레이션할 수 있습니다. JMeter는 또한 테스트 결과에 대한 우수한 보고 기능을 제공합니다.
우리는 Apache JMeter를 사용하여 시스템을 사용하는 많은 사용자를 시뮬레이션함으로써 시스템과 애플리케이션의 응답 시간에 잠재적인 문제를 식별하기 위해 부하 테스트를 수행하는 방법을 살펴볼 것입니다.
JMeter는 다음 링크에서 다운로드할 수 있습니다. https://jmeter.apache.org/download_jmeter.cgi#binaries
익숙할 JMeter 용어
- 테스트 계획 테스트 계획은 우리가 부하 테스트 구성 요소로 정의하는 내부의 최상위 수준입니다. 전역 구성 및 변수는 여기에서 정의됩니다.
- 스레드 그룹 스레드 수, 램프업 기간, 스레드 간 지연 및 루프와 같은 스레드 및 구성을 정의하는 데 사용됩니다. 부하 테스트를 실행할 병렬 사용자 수로 처리할 수 있습니다.
- 샘플러 단일 스레드가 실행하는 것입니다. HTTP 요청, SMTP 요청 또는 TCP 요청과 같은 다양한 유형의 샘플러가 있습니다.
- 사전/사후 프로세서 샘플러가 실행되기 전이나 후에 무언가를 실행하는 데 사용됩니다. 후처리기는 하나의 API 호출에서 응답 데이터를 가져와 다음 호출에 사용할 수 있도록 전달할 수 있습니다.
- 청취자 샘플러의 응답을 수신하고 각 스레드의 응답 시간 또는 응답에 대한 집계 보고서를 제공합니다.
- 주장 응답 데이터가 샘플러에서 예상한 것과 같은지 확인하는 데 유용할 수 있습니다.
- 구성 요소 HTTP 헤더, HTTP 쿠키 또는 CSV 데이터 세트 구성과 같은 구성을 정의합니다.
부하 테스트를 실행하려면 먼저 위에서 설명한 JMeter 용어를 정의하는 JMX 파일을 만들어야 합니다.
부하 테스트를 위한 JMX 파일 준비
JMX는 XML 형식으로 작성된 JMeter 프로젝트 파일입니다. JMX 파일을 수동으로 작성하는 것은 어려울 수 있으므로 JMeter 인터페이스를 사용하여 파일을 생성하겠습니다.
JMeter 인터페이스를 열고 테스트 계획을 찾습니다. 테스트 계획 내에서 스레드와 부하 테스트 구성을 추가합니다.
테스트 계획 작성을 위한 JMeter 인터페이스
테스트 계획은 부하 테스트 대상에 따라 이름을 바꿀 수 있습니다. 스레드 그룹(사용자)을 구성할 수 있습니다. 여기에서 기본 설정을 유지하고 계속해서 스레드 그룹을 만들 수 있습니다.
Add -> Threads(Users) -> Thread Group
스레드 그룹에는 기본적으로 단일 스레드가 지정됩니다. 앱에 액세스하는 사용자 수를 시뮬레이션하려면 필요에 따라 숫자를 변경하세요.
웹 기반 Rails 앱을 로드 테스트하므로 HTTP 샘플러를 추가합니다. ThreadGroup 안에 있는 샘플러를 추가할 수 있습니다. . HTTP Sampler 추가 다음을 탐색하여:
Add -> Sampler -> HTTP Request
여기에서 로드 테스트할 IP 또는 도메인과 HTTP 엔드포인트에 필요한 HTTP 메서드 및 요청 본문을 구성합니다.
마지막으로 부하 테스트 보고서를 보기 위해 스레드 그룹에 리스너를 추가할 수 있습니다.
Add -> Listener -> View Result Tree
보기 결과 트리는 각 스레드의 응답 시간을 표시합니다. 여기에 다른 종류의 보고서도 추가할 수 있습니다. '결과 트리 보기'는 실제 테스트가 아니라 디버깅 제안에만 사용해야 합니다.
이런 식으로 간단한 테스트 계획을 만들고 실행할 수 있습니다. 테스트를 실행하려면 JMeter의 상단 표시줄에 있는 재생 아이콘을 누르기만 하면 됩니다.
Rails 앱을 로드 테스트하기 전에 고려해야 할 사항
위의 예는 매우 간단한 단일 엔드포인트 HTTP 요청입니다. Rails 앱의 경우 테스트하려는 엔드포인트가 인증으로 잠겨 있습니다. 따라서 다음 사항이 준비되어 있는지 확인해야 합니다.
- 웹 쿠키 - HTTP 엔드포인트에 대한 부하 테스트를 수행하려면 먼저 쿠키 헤더가 있어야 합니다. JMeter는 사용자가 로그인하면 쿠키를 추가하는 기능을 제공합니다. 다음 섹션에서는 브라우저 요청을 기록하고 부하 테스트를 위해 이를 JMX 파일로 변환하는 방법을 살펴보겠습니다. 쿠키 기록도 다룰 것입니다.
- Rails CSRF 토큰 - Rails는 CSRF 토큰을 제공하여 보안 취약성으로부터 앱을 보호하므로 부하 테스트를 수행하기 전에 요청에 헤더에 CSRF 인증이 있는지 확인해야 합니다. 이 CSRF 토큰은
header에 있습니다.meta내부 HTML의 태그입니다.
Rails CSRF 토큰 포스트 프로세서를 사용하여 JMeter에서 가져올 수 있습니다. CSRF 토큰이 포함된 웹 페이지를 로드하는 HTTP 요청을 마우스 오른쪽 버튼으로 클릭한 다음 Add -> Post Processor -> Regular Expression Extractor를 선택합니다. . 여기에서 다음 정규식 추출기 구성을 추가하여 헤더 메타 태그에서 CSRF 값을 읽을 수 있습니다.
-
참조 이름:
csrf_value -
정규식:
name="csrfToken" content="(.+?)" -
템플릿:
$1$ -
일치 번호:
1
이제 변수 csrf_value 요청하는 데 사용할 수 있습니다.
JMX 파일 생성을 위한 브라우저의 요청 기록
HTTP 엔드포인트가 적으면 JMeter 인터페이스에서 JMX 파일을 간단하게 생성할 수 있습니다. 그러나 더 큰 테스트 케이스의 경우 어려울 수 있습니다. 또한 사용자가 애플리케이션을 사용하는 동안 실제 요청을 놓칠 가능성이 있습니다. 브라우저의 실제 요청이 기록되고 JMX 파일이 자동으로 생성되기를 원합니다.
JMeter는 Rails 앱과 브라우저 사이에 프록시로 추가할 수 있습니다. 이를 통해 모든 요청은 JMeter에 의해 Rails 서버로 전달됩니다. 이를 MITM(중간자) 공격이라고도 합니다.
JMeter 녹음
JMeter에서 녹음을 만들려면 file -> templates -> recording으로 이동하세요. 그리고 만들기를 클릭합니다. 기록 중인 호스트 이름을 지정합니다. 그러면 쿠키 관리자를 포함하여 몇 가지 항목이 자동으로 생성됩니다. 쿠키 관리자는 인증에 필요한 쿠키를 저장합니다.
JMeter SSL 인증서로 HTTPS 요청 확인
브라우저에서 만든 이 요청은 JMeter로 전달되고 JMeter는 이를 웹 서비스로 전달하고 JMeter 기록에서 부하 테스트를 실행할 수 있도록 요청을 기록합니다. 애플리케이션에 SSL 연결을 위한 https 프로토콜이 필요한 경우 브라우저에 인증서를 추가해야 합니다. 인증서를 추가하려면 Firefox,를 엽니다. 또는 다른 브라우저. Firefox,에서 settings > Privacy > Manage certificate로 이동합니다. 브라우저가 JMeter에 의해 생성된 인증서를 인식할 수 있도록 JMeter 인증서를 추가합니다.
cmd + sht + g 입력 /usr/local/Cellar/jmeter/5.2/libexec/bin/jmeter 경로를 입력합니다. 인증서를 추가하려면
JMeter를 Aa 프록시로 사용하도록 Firefox 구성
다음으로 Firefox의 요청을 JMeter 기록 스크립트로 전달해야 합니다. 이것은 Firefox에서 프록시를 구성하여 수행할 수 있습니다. Firefox를 열고 Preferences -> Advanced -> Connection(settings)으로 이동합니다. . 여기에서 HTTP 프록시를 "localhost"로, 포트를 "8080"으로 설정하고 "모든 프로토콜에 이 프록시 서버 사용"을 선택합니다.
이제 JMeter 및 Script recording으로 이동할 수 있습니다. 이전에 선택한 템플릿의 섹션입니다. 시작 버튼을 누르면 JMeter가 들어오는 요청을 수락하기 시작합니다. Firefox로 이동하여 부하 테스트 중인 애플리케이션을 탐색하면 이를 기록하고 부하 테스트를 위해 실행할 수 있는 JMX 파일로 변환합니다.
JMeter를 사용한 분산 부하 테스트
테스트를 실행하는 동안 로컬 시스템 중 하나에서 테스트를 수행할 수 있습니다. 테스트 계획을 준비할 때는 이렇게 해도 되지만 실제 테스트를 실행할 때는 변경해야 합니다. 단일 시스템에서 부하 테스트를 수행하면 하드웨어 제한(예:CPU 및 메모리)과 요청 위치 제한이 있습니다. 이러한 테스트는 애플리케이션을 사용하는 실제 사용자의 트래픽을 시뮬레이션하기 위해 실행됩니다. 이를 위해 테스트를 여러 서버에 배포하고 모든 결과를 볼 수 있는 단일 장소가 있어야 합니다.
JMeter는 테스트를 오케스트레이션하기 위한 기본 노드와 테스트 실행을 위한 여러 보조 노드를 제공합니다. 이것은 응용 프로그램을 사용하여 실제 사용자를 시뮬레이션하는 데 도움이 됩니다. 실제 사용자와 가까운 다른 지역에 테스트 서버를 배포할 수 있습니다.
JMeter 분산 테스트
분산 테스트를 수행하려면 기본 서버와 보조 서버 모두에 JMeter를 설치하여 시작하십시오.
보조 서버에서 해야 할 일:
jmeter/bin으로 이동jmeter-server실행 명령. 그러면 서버가 테스트를 실행하기 시작합니다.- 테스트에 CSV 입력이 필요한 경우 이 파일을 이 서버에 추가하세요.
주 서버에서 해야 할 일:
- jmeter/bin 디렉토리로 이동하여
jmeter.properties를 엽니다. 파일. remote_hosts가 포함된 행 편집 보조 서버의 IP를 쉼표로 구분하여 추가합니다.remote_hosts=<s1_ip>,<s2_ip>.- JMeter 테스트를 실행합니다.
보조 서버는 실제 테스트 실행을 담당하고 기본 서버는 보고서를 집계합니다.
부하 테스트를 수행하려면 UI에서 테스트를 트리거하는 대신 항상 CLI 명령을 사용해야 합니다. 이렇게 하면 부하 테스트 서버에 성능 문제가 발생할 수 있습니다. JMX 파일 이름을 지정하는 JMeter 명령을 사용할 수 있습니다.
> jmeter -n -t path/to/test.jxm -r
또는
> jmeter -n -t path/to/test.jxm -R s1_ip,s2_ip,…
-r jmeter.properties에 지정된 원격 서버를 사용합니다.
-n GUI 모드 없이 실행됩니다.
-t jmx 파일 경로
Rails 서버에 Puma와 Unicorn을 사용하기로 결정한 방법
Puma와 Unicorn은 Rails를 위한 두 개의 다른 웹 서버입니다. 둘 다 장점이 있는데 어떤 것이 가장 좋은지 어떻게 결정합니까? 응용 프로그램에 따라 다릅니다. 일부 응용 프로그램은 Unicorn과 가장 잘 작동하고 일부는 Puma와 가장 잘 작동합니다. 우리는 Rails 앱 중 하나에 대해 Unicorn과 Puma 중에서 선택해야 했으며 로드 테스트에서 얻은 데이터를 기반으로 선택했습니다. 우리는 Rails 앱에서 Unicorn으로 한 번, Puma를 사용하여 다른 한 번 부하 테스트를 수행했습니다. 우리가 변경한 유일한 것은 Rails 앱의 웹 서버였습니다.
이 테스트에서 다음과 같은 결과를 얻었습니다. 
퓨마와 유니콘의 응답 시간 차이
플랫폼에 많은 수의 사용자가 있을 때 Puma가 Rails 앱에서 더 나은 성능을 발휘한다는 것을 발견했습니다. 즉, 더 적은 수의 애플리케이션 서버로 더 많은 사용자를 처리할 수 있습니다.
<블록 인용>참고:이는 사용 중인 서버 인스턴스의 유형과 앱이 수행하는 처리 비즈니스 로직의 종류에 따라 다릅니다.
Rails 앱에 스트레스를 주는 동안 발생하는 몇 가지 일반적인 오류 및 해결 방법
- 최적화되지 않은 데이터베이스 쿼리
- n+1 쿼리 문제를 제거합니다.
- 접근 패턴에 따라 색인을 추가합니다.
- 데이터베이스 앞에 Redis와 유사한 캐싱 레이어를 사용합니다.
- 느린 루비 코드 성능
- 암호화하여 코드를 최적화합니다.
- o(n^2) 복잡성을 파악하고 최적의 알고리즘을 사용합니다.
- 마이크로 서비스 아키텍처에서는 서비스 간에 많은 HTTP 호출이 있을 수 있습니다. 네트워크 호출이 느립니다.
- 마이크로서비스용 메시징 시스템을 사용하여 HTTP 호출 수를 줄입니다.
- 동시에 생성하면 동일한 레코드가 두 번 생성됩니다.
- 데이터베이스 고유 제약 조건을 추가합니다.
- FIFO 이벤트(대기열) 기반 리소스 생성을 활용합니다.
- 가능하면 Sidekiq와 같은 백그라운드 처리를 사용합니다.
- API 응답 시간에 대한 SLA를 정의하고 성능 테스트를 개발 수명 주기의 일부로 포함합니다.
부하 테스트를 수행하려면 어떤 환경을 사용해야 합니까?
프로덕션 환경에서 부하 테스트를 수행하는 것은 문제를 일으키고 프로덕션에서 가동 중지 시간까지 발생할 수 있으므로 이상적인 선택이 아닙니다. 우리는 프로덕션 환경에서 문제를 만들고 싶지 않지만 테스트 보고서가 프로덕션과 유사한 실제 데이터를 반영하는지 확인하고 싶습니다. 부하/스트레스 테스트를 위해서는 프로덕션의 복제본 환경을 만드는 것이 좋습니다. 여기에는 다음과 같은 항목이 포함됩니다.
- 애플리케이션 서버의 수.
- 복제본을 포함한 데이터베이스 서버의 하드웨어 사양.
- 테스트 데이터베이스의 프로덕션과 유사한 데이터입니다. 여기에는 프로덕션에서 발생하는 거의 동일한 데이터 볼륨이 포함되어야 합니다.
프로덕션과 같은 환경을 만드는 것은 어렵고 비용이 많이 들 수 있습니다. 따라서 부하 테스트를 기반으로 해당 구성 요소와 관련된 인프라만 프로덕션 수준으로 업그레이드할 수 있습니다. 비용이 절감됩니다. 3개월에 한 번씩 앱을 로드/스트레스 테스트하는 것이 좋습니다. 그러나 단일 사용자에 대한 성능 테스트와 응답 시간이 정의된 표준(예:200m) 미만인지 검증하는 것은 개발 주기에 추가해야 하는 것입니다.
부하 테스트 중에는 대상 서버의 CPU/메모리 사용량과 같은 데이터 포인트도 필요합니다. 메모리/CPU 사용량이 급증하면 응용 프로그램이 충돌할 수 있습니다. 하드웨어 KPI를 측정하려면 부하 테스트를 시작하기 전에 Prometheus와 같은 모니터링 도구를 추가하세요.
Apache JMeter는 부하 테스트를 위한 강력한 도구입니다. Rails 앱의 부하 테스트를 위해 Apache JMeter를 사용했지만 모든 스택에서 애플리케이션 빌드의 부하/스트레스 테스트를 수행하는 데 사용할 수 있습니다. 부하 테스트는 애플리케이션에서 데이터 기반 결정을 내리는 데 도움이 됩니다. 부하 테스트는 무섭게 들릴 수 있지만 초기에 약간의 투자를 통해 장기적으로 애플리케이션에 많은 안정성과 안정성을 추가할 수 있습니다.