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

"완벽한 폭풍이다"라는 표현은 흔할 수 있지만, 클라우드 컴퓨팅 비용이 폭등하는 경우에는 유용한 표현입니다. 여러 요소가 서로 결합되어 완벽한 폭풍이 발생합니다.

1. 작업 부하를 배포하는 사람은 작업 부하에 대한 비용을 지불하는 사람이 아닙니다.
2. 필요에 따라 그리고 프로그래밍 방식으로 인프라를 사용하기 쉽습니다.
3. 쉽게 접근할 수 있는 코드 저장소를 통해 다른 사람이 작성한 기존 코드에서 기능을 "빌려올" 수 있습니다.
4. CI/CD 파이프라인과 SRE 관행은 개발자가 코드를 빠르게 통합하고 배포하는 데 도움이 됩니다.

이 모든 것을 종합해 보면, 개발자는 일반적으로 새로운 앱에서 제공하는 목적에 맞게 간소화되거나 최적화되지 않은 기존 코드 블록을 활용하여 새로운 기능을 빠르게 배포하려는 인센티브를 받습니다. 출시 시간이 가장 중요하기 때문에 최적화는 (아주 먼 옛날에) 뒤로 밀려납니다. 최적화되지 않은 코드로 인해 성능이 저하되는 경우 API 호출만으로 더욱 강력한 인프라를 프로비저닝할 수 있습니다. 문제 해결!

문제를 더욱 복잡하게 만드는 것은 코드를 작성하는 사람과 비용을 지불하는 사람 사이에 사고방식과 조직 구조 측면에서의 분열이 있다는 것입니다. 기업의 클라우드 비용이 증가함에 따라 CFO는 고민에 빠지게 됩니다. 하지만 클라우드 서비스 비용을 증가시킨 개발자들은 신속한 제품 제공에 대한 보상을 받지만, 자신들이 만들어내도록 유도된 하류의 재정 문제에 대해서는 전혀 알지 못한다.

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

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

NGINX 사용자는 클라우드 비용을 줄이는 가장 기본적인 방법, 즉 최소한의 대기 시간을 추가하면서도 번개처럼 빠른 성능을 제공하는 가벼운 도구를 사용하는 방법을 이미 알고 있습니다. 물론, 쿠버네티스 세계에서는 간단하면서도 강력한 도구가 성공적인 배포의 전제 조건입니다. 이 블로그에서는 세 가지 도구를 활용하여 비용을 절감하고 동시에 성과를 개선하는 방법을 설명합니다.

• NGINX Ingress Controller – F5 NGINX Plus 기반의 Ingress 컨트롤러로, 이벤트 핸들러나 구성 재로드 없이 백엔드 엔드포인트의 변경 사항에 동적으로 조정되므로 다른 NGINX 기반 Ingress 컨트롤러 보다 성능이 훨씬 뛰어납니다 .
• Opsani – CI/CD 파이프라인에 CO를 추가할 수 있는 고유한 COaaS(Continuous Optimization as a Service) 솔루션으로, 코드를 신속하게 제공하고 최저 비용으로 최적의 성능을 위해 코드를 최적화할 수 있습니다.
• 프로메테우스 – 모니터링 및 알림을 위한 인기 있는 오픈소스 프로젝트. NGINX Plus Prometheus 모듈을 사용하면 NGINX Plus 기반의 NGINX Ingress Controller가 수백 개의 메트릭을 Prometheus 서버로 내보냅니다.

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

숫자 살펴보기 – 최적화 테스트 결과

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

우리는 이러한 결과가 Kubernetes 커뮤니티가 GitHub kubernetes/ingress-nginx repo에서 유지 관리하는 가장 잘 알려진 Ingress 컨트롤러 중 하나인 NGINX 오픈 소스 기반 Ingress 컨트롤러와 비교했을 때 어떨지 궁금했습니다. ( NGINX 규칙에 따라 이 블로그의 나머지 부분에서는 "커뮤니티 Ingress 컨트롤러"라고 부르겠습니다. NGINX Plus 기반 버전의 NGINX Ingress Controller는 NGINX 엔지니어링 팀에서 GitHub nginxinc/kubernetes-ingress repo에서 유지 관리하고 있으며, NGINX 오픈 소스를 기반으로 하는 자매 버전인 NGINX Ingress Controller도 유지 관리하고 있습니다.

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

• 토폴로지 1 – 표준 프로세스를 사용하여 배포된 커뮤니티 Ingress 컨트롤러. 테스트 중인 애플리케이션에 Envoy 프록시를 인라인으로 추가하여 애플리케이션 포드의 사이드카 컨테이너에서 메트릭을 수집했습니다.

  

• 토폴로지 2 – Helm을 사용하여 배포된 NGINX Plus 기반의 NGINX Ingress Controller. 커뮤니티 Ingress Controller와 동일한 Envoy 배포 및 구성을 통해 메트릭을 수집하여 메트릭 수집이 최적화 성능 프로세스에 영향을 미치지 않도록 했습니다.

  

• 토폴로지 3 – NGINX Plus를 기반으로 하는 NGINX Ingress Controller, Helm을 사용하여 배포됨. 지표는 Prometheus를 사용하여 수집되었습니다.

  

이 표는 테스트 결과를 요약한 것입니다. 보시다시피 NGINX Ingress Controller는 커뮤니티 Ingress 컨트롤러보다 더 나은 비용 절감, CPU 최적화, 메모리 최적화를 달성합니다. 이는 NGINX Ingress Controller의 보다 효율적인 로드 밸런싱 덕분이라고 생각합니다.

P50 응답 시간에 대한 결과는 Prometheus가 Envoy 사이드카 메커니즘에 필요한 추가적인 홉을 없애므로 메트릭을 수집하는 이상적인 방법임을 나타냅니다. Envoy는 Community Ingress 컨트롤러의 P50 응답 시간에는 영향을 미치지 않지만, 실제로 NGINX Ingress 컨트롤러를 사용하면 지연 시간을 4% 더 악화시킵니다. 이와 대조적으로 Prometheus는 NGINX Ingress Controller를 사용하여 P50 응답 시간을 5% 향상시킵니다.

테스트를 어떻게 진행했는지에 대한 자세한 내용은 부록을 참조하세요.

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

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

NGINX가 Ingress 컨트롤러인 환경(현재 많은 애플리케이션에 적용됨)에서 NGINX Plus 기반 NGINX Ingress 컨트롤러로 간단히 전환하면 애플리케이션 기능에 영향을 주지 않고도 보다 효율적인 부하 분산 알고리즘을 제공합니다. 두 번째 이점은 NGINX Ingress Controller에 의해 부하가 분산된 애플리케이션에 대한 메트릭도 사용할 수 있다는 것입니다.

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

Opsani 및 NGINX Ingress Controller 시작하기

NGINX Ingress Controller 와 Opsani 의 무료 평가판을 받아보신 후, Prometheus와 함께 NGINX Ingress Controller와 Opsani에 대한 스크립트와 구성 파일이 있는 GitHub 저장소 로 이동하세요.

부록: 테스트 방법론

필수 조건

• NGINX Plus 기반 NGINX Ingress Controller는 컨테이너로 구축 되었습니다.
• 쿠버네티스가 구성되었으며 레지스트리 액세스 비밀을 사용하여 안전한 개인 Docker 레지스트리 에 액세스할 수 있습니다.
• NGINX Plus 기반 NGINX Ingress Controller는 Helm을 통해 ingress 네임스페이스에 배포됩니다.
• NGINX VirtualServer 리소스는 최적화할 서비스(일반적으로 기본적으로 프런트엔드 서비스)를 가리키도록 구성됩니다. 예를 보려면 GitHut 저장소의 frontend-virtualserver.yaml을 참조하세요.

토폴로지 및 구성

우리는 Opsani 인스턴스를 3개 생성합니다. 토폴로지 1과 2 의 경우 모든 Opsani 계정에서 사용 가능한 표준 Opsani Dev 템플릿을 사용하고 NGINX Ingress Controller로 애플리케이션을 프런트엔드하고 애플리케이션 서비스를 가리킵니다.

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

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

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

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

또한 Servo Pod가 올바른 인스턴스를 찾아 쿼리할 수 있도록 서비스를 구성했습니다. 이 아티팩트는 opsani-manifests-nginx-plus.yaml 에 포함되어 있습니다.

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