Amazon EKS에 NGINX Ingress Controller 배포: 우리가 테스트한 방법

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에서 프록시된 요청에 응답합니다. 백엔드 포드 배포를 참조하세요.

Amazon EKS 클러스터 생성

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

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

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

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

# eksctl 클러스터 생성 --인스턴스 유형=c5n.9xlarge --관리 --ssh 액세스=true --ssh 공개 키=/경로/공개 키

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

# ssh -i /path/to/private-key ec2-user@< EKS 노드의 공개 IP 주소 >

NGINX Plus Ingress Controller 배포

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

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

   # eksctl 유틸 iam-oidc-공급자 연관 --지역=< eks-클러스터-지역 > --클러스터=< eks-클러스터-이름 > --승인
   

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

   # eksctl create iamserviceaccount --name < 서비스 계정 이름 > --네임스페이스 nginx-ingress --cluster < eks 클러스터 이름 > --region < eks 클러스터 지역 > --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve
   

3. RBAC용 YAML 파일에서 subjects 필드의 name 값을 편집하여 이전 단계에서 설정한 service-account-name과 일치하도록 합니다. 이 내용은 rbac.yaml 의 104번째 줄과 ap-rbac.yaml 의 23번째 줄에 있습니다. 필요한 경우 네임스페이스 값(105번째 줄 또는 24번째 줄)도 편집합니다. 하지만 위 명령은 기본값인 nginx-ingress를 사용합니다.

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

   # kubectl 적용 –f rbac.yaml
   

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

6. Amazon Marketplace for Containers 에서 NGINX Plus Ingress Controller(프리미엄 에디션) 목록을 구독하세요.

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 Plus Ingress Controller Docker 이미지 위치

9. YAML 매니페스트를 적용합니다.

   # kubectl 적용 –f nginx-ingress.yaml
   

백엔드 Pod 배포

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

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

2. YAML 매니페스트를 적용합니다.

   # kubectl 적용 –f 백엔드 배포.yaml
   

3. wrk 에서 생성된 부하를 처리할 수 있을 만큼 백엔드 애플리케이션을 최대 3개의 복제본으로 확장합니다.

   # kubectl 스케일 배포 웹 서버 페이로드 --replicas=3
   

테스트 방법론

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

# wrk -t < 스레드 수 > -c < 연결 수 > -d 180초 http[s]://< NGINX Plus Ingress 컨트롤러 주소 >

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

우리는 2021년 7월 기준 GitHub에서 제공되는 wrk 버전을 사용했으며, 테스트를 재현할 때는 현재 버전을 사용할 것을 권장합니다.

두 가지 성능 지표를 수집하기 위해 테스트를 실행합니다.

• 초당 요청 수(RPS) – NGINX Plus Ingress Controller가 초당 처리할 수 있는 요청 수로, 고정된 기간 동안 평균화됩니다. 이 경우 wrk 명령에서 http:// 스키마를 사용하세요.

  NGINX Plus Ingress Controller는 1KB 파일(정적 콘텐츠)에 대한 요청을 수락하고 이를 백엔드 애플리케이션 Pod 전체에 걸쳐 부하를 분산합니다. 파일 크기는 작은 CSS나 JavaScript 파일, 혹은 매우 작은 이미지 크기와 비슷합니다.

• 초당 SSL/TLS 트랜잭션(TPS) – NGINX Plus Ingress Controller가 초당 설정하고 제공할 수 있는 새로운 HTTPS 연결 수입니다. 이 경우 wrk 명령에서 https:// 스키마를 사용하세요. 2048비트 키 크기와 완벽한 순방향 비밀성을 갖춘 RSA를 사용합니다. SSL 암호는 ECDHE-RSA-AES256-GCM-SHA384 입니다.

  클라이언트는 일련의 HTTPS 요청을 각각 새로운 연결로 보냅니다. 클라이언트와 NGINX Plus Ingress Controller는 TLS 핸드셰이크를 수행하여 보안 연결을 설정한 다음, NGINX Plus Ingress Controller는 요청을 구문 분석하여 0KB 응답을 반환합니다. 요청이 충족되면 연결이 닫힙니다.

Amazon EKS 클러스터 생성 에서 설명한 대로 간편하게 모든 테스트 실행에서 c5n.9xlarge 인스턴스에서 NGINX Plus Ingress Controller를 실행할 수 있습니다. 각 테스트 실행 중에 사용 가능한 CPU 수( 성능 분석 의 표에 지정된 대로 1~36개)를 제어하려면 매개변수를 worker_processes 지시문으로 설정합니다.

사용된 소프트웨어

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

• wrk를 실행하는 클라이언트 머신은 Ingress Controller가 프록시한 트래픽을 생성했습니다. 우리는 2021년 7월 GitHub에서 사용 가능한 wrk 버전을 사용했으며 테스트를 재현할 때는 현재 버전을 사용하는 것이 좋습니다.
• NGINX Plus Ingress Controller 버전 1.11.0
• Amazon Linux 2 LTS는 OpenSSL 1.0.2k–fips를 사용하여 세 대의 머신 모두에서 실행되었습니다.

성과 분석

위에서 언급했듯이, 우리는 모든 테스트 실행에서 c5n.9xlarge 인스턴스에서 NGINX Plus Ingress Controller를 실행했고, worker_processes 지시문을 사용하여 사용되는 CPU 수를 제어했습니다. 아래 표에서는 각 CPU 개수를 지원하는 c5n 제품군의 인스턴스 유형과 해당 인스턴스 유형에 대한 월별 TCO를 보고합니다.

이 표는 테스트 방법론 에 설명된 테스트를 통해 NGINX Plus Ingress Controller에서 사용 가능한 CPU 수에 따라 달성한 RPS 및 SSL TPS 수를 보고합니다.

RPS는 CPU 수가 많아질수록 선형적으로 증가하지 않으며, 실제로 CPU 수가 많아질수록 개선 비율이 감소하는 경향이 있습니다. c5n.9xlarge 인스턴스는 하이퍼스레딩이 활성화되어 있고 코어 18개와 코어당 스레드 2개가 장착되어 총 CPU 수가 최대 36개까지 늘어나기 때문에 개선 속도는 16개 코어 이상에서는 훨씬 더 떨어집니다. 하이퍼스레딩은 RPS 수를 약간만 개선합니다.

SSL TPS와 CPU 수 간의 관계도 선형적이지는 않지만 16개 CPU를 넘어 확장하기 전까지는 크게 떨어지지 않습니다. 하이퍼스레딩은 TLS 핸드셰이크와 같은 CPU에 집중되고 병렬화 가능한 작업의 성능을 향상시킵니다. 이로 인해 18개 CPU를 넘어 확장하더라도 SSL TPS 성능이 향상됩니다.

결론

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

HTTP RPS에 대한 결과는 CPU 수가 두 배가 되면 성능 향상 비율이 감소하여 약 300,000 RPS로 수렴한다는 것을 보여줍니다. SSL TPS의 결과는 TLS 핸드셰이크가 CPU에 국한되기 때문에 하이퍼스레딩(코어당 두 개의 스레드 사용)을 시작한 경우에도 CPU 개수를 두 배로 늘릴수록 성능이 거의 선형적으로 증가한다는 것을 보여줍니다.

솔루션 간략서를 확인 하고 NGINX Plus Ingress Controller의 성능을 직접 테스트해 보세요. 오늘 시작 하세요!

NGINX 오픈 소스로 NGINX Ingress Controller를 사용해 보려면 소스 코드를 얻거나 DockerHub 에서 미리 빌드된 컨테이너를 다운로드하세요.