Amazon EKS에 NGINX Ingress Controller 배포하기: 테스트 방법

Amir Rawdat솔루션 엔지니어

NGINX는 고객이 소프트웨어를 최대한 활용할 수 있도록 지원하는 방법을 끊임없이 모색하고 있습니다. NGINX가 제공하는 중요한 리소스 중 하나인 솔루션 개요 및 규모 산정 가이드에서는 다양한 컴퓨팅 성능 수준에서 기대할 수 있는 성능을 실증적으로 테스트합니다. 이를 통해 고객은 기존 인프라로 애플리케이션 전송 성능을 극대화하고, 준비 중인 성능과 규모에 필요한 운영 비용을 정확하게 산정할 수 있습니다.

최근 Amazon Elastic Kubernetes Service(EKS) 규모 산정 가이드라인을 추가하여 NGINX Ingress Controller 솔루션 개요서를 업데이트했습니다. 이 개요서에서는 Amazon EKS의 다양한 인스턴스 유형에서 NGINX Ingress Controller를 실행할 때 기대할 수 있는 성능과 예상 월간 총소유비용(TCO)을 설명합니다. 이 블로그에서는 이러한 수치를 산출한 방법과 함께, 유사한 테스트를 직접 수행하는 데 필요한 모든 정보를 소개합니다.

토폴로지

다음 다이어그램은 테스트에 사용된 토폴로지를 보여줍니다.

• 관리자는 다음 섹션에 명시된 명령을 실행하여 테스트를 수행하는 사용자입니다.
• Amazon ECR(Elastic Container Registry)은 테스트에 사용되는 공식 NGINX Plus Ingress Controller Docker 이미지를 호스팅합니다. NGINX Plus Ingress Controller 배포를 참조하세요.
• Amazon EC2(Elastic Compute Cloud)는 wrk가 실행되어 요청을 생성하는 c5n.9xlarge 이미지를 호스팅합니다. 테스트 방법론을 참조하세요.
• Amazon EKS(Elastic Kubernetes Service)는 NGINX Plus Ingress Controller와 백엔드 애플리케이션용 c5n.9xlarge 이미지를 호스팅합니다. Amazon EKS 클러스터 생성을 참조하세요.
• NGINX Plus Ingress Controller는 wrk에서 생성된 요청을 백엔드 애플리케이션으로 프록시하고 애플리케이션의 응답을 반환합니다. NGINX Plus Ingress Controller 배포를 참조하세요.
• 백엔드 애플리케이션은 NGINX가 프록시한 요청에 응답합니다. 백엔드 Pod 배포를 참조하세요.

Amazon EKS 클러스터 생성

EKS 클러스터를 배포하기 전에 다이어그램에서 관리자 아이콘으로 표시된 로컬 머신에서 다음 단계를 수행합니다:

1. Amazon EKS의 공식 명령줄 인터페이스인 eksctl을 다운로드합니다. 컴퓨터에 이미 eksctl이 설치되어 있다면 최신 버전으로 업데이트해야 합니다.
2. 적절한 AWS 관리자 자격 증명을 ${HOME}/.aws/credentials 파일에 추가합니다.
3. 이 블로그의 YAML 파일을 Gist 저장소에서 다운로드합니다.
4. 다운로드하세요: rbac.yaml(NGINX App Protect를 사용하는 경우 ap-rbac.yaml) — GitHub의 NGINX Ingress Controller 저장소에서 받을 수 있습니다.

EKS 클러스터를 배포하려면 로컬 머신에서 다음 eksctl 명령을 실행합니다. (기본적으로 이 명령은 테스트에 필요한 노드 두 개, 즉 NGINX Plus Ingress Controller용 노드 하나와 기본 백엔드 애플리케이션용 노드 하나를 생성하므로 --nodes 플래그는 생략합니다.)

참고: EKS 클러스터는 us-west-1을 제외한 모든 리전에 배포할 수 있습니다. 해당 리전에서는 Amazon Marketplace for Containers의 NGINX Plus Ingress Controller 이미지 구독이 지원되지 않습니다(다음 섹션 참조).

# eksctl create cluster --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/path/to/public-key

SSH를 통해 클러스터 노드에 연결하려면 다음 명령을 실행합니다. 테스트 중에는 NGINX Plus Ingress Controller 노드에 연결하여 htop 명령을 실행하고 wrk 클라이언트의 부하가 노드의 CPU 사용률을 100%까지 끌어올리기에 충분한지 확인해야 합니다.

# ssh -i /path/to/private-key ec2-user@<public-IP-address-of-EKS-node>

NGINX Plus Ingress Controller 배포

이제 Amazon EKS에 NGINX Plus Ingress Controller를 그 어느 때보다 쉽게 배포할 수 있습니다.

1. EKS 클러스터용 OIDC ID 공급자(IdP)를 생성합니다.

# eksctl utils associate-iam-oidc-provider --region=<eks-cluster-region> --cluster=<eks-cluster-name> --approve

1. EKS용 표준 페어인 iamserviceaccount를 생성하고, IAM 역할 및 서비스 계정(IRSA)에 NGINX Plus Ingress Controller 이미지 사용량을 모니터링하고 배포를 승인하기 위한 AWSMarketplaceMeteringRegisterUsage IAM 정책을 연결합니다. 이 명령은 iamserviceaccount에 연결되는 주석이 포함된 서비스 계정을 자동으로 생성합니다.

# eksctl create iamserviceaccount --name <service-account-name> --namespace nginx-ingress --cluster <eks-cluster-name> --region <eks-cluster-region> --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve

1. RBAC용 YAML 파일에서 name 값을 이전 단계에서 설정한 subjects 필드의 service-account-name과 일치하도록 수정합니다. 이 값은 rbac.yaml의 104번째 줄과 ap-rbac.yaml의 23번째 줄에 있습니다. 필요한 경우 네임스페이스 값(105번째 줄 또는 24번째 줄)도 수정합니다. 단, 위 명령은 기본값인 nginx-ingress를 사용합니다.
2. YAML 파일을 적용합니다(필요에 따라 ap-rbac.yaml로 바꿉니다).

# kubectl apply –f rbac.yaml

1. 로컬 머신에 Docker 클라이언트 소프트웨어를 설치합니다.
2. Subscribe to the NGINX Plus Ingress Controller(Premium Edition) 제품을 Amazon Marketplace for Containers에서 구독합니다.
3. NGINX Plus Ingress Controller Docker 이미지가 호스팅된 Amazon ECR에 Docker 클라이언트를 인증합니다.
4. 다음 값을 편집합니다: nginx-ingress.yaml:
   • kubernetes.io/hostname은 nodeSelector 필드(23행)에 있으며, kubectl get nodes --show-labels 명령으로 확인한 EKS 클러스터의 NGINX Plus Ingress Controller 노드 레이블입니다.
   • serviceAccountName(24행) — iamserviceaccount IRSA의 이름으로, service-account-name으로 2단계에서 지정했습니다.
   • image는 containers 필드(26행)에 있으며, Amazon ECR에 있는 NGINX Plus Ingress Controller Docker 이미지의 위치입니다.
5. YAML 매니페스트를 적용합니다:

# kubectl apply –f nginx-ingress.yaml

백엔드 Pod 배포

백엔드 애플리케이션을 배포하려면 다음 단계를 수행하세요:

1. In backend-deployment.yaml에서 kubernetes.io/hostname의 값을 nodeSelector 필드(15번째 줄)에서 편집하여 kubectl get nodes --show-labels 명령으로 얻은 레이블로 바꿉니다.
2. YAML 매니페스트를 적용합니다:

# kubectl apply –f backend-deployment.yaml

1. 백엔드 애플리케이션을 wrk에서 생성되는 부하를 처리하기에 충분한 3개의 복제본으로 확장합니다:

# kubectl scale deployment web-server-payload --replicas=3

테스트 방법론

Amazon EC2에서 호스팅되는 클라이언트 c5n.9xlarge AMI에서 다음 wrk 명령을 실행하고, 각 테스트 실행 시 NGINX Plus Ingress Controller 인스턴스의 CPU 사용률이 100%에 도달하도록 필요에 따라 값을 조정합니다:

# wrk -t <number-of-threads> -c <number-of-connections> -d 180s http[s]://<address-of-NGINX-Plus-Ingress-Controller>

• The –c 옵션은 생성할 TCP 연결 수를 지정합니다. CPU 사용률이 100%에 도달하도록 필요에 따라 이 옵션을 설정하되, 연결 수는 최대 500개로 제한합니다.
• The –d 옵션은 트래픽을 생성할 시간(각 테스트 실행 시간)을 지정합니다. 이 옵션을 180초(3분)로 설정합니다.
• The –t 옵션은 생성할 스레드 수를 지정합니다. CPU 사용률이 100%에 도달하도록 필요에 따라 이 옵션을 설정하되, 최대 16개 스레드까지 설정할 수 있습니다(테스트 실행 중 클라이언트에서 사용되는 각 CPU당 하나씩).

저희는 2021년 7월 당시 GitHub에서 제공되던 버전의 wrk를 사용했으며, 테스트를 재현할 때는 최신 버전을 사용하는 것이 좋습니다.

테스트를 실행하여 두 가지 성능 지표를 수집합니다:

• 초당 요청 수(RPS) – NGINX Plus Ingress Controller가 초당 처리할 수 있는 요청 수를 일정 기간에 걸쳐 평균한 값입니다. 이 경우 http:// 스킴을 wrk 명령에 사용합니다. NGINX Plus Ingress Controller는 1KB 파일(정적 콘텐츠)에 대한 요청을 수락하고 백엔드 애플리케이션 Pod에 부하를 분산합니다. 이 파일은 작은 CSS 또는 JavaScript 파일이나 매우 작은 이미지와 크기가 비슷합니다.
• 초당 SSL/TLS 트랜잭션 수(TPS) – NGINX Plus Ingress Controller가 초당 설정하고 처리할 수 있는 새로운 HTTPS 연결 수입니다. 이 경우 https:// 스킴을 wrk 명령에 사용합니다. 2048비트 키 크기의 RSA와 순방향 비밀성을 사용하며, SSL 암호화 스위트는 ECDHE-RSA-AES256-GCM-SHA384입니다. 클라이언트는 각각 새로운 연결을 사용하는 일련의 HTTPS 요청을 전송합니다. 클라이언트와 NGINX Plus Ingress Controller는 보안 연결을 설정하기 위해 TLS 핸드셰이크를 수행한 다음, NGINX Plus Ingress Controller가 요청을 구문 분석하고 0KB 응답을 반환합니다. 요청 처리가 완료되면 연결이 종료됩니다.

As noted in Amazon EKS 클러스터 생성에서 설명한 것처럼, 간소화를 위해 모든 테스트 실행에서 c5n.9xlarge 인스턴스에 NGINX Plus Ingress Controller를 실행할 수 있습니다. 각 테스트 실행에서 사용할 수 있는 CPU 수(성능 분석의 표에 명시된 1~36개)를 제어하려면 worker_processes 지시문의 매개변수를 설정합니다.

사용된 소프트웨어

테스트에는 다음 소프트웨어를 사용했습니다:

• The client machine running wrk를 실행하는 클라이언트 머신이 Ingress Controller가 프록시한 트래픽을 생성했습니다. 테스트에는 2021년 7월 당시 GitHub에서 제공되던 wrk 버전을 사용했으며, 테스트를 재현할 때는 최신 버전을 사용하는 것이 좋습니다.
• NGINX Plus Ingress Controller 버전 1.11.0
• 세 대의 머신 모두에서 OpenSSL 1.0.2k–fips가 포함된 Amazon Linux 2 LTS를 실행했습니다.

성능 분석

앞서 언급했듯이 모든 테스트 실행에서 NGINX Plus Ingress Controller를 c5n.9xlarge 인스턴스에서 실행했으며, worker_processes 지시어를 사용하여 사용할 CPU 수를 제어했습니다. 아래 표에는 각 CPU 수를 지원하는 c5n 제품군의 인스턴스 유형과 해당 인스턴스 유형의 월간 TCO가 나와 있습니다.

이 표에는 테스트 방법론에 설명된 테스트에서 NGINX Plus Ingress Controller에 할당된 CPU 수에 따라 달성한 RPS 및 SSL TPS가 나와 있습니다.

CPU 수가 늘어나도 RPS는 선형적으로 증가하지 않으며, 실제로 CPU 수가 많아질수록 향상률은 감소하는 경향이 있습니다. 16코어를 초과하면 향상률이 더욱 낮아집니다. c5n.9xlarge 인스턴스에는 하이퍼스레딩이 활성화되어 있고 18개의 코어와 코어당 2개의 스레드가 탑재되어 있어 총 36개의 CPU를 사용할 수 있기 때문입니다. 하이퍼스레딩은 RPS를 소폭 향상하는 데 그칩니다.

SSL TPS와 CPU 수의 관계 역시 선형적이지는 않지만, CPU를 16개 이상으로 확장하기 전까지는 성능 증가율이 크게 떨어지지 않습니다. 하이퍼스레딩은 TLS 핸드셰이크와 같이 CPU 의존적이면서 병렬화할 수 있는 작업의 성능을 실제로 향상시킵니다. 따라서 CPU를 18개 이상으로 확장해도 SSL TPS 성능은 계속 향상됩니다.

결론

Amazon EKS에서 실행되는 NGINX Plus Ingress Controller의 예상 성능을 파악하는 데 활용할 수 있도록 배포 세부 정보를 제공했습니다. 이 정보를 사용하여 다른 EKS 인스턴스 제품군을 테스트하고, Kubernetes의 프로덕션 워크로드에 필요한 성능 및 확장 요구 사항을 충족하는 경제적인 솔루션을 프로비저닝할 수 있습니다.

HTTP RPS 결과에 따르면 CPU 수를 두 배로 늘릴수록 성능 향상률은 감소하며, 약 300,000 RPS에 수렴합니다. SSL TPS 결과에서는 TLS 핸드셰이크가 CPU 성능에 좌우되므로 하이퍼스레딩(코어당 2개 스레드 사용)을 시작한 이후에도 CPU 수를 두 배로 늘릴 때마다 성능이 거의 선형적으로 향상되는 것으로 나타났습니다.

솔루션 개요를 확인하고, NGINX Plus Ingress Controller의 성능을 직접 테스트해 보세요. 지금 시작하세요!

NGINX Open Source와 함께 NGINX Ingress Controller를 사용해 보려면 소스 코드를 받거나 DockerHub에서 사전 빌드된 컨테이너를 다운로드할 수 있습니다.

작성자 소개

Amir Rawdat솔루션 엔지니어

Amir Rawdat의 다른 블로그 게시물