Amazon EKS에 NGINX Ingress Controller 배포 및 테스트 방법

이번 포스트에서는 Amazon EKS 에 NGINX Ingress Controller 배포 및 테스트 방법을 설명하고 CPU의 수에 따라 달라지는 성능을 알아보겠습니다.

NGINX에서는 지속적으로 소프트웨어를 최대한 활용할 수 있는 방법을 찾고 있습니다. 당사의 솔루션 요약 및 사이징(Sizing) 가이드는 당사가 제공하는 중요한 리소스 중 하나입니다. 다양한 컴퓨팅 성능에서 기대할 수 있는 성능을 경험적으로 테스트함으로써 이미 보유하고 있는 인프라를 통해 애플리케이션 제공 성능을 극대화하고 성능 및 규모에 대한 정확한 운영 비용을 결정할 수 있도록 지원합니다.

최근 NGINX Ingress Controller 솔루션 개요를 Amazon Elastic Kubernetes Service(EKS)에 대한 크기 조정 지침과 함께 업데이트했습니다. 이 요약 자료에는 Amazon EKS 에서 발생할 수 있는 다양한 인스턴스 유형에서 실행되는 NGINX Ingress Controller로 발생할 수 있는 예상 월별 총 소유 비용(TCO)와 성능에 대해 간략히 설명합니다. 이 포스트에서는 유사한 테스트를 수행하는 데 필요한 모든 정보를 포함하여 이러한 수치를 어떻게 계산했는지 설명합니다.

목차

1. Amazon EKS 토폴로지(Topology)
1-1. Amazon EKS 클러스터 생성
1-2. Amazon EKS에 NGINX Plus Ingress Controller 배포
1-3. Backend Pod 배포
2. 테스트 방법론(Methodology)
2-1. 사용된 소프트웨어
3. 성능 분석
4. 결론

1. Amazon EKS 토폴로지(Topology)

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

Topology for testing NGINX Plus Ingress Controller performance in Amazon Elastic Kubernetes Service (EKS)
  • Admin은 다음 섹션에 지정된 명령을 실행하여 테스트를 수행하는 사용자입니다.
  • Amazon ECR(Elastic Container Registry)은 테스트에 사용된 공식 NGINX Plus Ingress Controller Docker 이미지를 호스팅합니다. NGINX Plus Ingress Controller 배포를 참조하세요.
  • Amazon EC2(Elastic Compute Cloud)는 wrk가 실행되는 c5n.9xlarge 이미지를 호스팅하여 요청을 생성합니다. 테스트 방법론(Methodology)를 참조하십시오.
  • Amazon EKS(Elastic Kubernetes Service)는 NGINX Plus Ingress Controller 및 Backend 애플리케이션용 c5n.9xlarge 이미지를 호스팅합니다. Amazon EKS 클러스터 생성을 참조하십시오.
  • NGINX Plus Ingress Controller는 wrk에 의해 생성된 요청을 Backend 애플리케이션에 Proxy하고 애플리케이션의 응답을 반환합니다. NGINX Plus Ingress Controller 배포를 참조하세요.
  • Backend 애플리케이션은 NGINX에 의해 Proxy된 요청에 응답합니다. Backend Pod 배포를 참조하십시오.

1-1. Amazon EKS 클러스터 생성

EKS 클러스터를 배포하기 전에 다이어그램에서 관리자 아이콘으로 표시되는 로컬 시스템에서 다음 단계를 수행하십시오.

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

EKS 클러스터를 배포하려면 로컬 시스템에서 다음 eksctl 명령을 실행합니다. (–nodes 플래그는 기본적으로 명령이 테스트에 필요한 두 개의 노드를 생성하기 때문에 생략됩니다. 하나는 NGINX Plus Ingress Controller용이고 다른 하나는 기본 Backend 애플리케이션용입니다.)

참고: 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>

1-2. Amazon EKS 에 NGINX Plus Ingress Controller 배포

이제 Amazon EKS에 NGINX Plus Ingress Controller를 배포하는 것이 그 어느 때보다 쉬워졌습니다.

1. EKS 클러스터에 대한 OIDC Identity Provider(IdP)를 생성합니다.

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

2. EKS용 표준 쌍으로 구성된 IAM Role and Service Account(IRSA)인 iamserviceaccount를 생성하고 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

3. RBAC용 YAML 파일에서 subjects 필드의 이름 값을 이전 단계에서 설정한 서비스 계정 이름과 일치하도록 편집합니다. 이것은 rbac.yaml의 104행과 ap-rbac.yaml의 23행에 있습니다. 필요한 경우 Namespace 값도 편집하지만(105행 또는 24행) 위의 명령은 기본 nginx-ingress를 사용합니다.

4. YAML 파일을 적용합니다(적절한 경우 ap-rbac.yaml로 대체).

# kubectl apply –f rbac.yaml

5. 로컬 머신에 Docker 클라이언트 소프트웨어를 설치합니다.

6. Amazon Marketplace for Containers(Amazon Marketplace for Containers)의 NGINX Plus Ingress Controller(Premium Edition) 목록을 선택합니다.

7. NGINX Plus Ingress Controller Docker 이미지를 호스팅하는 Amazon ECR을 사용하여 Docker 클라이언트를 인증합니다.

8. nginx-ingress.yaml에서 다음 값을 편집합니다.

  • nodeSelector 필드의 kubernetes.io/hostname(23행) – kubectl get nodes –show-labels 명령에서 얻은 EKS 클러스터의 NGINX Plus Ingress Controller 노드에 대한 레이블
  • serviceAccountName(24행) — 2단계에서 service-account-name으로 지정된 iamserviceaccount IRSA의 이름입니다.
  • 컨테이너 필드의 이미지(26행) – Amazon ECR에서 NGINX PlusIngress Controller Docker 이미지의 위치

9. YAML Manifest를 적용합니다.

# kubectl apply –f nginx-ingress.yaml

1-3. Backend Pod 배포

다음 단계를 수행하여 Backend 애플리케이션을 배포합니다.

1. backend-deployment.yaml에 kubectl get nodes –show-labels 명령에서 얻은 레이블을 대체하여 nodeSelector 필드(15행)의 kubernetes.io/hostname 값을 편집합니다.

2. YAML Manifest를 적용합니다.

# kubectl apply –f backend-deployment.yaml

3. Backend 애플리케이션을 wrk에서 생성된 로드를 처리하기에 충분한 최대 3개의 Replicas으로 확장합니다.

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

2. 테스트 방법론(Methodology)

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>
  • -c 옵션은 생성할 TCP 연결 수를 지정합니다. 100% CPU 사용량, 최대 500개의 연결을 달성하려면 이 옵션을 설정하십시오.
  • –d 옵션은 트래픽을 생성할 기간(각 테스트 실행 기간)을 지정합니다. 이 옵션을 180초(3분)로 설정합니다.
  • -t 옵션은 작성할 Thread 수를 지정합니다. 100% CPU 사용, 최대 16개 Thread(테스트 실행 중에 클라이언트에서 사용되는 각 CPU에 대해 하나씩)를 달성하려면 이 옵션을 설정하십시오.

2021년 7월 GitHub에서 사용 가능한 wrk 버전을 사용했으며 테스트 재현 시 현재 버전 사용을 권장합니다.

테스트를 실행하여 두 가지 성능 Metrics을 수집합니다.

  • Requests per second (RPS) – NGINX Plus Ingress Controller가 초당 처리할 수 있는 요청 수(일정 기간 동안 평균)입니다. 이 경우 wrk 명령에서 http:// 스키마를 사용합니다.
  • NGINX Plus Ingress Controller는 1KB 파일(정적 콘텐츠)에 대한 요청을 수락하고 Backend 애플리케이션 Pod 간에 Load Balance합니다. 파일은 CSS 또는 JavaScript 파일 또는 매우 작은 이미지 크기입니다.
  • SSL/TLS transactions per second (TPS) – NGINX Plus Ingress Controller가 초당 설정하고 제공할 수 있는 새로운 HTTPS 연결 수입니다. 이 경우 wrk 명령에서 https:// 스키마를 사용합니다. 2048비트 키 크기 및 Perfect Forward Secrecy와 함께 RSA를 사용합니다. SSL 암호는 ECDHE-RSA-AES256-GCM-SHA384입니다.
  • 클라이언트는 각각 새로운 연결에서 일련의 HTTPS 요청을 보냅니다. 클라이언트와 NGINX Plus Ingress Controller가 TLS Handshake를 수행하여 보안 연결을 설정하면 NGINX Plus Ingress Controller가 요청을 구문 분석하고 0KB 응답을 반환합니다. 요청이 충족되면 연결이 닫힙니다.

Amazon EKS 클러스터 생성에서 언급한 것처럼 단순성을 위해 모든 테스트 실행에서 c5n.9xlarge 인스턴스에서 NGINX Plus Ingress Controller를 실행할 수 있습니다. 각 테스트 실행 동안 사용 가능한 CPU 수를 제어하려면(성능 분석의 테이블에 지정된 대로 1에서 36까지) 매개변수를 worker_processes 지시문으로 설정합니다.

2-1. 사용된 소프트웨어

테스트를 위해 다음 소프트웨어를 사용했습니다.

  • wrk를 실행하는 클라이언트 시스템은 Ingress Controller가 Proxy한 트래픽을 생성했습니다. 2021년 7월 GitHub에서 사용 가능한 wrk 버전을 사용했으며 테스트 재현 시 현재 버전 사용을 권장합니다.
  • NGINX Plus Ingress Controller 버전 1.11.0
  • Amazon Linux 2 LTS는 OpenSSL 1.0.2k–fips가 설치된 3개의 시스템에서 모두 실행되었습니다.

3. 성능 분석

위에서 언급했듯이 우리는 모든 테스트 실행을 c5n.9xlarge 인스턴스에서 NGINX Plus Ingress Controller를 사용하여 실행했으며, worker_processes 지시문을 사용하여 사용된 CPU 수를 제어했습니다. 아래 표에는 각 CPU 수를 지원하는 c5n 제품군의 인스턴스 유형과 해당 인스턴스 유형에 대한 월별 TCO(Total Cost Ownership)가 나와 있습니다.

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

RPS는 CPU 수가 많을수록 선형적으로 증가하지 않으며, 실제로 CPU 수가 많을수록 개선 비율이 감소하는 경향이 있습니다. c5n.9xlarge 인스턴스는 하이퍼스레딩(Hyper-Threading)이 지원되고 코어당 18개의 코어와 2개의 Thread가 장착되어 최대 총 36개의 CPU가 가능하지만 16개 코어 이상에서는 개선 속도가 훨씬 더 떨어집니다. 하이퍼스레딩은 RPS 수를 약간만 향상시킵니다.

SSL TPS와 CPU 수 사이의 관계도 선형적이지 않지만 16개 CPU를 초과하여 확장될 때까지 극적으로 떨어지지 않습니다. 하이퍼스레딩은 TLS Handshake와 같은 CPU 바인딩 작업의 성능을 향상시킵니다. 이 때문에 SSL TPS의 성능은 CPU를 18개 이상으로 확장해도 성능이 향상됩니다.

AWS Instance TypeCPUsRPSSSL TPS (RSA)Average Monthly TCO
c5n.large145,0006,700$100
c5n.large280,00012,600$100
c5n.xlarge4135,00023,000$200
c5n.2xlarge8175,00040,000$400
c5n.4xlarge16237,00068,500$795
c5n.9xlarge32290,00088,800$1790
c5n.9xlarge36300,00092,800$1790

4. 결론

Amazon EKS 에서 실행되는 NGINX Plus Ingress Controller의 예상 성능을 확인하는 데 사용할 수 있는 배포 세부 정보를 제공했습니다. 이를 통해 다른 EKS 인스턴스 제품군을 테스트하고 Kubernetes의 Production Workload에 대한 성능 및 확장 요구사항을 충족하는 경제적인 솔루션을 프로비저닝(Provisioning)할 수 있습니다.

HTTP RPS에 대한 결과는 CPU 수를 두 배로 늘려 약 300,000 RPS로 수렴함에 따라 성능 향상 비율이 감소함을 보여줍니다. SSL TPS의 대한 결과는 TLS Handshake가 CPU 바인딩이기 때문에 하이퍼스레딩(코어당 2개의 스레드 사용)을 시작할 때에도 CPU 수를 두 배로 늘리면 성능이 거의 선형적으로 증가함을 보여줍니다.

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

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