- 특정 공개 투두 아이템에 응원(==좋아요)이 몰릴 경우 EC2에서 감당 가능한 동시접속자 수와 이 때의 TPS(Transactions per Second)를 3 가지 상황에 대해서 측정한다.
- 공통 조건
- 1 만 명의 유저들이 1만 개의 투두 아이템 중 주키 번호 5000번에 해당하는 투두 아이템에 응원을 보낸다.
- 트래픽이 유지되는 시간은 60초로 설정한다.
- 첫 번째 상황 : t2.micro EC2 1대와 DB만으로 응원 집중 트래픽에 대응한다.
- 이때는 응원 요청이 들어올 때마다 주키 번호 5000번의 투두 아이템을 DB에서 찾아서 응원 개수를 직접 += 1하여 업데이트한다. 그후 응원을 보낸 유저의 주키 번호와 응원 받은 게시물의 번호을 짝지어서 DB에 저장한다.
- 두 번째 상황 : t2.micro EC2 1대, DB, Redis, @Async 로 응원 집중 트래픽에 대응한다.
- 이때는 응원 개수를 DB가 아니라 레디스에 저장하여 DB I/O를 줄인다.
- 응원 보낸 유저 및 응원 받은 투두 아이템 정보를 DB에 기록하는 것은 동일하다.
- @Async한 처리를 위해서 40개의 스레드 풀과 6만의 길이를 갖는 큐를 셋팅한다.
- 세 번째 상황 : 두 번째 상황과 같은 조건인데, t2.micro EC2 3대, 오토 스케일링 그룹, 로드 밸런서를 적용하여 서버를 3대로 늘려서 응원이 집중되는 트래픽을 감당한다.
- DB로만 대응했을 때보다, 레디스와 @Async를 동원했을 때가 감당 가능한 동시접속자 수와 평균 응답지연시간에 있어서 둘 다 3배 정도의 성능 향상을 가져왔다. 이러한 상황에서 250명 정도의 사용자를 처리하는 것이 가장 이상적이었다.
- 로드밸런서와 오토 스케일링 그룹을 동원하자 감당 가능한 동시 사용자 수는 3배가 되었지만 응답시간은 단일 EC2로만 대응했을 때보다 2배가 되면서 느려졌다. 로드밸런서라는 중간 서버가 한 번 더 개입해서 트래픽을 분산시키는 과정이 추가돼서 그런 것으로 생각된다.
- 세 번째 상황의 경우, TPS 그래프가 주기적으로 높아졌다가 낮아지는 것을 반복하는 모습을 보여줬는데, 이는 로드밸런서가 첫 번째 EC2에 트래픽을 주다가, 첫 번째 EC2가 힘들어하면 두 번째 EC2로 트래픽을 전달하고, 두 번째 EC2가 힘들어하면 세 번째 EC2로 트래픽을 전달하고, 다시 첫 번째 EC2로 트래픽을 전달하는 방식으로 순환적으로 트래픽을 전달하기 때문에 그런 것으로 생각된다.
| 상황 | 감당 가능한 동시접속자 수 | TPS | MTT(평균 테스트 시간 == 평균 응답 지연시간) |
|---|---|---|---|
| 첫 번째 상황 | 150 | 145.3 | 1021.44 밀리초 |
| 두 번째 상황 | 250 | 1324.6 | 187.48 밀리초 |
| 두 번째 상황 | 500 | 1534.9 | 312.39 밀리초 |
| 세 번째 상황 | 1500 | 1504.5 | 706.18 밀리초 |
- 첫 번째 상황 테스트 결과 이미지
- 두 번째 상황 동시접속자 수 250명일 때 테스트 결과 이미지
- 두 번째 상황 동시접속자 수 500명일 때 테스트 결과 이미지
- 세 번째 상황 테스트 결과 이미지
- 컨트롤러 설치하기
- nGrinder는 컨트롤러와 에이전트로 나누어져 있다. 우선 nGrinder 공식 깃허브에 가서 가장 최신의 컨트롤러를 war 파일로 다운 받는다. 그 후, 해당 파일을 맥북의 Documents 디렉토리로 옮긴다.
- 그 후,
- java -Djava.io.tmpdir=/Users/bagdongbin/Documents/ngrinder_temp -jar ngrinder-controller-3.5.8.war --port 8080
- 라는 명령어를 입력해서 nGrinder 컨트롤러를 실행시켜본다. 3.5.8이라는 버전명은 2023.4.26 기준 최신버전이기 때문에 나중에는 변경될 가능성이 크다. 그리고 -Djava.io.tmpdir=/Users/bagdongbin/Documents/ngrinder_temp 라는 부분은 nGrinder 실행에 필요한 임시 파일들을 저장해두는 디렉토리를 설정해주는 부분이고, 이 부분이 없으면 오류가 뜬다. 또한 포트 번호가 없을 시에도 오류가 뜨지만, 없을 때도 간혹 되는 경우가 있기 때문에 포트 번호만큼은 각자의 상황에 맞게 넣거나 빼서 실행하면 되겠다.
- 크롬 브라우저에서 url 입력칸에 localhost:8080을 입력해서 nGrinder에 최초로 접속한다. 초기 아이디와 비번은 모두 admin 이다.
- Agent 설치하기
- 그렇게 nGrinder 화면에 접속하면 Agent 파일을 다운 받을 수 있는데, 다운 방법은 ngrinder agent download라는 키워드로 구글링 해보면 금방 알 수 있다.
- nGrinder agent 파일 또한 맥북의 Document 디렉토리로 옮긴다. 그 후,
- tar -xvf ngrinder-agent-3.5.8-localhost.tar
- 라는 명령어를 입력해서 압축 파일을 해제시킨다. 여기 언급된 버전은 현재의 버전과 차이가 날 수 있으므로 각자 다운로다 받은 버전에 맞춰서 명령어를 입력하면 된다.
- 그 후, nGrinder Agent가 압축 해제된 디렉토리에서 아래와 같은
- ./run_agent.sh
- 명령어를 입력하면 nGrinder Agent가 실행되고, 컨트롤러가 실행중일 때, Agent가 알아서 컨트롤러와 연결한다.
- 컨트롤러가 잘 실행되지 않거나, Agent가 컨트롤러가 멀쩡히 돌아가고 있음에도 컨트롤러를 찾지 못할 때는 컨트롤러가 타깃으로 삼고 있는 ip와 Agent가 연결을 시도하는 ip를 일치시키는 작업이 필요하다.
- 관련된 에러 및 nGrinder 실행 시 발생가능한 여러 에러들에 대한 설명은 다음의 블로그에서 잘 설명해 주고 있다.
- JDK 11 버전으로 컨트롤러 및 Agent 실행시키기
- 그 다음으로 해줘야 하는 중요한 작업은 nGrinder의 컨트롤러와 Agent를 실행시킬 JDK를 jdk 11 버전으로 맞춰주는 일이다.
- 꼭 openjdk11로 할 필요는 없으며, Amazon Corretto 11으로 진행해도 문제 없이 진행되었다.
- 맥북 터미널에서 nGrinder를 실행할 때는 컨트롤러와 Agent를 별도의 터미널 탭에서 각자 실행시킬 것인데, 각각의 터미널에 대해서 아래의
- /usr/libexec/java_home -VCopy
- 라는 명령어를 입력해서 현재 맥북에 설치돼 있는 JDK가 뭐가 있는지를 확인해보고, JDK 11이 없는 경우 홈브류를 이용하든, 오라클 공식 홈페이지를 이용하든 JDK 11 버전을 설치해주자.
- 문제는 JDK 11 버전이 이미 설치돼 있지만 상우 버전의 JDK가 맥북 터미널에서의 디폴트 JDK로 셋팅돼 있는 경우다.
- 이때는 아래의 두 가지 명령어를 nGrinder의 컨트롤러 및 Agent가 실행될 예정인 각각의 탭에 대해서 순서대로 입력하여 실행해 준다.
- export JAVA_HOME=$(/usr/libexec/java_home -v 11)
- source ~/.zshrc
- 이 두 명령어는 현재의 탭이 닫히기 전까지는 해당 탭에서 사용하는 디폴트 JDK를 jdk 11 버전으로 유지하라는 뜻이다.
- jdk 11으로 셋팅하는 것이 끝났다면 java -version 명령어를 입력해서 현재 탭에서 실행되는 디폴트 jdk의 버전이 jdk 11 류의 버전인지를 다시 한 번 확인하자.
- 스크립트 작성하고 실제 테스트 진행하기
- nGrinder는 스크립트의 내용대로 테스트를 진행한다. 스크립트를 작성해서 저장해 둬야 한다. 컨트롤러와 Agent를 실행한 후, nGrinder 에 localhost:8080 으로 접속해서, 왼쪽 위에 있는 Script를 선택해서 스크립트를 생성하고 저장하자. 취향에 맞는 스크립트 언어를 선택하면 되고, 나는 groovy 언어를 선택했다.
- 스크립트에서 주목할 부분은 실제 호출을 할 대상 url과 HTTP 메서드의 종류다. 이 부분을 실수 없이 입력하고, 우측 상단의 validate 버튼을 눌러서 콘솔에 뜨는 메시지들을 보자. 여기서 error가 뜨면 안 된다. 물론 validate 버튼을 누르기 전에, 테스트 대상 서버에 실제로 테스트하고자 하는 어플리케이션이 작동 중이어야 한다.
- 스크립트를 작성 완료했다면 저장한다.
- 그 후, nGrinder 화면의 좌측 상단의 Performance Test를 선택해서 테스트를 만들고 Vuser 수, 테스트 실행 시간, 스크립트를 선택하고, 우측 상단의 테스트 시작 버튼을 누른다.
- 오류가 없다면 테스트 진행 페이지로 화면이 바뀌면서 TPS 그래프가 실시간으로 변동하는 모습을 지켜보게 될 것이다.