NGINX Ingress Controller와 Red Hat OpenShift Router 성능 테스트

Amir Rawdat솔루션 엔지니어

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

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

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

• 요소 1: 동적 배포의 지연 시간 결과동적 배포에서 최종 사용자 경험을 측정하는 데 가장 효과적인 지표는 지연 시간의 백분위수 분포입니다. 시스템으로 인해 추가되는 지연 시간이 길수록 사용자 경험에 미치는 영향도 커집니다. 또한 사용자 경험을 정확히 파악하려면 분포의 상위 백분위수에 해당하는 지연 시간도 포함해야 합니다. 자세한 설명은 블로그의 성능 결과 섹션이 포함된 NGINX와 HAProxy: 클라우드에서 사용자 경험 테스트 문서를 참조하세요.
• 요인 2: 시간 초과 및 오류테스트 대상 시스템으로 인해 동적 배포에서 지연 시간이 발생하는 경우, 일반적으로 시스템이 동적 재로드를 제대로 처리하지 못해 시간 초과나 오류가 발생하기 때문입니다.

성능 테스트 결과

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

앞서 설명한 바와 같이, 성능을 평가할 때는 지연 시간과 시간 초과/오류라는 두 가지 요소를 고려합니다.

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

다음 차트에서 볼 수 있듯이 NGINX Ingress Controller로 인해 추가된 지연 시간은 테스트 전반에 걸쳐 미미했으며, 99.999번째 백분위수에서도 최대 700ms 미만이었습니다. 반면 OCP Router는 비교적 낮은 백분위수부터 지연 시간을 추가했으며, 지연 시간은 기하급수적으로 증가하다가 99.99번째 백분위수에서 25,000ms(25초)를 약간 넘는 수준으로 안정화되었습니다. 이는 부하가 걸린 상태에서 클러스터 환경의 변경 사항이 자주 적용될 경우 Router로 인해 사용자 경험이 저하될 수 있음을 보여 줍니다.

요인 2: 시간 초과 및 오류

위에서 관찰된 지연 시간은 시간 초과와 오류로 인한 것입니다. OCP Router에서는 연결 시간 초과가 260건, 읽기 소켓 오류가 85건 발생한 반면, NGINX Ingress Controller에서는 한 건도 발생하지 않았습니다. 다른 성능 테스트(참조: 동적 Kubernetes 클라우드 환경에서 NGINX Ingress Controller 성능 테스트)에서도 확인했듯이, Router의 시간 초과와 오류는 HAproxy가 동적 재로드를 처리하는 방식 때문에 발생합니다. NGINX Plus 기반 NGINX Ingress Controller에서는 엔드포인트가 변경될 때 NGINX Plus API를 사용하여 NGINX 구성을 동적으로 업데이트하므로 시간 초과나 오류가 발생하지 않습니다.

테스트 환경 및 방법론

테스트 토폴로지

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

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

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

TLS 암호화에는 2048비트 키 크기의 RSA와 순방향 비밀성을 사용했습니다.

백엔드 애플리케이션의 각 응답은 약 1KB의 기본 서버 메타데이터와 200 OK HTTP 상태 코드로 구성되었습니다.

테스트 방법론

클라이언트 배포

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

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

사용된 SUT 소프트웨어

• 기본적으로 HAProxy 기반 라우터가 포함된 OpenShift Platform 버전 4.8
• NGINX Ingress Controller 버전 1.11.0 (NGINX Plus R22)

백엔드 배포

백엔드 애플리케이션을 동적으로 배포한 상태에서 다음 스크립트를 사용해 백엔드 복제본 수를 주기적으로 늘리고 줄이며 테스트를 수행했습니다. 이는 동적인 OpenShift 환경을 모사하고 NGINX Ingress Controller 또는 OCP Router가 엔드포인트 변경에 얼마나 효과적으로 대응하는지 측정합니다.

while [ 1 -eq 1 ]
do
  oc scale deployment nginx-backend --replicas=4  
  sleep 10 
  oc scale deployment nginx-backend --replicas=2
  sleep 10
done

결론

마이크로서비스 방법론을 도입한 대부분의 기업은 그 어느 때보다 더 자주 CI/CD 파이프라인을 통해 새로운 개발 사항을 배포하고 있습니다. 따라서 최종 사용자 경험을 저해하지 않으면서 이러한 새로운 방법론에 맞춰 기능과 성능을 확장할 수 있는 데이터 플레인을 활용하는 것이 매우 중요합니다. 최적의 최종 사용자 경험을 제공하려면 어떤 상황에서도 모든 클라이언트 연결에 일관되게 짧은 지연 시간을 보장해야 합니다.

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

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

작성자 소개

Amir Rawdat솔루션 엔지니어

Amir Rawdat의 다른 블로그 게시물