1. 서론
2. 테스트
3. 결론
1. 서론
프로젝트에서 '한 개의 Nginx 서버'가 '두 개의 스프링 서버'로 요청을 로드 밸런싱 하도록 했습니다.
그에 따라 서버를 scale-out 하면 어느 정도의 부하까지 견딜 수 있는지 테스트하고자 했습니다.
2. 테스트
취준생 입장에서 서버 요금은 부담스럽기 때문에, AWS와 네이버 클라우드의 프리티어를 최대한 활용했습니다.
필요한 서버
- Spring WAS 서버 2개
- Nginx 로드 밸런싱 서버 1개 (네이버 클라우스 micro server)
- RDS 1개 (AWS db.t3.micro)
- 10만 User, 10만 Contract, 30만 Board 데이터
부하
JMeter로 초당 300 스레드를 20회 반복하여, 총 6000번 요청했습니다.
테스트 목록
2-1. Spring 서버 1개
2-2. Nginx 서버 + Spring 서버 1개
2-3. Nginx 서버 + Spring 서버 2개
2-4. Nginx 서버 + Spring 서버 2개 (1개는 scale-up)
2-5. scale-up Spring 서버 1개
2-6. Nginx 서버 + Spring 서버 2개 (1개는 scale-up), 가중치 2:1
2-7. Nginx 서버 + Spring 서버 2개 (1개는 scale-up), 가중치 3:2
2 - 1. Spring 서버 1개
- AWS ec2 t2.micro (cpu 1, memory 1gb) : Spring 서버
부하 테스트 결과 평균 335 TPS를 보였습니다.
또한 WAS 서버에서 CPU 사용량이 100%로, 최대 성능을 내고 있었습니다.
2 - 2. Nginx + Spring 서버 1개
- 네이버 클라우드 micro server (cpu 1, memory 1gb) : Nginx
- AWS ec2 t2.micro (cpu 1, memory 1gb) : Spring 서버
부하 테스트 결과 평균 327 TPS를 보였습니다.
또한 WAS 서버에서 CPU 사용량이 100%로, 최대 성능을 내고 있었습니다.
즉, Spring 서버만 있을 때와 비슷한 수준의 TPS를 보였습니다.
또한 네이버 클라우드에서 성능 모니터링으로 Nginx 서버의 CPU 사용률을 확인했습니다.
위 사진은 제가 모든 테스트를 진행할 동안의 Nginx 서버 CPU 사용률입니다.
평균 10% 미만의 사용률을 보였으므로, Nginx 서버에서는 병목이 없었습니다.
Nginx의 Gzip ?
Compress server responses, or decompress them for clients that don’t support compression, to improve delivery speed and reduce overhead on the server.
Compressing responses often significantly reduces the size of transmitted data. However, since compression happens at runtime it can also add considerable processing overhead which can negatively affect performance.
https://docs.nginx.com/nginx/admin-guide/web-server/compression/
Compression and Decompression | NGINX Documentation
Compression and Decompression Compress server responses, or decompress them for clients that don’t support compression, to improve delivery speed and reduce overhead on the server. This section describes how to configure compression or decompression of r
docs.nginx.com
Nginx의 Gzip은 서버 응답을 압축하거나 압축을 지원하지 않는 클라이언트의 경우 압축을 풀어 전송 속도를 높이고 서버의 오버헤드를 줄입니다. 응답을 압축하면 전송되는 데이터의 크기가 크게 줄어드는 경우가 많습니다. 그러나 압축은 런타임에 발생하므로 성능에 부정적인 영향을 줄 수 있는 상당한 처리 오버헤드가 추가될 수도 있습니다.
즉, 응답을 압축하여 클라이언트에게 전송하기 때문에, 네트워크 전송 속도를 높일 수 있습니다.
하지만 압축하는 과정에서 오버헤드가 발생할 수 있고, 이 때문에 성능 저하가 일어날 수도 있습니다.
2 - 3. Nginx + Spring 서버 2개
- 네이버 클라우드 micro server (cpu 1, memory 1gb) : Nginx
- AWS ec2 t2.micro 2개 (cpu 1, memory 1gb) : Spring 서버 2개
부하 테스트 결과 평균 606 TPS를 보였습니다.
2개의 Spring 서버 모두 CPU 사용률 100%로 최대 성능을 내고 있었고,
1개의 Spring 서버만 있을 때보다 거의 2배의 성능 차이를 보여줬습니다. (서버가 2배 되었으니까 예상한 결과)
2 - 4. Nginx + Spring 서버 2개 (1개 Scale-up)
- 네이버 클라우드 micro server (cpu 1, memory 1gb) : Nginx
- AWS ec2 t2.micro (cpu 1, memory 1gb) : Spring 서버
- AWS ec2 t2.medium (cpu 2, memory 4gb) : Spring 서버
1개의 Spring 서버를 Scale-up하여 테스트를 진행했습니다.
cpu 코어는 2배가 되었고 메모리는 4배가 되었으므로 전체 TPS가 1.5배 향상될 것이라 예상했습니다.
부하 테스트 결과 평균 588TPS를 보였습니다.
1개의 서버를 Scale-up 하기 전보다 낮은 TPS를 보여줬지만, 이 정도는 네트워크 상황에 따라 달라질 수 있는 오차범위 내라고 생각하고, Scale-up 전과 비슷한 성능을 보여줬습니다.
스프링 서버 2개의 사용량을 확인한 결과,
Scale-up한 서버는 CPU 사용률이 66%로 최대 성능을 내지 않았고,
기존의 다른 서버는 여전히 CPU 사용률 100%로 최대 성능을 내고 있었습니다.
그래서 Scale-up한 서버의 최대 성능의 TPS를 알아보기 위해, 따로 테스트 해봤습니다.
2 - 5. Scale-up Spring 서버 1개
- AWS ec2 t2.medium (cpu 2, memory 4gb) : Spring 서버
부하 테스트 결과 평균 407 TPS를 보였습니다.
cpu 1, memory 1gb 서버보다 21% 높은 처리량입니다.
CPU 사용률 또한 99.8%로, 최대 성능을 내고 있었습니다.
즉, cpu가 2배, memory가 4배 늘었다고 해서, 2배 이상의 성능 차이를 보이진 않았습니다.
다음으로, Scale-up한 서버에 weight=2 설정으로 가중치를 주고, 로드 밸런싱해봤습니다.
2 - 6. Nginx + Spring 서버 2개 (1개 Scale-up, weight = 2)
- 네이버 클라우드 micro server (cpu 1, memory 1gb) : Nginx
- AWS ec2 t2.micro (cpu 1, memory 1gb) : Spring 서버
- AWS ec2 t2.medium (cpu 2, memory 4gb) : Spring 서버
- Scale-up 한 서버에 가중치를 2로 설정 (2:1)
부하 테스트 결과 평균 668 TPS로 10%이상 더 높은 처리량을 보여줬습니다.
Spring 서버의 CPU 사용률을 확인했을 때,
Scale-up한 서버의 경우 사용률이 100%로 최대 성능을 내고 있었지만,
기존의 서버는 CPU 사용률이 70% 정도로 최대 성능을 내고 있지 않았습니다.
그래서 한 번 더 가중치를 수정하여, 두 서버 모두 최대 성능을 낼 수 있도록 3:2 비율로 가중치를 설정했습니다.
2 - 7. Nginx + Spring 서버 2개 (1개 Scale-up, weight 3:2)
- 네이버 클라우드 micro server (cpu 1, memory 1gb) : Nginx
- AWS ec2 t2.micro (cpu 1, memory 1gb) : Spring 서버
- AWS ec2 t2.medium (cpu 2, memory 4gb) : Spring 서버
- 두 서버의 가중치를 3 : 2로 설정
부하 테스트 결과 평균 732 TPS를 보여줬습니다.
두 개의 서버 모두 98% CPU 사용률로, 거의 최대에 가까운 성능을 내고 있었습니다.
즉, 가중치를 3 : 2로 설정하면서, 같은 가중치를 가질 때보다 20% 정도 높은 처리량을 보여줬습니다.
3. 결론
Nginx를 사용하여 서버를 로드 밸런싱하고, 부하 테스트를 진행하여 그에 따른 TPS로 성능을 비교하였습니다.
같은 사양의 서버를 1개 추가하여, 2개의 서버에 로드 밸런싱했을 때는 예상처럼 약 2배 높은 처리량을 보여줬습니다.
하지만 서버를 scale-up하여 2배의 cpu와 4배의 memory를 사용할 때는 약 20% 정도 높은 처리량을 보이고,
그에 따라 로드 밸런싱으로 최대 성능을 내게 했을 때도 20% 정도 높은 TPS를 보여줬습니다.