GKE에서 비용에 최적화된 Kubernetes 애플리케이션을 실행하기 위한 권장사항

이 문서에서는 Google Kubernetes Engine(GKE) 기능 및 옵션을 설명하고 GKE에서 비용에 최적화된 애플리케이션을 실행하여 Google Cloud에서 제공되는 탄력성 이점을 활용하기 위한 권장사항을 설명합니다. 이 문서에서는 사용자가 Kubernetes, Google Cloud, GKE, 자동 확장에 익숙하다고 가정합니다.

소개

Kubernetes 채택이 늘어남에 따라 많은 기업, Platform-as-a-Service(PaaS), Software-as-a-Service(SaaS) 제공업체가 자사 워크로드에 멀티 테넌트 Kubernetes 클러스터를 사용하고 있습니다. 즉, 여러 팀, 부서, 고객, 환경에 속하는 애플리케이션이 단일 클러스터에서 실행될 수 있습니다. 기업은 Kubernetes에서 제공되는 멀티테넌시를 통해 다수의 소규모 클러스터 대신 소수의 대규모 클러스터를 관리함으로써 적절한 리소스 활용률, 간소화된 관리 제어, 파편화 감소와 같은 이점을 얻을 수 있습니다.

시간이 지남에 따라 이러한 기업들 중 일부에서는 빠르게 증가하는 Kubernetes 클러스터 수로 인해 비용 불균형이 발생합니다. 이는 Kubernetes와 같은 클라우드 기반 솔루션을 채택하는 기존 기업들의 개발자 및 운영자들에게 클라우드 전문성이 부족하기 때문입니다. 이와 같이 클라우드를 사용할 준비가 덜 되어 있으면 자동 확장 중의 불안정(예: 일상 업무 시간 중 트래픽 불안정), 갑작스러운 버스트, 사용량 급증(예: 블랙 프라이데이 및 사이버 먼데이와 같이 이용량이 갑작스럽게 증가하는 대규모 이벤트 또는 TV 광고) 등 애플리케이션에서의 문제 발생으로 이어집니다. 문제 '해결'을 위해 이러한 기업들은 비탄력적 환경에 사용했던 방식 그대로 클러스터를 초과 프로비저닝하는 경향이 있습니다. 초과 프로비저닝은 대부분의 업무 시간 중 애플리케이션이 사용하는 것보다 상당히 높은 CPU 및 메모리 할당으로 이어집니다.

이 문서에서는 GKE에서 비용에 최적화된 Kubernetes 워크로드를 실행하기 위한 권장사항을 제공합니다. 다음 다이어그램은 이러한 접근 방식을 간단히 보여줍니다.

Kubernetes 애플리케이션의 비용 최적화를 위한 접근 방식

비용에 최적화된 애플리케이션의 기본은 팀 간에 비용 절약 문화를 확산시키는 것입니다. 개발 프로세스 시작 단계로 비용 논의를 진행하는 것 이상으로 이 접근 방식을 통해 애플리케이션이 실행되는 환경 즉, GKE 환경을 더 효과적으로 이해할 수 있습니다.

낮은 비용 및 애플리케이션 안정성 목표를 달성하기 위해서는 일부 기능 및 구성(예: 자동 확장, 머신 유형, 리전 선택)을 올바르게 설정하거나 조정해야 합니다. 또 다른 중요한 고려 사항은 워크로드 유형입니다. 추가적인 비용 감소를 위해서는 워크로드 유형 및 애플리케이션의 요구 사항에 따라 서로 다른 구성을 적용해야 하기 때문입니다. 마지막으로 지출 내역을 모니터링하고 개발 주기 초기에 권장사항을 적용할 수 있도록 가드레일을 만들어야 합니다.

다음 표에서는 GKE로 해결하는 데 도움을 얻을 수 있는 도전과제를 요약해서 보여줍니다. 전체 문서를 읽어보면 좋지만 이 표를 통해 포함된 내용을 간략하게 살펴볼 수 있습니다.

도전과제 작업
GKE에서 간편하게 비용을 절약하는 방법 적절한 리전 선택, 약정 사용 할인 등록, E2 머신 유형 사용
GKE 비용 이해 GKE 클러스터 관찰 및 권장사항 보기, GKE 사용량 측정 사용 설정
기존 워크로드에 GKE 탄력성 최대 활용 수평형 포드 자동 확장 처리, 클러스터 자동 확장 처리, 자동 확장 처리 및 초과 프로비저닝 관련 권장사항 이해
가장 효율적인 머신 유형 사용 워크로드에 적합한 머신 유형 선택
클러스터의 많은 유휴 상태 노드 처리 클러스터 자동 확장 처리 권장사항 읽기
일괄 작업의 비용 절약 향상 방법 일괄 워크로드 권장사항 읽기
제공 워크로드의 비용 절약 향상 방법 제공 워크로드 권장사항 읽기
포드 리소스 요청 크기 조정 방법 확인 수직형 포드 자동 확장 처리 사용, 수평형 포드 자동 확장 처리(HPA)와 VPA 혼합 권장사항에 중점
자동 확장 및 유지보수 활동 중 애플리케이션 불안정성 Kubernetes용 클라우드 기반 애플리케이션 준비 및 측정항목 서버 작동 및 모니터링 방법 이해
개발자가 애플리케이션 리소스 사용량을 유념하도록 하는 방법 비용 절약 문화 확산, GKE Enterprise 정책 컨트롤러 사용 고려, 비용 절약 방식 시행을 위해 CI/CD 파이프라인 설계, Kubernetes 리소스 할당량 사용
생태계 비용 추가 감소를 위한 고려사항 소규모 개발 클러스터 검토, 로깅 및 모니터링 전략 검토, 리전 및 다중 영역 클러스터에서 리전 간 이그레스 트래픽 검토

GKE 비용 최적화 기능 및 옵션

비용에 최적화된 Kubernetes 애플리케이션에는 GKE 자동 확장이 중요합니다. GKE에서 비용, 안정성, 확장 처리 성능 간의 균형을 맞추기 위해서는 자동 확장의 작동 방식과 사용 가능한 옵션이 무엇인지 알아야 합니다. 이 섹션에서는 GKE 자동 확장과 제공 워크로드 및 일괄 워크로드를 위한 기타 유용한 비용 최적화 구성에 대해 설명합니다.

GKE 자동 확장 미세 조정

자동 확장은 인프라 업타임을 최소화하고 Google Cloud 고객이 필요한 대상에 대해서만 비용을 지불할 수 있도록 GKE에서 사용되는 전략입니다. 즉, 자동 확장은 1) 수요가 증가하기 전에 워크로드 및 기본 인프라 작동을 시작하고 2) 수요가 감소할 때 이를 종료시켜서 비용을 절약합니다.

이 개념에 대해서는 다음 다이어그램을 참조하세요. Kubernetes에서 워크로드는 포드 내에서 실행되는 컨테이너화된 애플리케이션이며, 노드 집합으로 구성된 기본 인프라는 워크로드를 실행하기에 충분한 컴퓨팅 용량을 제공해야 합니다.

자동 확장은 1) 수요가 증가하기 전에 워크로드 및 기본 인프라 작동을 시작하고 2) 수요가 감소할 때 이를 종료시켜서 비용을 절약합니다.

다음 다이어그램에 표시된 것처럼 이 환경에는 4개의 확장성 차원이 있습니다. 워크로드 및 인프라는 포드 또는 노드를 추가하거나 삭제하는 방식의 수평형 확장과 포드 또는 노드 크기를 늘리거나 줄이는 방식의 수직형 확장이 가능합니다.

비용 최적화 환경의 네 가지 확장성 차원

GKE는 다음과 같은 기능을 사용하여 이러한 자동 확장 시나리오를 지원합니다.

다음 다이어그램은 이러한 시나리오를 보여줍니다.

HPA, VPA, CA, 노드 자동 프로비저닝 시나리오 사용

이 섹션의 남은 부분에서는 GKE 자동 확장 기능을 더 자세히 설명하고 제공 워크로드 및 일괄 워크로드를 위한 기타 유용한 비용 최적화 구성에 대해 설명합니다.

수평형 포드 자동 확장 처리

수평형 포드 자동 확장 처리(HPA)는 부하를 표현하는 측정항목을 기준으로 포드에서 실행되는 애플리케이션을 확장합니다. CPU 사용률 또는 기타 커스텀 측정항목(예: 초당 요청 수)을 구성할 수 있습니다. 간단히 말해 HPA는 포드 복제본을 추가 및 삭제하며, 사용량 급증에 대응하기 위해 빠르게 가동하고 워크로드 불안정성을 방지하기 위해 정상적으로 종료할 수 있는 스테이트리스(Stateless) 작업자에 가장 적합합니다.

HPA 대상 사용률 기준점에 따라 확장을 자동으로 트리거할 시간을 맞춤설정할 수 있습니다.

앞의 이미지에 제시된 것처럼 HPA는 백분율로 표시되는 대상 사용률 기준점이 필요합니다. 이를 통해 자동으로 확장을 트리거할 시간을 맞춤설정할 수 있습니다. 이 예시에서 대상 CPU 사용률은 70%입니다. 즉, 새 복제본이 준비되는 동안 요청을 처리할 수 있는 30%의 CPU 버퍼가 워크로드에 존재합니다. 버퍼가 작으면 너무 초기에 수직 확장되는 것을 방지할 수 있지만 사용량 급증 기간 중 애플리케이션이 과부하될 수 있습니다. 반면에 버퍼가 크면 리소스가 낭비되고 비용이 증가합니다. 정확한 임곗값은 애플리케이션에 따라 달라지며, 사용량 급증 기간 중 2~3분 동안 요청을 충분히 처리할 수 있는 버퍼 크기를 고려해야 합니다. 애플리케이션이 몇 초 내에 가동될 수 있더라도, 클러스터 자동 확장 처리가 클러스터에 새 노드를 추가할 때, 또는 리소스 부족으로 인해 포드가 제한될 때 이러한 추가 시간이 필요합니다.

다음은 애플리케이션에서 HPA를 사용 설정하기 위한 권장사항입니다.

자세한 내용은 수평형 포드 자동 확장 처리 구성을 참조하세요.

수직형 포드 자동 확장 처리

사용량 급증에 빠르게 대응하기 위해 포드 복제본을 추가 및 삭제하는 HPA와 달리, 수직형 포드 자동 확장 처리(VPA)는 시간별로 포드를 관찰하고 포드에 필요한 최적 CPU 및 메모리 리소스를 점진적으로 찾아 냅니다. 안정성과 비용 효율성을 위해서는 올바른 리소스 설정이 중요합니다. 포드 리소스가 너무 작으면 애플리케이션이 제한되거나 메모리 부족 오류로 인해 실패할 수 있습니다. 리소스가 너무 크면 비용이 낭비되고 더 많은 비용이 청구됩니다. VPA는 HPA로 처리되지 않는 스테이트리스(Stateless) 및 스테이트풀(Stateful) 워크로드를 위해 또는 적절한 포드 리소스 요청을 모르는 경우에 사용됩니다.

VPA는 포드가 일정한 속도로 실행 중임을 감지하고 더 큰 리소스로 포드를 다시 만듭니다.

앞의 이미지에 제시된 것처럼 VPA는 포드가 계속해서 한도까지 실행되는지 확인하고 더 많은 리소스로 포드를 다시 만듭니다. 반대로 포드 사용률이 지속적으로 낮은 경우에는 축소가 트리거됩니다.

VPA는 세 가지 모드로 작동합니다.

  • 해제. 권장 모드이기도 한 이 모드에서는 VPA가 포드에 변경사항을 적용하지 않습니다. 권장사항을 계산하고 VPA 객체에서 검사할 수 있습니다.
  • 초기: VPA가 포드 생성 시에만 리소스 요청을 할당하고 이후에 항목을 변경하지 않습니다.
  • 자동: VPA가 포드 수명 주기 동안 CPU 및 메모리 요청을 업데이트합니다. 즉, 포드가 삭제되면 CPU 및 메모리가 조정되고 다시 새 포드가 시작됩니다.

VPA를 사용하려는 경우의 권장사항은 VPA 권장사항을 사용할 수 있도록 해제 모드로 시작하는 것입니다. 권장사항을 사용하기 전에 24시간(이상적으로는 1주일 이상) 동안 실행하는지 확인해야 합니다. 그런 후 확신이 들 때만 초기 또는 자동 모드로 전환을 고려하세요.

애플리케이션에서 초기 또는 자동 모드로 VPA를 사용 설정하기 위해서는 다음 권장사항을 따르세요.

자동 모드 사용을 고려할 때는 다음 방식을 따라야 합니다.

  • 트래픽을 수신하는 동안 애플리케이션을 다시 시작할 수 있어야 합니다.
  • 동시에 중단시킬 수 있는 포드 수를 제어하기 위해 포드 중단 예산(PDB)을 추가합니다.

자세한 내용은 수직형 포드 자동 확장 구성을 참조하세요.

HPA와 VPA 혼합

공식 권장사항은 CPU 또는 메모리에 VPA와 HPA를 혼합하지 않는 것입니다. 하지만 VPA의 권장 모드 또는 HPA의 커스텀 측정항목(예: 초당 요청 수)을 사용할 때는 혼합해서 사용해도 안전합니다. VPA를 HPA와 혼합할 때는 배포에 트래픽이 충분히 수신되는지, 즉 HPA 최소 복제본보다 많게 꾸준히 실행되는지 확인해야 합니다. 이렇게 하면 VPA가 포드의 리소스 수요를 이해할 수 있습니다.

VPA 제한에 대한 자세한 내용은 수직형 포드 자동 확장 제한을 참조하세요.

클러스터 자동 확장 처리

클러스터 자동 확장 처리(CA)는 기본 컴퓨터 인프라 크기를 자동으로 조정합니다. CA는 클러스터에서 실행할 공간이 없는 포드에 노드를 제공하고 사용률이 낮은 노드를 삭제합니다. CA는 인프라 비용에 최적화됩니다. 즉, 클러스터에 노드 유형이 2개 이상 있는 경우 CA는 지정된 수요에 맞는 가장 저렴한 노드 유형을 선택합니다.

HPA 및 VPA와 달리 CA에는 로드 측정항목이 사용되지 않습니다. 대신 예약 시뮬레이션 및 선언된 포드 요청을 기반으로 합니다. 권장사항은 HPA 또는 VPA를 사용할 때마다 CA를 사용 설정하는 것입니다. 이렇게 하면 포드 자동 확장 처리에서 용량이 더 필요하다고 판단될 때마다 그에 따라 기본 인프라가 증대될 수 있습니다.

CA는 갑작스러운 트래픽 급증을 처리하기 위해 컴퓨팅 용량을 자동으로 추가 및 삭제합니다.

다이어그램에 제시된 것처럼 CA는 갑작스러운 트래픽 급증을 처리하기 위해 컴퓨팅 용량을 자동으로 추가 및 삭제하고, 고객들의 사용량이 낮을 때는 비용을 절약할 수 있게 해줍니다. 권장사항은 모든 애플리케이션에 대해 포드 중단 예산(PDB)을 정의하는 것입니다. 이 권장사항은 한 번에 작동을 중지할 수 있는 복제본 수를 PDB가 제어하는 CA 축소 단계에서 특히 중요합니다.

일시적인 장애를 일으킬 경우 자동 확장 처리로 특정 포드를 다시 시작할 수 없으므로 포드가 실행되는 노드를 삭제할 수 없습니다. 예를 들어 시스템 포드(예: metrics-server 및 kube-dns) 및 로컬 스토리지를 사용하는 포드는 다시 시작되지 않습니다. 하지만 시스템 포드에 대해 PDB를 정의하고 자동 확장 처리가 다시 시작해도 안전한 로컬 스토리지를 사용하는 포드에 대해 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" 주석을 설정하면 이러한 동작을 변경할 수 있습니다. 또한 다른 노드의 축소를 차단하지 않도록 별도의 노드 풀에서 다시 시작될 수 없는 장기 포드 실행을 고려하세요. 마지막으로 로그에서 CA 이벤트를 분석하여 특정 확장 활동이 예상한 대로 수행되지 않는 이유를 확인합니다.

워크로드에 의도치 않은 노드 재시작 및 용량 손실로 인한 영향이 크지 않은 경우 에는 선점형 VM을 사용하여 클러스터 또는 노드 풀을 만들어서 비용을 더 절약할 수 있습니다. CA가 예상한 대로 작동하기 위해서는 포드가 정상적으로 작동할 수 있도록 포드 리소스 요청이 충분히 커야 합니다. 리소스 요청이 너무 작으면 노드에 리소스가 충분히 포함되지 않을 수 있고 포드가 비정상적으로 종료되거나 실행 중 문제가 발생할 수 있습니다.

다음은 클러스터에서 클러스터 자동 확장 처리를 사용 설정하기 위한 권장사항을 요약해서 보여줍니다.

  • 워크로드 자동 확장을 위해 HPA 또는 VPA를 사용합니다.
  • 선택한 포드 자동 확장 처리에 설명된 권장사항을 따라야 합니다.
  • 적합한 리소스 요청 및 제한을 설정하여 애플리케이션 크기를 올바르게 조정하거나 VPA를 사용합니다.
  • 애플리케이션에 대해 PDB를 정의합니다.
  • 축소를 차단할 수 있는 시스템 포드에 대해 PDB를 정의합니다. 예를 들면 kube-dns입니다. 클러스터에서 일시적인 중단을 방지하기 위해서는 복제본이 1개만 있는 시스템 포드(예: metrics-server)에 대해 PDB를 설정하지 마세요.
  • 단기 포드 및 별도의 노드 풀로 다시 시작될 수 있는 포드를 실행하여, 장기 포드로 인해 이러한 포드의 축소가 차단되지 않도록 합니다.
  • 클러스터에서 유휴 노드를 구성하여 초과 프로비저닝을 방지합니다. 이를 위해서는 최소 용량(대부분의 경우 야간 용량)을 확인하고 이러한 용량을 지원할 수 있도록 노드 풀에서 최소 노드 수를 설정해야 합니다.
  • 사용량 급증 기간 중 요청 처리를 위해 추가 용량이 필요한 경우에는 자동 확장 처리 및 초과 프로비저닝에서 설명하는 일시중지 포드를 사용합니다.

자세한 내용은 클러스터 자동 확장를 참조하세요.

노드 자동 프로비저닝

노드 자동 프로비저닝(NAP)은 사용자 대신 크기를 관리하는 것 외에도 새 노드 풀을 자동으로 추가하는 클러스터 자동 확장 처리의 메커니즘입니다. 노드 자동 프로비저닝을 사용하지 않으면 GKE는 사용자가 만든 노드 풀 집합에서만 새 노드를 시작합니다. 노드 자동 프로비저닝을 사용하는 경우에는 GKE가 새 노드 풀을 자동으로 만들고 삭제할 수 있습니다.

노드 자동 프로비저닝은 예정된 워크로드에 가장 적합한 노드 풀을 동적으로 만들어서 리소스 낭비를 줄여줍니다. 하지만 새 노드 풀을 만들어야 할 때 자동 확장이 약간 더 지연될 수 있습니다. 워크로드에 의도치 않은 노드 재시작 및 용량 손실로 인한 영향이 크지 않은 경우에는 포드에 선점형 VM 허용값을 구성하여 비용을 더 낮출 수 있습니다.

다음은 노드 자동 프로비저닝 사용 설정을 위한 권장사항입니다.

  • 클러스터 자동 확장 처리에 대한 모든 권장사항을 따릅니다.
  • 애플리케이션이 트래픽을 수신하지 않을 때 NAP가 항목을 크게 변경하지 않도록 최소 및 최대 리소스 크기를 설정합니다.
  • 제공 워크로드를 위해 수평형 포드 자동 확장 처리를 사용할 때는 일부 경우에 NAP로 인해 자동 확장 지연이 길어질 수 있기 때문에 대상 사용률 버퍼를 약간 크게 잡는 것이 좋습니다.

자세한 내용은 노드 자동 프로비저닝 사용 및 지원되지 않는 기능을 참조하세요.

자동 확장 처리 및 초과 프로비저닝

비용을 제어하려면 이전 섹션에 따라 자동 확장 처리를 사용 설정하는 것이 적극 권장됩니다. 모든 경우에 적합한 단일 구성이란 존재하지 않으므로, 자동 확장 처리가 트래픽 증가에 올바르게 대응할 수 있도록 워크로드에 따라 설정을 세밀하게 조정해야 합니다.

하지만 수평형 포드 자동 확장 처리 섹션에서 설명한 것처럼 일부 경우에는 인프라 프로비저닝으로 인해 확장에 시간이 걸릴 수 있습니다. 이러한 시간 차와 가능한 확장 시나리오를 시각적으로 확인하려면 다음 이미지를 참조하세요.

시간 차 및 가능한 확장 시나리오 시각화

클러스터에 새 포드를 배포하기 위한 공간이 충분하면 워크로드 확장 시나리오 중 하나가 트리거됩니다. 즉, 기존 노드가 애플리케이션에 배포된 적이 없으면 포드를 시작하기 전 컨테이너 이미지를 다운로드해야 합니다(시나리오 1). 그러나 동일한 노드가 애플리케이션의 새 포드 복제본을 시작해야 하는 경우 이미지 다운로드가 필요하지 않으므로 총 확장 시간이 줄어듭니다 (시나리오 2).

클러스터에 새 포드를 배포하기 위한 공간이 충분하지 않으면 인프라 및 워크로드 확장 시나리오 중 하나가 트리거됩니다. 즉, 애플리케이션에 접근하기 전에 클러스터 자동 확장 처리가 새 노드를 프로비저닝하고 필요한 소프트웨어를 시작해야 합니다(시나리오 1). 노드 자동 프로비저닝을 사용하는 경우 예정된 워크로드에 따라 새 노드 풀이 필요할 수 있습니다. 이 경우에는 클러스터 자동 확장 처리가 노드 및 노드 풀을 프로비저닝해야 하기 때문에 총 확장 시간이 늘어납니다(시나리오 2).

새 인프라가 필요한 시나리오의 경우, 클러스터를 너무 제한적으로 설정하지 마세요. 즉, 확장 중 예상되는 최대 요청을 처리하는 데 필요한 버퍼만 줄 수 있도록 초과 프로비저닝해야 합니다.

이러한 초과 프로비저닝을 위해서는 기본적으로 두 가지 전략이 있습니다.

  • HPA 사용률 대상을 미세 조정합니다. 다음 수식은 올바른 CPU 대상을 찾기 위한 간단하고 안전한 방법입니다.

    (1 - buff)/(1 + perc)

    • buff는 100% CPU에 도달하는 것일 방지하기 위해 설정할 수 있는 안전 버퍼입니다. 이 변수는 100% CPU에 도달할 경우 요청 처리 지연 시간이 일반적인 것보다 훨씬 크기 때문에 유용합니다.
    • perc는 2~3분 내에 예상되는 트래픽 증가 백분율입니다.

    예를 들어 30% 요청 증가가 예상되고 안전 버퍼를 10%로 정의하여 CPU가 100%에 도달하는 것을 방지하고 싶을 때 사용할 수 있는 수식은 다음과 같습니다.

    (1 - 0.1)/(1 + 0.3) = 0.69

  • 일시중지 포드를 구성합니다. 초기에 노드를 가동하도록 클러스터 자동 확장 처리를 구성할 수 있는 방법은 없습니다. 대신 HPA 사용률 대상을 설정하여 갑작스러운 로드 급증을 처리할 수 있도록 버퍼를 제공할 수 있습니다. 하지만 사용량 증가가 매우 클 것으로 예상되는 경우에는 HPA 사용률 대상을 작게 설정하는 것만으론 충분하지 않거나 비용이 너무 클 수 있습니다.

    이 문제에 대한 다른 솔루션은 일시중지 포드를 사용하는 것입니다. 일시중지 포드는 아무 것도 수행하지 않지만 클러스터에 공간을 예약하는 우선순위가 낮은 배포입니다. 우선순위가 높은 포드가 예약될 때마다 일시중지 포드가 사라지고 우선순위가 높은 포드가 즉시 해당 자리를 차지합니다. 사라진 일시중지 포드는 다시 재예약되고, 클러스터에 공간이 없으면 클러스터 자동 확장 처리가 이를 위해 새 노드를 가동합니다. 일시중지 포드는 노드별로 하나만 설정하는 것이 좋습니다. 예를 들어 CPU 노드를 4개 사용 중이면 일시 중지 포드의 CPU 요청을 약 3,200m으로 구성합니다.

올바른 머신 유형 선택

자동 확장 외에도 GKE에서 비용에 최적화된 Kubernetes 애플리케이션을 실행하는 데 도움이 되는 다른 구성이 존재합니다. 이 섹션에서는 올바른 머신 유형을 선택하는 방법을 설명합니다.

선점형 VM

선점형 VM(PVM)은 최대 24시간 동안 지속되고 가용성을 보장하지 않는 Compute Engine VM 인스턴스입니다. PVM은 표준 Compute Engine VM보다 최대 80%까지 더 저렴하지만 GKE 클러스터에서 사용할 때는 주의가 필요합니다. GKE에서 PVM은 PVM의 임시성과 비보장성에 덜 민감한 일괄 작업이나 내결함성 작업을 실행하는 데 가장 적합합니다. 스테이트풀(Stateful) 및 제공 워크로드의 경우에는 PVM의 제약조건을 해결할 수 있도록 시스템 및 아키텍처가 준비되지 않은 한 PVM을 사용하지 않아야 합니다.

워크로드 유형이 무엇이든, 다음과 같은 제약조건에 주의해야 합니다.

  • 선점형 노드가 의도치 않게 종료될 수 있기 때문에 포드 중단 예산이 지켜지지 않을 수 있습니다.
  • 노드 선점 시 포드 유예 기간이 무시되므로 포드가 정상적으로 종료된다고 보장되지 않습니다.
  • GKE에서 노드가 선점되었고 실행 중인 포드가 더 이상 없다는 것을 감지하는 데 몇 분 정도 걸리므로, 포드를 새 노드로 재예약하는 동안 지연이 발생합니다.

이러한 제약조건을 완화하기 위해서는 Kubernetes에서 Compute Engine 노드 종료 이벤트를 정상적인 포드 종료로 변환하기 위한 어댑터를 제공하는 커뮤니티 노드 종료 이벤트 핸들러 프로젝트(중요: 공식 Google 프로젝트가 아니므로 주의 필요)를 클러스터에서 배포할 수 있습니다. 이 커뮤니티 프로젝트는 포드 중단 예산이 여전히 지켜지지 않을 수 있기 때문에 모든 PVM 제약조건을 안정적으로 해결하지 않습니다. 따라서 포드가 다시 예약되려면 시간이 조금 더 걸릴 수 있습니다.

마지막으로 PVM은 가용성이 보장되지 않습니다. 즉, 일부 리전에서는 쉽게 재고가 부족해질 수 있습니다. 이러한 한계를 극복하기 위해서는 PVM 없이 백업 노드 풀을 설정하는 것이 좋습니다. 클러스터 자동 확장 처리에서는 인프라 비용에 최적화되었기 때문에 PVM이 자주 사용됩니다.

자세한 내용은 GKE에서 선점형 VM 실행 및 비용 최적화 스팟 VM을 사용하여 GKE에서 웹 애플리케이션 실행을 참조하세요.

E2 머신 유형

E2 머신 유형(E2 VM)은 N1 머신 유형에 비해 31% 비용 절약을 제공하는 비용에 최적화된 VM입니다. E2 VM은 웹 서버, 마이크로서비스, 비즈니스에 중요한 애플리케이션, 중소규모 데이터베이스, 개발 환경을 비롯한 다양한 워크로드에 적합합니다.

E2 VM 및 다른 Google Cloud 머신 유형과의 비교에 대한 자세한 내용은 E2 VM의 성능 기반 동적 리소스 관리 및 머신 유형을 참조하세요.

적합한 리전 선택

비용이 제약조건일 때는 GKE 클러스터를 실행하는 위치가 중요합니다. 많은 요인들로 인해 비용은 컴퓨팅 리전별로 달라집니다. 따라서 지연 시간이 고객에게 영향을 주지 않는 최저 비용 옵션으로 워크로드가 실행되는지 확인해야 합니다. 일괄 작업 실행과 같이 한 리전에서 다른 리전으로의 데이터 복사가 필요한 워크로드의 경우에는 이러한 데이터 이동 비용도 고려해야 합니다.

적합한 리전을 선택하는 방법에 대한 자세한 내용은 Compute Engine 리전 선택 권장사항을 참조하세요.

약정 사용 할인 등록

Google Cloud를 몇 년 간 사용할 예정이라면 VM을 크게 할인된 가격으로 사용할 수 있는 약정 사용 할인을 구입하는 것이 가장 좋습니다. 약정 사용 계약을 체결할 경우에는 1년 또는 3년 리소스 사용 약정에 따라 최대 70%까지 크게 할인된 가격으로 컴퓨팅 리소스를 구입할 수 있습니다. 약정할 리소스 양이 확실하지 않으면 야간 중과 같은 최소 컴퓨팅 사용량을 확인하고 이 용량에 대해 약정 사용을 구입하면 됩니다.

여러 머신 유형별 약정 사용 가격에 대한 자세한 내용은 VM 인스턴스 가격 책정을 참조하세요.

소규모 개발 클러스터 검토

비용을 최소화해야 하는 소규모 개발 클러스터의 경우 Autopilot 클러스터를 사용하는 것이 좋습니다. 이 작업 모드의 클러스터를 사용하면 시스템 포드, 운영체제 비용 또는 예약되지 않은 워크로드에 대한 요금이 부과되지 않습니다.

로깅 및 모니터링 전략 검토

애플리케이션 및 인프라에 관측 가능성을 제공하기 위해 Cloud Logging 및 Cloud Monitoring을 사용하는 경우에는 사용량에 대해서만 비용을 지불하는 중입니다. 하지만 인프라 및 애플리케이션 로그가 늘어날수록 해당 로그 보존 기간이 늘어나고, 그로 인한 비용도 증가합니다. 이와 비슷하게, 사용 중인 외부 및 커스텀 측정항목이 많을수록 비용이 높아집니다. Cloud Logging, Cloud Monitoring, 애플리케이션 성능 관리 비용 최적화에 따라 로깅 및 모니터링 전략을 검토하세요.

리전별 및 다중 영역별 클러스터에서 리전 간 이그레스 트래픽 검토

사용 가능한 GKE 클러스터 유형은 단일 영역, 다중 영역, 리전별입니다. 영역 간 노드의 고가용성으로 인해 리전별 및 다중 영역별 클러스터는 프로덕션 환경에 적합합니다. 하지만 영역 간 이그레스 트래픽에 따라 비용이 청구됩니다. 프로덕션 환경에서는 영역 간 트래픽 로드를 모니터링하고 API를 향상시켜서 이를 최소화하는 것이 좋습니다. 또한 여러 서비스의 종속 포드를 동일한 노드 또는 동일한 가용성 영역에 공동 배치하여 비용을 최소화하고 이들 간 네트워크 지연 시간을 최소화할 수 있도록 포드간 어피니티 및 안티어피니티 구성을 사용하는 것이 좋습니다. 이 트래픽을 모니터링하기 위해서는 GKE 사용 측정 및 해당 네트워크 이그레스 에이전트(기본적으로 사용 중지됨)를 사용 설정하는 것이 좋습니다.

비프로덕션 환경의 경우에는 비용 절약을 위해 단일 영역 클러스터를 배포하는 것이 좋습니다.

워크로드 유형에 맞게 환경 준비

비용 및 가용성 요구사항이 기업마다 다르긴 해도, 워크로드는 사용량 급증을 가능한 신속하게 대처해야 하는 제공 워크로드와 일반적으로 작업이 최종적으로 수행되었는지 여부가 중요한 일괄 워크로드로 나눌 수 있습니다. 제공 워크로드는 낮은 확장 지연 시간이 필요하지만 일괄 워크로드는 지연 시간으로 인한 영향이 크지 않습니다. 이러한 워크로드 유형의 서로 다른 기대 수준에 따라 비용 절약 방법을 보다 유연하게 선택할 수 있습니다.

일괄 워크로드

일괄 워크로드는 최종적인 작업 수행 여부가 중요하며 작업 시작 시 발생하는 지연 시간으로 인한 영향이 크지 않기 때문에 GKE에서 비용을 절약하는 데 유리합니다. 따라서 클러스터 자동 확장 처리가 작업이 예약된 시간에만 새 노드를 가동하고 작업이 완료되는 즉시 이를 없앨 수 있습니다.

첫 번째 권장 방법은 라벨 및 선택기를 사용하고 taints 및 허용값을 사용해서 일괄 워크로드를 여러 노드 풀로 구분하는 것입니다. 이렇게 하는 이유는 다음과 같습니다.

  • 포드를 다시 시작할 필요가 없으면 클러스터 자동 확장 처리가 빈 노드를 빠르게 삭제할 수 있습니다. 일괄 작업이 완료되면 워크로드가 지금은 비워진 전용 노드에서 실행되는 경우, 클러스터가 축소 프로세스를 더 빠르게 수행할 수 있습니다. 축소 속도를 더욱 개선하려면 CA의 최적화 사용량 프로필을 구성하는 것이 좋습니다.
  • 일부 포드는 다시 시작할 수 없으므로 노드의 축소가 영구적으로 차단됩니다. 시스템 포드가 포함된 이러한 포드는 축소에 영향을 주지 않도록 다른 노드 풀에서 실행되어야 합니다.

두 번째 권장 방법은 노드 자동 프로비저닝을 사용하여 일치하는 taint 또는 톨러레이션(toleration)이 포함된 작업 전용 노드 풀을 자동으로 만드는 것입니다. 이렇게 하면 이 모든 노드 풀을 서로 다르게 설정할 필요 없이 여러 다른 워크로드를 분리할 수 있습니다.

선점형 VM의 임시성과 미보장성에 덜 민감한 내결함성 작업을 실행하는 경우에만 선점형 VM을 사용하는 것이 좋습니다.

이러한 방법에 따라 환경을 설정하는 방법에 대한 자세한 내용은 노드 자동 프로비저닝을 사용하여 멀티 테넌트 GKE 클러스터에서 리소스 사용 최적화 튜토리얼을 참조하세요.

제공 워크로드

일괄 워크로드와 달리 제공 워크로드는 사용량 급증에 가능한 한 신속하게 대응해야 합니다. 이러한 갑작스러운 트래픽 증가는 TV 광고, 블랙 프라이데이와 같은 트래픽 급증 이벤트, 속보와 같은 여러 요인들로 인해 발생할 수 있습니다. 이를 처리할 수 있도록 애플리케이션이 준비되어 있어야 합니다.

이러한 사용량 급증을 처리할 때의 문제는 일반적으로 다음과 같은 이유 중 하나와 관련되어 있습니다.

클라우드 기반 Kubernetes 애플리케이션 준비

이 섹션의 권장사항 중 일부는 자체적으로 비용 절약에 도움이 될 수 있습니다. 하지만 이러한 방법 중 대부분이 자동 확장 처리로 애플리케이션을 안정적으로 작동하기 위해 의도된 것이므로, 이를 구현하는 것이 좋습니다.

애플리케이션 용량 이해

애플리케이션 용량을 계획할 때는 애플리케이션이 처리할 수 있는 동시 요청 수, 필요한 CPU 및 메모리, 과부하 시 응답 성능을 알아야 합니다. 대부분의 팀은 이러한 용량에 대해 알지 못하므로 부하 상태에서 애플리케이션의 작동 방식을 테스트하는 것이 좋습니다. 자동 확장을 해제한 상태로 단일 애플리케이션 포드 복제본을 격리시키고, 실제 사용량 부하를 시뮬레이션하여 테스트를 수행합니다. 이렇게 하면 포드별 용량을 이해하는 데 도움이 됩니다. 그런 후 클러스터 자동 확장 처리, 리소스 요청 및 한도, HPA 또는 VPA를 구성하는 것이 좋습니다. 그 다음에는 다시 사용량 급증을 시뮬레이션하기 위해 애플리케이션에 더 심한 스트레스 테스트를 진행합니다.

이상적으로 지연 시간 문제를 없애기 위해서는 Google Cloud에서 애플리케이션이 실행되고 있는 동일한 리전 또는 영역에서 이러한 테스트를 실행해야 합니다. 이러한 테스트를 위해서는 직접 만든 스크립트나 Apache Benchmark, JMeter, Locust와 같은 고급 성능 도구 등 원하는 도구를 사용할 수 있습니다.

테스트 수행 방법에 대한 예시는 Google Kubernetes Engine을 사용하여 부하 분산 테스트를 참조하세요.

애플리케이션이 수직 및 수평으로 확장될 수 있는지 확인

애플리케이션이 확장되고 축소될 수 있는지 확인합니다. 즉, CPU 및 메모리를 추가하거나 포드 복제본을 추가하는 방식으로 트래픽 증가를 처리할 수 있어야 합니다. 이렇게 하면 자동 확장 처리 설정 변경이나 또는 노드 크기 변경 등 애플리케이션에 적합한 방식을 유연하게 실험해볼 수 있습니다. 하지만 일부 애플리케이션에서는 단일 스레드로 구성되거나 고정된 작업자 수 또는 하위 프로세스 수로 제한되어 해당 아키텍처를 완전히 리팩터링하지 않고서는 이러한 실험이 불가능한 경우도 있습니다.

적절한 리소스 요청 및 한도 설정

애플리케이션 용량을 이해하면 컨테이너 리소스에서 구성할 항목을 결정할 수 있습니다. Kubernetes에서 리소스는 주로 CPU 및 메모리(RAM)로 정의됩니다. spec.containers[].resources.requests.<cpu|memory> 요청을 사용하여 애플리케이션을 실행하는 데 필요한 양의 CPU 또는 메모리를 구성하고 spec.containers[].resources.limits.<cpu|memory> 요청을 사용하여 상한값을 구성합니다.

리소스 요청을 올바르게 설정했으면 Kubernetes 스케줄러가 이를 사용하여 포드를 배치할 노드를 결정할 수 있습니다. 그러면 포드가 정상적으로 작동할 수 있는 노드에 배치되므로 안정성이 향상되고 리소스 낭비가 줄어듭니다. 또한 리소스 한도를 정의하면 컴퓨팅 노드에서 제공되는 사용 가능한 기본 인프라가 이러한 애플리케이션에 모두 사용되지 않도록 보장하는 데 도움이 됩니다.

컨테이너 리소스를 설정하기 위한 좋은 방법은 요청 및 한도에 대해 동일한 양의 메모리를 사용하고, 더 크거나 결합되지 않은 CPU 한도를 사용하는 것입니다. 다음 배포 예시를 참조하세요.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wp
  template:
    metadata:
      labels:
        app: wp
    spec:
      containers:
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"

위 패턴을 사용한 이유는 Kubernetes의 리소스 부족 처리 작동 방식에서 찾아볼 수 있습니다. 간단히 말해서 컴퓨터 리소스가 소진되면 노드가 불안정해집니다. 이러한 상황을 방지하기 위해 kubelet은 리소스 부족 포드 순위를 확인하여 종합적인 리소스 부족 상황을 모니터링하고 방지합니다. CPU 경합이 발생하면 포드가 해당 요청으로 축소 제한됩니다. 하지만 메모리는 억제할 수 없는 리소스이기 때문에 메모리가 소진되면 포드를 종료해야 합니다. 포드를 종료해서 결과적으로 환경이 불안정화되는 것을 방지하기 위해서는 요청된 메모리를 메모리 한도로 설정해야 합니다.

또한 권장 모드의 VPA를 사용하여 제공된 애플리케이션에 대한 CPU 및 메모리 사용량을 확인할 수 있습니다. VPA가 애플리케이션 사용량을 기준으로 이러한 권장사항을 제공하기 때문에 실제 트래픽이 사용되는 프로덕션 유사 환경에서는 이를 사용 설정하는 것이 좋습니다. 그러면 VPA 상태에 따라 배포 매니페스트에서 정적으로 지정할 수 있는 권장 리소스 요청 및 한도가 포함된 보고서가 생성됩니다. 애플리케이션에 이미 HPA가 정의된 경우에는 HPA 및 VPA 혼합을 참조하세요.

컨테이너는 가능한 한 가볍게 유지

컨테이너에서 애플리케이션을 실행할 때는 해당 컨테이너 빌드를 위한 몇 가지 방식을 따르는 것이 중요합니다. Kubernetes에서 컨테이너를 실행할 때는 애플리케이션이 언제든지 시작 및 중지될 수 있기 때문에 이러한 방법이 더욱 중요합니다. 이 섹션에서는 주로 다음 두 가지 방법에 대해 설명합니다.

  • 이미지 크기를 가능한 한 최소화합니다. 클러스터 자동 확장 처리가 클러스터에 새 노드를 프로비저닝할 때마다 해당 노드에서 실행되는 이미지를 노드가 다운로드해야 하기 때문에 이미지를 작게 하는 것이 좋습니다. 이미지가 작을수록 노드가 더 빨리 다운로드할 수 있습니다.

  • 가능한 한 빨리 애플리케이션을 시작합니다. 일부 애플리케이션은 클래스 로드, 캐싱 등의 이유로 시작하는 데 몇 분이 걸릴 수 있습니다. 포드에 필요한 시작 시간이 길면 애플리케이션이 부팅되는 동안 고객 요청을 충족하지 못할 수 있습니다.

시스템을 디자인할 때, 특히 사용량 급증이 예상될 때는 이러한 두 가지 방식을 고려해야 합니다. 이미지를 작게 하고 시작 시간을 빠르게 하면 확장 지연 시간을 줄일 수 있습니다. 따라서 불안정성에 대한 걱정 없이 트래픽 증가를 더 효과적으로 처리할 수 있습니다. 이러한 권장사항은 GKE 자동 확장에서 설명한 자동 확장 권장사항에 더 잘 적용됩니다.

컨테이너 빌드 방법에 대한 자세한 내용은 컨테이너 빌드 권장사항을 참조하세요.

애플리케이션에 포드 중단 예산 추가

포드 중단 예산(PDB)은 자발적 중단으로부터 동시에 중단될 수 있는 포드 수를 제한합니다. 즉, 정의된 중단 예산이 출시, 노드 업그레이드, 모든 자동 확장 활동 중에 적용됩니다. 하지만 하드웨어 오류, 커널 패닉, 실수로 인한 VM 삭제와 같은 비자발적 상황에서는 이러한 예산이 보장될 수 없습니다.

클러스터 자동 확장 처리의 압축 단계 중 PDB가 적용될 때는 모든 애플리케이션에 대해 포드 중단 예산을 정의하는 것이 가장 좋습니다. 이렇게 하면 CA가 클러스터를 축소할 때를 포함하여 언제든 로드를 지원하는 데 필요한 최소 복제본 수를 제어할 수 있습니다.

자세한 내용은 애플리케이션에 중단 예산 지정을 참조하세요.

애플리케이션에 유의미한 준비 및 활성 프로브 설정

유의미한 프로브를 설정하면 애플리케이션이 작동되어 실행 중이고 트래픽을 수신할 준비가 되었을 때만 트래픽이 애플리케이션에 수신되도록 보장할 수 있습니다. GKE는 준비 상태 프로브를 사용하여 부하 분산기에서 포드를 추가하거나 삭제할 시점을 결정합니다. GKE는 활성 프로브를 사용하여 포드를 다시 시작할 시점을 결정합니다.

활성 프로브는 교착 상태가 감지된 경우와 같이 지정된 포드가 작업을 진행할 수 없는 것을 Kubernetes에 알리는 데 유용합니다. 준비 상태 프로브는 예를 들면 시작 시 대용량 캐시 데이터를 로드 중인 상태 등 Kubernetes에 애플리케이션이 트래픽을 수신할 준비가 되지 않았음을 알리는 데 유용합니다.

확장 활동 중 애플리케이션의 올바른 수명 주기를 보장하기 위해서는 다음을 수행하는 것이 중요합니다.

  • 모든 컨테이너의 준비 상태 프로브를 정의합니다.
  • 시작 시 로드를 위해 애플리케이션에 캐시가 사용되는 경우, 준비 상태 프로브는 캐시가 완전히 로드된 다음에만 준비 상태임을 알려야 합니다.
  • 애플리케이션이 서비스 제공을 즉시 시작할 수 있는 경우, 적정 기본 프로브 구현은 200 상태 코드를 반환하는 HTTP 엔드포인트와 같이 가능한 한 간단하게 설정될 수 있습니다.
  • 연결 풀에 사용 가능한 리소스가 있는지 확인하는 것과 같은 고급 프로브 구현이 있으면 더 간단한 구현과 비교했을 때 오류율이 증가하지 않는지 확인해야 합니다.
  • 프로브 논리가 다른 서비스에 액세스하도록 만들지 마세요. 이러한 서비스가 즉시 반응하지 못할 경우 포드 수명 주기가 손상될 수 있습니다.

자세한 내용은 활성, 준비 상태, 시작 프로브 구성을 참조하세요.

Kubernetes 예상값에 따라 애플리케이션이 종료되는지 확인

자동 확장 처리는 새 포드 및 노드를 가동하고 사용량 급증이 끝났을 때 이를 삭제하여 사용량 급증에 대처할 수 있게 해줍니다. 즉, 빠른 시작 또는 정상적인 종료를 위해 포드 제공을 준비할 때 오류를 방지하기 위한 것입니다.

Kubernetes가 엔드포인트 및 부하 분산기를 비동기적으로 업데이트하기 때문에 무중단 종료를 보장하기 위해서는 이러한 권장사항을 따르는 것이 중요합니다.

  • SIGTERM 다음에 바로 새 요청을 수락하지 마세요. 애플리케이션이 즉시 종료되지 않아야 하며, 진행 중인 모든 요청을 완료하고, 포드 종료 시작 후 도착하는 새로 추가되는 연결을 계속 리슨해야 합니다. Kubernetes가 모든 kube-proxies 및 부하 분산기를 업데이트할 때까지 잠시 시간이 걸릴 수 있습니다. 이것들이 업데이트되기 전에 애플리케이션이 종료되면 일부 요청에 따라 클라이언트 측에서 오류가 발생할 수 있습니다.
  • 애플리케이션이 이전 방법을 따르지 않을 경우에는 preStop 후크를 사용합니다. 대부분의 프로그램은 요청 수락을 즉시 중지하지 않습니다. 하지만 제3자 코드를 사용 중이거나 자신이 제어할 수 없는 시스템을 관리하는 경우(예: nginx) preStop 후크는 애플리케이션 수정 없이 정상 종료를 트리거하기 위한 좋은 방법입니다. 한 가지 일반적인 전략은 preStop 후크에서 몇 초 간 대기를 실행하여 SIGTERM을 지연시키는 것입니다. 이렇게 하면 Kubernetes가 포드 삭제 프로세스를 완료할 수 있는 여유 시간을 얻을 수 있고 클라이언트 측에서 발생하는 연결 오류를 줄일 수 있습니다.
  • 삭제를 위해 SIGTERM을 처리합니다. 애플리케이션이 프로세스 종료 전 지속해야 하는 인메모리 상태를 포함하거나 이를 삭제해야 하는 경우에는 이를 수행해야 합니다. 프로그래밍 언어에 따라 이 신호를 포착하는 방법이 다르므로, 해당 언어에 따라 적합한 방법을 찾아야 합니다.
  • 애플리케이션 요구에 맞게 terminationGracePeriodSeconds를 구성합니다. 일부 애플리케이션은 종료하는 데 기본 30초 이상이 필요합니다. 이 경우에는 terminationGracePeriodSeconds를 지정해야 합니다. 예를 들어 노드 업그레이드, 출시의 경우 높은 값을 사용하여 시간을 늘릴 수 있습니다. 값이 낮으면 Kubernetes가 포드 종료 프로세스를 완료하는 데 시간이 충분하지 않을 수 있습니다. 어떤 경우든 클러스터 자동 확장 처리에서는 최대 10분만 허용되므로 애플리케이션 종료 기간을 10분 미만으로 설정하는 것이 좋습니다.
  • 애플리케이션에 컨테이너 기반 부하 분산이 사용되는 경우 SIGTERM이 수신되는 즉시 준비 프로브 실패를 시작합니다. 이 작업은 백엔드 포드로 새 요청 전송을 중지하도록 부하 분산기에 직접 신호를 보냅니다. 상태 확인 구성과 엔드포인트 프로그래밍 사이의 경합에 따라 백엔드 포드에 트래픽이 조기에 부족해질 수 있습니다.

자세한 내용은 Kubernetes 권장사항: 정상적으로 종료를 참조하세요.

NodeLocal DNSCache 설정

GKE 관리 DNS는 모든 GKE 클러스터에 배포된 부가 기능인 kube-dns로 구현됩니다. DNS가 부족한 애플리케이션을 실행할 경우에는 클러스터의 노드 및 코어 수를 기준으로 kube-dns 복제본 수를 조정하는 기본 kube-dns-autoscaler 구성이 충분하지 않을 수 있습니다. 이 시나리오에서는 DNS 쿼리가 느려지거나 시간 초과될 수 있습니다. 이 문제를 완화하기 위해 기업들은 흔히 kube-dns-autoscaler ConfigMap을 조정해서 클러스터에 있는 kube-dns 복제본 수를 늘리는 방법을 선택합니다. 이 전략이 예상 대로 작동할 수 있지만, 리소스 사용량이 늘어나고 총 GKE 비용이 늘어납니다.

비용에 최적화되고 보다 확장 가능한 또 다른 방법은 클러스터에 NodeLocal DNSCache를 구성하는 것입니다. NodeLocal DNSCache는 각 클러스터 노드에서 DNS 캐시를 실행하여 DNS 조회 지연 시간을 개선하고, DNS 조회 시간을 보다 일관적으로 만들고, kube-dns에 대한 DNS 쿼리 수를 줄여주는 선택적인 GKE 부가기능입니다.

자세한 내용은 NodeLocal DNSCache 설정을 참조하세요.

인그레스를 통해 컨테이너 기반 부하 분산 사용

컨테이너 기반 부하 분산을 사용하면 부하 분산기가 Kubernetes 포드를 직접 대상으로 지정하고 네트워크 엔드포인트 그룹(NEG)이라는 데이터 모델을 사용하여 포드에 트래픽을 고르게 분산시킬 수 있습니다. 이 방식은 네트워크 성능 및 가시성을 향상시켜 주고, 고급 부하 분산 기능을 사용 설정하며, 서비스 메시를 위한 Google Cloud의 완전 관리형 트래픽 제어 영역인 Traffic Director를 사용할 수 있게 해줍니다.

이러한 이점에 따라 컨테이너 기반 부하 분산이 인그레스를 통한 부하 분산에 권장되는 솔루션입니다. NEG가 GKE 인그레스와 함께 사용되면 인그레스 컨트롤러는 L7 부하 분산기 생성의 모든 측면을 용이하게 해줍니다. 여기에는 가상 IP 주소, 전달 규칙, 상태 확인, 방화벽 규칙 등이 포함됩니다.

클러스터 자동 확장 처리를 사용할 때는 컨테이너 기반 부하 분산이 더 중요합니다. 비NEG 부하 분산기의 경우, 축소되는 동안 클러스터 자동 확장 처리가 노드 인스턴스를 종료하기 전에 부하 분산 프로그래밍 및 연결 드레이닝이 완전히 완료되지 않을 수 있습니다. 그 결과 백엔드 포드가 노드에 있지 않은 경우에도 노드를 통과하는 진행 중인 연결이 중단될 수 있습니다.

컨테이너 기반 부하 분산은 다음 조건이 모두 충족될 때 서비스에 대해 기본적으로 사용 설정됩니다.

  • 이 서비스는 GKE 클러스터 1.17.6-gke.7 이상에서 생성되었습니다.
  • VPC 기반 클러스터를 사용 중입니다.
  • 공유 VPC를 사용 중이 아닙니다.
  • GKE 네트워크 정책을 사용 중이 아닙니다.

자세한 내용은 인그레스 GKE 문서 및 컨테이너 기반 부하 분산을 참조하세요.

지수 백오프로 재시도 사용 고려

Kubernetes에서 실행되는 마이크로서비스 아키텍처에서는 여러 가지 이유로 일시적인 오류가 발생할 수 있습니다.

이러한 문제는 일시적이며 지연 후 다시 서비스를 호출하면 문제가 해결될 수 있습니다. 하지만 대상 서비스에 요청이 과도하게 몰리는 것을 방지하기 위해서는 지수 백오프를 사용하여 이러한 호출을 수행하는 것이 중요합니다.

이러한 재시도 패턴을 활용하기 위해 기존의 많은 라이브러리에서 지수 재시도 논리가 구현됩니다. 선택한 라이브러리를 사용하거나 자신의 고유 코드를 작성할 수 있습니다. Istio 또는 Anthos Service Mesh(ASM)를 사용하는 경우 사용자 대신 재시도를 투명하게 실행하는 프록시 수준의 재시도 메커니즘을 선택할 수 있습니다.

이미 삽입된 정보의 삽입을 방지하는 등 애플리케이션이 서비스 호출 재시도를 지원하도록 계획하는 것이 중요합니다. 일련의 재시도는 최종 사용자의 지연 시간에 영향을 줄 수 있고, 잘못 계획된 경우 시간 초과될 수 있습니다.

환경 모니터링과 비용에 최적화된 구성 및 방법 적용

많은 중소규모 그룹에서 중앙화된 플랫폼 및 인프라팀은 일반적으로 전체 회사를 위해 Kubernetes 클러스터를 생성, 유지보수, 모니터링할 책임을 갖고 있습니다. 리소스 사용량 한도를 적용하고 모든 팀이 회사 정책을 따르도록 관리할 필요가 크다는 것을 나타냅니다. 이 섹션에서는 비용 관련 업무 방식을 모니터링하고 적용하기 위한 옵션들을 살펴봅니다.

GKE 클러스터 관찰 및 권장사항 확인

Kubernetes 클러스터에서 컨테이너, 포드, 서비스, 전체 클러스터의 특성을 조사하여 리소스 사용량을 확인할 수 있습니다. 이 작업은 여러 방법을 통해 수행할 수 있지만, 권장되는 초기 방식은 모니터링 대시보드를 통해 GKE 클러스터를 관찰하는 것입니다. 이렇게 하면 인프라, 워크로드, 서비스에서 사용 중인 클러스터에 대한 시계열 데이터를 얻을 수 있습니다.

좋은 출발지가 될 수 있지만 Google Cloud에서는 다음과 같은 여러 옵션이 제공됩니다.

  • Google Cloud 콘솔의 GKE 클러스터 페이지에서 알림 열을 확인합니다. 클러스터에서 리소스 낭비 수준이 높으면 전체 할당 및 요청 리소스 비교에 대한 힌트가 UI에 제공됩니다.

    GKE 클러스터 목록으로 이동

  • Google Cloud 콘솔의 권장사항 페이지에서 비용 절약 권장사항 카드를 확인합니다.

    권장사항 허브로 이동

자세한 내용은 GKE 클러스터 관찰 및 권장사항 허브 시작하기를 참조하세요.

GKE 사용량 측정 사용 설정

대략적인 비용 명세를 볼 수 있는 보다 유연한 접근 방식은 GKE 사용량 측정을 시도해보세요. GKE 사용량 측정을 사용하면 네임스페이스 및 라벨에 따라 분류된 GKE 클러스터의 사용량 프로필을 볼 수 있습니다. CPU, GPU, TPU, 메모리, 스토리지, 선택적인 네트워크 이그레스와 같이 클러스터의 워크로드에 대한 리소스 요청 및 리소스 소비 관련 정보를 추적합니다.

GKE 사용량 측정을 사용하면 GKE 클러스터의 전체 비용 구조, 가장 많은 리소스를 사용 중인 팀 또는 애플리케이션, 사용량 또는 비용의 급증을 일으킨 환경 또는 구성요소, 낭비가 심한 팀을 이해할 수 있습니다. 리소스 요청을 실제 사용률과 비교하면 워크로드의 프로비저닝 수준이 높거나 낮은지 확인할 수 있습니다.

기본 Looker Studio 템플릿을 활용하거나 한 단계 더 나가서 조직 요구에 따라 대시보드를 맞춤설정할 수 있습니다. GKE 사용량 측정 및 기본 요건에 대한 자세한 내용은 클러스터 리소스 사용량 이해를 참조하세요.

측정항목 서버의 작동 방법과 모니터링 방법 이해

측정 항목 서버는 GKE에서 기본 제공되는 자동 확장 파이프라인에 대한 컨테이너 리소스 측정항목의 소스입니다. 측정항목 서버는 kubelets에서 측정항목을 검색하고 Kubernetes Metrics API를 통해 노출합니다. 그런 후 HPA 및 VPA는 이러한 측정항목을 사용하여 자동 확장을 트리거할 시간을 결정합니다.

GKE 자동 확장 상태의 경우 정상 측정항목 서버가 있어야 합니다. GKE metrics-server 베포에서는 클러스터의 노드 수에 따라 CPU 및 메모리를 추가하거나 삭제하여 측정항목 서버 컨테이너가 수직형으로 증가할 수 있게 해주는 크기 조정 도구 nanny가 설치됩니다. 포드의 인플레이스 업데이트는 아직 Kubernetes에서 지원되지 않기 때문에 nanny가 metrics-server 포드를 다시 시작하여 필요한 새 리소스를 적용해야 합니다.

다시 시작이 빠르게 발생하더라도 조치가 필요하다는 것을 자동 확장 처리가 인식할 때까지 걸리는 시간 총 지연 시간은 metrics-server 크기 조정 후 약간 증가될 수 있습니다. 빠르게 변경되는 클러스터에서 측정항목 서버의 잦은 재시작을 방지하기 위해 GKE 1.15.11-gke.9부터는 nanny에서 크기조정 지연이 지원됩니다.

측정항목 서버를 사용할 때는 다음 권장사항을 따르세요.

  • metrics-server 크기 조정 지연을 지원하는 GKE 버전을 선택합니다. metrics-server 배포 YAML 파일에 metrics-server-nanny 컨테이너의 scale-down-delay 구성이 포함되었는지 여부를 검사하여 확인할 수 있습니다.
  • metrics-server 배포를 모니터링합니다. 측정항목 서버가 작동 중지되었으면 자동 확장이 전혀 작동 중이 아님을 의미합니다. 최우선 모니터링 서비스가 이 배포를 모니터링하도록 해야 합니다.
  • GKE 자동 확장에 설명된 권장사항을 따르세요.

Kubernetes 리소스 할당량 사용

멀티 테넌트 클러스터에서는 일반적으로 서로 다른 팀이 서로 다른 네임스페이스에 배포된 애플리케이션을 관리해야 합니다. 중앙화된 플랫폼 및 인프라 그룹의 경우 한 팀이 필요한 것보다 많은 리소스를 사용하는 것이 문제가 됩니다. 모든 클러스터의 컴퓨팅 리소스를 소진하거나 너무 많은 확장을 트리거하는 것도 비용을 증가시킬 수 있습니다.

이러한 문제를 해결하기 위해서는 리소스 할당량을 사용해야 합니다. 리소스 할당량은 네임스페이스의 객체가 사용하는 리소스의 양을 관리합니다. 할당량은 컴퓨팅(CPU 및 메모리), 스토리지 리소스, 객체 수를 기준으로 설정할 수 있습니다. 리소스 할당량을 통해 모든 테넌트가 자신에게 할당된 클러스터 리소스까지만 사용하도록 제한할 수 있습니다.

자세한 내용은 네임스페이스의 메모리 및 CPU 할당량 구성을 참조하세요.

GKE Enterprise 정책 컨트롤러 사용 고려

GKE Enterprise 정책 컨트롤러(APC)는 클러스터가 보안, 규정, 임의적인 비즈니스 규칙과 관련된 정책을 준수하는지 확인 및 감사하고 정책 준수를 시행하는 Kubernetes 동적 승인 컨트롤러입니다. 정책 컨트롤러는 제약조건을 사용하여 클러스터의 규정 준수를 시행합니다. 예를 들어 클라우드 기반 Kubernetes 애플리케이션 준비 섹션에 설명된 많은 권장사항에 따라 클러스터 제약조건을 설치할 수 있습니다. 이렇게 하면 Kubernetes 방식을 엄격하게 따르지 않는 경우 배포가 거부됩니다. 이러한 규칙을 시행하면 예상치 않은 비용 급증을 방지하고 자동 확장 중 워크로드가 불안정해질 가능성을 줄일 수 있습니다.

고유 규칙을 시행하고 작성하는 방법에 대한 자세한 내용은 제약조건 만들기 및 제약조건 템플릿 작성을 참조하세요. GKE Enterprise 고객이 아닌 경우 APC가 빌드된 오픈소스 소프트웨어인 게이트키퍼를 사용할 수 있습니다.

비용 절약 방식 시행을 위해 CI/CD 파이프라인 설계

GKE Enterprise 정책 컨트롤러를 사용하면 GKE 클러스터에 비준수 소프트웨어가 배포되는 것을 방지할 수 있습니다. 하지만 커밋 전 검사, pull 요청 검사, 전송 워크플로 또는 환경에 필요한 어떤 단계에서든 개발 주기 초기에 이러한 정책 제약조건을 시행하는 것이 좋습니다. 이렇게 하면 잘못된 구성을 신속하게 찾아서 수정하고, 가드레일을 만들어서 주의해야 할 항목을 이해하는 데 도움이 됩니다.

또한 CI/CD 파이프라인에서 kpt 함수를 사용하여 Kubernetes 구성 파일이 GKE Enterprise 정책 컨트롤러로 시행되는 제약조건을 준수하는지 확인하고 리소스 사용률 또는 배포 비용을 예측할 수 있습니다. 이렇게 하면 비용 관련 문제가 감지되었을 때 파이프라인을 중지할 수 있습니다. 또는 복제본 수를 늘리는 구성 등의 다른 배포 승인 프로세스를 만들 수도 있습니다.

자세한 내용은 CI 파이프라인에서 정책 컨트롤러 사용을 참조하고, 전송 플랫폼의 전체 예시는 GKE Enterprise를 사용한 최신 CI/CD를 참조하세요.

비용 절약 문화 확산

많은 조직들이 인프라 복잡성을 숨기기 위해 추상화 및 플랫폼을 만듭니다. 이것은 서비스를 가상 머신에서 Kubernetes로 마이그레이션하는 기업들에서 일반적인 방식입니다. 일부 경우 이러한 기업들은 개발자가 자신의 고유 애플리케이션을 프로덕션에서 구성할 수 있도록 허용합니다. 하지만 개발자에게 Kubernetes 클러스터 사용 경험이 없는 경우도 많습니다.

이 섹션에서 권장되는 방식은 추상화 사용을 완전히 없애야 한다는 것을 의미하지 않습니다. 대신 Google Cloud에서의 지출 비용을 확인하고 인프라에 대한 개발자 및 운영자 교육에 도움이 됩니다. 이를 위해서는 기존 또는 온라인 교육 과정, 토론 그룹, 동료 검토, 페어 프로그래밍, CI/CD, 비용 절약 게임화 등을 사용할 수 있는 학습 인센티브 및 프로그램을 만들 수 있습니다. 예를 들어 Kubernetes 환경에서는 3Gb 이미지 애플리케이션, 누락된 준비 상태 프로브, HPA 구성 오류의 영향을 이해하는 것이 중요합니다.

마지막으로 Google의 DORA 연구조사에 표시된 것처럼 문화적 기능은 조직의 성능을 향상시키고, 재작업을 줄이고, 피로감을 줄이는 등의 효과가 있는 주요 요인에 속합니다. 비용 절약도 다르지 않습니다. 직원에게 자신의 지출 비용을 확인할 수 있게 함으로써 비즈니스 목표 및 제약조건을 더 긴밀하게 따르도록 도와줄 수 있습니다.

권장사항 요약

다음 표에서는 이 문서에 설명된 권장사항을 요약해서 보여줍니다.

주제 작업
GKE 비용 최적화 기능 및 옵션
클라우드 기반 Kubernetes 애플리케이션 준비
환경 모니터링과 비용에 최적화된 구성 및 방법 적용
문화

다음 단계