성능 테스트 NGINX Ingress Controller 및 Red Hat OpenShift 라우터

Red Hat OpenShift Container Platform(OCP)은 가장 인기 있는 관리형 Kubernetes 플랫폼 중 하나이며, 경쟁 제품과 마찬가지로 OCP에는 사용자가 빠르게 시작할 수 있도록 돕는 기본 트래픽 관리 도구가 포함되어 있습니다. HAProxy 기반의 OCP 라우터 는 OCP 클러스터의 기본 진입점입니다. HTTP 및 WebSocket 트래픽에 대한 부하를 분산하고, 라우터와 애플리케이션 인스턴스 간의 TLS 종료 및 TLS를 지원하며, 패스스루 모드에서 TLS 연결에 대한 부하를 분산할 수 있습니다.

고객들은 종종 "라우터를 무료로 사용할 수 있는데 왜 OpenShift에서 NGINX Ingress Controller를 사용해야 합니까?"라고 묻습니다. OpenShift에서 엔터프라이즈급 Ingress 컨트롤러가 필요한 이유 에서 게스트 블로거인 GigaOm의 Max Mortillaro는 NGINX Ingress Controller를 사용해야 하는 몇 가지 정성적 이유를 공유합니다. 여기에는 고급 트래픽 관리, 사용 편의성, JWT 검증, WAF 통합이 포함됩니다. 하지만 이 질문에 정량적인 관점에서 답하는 것도 중요합니다. 그래서 우리는 OCP 환경에서 라우터와 NGINX Plus 기반 NGINX Ingress Controller ( nginxinc/kubernetes-ingress ) 에 대한 성능 테스트를 진행했고, 테스트 중에 업스트림(백엔드) 서버의 수를 늘리거나 줄이는 동적 배포 환경을 진행했습니다.

성능 테스트를 수행할 때 우리는 도구의 성능을 평가하기 위해 두 가지 요소를 살펴봅니다.

• 요인 1: 동적 배포에 대한 대기 시간 결과

  동적 배포에서 최종 사용자 경험을 측정하는 데 가장 효과적인 지표는 지연 시간 백분위수 분포라는 것을 발견했습니다. 시스템에 의해 지연 시간이 길어질수록 사용자 경험에 미치는 영향도 커집니다. 또한 사용자 경험에 대한 실제 그림을 얻으려면 분포의 상위 백분위수에 대한 대기 시간을 포함해야 한다는 사실도 발견했습니다. 자세한 설명은 다음을 참조하세요. 성과 결과 섹션의 NGINX 및 HAProxy: 클라우드에서 사용자 경험 테스트 우리의 블로그에서.

• 요인 2: 시간 초과 및 오류

  테스트 중인 시스템이 동적 배포에서 지연을 유발하는 경우, 일반적으로 시스템에서 동적 다시 로드를 처리하는 데 문제가 있거나 시간 초과 또는 오류가 발생하기 때문입니다.

성능 테스트 결과

흥미로운 부분으로 바로 들어가서 결과를 살펴보겠습니다. 테스트 토폴로지와 방법 에 대한 자세한 내용은 다음과 같습니다.

위에서 설명한 대로 성능을 평가할 때는 지연 시간과 시간 초과/오류라는 두 가지 요소를 고려합니다.

요인 1: 지연 백분위수 분포

아래 차트에서 알 수 있듯이 NGINX Ingress Controller는 테스트 내내 무시할 만한 지연 시간을 추가했으며 99.999번째 백분위수에서 최대 700ms 미만에 도달했습니다. 이와 대조적으로 OCP 라우터는 비교적 낮은 백분위수에서 지연 시간을 추가했으며 지연 시간은 기하급수적으로 증가하여 99.99번째 백분위수에서 25,000ms(25초)가 조금 넘는 수준에서 정점에 도달했습니다. 이는 클러스터 환경에서 변경 사항이 자주 적용되는 부하가 발생하면 라우터가 사용자 환경을 저하시킬 수 있음을 보여줍니다.

요인 2: 시간 초과 및 오류

위에서 관찰된 지연은 시간 초과 및 오류로 인한 것일 수 있습니다. OCP 라우터는 260개의 연결 시간 초과와 85개의 읽기 소켓 오류를 발생시킨 반면, NGINX Ingress 컨트롤러는 오류를 전혀 발생시키지 않았습니다. 다른 성능 테스트에서 보았듯이( 동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트 참조), 라우터의 시간 초과 및 오류는 HAproxy가 동적 다시 로드를 처리하는 방식으로 인해 발생합니다. NGINX Plus 기반의 NGINX Ingress Controller는 엔드포인트가 변경될 때 NGINX Plus API를 사용하여 NGINX 구성을 동적으로 업데이트하므로 시간 초과나 오류가 발생하지 않습니다.

테스트 설정 및 방법론

토폴로지 테스트

우리는 테스트 시스템(SUT)으로서 NGINX Ingress Controller와 OpenShift Router에서 동일한 테스트를 실행했습니다. SUT는 클라이언트로부터 TLS 1.3 연결을 종료하고 별도 연결을 통해 클라이언트 요청을 백엔드 배포에 전달했습니다.

클라이언트는 OpenShift 클러스터와 동일한 LAN에 위치한 CentOS 7을 실행하는 별도의 머신에 호스팅되었습니다.

SUT와 백엔드 배포는 VMware vSphere 6.7.0.45100에 호스팅된 OCP 클러스터에서 실행되었습니다.

TLS 암호화의 경우, 2048비트 키 크기와 완벽한 순방향 비밀성을 갖춘 RSA를 사용했습니다.

백엔드 애플리케이션의 각 응답은 다음으로 구성됩니다. 약 1KB 기본 서버 메타데이터와 함께 그 200 좋아요 HTTP 상태 코드.

테스트 방법론

클라이언트 배포

wrk2 (버전 4.0.0)를 사용하여 클라이언트 머신에서 다음 스크립트를 실행하고, 초당 1000개 요청(RPS, -R 옵션으로 설정)의 일정한 처리량으로 60초 동안 테스트를 실행했습니다( -d 옵션으로 설정).

./wrk -t 2 -c 50 -d 60초 -R 1000 -L https:// ingress-url :443/

사용된 SUT 소프트웨어

• 기본적으로 HAProxy 기반 라우터를 포함하는 OpenShift Platform 버전 4.8
• NGINX Ingress 컨트롤러 버전 1.11.0 (NGINX Plus R22)

백엔드 배포

다음 스크립트를 사용하여 백엔드 복제본의 수를 주기적으로 늘리거나 줄이는 방식으로 백엔드 애플리케이션을 동적으로 배포하여 테스트를 수행했습니다. 이는 동적인 OpenShift 환경을 에뮬레이트하고 NGINX Ingress Controller 또는 OCP 라우터가 엔드포인트 변경에 얼마나 효과적으로 적응하는지 측정합니다.

while [ 1 -eq 1 ]
do
oc 스케일 배포 nginx-백엔드 --replicas=4 
sleep 10 
oc 스케일 배포 nginx-백엔드 --replicas=2
sleep 10
done

결론

마이크로서비스 방법론을 도입한 대부분의 회사는 그 어느 때보다 더 높은 빈도로 CI/CD 파이프라인을 통해 새로운 개발을 추진하고 있습니다. 이러한 이유로 최종 사용자 경험을 방해하지 않으면서 이러한 새로운 방법론의 기능과 성능에 따라 성장하는 데이터 플레인을 활용하는 것이 중요합니다. 최적의 최종 사용자 경험을 제공하려면 모든 상황에서 모든 클라이언트 연결에 대해 지속적으로 낮은 지연 시간을 제공해야 합니다.

성능 결과에 따르면, NGINX Ingress Controller는 개발을 반복하고 개선해야 할 필요성이 높은 컨테이너화된 환경에서 최적의 최종 사용자 경험을 제공합니다.

시작하려면 NGINX Ingress Controller의 무료 평가판을 다운로드하고 NGINX Ingress Operator를 사용하여 배포하는 방법을 알아보세요.