AWS Distributed Load Testing
AWS Solutions Library에서 Distributed Load Testing 솔루션을 사용하여 부하테스트를 진행한다.
이 AWS 솔루션을 배포하면 서버를 프로비저닝하지 않고도 일관된 속도로 트랜잭션 레코드를 생성하여 수천 명의 연결된 사용자를 구축하고 시뮬레이션할 수 있다.
위 링크에서 AWS 콘솔에서 시작을 누르면 배포를 시작한다.
CloudFormation 스택 생성
- AWS에서 제공하는 기존 템플릿을 사용할 것이기 때문에 기존 템플릿 선택을 선택한다.
- 템플릿 소스
- Amazon S3 URL을 선택하고 기본으로 설정되어 있는 URL은 AWS에서 공식 제공하는 Distributed Load Testing 솔루션 템플릿이다.
- 스택 이름
- CloudFormation 스택 이름
- Console Access
- Console Administrator Name: Distributed Load Testing 대시보드에 접근할 관리자 이름을 입력한다.
- ex) admin
- Console Administrator Email: 관리자의 이메일 주소를 입력한다. Load Testing 솔루션에 접근하는 사용자 계정을 설정하는 데 필요하다.
- VPC ID
- 테스트할 운영환경의 VPC ID를 입력한다.
- 서브넷 ID
- 운영환경 VPC 내에 위치한 서브넷 ID를 입력한다.
아래는 새 VPC를 생성하는 옵션들이다. 새 VPC를 설정하면 운영 환경과 분리된 환경에서 부하 테스트를 수행할 수 있다.
이후 다음을 누르면 나오는 옵션 구성 페이지에서는 기본값들을 유지하고 생성한다.
Distributed Load Testing 대시보드
생성하고 나면 생성 시 Console Access 부분에 적었던 email을 통해 Distributed Load Testing 솔루션의 웹 대시보드에 로그인을 할 수 있는 password를 보내준다.
해당 콘솔은 CloudFormation 콘솔에서 생성한 스택의 출력란을 보면 접근할 수 있는 URL을 확인할 수 있다.
해당 URL에서 주어진 값으로 로그인을 하면 비밀번호를 변경 후 콘솔에 접근할 수 있다.
상단의 CREATE TEST를 누르면 테스트 시나리오를 작성할 수 있다.
테스트 시나리오 작성
나는 쿠폰 발급 대기열 서버의 최대 SSE 연결 수를 테스트를 진행하기 위한 시나리오를 작성했다.
우선 CREATE TEST의 각 값들에 대해 알아보자.
- General Settings
- Name: 테스트 이름
- Description: 테스트 간단한 설명
- Task Count: 동시 실행할 Fargate 컨테이너 수
- 부하를 늘리며 성능 한계를 확인해야 하기 때문에 점진적으로 증가시키며 테스트 한다.
- Concurrency: 각 Task가 처리할 동시 사용자 수
- 개별 컨테이너의 동시 사용자 수이다.
- Region: 테스트 대상 서버가 위치한 AWS 리전
- Ramp Up: 부하를 증가시키는 시간
- 부하를 서서히 증가시켜 단시간에 많은 요청이 몰리는 것을 방지한다.
- Hold For: 최대 동시 연결 수를 달성한 상태로 Hold For 시간만큼 지속해 시스템의 한계를 확인한다.
- Run Now: 즉시 실행한다.
- Senario
- Test Type
- Single HTTP Endpoint
- Jmeter: Jmeter의 jmx 파일을 사용해 테스트할 수도 있다.
- Test Type
나는 여기서 기존에 로컬에서 테스트하던 jmx 파일이 있기 때문에 해당 파일을 사용하도록 했다.
Jmeter 테스트
5000개 연결했을 때
CPU 사용량은 안정적이지만 java.lang.OutOfMemoryError: Java heap space 에러 발생으로 정상적인 처리 안됨.
JVM 옵션 설정
1
JAVA_OPTS="-Xms2g -Xmx2g"
- Xms2g: 초기 Heap 메모리 2G
- Xmx2g: 최대 Heap 메모리 2G
옵션 설정으로 OutOfMemory 발생을 방지한다.
설정 후 1000개 연결 요청을 보냈을 때 OutOfMemoryError는 나지 않았다.
CPU 사용량도 안정적임을 확인할 수 있었다.
같은 조건으로 1500으로 연결 수를 늘렸을 때 메모리 초과나 응답 실패같은 경우는 없었지만 중간중간 응답이 매우 긴 경우가 있었다.
OutofMemory 에러가 나진 않지만 메모리 사용 초과로 인해 지연된 것이라고 추측된다.
따라서 1500개의 연결 테스트는 실패라고 간주하고, 최대 대기열 수 1000, 티켓 수 100으로 수정하는 것이 좋을 것 같다.
대기열 수를 늘리고 싶다면 인스턴스를 업그레이드 하거나 서버 분산을 해주면 될 것 같다.
