NGINX, Opsani 및 Prometheus를 사용하여 클라우드에서 Kubernetes 비용 70% 절감 사례

“완벽한 폭풍”이라는 말은 흔한 표현일 수 있지만, 클라우드 컴퓨팅 비용이 폭주하는 경우에 유용합니다. 이 완벽한 폭풍을 일으키기 위해 몇 가지 요소가 서로 구축됩니다.

  1. 워크로드를 배포하는 사람은 비용을 지불하는 사람이 아닙니다.
  2. On-Demand 방식으로 프로그래밍 방식으로 인프라를 사용하기 쉽습니다.
  3. 쉽게 액세스할 수 있는 코드 리포지토리를 통해 다른 사람이 작성한 기존 코드에서 기능을 빌릴 수 있습니다.
  4. CI/CD 파이프라인 및 SRE 사례는 개발자가 코드를 신속하게 통합하고 배포하는 데 도움이 됩니다.

모든 것을 종합하면 개발자가 일반적으로 새 앱에서 제공하는 목적에 맞게 간소화되거나 최적화되지 않은 기존 코드 블록을 활용하여 새로운 기능을 신속하게 배포하도록 장려되는 상황이 있습니다. 시장 출시 시간이 가장 중요하기 때문에 최적화는 뒷전입니다. 최적화되지 않은 코드가 성능을 저하시키는 경우 API를 호출하기만 하면 더 강력한 인프라를 프로비저닝할 수 있습니다.

문제를 더 복잡하게 만드는 것은 사고 방식과 조직 구조 측면에서 코드를 작성하는 사람들과 비용을 지불하는 사람들 사이의 격차입니다. 엔터프라이즈 클라우드 비용이 증가함에 따라 CFO는 땀을 흘립니다. 그러나 더 높은 클라우드 요금을 유발한 개발자는 자신이 생성하도록 유도된 다운스트림 재정 문제에 대해 무지한 채 빠른 제품 제공에 대한 보상을 받았습니다.

이 문제를 해결하기 위해 NGINX와 Opsani는 NGINX Ingress Controller 구독자에게 기존 배포의 추가 이점을 제공하는 최적화 솔루션을 제공하기 위해 협력했습니다. NGINX Ingress Controller는 Opsani Servo 컨테이너가 KubeNest 워크로드에 배포될 때 최적화된 솔루션이 됩니다. 여기에서 Prometheus를 활용하여 속도, 오류 및 기간(RED) 메트릭을 수집합니다. Opsani는 머신 러닝 기반 자율 최적화 기능을 사용하여 인프라를 지속적으로 최적화하여 더 높은 성능과 더 낮은 비용을 위해 적절한 양의 리소스가 소비되도록 합니다.

목차

1. 클라우드 최적화를 사용하여 비용 절감
2. 수치 살펴보기 – 최적화(Optimization) 테스트 결과
3. Opsani가 NGINX Ingress Controller를 최적화하는 방법
4. Opsani 및 NGINX Ingress Controller 시작하기
5. 부록: 테스트 방법론
  5-1. 전제 조건
  5-2. 토폴로지 및 구성

1. 클라우드 최적화를 사용하여 비용 절감

NGINX 사용자는 클라우드 비용을 줄이는 가장 기본적인 방법에 이미 익숙합니다. 번개처럼 빠른 성능을 제공하면서 대기 시간을 최소화하는 가벼운 도구를 사용하십시오. 물론 Kubernetes의 세계에서는 간단하면서도 강력한 도구가 성공적인 배포의 전제 조건입니다. 이 모범 사례에서는 세 가지 도구를 활용하여 비용을 절감하고 동시에 성능을 향상시키는 방법을 설명합니다.

  • NGINX Plus 기반 NGINX Ingress Controller – 이벤트 처리기 또는 구성 다시 로드 없이 Backend Endpoint의 변경 사항에 동적으로 조정되기 때문에 다른 NGINX 기반 Ingress Controller보다 훨씬 우수한 NGINX Plus 기반 Ingress Controller입니다.
  • Opsani – CI/CD 파이프라인에 CO를 추가할 수 있는 고유한 COaaS(Continuous Optimization as a Service) 솔루션으로 코드를 신속하게 제공하고 가능한 최저 비용으로 최적의 성능을 위해 해당 코드를 최적화할 수 있습니다.
  • Prometheus – 모니터링 및 경고를 위한 인기 있는 오픈소스 프로젝트입니다. NGINX Plus Prometheus 모듈을 통해 NGINX Plus 기반 NGINX Ingress Controller는 수백 개의 메트릭을 Prometheus 서버로 내보냅니다.

NGINX Plus 기반 버전의 NGINX Ingress Controller에 대한 가장 강력한 사용 사례 중 하나는 라이브 모니터링(NGINX Plus 대시보드를 통해) 및 기록 데이터(Prometheus를 통해)를 통해 Kubernetes의 가시성을 개선하는 기능입니다. 또한 NGINX Ingress Controller는 워크로드에 대한 Frontend 역할을 하여 속도, 오류 및 기간(RED) 메트릭을 수집하고 이를 Opsani에 제공할 수 있습니다(Prometheus를 통해). Opsani는 머신 러닝을 사용하여 메트릭을 현재 배포된 인프라와 연관시키고 NGINX Ingress Controller, 앱 또는 기술 스택 전체를 최적화하는 변경 사항을 권장합니다. NGINX Ingress Controller에 대해 설정된 대기 시간 및 성능 임계값에 대해 경고하도록 Opsani를 구성할 수도 있습니다.

2. 수치 살펴보기 – 최적화(Optimization) 테스트 결과

Opsani 및 Prometheus와 함께 NGINX Plus 기반 NGINX Ingress Controller를 배포할 때 기대할 수 있는 결과의 예를 살펴보겠습니다. 스크린샷에 표시된 것처럼 Opsani 요약 페이지는 시간 경과에 따른 트래픽 양(초당 요청 수 또는 RPS)을 보고하고 기준 설정과 비교하여 최적화의 이점을 강조합니다. 여기에서 시간당 인스턴스 비용은 70% 절감 되었고, P50 응답 시간(Response Time) 5%는 더 좋습니다.

우리는 이러한 결과가 가장 잘 알려진 Ingress Controller 중 하나인 GitHub kubernetes/ingress-nginx 리포지토리의 Kubernetes 커뮤니티에서 유지 관리하는 NGINX 오픈소스 기반 Ingress Controller와 어떻게 비교할 수 있는지 궁금했습니다. (설정된 NGINX 규칙에 따라 이 모범사례의 나머지 부분에서 “커뮤니티 Ingress Controller”라고 부를 것입니다. NGINX Ingress Controller의 NGINX Plus 기반 버전은 NGINX 오픈소스를 기반으로 하는 NGINX Ingress Controller와 함께 GitHub nginxinc/kubernetes-ingress 리포지토리의 NGINX 엔지니어링 팀에서 유지 관리합니다.)

우리는 세 가지 토폴로지에서 두 Ingress Controller의 성능을 테스트했습니다.

  • 토폴로지 1 – 표준 프로세스를 사용하여 배포된 Community Ingress Controller. 애플리케이션 파드(Pod)의 사이드카(Sidecar) 컨테이너에서 테스트 중인 애플리케이션과 인라인으로 Envoy 프록시를 추가하여 메트릭을 수집했습니다.
  • 토폴로지 2 – Helm을 사용하여 배포된 NGINX Plus 기반 NGINX Ingress Controller. 메트릭 수집이 최적화 성능 프로세스에 영향을 미치지 않도록 하기 위해 커뮤니티 Ingress Controller와 동일한 Envoy 배포 및 구성으로 메트릭을 수집했습니다.
  • 토폴로지 3 – Helm을 사용하여 배포된 NGINX Plus 기반 NGINX Ingress Controller. 메트릭은 Prometheus를 사용하여 수집되었습니다.

표에는 테스트 결과가 요약되어 있습니다. 보시다시피 NGINX Ingress Controller는 커뮤니티 Ingress Controller보다 더 나은 비용 절감, CPU 최적화 및 메모리 최적화를 달성합니다. 이것은 NGINX Ingress Controller의 보다 효율적인 로드 밸런싱 덕분입니다.

P50 응답 시간에 대한 결과는 Prometheus가 Envoy 사이드카(Sidecar) 메커니즘에 필요한 추가 홉을 제거하기 때문에 메트릭을 수집하는 이상적인 방법임을 나타냅니다. Envoy는 Community Ingress Controller의 P50 응답 시간(Response Time)에 영향을 미치지 않지만 실제로 NGINX Ingress Controller를 사용하면 지연 시간이 4% 악화됩니다. 대조적으로 Prometheus는 NGINX Ingress Controller를 사용하여 P50 응답 시간을 5% 향상시킵니다.

토폴로지비용절감
(%)		P5 응답 시간
(%)		CPU 최적화
(%)		Memory 최적화
(%)
1 – Envoy가 있는
커뮤니티 Ingress Controller		4404444
2 – Envoy가 있는
NGINX Ingress Controller		7046381
3 – Prometheus가 있는
Ingress Controller		70-56381

테스트를 실행한 방법에 대한 정보는 아래 부록을 참조하십시오.

3. Opsani가 NGINX Ingress Controller를 최적화하는 방법

Opsani는 동적 환경에서 부하 분산이 제대로 되지 않는 경우에도 애플리케이션을 최적화할 수 있습니다. 또한 모든 유형의 메트릭 입력을 활용할 수 있지만 네트워크 메트릭을 수집하는 기존 도구에서 입력이 올 때 연결된 서비스의 최적화가 크게 향상됩니다. 이를 위해 간단한 배포 프로세스를 사용하여 Opsani를 NGINX Ingress Controller와 통합합니다.

NGINX가 Ingress Controller인 환경(오늘날 많은 애플리케이션에 적용됨)에서 NGINX Plus 기반 NGINX Ingress Controller를 사용하는 간단한 전환은 애플리케이션 기능에 다른 영향을 미치지 않으면서 보다 효율적인 로드 밸런싱 알고리즘을 제공합니다. 두 번째 이점은 NGINX Ingress Controller에 의해 로드 밸런싱된 애플리케이션에 대한 메트릭(Metric)도 사용할 수 있다는 것입니다.

유일한 추가 요구 사항은 최적화 네임스페이스 아래에 애플리케이션과 함께 단일 Opsani 파드(Pod)를 배포하는 것입니다. NGINX Plus 기반 NGINX Ingress Controller용 Opsani 템플릿은 최적화에 필요한 애플리케이션별 메트릭(Metric)을 캡처하기 위해 Ingress 서비스의 메트릭(Metric) Endpoint를 가리킵니다. 3~4개의 피크 기간의 메트릭(Metric)을 처리하여 Opsani 엔진은 단 몇 시간 내에 최적의 최적화 수준에 도달합니다. 현재까지 우리는 최대 부하 최적화를 30%에서 70%로 달성했습니다.

4. Opsani 및 NGINX Ingress Controller 시작하기

NGINX Ingress Controller 및 Opsani 무료 평가판을 요청한 다음 GitHub 리포지토리에서 NGINX Ingress Controller 및 Opsani with Prometheus용 스크립트 및 구성 파일을 확인하십시오.

5. 부록: 테스트 방법론

5-1. 전제 조건

  • NGINX Plus 기반 NGINX Ingress Controller는 컨테이너로 구축됩니다.
  • NGINX Plus 기반 NGINX Ingress Controller는 Helm을 통해 ingress 네임스페이스에 배포됩니다.
  • NGINX VirtualServer 리소스는 최적화할 서비스(일반적으로 기본적으로 Endpoint 서비스)를 가리키도록 구성됩니다. 예를 보려면 GitHut 리포지토리에서 frontend-virtualserver.yaml을 참조하세요.

5-2. 토폴로지 및 구성

3개의 Opsani 인스턴스를 생성합니다. 토폴로지 1 및 2의 경우 모든 Opsani 계정에 사용할 수 있는 표준 Opsani Dev 템플릿을 사용하고 NGINX Ingress Controller로 애플리케이션을 Frontend하고 애플리케이션 서비스를 가리킵니다.

토폴로지 3의 경우 동일한 기본 템플릿을 사용하고 GitHub 리포지토리의 opsani-manifests-nginx-plus.yaml에 정의된 ConfigMap으로 서보 구성을 수정합니다. 표준 템플릿과 마찬가지로 ConfigMap에서 다음 변수를 적절한 값으로 대체합니다.

  • {{ NAMESPACE }} – 대상 리소스 네임스페이스
  • {{ DEPLOYMENT }} – 대상 배포
  • {{ CONTAINER }} – 대상 애플리케이션 컨테이너 이름

또한 애플리케이션 배포 시 노출되는 문서에 따라 OPSANI_ACCOUNT_NAME, OPSANI_APPLICATION_NAME, OPSANI_TOKEN을 설정합니다.

Opsani Dev용 기본 ServoX에는 Prometheus 인스턴스가 포함되어 있지만 대신 NGINX Ingress Controller와 동일한 네임스페이스에 Prometheus 인스턴스를 배포하여 ClusterRole 구성의 필요성을 줄입니다.

또한 Servo 파드(Pod)가 올바른 인스턴스를 찾고 쿼리(Query)할 수 있도록 서비스를 구성합니다. 이 아티팩트는 opsani-manifests-nginx-plus.yaml에서 다룹니다.

Bank of Anthos가 샘플 웹 애플리케이션으로 실행되고 Ingress가 확인되면 Ingress Prometheus 인스턴스를 시작합니다. 마지막으로 opsani-manifests-nginx-plus.yaml 파일을 적용하여 Opsani 최적화를 시작할 수 있습니다.