NGINX, Opsani, Prometheus로 클라우드의 Kubernetes 비용을 70% 절감하는 방법

Amir Sharif

“퍼펙트 스톰”은 흔히 쓰이는 표현이지만, 걷잡을 수 없이 치솟는 클라우드 컴퓨팅 비용을 설명하는 데 매우 적절합니다. 여러 요인이 서로 맞물리며 이러한 퍼펙트 스톰을 만들어냅니다:

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 사용자는 클라우드 비용을 절감하는 가장 기본적인 방법, 즉 지연 시간을 최소화하면서도 매우 빠른 성능을 제공하는 경량 도구를 사용하는 방법에 이미 익숙합니다. 물론 Kubernetes 환경에서는 단순하면서도 강력한 도구가 성공적인 배포를 위한 필수 조건입니다. 이 블로그에서는 다음 세 가지 도구를 활용하여 비용을 절감하는 동시에 성능을 개선하는 방법을 설명합니다:

• NGINX Ingress Controller – F5 NGINX Plus 기반의 Ingress 컨트롤러로, 성능이 월등히 뛰어납니다 이벤트 핸들러나 구성 다시 로드 없이 백엔드 엔드포인트의 변경 사항에 동적으로 대응하므로 다른 NGINX 기반 Ingress 컨트롤러보다 성능이 월등히 뛰어납니다.
• Opsani – CI/CD 파이프라인에 지속적 최적화(CO)를 추가할 수 있도록 지원하는 독보적인 서비스형 지속적 최적화(COaaS) 솔루션으로, 코드를 신속하게 배포하고 가능한 최저 비용으로 최상의 성능을 발휘하도록 최적화할 수 있습니다.
• Prometheus – 모니터링 및 알림을 위한 인기 있는 오픈 소스 프로젝트입니다. NGINX Plus Prometheus 모듈을 사용하면 NGINXnbsp;Plus 기반 NGINX Ingress Controller가 수백 개의 메트릭을 Prometheus 서버로 내보냅니다.

NGINX Plus 기반 NGINX Ingress Controller 버전의 가장 강력한 활용 사례 중 하나는 실시간 모니터링(다음의 Kubernetes 가시성 향상을 통해 NGINX Plus 대시보드)과 과거 데이터(Prometheus를 통해)를 활용할 수 있다는 점입니다. 또한 NGINX Ingress Controller는 워크로드의 프런트엔드 역할을 하면서 요청률, 오류 및 지속 시간(RED) 메트릭을 수집하여 Prometheus를 통해 Opsani에 전달할 수 있습니다. Opsani는 머신 러닝을 사용해 이러한 메트릭을 현재 배포된 인프라와 연관 지어 분석하고, NGINX Ingress Controller, 애플리케이션 또는 전체 기술 스택을 최적화할 수 있는 변경 사항을 권장합니다. Opsani가 NGINX Ingress Controller에 설정된 지연 시간 및 성능 임계값에 대해 알림을 보내도록 구성할 수도 있습니다.

수치로 살펴보기 – 최적화 테스트 결과

Opsani 및 Prometheus와 함께 NGINX Plus 기반 NGINX Ingress Controller를 배포했을 때 기대할 수 있는 결과의 예를 살펴보겠습니다. 스크린샷에서 볼 수 있듯이 Opsani 요약 페이지는 시간 경과에 따른 트래픽 양(초당 요청 수, 즉 RPS)을 보여 주고, 기준 설정과 비교한 최적화 효과를 강조합니다. 이 예에서는 시간당 인스턴스 비용이 70% 절감되고 P50 응답 시간이 5% 개선되었습니다.

이러한 결과가 가장 잘 알려진 Ingress 컨트롤러 중 하나인, Kubernetes 커뮤니티가 GitHub kubernetes/ingress-nginx 리포지토리에서 유지 관리하는 NGINX Open Source 기반 Ingress 컨트롤러와 비교하면 어떨지 궁금했습니다. (기존의 NGINX 명명 규칙에 따라 이 블로그의 나머지 부분에서는 이를 ‘커뮤니티 Ingress 컨트롤러’라고 부르겠습니다. NGINX Plus 기반 버전의 NGINX Ingress Controller는 NGINX 엔지니어링 팀이 GitHub nginxinc/kubernetes-ingress 리포지토리에서 NGINX Open Source 기반의 자매 NGINX Ingress Controller와 함께 유지 관리합니다.)

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

• 토폴로지 1 – 표준 프로세스를 사용하여 배포된 커뮤니티 Ingress 컨트롤러입니다. 표준 프로세스 테스트 대상 애플리케이션의 트래픽 경로에 Envoy 프록시를 추가하고, 애플리케이션 파드의 사이드카 컨테이너로 실행하여 메트릭을 수집했습니다.
  
• 토폴로지 2 – NGINX Plus 기반 NGINX Ingress Controller로, Helm을 사용하여 배포했습니다. 메트릭 수집이 최적화 성능 프로세스에 영향을 미치지 않도록 커뮤니티 Ingress Controller와 동일한 Envoy 배포 및 구성을 사용하여 메트릭을 수집했습니다.
  

• 토폴로지 3 – NGINX Plus 기반의 NGINX Ingress Controller로, 역시 Helm을 사용하여 배포했습니다. 메트릭은 Prometheus를 사용하여 수집했습니다.
  

이 표는 테스트 결과를 요약한 것입니다. 보시다시피 NGINX Ingress Controller는 커뮤니티 Ingress 컨트롤러보다 비용 절감, CPU 최적화 및 메모리 최적화 측면에서 더 우수한 성과를 보입니다. 이는 NGINX Ingress Controller의 부하 분산 효율이 더 높기 때문인 것으로 판단됩니다.

P50 응답 시간 결과에 따르면 Prometheus는 Envoy 사이드카 메커니즘에 필요한 추가 홉을 제거하므로 메트릭을 수집하는 데 가장 적합한 방법입니다. Envoy는 커뮤니티 Ingress 컨트롤러의 P50 응답 시간에는 영향을 미치지 않지만, NGINX Ingress Controller에서는 실제로 지연 시간을 4% 악화시킵니다. 반면 Prometheus는 NGINX Ingress Controller의 P50 응답 시간을 5% 개선합니다.

테스트 수행 방법에 대한 자세한 내용은 부록을 참조하세요.

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

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

NGINX가 Ingress 컨트롤러인 환경(오늘날 많은 애플리케이션이 이에 해당)에서는 NGINX Plus 기반 NGINX Ingress Controller로 간단히 전환하기만 해도 애플리케이션의 작동에는 별다른 영향을 주지 않으면서 더 효율적인 부하 분산 알고리즘을 사용할 수 있습니다. 또 다른 이점은 NGINX Ingress Controller가 부하를 분산하는 애플리케이션의 메트릭도 사용할 수 있게 된다는 것입니다.

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

Opsani 및 NGINX Ingress Controller 시작하기

Get your free trials of NGINX Ingress Controller와(과) Opsani의 무료 평가판을 신청한 다음, GitHub 리포지토리에서 Prometheus와 함께 NGINX Ingress Controller 및 Opsani를 사용하는 데 필요한 스크립트와 구성 파일을 확인하세요.

부록: 테스트 방법론

사전 요구 사항

• NGINX Plus 기반 NGINX Ingress Controller는 컨테이너로 빌드됩니다.
• Kubernetes가 구성되어 있으며, 레지스트리 액세스 보안 비밀을 사용하여 보안이 적용된 비공개 Docker 레지스트리에 액세스할 수 있습니다.
• NGINX Plus 기반 NGINX Ingress Controller는 Helm을 통해 ingress 네임스페이스에 배포됩니다.
• An NGINX VirtualServer 리소스는 최적화할 서비스(일반적으로 기본값은 프런트엔드 서비스)를 가리키도록 구성됩니다. 예시는 GitHut 리포지토리의 frontend-virtualserver.yaml을 참조하세요.

토폴로지 및 구성

Opsani 인스턴스 3개를 생성합니다. 토폴로지 1 및 2에는 모든 Opsani 계정에서 사용할 수 있는 표준 Opsani Dev 템플릿을 사용하고, NGINX Ingress Controller를 애플리케이션의 프런트엔드로 구성하여 애플리케이션 서비스로 연결합니다.

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

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

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

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

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

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

작성자 소개

Amir Sharif

Amir Sharif의 다른 블로그 게시물