[Trouble Shooting] 대용량 트래픽에 적합한 부하 테스트 환경 (티켓팅 서비스)

 

🎯 로컬 환경에서 대용량 트래픽 부하 테스트는 적절하지 못함..

---

가장 처음에 진행했던 부하 테스트 환경입니다.

 

(1) 애플리케이션 로컬 도커로 띄우기

(2) 내 컴퓨터에서 K6 부하 발생 

(3) Grafana 에서 부하 결과 모니터링

 

 

즉, 부하 발생부터 애플리케이션 실행까지 전부 로컬 컴퓨터에서 진행되었습니다. 

 

 

K6 를 통해 API 엔트포인트로 초당 500개 정도의 요청을 보내봤지만 평균 응닶값이 20초, 절반이상의 요청들이 dropped 되는 것을 확인했습니다. 혹시 카프카 문제인가 싶어서 요청 후 바로 응답해주는 테스트용 API 를 만들어 진행해도 결과는 비슷했습니다. 

 

 

그래서 애플리케이션 자체에서의 병목이 아니라 부하를 발생시키는 k6 와 이를 처리하는 서버가 같은 컴퓨터에서 실행되고 K6 에서 도커로 넘어가는 흐름이 문제일 수 있겠다라고 의심했습니다.(서버 CPU, 메모리 등은 매우 양호했음) 그래서 k6를 Docker 로 실행하고 같은 Docker 네트워크에서 API 서버로 요청을 보내본 결과 평균 응답 속도가 ms 수준으로 회복됨을 확인했습니다.

 

 

즉, 로컬 K6 -> 로컬 Docker 컨테이너 안의 서버로 요청을 보내면 로컬 커널을 거쳐 이동합니다. Docker는 기본적으로 bridge 네트워크를 사용하며, 이는 호스트 NIC와는 별개의 가상 인터페이스를 생성해 트래픽을 라우팅합니다.이 과정에서 NAT 변환, 패킷 복사, 커널 네트워크 스택 오버헤드가 발생해 기대했던 결과보다 느렸던 것 이었습니다.

 

 

결과적으로 컨텍스트 스위칭 비용, 네트워크 I/O 지연, 리소스 경합 등이 발생해 가벼운 논블로킹 요청이여도 부하 시나리오가 무거워지면 응답 시간이 늘어날 수 밖에 없는 환경이기에 대용량 트래픽에 대한 부하 테스트는 로컬 환경에서 적절하지 못함을 알게 되었습니다.

 

 

흠.. 그러면 어떻게 대용량 트래픽에 대한 부하 테스트를 진행하지 ? 다른 사람들은 높은 부하 테스트를 어떻게 하는지 찾아본 결과 부하 발생 인스턴스와 서버 인스턴스를 따로 분리해 같은 컴퓨터 내에서의 리소스 경합 과정을 배제하는 방식을 많이 사용했습니다.  (아래 블로그 에서 많이 참고했습니다.)

 

https://vince-kim.tistory.com/39

대용량 트래픽은 어떻게 테스트해야할까? 60만 RPM 테스트하기 (K6, AWS, EC2, 테스트, 성능테스트)

 

 

즉, 일반적으로 부하 테스트를 진행할때 다음과 같은 과정을 거칩니다.

 

 

1. 로컬 환경에서 빠르게 테스트 시나리오 확인

2. 별도의 클라우드 서버(EC2, 쿠버네티스 등)에서 정밀한 부하 테스트 진행

3. 부하 발생기는 별도의 서버에서 띄움

4. 네트워크 병목 최소화 

 

이렇게 K6 부하 발생 인스턴스와 서버 애플리케이션 인스턴스를 분리하면 

 

로컬 부하 -> 로컬 Docker 에서 발생하는 가상 NIC -> NAT -> docerk0(기본 도커 네트워크) ->  커널 네트워크 -> 컨테이너로 이어지는 흐름에서 일반 TCP/IP 통신으로 처리되어 NAT 와 기본 도커 네트워크, 가상 NIC 도 없어 더 빠른 성능을 확보할 수 있습니다.

 

 

그리고 가장 중요한 점은 같은 자원을 공유하지 않는다는 점 입니다. 또한 EC2 를 통해 분리하면 부하 테스트를 진행하다 병목이 생겼을때 서버 CPU 가 과부하면 서버 문제임을 알 수 있고, K6 가 느리면 네트워크나 K6 인스턴스에 문제가 있음을 정확히 알 수 있습니다.

 

 

그리고 여기서 한가지 더 의문점이 생겼던건, 서버는 EC2 에 올리고, 부하 발생은 내 컴퓨터에서 하면 안되나? 결론부터 말하면 가능은 하지만 좋은 방법은 아니였습니다. 내 컴퓨터에서 EC2 서버로 테스트할경우 테스트 트래픽이 실제 인터넷을 통해 요청이 보내지기 때문에 ISP -> 백본망 -> AWS 로 이동하고 이 과정에서 패킷 손실이나 지연이 발생할 수 있고 네트워크 품질에 따라 테스트 결과가 매번 달라져 테스트에 대한 신뢰도가 저하될 수 있습니다.

 

 

이러한 이유 때문에 대용량 트래픽에 대한 부하 테스트를 진행할때 부하 발생 인스턴스, 서버 인스턴스를 각각 배포하는 분리를 결정했습니다.

 

 

 

일단 하나의 대기열 서버가 어느 정도의 RPS를 견딜 수 있는지 테스트해보고, 그에 맞춰 적절한 EC2 인스턴스 유형을 선택하며 성능을 조정해나가는 것이 중요해 보입니다.