[트러블 슛팅] 서버 부하 테스트 & 스케일 업

실전 프로젝트를 진행하며 겪었던 트러블 슛팅에 대해서 간단히 기록하려고 한다.

1. 문제 & 원인

1) 문제 발생

• 유저 테스트 기간 중, 약 15명의 유저가 서비스를 이용하다가 DB가 정상적으로 작동하지 않는 문제 발생
• 여러 유저가 계속해서 훈수 무한 채팅을 시도한 상황을 파악

• 훈수 채팅은 위의 시연 영상에서, 채팅을 치면 구름이 지나가는 채팅을 뜻합니다.

*훈수 채팅 로직
유저가 socket으로 채팅 내용을 서버에 전달  =>  서버에서 해당 ID의 훈수 채팅 cnt를 +1로 업데이트
=> socket으로 해당 방의 모든 유저에게 채팅 내용을 전달 => 전달받은 채팅 내용을 화면의 효과 처리함

 

2) 원인 파악

• 유저 테스트 기간 중 훈수 채팅 서비스는 무한 채팅이 가능한 상황이었고, 여러 유저의 동시적인 무한 채팅으로 인해 socket과 DB에서 병목 현상이 일어났고, 서버 과부화로 이어진 것으로 판단함
• 예상한 문제점이 맞는지에 대해서 확인하기 위해 Artillery를 통해서 무한 채팅 시나리오를 작성하여 서버 부하 테스트 진행

*Why Artillery?
- 서버 부하 테스트를 위해 처음에는 오픈소스로 대중적인 J Meter를 이용하려 하였으나, socket.io와 호환 이슈가 있음을 발견
- Node.js 라이브러리 중 socket.io에서 공식적으로 추천하는 Artillery를 통하여 서버 부하 테스트를 진행하기로 결정

 

3) 서버 부하 테스트를 통한 원인 캐치 

• 동일한 환경에서 무한 채팅 시나리오를 진행

1) 동시접속자 60명, 초당 360emit을 40초가량 보내면  서버가 다운되는 문제점 발견

2) 서버가 다운됨과 동시에 아래와 같이 socket response time이 극단적으로 길어지는 문제 발견 (병목현상)

=> 이를 통해 위의 원인 파악했던 내용이 맞는 것으로 판단함

 

2. 해결 방안

• 내부 논의를 통해 무한 채팅 관련해서 논의하여 2가지 해결 방안을 결정함
• 1) 프론트엔드에서 채팅을 1초에 1번으로 제한하여, 원천적으로 무한 채팅 방지
• 2) 적어도 70명이  동시에 서비스 이용이 가능한 상태로 서버 구축
• 2)번의 내용에 대해서, 현재 EC2 사양이 T3 micro이기에, 우선 한 단계 스케일 업을 진행하고, 그래도 해결되지 않으면 향후 스케일 아웃도 고려해보기로 결정

 

3. 서버 부하 테스트 & 스케일 업

• 서비스 특성상 서버 부하는 socket 부분에서 생길 것으로 판단하였고, 그 중에서도 채팅과 팀 변경으로 인한 부하가 클 것으로 판단되어, 이 부분을 집중적으로 반복하는 3가지 시나리오를 작성함
• 동시접속자 70명 이상일 시, socket.io reponse_time은 max가 100 안으로 들어오는 것을 목표로 하였고, CPU 사용률도 평균 30%대를 넘지 않는 것을 목표로 함
• 예정대로 한 단계 스케일 업 한 후에 Artillery를 통하여 서버 부하 테스트를 진행하였고, Artillery report와 AWS Cloud Watch로 서버 부하 수준을 파악함.

 *서버 부하 테스트 결과

1) 시나리오 1 결과

2) 시나리오 2 결과

3) 시나리오 3 결과

4. 결과

• 스케일 업 한 서버가 동시접속자 100명까지는 안정적으로 서비스 될 것으로 판단, 추가적인 스케일 아웃은 진행하지 않음
  • 스케일 업 한 서버의 한계치는 동시접속자 300명, 초당 600emit 60초 지속할 시 서버 다운
• 지속적으로 AWS Cloud Watch를 통해서 서버를 모니터링 하였고, 계속해서 안정적인 서비스 운영 중