테스트 진행
어제에 이어서 테스트를 진행했는데 문제가 있었다
웹소켓 서버에 동시에 연결을 시도할 사용자 수(스레드 수)를 설정한다. 이번 테스트에서는 약 500명의 동시 사용자를 가정했다.웹소켓 서버에 연결하고, 메시지를 전송하는 요청을 설정한다. 이 과정에서, 서버로부터의 응답도 캡처했는데...
500명 정도가 되니 실패율이 크게 늘어나버렸다.
그리고 서버에 문제도 있었는데.
100%를 다 사용해버리며 실패가 기하급수적으로 늘어나버렸다..
성능 테스트 결과 분석
이번 테스트에서는 약 500명의 동시 사용자가 웹소켓 서버에 연결을 시도했을 때, 서버의 응답 시간이 급격히 증가하고, 연결 실패율이 높아지는 현상을 관찰했다. 이는 서버가 과부하 상태에 이르렀음을 나타낸다. 특히, CPU 사용률과 메모리 사용량이 급격히 상승하여, 서버의 안정성과 성능이 크게 저하되었다는 것을 확인할 수 있었다.
해결방법 모색
이 과정중에서 두가지를 고민했다.
스케일 아웃(수평 확장)
- 문제: 서버의 리소스 한계로 인해 성능이 저하된다.
- 해결 방안: 추가 서버를 도입하여 애플리케이션을 수평적으로 확장한다. 이를 통해 처리 능력을 증가시키고, 단일 서버의 과부하 문제를 해결한다.
인스턴스 사양 업그레이드(수직 확장)
- 문제: 현재 서버 사양이 트래픽을 감당하기에 부족하다.
- 해결 방안: AWS 인스턴스의 사양을 Medium에서 XL로 업그레이드하여 CPU, 메모리, 네트워크 대역폭 등의 리소스를 증가시킨다. 이 방법은 빠르게 성능 문제를 해결할 수 있는 장점이 있다.
라는 방법들을 생각을 했는데
선택한 방법은 인스턴스 사양 업그레이드였다.
이는 단기간 내에 시스템 성능을 크게 향상시킬 수 있으며, 현재의 과부하 상황을 신속하게 해결할 수 있는 가장 직접적인 방법이었다. 물론, 장기적으로는 코드 최적화, 로드 밸런싱, 스케일 아웃 등의 추가적인 방법들도 함께 고려할 필요가 있다.
인스턴스 사양 업그레이드
현재는 인스턴스 사양을 Medium에서 XL로 업그레이드를 해보았다.
업그레이드 후 성능 평가
사양이 XL로 업그레이드된 후, 동일한 웹소켓 성능 테스트를 재실시하여 성능 변화를 평가했다. 결과적으로, 서버의 응답 시간이 개선되었고, 동시 사용자 500명에 대한 연결 실패율이 크게 감소했다.감소하다 못해 500명은 미리 처리해버리고 전송되지않는 시간까지 생겨벼렸다. 이는 서버 리소스의 증가가 웹소켓 통신의 안정성과 성능을 크게 향상시켰음을 의미한다. CPU와 메모리 사용률도 안정적인 수준을 유지하며, 사용량도 크게 줄어들며 시스템의 전반적인 안정성이 개선되었다.
