클러스터 자동 확장

자동 확장이란 무엇인가요?

워크로드에 '적절한' 클러스터 작업자(노드) 수를 예측하는 것은 어려우며 전체 파이프라인에 단일 클러스터 크기 사용하는 것이 적합하지 않은 경우가 많습니다. 사용자가 시작하는 클러스터 확장으로 이 문제를 부분적으로 해결할 수 있지만 클러스터 사용률 및 수동 개입을 모니터링해야 합니다.

Dataproc AutoscalingPolicies API는 클러스터 리소스 관리를 자동화하는 메커니즘을 제공하고 클러스터 자동 확장을 사용 설정합니다. Autoscaling Policy는 자동 확장 정책을 사용하는 클러스터가 확장되어야 하는 방식을 설명하는 재사용 가능한 구성입니다. 확장 경계, 빈도, 강도를 정의하여 클러스터의 수명 동안 클러스터 리소스에 대한 세분화된 제어를 제공합니다.

자동 확장을 사용해야 하는 경우

자동 확장 사용:

Cloud Storage 또는 BigQuery와 같이 데이터를 외부 서비스에 저장하는 클러스터

여러 작업을 처리하는 클러스터

단일 작업 클러스터 확장

다음을 대상으로 하거나 다음의 용도로 자동 확장을 사용하는 것은 권장되지 않습니다.

  • 고가용성 클러스터: 표준 클러스터를 대신 사용하며, 연속된 크기 조절 작업 후 보다 안정적입니다.

  • HDFS: 자동 확장은 온클러스터 HDFS를 확장하기 위한 용도가 아닙니다. HDFS에 자동 확장을 사용하는 경우 최소 기본 작업자 수가 모든 HDFS 데이터를 처리하기에 충분한지 확인하세요. HDFS 데이터 노드를 사용 중단할 경우 작업자 삭제가 지연될 수 있다는 점에도 주의하세요.

  • YARN Node Labels: 자동 확장은 YARN Node Labels를 지원하지 않으며 YARN-9088로 인해 dataproc:am.primary_only 속성도 지원하지 않습니다. YARN은 노드 라벨을 사용할 때 클러스터 측정항목을 잘못 보고합니다.

  • Spark Structured Streaming: 자동 확장은 Spark Structured Streaming을 지원하지 않습니다(자동 확장 및 Spark Structured Streaming 참조).

  • 유휴 클러스터: 클러스터가 유휴 상태일 때 클러스터를 최소 크기로 축소하기 위한 용도로 자동 확장을 사용하는 것은 권장되지 않습니다. 새 클러스터 만들기와 클러스터 크기 조절은 비슷한 속도로 실행되기 때문에 유휴 클러스터를 삭제하고 대신 다시 만드는 것이 좋습니다. 다음 도구가 이러한 '임시' 모델을 지원합니다.

    Dataproc 워크플로를 사용하여 전용 클러스터에서 일련의 작업을 예약하고, 작업이 완료되면 클러스터를 삭제합니다. 고급 조정의 경우 Apache Airflow 기반의 Cloud Composer를 사용합니다.

    임시 쿼리 또는 외부에서 예약된 워크로드를 처리하는 클러스터의 경우, 클러스터 예약 삭제를 사용하여 지정된 유휴 기간 후에 또는 특정 시간에 클러스터를 삭제합니다.

자동 확장 사용 설정

클러스터에서 자동 확장 정책을 사용 설정하려면 다음 안내를 따르세요.

  1. 자동 확장 정책을 만듭니다.

  2. 다음 중 하나를 수행합니다.

    1. 자동 확장 클러스터 만들기
    2. 기존 클러스터에서 자동 확장 사용 설정

자동 확장 정책 만들기

gcloud 명령어

gcloud dataproc autoscaling-policies import 명령어를 사용하여 자동 확장 정책을 만들 수 있습니다. 자동 확장 정책을 정의하는 로컬 YAML 파일을 읽습니다. 파일의 형식 및 콘텐츠는 autoscalingPolicies REST API에서 정의한 구성 객체 및 필드와 일치해야 합니다.

다음 YAML 예시는 모든 필수 필드를 지정하는 정책을 정의합니다. 또한 기본 및 보조(선점형) 작업자에 maxInstances 값을 제공하며 4분의 cooldownPeriod(기본값은 2분)도 지정합니다.

workerConfig:
  maxInstances: 100
secondaryWorkerConfig:
  maxInstances: 50
basicAlgorithm:
  cooldownPeriod: 4m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    gracefulDecommissionTimeout: 1h

다음은 모든 선택사항 및 필수 자동 확장 정책 필드를 지정하는 또 하나의 YAML 예시입니다.

workerConfig:
  minInstances: 2
  maxInstances: 100
  weight: 1
secondaryWorkerConfig:
  minInstances: 0
  maxInstances: 100
  weight: 1
basicAlgorithm:
  cooldownPeriod: 4m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    scaleUpMinWorkerFraction: 0.0
    scaleDownMinWorkerFraction: 0.0
    gracefulDecommissionTimeout: 1h

로컬 터미널 또는 Cloud Shell에서 gcloud 명령어를 실행하여 자동 확장 정책을 만듭니다. 정책의 이름을 입력합니다. 이 이름이 id 정책이 되며, 나중에 gcloud 명령어에서 정책을 참조할 때 사용될 수 있습니다. --source 플래그를 사용하여 가져올 자동 확장 정책 YAML 파일의 로컬 파일 경로와 파일 이름을 지정합니다.

gcloud dataproc autoscaling-policies import policy-name \
    --source=filepath/filename.yaml \
    --region=region

REST API

autoscalingPolicies.create 요청의 일부로 AutoscalingPolicy를 정의하여 자동 확장 정책을 만듭니다.

콘솔

현재 Google Cloud Console에서는 자동 확장 정책 만들기를 지원하지 않습니다.

자동 확장 클러스터 만들기

자동 확장 정책을 만들었으면 자동 확장 정책을 사용할 클러스터를 만듭니다. 클러스터는 자동 확장 정책과 동일한 리전에 있어야 합니다.

gcloud 명령

로컬 터미널 또는 Cloud Shell에서 gcloud 명령어를 실행하여 자동 확장 클러스터를 만듭니다. 클러스터 이름을 입력하고 --autoscaling-policy 플래그를 사용하여 policy id(정책을 만들 때 지정한 정책 이름) 또는 정책 resource URI (resource name)를 지정합니다(AutoscalingPolicy idname 필드 참조).

gcloud dataproc clusters create cluster-name \
    --autoscaling-policy=policy id or resource URI \
    --region=region

REST API

clusters.create 요청에 AutoscalingConfig를 포함하여 자동 확장 클러스터를 만듭니다.

콘솔

Cloud Console의 Dataproc 클러스터 만들기 페이지에 있는 자동 확장 정책 섹션에서 새 클러스터에 적용할 기존 자동 확장 정책을 선택할 수 있습니다.

기존 클러스터에서 자동 확장 사용 설정

자동 확장 정책을 만들었으면 동일한 리전의 기존 클러스터에서 정책을 사용 설정할 수 있습니다.

gcloud 명령

로컬 터미널 또는 Cloud Shell에서 gcloud 명령어를 실행하여 기존 클러스터에서 자동 확장 정책을 사용 설정합니다. 클러스터 이름을 입력하고 --autoscaling-policy 플래그를 사용하여 policy id(정책을 만들 때 지정한 정책 이름) 또는 정책 resource URI (resource name)를 지정합니다(AutoscalingPolicy idname 필드 참조).

gcloud dataproc clusters update cluster-name \
    --autoscaling-policy=policy id or resource URI \
    --region=region

REST API

기존 클러스터에서 자동 확장 정책을 사용 설정하려면 clusters.patch 요청의 updateMask에서 정책의 AutoscalingConfig.policyUri를 설정합니다.

콘솔

현재 Google Cloud Console에서는 기존 클러스터에 자동 확장 정책 사용 설정이 지원되지 않습니다.

자동 확장 방식

자동 확장은 '대기' 기간마다 클러스터 Hadoop YARN 측정항목을 확인하여 클러스터를 확장할 것인지 그리고 확장할 경우 어느 정도 업데이트할 것인지를 결정합니다.

  1. 평가할 때마다 자동 확장은 지난 cooldown_period 동안의 평균적인 보류 및 사용 가능 클러스터 메모리를 조사하여 작업자 수를 얼마나 변경해야 하는지를 정확하게 결정합니다.

    exact Δworkers = avg(pending memory - available memory) / memory per node manager

    • pending memory는 클러스터에 아직 실행되지 않고 큐에 추가된 작업이 있으며 워크로드 처리를 개선하기 위해서는 확장이 필요할 수도 있음을 나타내는 신호입니다.
    • available memory는 클러스터의 정상 노드에 대역폭이 남아 있으며 리소스를 절약하기 위해 축소가 필요할 수도 있음을 나타내는 신호입니다.
    • 이러한 Apache Hadoop YARN 측정항목에 대한 자세한 내용은 Hadoop 및 Spark로 자동 확장을 참조하세요.
  2. 작업자 수를 얼마나 변경해야 하는지 정확하게 파악한 후 자동 확장은 scaleUpFactor 또는 scaleDownFactor를 사용하여 실제 작업자 수의 변화를 계산합니다.

    if exact Δworkers > 0:
      actual Δworkers = ROUND_UP(exact Δworkers * scaleUpFactor)
      # examples:
      # ROUND_UP(exact Δworkers=5 * scaleUpFactor=0.5) = 3
      # ROUND_UP(exact Δworkers=0.8 * scaleUpFactor=0.5) = 1
    else:
      actual Δworkers = ROUND_DOWN(exact Δworkers * scaleDownFactor)
      # examples:
      # ROUND_DOWN(exact Δworkers=-5 * scaleDownFactor=0.5) = -2
      # ROUND_DOWN(exact Δworkers=-0.8 * scaleDownFactor=0.5) = 0
      # ROUND_DOWN(exact Δworkers=-1.5 * scaleDownFactor=0.5) = 0
    
    1.0의 scaleUpFactor 또는 scaleDownFactor는 보류/사용 가능한 메모리가 0(완전 사용)이 되도록 자동 확장이 이루어진다는 의미입니다.

  3. 작업자 수의 실제 변경사항이 계산되면 scaleUpMinWorkerFractionscaleDownMinWorkerFraction이 임곗값 역할을 하여 자동 확장이 클러스터를 확장할지 결정합니다. 작은 비율은 Δworkers가 작은 경우에도 자동 확장이 이루어진다는 의미입니다. 비율이 클 경우 Δworkers가 클 경우에만 확장됩니다.

    if (Δworkers >  scaleUpMinWorkerFraction* cluster size) then scale up
    또는
    if (abs(Δworkers) >  scaleDownMinWorkerFraction* cluster size) then scale down

  4. 작업자 수가 확장이 필요할 만큼 클 경우, 자동 확장은 workerConfigsecondaryWorkerConfigminInstances maxInstances 경계와 weight(기본 작업자와 보조 작업자의 비율)를 사용하여 기본 및 보조 작업자 인스턴스 그룹 간에 작업자 수를 분할할 방법을 결정합니다. 이 계산의 결과에 따라 자동 확장은 확장 기간 동안 클러스터를 최종적으로 변경합니다.

단계적 해제

자동 확장은 클러스터에서 노드를 삭제할 때 YARN 단계적 해제를 지원합니다. 단계적 해제를 사용하면 애플리케이션이 단계 간의 데이터 셔플 처리를 완료하여 작업 진행을 다시 설정할 필요가 없습니다. 자동 확장 정책에서 제공되는 단계적 해제 제한 시간은 YARN이 노드를 삭제하기 전에 실행 중인 애플리케이션(지원 중단이 시작될 때 실행 중이었던 애플리케이션)을 기다리는 기간의 상한입니다.

멀티 클러스터 정책 사용

  • 자동 확장 정책은 여러 클러스터에 적용할 수 있는 확장 동작을 정의합니다. 자동 확장 정책은 클러스터가 비슷한 워크로드를 공유하거나 리소스 사용 패턴이 비슷한 작업을 실행하는 경우 여러 클러스터에 적용하는 데 가장 작업합니다.

  • 여러 클러스터에서 사용 중인 정책을 업데이트할 수 있습니다. 이 업데이트는 해당 정책을 사용하는 모든 클러스터의 자동 확장 동작에 즉시 영향을 미칩니다(autoscalingPolicies.update 참조). 정책을 사용 중인 클러스터에 정책 업데이트를 적용하지 않으려면 정책을 업데이트하기 전에 클러스터에서 자동 확장을 사용 중지합니다.

gcloud 명령

로컬 터미널 또는 Cloud Shell에서 gcloud 명령어를 실행하여 클러스터에서 자동 확장 정책을 사용 중지합니다.

gcloud dataproc clusters update cluster-name --disable-autoscaling \
    --region=region

REST API

클러스터에서 자동 확장을 사용 중지하려면 AutoscalingConfig.policyUri를 빈 문자열로 설정하거나 clusters.patch 요청에 update_mask=config.autoscaling_config.policy_uri를 설정합니다.

콘솔

현재 Google Cloud Console에서는 클러스터에서 자동 확장 사용 중지가 지원되지 않습니다.

자동 확장 권장사항

  • 대기 기간: 최소 및 기본값 cooldownPeriod은 2분입니다. 정책에서 더 짧은 cooldownPeriod를 설정하면 워크로드 변경 사항이 클러스터 크기에 더 빨리 영향을 미치지만 불필요하게 클러스터가 확장 및 축소될 수 있습니다. 더 짧은 cooldownPeriod를 사용할 때는 정책의 scale_up, scale_down, min_worker_fractions를 모두 0이 아닌 값으로 설정하는 것이 좋습니다. 이렇게 하면 메모리 사용률의 변화가 클러스터 업데이트를 보증하기에 충분할 때만 클러스터가 확장 및 축소됩니다.

  • 축소 맵리듀스 및 Spark는 중간 shuffle 데이터를 로컬 디스크에 씁니다. shuffle 데이터가 있는 작업자를 삭제하면 shuffle 데이터를 재현하기 위해 매핑 작업을 다시 실행해야 하기 때문에 작업 진행이 지연될 수 있습니다. 누락된 shuffle 파일을 감지할 경우 Spark는 전체 단계를 다시 실행합니다.

    • 클러스터가 유휴 상태일 때만 축소하려면 scale_down factorscale_down min_worker_fraction을 1.0으로 설정합니다.

    • 지속적 부하가 포함된 클러스터의 경우 scale_down 요소를 1.0으로 설정하거나 0이 아닌 graceful_decommission_timeout을 설정하여 두 작업 간 축소를 구성하면 YARN 컨테이너를 실행하지 않을 때 클러스터 노드를 제거할 수 있습니다(단계적 해제 참조). 작업이 완료되기 전에 노드가 강제로 해제되지 않도록 graceful_decommission_timeout을 가장 오랫동안 실행된 클러스터 작업보다 길게 설정합니다.

    • 노드를 제거할 때 작업 진행 상태가 손실될 가능성을 방지하거나 줄이려면 향상된 유연성 모드를 사용하는 것이 좋습니다.

  • 캐시된 데이터가 있는 Spark 작업 spark.dynamicAllocation.cachedExecutorIdleTimeout을 설정하거나 더 이상 필요 없는 데이터 세트를 캐시 해제합니다. 기본적으로 Spark는 캐시된 데이터가 있는 실행자를 삭제하지 않습니다.

Apache Hadoop 및 Apache Spark로 자동 확장

다음 섹션에서는 자동 확장이 어떻게 Hadoop YARN 및 Hadoop 맵리듀스, Apache Spark, Spark Streaming, Spark Structured Streaming과 상호작용하는지(혹은 하지 않는지) 설명합니다.

Hadoop YARN 측정항목

자동 확장은 YARN 핵심 요청이 아니라 YARN 메모리 요청을 기준으로 작업을 예약하도록 Hadoop YARN을 구성합니다.

자동 확장은 다음의 Hadoop YARN 측정항목을 중심으로 이루어집니다.

  1. Allocated memory는 전체 클러스터에서 컨테이너를 실행함으로써 소비되는 총 YARN 메모리를 나타냅니다. 최대 1GB를 사용할 수 있는 컨테이너가 6개 있으면 할당된 메모리가 6GB인 것입니다.

  2. Available memory는 클러스터에서 할당된 컨테이너가 사용하지 않는 YARN 메모리입니다. 모든 노드 관리자에 10GB의 메모리가 있고 할당된 메모리가 6GB인 경우에는 사용 가능 메모리가 4GB 있는 것입니다. 클러스터에 사용 가능(미사용) 메모리가 있는 경우, 자동 확장은 클러스터에서 작업자를 삭제할 수 있습니다.

  3. Pending memory는 보류 컨테이너를 위한 YARN 메모리 요청 합계입니다. 보류 컨테이너는 공간이 YARN으로 돌아오기를 기다리고 있습니다. 사용 가능 메모리가 0이거나 다음 컨테이너를 할당하기에 너무 작은 경우 보류 메모리는 0이 아닙니다. 보류 컨테이너가 있으면 자동 확장이 작업자를 클러스터에 추가할 수 있습니다.

Cloud Monitoring에서 이러한 측정항목을 볼 수 있습니다. 기본적으로 YARN 메모리는 클러스터의 총 메모리에 0.8을 곱한 것입니다. 남은 메모리는 페이지 캐시와 같이 다른 데몬 및 운영체제가 사용할 수 있도록 예약됩니다. 기본값을 'yarn.nodemanager.resource.memory-mb 'YARN 구성 설정으로 재정의할 수 있습니다(Apache Hadoop YARN, HDFS, Spark, 관련 속성 참조).

자동 확장 및 Hadoop 맵리듀스

MapReduce는 각각의 매핑 및 감소 작업을 별도의 YARN 컨테이너로 실행합니다. 작업이 시작될 때 MapReduce는 각 매핑 작업에 컨테이너 요청을 제출하기 때문에 보류 YARN 메모리가 크게 증가하게 됩니다. 매핑 작업이 완료되면 보류 메모리가 줄어듭니다.

mapreduce.job.reduce.slowstart.completedmaps가 완료될 때(Dataproc에서 기본적으로 95%) 맵리듀스는 모든 감소기의 컨테이너 요청을 큐에 추가하기 때문에 또 다시 보류 메모리가 크게 증가합니다.

매핑 및 감소 작업이 몇 분 걸리는 경우를 제외하고는 자동 확장 scaleUpFactor에 높은 값을 설정하지 마세요. 작업자를 클러스터에 추가하는 데 적어도 1.5분이 걸리기 때문에 몇 분 동안 새 작업자를 활용하기에 충분한 보류 작업이 있는지 확인해야 합니다. 처음에는 scaleUpFactor를 보류 메모리의 0.05(5%) 또는 0.1(10%)로 설정하는 것이 좋습니다.

자동 확장 및 Spark

Spark는 YARN 위에 일정 예약 레이어를 하나 더 추가합니다. 특히 Spark Core의 동적 할당은 YARN에 컨테이너를 요청할 때 Spark 실행자를 실행한 후에 해당 실행자의 스레드에서 Spark 작업을 예약할 수 있게 해줍니다. Dataproc 클러스터는 기본적으로 동적 할당을 사용하기 때문에 필요할 때 실행자가 추가되고 삭제됩니다.

Spark는 항상 YARN에 컨테이너를 요청하지만 동적 할당 없이는 작업이 시작될 때만 컨테이너를 요청할 수 있습니다. 동적 할당을 사용하면 필요할 때 컨테이너를 삭제하고 새 컨테이너를 요청할 수 있습니다.

Spark는 소수의 실행자로 시작됩니다(자동 확장 클러스터에서는 2개). 그리고 백로깅된 작업이 있을 때 계속해서 실행자 수를 두 배로 늘립니다. 이로써 보류 메모리의 변동이 줄어듭니다(보류 메모리 급증 감소). Spark 작업의 경우 자동 확장 scaleUpFactor를 1.0(100%)과 같은 큰 숫자로 설정하는 것이 좋습니다.

Spark 동적 할당 중지

Spark 동적 할당을 활용하지 않는 별도의 Spark 작업을 실행 중인 경우에는 spark.dynamicAllocation.enabled=falsespark.executor.instances를 설정함으로써 Spark 동적 할당을 중지할 수 있습니다. 별도의 Spark 작업이 실행되는 동안에도 계속해서 자동 확장을 사용하여 클러스터를 확장하고 축소할 수 있습니다.

자동 확장 및 Spark Streaming

  1. Spark Streaming에는 스트리밍별 신호를 사용하여 실행자를 추가하고 삭제하는 자체적인 버전의 동적 할당이 있기 때문에 spark.streaming.dynamicAllocation.enabled=true를 설정하고, spark.dynamicAllocation.enabled=false를 설정하여 Spark Core의 동적 할당을 중지합니다.

  2. Spark Streaming 작업을 통해 단계적 해제(gracefulDecommissionTimeout 자동 확장)를 사용하지 마세요. 대신 자동 확장을 사용하여 작업자를 안전하게 삭제할 수 있도록 내결함성을 위한 체크포인팅을 구성합니다.

또는 Spark Streaming을 자동 확장 없이 사용하려면 다음 단계를 따르세요.

  1. Spark Core의 동적 할당을 중지합니다(spark.dynamicAllocation.enabled=false).
  2. 작업에 맞는 실행자 수(spark.executor.instances)를 설정합니다. 클러스터 속성을 참조하세요.

자동 확장 및 Spark Structured Streaming

Spark Structured Streaming은 현재 동적 할당을 지원하지 않기 때문에(SPARK-24815: Structured Streaming은 동적 할당을 지원해야 함 참조) 자동 확장은 Spark Structured Streaming과 호환되지 않습니다.

파티션 나누기 및 동시 로드를 통해 자동 확장 제어

동시 로드는 일반적으로 클러스터 리소스에 의해 설정되거나 결정되지만(예: HDFS 블록 수에 따라 작업 수가 결정됨) 자동 확장을 사용할 때는 반대가 됩니다. 즉, 자동 확장이 작업 동시 로드에 맞춰 작업자 수를 설정합니다. 다음은 작업 동시 로드를 설정하는 데 도움이 되는 가이드라인입니다.

  • Dataproc이 클러스터의 초기 클러스터 크기를 기준으로 맵리듀스 감소 작업의 기본 개수를 설정하지만, 사용자가 직접 mapreduce.job.reduces를 설정하여 감소 단계의 동시 로드 수를 늘릴 수 있습니다.
  • Spark SQL 및 Dataframe 동시 로드는 spark.sql.shuffle.partitions에 의해 결정됩니다(기본값은 200).
  • Spark의 RDD 함수는 spark.default.parallelism로 기본 설정되어 작업이 시작될 때 작업자 노드의 코어 수로 설정됩니다. 하지만 shuffle을 생성하는 모든 RDD 함수는 파티션 수로 매개변수를 사용하며, 이 매개변수가 spark.default.parallelism을 재정의합니다.

데이터가 균등하게 분할되어야 합니다. 눈에 띌 정도의 데이터 편향이 있으면 하나 이상의 작업이 다른 작업보다 더 오래 걸려서 사용률이 낮아질 수 있습니다.

자동 확장 기본 Spark/Hadoop 속성 설정

자동 확장 클러스터에는 기본 작업자가 삭제되거나 보조 작업자가 선점될 때의 작업 오류를 방지하기 위한 기본 클러스터 속성 값이 있습니다. 자동 확장을 사용하여 클러스터를 만들 때 기본값을 재정의할 수 있습니다(클러스터 속성 참조).

작업, 애플리케이션 마스터, 스테이지의 재시도 최대 횟수를 늘리기 위한 기본값:

yarn:yarn.resourcemanager.am.max-attempts=10
mapred:mapreduce.map.maxattempts=10
mapred:mapreduce.reduce.maxattempts=10
spark:spark.task.maxFailures=10
spark:spark.stage.maxConsecutiveAttempts=10

재시도 카운터를 재설정하기 위한 기본값(장기 실행 Spark Streaming 작업에 유용):

spark:spark.yarn.am.attemptFailuresValidityInterval=1h
spark:spark.yarn.executor.failuresValidityInterval=1h

Spark의 느린 시작 동적 할당 메커니즘이 작은 크기로 시작되도록 하기 위한 기본값:

spark:spark.executor.instances=2

자동 확장 측정항목 및 로그

다음 리소스 및 도구는 자동 확장 작업과 클러스터 및 작업에 미치는 영향을 모니터링하는 데 도움을 줄 수 있습니다.

Cloud Monitoring

다음과 같은 용도로 Cloud Monitoring을 사용합니다.

  • 자동 확장에서 사용하는 측정항목을 봅니다.
  • 클러스터에 있는 노드 관리자 수를 봅니다.
  • 자동 확장이 클러스터를 확장하거나 확장하지 않은 이유를 이해합니다. autoscaling-stackdriver1 autoscaling-stackdriver2 autoscaling-stackdriver3

Cloud 로깅

Cloud Logging을 사용하여 Cloud Dataproc 자동 확장 처리의 로그를 확인하세요.

1) 클러스터의 로그를 찾습니다.

autoscaling-logs-for-cluster

2) dataproc.googleapis.com/autoscaler를 선택합니다.

autoscaling-log-file

3) 로그 메시지를 펼쳐서 status 필드를 확인합니다. 로그는 머신이 읽을 수 있는 JSON 형식입니다.

autoscaling-three-logs autoscaling-update-operation

4) 로그 메시지를 펼쳐서 확장 권장사항, 확장 결정에 사용되는 측정항목, 원래 클러스터 크기, 새 대상 클러스터 크기를 확인합니다.

autoscaling-recommendation-message

자주 묻는 질문(FAQ)

고가용성 클러스터 및 단일 노드 클러스터에서 자동 확장을 사용할 수 있나요?

고가용성 클러스터에서는 자동 확장을 사용할 수 있지만 단일 노드 클러스터에서는 사용할 수 없습니다(단일 노드 클러스터는 크기 조정을 지원하지 않음).

자동 확장 클러스터의 크기를 수동으로 조절할 수 있나요?

예 자동 확장 정책을 조정할 때는 임시방편으로 클러스터를 수동으로 조절할 수 있습니다. 하지만 이러한 변경은 일시적으로만 영향을 미치며 결국에는 자동 확장이 클러스터를 다시 조정합니다.

클러스터의 크기를 수동으로 조절하는 대신 다음을 고려해보세요.

자동 확장 정책을 업데이트합니다. 자동 확장 정책 변경 사항은 현재 정책을 사용 중인 모든 클러스터에 적용됩니다.(멀티 클러스터 정책 사용 참조).

정책을 분리하고 클러스터를 원하는 크기로 수동 확장합니다.

Dataproc 지원을 받습니다.

어떤 이미지 버전과 API 버전에서 자동 확장이 지원되나요?

자동 확장은 클러스터 이미지 버전 1.0.99+, 1.1.90+, 1.2.22+, 1.3.0+, 1.4.0+에서 v1 API(Cloud Dataproc 버전 목록 참조)를 통해 그리고 gcloud dataproc autoscaling-policies 명령어를 통해 지원됩니다.

Dataproc은 Dataflow 자동 확장과 어떻게 다른가요?

Cloud Dataflow 자동 확장과 Spark 및 Hadoop 비교를 참조하세요.