작성자: 정지성, 진유록
nGrinder Controller/Agnet 실행 환경
•
로컬 환경에 설치해서 EC2 서버에 요청을 보내는 방식으로 테스트
•
nGrinder Controller/Agent를 실행하는 비용도 존재하기 때문에 서버와 동일한 환경에 설치해서 진행하는것은 바람직하지 않고, 서버 환경에 대한 스펙은 명시하되 Controller/Agent가 실행되는 환경의 스펙은 명시하지 않아도 무관하다.
서버 스펙에 대한 참고사항
•
t2.micro: amazon linux 2023 ami / 1 vCPU / 1 GiB memory
•
위 서버 스펙은 aws freetier 스펙인데 실무에서는 4vCPU, 16GiB 환경을 주로 쓴다고 한다. 본 프로젝트는 학습의 목적이 크기 때문에 낮은 스펙으로 시작해 스펙을 올려가면서 테스트를 진행하고자함
•
고민해본 결과 spring application은 실행 시키기만 해도 메모리를 800mb나 잡아먹기 때문에 위 스펙으로 테스트를 진행했을시에 기대하는 테스트를 진행할 수 없을 것으로 판단. 테스트 머신의 최초 스펙은 아래와 같이 설정하고 시작하는 것으로 결정.
•
t3.medium: amazon linux 2023 ami / 2 vCPU / 4 GiB memory
1. HotDeal 동시성 테스트
•
테스트 개요
◦
재고가 100개인 핫딜 상품에 대해 3000명의 사용자가 거의 동시에 (약 7.5초)구매 요청을 하는 시나리오. 동시성 처리 및 데이터베이스 무결성확인을 중점으로함
•
테스트 환경
◦
서버 환경: AWS EC2 > DockerImage로 구동되는 Spring서버
▪
t2.medium: amazon linux 2023 ami / 2 vCPU / 4 GiB memory
▪
Docker 24.0.7, Spring Boot 3.2.1
•
테스트 시나리오 설계
◦
3000명의 사용자가 약 7.5초 이내로 3개씩 핫딜 상품구매 요청을 보내는 테스트 진행
◦
◦
각 요청은 사용자, 상품 정보를 포함한 Groovy 스크립트를 작성해서 서버에 전송
•
기대하는 테스트 결과
◦
재고 관리 정확성: 모든 구매 요청이 처리된 후, 핫딜 상품의 재고 수량이 정확하게 1이 되어야 합니다.
◦
동시성 처리 능력: 시스템은 동시에 들어오는 대량의 요청을 효율적으로 처리할 수 있어야 합니다.
◦
데이터 무결성: 데이터베이스의 무결성이 유지되며, 어떠한 경우에도 재고가 음수가 되지 않아야 합니다.
2. 상품 검색 기능 부하테스트 시나리오
•
테스트 개요
◦
상품 검색 기능의 성능 최적화 전/후 서버에 부하를 발생시켜 상품 검색 서비스의 성능이 어느정도 개선되었는지 측정하고 최적화 후 서비스에서 어느정도의 트래픽을 견딜 수 있는지 안정성을 측정하기 위함
•
테스트 환경
◦
서버 환경: AWS EC2 > DockerImage로 구동되는 Spring서버
▪
t2.medium: amazon linux 2023 ami / 2 vCPU / 4 GiB memory
▪
Docker 24.0.7, Spring Boot 3.2.1
•
테스트 시나리오 설계
◦
성능 최적화 전/후의 상품 검색 코드를 서버에 올린 후 10명의 agent로 시작해 100, 1000명 단위로 늘려서 테스트를 진행한다. 요청 Duration은 30분으로 설정한다. 성능 최적화 전/후 상황에서 서버가 감당 가능한 agent의 수를 찾는다.
◦
Optional: 위 테스트 시나리오와 별도로 테스트 진행시 SQL이 예상한대로 날아가고 있는지(2번의 쿼리가 나가도록 개발했는데 3개가 나간다는 등) 테스트를 진행
◦
◦
각 요청은 nGrinder Groovy 스크립트를 이용해 페이지 정보(offset, size)와 검색 키워드를 파라미터로 함께 전달
◦
성능 최적화 전/후의 TPS, MTT(nGrinder에서 확인 가능)와 서버의 CPU, MEM 사용률을 측정 비교한다.
▪
CPU, MEM 사용률을 편하게, 그래프화해서 보고싶다면 AWS에서 제공하는 모니터링 기능을 사용해도 괜찮다.
▪
하지만, 본 프로젝트를 학습의 목적으로 진행하는 것이기 때문에 EC2 상에서 직접 shell script를 작성해 5초에 한번씩 CPU, MEM 사용률을 기록한다. (간단하게 하려면 도커로 오픈소스를 불러와 사용)
•
기대하는 테스트 결과
◦
Postman을 이용해 간단한 테스트를 해봤을때, 최적화 이전에는 평균 1500ms의 응답시간을 보여주고 있고 최적화 이후에는 평균 50ms의 응답시간을 보여주었음. 따라서, 성능 최적화 이후의 테스트에서 TPS, MTT 지표가 더 좋게 나올것으로 예상함
◦
CPU, MEM 사용률의 경우에는 측정 후 분석을 해봐야할 것 같음
3. WebSocket Connection 부하 테스트
위 자료들을 읽고난후… nGrinder로 WebSocket Connection/부하 테스트를 진행하기에는 관련 자료가 적을 뿐더러 최적화가 되어있지 않아 WebSocket 연결을 수행하는 별도의 스크립트 작성에 시간이 많이 들 것이라고 판단했습니다. 프로젝트 마감 기한이 얼마 남지 않아 WebSocket에 대한 테스트는 테스트 환경이 잘 구축되어 있는 Jmeter로 진행하고자 합니다.
!!!!!Jmeter를 이용한 WebSocket 테스트는 Jmeter에 대해 좀 알아봐야해서 아직 작성하지 못했습니다ㅜㅜ 서둘러 정리해서 시나리오 짜보겠습니다!
•
테스트 개요
◦
작은 단위에서 시작해 시작해 connection, send 메세지 단위를 점차 늘려가는 방식으로 WebSocket의 테스트를 진행(ex: 초기 사용자 10명, send 메세지 10개)
•
테스트 환경
◦
서버 환경: AWS EC2 > DockerImage로 구동되는 Spring서버
▪
t2.micro: amazon linux 2023 ami / 1 vCPU / 1 GiB memory
▪
Docker 24.0.7, Spring Boot 3.2.1
•
테스트 시나리오 설계
◦
•
기대하는 테스트 결과
◦
추후 시간나면 해볼 테스트 (추상적)
