환경 성능 및 비용 최적화

Cloud Composer 1 | Cloud Composer 2

이 페이지에서는 프로젝트의 요구사항에 맞게 환경의 규모와 성능 매개변수를 조정하여 성능을 개선하고 환경에서 활용되지 않은 리소스에 대한 비용을 줄이는 방법을 설명합니다.

확장 및 최적화에 대한 다른 페이지:

최적화 프로세스 개요

환경 매개변수를 변경하면 환경 성능의 여러 측면에 영향을 줄 수 있습니다. 반복 작업을 통해 환경을 최적화하는 것이 좋습니다.

  1. 환경 사전 설정을 시작합니다.
  2. DAG를 실행합니다.
  3. 환경 성능을 관찰합니다.
  4. 환경 규모 및 성능 매개변수를 조정한 다음 이전 단계를 반복합니다.

환경 사전 설정 시작

Google Cloud Console에서 환경을 만들 때 세 가지 환경 사전 설정 중 하나를 선택할 수 있습니다. 이러한 사전 설정은 환경의 초기 규모 및 성능 구성을 설정합니다. 환경을 만든 후에는 사전 설정된 모든 규모 및 성능 매개변수를 변경할 수 있습니다.

다음 추정치를 기반으로 사전 설정 중 하나를 시작하는 것이 좋습니다.

  • 환경에 배포하려는 총 DAG 수
  • 최대 동시 실행 DAG 수
  • 최대 동시 실행 태스크 수

환경 성능은 환경에서 실행되는 특정 DAG 구현에 따라 달라집니다. 다음 표에는 평균 리소스 소비를 기준으로 한 추정치가 나열되어 있습니다. DAG가 더 많은 리소스를 소비할 것으로 예상되면 이에 맞게 추정치를 조정합니다.

권장되는 사전 설정 총 DAG 수 최대 동시 실행 DAG 수 최대 동시 실행 태스크 수
작게 50 15 18
보통 250 60 100
크게 1000 250 400

예를 들어 환경에서 40개의 DAG를 실행해야 합니다. 모든 DAG는 각각 하나의 활성 태스크를 포함하여 동시에 실행되어야 합니다. 최대 동시 실행 DAG와 태스크 수가 소형 사전 설정의 권장 추정치를 초과하기 때문에 이 환경에서는 중간 사전 설정을 사용합니다.

DAG 실행

환경이 생성되면 DAG를 업로드합니다. DAG를 실행하고 환경의 성능을 관찰합니다.

DAG의 실제 애플리케이션을 반영하는 일정에 따라 DAG를 실행하는 것이 좋습니다. 예를 들어 여러 DAG를 동시에 실행하려면 이러한 DAG가 모두 동시에 실행될 때 환경의 성능을 확인해야 합니다.

환경 성능 관찰

이 섹션에서는 가장 일반적인 Cloud Composer 2 용량과 성능 미세 조정 측면을 중점적으로 설명합니다. 가장 일반적인 성능 고려사항을 먼저 다루기 때문에 이 가이드를 단계별로 따르는 것이 좋습니다.

Monitoring 대시보드로 이동

환경의 Monitoring 대시보드에서 환경의 성능 측정항목을 모니터링할 수 있습니다.

환경의 Monitoring 대시보드로 이동하려면 다음 안내를 따르세요.

  1. Google Cloud Console에서 환경 페이지로 이동합니다.

    환경으로 이동

  2. 환경 이름을 클릭합니다.

  3. Monitoring 탭으로 이동합니다.

스케줄러 CPU 및 메모리 측정항목 모니터링

Airflow 스케줄러의 CPU 및 메모리 측정항목은 스케줄러의 성능이 전체 Airflow 성능에서 병목 현상인지 여부를 확인하는 데 도움이 됩니다.

Ariflow 스케줄러 그래프
그림 1. Airflow 스케줄러 그래프 (확대하려면 클릭)

Monitoring 대시보드의 스케줄러 섹션에서 환경의 Airflow 스케줄러 그래프를 관찰합니다.

  • 총 스케줄러 CPU 사용량
  • 총 스케줄러 메모리 사용량

관찰 결과에 따라 조정합니다.

모든 DAG 파일의 총 파싱 시간 모니터링

스케줄러는 DAG 실행을 예약하기 전에 DAG를 파싱합니다. DAG가 파싱하는 데 시간이 오래 걸리면 스케줄러의 용량이 소비되고 DAG 실행 성능이 저하될 수 있습니다.

총 DAG 파싱 시간 그래프
그림 2. DAG 파싱 시간 그래프(확대하려면 클릭)

Monitoring 대시보드의 DAG 통계 섹션에서 총 DAG 파싱 시간의 그래프를 관찰합니다.

시간이 약 10초를 초과하면 스케줄러가 DAG 파싱으로 과부하되어 DAG를 효과적으로 실행할 수 없습니다. Airflow의 기본 DAG 파싱 빈도는 30초입니다. DAG 파싱 시간이 이 임곗값을 초과하면 파싱 주기가 겹치기 시작하므로 스케줄러의 용량이 소진됩니다.

관찰 결과에 따라 다음을 수행할 수 있습니다.

작업자 포드 제거 모니터링

포드 제거는 환경 클러스터의 특정 포드가 리소스 한도에 도달하면 발생할 수 있습니다.

작업자 포드 제거 그래프
그림 3. 작업자 포드 제거를 표시하는 그래프(확대하려면 클릭)

Airflow 작업자 포드가 제거되면 해당 포드에서 실행 중인 모든 태스크 인스턴스가 중단되고 나중에 Airflow에서 실패로 표시됩니다.

작업자 포드 제거와 관련된 대부분의 문제는 작업자의 메모리 부족 문제로 인해 발생합니다.

Monitoring 대시보드의 작업자 섹션에서 환경의 작업자 포드 제거 그래프를 관찰합니다.

총 작업자 메모리 사용량 그래프는 환경의 전체 관점을 보여줍니다. 단일 작업자는 메모리 사용률이 환경 수준에서 정상인 경우에도 메모리 한도를 초과할 수 있습니다.

관찰 결과에 따라 다음을 수행할 수 있습니다.

활성 작업자 모니터링

환경의 작업자 수는 큐의 태스크 수에 따라 자동으로 확장됩니다.

활성 작업자 및 큐의 태스크 그래프
그림 4. 활성 작업자 및 큐의 태스크 그래프(확대하려면 클릭)

Monitoring 대시보드의 작업자 섹션에서 활성 작업자 수 및 큐의 태스크 수 그래프를 관찰합니다.

  • 활성 작업자
  • Airflow 태스크

관찰 결과에 따라 조정합니다.

  • 환경이 작업자의 최대 한도에 자주 도달하고 동시에 Celery 큐의 태스크 작업 수가 계속 높으면 최대 작업자 수를 늘려야 할 수 있습니다.

  • 태스크 간 예약 지연 시간이 길지만 동시에 환경이 최대 작업자 수까지 확장되지 않으면 실행을 제한하고 Cloud Composer 메커니즘이 환경을 확장하지 못하게 하는 Airflow 설정이 있을 수 있습니다. Cloud Composer 2 환경은 Celery 큐의 태스크 수에 따라 확장되므로 큐로 이동하는 동안 태스크를 제한하지 않도록 Airflow를 구성하세요.

    • 작업자 동시 실행을 늘립니다. 작업자 동시 실행은 예상 최대 동시 실행 태스크 수를 환경의 최대 작업자 수로 나눈 값보다 큰 값으로 설정해야 합니다.
    • 단일 DAG가 동시에 많은 수의 태스크를 실행하는 경우 DAG 동시 실행을 늘리면 DAG당 최대 실행 태스크 인스턴스 수에 도달할 수 있습니다.
    • 동일한 DAG를 동시에 여러 번 실행하는 경우 DAG당 최대 활성 실행을 늘리면 DAG당 최대 활성 실행 제한에 도달하므로 Airflow가 실행을 제한할 수 있습니다.

작업자 CPU 및 메모리 사용량 모니터링

환경의 모든 작업자에게서 집계된 총 CPU 및 메모리 사용량을 모니터링하여 Airflow 작업자가 환경의 리소스를 올바르게 사용하는지 확인합니다.

작업자 CPU 및 메모리 그래프
그림 5. 작업자 CPU 및 메모리 그래프(확대하려면 클릭)

Monitoring 대시보드의 작업자 섹션에서 Airflow 작업자의 CPU 및 메모리 사용량 그래프를 관찰합니다.

  • 총 작업자 CPU 사용량
  • 총 작업자 메모리 사용량

이 그래프는 집계된 리소스 사용량을 나타냅니다. 집계 뷰에 여유 용량이 표시되더라도 개별 작업자가 용량 한도에 도달할 수 있습니다.

관찰 결과에 따라 조정합니다.

실행 및 큐에 추가된 태스크 모니터링

큐에 추가되었거나 실행 중인 태스크 수를 모니터링하여 예약 프로세스의 효율성을 확인할 수 있습니다.

실행 및 큐에 추가된 태스크를 표시하는 그래프
그림 6. 실행 및 큐에 추가된 태스크를 표시하는 그래프(확대하려면 클릭)

Monitoring 대시보드의 작업자 섹션에서 환경의 Airflow 태스크 그래프를 관찰합니다.

큐의 태스크는 작업자가 실행될 때까지 대기합니다. 환경에 큐에 추가된 태스크가 있으면 환경의 작업자가 다른 태스크를 실행 중임을 의미합니다.

일부 큐는 특히 처리량이 가장 많을 때 환경에 항상 존재합니다. 하지만 큐에 추가된 태스크가 많거나 그래프에서 증가 추세가 관찰된다면 작업자의 용량이 태스크를 처리할 만큼 충분하지 않거나 Airflow가 태스크 실행을 제한하고 있을 수 있습니다.

실행 중인 태스크의 수도 최대 수준에 도달하면 일반적으로 큐에 추가된 태스크가 많이 관찰됩니다.

이 두 가지 문제를 모두 해결하려면 다음 안내를 따르세요.

데이터베이스 CPU 및 메모리 사용량 모니터링

Airflow 데이터베이스 성능 문제로 인해 전체 DAG 실행 문제가 발생할 수 있습니다. 필요에 따라 스토리지가 자동으로 확장되므로 데이터베이스 디스크 사용량은 일반적으로 문제가 되지 않습니다.

데이터베이스 CPU 및 메모리 그래프
그림 7. 데이터베이스 CPU 및 메모리 그래프(확대하려면 클릭)

Monitoring 대시보드의 작업자 섹션에서 Airflow 데이터베이스의 CPU 및 메모리 사용량 그래프를 관찰합니다.

  • 데이터베이스 CPU 사용량
  • 데이터베이스 메모리 사용량

데이터베이스 CPU 사용량이 총 시간의 몇 분 이상 80%를 초과하는 경우 데이터베이스에 과부하가 발생하므로 확장해야 합니다.

데이터베이스 크기 설정은 환경의 환경 크기 속성에 따라 제어됩니다. 데이터베이스를 확장하거나 축소하려면 환경 크기를 다른 등급(소형, 중간 또는 대형)으로 변경하세요. 환경 크기를 늘리면 환경의 비용이 증가합니다.

태스크 예약 지연 시간 모니터링

태스크 간의 지연 시간이 예상 수준(예: 20초 이상)을 초과하면 환경에서 DAG 실행에 의해 생성된 태스크 부하를 처리할 수 없음을 나타냅니다.

태스크 지연 시간 그래프(Airflow UI)
그림 8. 태스크 지연 시간 그래프, Airflow UI(확대하려면 클릭)

환경의 Airflow UI에서 태스크 예약 지연 시간 그래프를 볼 수 있습니다.

이 예시에서 지연(2.5초 및 3.5초)은 허용 가능한 한도 내에 있지만 지연 시간이 훨씬 길면 다음을 의미할 수 있습니다.

웹 서버 CPU 및 메모리 모니터링

Airflow 웹 서버 성능은 Airflow UI에 영향을 줍니다. 웹 서버에 과부하가 발생하는 것은 일반적이지 않습니다. 이 경우 Airflow UI 성능이 저하될 수 있지만 DAG 실행의 성능에는 영향을 미치지 않습니다.

웹 서버 CPU 및 메모리 그래프
그림 9. 웹 서버 CPU 및 메모리 그래프(확대하려면 클릭)

Monitoring 대시보드의 웹 서버 섹션에서 Airflow 웹 서버의 그래프를 관찰합니다.

  • 웹 서버 CPU 사용량
  • 웹 서버 메모리 사용량

관찰 결과에 따라 조정합니다.

환경의 규모 및 성능 매개변수 조정

스케줄러 수 변경

스케줄러 수를 조정하면 스케줄러 용량과 Airflow 예약의 복원력이 향상됩니다.

스케줄러 수를 늘리면 Airflow 데이터베이스를 오가는 트래픽이 증가합니다. 대부분의 시나리오에서 Airflow 스케줄러 두 개를 사용하는 것이 좋습니다. 3개 이상의 스케줄러를 사용하는 것은 드물게 특별한 고려사항이 필요한 경우에만 필요합니다.

더 빠른 스케줄링이 필요한 경우:

예:

Console

스케줄러 수 조정의 단계에 따라 환경에 필요한 스케줄러 수를 설정합니다.

gcloud

스케줄러 수 조정의 단계에 따라 환경에 필요한 스케줄러 수를 설정합니다.

다음 예시에서는 스케줄러 수를 2로 설정합니다.

gcloud composer environments update example-environment \
    --scheduler-count=2

Terraform

스케줄러 수 조정의 단계에 따라 환경에 필요한 스케줄러 수를 설정합니다.

다음 예시에서는 스케줄러 수를 2로 설정합니다.

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      scheduler {
        count = 2
      }
    }
  }
}

스케줄러의 CPU 및 메모리 변경

CPU 및 메모리 매개변수는 환경의 각 스케줄러에 사용됩니다. 예를 들어 환경에 2개의 스케줄러가 있으면 총 용량은 지정된 CPU 및 메모리 수의 2배가 됩니다.

Console

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 스케줄러의 CPU 및 메모리를 설정합니다.

gcloud

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 스케줄러의 CPU 및 메모리를 설정합니다.

다음 예시에서는 스케줄러의 CPU 및 메모리를 변경합니다. 필요에 따라 CPU 또는 메모리 속성만 지정할 수 있습니다.

gcloud composer environments update example-environment \
  --scheduler-cpu=0.5 \
  --scheduler-memory=3.75

Terraform

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 스케줄러의 CPU 및 메모리를 설정합니다.

다음 예시에서는 스케줄러의 CPU 및 메모리를 변경합니다. 필요에 따라 CPU 또는 메모리 속성을 생략할 수 있습니다.

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      scheduler {
        cpu = "0.5"
        memory_gb = "3.75"
      }
    }
  }
}

최대 작업자 수 변경

최대 작업자 수를 늘리면 필요한 경우 환경에서 더 많은 작업자 수로 자동 확장할 수 있습니다.

최대 작업자 수를 줄이면 환경의 최대 용량이 줄어들지만 환경 비용을 줄이는 데도 도움이 될 수 있습니다.

예를 들면 다음과 같습니다.

Console

최소 및 최대 작업자 수 조정의 단계에 따라 환경에 필요한 최대 작업자 수를 설정합니다.

gcloud

최소 및 최대 작업자 수 조정의 단계에 따라 환경에 필요한 최대 작업자 수를 설정합니다.

다음 예시에서는 최대 작업자 수를 6으로 설정합니다.

gcloud composer environments update example-environment \
    --max-workers=6

Terraform

최소 및 최대 작업자 수 조정의 단계에 따라 환경에 필요한 최대 작업자 수를 설정합니다.

다음 예시에서는 최대 스케줄러 수를 6으로 설정합니다.

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      worker {
        max_count = "6"
      }
    }
  }
}

작업자 CPU 및 메모리 변경

  • 작업자 사용량 그래프가 매우 낮은 메모리 사용률을 나타낼 때 작업자 메모리를 줄이는 것이 도움이 될 수 있습니다.

  • 작업자 메모리를 늘리면 작업자가 더 많은 태스크를 동시에 처리하거나 메모리 집약적인 태스크를 처리할 수 있습니다. 이렇게 하면 작업자 포드 제거 문제가 해결될 수 있습니다.

  • 작업자 CPU 사용량 그래프가 CPU 리소스의 과도한 초과 할당을 나타낼 때 작업자 CPU를 줄이는 것이 도움이 될 수 있습니다.

  • 작업자 CPU를 늘리면 작업자가 더 많은 태스크를 동시에 처리하고 경우에 따라 이러한 태스크를 처리하는 데 걸리는 시간을 줄일 수 있습니다.

작업자 CPU 또는 메모리를 변경하면 작업자가 다시 시작되며, 이로 인해 실행 중인 작업이 영향을 받을 수 있습니다. DAG가 실행 중이 아닐 때 이 변경사항을 구현하는 것이 좋습니다.

CPU 및 메모리 매개변수는 환경의 각 작업자에 사용됩니다. 예를 들어 환경에 4개의 작업자가 있으면 총 용량은 지정된 CPU 및 메모리 수의 4배가 됩니다.

Console

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 작업자의 CPU 및 메모리를 설정합니다.

gcloud

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 작업자의 CPU 및 메모리를 설정합니다.

다음 예시에서는 작업자의 CPU 및 메모리를 변경합니다. 필요한 경우 CPU 또는 메모리 속성을 생략할 수 있습니다.

gcloud composer environments update example-environment \
  --worker-memory=3.75 \
  --worker-cpu=2

Terraform

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 작업자의 CPU 및 메모리를 설정합니다.

다음 예시에서는 작업자의 CPU 및 메모리를 변경합니다. 필요한 경우 CPU 또는 메모리 매개변수를 생략할 수 있습니다.

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      worker {
        cpu = "2"
        memory_gb = "3.75"
      }
    }
  }
}

웹 서버 CPU 및 메모리 변경

웹 서버 사용량 그래프가 지속적으로 낮은 활용도를 나타날 때 웹 서버 CPU 또는 메모리를 줄이는 것이 도움이 될 수 있습니다.

웹 서버 매개변수를 변경하면 웹 서버가 다시 시작되며, 이로 인해 일시적인 웹 서버 다운타임이 발생할 수 있습니다. 정규 사용 시간이 아닐 때 변경하는 것이 좋습니다.

Console

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 웹 서버의 CPU 및 메모리를 설정합니다.

gcloud

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 웹 서버의 CPU 및 메모리를 설정합니다.

다음 예시에서는 웹 서버의 CPU와 메모리를 변경합니다. 필요에 따라 CPU 또는 메모리 속성을 생략할 수 있습니다.

gcloud composer environments update example-environment \
    --web-server-cpu=2 \
    --web-server-memory=3.75

Terraform

작업자, 스케줄러, 웹 서버 확장, 성능 매개변수 조정의 단계에 따라 웹 서버의 CPU 및 메모리를 설정합니다.

다음 예시에서는 웹 서버의 CPU와 메모리를 변경합니다. 필요에 따라 CPU 또는 메모리 속성을 생략할 수 있습니다.

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      web_server {
        cpu = "2"
        memory_gb = "3.75"
      }
    }
  }
}

환경 크기 변경

환경 크기를 변경하면 Airflow 데이터베이스와 Airflow 큐와 같은 Cloud Composer 백엔드 구성요소의 용량이 수정됩니다.

  • 데이터베이스 사용량 측정항목이 상당히 낮은 사용률을 나타내면 환경 크기를 더 작은 크기(예: 대형에서 중형, 중형에서 소형)로 변경하는 것이 좋습니다.

  • Airflow 데이터베이스의 사용량이 많은 경우 환경 크기를 늘려보세요.

Console

환경 크기 조정의 단계에 따라 환경 크기를 설정합니다.

gcloud

환경 크기 조정의 단계에 따라 환경 크기를 설정합니다.

다음 예시에서는 환경 크기를 중형으로 변경합니다.

gcloud composer environments update example-environment \
    --environment-size=medium

Terraform

환경 크기 조정의 단계에 따라 환경 크기를 설정합니다.

다음 예시에서는 환경 크기를 중형으로 변경합니다.

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    environment_size = "medium"
  }
}

DAG 디렉터리 등록 간격 변경

DAG 디렉터리 등록 간격을 늘리면 환경의 버킷에서 새 DAG의 검색과 관련된 스케줄러 부하가 줄어듭니다.

  • 새 DAG를 자주 배포하지 않으면 이 간격을 늘려보세요.
  • Airflow가 새로 배포된 DAG 파일에 더 빠르게 반응하도록 하려면 이 간격을 줄여보세요.

이 매개변수를 변경하려면 다음 Airflow 구성 옵션을 재정의합니다.

섹션 키 값 참고
scheduler dag_dir_list_interval 등록 간격의 새 값 기본값은 120초입니다.

DAG 파일 파싱 간격 변경

DAG 파일 파싱 간격을 늘리면 DAG 모음의 DAG를 지속적으로 파싱하는 것과 관련된 스케줄러 부하가 줄어듭니다.

DAG 수가 너무 많아 자주 변경되지 않거나 일반적으로 스케줄러 부하가 높은 경우 이 간격을 늘리는 것이 좋습니다.

이 매개변수를 변경하려면 다음 Airflow 구성 옵션을 재정의합니다.

섹션 키 값 참고
scheduler min_file_process_interval DAG 파싱 간격의 새 값 기본값은 30초입니다.

작업자 동시 실행

동시 실행 성능과 환경의 자동 확장 기능은 다음과 같은 두 가지 설정에 연결됩니다.

  • 최소 Airflow 작업자 수
  • [celery]worker_concurrency 매개변수

Cloud Composer에서 제공하는 기본값은 대부분의 사용 사례에 적합하지만 사용자 환경에서 커스텀 조정의 이점을 활용할 수 있습니다.

작업자 동시 실행 성능 고려사항

[celery]worker_concurrency 매개변수는 단일 작업자가 태스크 큐에서 선택할 수 있는 태스크 수를 정의합니다. 태스크 실행 속도는 작업자 CPU, 메모리, 작업 유형 자체와 같은 여러 요소에 따라 달라집니다.

작업자 자동 확장

Cloud Composer는 태스크 큐를 모니터링하고 대기 태스크를 선택할 추가 작업자를 생성합니다. [celery]worker_concurrency를 높은 값으로 설정하면 모든 작업자가 많은 태스크를 선택할 수 있으므로 특정 상황에서는 큐가 가득 차지 않고 자동 확장이 트리거되지 않을 수 있습니다.

예를 들어 [celery]worker_concurrency가 100으로 설정되어 있고 큐에 태스크 200개가 있는 Airflow 작업자 2개가 있는 Cloud Composer 환경에서 각 작업자는 100개의 태스크를 선택합니다. 이렇게 하면 큐가 비어 있게 되고 자동 확장이 트리거되지 않습니다. 이러한 태스크를 완료하는 데 시간이 오래 걸릴 경우 성능 문제가 발생할 수 있습니다.

그러나 태스크가 작으며 빠르게 실행할 수 있는 경우 [celery]worker_concurrency 설정의 값이 높으면 확장이 과도하게 발생할 수 있습니다. 예를 들어 환경의 큐에 300개의 태스크가 있으면 Cloud Composer가 새 작업자를 만들기 시작합니다. 그러나 처음 200개의 태스크가 새 작업자가 준비될 때까지 실행을 완료하면 기존 작업자가 태스크를 선택할 수 있습니다. 그 결과 자동 확장이 새 작업자를 생성하지만 새 작업자가 수행할 태스크가 없습니다.

특수한 경우 [celery]worker_concurrency는 최대 태스크 실행 시간과 큐 번호를 기반으로 조정해야 합니다.

  • 완료하는 데 시간이 오래 걸리는 태스크의 경우 작업자가 큐를 완전히 비울 수 없어야 합니다.
  • 더 빠르고 작은 태스크를 수행하려면 최소 규모의 Airflow 작업자 수를 늘려 과도하게 확장되지 않도록 합니다.

태스크 로그 동기화

Airflow 작업자는 태스크 실행 로그를 Cloud Storage 버킷에 동기화하는 구성요소를 제공합니다. 단일 작업자가 수행하는 동시 태스크가 많으면 동기화 요청이 증가합니다. 이로 인해 작업자에 과부하가 발생하고 성능 문제가 발생할 수 있습니다.

로그 동기화 트래픽 수가 많아서 성능 문제가 발생하는 경우 [celery]worker_concurrency 값을 낮추고 최소 Airflow 작업자 수를 대신 조정합니다.

작업자 동시 실행 변경

이 매개변수를 변경하면 단일 작업자가 동시에 실행할 수 있는 태스크 수가 조정됩니다.

예를 들어 CPU가 0.5개인 작업자는 일반적으로 6개의 동시 실행 태스크를 처리할 수 있습니다. 이러한 작업자가 3개인 환경은 최대 18개의 동시 실행 태스크를 처리할 수 있습니다.

  • 큐에서 대기 중인 태스크가 있고 작업자가 동시에 CPU와 메모리를 적게 사용하면 이 매개변수를 늘립니다.

  • 포드 제거가 발생하면 이 매개변수를 줄입니다. 이렇게 하면 단일 작업자가 처리하려고 하는 태스크 수가 줄어듭니다. 대신 작업자 메모리를 늘릴 수 있습니다.

작업자 동시 실행의 기본값은 다음과 같습니다.

  • Airflow 2.6.3 이상 버전에서는 32, 12 * worker_CPU, 6 * worker_memory의 최솟값입니다.
  • Airflow 2.6.3 이전 버전에서는 32, 12 * worker_CPU, 8 * worker_memory의 최솟값입니다.
  • 2.3.3 이전의 Airflow 버전에서는 12 * worker_CPU입니다.

worker_CPU 값은 단일 작업자에 할당된 CPU 수입니다. worker_memory 값은 단일 작업자에 할당된 메모리 양입니다. 예를 들어 사용자 환경의 작업자가 각각 CPU 0.5개 및 메모리 4GB를 사용하는 경우 작업자 동시 실행 값이 6으로 설정됩니다. 작업자 동시 실행 값은 사용자 환경의 작업자 수에 따라 달라지지 않습니다.

이 매개변수를 변경하려면 다음 Airflow 구성 옵션을 재정의합니다.

섹션 키 값
celery worker_concurrency 작업자 동시 실행의 새 값

DAG 동시 실행 변경

DAG 동시 실행은 각 DAG에서 동시에 실행할 수 있는 최대 작업 인스턴스 수를 정의합니다. DAG가 많은 수의 동시 작업을 실행할 때 증가시킵니다. 이 설정이 낮으면 스케줄러가 큐에 더 많은 태스크를 넣기 때문에 환경 자동 확장 효율이 저하됩니다.

이 매개변수를 변경하려면 다음 Airflow 구성 옵션을 재정의합니다.

섹션 키 값 참고
core max_active_tasks_per_dag DAG 동시 실행의 새 값 기본값은 16입니다.

DAG당 최대 활성 실행 수 증가

이 속성은 DAG당 최대 활성 DAG 실행 수를 정의합니다. 예를 들어 입력 인수가 다를 때 동일한 DAG를 동시에 여러 번 실행해야 하는 경우 이 속성은 스케줄러가 해당 실행을 동시에 시작할 수 있도록 허용합니다.

이 매개변수를 변경하려면 다음 Airflow 구성 옵션을 재정의합니다.

섹션 키 값 참고
core max_active_runs_per_dag DAG당 최대 활성 실행 수의 새 값 기본값은 25입니다.

다음 단계