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

Red Hat OpenShift Container Platform(OCP)은 가장 인기 있는 관리형 Kubernetes 플랫폼 중 하나이며, 경쟁사와 마찬가지로 OCP에는 사용자가 빠르게 시작할 수 있도록 지원하는 기본 트래픽 관리 도구가 포함되어 있습니다. HAProxy를 기반으로 하는 OCP Router는 OCP 클러스터의 기본 Entry Point입니다. HTTP 및 WebSocket 트래픽을 Load balancing하고 Router와 애플리케이션 인스턴스 간의 TLS와 TLS termination를 지원하며 passthrough 모드에서 TLS 연결을 Load balancing할 수 있습니다.

고객은 종종 “Router를 무료로 사용할 수 있는데 왜 OpenShift에서 NGINX Ingress Controller를 사용해야 합니까?”라고 묻습니다. GigaOm의 Max Mortillaro는 “OpenShift에 Enterprise-Grade Ingress Controller가 필요한 이유“에서 고급 트래픽 관리, 사용 편의성, JWT 검증 및 WAF 통합 등 NGINX Ingress Controller를 사용해야 하는 몇 가지 이유를 설명합니다. 정량적 관점에서 이 질문에 답하는 것도 중요합니다. 따라서 OCP 환경에서 Router와 NGINX Plus 기반 NGINX Ingress Controller(nginxinc/kubernetes-ingress)를 테스트하는 동안 upstream(backend) 서버의 수를 위/아래로 확장한 동적 배포 환경에서 성능을 테스트했습니다.

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

요인 1: 동적 배포의 지연 시간 결과

동적 배포에서 최종 사용자 경험(UX)을 측정하는 가장 효과적인 metric은 대기 시간 백분위수 분포입니다. 시스템에서 추가된 대기 시간이 많을수록 사용자 경험(UX)이 더 많이 영향을 받습니다. 또한 실제 사용자 환경을 파악하려면 분포의 상위 백분위수 대기 시간을 포함해야 합니다.

요인 2: 시간 초과 및 오류

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

목차
1. 성능 테스트 결과
1-1. 요인 1: 대기 시간 백분위수 분포
1-2. 요인 2: 시간 초과 및 오류
2. 테스트 설정 및 방법론
2-1. Topology 테스트
2-2. 테스트 방법론
3. 결론

1. 성능 테스트 결과

흥미로운 부분으로 바로 이동하여 결과를 검토해 보겠습니다. Topology 테스트 및 방법에 대한 자세한 내용은 다음과 같습니다.

위에서 논의한 바와 같이 성능을 평가할 때 대기 시간과 시간 초과/오류라는 두 가지 요소를 고려합니다.

1-1. 요인 1: 대기 시간 백분위수 분포

다음 차트에서 볼 수 있듯이 NGINX Ingress Controller는 테스트 전반에 걸쳐 무시할 수 있는 대기 시간을 추가하여 99.999번째 백분위수에서 최대 700ms 미만에 도달했습니다. 대조적으로, OCP Router는 상당히 낮은 백분위수에서 대기 시간을 추가했으며 대기 시간은 99.99번째 백분위수에서 25,000ms(25초)를 약간 넘을 때까지 기하급수적으로 증가했습니다. 이는 클러스터 환경의 변경 사항이 자주 적용되는 동안 부하가 걸리면 Router가 좋지 않은 사용자 경험(UX)을 유발할 수 있음을 보여줍니다.

1-2. 요인 2: 시간 초과 및 오류

위에서 관찰된 대기 시간은 시간 초과 및 오류로 인한 것일 수 있습니다. OCP Router는 260개의 연결 시간 초과 및 85개의 소켓 읽기 오류를 생성했지만 NGINX Ingress Controller는 아무 것도 생성하지 않았습니다. 다른 성능 테스트(동적 Kubernetes 클라우드 환경에서 NGINX Ingress Controller 성능 테스트 참조)에서 살펴본 바와 같이, Router의 시간 초과 및 오류는 HAproxy가 동적 reload를 처리하는 방식으로 인해 발생합니다. NGINX Plus 기반 NGINX Ingress Controller는 NGINX Plus API를 사용하여 Endpoint가 변경될 때 NGINX 구성을 동적으로 업데이트하기 때문에 시간 초과나 오류를 일으키지 않습니다.

2. 테스트 설정 및 방법론

2-1. Topology 테스트

System Under Test(SUT)과 마찬가지로 NGINX Ingress Controller와 OpenShift Router 모두에서 동일한 테스트를 수행했습니다. SUT는 클라이언트의 TLS 1.3 연결을 종료하고 별도의 연결을 통해 클라이언트 요청을 backend 배포로 전달합니다.

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

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

TLS 암호화의 경우 2048비트 키 크기와 Perfect Forward Secrecy를 사용하는 RSA를 사용했습니다.

Backend 애플리케이션의 각 응답은 200 OK HTTP 상태 코드와 함께 약 1KB의 기본 서버 metadata로 구성되었습니다.

2-2. 테스트 방법론

클라이언트 배포

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

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

사용된 SUT 소프트웨어

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

Backend 배포

다음 스크립트를 사용하여 Backend replica의 수를 주기적으로 늘리거나 줄이며 Backend 애플리케이션의 동적 배포로 테스트 실행을 수행했습니다. 이것은 동적 OpenShift 환경을 에뮬레이트하고 NGINX Ingress Controller 또는 OCP Router가 endpoint 변경에 얼마나 효과적으로 적응하는지 측정합니다.

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

3. 결론

Microservice 방법론을 채택하는 대부분의 기업은 그 어느 때보다 높은 빈도로 CI/CD Pipeline을 통해 새로운 개발을 추진하고 있습니다. 이러한 이유로 최종 사용자 경험(UX)을 방해하지 않으면서 기능과 성능 면에서 이러한 새로운 방법론과 함께 성장하는 Data Plane을 활용하는 것이 중요합니다. 최적의 사용자 경험(UX)을 제공하려면 모든 상황에서 모든 클라이언트 연결에 대해 낮은 지연 시간을 일관되게 제공해야 합니다.

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

NGINX Ingress Controller를 직접 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.

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