flex-start 프로비저닝 모드의 GPU 가용성 정보

이 페이지에서는 Google Kubernetes Engine (GKE)의 유연한 시작 프로비저닝 모드를 설명합니다. 동적 워크로드 스케줄러를 기반으로 하는 유연한 시작은 AI/ML 워크로드를 실행해야 할 때 GPU를 얻는 유연하고 비용 효율적인 기법을 제공합니다.

유연한 시작을 사용하면 특정 시작 시간에 제한되지 않고 장기 예약을 관리하지 않고도 최대 7일 동안 필요에 따라 가속기를 동적으로 프로비저닝할 수 있습니다. 따라서 유연한 시작은 수요 요구사항이 변동되거나 기간이 짧은 소규모에서 중형 워크로드에 적합합니다. 예를 들어 소규모 모델 사전 학습, 모델 미세 조정 또는 확장 가능한 서빙 모델이 여기에 해당합니다.

이 페이지의 정보는 다음을 수행하는 데 도움이 됩니다.

  • GKE의 유연한 시작 작동 방식을 이해합니다.
  • 워크로드에 flex-start가 적합한지 결정합니다.
  • 워크로드에 적합한 유연한 시작 구성을 결정합니다.
  • flex-start를 사용할 때 발생하는 중단을 관리합니다.
  • GKE의 flex-start 제한사항을 이해합니다.

이 페이지는 워크로드에 맞게 가속기 인프라를 최적화하려는 플랫폼 관리자 및 운영자와 머신러닝 (ML) 엔지니어를 대상으로 합니다.

flex-start를 사용해야 하는 경우

워크로드가 다음 조건을 모두 충족하는 경우 flex-start를 사용하는 것이 좋습니다.

  • 워크로드에 GPU 리소스가 필요합니다.
  • 예약된 GPU 용량이 제한되거나 없고 GPU에 더 안정적으로 액세스해야 하는 경우
  • 워크로드가 시간에 구애받지 않으며 사용 사례는 GKE에서 사용량이 가장 많은 시간 외에 GPU 리소스를 할당하는 경우와 같이 요청된 모든 용량을 얻을 때까지 대기할 수 있습니다.

요구사항

GKE에서 flex-start를 사용하려면 클러스터가 버전 1.32.2-gke.1652000 이상을 사용해야 합니다.

유연한 시작 프로비저닝 모드의 작동 방식

flex-start를 사용하면 워크로드에서 필요한 GPU 용량을 지정할 수 있습니다. 또한 Standard 클러스터에서는 특정 노드 풀에 flex-start를 구성합니다. GKE는 용량을 사용할 수 있게 되면 다음 프로세스를 완료하여 VM을 자동으로 프로비저닝합니다.

  1. 워크로드가 즉시 사용할 수 없는 GPU 리소스를 요청합니다. 이 요청은 워크로드 사양에서 직접 또는 커스텀 컴퓨팅 클래스 또는 Kueue와 같은 예약 도구를 통해 할 수 있습니다.
  2. GKE는 노드에 유연한 시작이 사용 설정되어 있고 워크로드가 정해지지 않은 시간 동안 기다릴 수 있음을 확인합니다.
  3. 클러스터 자동 확장 처리는 요청을 수락하고 필요한 노드 수를 계산하여 단일 단위로 처리합니다.
  4. 스케줄러는 필요한 모든 리소스를 단일 영역에서 사용할 수 있을 때까지 기다립니다.
  5. 클러스터 자동 확장 처리는 사용 가능한 경우 필요한 노드를 프로비저닝합니다. 이러한 노드는 최대 7일 동안 실행되며 maxRunDurationSeconds 매개변수에 값을 지정하면 더 짧은 기간 동안 실행됩니다. 이 매개변수는 GKE 버전 1.28.5-gke.1355000 이상에서 사용할 수 있습니다. maxRunDurationSeconds 매개변수 값을 지정하지 않으면 기본값은 7일입니다.
  6. maxRunDurationSeconds 매개변수에 정의한 실행 시간이 종료되면 노드와 포드가 선점됩니다.
  7. 포드가 더 빨리 완료되고 노드가 더 이상 사용되지 않으면 클러스터 자동 확장 처리는 자동 확장 프로필에 따라 노드를 삭제합니다.

GKE는 노드 수준에서 각 유연한 시작 요청의 기간을 계산합니다. 시작 중 지연으로 인해 포드를 실행하는 데 사용할 수 있는 시간이 약간 더 짧을 수 있습니다. 포드 재시도는 이 기간을 공유하므로 재시도 후 해당 포드에 사용할 수 있는 시간이 줄어듭니다. GKE는 각 flex-start 요청의 기간을 별도로 계산합니다.

유연한 시작 구성

GKE는 다음과 같은 유연한 시작 구성을 지원합니다.

  • Flex-start: GKE가 노드별로 리소스를 할당합니다. 이 구성에서는 노드 생성 중에 --flex-start 플래그만 설정하면 됩니다.

  • 큐에 추가된 프로비저닝을 통한 flex-start: GKE가 요청된 모든 리소스를 동시에 할당합니다. 워크로드의 모든 포드는 새로 프로비저닝된 노드에서 함께 실행될 수 있습니다. 프로비저닝된 노드는 워크로드 실행 간에 재사용되지 않습니다. 이 구성을 사용하려면 노드 풀을 만들 때 --flex-start 및 enable-queued-provisioning 플래그를 추가해야 합니다.

다음 표에서는 유연한 시작 구성을 비교합니다.

유연한 시작 큐에 추가된 프로비저닝을 통한 flex-start
가용성 미리보기
참고: 유연한 시작 미리보기에 등록하려면 요청 양식을 작성하세요. 이 기능에 대한 의견을 제공하거나 지원을 요청하려면 dws-flex-start-feedback@google.com으로 문의하세요.

정식 버전 (GA)

참고: Flex-start는 미리보기에서 flex-start 및 enable-queued-provisioning 플래그를 지원합니다. 이러한 플래그의 미리보기에 등록하려면 요청 양식을 작성하세요. 이 기능에 대한 의견을 제공하거나 지원을 요청하려면 dws-flex-start-feedback@google.com으로 문의하세요.
권장 워크로드 크기 소규모에서 중규모: 워크로드를 단일 노드에서 실행할 수 있습니다. 예를 들어 이 구성은 소규모 학습 작업, 오프라인 추론 또는 일괄 작업을 실행하는 경우에 적합합니다. 중대형: 워크로드를 여러 노드에서 실행할 수 있습니다. 워크로드에 여러 리소스가 필요하며 모든 GPU 노드가 동시에 프로비저닝되고 준비될 때까지 실행을 시작할 수 없습니다. 예를 들어 이 구성은 분산된 ML 학습 워크로드를 실행하는 경우에 적합합니다.
프로비저닝 유형 GKE는 리소스가 사용 가능한 경우 한 번에 하나씩 노드를 프로비저닝합니다. GKE는 요청된 모든 리소스를 동시에 할당합니다.
설정 복잡성 덜 복잡합니다. 이 구성은 주문형 및 스팟 VM과 유사합니다. 더 복잡합니다. Kueue와 같은 할당량 관리 도구를 사용하는 것이 좋습니다.
커스텀 컴퓨팅 클래스 지원 예 아니요
노드 재활용 예 아니요
가격 Flex Start SKU Flex Start SKU
할당량 선점형 선점형
노드 업그레이드 전략 단기 업그레이드 단기 업그레이드
gcloud container node pool create 플래그 --flex-start
  • --flex-start
  • --enable-queued-provisioning
시작하기 큐에 추가된 프로비저닝을 통한 flex-start로 대규모 워크로드 실행

flex-start 구성 최적화

비용 효율적이고 강력한 AI/ML 인프라를 만들려면 유연한 시작 구성을 사용 가능한 GKE 기능과 결합하면 됩니다. 컴퓨팅 클래스를 사용하여 워크로드 요구사항에 따라 우선순위가 지정된 노드 구성 목록을 정의하는 것이 좋습니다. GKE는 가용성과 정의된 우선순위에 따라 가장 적합한 구성을 선택합니다.

동적 워크로드 스케줄러를 사용하는 워크로드의 중단 관리

노드 풀에서 모든 노드 또는 대부분의 노드의 가용성이 필요한 워크로드는 제거에 민감합니다. 또한 동적 워크로드 스케줄러 요청을 사용하여 프로비저닝된 노드는 자동 복구를 지원하지 않습니다. 자동 수리는 노드에서 모든 워크로드를 삭제하므로 워크로드가 실행되지 않습니다.

클러스터 제어 영역에서 유연한 시작의 최소 버전인 1.32.2-gke.1652000 이상을 실행하는 경우 유연한 시작, 대기열에 추가된 프로비저닝 또는 둘 다를 사용하는 모든 노드는 단기 업그레이드를 사용합니다.

단기 업그레이드는 실행 중인 노드를 중단하지 않고 Autopilot 클러스터의 Standard 노드 풀 또는 노드 그룹을 업데이트합니다. 새 구성으로 새 노드가 생성되고 시간이 지남에 따라 기존 노드가 이전 구성으로 점진적으로 대체됩니다. 유연한 시작 또는 단기 업그레이드를 지원하지 않는 이전 버전의 GKE에는 다른 권장사항이 적용됩니다.

단기 업그레이드를 사용하여 노드의 워크로드 중단을 최소화하기 위한 권장사항

클러스터에서 버전 1.32.2-gke.1652000 이상을 실행할 때는 대기열에 추가된 프로비저닝을 사용하는 유연한 시작 노드와 노드가 자동으로 단기 업그레이드를 사용하도록 구성됩니다.

단기 업그레이드를 사용하는 노드에서 실행되는 워크로드의 중단을 최소화하려면 다음 작업을 실행합니다.

1.32.2-gke.1652000 이하 버전을 실행하고 있으므로 단기 업그레이드를 사용하지 않는 클러스터의 노드의 경우 해당 노드에 관한 구체적인 안내를 참고하세요.

단기 업그레이드 없이 대기열에 있는 프로비저닝 노드의 워크로드 중단을 최소화하기 위한 권장사항

1.32.2-gke.1652000 이전의 GKE 버전을 실행하는 클러스터에서 대기열에 추가된 프로비저닝을 사용하는 노드는 단기 업그레이드를 사용하지 않습니다. 기존에 대기열에 추가된 프로비저닝 노드가 있는 클러스터가 1.32.2-gke.1652000 이상으로 업그레이드되면 단기 업그레이드를 사용하도록 자동 업데이트됩니다.

이러한 이전 버전을 실행하는 노드의 경우 다음 안내를 참고하세요.

클러스터가 단기 업그레이드로 이전하는 경우 고려사항

GKE는 클러스터가 버전 1.32.2-gke.1652000 이상으로 업그레이드될 때 일시적인 업그레이드를 사용하도록 대기열에 추가된 프로비저닝을 사용하여 기존 노드를 업데이트합니다. GKE는 특정 노드 풀에서 노드 자동 업그레이드를 사용 중지한 경우 노드 자동 업그레이드를 사용 설정하는 등의 다른 설정을 업데이트하지 않습니다.

노드 풀에서 단기 업그레이드를 사용하는 지금 다음 권장사항을 구현하는 것이 좋습니다.

  • --no-enable-autoupgrade 플래그를 사용하여 노드 자동 업그레이드를 사용 중지한 경우 이 이전은 노드 풀의 노드 자동 업그레이드를 다시 사용 설정하지 않습니다. 단기 업그레이드는 기존 노드와 노드에서 실행되는 워크로드에 지장을 주지 않으므로 노드 자동 업그레이드를 사용 설정하는 것이 좋습니다. 자세한 내용은 단기 업그레이드를 참고하세요.
  • 또한 클러스터가 아직 출시 채널에 등록되지 않은 경우 더 세분화된 유지보수 제외 범위를 사용할 수 있도록 클러스터를 등록하는 것이 좋습니다.

flex-start의 노드 재활용

노드의 원활한 전환을 보장하고 실행 중인 작업의 다운타임을 방지하기 위해 flex-start는 노드 재활용을 지원합니다. 노드의 7일 기간이 종료되면 GKE는 실행 중인 워크로드를 보존하기 위해 노드를 새 노드로 자동 교체합니다.

노드 재활용을 사용하려면 커스텀 컴퓨팅 클래스 프로필을 만들고 다음 매개변수를 사용하여 flexStart 사양에 nodeRecycling 필드를 포함해야 합니다.

  • leadTimeSeconds: 리소스 가용성과 비용 효율성 간의 균형을 맞출 수 있는 구성 가능한 매개변수입니다. leadTimeSeconds 매개변수는 노드의 7일 기간이 종료되기 몇 초 전에 새 노드 프로비저닝 프로세스가 노드를 대체하기 시작해야 하는지 지정합니다. 리드 타임이 길수록 이전 노드가 삭제되기 전에 새 노드가 준비될 가능성이 높아지지만 추가 비용이 발생할 수 있습니다.
  • maxRunDurationSeconds: 노드가 활성 상태일 수 있는 최대 시간을 설정할 수 있는 구성 가능한 매개변수입니다.

노드 재활용 프로세스는 다음 단계로 구성됩니다.

  1. 재활용 단계: GKE는 flex-start-provisioned 노드의 nodeRecycling 플래그가 true로 설정되어 있는지 확인합니다. 이 경우 GKE는 현재 날짜가 다음 필드의 값 차이보다 크거나 같은 경우 노드 재활용 단계를 시작합니다.

    • creationTimestamp + maxRunDurationSeconds
    • leadTimeSeconds

    creationTimeStamp 플래그에는 노드가 생성된 시간이 포함됩니다.

  2. 노드 생성: 새 노드의 생성 프로세스가 시작되어 대기열 및 프로비저닝 단계를 거칩니다. 대기열 단계 기간은 영역 및 특정 가속기 용량에 따라 동적으로 달라질 수 있습니다.

  3. 7일 기간이 종료되는 노드 차단: 새 노드가 실행된 후 기존 노드가 차단됩니다. 이 작업을 수행하면 새 포드가 예약되지 않습니다. 해당 노드의 기존 포드는 계속 실행됩니다.

  4. 노드 프로비저닝 해제: 7일 기간이 종료되는 노드는 적절한 기간이 지난 후 프로비저닝 해제되므로 실행 중인 워크로드가 새 노드로 이전될 수 있습니다.

노드 재활용을 사용하는 방법에 관한 자세한 내용은 비용 최적화 및 고가용성 GPU 프로비저닝 전략으로 GKE에서 LLM 제공 튜토리얼을 참고하세요.

제한사항

  • 포드 간 안티-어피니티는 지원되지 않습니다. 클러스터 자동 확장 처리는 노드 프로비저닝 중에 포드 간 안티어피니티 규칙을 고려하지 않으므로 워크로드를 예약하지 못할 수 있습니다. 이 문제는 2개 이상의 동적 워크로드 스케줄러 객체의 노드가 동일한 노드 풀에 프로비저닝된 경우에 발생할 수 있습니다.
  • GPU 노드만 지원됩니다.
  • 동적 워크로드 스케줄러에서는 예약이 지원되지 않습니다. 노드 풀을 만들 때 --reservation-affinity=none 플래그를 지정해야 합니다. 동적 워크로드 스케줄러는 클러스터 자동 확장의 ANY 위치 정책만 필요로 하고 지원합니다.
  • 단일 동적 워크로드 스케줄러 요청은 단일 노드 풀의 영역당 최대 노드 수인 가상 머신(VM)을 최대 1,000개까지 만들 수 있습니다.
  • GKE는 Compute Engine ACTIVE_RESIZE_REQUESTS 할당량을 사용하여 큐에서 대기 중인 동적 워크로드 스케줄러 요청 수를 제어합니다. 기본적으로 이 할당량은 프로젝트당 100개 요청으로 제한됩니다. Google Cloud이 할당량을 초과하는 동적 워크로드 스케줄러 요청을 만들려고 하면 새 요청이 실패합니다.
  • 동적 워크로드 스케줄러를 사용하는 노드 풀은 노드가 함께 프로비저닝되므로 중단에 민감합니다. 자세한 내용은 동적 워크로드 스케줄러를 사용하는 워크로드의 중단 관리를 참고하세요.
  • 콘솔에 나열된 추가 단기 VM이 표시될 수 있습니다. Google Cloud 이 동작은 필요한 모든 머신을 프로비저닝할 수 있는 용량을 사용할 수 있을 때까지 Compute Engine이 VM을 만들고 즉시 삭제할 수 있기 때문입니다.
  • 스팟 VM은 지원되지 않습니다.
  • 동적 워크로드 스케줄러는 임시 볼륨을 지원하지 않습니다. 스토리지에는 영구 볼륨을 사용해야 합니다. 영구 볼륨을 사용하는 가장 적합한 스토리지 유형을 선택하려면 GKE 클러스터용 스토리지 개요를 참고하세요.
  • 워크로드가 노드 재활용을 사용하고 작업에 의해 배포되는 경우 완료 모드를 Indexed로 설정하여 작업을 구성합니다.

다음 단계