Yg-Hong commented 12 months ago

👍 문제

~웹툰" 멸망 이후의 세계"를 아는가?~ 서비스 개발을 모두 마치고 나면 무슨 작업을 거치게 될까? 우리는 이번주 GC, GC튜닝, 모니터링에 대해 학습했다. 서비스 개발이 마무리 될 때 고민하는 위 문제들은 이상적으로 동작하는 어플리케이션을 지향하며 개발을 더 나은 방향으로 이끌 것이다. 그럼, 책에서 벗어나 실제 현업에서 테스트를 어떤 방식으로 진행하는지 알아보자. 우아한 기술블로그, 결제 시스템 성능, 부하, 스트레스 테스트

위 포스팅을 한번 정리해보자. 추가적인 자료는 찾지 말고 진짜 위 포스팅에 나온 내용만 가져오자.

✈️ 선정 배경

음...책에 있는 내용을 현 시점에도 유용하게 적용할 수 있을까 의문이 들어 모니터링 최신 기술을 공부하자는 의도로 가져오게 되었다.

📺 관련 챕터 및 레퍼런스

Story 20. 모니터링 API인 JMX

🐳 비고

많.이. 가.져.오.지.마.

daminzzi commented 11 months ago

Java_04.성능,부하,스트레스 테스트

성능, 부하, 스트레스 테스트

성능 테스트

성능 테스트는 시스템 구성 요소가 특정 상황에서 어떤 성능을 보이는지 확인하기 위해 수행되는 테스트이다. 제품의 리소스 사용, 확장성 및 안정성도 이 테스트를 통해 검증할 수 있다.

성능 테스트는 기본적으로 매우 광범위하다. 다음 그림은 성능 테스트가 부하 및 스트레스 테스트 모두에 대한 상위 집합임을 보여준다. 그 외에도 스파이크 테스트, 볼륨 테스트, 내구성 테스트 및 확장성 테스트가 하위 집합으로 존재한다.

성능 테스트 중에 충족되어야하는 벤치 마크가 업계별로 많이 존재하는 데 해당 시스템의 벤치 마크 수준으로 시스템을 동작시키는 것이 성능 테스트의 주요 목표이다.

Untitled

부하 테스트

부하 테스트는 성능 테스트의 하위 집합으로, 임계치 한계에 도달 할 때까지 시스템의 부하를 지속적으로 지속적으로 증가시켜 시스템을 테스트하는 것을 의미한다. 부하 테스트의 유일한 목적은 시스템의 내구성을 테스트하고 결과를 모니터링하기 위해 처리 할 수 있는 가장 큰 작업을 시스템에 할당하는 것이다. 여기서 흥미로운 사실은 때때로 무부하 상황에서 시스템의 동작을 결정하기 위해 시스템에 빈 작업이 공급된다는 것이다.

부하 테스트에서 모니터링되는 속성에는 최대 성능, 서버 처리량, 다양한 부하 수준 (중단 임계 값 미만)에서의 응답 시간, H / W 환경의 적절성, 성능에 영향을주지 않고 처리 할 수있는 사용자 애플리케이션 수 등이 있다.

스트레스 테스트

스트레스 테스트를 통해 기존 자원에 과잉 작업을 과부하시키는 다양한 활동을 수행하여 시스템을 무너뜨리는 시도를 한다.

네거티브 테스트: 시스템에서 구성 요소를 제거하는 작업도 스트레스 테스트의 일부로 수행된다.
피로 테스트: 이 테스트는 대역폭 용량을 넘을 정도로 테스트하여 애플리케이션의 안정성을 포착해야 한다.
따라서 기본적으로 스트레스 테스트는 최대 부하 및 정상 조건을 넘어서는 애플리케이션의 동작을 평가한다.

스트레스 테스트의 목적은 시스템의 오류를 확인하고 시스템이 어떻게 정상적으로 복구되는지 모니터링하는 것이다. 여기서 문제는 테스트를 시작하기 전에 제어 된 환경을 설정하여 가장 예측할 수없는 시나리오에서 반복적으로 시스템의 동작을 정확하게 캡처 할 수 있도록 하는 것이다.

스트레스 테스트의 결과로 결국 나올 문제에는 동기화 문제, 메모리 누수, 경쟁 조건 등이 포함될 수 있다.

스트레스 테스트가 사용자 수가 갑자기 증가하는 상황에서 시스템이 어떻게 작동하는지 확인하는 경우를 스파이크 테스트라고 한다.
스트레스 테스트가 사용자 수의 느린 증가를 통해 일정 기간 동안 시스템의 지속 가능성을 확인하는 것이라면 흡수 테스트라고 한다.

	성능 테스트	부하 테스트	스트레스 테스트
도메인	부하 및 스트레스 테스트의 상위 집합	성능 테스트의 하위 집합	성능 테스트의 하위 집합
범위	매우 넓은 범위하위 집합 - {부하 테스트, 스트레스 테스트, 용량 테스트, 볼륨 테스트, 내구성 테스트, 스파이크 테스트, 확장 성 테스트 및 안정성 테스트 등}	성능 테스트에 비해 범위가 좁다.볼륨 테스트 및 내구성 테스트를 포함한다.	성능 테스트에 비해 범위가 좁다.soak 테스트 및 스파이크 테스트를 포함한다.
주요 목표	애플리케이션 성능을 벤치 마크 및 표준에 맞춘다.	시스템의 상한선을 식별하려면 앱의 SLA를 설정하고 시스템이 과부하 볼륨을 처리하는 방법을 확인한다.	과부하에서 시스템이 작동하는 방식과 장애로부터 복구하는 방식을 테스트하면서 알아낸다.앱이 기본적으로 예기치 않은 트래픽 급증에 다운되지 않도록 대비한다.
부하 제한	임계치 이전과 초과된 경우 모두 검사	임계치 이전까지 검사	임계치를 초과한 경우 검사
학습된 속성	리소스 사용량, 안정성, 확장성, 리소스 사용량, 응답 시간, 처리량, 속도 등	과부하 수준에서 최대 성능, 서버 처리량, 응답 시간 (임계치 값 미만), H/W 환경의 적절성, 처리 할 수 있는 사용자 앱 수, 부하 분산 요구 사항 등	대역폭 용량, 응답 시간 이상의 안정성 (임계치 값 초과)
얻은 결과	런타임 팽창, 최적화 범위, 속도, 지연 시간, 처리량 등과 관련된 문제를 포함한 모든 성능 버그. 기본적으로 – 성능과 관련된 모든 것!	부하 분산 문제, 대역폭 문제, 시스템 용량 문제, 응답 시간 부족, 처리량 문제 등	과부하, 과부하 상황에서의 데이터 손상 문제, 속도 저하, 메모리 누수 등의 보안 허점

테스트의 목표

내가 만든 이 시스템은 실제 장비에서

어느 정도의 부하 를 견딜 수 있는가?
시스템(데이터베이스, 서버), 자원(cpu, disk, memory 등)에서 병목 이 생기진 않는가?
자원을 효율적 으로 사용하는가?
메모리 누수, 오류, 오버플로우 는 발생하지 않는가?
최악의 상황 에선 어떤 동작을 하는가? (예측하고 대비하기 위하여)
장애 조치와 복구 가 잘 동작을 하는가?

테스트 후 내가 만든 이 시스템은 실제 장비에서

어느 정도의 부하 를 견딜 수 있는지 알고 있다.
한계치에서 병목 이 생기는 지점을 알고 있다.
자원을 효율적 으로 사용한다.
메모리 누수, 오류, 오버플로우 는 발생하지 않는다.
최악의 상황 에서 어떤 동작을 하는지 직접 확인하였다.
장애 조치와 복구 의 동작을 직접 확인하였다.

즉, 벤치마크(성능을 시험하여 수치화하는 것)와 표준을 속도, 응답시간, 처리량, 리소스 사용량 및 안정성 등을 고려하여 설정하는 것을 목표로 테스트를 진행한다.

테스트 진행 과정

예시는 참고자료를 참고해서 작성함

외부 인터페이스 Mock 처리

온전히 테스트 대상 시스템의 성능을 측정하기 위해서 외부 시스템의 영향을 최소화 해야 한다. 따라서 항상 기대한 결과만을 반환하는 Mock 환경이 필요하다.

예를 들어 결제 시스템은 사용자의 주문 비용을 결제 수단(PG사(Payment Gateway), 포인트, 쿠폰) 등의 시스템과 통신하여 지불 처리하는 시스템이다. 즉, 하나의 결제는 결제수단이라는 외부 인터페이스를 거치게 된다.

성능 테스트 시 하지 말아야 할 Mocking 방식

객체 Mocking
같은 어플리케이션에 Dummy Controller 생성

Mock Server 만들고 띄우기

Mock Server는

모든 요청에 기대한 결과만을 반환한다.
모든 요청에 기대한 퍼포먼스만 낸다.
병목이 되지 않아야 한다.

→ 위의 조건을 만족하는 Mock Server는 간단히 Spring Boot 등을 이용해 개발할 수도 있다. 요청에 대해서 기대한 결과, 퍼포먼스로 응답을 하는 값을 반환할 수 있도록 구성한다. 앞에서 이야기한 결제 시스템의 경우 결제 방식이나 결제 성공여부와 같은 내용이 포함될 수 있다.

Mock Application의 배포

AWS Elastic Beanstalk 등을 이용해서 작성된 Mock Server를 띄울 수 있고, 간단한 API의 경우 Postman , MSW 와 같은 Mock API Server를 이용할 수도 있다.

여담이지만 이러한 Mocking의 경우 프론트엔드 개발 업무의 효율성을 높이기 위해서도 사용된다. API 스펙이 제공된다면 백엔드 개발과 병행해서 프론트엔드 개발을 진행하기 위해서 Mocking을 이용할 수 있다.

Untitled 1

여러 도구를 이용한 테스트 진행

1. nGrinder

nGrinder는 네이버에서 제공하는 서버 부하 테스트 오픈 소스 프로젝트이다.

애플리케이션을 개발하고 nGrinder에서 여러가지 가상 시나리오를 만들어 트래픽에 몰렸을 때 성능을 측정할 수 있도록 도와준다.

구조

Controller : 사용자가 테스트 수행을 위한 스크립트를 생성하여 성능 측정을 위한 웹 인터페이스를 제공하며 테스트 결과를 수집해 통계를 보여준다.
Agent : Controller의 명령을 받아 작업을 수행하며 프로세스 및 스레드를 실행시켜 타겟이 되는 애플리케이션에 부하를 발생시킨다.

설치 방법 및 시뮬레이션 방법은 링크를 참조

테스트 스크립트로는 Groovy, Jython 등을 이용할 수 있다.

Groovy는 자바에 파이썬, 루비, 스몰토크 등의 특징을 더한 동적 객체 지향 프로그래밍 언어로 자바 소스는 컴파일해야만 사용할 수 있지만, 그루비 소스는 스크립트 파일 그대로 실행시킬 수도 있고, 자바처럼 컴파일하여 쓸 수도 있다. 거의 대부분의 자바 소스는 파일 확장자만 바꾸면 수정 없이 그루비에서도 쓸 수 있다.

2. pinpoint

pinpoint 는 Java로 작성된 대규모 분산 시스템용 APM 도구이다.

사내에서 사용하고 있는 모니터링툴이기도 하며, Transaction 의 추적을 제공하는 APM 중 하나이다.

단일 Transaction의 Stack Trace 를 기록하여 직접적인 병목이나 문제를 빠르게 추적할 수 있고, Transaction 이 DOT 로 그려지는 응답시간/요청시간 그래프 Transaction View 는 테스트의 상태를 실시간으로 확인하여, 가장 빠르게 이상을 감지하도록 도와준다.

Transaction View 는 패턴에 따른 어플리케이션 상태 예측에도 도움을 준다. A 구간의 병목을 보였을 때 보이는 패턴, 외부 인터페이스가 병목을 보였을 때 등등 예상 패턴을 통해 더 빠른 조치가 가능하게 만들어 준다.