용량 버퍼를 사용하면 클러스터에서 활성 또는 대기 용량 버퍼의 등급을 사전에 선언하여 Google Kubernetes Engine (GKE) 워크로드의 포드 시작 지연 시간을 줄일 수 있습니다. 예비 용량을 미리 선언하면 비용 효율적인 방식으로 워크로드를 더 빠르게 시작할 수 있습니다.
이 문서에서는 용량 버퍼의 작동 방식을 설명합니다. 용량 버퍼를 사용 설정하고 사용하는 방법은 용량 버퍼 구성을 참조하세요.
용량 버퍼를 사용해야 하는 경우
시작 지연 시간에 민감하고 빠르게 확장해야 하는 애플리케이션에는 용량 버퍼를 사용합니다. 트래픽이 갑자기 증가하면 활성 버퍼가 지연 시간이 짧은 확장을 위해 설계된 사전 프로비저닝된 용량을 제공합니다. 트래픽이 지속적으로 증가하는 경우 대기 버퍼는 사전 프로비저닝보다 저렴한 비용으로 포드 예약을 제공합니다.
용량 버퍼는 다음과 같은 이점을 제공합니다.
- 확장 지연 시간 최소화: 활성 버퍼는 실행 중인 노드를 제공하므로 지연 시간을 최소화하는 데 도움이 됩니다. 대기 버퍼는 빠르게 재개되므로 활성 버퍼에 비해 저렴한 비용으로 새 노드보다 빠르게 용량을 사용할 수 있습니다.
- 비용 효율적인 초과 프로비저닝: 용량 버퍼는 안전망을 유지하는 데 도움이 됩니다. 대규모 워크로드의 경우 이 접근 방식은 클러스터가 증가함에 따라 유휴 용량을 선형적으로 늘릴 수 있는 수평형 포드 자동 확장 처리 (HPA) 사용률 목표를 낮추는 것과 같은 다른 초과 프로비저닝 방법보다 비용 효율적인 경우가 많습니다.
- 워크로드 요구사항 충족: 용량 버퍼 구성을 완전히 제어할 수 있습니다. 커스텀 DaemonSet을 통합하여 이미지를 미리 로드하고, 시작 시간을 조정하고, 필요에 맞게 버퍼 크기를 제어하는 등의 옵션이 있습니다.
AI 에이전트, AI 추론, 할인 이벤트 중 소매 애플리케이션, 플레이어 활동이 최고조에 달하는 동안의 게임 서버와 같이 빠른 수직 확장이 필요한 지연 시간에 민감한 워크로드에는 용량 버퍼를 사용하는 것이 좋습니다.
용량 버퍼 작동 방식
Kubernetes CapacityBuffer 커스텀 리소스를 사용하여 예비 용량 버퍼를 정의하여 용량 버퍼를 구현합니다. GKE 클러스터 자동 확장 처리는 CapacityBuffer 리소스를 모니터링하고 이를 대기 중인 수요로 처리하여 예비 용량을 확보합니다. 클러스터에 버퍼에 정의된 리소스 요청을 충족할 만큼 충분한 용량이 없으면 클러스터 자동 확장 처리가 추가 노드를 프로비저닝합니다.
워크로드가 확장되면 GKE는 다음 우선순위에 따라 사용 가능한 용량에 대기 중인 포드를 예약합니다.
- 활성 버퍼에서 노드 실행
- 아직 정지되지 않은 대기 버퍼에서 실행 중인 노드
- 대기 버퍼의 정지된 노드
- 새로 프로비저닝된 노드
대기 중인 포드를 최대한 빨리 예약하기 위해 GKE는 새 노드를 프로비저닝하기 전에 사용 가능한 버퍼 용량을 사용합니다. 이 우선순위는 커스텀 ComputeClass의 우선순위가 더 높은 규칙이 새 노드를 프로비저닝하는 경우에도 적용됩니다.
버퍼 용량은 scalableRef 필드에서 참조되는 워크로드로 제한되지 않습니다. 노드 선택기, 톨러레이션(toleration), 리소스 요청과 같은 예약 제약조건이 버퍼 노드의 구성과 일치하는 대기 중인 포드는 해당 용량을 요청할 수 있습니다. 특정 워크로드의 용량 버퍼를 예약하려면 워크로드와 용량 버퍼 모두에 일치하는 톨러레이션(toleration)과 노드 선택기(또는 노드 어피니티)를 추가하여 워크로드 분리를 구성합니다.
워크로드가 활성 버퍼의 용량을 소비하면 클러스터 자동 확장 처리는 호환되는 대기 버퍼에서 노드를 재개하거나(있는 경우) 새 노드를 프로비저닝하여 활성 버퍼를 보충합니다. 워크로드 또는 활성 버퍼가 대기 버퍼에서 노드를 사용하면 클러스터 자동 확장 처리가 새 노드를 프로비저닝하고 정지하여 대기 버퍼를 보충합니다. 워크로드가 다시 축소되고 노드가 충분히 활용되지 않으면 클러스터 자동 확장 처리는 축소 안정화 기간이 지난 후 초과 실행 노드를 대기 버퍼로 다시 정지하는 대신 삭제합니다. 대기 버퍼를 보충하기 위해 GKE는 새 노드를 별도로 프로비저닝하고 정지합니다.
용량 버퍼 전략
지연 시간 및 비용 요구사항에 따라 다양한 프로비저닝 전략을 사용하여 용량 버퍼를 구성할 수 있습니다.
활성 버퍼
활성 버퍼는 예약된 용량 내에 맞는 워크로드의 지연 시간이 짧은 확장을 위해 실행 중인 노드를 제공합니다. 노드가 이미 실행 중이므로 확장 이벤트 중에 포드를 요청하는 데 최소한의 지연 시간이 발생합니다.
대기 버퍼
대기 버퍼는 정지된 노드를 제공합니다. 대기 전략은 활성 전략보다 비용 효율적이지만 워크로드를 수락하기 전에 노드를 재개하는 데 약간의 지연이 발생합니다.
비용 및 가격 책정
용량 버퍼는 Standard 노드 풀 및 특정 하드웨어를 선택하는 Autopilot 워크로드에 적용되는 표준 노드 기반 컴퓨팅 비용 외에 추가 비용 없이 제공됩니다. 용량 버퍼는 포드 기반 청구 모델을 지원하지 않습니다.
기본 노드에 대한 청구는 버퍼 유형에 따라 다릅니다.
- 활성 버퍼: GKE가 활성 버퍼 용량으로 제공하기 위해 유지하는 실행 중인 VM에 대해 표준 노드 기반 컴퓨팅 요금이 청구됩니다.
- 대기 버퍼: VM 인스턴스가 정지된 동안에는 컴퓨팅 비용 (CPU 또는 메모리)을 지불하지 않습니다. 소액의 스토리지 요금 (예: VM 부팅 디스크 및 저장된 메모리 상태)과 고정 외부 IP 주소와 같은 관련 리소스 비용이 발생합니다. GKE가 워크로드를 호스팅하기 위해 대기 VM을 재개하면 표준 노드 기반 컴퓨팅 요금이 적용됩니다. 자세한 내용은 일시중지된 인스턴스 가격 책정을 참조하세요.
CapacityBuffer CRD
용량 버퍼를 구성하려면 CapacityBuffer CustomResourceDefinition (CRD)을 만듭니다. 다양한 기준을 충족하도록 용량 버퍼를 구성할 수 있습니다.
- 고정 복제본: 참조된 포드 템플릿의 리소스 요청에 따라 만들 버퍼 포드의 고정된 수를 지정합니다. 이 구성은 알려진 크기의 버퍼를 만드는 가장 간단한 방법입니다.
- 리소스 한도: 버퍼가 예약해야 하는 총 CPU 및 메모리 양을 지정합니다. 컨트롤러는 참조된 포드 템플릿의 리소스 요청을 기반으로 만들 버퍼 포드 수를 계산합니다.
- 비율 기반: 배포, StatefulSet, ReplicaSet, 작업과 같은 확장 하위 리소스를 정의하는 기존 확장 가능 객체의 비율로 버퍼 크기를 정의합니다. 버퍼 크기는 참조 워크로드 확장에 따라 동적으로 조정됩니다. 백분율 기반 용량 버퍼는 Kubernetes 확장 하위 리소스를 구현하는 객체에만 지원됩니다.
이러한 옵션을 결합할 수 있습니다. 예를 들어 GKE가 더 큰 값을 최솟값으로 사용하도록 replicas 및 percentage를 모두 설정하고 limits를 상한값으로 설정할 수 있습니다.
자세한 내용은 CapacityBuffer CRD 참고 문서를 참조하세요.
권장사항
용량 버퍼를 구성할 때 비용 효율성과 응답성을 최적화하려면 다음 권장사항을 따르세요.
- 비용 최적화, 대기 우선 전략 사용: 워크로드가 약 30초의 짧은 수직 확장 지연을 허용할 수 있는 경우 대기 버퍼를 우선시합니다. 이 전략은 활성 VM의 전체 비용을 발생시키지 않고 새 VM의 콜드 노드 부팅을 방지합니다.
- 지연 시간에 민감한 워크로드에 활성 버퍼 사용: 포드 예약 시간이 최대한 짧아야 할 때 노드 재개 시간을 허용할 수 없는 워크로드에 활성 버퍼를 사용합니다.
- 하이브리드 전략을 사용하여 성능과 비용의 균형 맞추기: 작은 활성 버퍼와 큰 대기 버퍼를 결합하여 비용 효율적인 설정을 만듭니다. GKE는 대기 버퍼에서 노드를 재개하여 (약 30초 소요) 활성 버퍼를 다시 채우는 것을 우선시하며, 백그라운드에서 새 노드가 프로비저닝되어 대기 버퍼를 백필합니다. 이 설정은 활성 용량으로 초기 급증을 흡수하고 저렴한 대기 용량을 사용하여 지속적인 성장을 수용합니다.
- 초기 버스트에 맞게 활성 버퍼 크기 조정: 대기 버퍼 노드가 재개되기 전에 발생할 것으로 예상되는 초기 복제본 급증을 처리할 수 있도록 활성 버퍼의 크기를 정의합니다.
- 지속적인 부하에 맞게 대기 버퍼 크기 조정: 예상되는 확장된 부하를 처리하기에 충분한 대기 버퍼를 정의하여 콜드 스타트에서 백그라운드로 버퍼를 다시 채울 수 있도록 합니다. 충분한 크기의 대기 버퍼는 최대 포드 예약 지연 시간을 노드를 재개하는 데 걸리는 시간(약 30초)으로 줄일 수 있습니다. 용량 버퍼가 사용되기 시작하고 다시 채워지면 새 버퍼 노드가 정지되기 전에 활성 상태로 전환됩니다. 이 전략은 장기적인 부하가 발생하는 동안 활성 용량을 늘리는 데 도움이 됩니다.
- 버퍼 시뮬레이터 사용: 다양한 활성 및 대기 버퍼 크기를 실험하여 특정 워크로드에 가장 적합한 결과를 얻습니다. https://github.com/gke-labs/buffers-simulator에서 오픈소스 GKE 버퍼 시뮬레이터를 사용하여 워크로드 확장 동작의 시뮬레이션을 실행하여 버퍼 크기 조정 규칙을 미세 조정하고 성능 목표를 달성합니다.
- 워크로드를 0에서 확장할 때 콜드 스타트 지연 시간 감소: HPA를 사용하여 0으로 축소하고 0에서 확장하는 워크로드 (
minReplicas: 0)를 용량 버퍼와 페어링합니다. 수요가 증가하고 워크로드가 0에서 확장되면 GKE는 새 컴퓨팅 노드가 프로비저닝될 때까지 기다리지 않고 사전 준비된 버퍼 노드에서 포드를 즉시 예약합니다. - Standard 클러스터의
optimize-utilization자동 확장 프로필 고려: 용량 버퍼가 이미 여유 공간을 유지하고 있으므로 수요가 감소한 후 클러스터 자동 확장 처리가 사용률이 낮은 노드를 더 빠르게 축소하도록optimize-utilization자동 확장 프로필(--autoscaling-profile=optimize-utilization)을 구성할 수 있습니다. 또한 이 프로필은 포드를 노드에 더 밀집하게 패킹하므로 사용 설정하기 전에 더 밀집한 빈 패킹이 워크로드 가용성 요구사항에 적합한지 평가하세요.
버퍼 크기 계산
활성 버퍼를 대기 버퍼와 결합하면 트래픽 급증을 흡수하는 데 필요한 버퍼 복제본 수 또는 시뮬레이션된 버퍼 포드 수를 추정할 수 있습니다. 초당 포드 수의 예상 수직 확장 속도, 대기 노드 재개 지연 시간, 콜드 노드 생성 지연 시간을 사용하여 이 추정치를 계산합니다. 이러한 지연 시간은 VM 머신 시리즈 및 노드 구성에 따라 다릅니다. 예를 들어 대기 노드 재개 지연 시간은 일반적으로 30~35초이고 새 노드 생성 지연 시간은 일반적으로 머신 시리즈에 따라 60~120초입니다. 클러스터의 실제 지연 시간을 측정하려면 시작 지연 시간 측정항목 모니터링을 참조하세요.
대기 노드가 재개되는 동안 생성된 포드를 포함하도록 활성 버퍼 사이즈를 계산합니다.
\[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]
새 콜드 노드가 프로비저닝을 완료하는 동안 생성된 나머지 포드를 처리할 수 있도록 대기 버퍼 사이즈를 계산합니다.
\[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]
예를 들어 워크로드가 초당 포드 2개로 수직 확장되고 대기 노드가 재개되는 데 30초가 걸리고 새 콜드 노드가 프로비저닝되는 데 90초가 걸리는 경우:
- 활성 버퍼에는 급증의 처음 30초를 흡수하기 위해 \( 2 \times 30 = 60 \) 복제본이 필요합니다.
- 클러스터 자동 확장 처리가 백그라운드에서 새 콜드 노드를 프로비저닝하여 버퍼를 보충하는 동안 대기 버퍼는 남은 60초를 처리하기 위해 \( (2 \times 90) - 60 = 120 \) 복제본이 필요합니다. 급증이 90초 이상 동일한 속도로 계속되면 보충된 노드가 대기 시간 없이 수신 포드를 처리할 준비가 됩니다.
워크로드 확장 패턴에 대해 이러한 추정치를 테스트하려면 GKE 버퍼 시뮬레이터를 사용하여 시뮬레이션을 실행합니다.
요구사항 및 제한사항
용량 버퍼에는 다음과 같은 요구사항 및 제한사항이 있습니다.
- 용량 버퍼는 활성 버퍼의 경우 버전 1.35.2-gke.1842000 이상, 대기 버퍼의 경우 버전 1.36.0-gke.2253000을 실행하는 GKE 클러스터에서 사용할 수 있습니다.
- 용량 버퍼는 Standard 노드 풀에 노드 기반 결제 모델을 사용하고 특정 하드웨어를 선택하는 Autopilot 노드 풀을 사용하는 워크로드만 지원합니다. 용량 버퍼는 포드 기반 청구 모델을 사용하는 워크로드를 지원하지 않습니다.
- Standard 클러스터에서는 노드 풀 자동 생성을 사용 설정하는 것이 좋습니다. 노드 풀 자동 생성을 사용하면 클러스터 자동 확장 처리가 CapacityBuffer의 리소스 요청에 따라 새 노드 풀을 만들 수 있습니다. 노드 풀 자동 생성을 사용 설정하지 않으면 클러스터 자동 확장 처리는 기존 노드 풀만 수직 확장합니다.
- 활성 및 대기 용량 버퍼는 할당량을 다르게 사용합니다.
- 활성 버퍼에서 노드를 실행하면 vCPU, 메모리, 디스크, IP 주소 Compute Engine 할당량에 반영됩니다.
- 대기 버퍼의 정지된 노드는 정지된 동안 Compute Engine vCPU 또는 메모리 할당량에 반영되지 않습니다. 하지만 정지된 VM의 메모리를 저장하는 데 사용되는
Persistent disk standard (GB)할당량을 포함하여 IP 주소 할당량과 디스크 할당량은 계속 사용됩니다. - Kubernetes에서는 활성 및 정지된 대기 버퍼 단위가 모두 버퍼 포드가 실행 중인 것처럼 네임스페이스의 Kubernetes 리소스 할당량에 반영됩니다.
- CapacityBuffer 구성 종속 항목 (예: PodTemplate)이 커스텀 ComputeClass를 선택하는 경우 종속 항목은 프로비저닝된 노드에서 예약하는 데 필요한 taint 허용, 노드 선택기 또는 런타임 클래스 (예: GKE Sandbox 요구사항)를 정의해야 합니다. 자세한 내용은 커스텀 ComputeClass 문서를 참조하세요.
대기 버퍼에는 다음과 같은 추가 제한사항이 있습니다.
- 노드 풀 자동 생성이 사용 설정된 Standard 클러스터에서 지원됩니다.
- 버전 1.36.0-gke.2853000 이상을 실행하는 Autopilot 클러스터에서 지원됩니다.
- GPU 또는 TPU가 연결된 노드는 지원되지 않습니다.
- 로컬 SSD는 지원되지 않습니다.
- 대기 버퍼는 노드 스토리지에 고객 관리 암호화 키 (CMEK)를 지원하지만 노드의 메모리는 정지 중에 Google-owned and Google-managed encryption keys 를 사용하여 암호화됩니다.
- 컨피덴셜 Google Kubernetes Engine 노드는 지원되지 않습니다.
- 대기 버퍼는 GKE Container-Optimized OS 및 Ubuntu 노드 이미지만 지원합니다. Windows Server 노드는 지원되지 않습니다. 커스텀 노드 운영체제를 사용하는 경우 OS가 Compute Engine 일시정지 및 재개 작업을 지원하는지 확인해야 합니다.
- Compute Engine 일시중지 및 재개 작업과 관련된 제한사항을 숙지해야 합니다.
주요 제한사항은 다음과 같습니다.
- 고객 제공 암호화 키 (CSEK)로 보호되는 디스크가 있는 노드는 지원되지 않습니다.
- 메모리가 208GB를 초과하는 노드는 지원되지 않습니다.
- 베어메탈 인스턴스는 지원되지 않습니다.
- 노드 OS는 ACPI S3 절전 신호를 지원해야 합니다.
- 정지 프로세스 길이는 메모리 크기에 비례합니다.
다음 단계
- 용량 버퍼를 구현하는 방법은 용량 버퍼 구성을 참조하세요.