용량 버퍼를 사용하면 클러스터에서 활성 또는 대기 용량 버퍼의 티어를 사전 선언하여 Google Kubernetes Engine (GKE) 워크로드의 포드 시작 지연 시간을 줄일 수 있습니다. 사전 예비 용량을 선언하면 비용 효율적인 방식으로 워크로드를 더 빠르게 시작할 수 있습니다.
이 문서에서는 용량 버퍼의 작동 방식을 설명합니다. 용량 버퍼를 사용 설정하고 사용하는 방법을 알아보려면 용량 버퍼 구성을 참고하세요.
용량 버퍼를 사용해야 하는 경우
시작 지연 시간에 민감하고 빠르게 확장해야 하는 애플리케이션에는 용량 버퍼를 사용합니다. 트래픽이 갑자기 증가하는 경우 활성 버퍼는 지연 시간 감소를 위해 설계된 사전 프로비저닝된 용량을 제공합니다. 트래픽이 지속적으로 증가하는 경우 대기 버퍼를 사용하면 사전 프로비저닝보다 저렴한 비용으로 포드를 예약할 수 있습니다.
용량 버퍼는 다음과 같은 이점을 제공합니다.
- 확장 지연 시간 최소화: 활성 버퍼는 실행 중인 노드를 제공하여 지연 시간을 최소화합니다. 대기 버퍼는 빠르게 재개되므로 활성 버퍼에 비해 비용이 저렴하면서도 새 노드보다 빠른 용량 가용성을 제공합니다.
- 비용 효율적인 오버프로비저닝: 용량 버퍼를 사용하면 안전망을 유지할 수 있습니다. 대규모 워크로드의 경우 이 접근 방식은 클러스터가 커짐에 따라 유휴 용량이 선형적으로 증가할 수 있는 다른 오버프로비저닝 방법 (예: HorizontalPodAutoscaler (HPA) 사용률 타겟 낮추기)보다 비용 효율적인 경우가 많습니다.
- 워크로드 요구사항 충족: 용량 버퍼 구성을 완전히 제어할 수 있습니다. 이미지를 미리 로드하고, 시작 시간을 조정하고, 필요에 맞게 버퍼 크기를 제어하는 맞춤 데몬 세트를 통합하는 등의 옵션이 있습니다.
AI 에이전트, AI 추론, 할인 이벤트 중의 소매 애플리케이션, 플레이어 활동이 가장 많은 시간대의 게임 서버와 같이 빠른 스케일업이 필요한 지연 시간에 민감한 워크로드에는 용량 버퍼를 사용하는 것이 좋습니다.
용량 버퍼 작동 방식
Kubernetes CapacityBuffer 커스텀 리소스를 사용하여 예비 용량 버퍼를 정의하여 용량 버퍼를 구현합니다. GKE 클러스터 자동 확장 처리기는 CapacityBuffer 리소스를 모니터링하고 이를 대기 중인 수요로 취급하여 예비 용량을 사용할 수 있도록 합니다. 클러스터에 버퍼에 정의된 리소스 요청을 충족할 충분한 용량이 없으면 클러스터 자동 확장 처리에서 추가 노드를 프로비저닝합니다.
우선순위가 높은 워크로드가 확장되면 GKE는 버퍼의 사용 가능한 용량에 워크로드를 즉시 예약합니다. 이 즉시 예약은 버퍼에 예약된 복제본 수 또는 리소스 양에 적용되어 노드 프로비저닝과 관련된 일반적인 지연을 방지합니다. 워크로드가 버퍼 단위를 사용하는 경우 클러스터 자동 확장 처리는 버퍼를 리필하기 위해 새 노드를 프로비저닝합니다.
용량 버퍼 전략
지연 시간 및 비용 요구사항에 따라 다양한 프로비저닝 전략을 사용하여 용량 버퍼를 구성할 수 있습니다.
활성 버퍼
활성 버퍼는 예약된 용량 내에 맞는 워크로드의 지연 시간이 짧은 확장을 위해 실행 중인 노드를 제공합니다. 노드가 이미 실행 중이므로 확장 이벤트 중에 포드를 요청할 때 지연 시간이 최소화됩니다.
대기 버퍼
대기 버퍼는 일시중지된 노드를 제공합니다. 대기 전략은 활성 전략보다 비용 효율적이지만 워크로드를 수락하기 전에 노드를 재개하는 데 약간의 지연이 발생합니다.
비용 및 가격 책정
용량 버퍼의 청구는 버퍼 유형에 따라 다릅니다.
- 활성 버퍼: 활성 버퍼 용량으로 사용하기 위해 GKE에서 유지관리하는 실행 중인 VM에 대해 표준 GKE 컴퓨팅 요금이 청구됩니다. Autopilot에서는 실행 중인 포드에 표준 포드 기반 요금이 적용됩니다.
- 대기 버퍼: VM 인스턴스가 일시 중지된 동안에는 컴퓨팅 비용 (CPU 또는 메모리)이 청구되지 않습니다. 스토리지 요금 (예: VM 부팅 디스크)과 고정 외부 IP 주소와 같은 연결된 리소스 비용이 발생합니다. GKE가 워크로드를 호스팅하기 위해 대기 VM을 재개하면 표준 컴퓨팅 또는 포드 기반 청구 요금이 적용됩니다.
CapacityBuffer CRD
용량 버퍼를 구성하려면 CapacityBuffer CustomResourceDefinition (CRD)을 만듭니다. 다양한 기준을 충족하도록 용량 버퍼를 구성할 수 있습니다.
- 고정 복제본: 참조된 포드 템플릿의 리소스 요청에 따라 생성할 고정된 수의 버퍼 포드를 지정합니다. 이 구성은 알려진 크기의 버퍼를 만드는 가장 간단한 방법입니다.
- 리소스 한도: 버퍼가 예약해야 하는 총 CPU 및 메모리 양을 지정합니다. 컨트롤러는 참조된 포드 템플릿의 리소스 요청을 기반으로 생성할 버퍼 포드 수를 계산합니다.
- 백분율 기반: 스케일 하위 리소스를 정의하는 기존 확장 가능 객체 (예: Deployment, StatefulSet, ReplicaSet, Job)의 백분율로 버퍼 크기를 정의합니다. 참조 워크로드가 확장됨에 따라 버퍼 크기가 동적으로 조정됩니다. 백분율 기반 용량 버퍼는 Kubernetes 규모 하위 리소스를 구현하는 객체에만 지원됩니다.
자세한 내용은 CapacityBuffer CRD 참조 문서를 참고하세요.
권장사항
용량 버퍼를 구성할 때 비용 효율성과 응답성을 최적화하려면 다음 권장사항을 따르세요.
- 비용 최적화, 대기 우선 전략 사용: 워크로드가 약 30초의 짧은 스케일 업 지연을 허용할 수 있는 경우 대기 버퍼에 우선순위를 둡니다. 이 전략을 사용하면 활성 VM의 전체 비용을 지불하지 않고도 새 VM의 콜드 노드 부팅을 방지할 수 있습니다.
- 지연 시간에 민감한 워크로드에 활성 버퍼 사용: 포드 일정 계획 시간이 최대한 짧아야 할 때 노드 재개 시간을 허용할 수 없는 워크로드에 활성 버퍼를 사용합니다.
- 하이브리드 전략을 사용하여 성능과 비용의 균형 유지: 비용 효율적인 설정을 위해 작은 활성 버퍼와 큰 대기 버퍼를 결합합니다. GKE는 대기 버퍼에서 노드를 재개하여 활성 버퍼를 다시 채우는 데 우선순위를 둡니다 (약 30초 소요). 새 노드는 백그라운드에서 프로비저닝되어 대기 버퍼를 다시 채웁니다. 이 설정은 활성 용량으로 초기 급증을 흡수하고, 저렴한 비용의 대기 용량을 사용하여 지속적인 성장을 수용합니다.
- 초기 버스트를 위한 활성 버퍼 크기 조정: 대기 버퍼 노드가 재개되기 전에 발생할 것으로 예상되는 초기 갑작스러운 복제본 스파이크를 처리할 수 있도록 활성 버퍼의 크기를 정의합니다.
- 지속적인 부하를 위한 대기 버퍼 크기 조정: 예상되는 확장된 부하를 처리할 수 있는 대기 버퍼를 정의하여 콜드 스타트에서 버퍼가 백그라운드에서 다시 채워질 수 있도록 합니다. 충분한 크기의 대기 버퍼를 사용하면 최대 포드 예약 지연 시간을 노드 재개 시간(약 30초)으로 줄일 수 있습니다. 용량 버퍼가 사용되기 시작하고 다시 채워지면 새 버퍼 노드가 일시중지되기 전에 활성 상태로 전환됩니다. 이 전략은 장기 로드 중에 활성 용량을 늘리는 데 도움이 됩니다.
- 버퍼 시뮬레이터 사용: 다양한 활성 및 대기 버퍼 크기를 실험하여 특정 워크로드에 가장 적합한 결과를 얻습니다. https://github.com/gke-labs/buffers-simulator에서 오픈소스 GKE 버퍼 시뮬레이터를 사용하여 워크로드 확장 동작 시뮬레이션을 실행하여 버퍼 크기 조정 규칙을 미세 조정하고 성능 목표를 달성하세요.
요구사항 및 제한사항
용량 버퍼에는 다음과 같은 요구사항 및 제한사항이 있습니다.
- 용량 버퍼는 활성 버퍼의 경우 버전 1.35.2-gke.1842000 이상, 대기 버퍼의 경우 버전 1.36.0-gke.2253000 이상을 실행하는 GKE 클러스터에서 사용할 수 있습니다.
- 용량 버퍼는 Standard 노드 풀의 노드 기반 결제 모델과 특정 하드웨어를 선택하는 Autopilot 노드 풀을 사용하는 워크로드만 지원합니다. 용량 버퍼는 포드 기반 결제 모델을 사용하는 워크로드를 지원하지 않습니다.
- Standard 클러스터에서는 노드 자동 프로비저닝을 사용 설정하는 것이 좋습니다. 노드 자동 프로비저닝을 사용하면 클러스터 자동 확장 처리가 CapacityBuffer의 리소스 요청에 따라 새 노드 풀을 만들 수 있습니다. 노드 자동 프로비저닝을 사용 설정하지 않으면 클러스터 자동 확장 처리는 기존 노드 풀만 수직 확장합니다.
- 활성 및 대기 용량 버퍼는 모두 Compute Engine 할당량에 포함됩니다.
대기 버퍼에는 다음과 같은 추가 제한사항이 있습니다.
- 노드 자동 프로비저닝이 사용 설정된 Standard 클러스터에서만 지원됩니다.
- GPU 또는 TPU가 연결된 노드는 지원되지 않습니다.
- 로컬 SSD는 지원되지 않습니다.
- 고객 관리 암호화 키 (CMEK)는 지원되지 않습니다.
- 컨피덴셜 Google Kubernetes Engine 노드는 지원되지 않습니다.
- Compute Engine 일시중지 및 재개 작업과 관련된 제한사항을 잘 알고 있어야 합니다.
몇 가지 주요 제한사항은 다음과 같습니다.
- 고객 제공 암호화 키 (CSEK)로 보호되는 디스크가 있는 노드는 지원되지 않습니다.
- 메모리가 208GB를 초과하는 노드는 지원되지 않습니다.
- 베어메탈 인스턴스는 지원되지 않습니다.
- 노드 OS는 ACPI S3 절전 모드 신호를 지원해야 합니다.
- 정지 프로세스 길이는 메모리 크기에 비례합니다.
- 다시 시작 여부는 다시 시작하는 데 필요한 기본 리소스의 획득 가능성에 따라 달라집니다.
다음 단계
- 용량 버퍼를 구현하는 방법을 알아보려면 용량 버퍼 구성을 참고하세요.