Cloud Composer 1은 사후 유지보수 모드 상태입니다. Google은 Airflow의 새 버전, 버그 수정, 보안 업데이트를 비롯한 Cloud Composer 1 추가 업데이트를 출시하지 않습니다. Cloud Composer 2로 마이그레이션하는 것이 좋습니다.

Cloud Composer 환경 만들기

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

이 페이지에서는 Cloud Composer 환경을 만드는 방법을 설명합니다.

환경에 대한 자세한 내용은 환경 아키텍처를 참조하세요.
Terraform을 사용하여 환경을 만드는 방법에 대한 자세한 내용은 환경 만들기(Terraform)를 참조하세요.

시작하기 전에

Cloud Composer API를 사용 설정합니다. Cloud Composer에서 사용하는 서비스의 전체 목록은 Cloud Composer에 필요한 서비스를 참조하세요.
환경을 만드는 데 걸리는 시간은 약 25분입니다.

환경을 만드는 동안 서비스 계정을 지정합니다. Cloud Composer는 환경 클러스터의 Kubernetes 서비스 계정에 이 계정을 바인딩합니다.

기본적으로 Cloud Composer 환경은 Google 관리형 기본 Compute Engine 서비스 계정을 사용합니다. Cloud Composer 관련 역할이 있는 사용자 관리형 서비스 계정을 만들고 사용자 환경에 사용하는 것이 좋습니다.

참고: 과거에 Cloud Composer 사용자는 서비스 계정 명의 도용 권한이 없더라도 서비스 계정으로 인증된 Cloud Composer 애플리케이션을 배포할 수 있었습니다. 이러한 기존 동작은 일부 조직에 여전히 영향을 줍니다. 자세한 내용은 서비스 계정을 리소스에 연결할 때 가장 권한 필요를 참조하세요.

Terraform으로 환경을 만드는 경우 Terraform에서 사용하는 서비스 계정에는 composer.environments.create 권한이 사용 설정된 역할이 있어야 합니다.

Terraform의 서비스 계정에 대한 자세한 내용은 Google 제공업체 구성 참조를 확인하세요.

Terraform을 사용하여 Cloud Composer 환경을 만드는 방법에 대한 자세한 내용은 Terraform 문서를 참조하세요.

추가 매개변수에 대한 자세한 내용은 Terraform 인수 참조를 확인하세요.
비공개 IP: 비공개 IP 환경을 만들 때 적용되는 특정 네트워크 및 피어링 요구사항이 있습니다. 자세한 내용은 비공개 IP 구성을 참조하세요.
공유 VPC: Cloud Composer에서 공유 VPC를 사용할 때 적용되는 특정 네트워크 요구사항이 있습니다. 자세한 내용은 공유 VPC 구성을 참조하세요.
VPC SC: 보안 경계 내에 Cloud Composer 환경을 배포하려면 VPC SC 구성을 참조하세요. Cloud Composer와 함께 사용하는 경우 VPC 서비스 제어에 몇 가지 알려진 제한사항이 있습니다.

1단계: 기본 설정

이 단계에서는 지정된 위치에 기본 매개변수로 Cloud Composer 환경을 만듭니다.

콘솔

Google Cloud 콘솔에서 환경 만들기 페이지로 이동합니다.

환경 만들기로 이동
이름 필드에 환경 이름을 입력합니다.

이름은 소문자로 시작해야 합니다. 이어서 최대 62자(영문 기준)의 소문자, 숫자 또는 하이픈이 와야 하며 하이픈으로 끝나서는 안 됩니다 환경 이름은 환경의 하위 구성요소를 만드는 데 사용되므로 Cloud Storage 버킷 이름으로도 유효한 이름으로 지정해야 합니다. 제한사항 목록은 버킷 이름 지정 가이드라인을 참조하세요.
위치 드롭다운 목록에서 환경의 위치를 선택합니다.

위치는 환경이 위치한 리전입니다.
이미지 버전 드롭다운 목록에서 필요한 버전의 Airflow가 포함된 Cloud Composer 이미지를 선택합니다.

gcloud

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version IMAGE_VERSION

다음과 같이 바꿉니다.

ENVIRONMENT_NAME을 환경 이름으로 바꿉니다.

이름은 소문자로 시작해야 합니다. 이어서 최대 62자(영문 기준)의 소문자, 숫자 또는 하이픈이 와야 하며 하이픈으로 끝나서는 안 됩니다 환경 이름은 환경의 하위 구성요소를 만드는 데 사용되므로 Cloud Storage 버킷 이름으로도 유효한 이름으로 지정해야 합니다. 제한사항 목록은 버킷 이름 지정 가이드라인을 참조하세요.
LOCATION을 환경의 리전으로 바꿉니다.

위치는 환경이 위치한 리전입니다.
IMAGE_VERSION을 Cloud Composer 이미지 이름으로 바꿉니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3

API

environments.create API 요청을 생성합니다. Environment 리소스에서 구성을 지정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "softwareConfig": {
      "imageVersion": "IMAGE_VERSION"
    }
  }
}

다음과 같이 바꿉니다.

PROJECT_ID를 프로젝트 ID로 바꿉니다.
LOCATION을 환경의 리전으로 바꿉니다.

위치는 환경이 위치한 리전입니다.
ENVIRONMENT_NAME을 환경 이름으로 바꿉니다.

이름은 소문자로 시작해야 합니다. 이어서 최대 62자(영문 기준)의 소문자, 숫자 또는 하이픈이 와야 하며 하이픈으로 끝나서는 안 됩니다 환경 이름은 환경의 하위 구성요소를 만드는 데 사용되므로 Cloud Storage 버킷 이름으로도 유효한 이름으로 지정해야 합니다. 제한사항 목록은 버킷 이름 지정 가이드라인을 참조하세요.
IMAGE_VERSION을 Cloud Composer 이미지 이름으로 바꿉니다.

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

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "softwareConfig": {
      "imageVersion": "composer-2.9.7-airflow-2.9.3"
    }
  }
}

Terraform

기본 매개변수를 사용하여 환경을 만들려면 지정된 리소스 위치를 다음 Terraform 구성에 추가하고 terraform apply를 실행합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    software_config {
      image_version = "IMAGE_VERSION"
    }
  }
}

다음과 같이 바꿉니다.

ENVIRONMENT_NAME을 환경 이름으로 바꿉니다.

이름은 소문자로 시작해야 합니다. 이어서 최대 62자(영문 기준)의 소문자, 숫자 또는 하이픈이 와야 하며 하이픈으로 끝나서는 안 됩니다 환경 이름은 환경의 하위 구성요소를 만드는 데 사용되므로 Cloud Storage 버킷 이름으로도 유효한 이름으로 지정해야 합니다. 제한사항 목록은 버킷 이름 지정 가이드라인을 참조하세요.
LOCATION을 환경의 리전으로 바꿉니다.

위치는 환경이 위치한 리전입니다.
IMAGE_VERSION을 Cloud Composer 이미지 이름으로 바꿉니다.

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

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    software_config {
      image_version = "composer-2.9.7-airflow-2.9.3"
    }
  }
}

2단계: (선택사항) 환경의 서비스 계정 선택

Cloud Composer는 이 서비스 계정을 환경의 Kubernetes 서비스 계정에 바인딩합니다. 환경 클러스터의 노드는 Kubernetes 서비스 계정으로 실행되고 바인딩을 사용하여 환경 버킷의 DAG 정의 파일과 같은 Google Cloud 프로젝트의 리소스에 액세스합니다.

기본적으로 Cloud Composer 환경은 기본 Compute Engine 서비스 계정을 사용합니다. Cloud Composer 환경의 사용자 관리형 서비스 계정을 설정하는 것이 좋습니다.

나중에는 환경의 서비스 계정을 변경할 수 없습니다.

콘솔

환경 만들기 페이지의 서비스 계정 드롭다운 목록에서 환경의 서비스 계정을 선택합니다.

gcloud

환경을 만들 때 --service-account는 환경의 서비스 계정을 지정합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --service-account "SERVICE_ACCOUNT"

다음과 같이 바꿉니다.

SERVICE_ACCOUNT를 환경의 서비스 계정으로 바꿉니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --service-account "example-account@example-project.iam.gserviceaccount.com"

API

환경을 만들 때 환경 > EnvironmentConfig 리소스에 환경의 서비스 계정을 지정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
}

다음과 같이 바꿉니다.

SERVICE_ACCOUNT를 환경의 서비스 계정으로 바꿉니다.

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


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "nodeConfig": {
      "serviceAccount": "example-account@example-project.iam.gserviceaccount.com"
    }
  }
}

Terraform

환경을 만들 때 node_config 블록의 service_account 필드를 사용합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

다음과 같이 바꿉니다.

SERVICE_ACCOUNT를 환경의 서비스 계정으로 바꿉니다.

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

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    node_config {
      service_account = "example-account@example-project.iam.gserviceaccount.com"
    }
  }
}

3단계: Cloud Composer 서비스 계정에 필요한 권한 부여

프로젝트에서 Cloud Composer API를 사용 설정하면 프로젝트에 Composer 서비스 에이전트 계정이 생성됩니다. Cloud Composer는 이 계정을 사용하여 Google Cloud 프로젝트에서 작업을 수행합니다.

Cloud Composer v2 API 서비스 에이전트 확장 역할은 Cloud Composer 서비스 에이전트 계정에 추가 권한을 제공합니다. 이 역할은 자동으로 부여되지 않습니다. 직접 부여해야 합니다.

콘솔

프로젝트에서 환경을 만들 때 Cloud Composer 서비스 에이전트에 환경 서비스 계정에 필요한 권한이 없으면 Cloud Composer 서비스 계정에 필요한 권한 부여 섹션이 표시됩니다.

Cloud Composer 서비스 에이전트 계정을 환경 서비스 계정의 새 주 구성원으로 추가하고 Cloud Composer v2 API 서비스 에이전트 확장 역할을 부여합니다.

원하는 환경 서비스 계정을 사용하고 있는지 확인하고 부여를 클릭합니다.

gcloud

Cloud Composer 서비스 에이전트 계정을 환경 서비스 계정의 새 주 구성원으로 추가하고 Cloud Composer v2 API 서비스 에이전트 확장 역할을 부여합니다.

gcloud iam service-accounts add-iam-policy-binding \
    SERVICE_ACCOUNT \
    --member serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com \
    --role roles/composer.ServiceAgentV2Ext

다음과 같이 바꿉니다.

SERVICE_ACCOUNT를 환경의 서비스 계정으로 바꿉니다.
PROJECT_NUMBER를 프로젝트 번호로 바꿉니다.

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

gcloud iam service-accounts add-iam-policy-binding \
    example-account@example-project.iam.gserviceaccount.com \
    --member serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com \
    --role roles/composer.ServiceAgentV2Ext

API

역할을 부여하려면 읽기-수정-쓰기 패턴을 사용하여 기존 허용 정책을 수정해야 합니다.

환경 서비스 계정에 대한 기존 허용 정책을 읽습니다.
Cloud Composer 서비스 계정에 roles/composer.ServiceAgentV2Ext 역할이 포함되도록 수정합니다.
기존 허용 정책을 다시 작성합니다.

자세한 내용은 프로그래매틱 방식으로 액세스 제어를 참조하세요.

{
  "role": "roles/composer.ServiceAgentV2Ext",
  "members": [
    "serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com"
  ]
}

다음과 같이 바꿉니다.

PROJECT_NUMBER를 프로젝트 번호로 바꿉니다.

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

{
  "role": "roles/composer.ServiceAgentV2Ext",
  "members": [
    "serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com"
  ]
}

Terraform

환경 서비스 계정 허용 정책에 새 역할 바인딩을 추가합니다.

Cloud Composer 서비스 에이전트 계정을 환경 서비스 계정의 새 주 구성원으로 추가하고 Cloud Composer v2 API 서비스 에이전트 확장 역할을 부여합니다.

Terraform을 사용하여 환경 서비스 계정 허용 정책을 정의하지 않는 경우 다음 예시를 사용하지 마세요. 대신 다른 메서드를 사용하여 이 바인딩을 추가합니다.

resource "google_service_account_iam_member" "custom_service_account" {
  provider = google-beta
  service_account_id = "SERVICE_ACCOUNT"
  role = "roles/composer.ServiceAgentV2Ext"
  member = "serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com"
}

다음과 같이 바꿉니다.

SERVICE_ACCOUNT를 환경의 서비스 계정으로 바꿉니다.
PROJECT_NUMBER를 프로젝트 번호로 바꿉니다.

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

resource "google_service_account_iam_member" "custom_service_account" {
  provider = google-beta
  service_account_id = "example-account@example-project.iam.gserviceaccount.com"
  role = "roles/composer.ServiceAgentV2Ext"
  member = "serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com"
}

4단계: (선택사항) 환경 규모 및 성능 매개변수 구성

환경의 규모 및 성능 구성을 지정하려면 환경 크기 및 워크로드 구성을 선택합니다.

환경을 만든 후 모든 성능 및 규모 매개변수를 변경할 수 있습니다.

다음 매개변수는 규모 및 성능을 제어합니다.

환경 크기. Airflow 데이터베이스가 포함된 관리형 Cloud Composer 인프라의 성능 매개변수를 제어합니다. 인프라 성능이 우수한 DAG 및 태스크를 대량으로 실행하려는 경우에는 더 큰 환경 크기를 선택하는 것이 좋습니다. 예를 들어 환경 크기가 클수록 환경에서 최소 지연으로 처리할 수 있는 Airflow 태스크 로그 항목 양이 증가합니다.
워크로드 구성. Airflow 스케줄러, Airflow 웹 서버, Airflow 작업자와 같은 GKE 클러스터에서 실행되는 환경 구성요소의 규모 및 성능을 제어합니다.
- Airflow 스케줄러. DAG 정의 파일을 파싱하고, 일정 간격에 따라 DAG 실행을 예약하며, Airflow 작업자의 실행을 위해 태스크를 큐에 추가합니다.
  
  환경에서 동시에 2개 이상의 Airflow 스케줄러를 실행할 수 있습니다. 성능 및 안정성을 높이기 위해 여러 스케줄러를 사용하여 여러 스케줄러 인스턴스 사이에 부하를 분산합니다.
  
  스케줄러 수를 늘린다고 해서 항상 Airflow 성능이 향상되는 것은 아닙니다. 예를 들어 1개의 스케줄러만 사용하면 2개를 사용할 때보다 더 나은 성능을 제공할 수 있습니다. 스케줄러를 추가해도 전체 성능에 도움을 주지 않고 환경의 리소스만 소비될 때가 여기에 해당합니다. 실제 스케줄러 성능은 Airflow 작업자 수, 환경에서 실행되는 DAG 및 태스크 수, Airflow와 환경의 구성에 따라 다릅니다.
  
  2개의 스케줄러로 시작한 다음 환경의 성능을 모니터링하는 것이 좋습니다. 스케줄러 수를 변경한 후 언제든지 환경을 원래 스케줄러 수로 다시 조정할 수 있습니다.
  
  여러 스케줄러 구성에 대한 상세 설명은 Airflow 문서를 참조하세요.
- Airflow 트리거. 개발자 환경의 모든 지연된 태스크를 비동기적으로 모니터링합니다. 환경에 트리거 인스턴스가 1개 이상(또는 복원력이 우수한 환경에서는 2개 이상) 있다면 DAG에서 지연 가능한 연산자를 사용할 수 있습니다.
- Airflow 웹 서버. DAG를 모니터링, 관리, 시각화할 수 있는 Airflow 웹 인터페이스를 실행합니다.
- Airflow 작업자. Airflow 스케줄러에서 예약된 태스크를 실행합니다. 환경의 최소 및 최대 작업자 수는 큐의 태스크 수에 따라 동적으로 변경됩니다.

콘솔

환경의 사전 설정을 선택할 수 있습니다. 사전 설정을 선택하면 해당 사전 설정의 규모 및 성능 매개변수가 자동으로 선택됩니다. 커스텀 사전 설정을 선택하고 환경의 모든 규모 및 성능 매개변수를 지정할 수도 있습니다.

환경의 규모 및 성능 구성을 선택하려면 환경 만들기 페이지에서 다음을 수행합니다.

사전 정의된 값을 사용하려면 환경 리소스 섹션에서 소형, 중형, 대형을 클릭합니다.
규모 및 성능 매개변수에 커스텀 값을 지정하려면 다음 안내를 따르세요.
1. 환경 리소스 섹션에서 커스텀을 클릭합니다.
2. 스케줄러 섹션에서 사용할 스케줄러 수 및 CPU, 메모리, 스토리지의 리소스 할당을 설정합니다.
3. 트리거 섹션에서 트리거 수 필드를 사용하여 환경의 트리거 수를 입력합니다. DAG에서 지연 가능한 연산자를 사용하지 않으려면 이 숫자를 0으로 설정하면 됩니다.
  
  환경에 트리거를 최소 하나 이상 설정하는 경우 CPU 및 메모리 필드를 사용하여 트리거에 대한 리소스 할당을 구성합니다.
4. DAG 프로세서 섹션에서 환경의 DAG 프로세서 수와 각 DAG 프로세서의 CPU, 메모리, 스토리지 용량을 지정합니다.
5. 웹 서버 섹션에서 웹 서버의 CPU, 메모리, 스토리지 용량을 지정합니다.
6. 작업자 섹션에서 다음을 지정합니다.
  - 사용자 환경의 자동 확장 한도에 대한 최소 및 최대 작업자 수
  - 작업자의 CPU, 메모리, 스토리지 할당
7. 핵심 인프라 섹션의 환경 크기 드롭다운 목록에서 환경 크기를 선택합니다.

gcloud

환경을 만들 때 다음 인수는 환경의 규모와 성능 매개변수를 제어합니다.

--environment-size: 환경 크기를 지정합니다.
--scheduler-count: 스케줄러 수를 지정합니다.
--scheduler-cpu: Airflow 스케줄러의 CPU 수를 지정합니다.
--scheduler-memory: Airflow 스케줄러의 메모리 양을 지정합니다.
--scheduler-storage: Airflow 스케줄러의 디스크 공간 크기를 지정합니다.
--triggerer-count: 사용자 환경의 Airflow 트리거 수를 지정합니다. 이 플래그의 기본값은 0입니다. DAG에서 지연 가능한 연산자를 사용하려면 트리거가 필요합니다.
- 표준 복원력 환경의 경우 0에서 10 사이의 값을 사용합니다.
- 복원력이 우수한 환경의 경우 0을 사용하거나 2에서 10 사이의 값을 사용합니다.
--triggerer-cpu: Airflow 트리거의 CPU 수를 vCPU 단위로 지정합니다. 허용되는 값은 0.5, 0.75, 1입니다. 기본값은 0.5입니다.
--triggerer-memory: Airflow 트리거의 메모리 양(GB)을 지정합니다. 기본값은 0.5입니다.

필요한 최소 메모리는 트리거에 할당된 CPU 수와 동일합니다. 허용되는 최댓값은 트리거 CPU 수에 6.5를 곱한 값과 같습니다.

예를 들어 --triggerer-cpu 플래그를 1로 설정하면 --triggerer-memory의 최솟값은 1이고 최댓값은 6.5입니다.
--web-server-cpu: Airflow 웹 서버의 CPU 수를 지정합니다.
--web-server-memory: Airflow 웹 서버의 메모리 양을 지정합니다.
--web-server-storage: Airflow 웹 서버의 디스크 공간을 지정합니다.
--worker-cpu: Airflow 작업자의 CPU 수를 지정합니다.
--worker-memory: Airflow 작업자의 메모리 양을 지정합니다.
--worker-storage: Airflow :작업자에 대한 디스크 공간 크기를 지정합니다.
--min-workers: 최소 Airflow 작업자 수를 지정합니다. 환경 클러스터는 이 작업자 수를 최소한으로 잡아서 실행합니다.
--max-workers: 최대 Airflow 작업자 수를 지정합니다. 환경 클러스터는 이 작업자 수를 최대한으로 잡아서 실행합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --environment-size ENVIRONMENT_SIZE \
    --scheduler-count SCHEDULER_COUNT \
    --scheduler-cpu SCHEDULER_CPU \
    --scheduler-memory SCHEDULER_MEMORY \
    --scheduler-storage SCHEDULER_STORAGE \
    --triggerer-count TRIGGERER_COUNT \
    --triggerer-cpu TRIGGERER_CPU \
    --triggerer-memory TRIGGERER_MEMORY \
    --web-server-cpu WEB_SERVER_CPU \
    --web-server-memory WEB_SERVER_MEMORY \
    --web-server-storage WEB_SERVER_STORAGE \
    --worker-cpu WORKER_CPU \
    --worker-memory WORKER_MEMORY \
    --worker-storage WORKER_STORAGE \
    --min-workers WORKERS_MIN \
    --max-workers WORKERS_MAX

다음과 같이 바꿉니다.

ENVIRONMENT_SIZE: small, medium 또는 large입니다.
SCHEDULER_COUNT를 스케줄러 수로 바꿉니다.
SCHEDULER_CPU를 스케줄러의 CPU 수(vCPU 단위)로 바꿉니다.
SCHEDULER_MEMORY를 스케줄러의 메모리 양으로 바꿉니다.
SCHEDULER_STORAGE를 스케줄러의 디스크 크기로 바꿉니다.
TRIGGERER_COUNT를 트리거 수로 바꿉니다.
TRIGGERER_CPU를 트리거의 CPU 수(vCPU 단위)로 바꿉니다.
TRIGGERER_MEMORY를 트리거의 메모리 양(GB)으로 바꿉니다.
WEB_SERVER_CPU를 웹 서버의 CPU 수(vCPU 단위)로 바꿉니다.
WEB_SERVER_MEMORY를 웹 서버의 메모리 양으로 바꿉니다.
WEB_SERVER_STORAGE를 웹 서버의 메모리 양으로 바꿉니다.
WORKER_CPU를 작업자의 CPU 수(vCPU 단위)로 바꿉니다.
WORKER_MEMORY를 작업자의 메모리 양으로 바꿉니다.
WORKER_STORAGE를 작업자의 디스크 크기로 바꿉니다.
WORKERS_MIN를 환경에서 실행할 수 있는 최소 Airflow 작업자 수로 바꿉니다. 더 적은 작업자 수로 부하를 처리할 수 있어도 사용자 환경의 작업자 수는 이 수보다 적지 않습니다.
WORKERS_MAX를 환경에서 실행할 수 있는 최대 Airflow 작업자 수로 바꿉니다. 더 많은 작업자 수로 부하를 처리해야 하는 경우에도 사용자 환경의 작업자 수는 이 수보다 많지 않습니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --environment-size small \
    --scheduler-count 1 \
    --scheduler-cpu 0.5 \
    --scheduler-memory 2.5GB \
    --scheduler-storage 2GB \
    --triggerer-count 1 \
    --triggerer-cpu 0.5 \
    --triggerer-memory 0.5GB \
    --web-server-cpu 1 \
    --web-server-memory 2.5GB \
    --web-server-storage 2GB \
    --worker-cpu 1 \
    --worker-memory 2GB \
    --worker-storage 2GB \
    --min-workers 2 \
    --max-workers 4

API

환경을 만들 때 환경 > EnvironmentConfig > WorkloadsConfig 리소스에서 환경 규모와 성능 매개변수를 지정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "workloadsConfig": {
      "scheduler": {
        "cpu": SCHEDULER_CPU,
        "memoryGb": SCHEDULER_MEMORY,
        "storageGb": SCHEDULER_STORAGE,
        "count": SCHEDULER_COUNT
      },
      "triggerer": {
        "count": TRIGGERER_COUNT,
        "cpu": TRIGGERER_CPU,
        "memoryGb": TRIGGERER_MEMORY
      },
      "webServer": {
        "cpu": WEB_SERVER_CPU,
        "memoryGb": WEB_SERVER_MEMORY,
        "storageGb": WEB_SERVER_STORAGE
      },
      "worker": {
        "cpu": WORKER_CPU,
        "memoryGb": WORKER_MEMORY,
        "storageGb": WORKER_STORAGE,
        "minCount": WORKERS_MIN,
        "maxCount": WORKERS_MAX
      }
    },
    "environmentSize": "ENVIRONMENT_SIZE"
  }
}

다음과 같이 바꿉니다.

SCHEDULER_CPU를 스케줄러의 CPU 수(vCPU 단위)로 바꿉니다.
SCHEDULER_MEMORY를 스케줄러의 메모리 양(GB)으로 바꿉니다.
SCHEDULER_STORAGE를 스케줄러의 디스크 크기(GB)로 바꿉니다.
SCHEDULER_COUNT를 스케줄러 수로 바꿉니다.
TRIGGERER_COUNT를 트리거 수로 바꿉니다. 기본값은 0입니다. DAG에서 지연 가능한 연산자를 사용하려면 트리거가 필요합니다.
- 표준 복원력 환경의 경우 0에서 10 사이의 값을 사용합니다.
- 복원력이 우수한 환경의 경우 0을 사용하거나 2에서 10 사이의 값을 사용합니다.
트리거를 하나 이상 사용하는 경우 TRIGGERER_CPU 및 TRIGGERER_MEMORY 매개변수도 지정해야 합니다.
TRIGGERER_CPU는 트리거의 CPU 수(vCPU 단위)를 지정합니다. 허용되는 값은 0.5, 0.75, 1입니다.
TRIGGERER_MEMORY는 트리거의 메모리 양을 구성합니다. 필요한 최소 메모리는 트리거에 할당된 CPU 수와 동일합니다. 허용되는 최댓값은 트리거 CPU 수에 6.5를 곱한 값과 같습니다.

예를 들어 TRIGGERER_CPU를 1로 설정하면 TRIGGERER_MEMORY의 최솟값은 1이고 최댓값은 6.5입니다.
WEB_SERVER_CPU를 웹 서버의 CPU 수(vCPU 단위)로 바꿉니다.
WEB_SERVER_MEMORY를 웹 서버의 메모리 양(GB)으로 바꿉니다.
WEB_SERVER_STORAGE를 웹 서버의 디스크 크기(GB)로 바꿉니다.
WORKER_CPU를 작업자의 CPU 수(vCPU 단위)로 바꿉니다.
WORKER_MEMORY를 작업자의 메모리 양(GB)으로 바꿉니다.
WORKER_STORAGE를 작업자의 디스크 크기(GB)로 바꿉니다.
WORKERS_MIN를 환경에서 실행할 수 있는 최소 Airflow 작업자 수로 바꿉니다. 더 적은 작업자 수로 부하를 처리할 수 있어도 사용자 환경의 작업자 수는 이 수보다 적지 않습니다.
WORKERS_MAX를 환경에서 실행할 수 있는 최대 Airflow 작업자 수로 바꿉니다. 더 많은 작업자 수로 부하를 처리해야 하는 경우에도 사용자 환경의 작업자 수는 이 수보다 많지 않습니다.
ENVIRONMENT_SIZE를 환경 크기(ENVIRONMENT_SIZE_SMALL, ENVIRONMENT_SIZE_MEDIUM 또는 ENVIRONMENT_SIZE_LARGE)로 바꿉니다.

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

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "workloadsConfig": {
      "scheduler": {
        "cpu": 2.5,
        "memoryGb": 2.5,
        "storageGb": 2,
        "count": 1
      },
      "triggerer": {
        "cpu": 0.5,
        "memoryGb": 0.5,
        "count": 1
      },
      "webServer": {
        "cpu": 1,
        "memoryGb": 2.5,
        "storageGb": 2
      },
      "worker": {
        "cpu": 1,
        "memoryGb": 2,
        "storageGb": 2,
        "minCount": 2,
        "maxCount": 4
      }
    },
    "environmentSize": "ENVIRONMENT_SIZE_SMALL"
  }
}

Terraform

환경을 만들 때 다음 인수는 환경의 규모와 성능 매개변수를 제어합니다.

config 블록에 대한 설명은 다음과 같습니다.
- environment_size 필드는 환경 크기를 제어합니다.
workloads_config 블록에 대한 설명은 다음과 같습니다.
- scheduler.cpu 필드는 Airflow 스케줄러의 CPU 수를 지정합니다.
- scheduler.memory_gb 필드는 Airflow 스케줄러의 메모리 양을 지정합니다.
- scheduler.storage_gb 필드는 스케줄러의 디스크 공간 크기를 지정합니다.
- scheduler.count 필드는 환경의 스케줄러 수를 지정합니다.
- triggerer.cpu 필드는 Airflow 트리거의 CPU 수를 지정합니다.
- triggerer.memory_gb 필드는 Airflow 트리거의 메모리 양을 지정합니다.
- triggerer.count 필드는 환경의 트리거 수를 지정합니다.
- web_server.cpu 필드는 Airflow 웹 서버의 CPU 수를 지정합니다.
- web_server.memory_gb 필드는 Airflow 웹 서버의 메모리 양을 지정합니다.
- web_server.storage_gb 필드는 Airflow 웹 서버의 디스크 공간 크기를 지정합니다.
- worker.cpu 필드는 Airflow 작업자의 CPU 수를 지정합니다.
- worker.memory_gb 필드는 Airflow 작업자의 메모리 양을 지정합니다.
- worker.storage_gb 필드는 Airflow 작업자의 디스크 공간 크기를 지정합니다.
- worker.min_count 필드는 환경의 최소 작업자 수를 지정합니다.
- worker.max_count 필드는 환경의 최대 작업자 수를 지정합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    workloads_config {

      scheduler {
        cpu = SCHEDULER_CPU
        memory_gb = SCHEDULER_MEMORY
        storage_gb = SCHEDULER_STORAGE
        count = SCHEDULER_COUNT
      }
      triggerer {
        count = TRIGGERER_COUNT
        cpu = TRIGGERER_CPU
        memory_gb = TRIGGERER_MEMORY
      }
      web_server {
        cpu = WEB_SERVER_CPU
        memory_gb = WEB_SERVER_MEMORY
        storage_gb = WEB_SERVER_STORAGE
      }
      worker {
        cpu = WORKER_CPU
        memory_gb = WORKER_MEMORY
        storage_gb = WORKER_STORAGE
        min_count = WORKERS_MIN
        max_count = WORKERS_MAX
      }
    }

    environment_size = "ENVIRONMENT_SIZE"

  }
}

다음과 같이 바꿉니다.

ENVIRONMENT_NAME을 환경 이름으로 바꿉니다.
LOCATION을 환경이 위치한 리전으로 바꿉니다.
SCHEDULER_CPU를 스케줄러의 CPU 수(vCPU 단위)로 바꿉니다.
SCHEDULER_MEMORY를 스케줄러의 메모리 양(GB)으로 바꿉니다.
SCHEDULER_STORAGE를 스케줄러의 디스크 크기(GB)로 바꿉니다.
SCHEDULER_COUNT를 스케줄러 수로 바꿉니다.
TRIGGERER_COUNT를 트리거 수로 바꿉니다.
TRIGGERER_CPU를 트리거의 CPU 수(vCPU 단위)로 바꿉니다.
TRIGGERER_MEMORY를 트리거의 메모리 양(GB)으로 바꿉니다.
WEB_SERVER_CPU를 웹 서버의 CPU 수(vCPU 단위)로 바꿉니다.
WEB_SERVER_MEMORY를 웹 서버의 메모리 양(GB)으로 바꿉니다.
WEB_SERVER_STORAGE를 웹 서버의 디스크 크기(GB)로 바꿉니다.
WORKER_CPU를 작업자의 CPU 수(vCPU 단위)로 바꿉니다.
WORKER_MEMORY를 작업자의 메모리 양(GB)으로 바꿉니다.
WORKER_STORAGE를 작업자의 디스크 크기(GB)로 바꿉니다.
WORKERS_MIN를 환경에서 실행할 수 있는 최소 Airflow 작업자 수로 바꿉니다. 더 적은 작업자 수로 부하를 처리할 수 있어도 사용자 환경의 작업자 수는 이 수보다 적지 않습니다.
WORKERS_MAX를 환경에서 실행할 수 있는 최대 Airflow 작업자 수로 바꿉니다. 더 많은 작업자 수로 부하를 처리해야 하는 경우에도 사용자 환경의 작업자 수는 이 수보다 많지 않습니다.
ENVIRONMENT_SIZE를 환경 크기(ENVIRONMENT_SIZE_SMALL, ENVIRONMENT_SIZE_MEDIUM 또는 ENVIRONMENT_SIZE_LARGE)로 바꿉니다.

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

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    workloads_config {

      scheduler {
        cpu = 2.5
        memory_gb = 2.5
        storage_gb = 2
        count = 1
      }
      triggerer {
        count = 1
        cpu = 0.5
        memory_gb = 0.5
      }
      web_server {
        cpu = 1
        memory_gb = 2.5
        storage_gb = 2
      }
      worker {
        cpu = 1
        memory_gb = 2
        storage_gb = 2
        min_count = 2
        max_count = 4
      }
    }

    environment_size = "ENVIRONMENT_SIZE_SMALL"

  }
}

5단계: (선택사항) 높은 복원력 모드 사용 설정

복원력이 우수한 Cloud Composer 환경은 기본 제공되는 중복성 및 장애 조치 메커니즘을 사용하여 영역 장애와 단일 장애점 서비스 중단에 대한 환경 민감성을 줄이는 환경입니다.

복원력이 우수한 환경은 선택한 리전의 최소 두 개 이상의 영역에서 실행됩니다. 정확히 2개의 Airflow 스케줄러, 2개의 웹 서버, 2개 이상의 트리거(트리거 수가 0으로 설정되지 않은 경우)는 별도의 영역에서 실행됩니다. 최소 작업자 수는 2로 설정되며 환경 클러스터에서 영역 간에 작업자 인스턴스를 분산합니다. 영역 서비스 중단이 발생하면 영향을 받는 작업자 인스턴스가 다른 영역에서 다시 예약됩니다. 복원력이 뛰어난 환경의 Cloud SQL 데이터베이스는 기본 인스턴스와 대기 인스턴스가 있는 리전 인스턴스입니다.

콘솔

환경 만들기 페이지에서 다음을 수행합니다.

복원 모드 섹션에서 높은 복원력을 선택합니다.
환경 리소스 섹션에서 복원력이 우수한 환경을 위한 확장 매개변수를 선택합니다. 복원력이 우수한 환경에는 정확히 2개의 스케줄러, 0개 또는 2~10개의 트리거와 2개 이상의 작업자가 있어야 합니다.
1. Custom을 클릭합니다.
2. 스케줄러 수 드롭다운 목록에서 2를 선택합니다.
3. 트리거 수 드롭다운 목록에서 0을 선택하거나 2와 10 사이의 값을 선택합니다. 트리거의 CPU 및 메모리 할당을 구성합니다.
4. 최소 작업자 수 드롭다운 목록에서 필요한 작업자 수에 따라 2 이상을 선택합니다.
네트워크 구성 섹션에서 다음을 수행합니다.
1. 네트워킹 유형에서 비공개 IP 환경을 선택합니다.
2. 필요한 경우 기타 네트워킹 매개변수를 지정합니다.

gcloud

환경을 만들 때 --enable-high-resilience 인수는 높은 복원력 모드를 사용 설정합니다.

다음 인수를 설정합니다.

--enable-high-resilience
--enable-private-environment 및 필요한 경우 비공개 IP 환경의 기타 네트워킹 매개변수
2에게 --scheduler-count 부여
--triggerer-count를 0 또는 2~10 사이의 값으로 설정합니다. 트리거를 사용하는 경우 환경 생성에 --triggerer-cpu and--triggerer-memory` 플래그도 필요합니다.

--triggerer-count, --triggerer-cpu, --triggerer-memory 플래그에 관한 자세한 내용은 환경 규모 및 성능 매개변수 구성을 참고하세요.
--min-workers: 2 이상

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --enable-high-resilience \
    --enable-private-environment \
    --scheduler-count 2 \
    --triggerer-count 2 \
    --triggerer-cpu 0.5 \
    --triggerer-memory 0.5 \
    --min-workers 2

API

환경을 만들 때 환경 > EnvironmentConfig 리소스에 높은 복원력 모드를 사용 설정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "resilience_mode": "HIGH_RESILIENCE"
  }
}

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


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "resilience_mode": "HIGH_RESILIENCE"
  }
}

Terraform

환경을 만들 때 config 블록의 resilience_mode 필드에서 높은 복원력 모드를 사용 설정합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    resilience_mode = "HIGH_RESILIENCE"

  }
}

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

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    resilience_mode = "HIGH_RESILIENCE"

}

6단계: (선택사항) 환경 데이터베이스의 영역 지정

표준 복원력 환경을 만들 때 선호하는 Cloud SQL 영역을 지정할 수 있습니다.

콘솔

환경 만들기 페이지에서 다음을 수행합니다.

고급 구성 섹션에서 고급 구성 표시 항목을 펼칩니다.
Airflow 데이터베이스 영역 목록에서 원하는 Cloud SQL 영역을 선택합니다.

gcloud

환경을 만들 때 --cloud-sql-preferred-zone 인수는 선호하는 Cloud SQL 영역을 지정합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --cloud-sql-preferred-zone SQL_ZONE

다음을 바꿉니다.

SQL_ZONE: 선호하는 Cloud SQL 영역입니다. 이 영역은 환경이 위치한 리전에 있어야 합니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --cloud-sql-preferred-zone us-central1-a

API

환경을 만들 때 환경 > DatabaseConfig 리소스에 선호하는 Cloud SQL 영역을 지정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "databaseConfig": {
      "zone": "SQL_ZONE"
    }
  }
}

다음을 바꿉니다.

SQL_ZONE: 선호하는 Cloud SQL 영역입니다. 이 영역은 환경이 위치한 리전에 있어야 합니다.

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


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "databaseConfig": {
      "zone": "us-central1-a"
    }
  }
}

Terraform

환경을 만들 때 database_config 블록의 zone 필드는 선호하는 Cloud SQL 영역을 지정합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    database_config {
      zone = "SQL_ZONE"
    }
  }
}

다음을 바꿉니다.

SQL_ZONE: 선호하는 Cloud SQL 영역입니다. 이 영역은 환경이 위치한 리전에 있어야 합니다.

7단계: (선택사항) 환경의 네트워킹 구성

네트워킹 매개변수는 만들려는 환경 유형에 따라 달라집니다.

공개 IP 환경. 기본 네트워킹 매개변수를 사용합니다.
비공개 IP 환경(PSC 포함). 이 구성에서 환경은 연결을 위해 Private Service Connect를 사용합니다.

비공개 IP 환경을 구성합니다.
1. 비공개 IP 환경에 대한 프로젝트 네트워킹을 구성합니다.
2. 환경을 만들 때 Private Service Connect를 구성합니다.
3. 이 섹션의 뒷부분에 설명된 대로 비공개 IP 환경의 다른 매개변수를 지정합니다.
PSC가 있는 비공개 IP 환경의 경우 다음을 알아야 합니다.
- VPC 네트워크 ID
- VPC 서브네트워크 ID
- VPC 서브네트워크의 보조 IP 범위 2개:
  - 포드의 보조 IP 범위
  - 서비스의 보조 IP 범위
- 환경 구성요소의 IP 범위:
  - GKE 컨트롤 플레인 IP 범위. GKE 컨트롤 플레인의 IP 범위입니다.
  - Cloud Composer 연결 서브네트워크. Cloud Composer 연결 서브네트워크의 IP 범위.
비공개 IP 환경(VPC 피어링). 이 구성에서 환경은 연결에 VPC 피어링을 사용합니다.

비공개 IP 환경을 구성합니다.
1. 비공개 IP 환경에 대한 프로젝트 네트워킹을 구성합니다.
2. 이 섹션의 뒷부분에 설명된 대로 비공개 IP 환경의 다른 매개변수를 지정합니다.
VPC 피어링이 있는 비공개 IP 환경의 경우 다음을 알아야 합니다.
- VPC 네트워크 ID
- VPC 서브네트워크 ID
- VPC 서브네트워크의 보조 IP 범위 2개:
  - 포드의 보조 IP 범위
  - 서비스의 보조 IP 범위
- 환경 구성요소의 IP 범위:
  - GKE 컨트롤 플레인의 IP 범위.
  - 내부 Cloud Composer 네트워크에서 선택한 네트워크로 내보낼 VPC 피어링의 IP 범위. Cloud Composer 인프라 구성요소는 이 범위의 IP 주소를 사용합니다.
  - Cloud SQL 인스턴스의 IP 범위.
공유 VPC 환경의 경우 호스트 프로젝트에 추가 네트워킹 설정을 수행한 다음 서비스 프로젝트에 공개 또는 비공개 IP 환경을 만들어야 합니다. 공유 VPC 구성 페이지의 안내를 따릅니다.

중요: Google Cloud 콘솔을 사용하여 서비스 프로젝트에 환경을 만드는 경우 호스트 프로젝트에서 계정에 compute.subnetworks.use 권한이 있어야 합니다. 그렇지 않으면 사용 가능한 서브네트워크 목록에 호스트 프로젝트의 서브네트워크가 포함되지 않습니다. gcloud, API, Terraform을 사용하여 환경을 만드는 경우 계정에 이 추가 권한이 필요하지 않습니다.

공유 VPC 환경의 경우 다음을 알아야 합니다.
- 호스트 프로젝트 VPC 네트워크 ID
- 호스트 프로젝트 VPC 서브네트워크 ID
- 호스트 프로젝트 VPC 서브네트워크의 보조 IP 범위 2개:
  - 포드의 보조 IP 범위
  - 서비스의 보조 IP 범위
공개 IP 공유 VPC 환경을 만들 때도 호스트 프로젝트 VPC 네트워크, 서브네트워크, 포드 및 서비스의 보조 IP 범위를 지정해야 합니다.
VPC SC 환경을 만들려면 서비스 경계를 만든 다음 이 경계 내에 비공개 IP 환경을 만들어야 합니다. VPC 서비스 제어 구성에 설명된 안내를 따릅니다.

환경의 추가 네트워킹 옵션은 다음과 같습니다.

비공개로 사용되는 공개 IP 주소. 더 많은 IP 주소를 사용하려는 경우 환경에서 특정 공개 IP 주소 범위를 포드 및 서비스의 내부 서브넷 IP 주소 범위로 비공개로 사용할 수 있습니다.
승인된 네트워크 HTTPS를 사용하여 비공개 IP 환경의 컨트롤 플레인에 액세스하려면 승인된 네트워크를 사용하여 이를 수행할 수 있는 CIDR 범위를 지정하면 됩니다.
IP 매스커레이드 에이전트. IP 매스커레이드 에이전트에서 환경을 사용하면 환경의 네트워킹 구성에서 다대일 IP 주소 변환을 사용할 수 있습니다. IP 매스커레이드 에이전트로 환경을 만드는 방법에 대한 자세한 내용은 IP 매스커레이드 에이전트 사용 설정을 참조하세요.

콘솔

비공개 IP 환경을 만들려면 다음 안내를 따르세요.

만들려는 환경 유형에 맞게 네트워킹이 구성되었는지 확인합니다.
네트워크 구성 섹션에서 네트워크 구성 표시 항목을 펼칩니다.
네트워크 드롭다운 목록에서 VPC 네트워크 ID를 선택합니다.
서브네트워크 드롭다운 목록에서 VPC 서브네트워크 ID를 선택합니다.
포드의 보조 IP 범위 섹션에서 포드의 보조 IP 범위를 선택하거나 지정합니다. VPC 네트워크에서 기존 보조 범위를 사용하거나 자동 생성된 범위를 사용하도록 선택할 수 있습니다.
서비스의 보조 IP 범위 섹션에서 서비스의 보조 IP 범위를 선택하거나 지정합니다. VPC 네트워크에서 기존 보조 범위를 사용하거나 자동 생성된 범위를 사용하도록 선택할 수 있습니다.
네트워킹 유형 섹션에서 비공개 IP 환경 옵션을 선택하여 비공개 IP 환경을 만듭니다.
Composer 연결 섹션에서 환경의 네트워킹 유형을 선택하고 환경 구성요소의 IP 범위를 지정합니다.

Private Service Connect를 사용하는 환경의 경우 다음을 따르세요.
1. Private Service Connect를 사용하는 환경에 대해 Private Service Connect를 선택합니다.
2. Composer 연결 서브네트워크 섹션에서 Cloud Composer 연결 서브네트워크의 IP 범위를 지정합니다. PSC 엔드포인트의 주소가 이 범위에서 선택됩니다. 커스텀 범위를 지정하거나 기본 범위를 사용하도록 선택할 수 있습니다.
VPC 피어링을 사용하는 환경의 경우 다음을 따르세요.
1. VPC 피어링을 사용하는 환경에 대해 VPC 피어링을 선택합니다.
  
  참고: VPC 피어링이 있는 환경에는 PSC 환경보다 더 많은 제한사항이 있습니다.
2. Composer 테넌트 네트워크의 IP 범위 섹션에서 Cloud Composer 테넌트 네트워크의 IP 범위를 지정합니다. 이 네트워크는 환경의 SQL 프록시 구성요소를 호스팅합니다. 커스텀 범위를 지정하거나 기본 범위를 사용하도록 선택할 수 있습니다.
3. Cloud SQL 네트워크의 IP 범위 섹션에서 Cloud SQL 인스턴스의 IP 범위를 지정합니다. 커스텀 범위를 지정하거나 기본 범위를 사용하도록 선택할 수 있습니다.
  
  주의: 172.17.0.0/16 범위는 Cloud SQL에 예약되어 있습니다.
GKE 컨트롤 플레인 네트워크의 IP 범위 섹션에서 GKE 컨트롤 플레인의 IP 범위를 지정합니다.
- 환경이 위치한 리전의 기본 IP 범위를 사용하려면 기본 IP 범위를 선택합니다.
- 커스텀 IP 범위를 지정하려면 커스텀 IP 범위를 선택하고 GKE 클러스터 마스터 비공개 IP 필드에 CIDR 표기법으로 범위를 입력합니다.
GKE 컨트롤 플레인의 수준 액세스를 선택합니다. 컨트롤 플레인에는 엔드포인트가 2개 있습니다. 하나의 엔드포인트는 클러스터 노드 및 VM에서 사용할 용도로 비공개입니다. 다른 엔드포인트는 공개입니다. 공개 엔드포인트에 대한 액세스 수준을 지정할 수 있습니다.
- 승인된 네트워크에서 공개 엔드포인트에 대한 액세스를 사용 설정하려면 외부 IP 주소를 사용하여 클러스터 컨트롤 플레인 엔드포인트에 액세스 체크박스를 선택합니다.
  
  이 옵션을 사용하면 컨트롤 플레인의 액세스 수준이 '공개 엔드포인트 액세스 사용 설정됨, 승인된 네트워크 사용 설정됨'으로 설정됩니다. 이를 통해 승인된 네트워크에서 컨트롤 플레인에 대한 제한된 액세스가 제공됩니다. 기본적으로 소스 IP 주소는 지정되지 않습니다. 클러스터에 승인된 네트워크를 추가할 수 있습니다.
- 승인된 네트워크에서 공개 엔드포인트에 액세스를 할 수 없게 하려면 외부 IP 주소를 사용하여 클러스터 컨트롤 플레인 엔드포인트에 액세스 체크박스를 선택 취소합니다.
  
  이 옵션을 사용하면 컨트롤 플레인의 액세스 수준이 '공개 엔드포인트 액세스 사용 중지됨'으로 설정됩니다. 이렇게 하면 컨트롤 플레인에 대한 모든 인터넷 액세스가 방지됩니다.

gcloud

만들려는 환경 유형에 맞게 네트워킹이 구성되었는지 확인합니다.

환경을 만들 때 다음 인수가 네트워킹 매개변수를 제어합니다. 매개변수를 생략하면 기본값이 사용됩니다.

--enable-private-environment: 비공개 IP 환경을 사용 설정합니다.
--network: VPC 네트워크 ID를 지정합니다.
--subnetwork: VPC 서브네트워크 ID를 지정합니다.
--cluster-secondary-range-name 또는 --cluster-ipv4-cidr: 포드의 보조 범위를 구성합니다.
--services-secondary-range-name 또는 --services-ipv4-cidr - 서비스의 보조 범위를 구성합니다.
--master-ipv4-cidr: GKE 컨트롤 플레인의 범위를 지정합니다.

(PSC가 있는 환경) --connection-subnetwork는 PSC 엔드포인트를 호스팅하는 Cloud Composer 연결 서브네트워크의 범위를 지정합니다.
(VPC 피어링이 있는 환경) --composer-network-ipv4-cidr은 Cloud Composer 테넌트 네트워크의 범위를 지정합니다. 이 네트워크는 환경의 SQL 프록시 구성요소를 호스팅합니다.
(VPC 피어링이 있는 환경) --cloud-sql-ipv4-cidr은 Cloud SQL 인스턴스의 범위를 지정합니다.

--enable-private-endpoint: GKE 컨트롤 플레인의 수준 액세스를 제어합니다. 컨트롤 플레인에는 엔드포인트가 2개 있습니다. 하나의 엔드포인트는 클러스터 노드 및 VM에서 사용할 용도로 비공개입니다. 다른 엔드포인트는 공개입니다. 공개 엔드포인트에 대한 액세스 수준을 지정할 수 있습니다.
- 승인된 네트워크에서 공개 엔드포인트에 액세스하도록 허용하려면 --enable-private-endpoint 인수를 생략합니다.
  
  이 옵션을 사용하면 컨트롤 플레인의 액세스 수준이 '공개 엔드포인트 액세스 사용 설정됨, 승인된 네트워크 사용 설정됨'으로 설정됩니다. 이를 통해 승인된 네트워크에서 컨트롤 플레인에 대한 제한된 액세스가 제공됩니다. 기본적으로 소스 IP 주소는 지정되지 않습니다. 클러스터에 승인된 네트워크를 추가할 수 있습니다.
- 승인된 네트워크에서 공개 엔드포인트에 액세스할 수 없게 하려면 --enable-private-endpoint 인수를 지정합니다.
  
  이 옵션을 사용하면 컨트롤 플레인의 액세스 수준이 '공개 엔드포인트 액세스 사용 중지됨'으로 설정됩니다. 이렇게 하면 컨트롤 플레인에 대한 모든 인터넷 액세스가 방지됩니다.
--enable-master-authorized-networks 및 --master-authorized-networks 인수는 환경의 승인된 네트워크를 구성합니다.
--enable-privately-used-public-ips는 환경에서 비공개로 사용되는 공개 IP 주소를 구성합니다.
--enable-ip-masq-agent는 IP 매스커레이드 에이전트를 사용 설정합니다.

예시(비공개 IP 환경)

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --enable-private-environment \
    --network NETWORK_ID \
    --subnetwork SUBNETWORK_ID \
    --cluster-ipv4-cidr PODS_RANGE \
    --services-ipv4-cidr SERVICES_RANGE \
    --master-ipv4-cidr CONTROL_PLANE_RANGE \
    --connection-subnetwork COMPOSER_PSC_RANGE \

다음과 같이 바꿉니다.

NETWORK_ID를 VPC 네트워크 ID로 바꿉니다.
SUBNETWORK_ID를 VPC 서브네트워크 ID로 바꿉니다.
PODS_RANGE를 포드의 보조 범위로 바꿉니다.
SERVICES_RANGE를 서비스의 보조 범위로 바꿉니다.
CONTROL_PLANE_RANGE를 GKE 컨트롤 플레인의 보조 범위로 바꿉니다.
COMPOSER_PSC_RANGE를 Cloud Composer 연결 서브네트워크의 범위로 바꿉니다.

8단계: (선택사항) 네트워크 태그 추가

네트워크 태그는 환경 클러스터의 모든 노드 VM에 적용됩니다. 태그는 네트워크 방화벽의 유효한 소스 또는 대상을 식별하는 데 사용됩니다. 목록의 각 태그는 RFC 1035를 준수해야 합니다.

예를 들어 방화벽 규칙이 있는 비공개 IP 환경의 트래픽을 제한하려는 경우 네트워크 태그를 추가하고 싶을 수 있습니다.

콘솔

환경 만들기 페이지에서 다음을 수행합니다.

네트워크 구성 섹션을 찾습니다.
네트워크 태그 필드에 환경의 네트워크 태그를 입력합니다.

gcloud

환경을 만들 때 다음 인수가 네트워크 태그를 제어합니다.

--tags는 모든 노드 VM에 적용되는 쉼표로 구분된 네트워크 태그 목록을 지정합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --tags TAGS

다음과 같이 바꿉니다.

TAGS를 쉼표로 구분된 네트워크 태그 목록으로 바꿉니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --tags group1,production

API

환경을 만들 때 환경 > EnvironmentConfig 리소스에서 해당 환경의 네트워크 태그를 지정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "nodeConfig": {
      "tags": [
        "TAG"
      ]
    }
  }
}

다음과 같이 바꿉니다.

TAG를 네트워크 태그로 바꿉니다.

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

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "nodeConfig": {
      "tags": [
        "group1",
        "production"
      ]
    }
  }
}

Terraform

환경을 만들 때 다음 필드는 해당 환경의 네트워크 태그를 정의합니다.

node_config 블록의 tags 필드는 모든 노드 VM에 적용되는 쉼표로 구분된 네트워크 태그 목록을 지정합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    node_config {
      tags = ["TAGS"]
    }
  }
}

다음과 같이 바꿉니다.

TAGS를 쉼표로 구분된 네트워크 태그 목록으로 바꿉니다.

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

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    node_config {
      tags = ["group1","production"]
    }
  }
}

9단계: (선택사항) 웹 서버 네트워크 액세스 구성

Airflow 웹 서버 액세스 매개변수는 환경 유형에 따라 달라지지 않습니다. 대신 웹 서버 액세스를 별도로 구성할 수 있습니다. 예를 들어 비공개 IP 환경은 인터넷에서 Airflow UI에 계속 액세스할 수 있습니다.

비공개 IP 주소를 사용하여 허용되는 IP 범위를 구성할 수 없습니다.

콘솔

환경 만들기 페이지에서 다음을 수행합니다.

네트워크 구성 섹션에서 네트워크 구성 표시 항목을 펼칩니다.
웹 서버 네트워크 액세스 제어 섹션에서 다음을 수행합니다.
- 모든 IP 주소의 Airfow 웹 서버에 대한 액세스 권한을 제공하려면 모든 IP 주소의 액세스 허용을 선택합니다.
- 특정 IP 범위로만 액세스를 제한하려면 특정 IP 주소에서만 액세스 허용을 선택합니다. IP 범위 필드에서 CIDR 표기법으로 IP 범위를 지정합니다. 설명 필드에 이 범위의 설명(선택사항)을 지정합니다. 범위를 두 개 이상 지정하려면 IP 범위 추가를 클릭합니다.
- 모든 IP 주소의 액세스를 금지하려면 특정 IP 주소에서만 액세스 허용을 선택하고 빈 범위 항목 옆에 있는 항목 삭제를 클릭합니다.

gcloud

환경을 만들 때 다음 인수가 웹 서버 액세스 수준을 제어합니다.

--web-server-allow-all은 모든 IP 주소의 Airflow에 대한 액세스를 제공합니다. 기본 옵션입니다.
--web-server-allow-ip는 특정 소스 IP 범위로만 액세스를 제한합니다. 여러 IP 범위를 지정하려면 이 인수를 여러 번 사용합니다.
--web-server-deny-all은 모든 IP 주소의 액세스를 금지합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --web-server-allow-ip ip_range=WS_IP_RANGE,description=WS_RANGE_DESCRIPTION

다음과 같이 바꿉니다.

WS_IP_RANGE를 CIDR 표기법으로 나타낸 IP 범위로 바꿉니다. Airflow UI에 액세스할 수 있습니다.
WS_RANGE_DESCRIPTION을 IP 범위 설명으로 바꿉니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --web-server-allow-ip ip_range=192.0.2.0/24,description="office net 1" \
    --web-server-allow-ip ip_range=192.0.4.0/24,description="office net 3"

API

환경을 만들 때 환경 > EnvironmentConfig 리소스에 웹 서버 액세스 매개변수를 지정합니다.

모든 IP 주소의 Airfow 웹 서버에 대한 액세스 권한을 제공하려면 webServerNetworkAccessControl을 생략합니다.
특정 IP 범위로만 액세스를 제한하려면 allowedIpRanges에 하나 이상의 범위를 지정합니다.
모든 IP 주소의 액세스를 금지하려면 allowedIpRanges를 추가하고 빈 목록으로 만듭니다. 여기에 IP 범위를 지정하지 마세요.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "webServerNetworkAccessControl": {
      "allowedIpRanges": [
        {
          "value": "WS_IP_RANGE",
          "description": "WS_RANGE_DESCRIPTION"
        }
      ]
    }
  }
}

다음과 같이 바꿉니다.

WS_IP_RANGE를 CIDR 표기법으로 나타낸 IP 범위로 바꿉니다. Airflow UI에 액세스할 수 있습니다.
WS_RANGE_DESCRIPTION을 IP 범위 설명으로 바꿉니다.

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


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "webServerNetworkAccessControl": {
      "allowedIpRanges": [
        {
          "value": "192.0.2.0/24",
          "description": "office net 1"
        },
        {
          "value": "192.0.4.0/24",
          "description": "office net 3"
        }
      ]
    }
  }
}

Terraform

환경을 만들 때 web_server_network_access_control 블록의 allowed_ip_range 블록에는 웹 서버에 액세스할 수 있는 IP 범위가 포함됩니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    web_server_network_access_control {

      allowed_ip_range {
        value = "WS_IP_RANGE"
        description = "WS_RANGE_DESCRIPTION"
      }

    }

  }
}

다음과 같이 바꿉니다.

WS_IP_RANGE를 CIDR 표기법으로 나타낸 IP 범위로 바꿉니다. Airflow UI에 액세스할 수 있습니다.
WS_RANGE_DESCRIPTION을 IP 범위 설명으로 바꿉니다.

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

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    web_server_network_access_control {
      allowed_ip_range {
        value = "192.0.2.0/24"
        description = "office net 1"
      },
      allowed_ip_range {
        value = "192.0.4.0/24"
        description = "office net 3"
      }

    }
}

10단계: (선택사항) Airflow 구성 재정의 및 환경 변수 지정

환경을 만들 때 Airflow 구성 재정의 및 환경 변수를 설정할 수 있습니다. 또는 환경이 생성된 후 나중에 수행할 수도 있습니다.

일부 차단된 Airflow 구성 옵션은 재정의할 수 없습니다.

사용 가능한 Airflow 구성 옵션의 목록은 Airflow 2 구성 참조 및 Airflow 1.10*을 참조하세요.

Airflow 구성 재정의 및 환경 변수를 지정하려면 다음 안내를 따르세요.

콘솔

환경 만들기 페이지에서 다음을 수행합니다.

환경 변수 섹션에서 환경 변수 추가를 클릭합니다.
환경 변수의 이름 및 값을 입력합니다.
Airflow 구성 재정의 섹션에서 Airflow 구성 재정의 추가를 클릭합니다.
구성 옵션 재정의의 섹션, 키, 값을 입력합니다.

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

섹션 키 값

webserver dag_orientation TB

섹션	키	값
`webserver`	`dag_orientation`	`TB`

gcloud

환경을 만들 때 다음 인수는 환경 변수와 Airflow 구성 재정의를 제어합니다.

--env-variables는 쉼표로 구분된 환경 변수 목록을 지정합니다.

변수 이름에는 대소문자, 숫자, 밑줄이 포함될 수 있지만 숫자로 시작할 수 없습니다.
--airflow-configs는 Airflow 구성 재정의의 키와 값을 쉼표로 구분된 목록으로 지정합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --env-variables ENV_VARS \
    --airflow-configs CONFIG_OVERRIDES

다음과 같이 바꿉니다.

ENV_VARS를 환경 변수의 쉼표로 구분된 NAME=VALUE 쌍 목록으로 바꿉니다.
CONFIG_OVERRIDES를 구성 재정의의 쉼표로 구분된 SECTION-KEY=VALUE 쌍 목록으로 바꿉니다. 구성 섹션 이름을 - 기호로 구분하고 그 뒤에 키 이름을 입력합니다. 예를 들면 core-dags_are_paused_at_creation입니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --env-variables SENDGRID_MAIL_FROM=user@example.com,SENDGRID_API_KEY=example-key \
    --airflow-configs core-dags_are_paused_at_creation=True,webserver-dag_orientation=TB

API

환경을 만들 때 환경 > EnvironmentConfig 리소스에 환경 변수 및 Airflow 구성 재정의를 지정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "softwareConfig": {
      "airflowConfigOverrides": {
        "SECTION-KEY": "OVERRIDE_VALUE"
      },
      "envVariables": {
        "VAR_NAME": "VAR_VALUE",
      }
    }
  }
}

다음과 같이 바꿉니다.

SECTION을 구성 파일에서 Airflow 구성 옵션이 있는 섹션으로 바꿉니다.
KEY를 Airflow 구성 옵션의 이름으로 바꿉니다.
OVERRIDE_VALUE를 Airflow 구성 옵션의 값으로 바꿉니다.
VAR_NAME을 환경 변수의 이름으로 바꿉니다.
VAR_VALUE를 환경 변수 값으로 바꿉니다.

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

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "softwareConfig": {
      "airflowConfigOverrides": {
        "core-dags_are_paused_at_creation": "True",
        "webserver-dag_orientation": "TB"
      },
      "envVariables": {
        "SENDGRID_MAIL_FROM": "user@example.com",
        "SENDGRID_API_KEY": "example-key"
      }
    }
  }
}

Terraform

환경을 만들 때 다음 블록은 환경 변수와 Airflow 구성 재정의를 제어합니다.

software_config 블록의 env_variables 블록은 환경 변수를 지정합니다.

변수 이름에는 대소문자, 숫자, 밑줄이 포함될 수 있지만 숫자로 시작할 수 없습니다.
software_config 블록의 airflow_config_overrides 블록은 Airflow 구성 재정의를 지정합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    software_config {

      airflow_config_overrides = {
        SECTION-KEY = "OVERRIDE_VALUE"
      }

      env_variables = {
        VAR_NAME = "VAR_VALUE"
      }
    }
  }
}

다음과 같이 바꿉니다.

SECTION을 구성 파일에서 Airflow 구성 옵션이 있는 섹션으로 바꿉니다.
KEY를 Airflow 구성 옵션의 이름으로 바꿉니다.
OVERRIDE_VALUE를 Airflow 구성 옵션의 값으로 바꿉니다.
VAR_NAME을 환경 변수의 이름으로 바꿉니다.
VAR_VALUE를 환경 변수 값으로 바꿉니다.

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

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    software_config {

      airflow_config_overrides = {
        core-dags_are_paused_at_creation = "True"
        webserver-dag_orientation = "TB"
      }

      env_variables = {
        SENDGRID_MAIL_FROM = "user@example.com"
        SENDGRID_API_KEY = "example-key"
      }
    }
  }
}

11단계: (선택사항) 유지보수 기간 지정

Cloud Composer 2의 기본 유지보수 기간은 매주 금요일, 토요일, 일요일 00:00:00~04:00:00(GMT)입니다.

환경의 커스텀 유지보수 기간을 지정하려면 다음 안내를 따르세요.

콘솔

환경 만들기 페이지에서 다음을 수행합니다.

유지보수 기간 섹션을 찾습니다.
시간대 드롭다운 목록에서 유지보수 기간의 시간대를 선택합니다.
지정한 일정의 총 기간이 7일 순환 기간 동안 최소 12시간이 되도록 시작 시간, 일, 길이를 설정합니다. 예를 들어 매주 월요일, 수요일, 금요일마다 4시간이면 필요한 시간을 제공합니다.

gcloud

다음 인수는 유지보수 기간 매개변수를 정의합니다.

--maintenance-window-start는 유지보수 기간의 시작 시간을 설정합니다.
--maintenance-window-end는 유지보수 기간의 종료 시간을 설정합니다.
--maintenance-window-recurrence는 유지보수 기간 반복을 설정합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --maintenance-window-start 'DATETIME_START' \
    --maintenance-window-end 'DATETIME_END' \
    --maintenance-window-recurrence 'MAINTENANCE_RECURRENCE'

다음과 같이 바꿉니다.

ENVIRONMENT_NAME을 환경 이름으로 바꿉니다.
DATETIME_START를 날짜/시간 입력 형식의 시작 날짜 및 시간으로 바꿉니다. 지정한 시간만 사용되며 날짜는 무시됩니다.
DATETIME_END를 날짜/시간 입력 형식의 종료 날짜 및 시간으로 바꿉니다. 지정한 시간만 사용되며 날짜는 무시됩니다. 지정한 날짜와 시간은 시작일 이후여야 합니다.
MAINTENANCE_RECURRENCE를 유지보수 기간 반복을 위한 RFC 5545 RRULE로 바꿉니다. Cloud Composer는 다음 두 가지 형식을 지원합니다.
FREQ=DAILY 형식은 일일 반복을 지정합니다.
FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA 형식은 선택한 요일의 반복을 지정합니다.

다음 예시에서는 수요일, 토요일, 일요일 01:00~07:00(UTC) 사이에서 유지보수 기간 6시간을 지정합니다. 2023년 1월 1일 날짜는 무시됩니다.

gcloud composer environments create example-environment \
  --location us-central1 \
  --image-version composer-2.9.7-airflow-2.9.3 \
  --maintenance-window-start '2023-01-01T01:00:00Z' \
  --maintenance-window-end '2023-01-01T07:00:00Z' \
  --maintenance-window-recurrence 'FREQ=WEEKLY;BYDAY=SU,WE,SA'

API

환경을 만들 때 환경 > EnvironmentConfig 리소스에 유지보수 기간 매개변수를 지정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "maintenanceWindow": {
        "startTime": "DATETIME_START",
        "endTime": "DATETIME_END",
        "recurrence": "MAINTENANCE_RECURRENCE"
    }
  }
}

다음과 같이 바꿉니다.

DATETIME_START를 날짜/시간 입력 형식의 시작 날짜 및 시간으로 바꿉니다. 지정한 시간만 사용되며 날짜는 무시됩니다.
DATETIME_END를 날짜/시간 입력 형식의 종료 날짜 및 시간으로 바꿉니다. 지정한 시간만 사용되며 날짜는 무시됩니다. 지정한 날짜와 시간은 시작일 이후여야 합니다.
MAINTENANCE_RECURRENCE를 유지보수 기간 반복을 위한 RFC 5545 RRULE로 바꿉니다. Cloud Composer는 다음 두 가지 형식을 지원합니다.
FREQ=DAILY 형식은 일일 반복을 지정합니다.
FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA 형식은 선택한 요일의 반복을 지정합니다.

다음 예시에서는 수요일, 토요일, 일요일 01:00~07:00(UTC) 사이에서 유지보수 기간 6시간을 지정합니다. 2023년 1월 1일 날짜는 무시됩니다.

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

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "maintenanceWindow": {
        "startTime": "2023-01-01T01:00:00Z",
        "endTime": "2023-01-01T07:00:00Z",
        "recurrence": "FREQ=WEEKLY;BYDAY=SU,WE,SA"
    }
  }
}

Terraform

maintenance_window 블록은 환경의 유지보수 기간을 지정합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    maintenance_window {
      start_time = "DATETIME_START"
      end_time = "DATETIME_END"
      recurrence = "MAINTENANCE_RECURRENCE"
    }
  }
}

다음과 같이 바꿉니다.

DATETIME_START를 날짜/시간 입력 형식의 시작 날짜 및 시간으로 바꿉니다. 지정한 시간만 사용되며 날짜는 무시됩니다.
DATETIME_END를 날짜/시간 입력 형식의 종료 날짜 및 시간으로 바꿉니다. 지정한 시간만 사용되며 날짜는 무시됩니다. 지정한 날짜와 시간은 시작일 이후여야 합니다.
MAINTENANCE_RECURRENCE를 유지보수 기간 반복을 위한 RFC 5545 RRULE로 바꿉니다. Cloud Composer는 다음 두 가지 형식을 지원합니다.
- FREQ=DAILY 형식은 일일 반복을 지정합니다.
- FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA 형식은 선택한 요일의 반복을 지정합니다.

다음 예시에서는 수요일, 토요일, 일요일 01:00~07:00(UTC) 사이에서 유지보수 기간 6시간을 지정합니다. 2023년 1월 1일 날짜는 무시됩니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    maintenance_window {
      start_time = "2023-01-01T01:00:00Z"
      end_time = "2023-01-01T07:00:00Z"
      recurrence = "FREQ=WEEKLY;BYDAY=SU,WE,SA"
    }
  }
}

12단계: (선택사항) 데이터 계보 통합

데이터 계보는 데이터 이동을 추적할 수 있는 Dataplex 기능입니다.

Cloud Composer 2 버전 2.1.2 이상 및 Airflow 버전 2.2.5 이상에서 데이터 계보 통합을 사용할 수 있습니다.

다음 조건이 충족되면 새 Cloud Composer 환경에서 데이터 계보 통합이 자동으로 사용 설정됩니다.

프로젝트에 Data Lineage API가 사용 설정되어 있습니다. 자세한 내용은 Dataplex 문서의 Data Lineage API 사용 설정을 참조하세요.

주의: Data Lineage API를 사용 설정하면 Dataplex에서 BigQuery, Cloud Data Fusion, Dataproc에 대한 데이터를 자동으로 수집합니다. 이는 데이터 계보 통합으로 Cloud Composer 환경을 만들지 않은 경우에도 발생합니다.
Airflow에는 커스텀 계보 백엔드가 구성되지 않습니다.

환경을 만들 때 데이터 계보 통합을 중지할 수 있습니다. 예를 들어 자동 동작을 재정의하거나 환경이 생성된 후 나중에 데이터 계보를 사용 설정하려는 경우입니다.

콘솔

데이터 계보 통합을 중지하려면 환경 만들기 페이지에서 다음을 수행합니다.

고급 구성 섹션에서 고급 구성 표시 항목을 펼칩니다.
Dataplex 데이터 계보 통합 섹션에서 Dataplex 데이터 계보와의 통합 중지를 선택합니다.

gcloud

환경을 만들 때 --disable-cloud-data-lineage-integration 인수는 데이터 계보 통합을 중지합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --disable-cloud-data-lineage-integration

다음과 같이 바꿉니다.

ENVIRONMENT_NAME을 환경 이름으로 바꿉니다.
LOCATION을 환경이 위치한 리전으로 바꿉니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --disable-cloud-data-lineage-integration

13 단계 (선택사항) 데이터 암호화 구성(CMEK)

기본적으로 환경의 데이터는 Google이 제공하는 키로 암호화됩니다.

고객 관리 암호화 키(CMEK)를 사용하여 사용자 환경에서 데이터를 암호화하려면 고객 관리 암호화 키 사용에 설명된 안내를 따르세요.

14단계: (선택사항) 커스텀 환경의 버킷 사용

환경을 만들면 Cloud Composer가 사용자 환경의 버킷을 자동으로 만듭니다.

또는 프로젝트에서 커스텀 Cloud Storage 버킷을 지정할 수 있습니다. 환경은 자동으로 생성된 버킷과 동일한 방식으로 이 버킷을 사용합니다.

커스텀 환경 버킷을 사용하려면 커스텀 환경의 버킷 사용에 설명된 안내를 따르세요.

15단계: (선택사항) 환경 라벨 지정

환경에 라벨을 할당하여 이 라벨을 기준으로 청구 비용을 세분화할 수 있습니다.

콘솔

환경 만들기 페이지의 라벨 섹션에서 다음을 수행합니다.

라벨 추가를 클릭합니다.
키 및 값 필드에서 환경 라벨의 키 및 값 쌍을 지정합니다.

gcloud

환경을 만들 때 --labels 인수는 환경 라벨의 키와 값을 쉼표로 구분된 목록으로 지정합니다.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --labels LABELS

다음과 같이 바꿉니다.

LABELS를 환경 라벨의 쉼표로 구분된 KEY=VALUE 쌍 목록으로 바꿉니다.

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

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.9.7-airflow-2.9.3 \
    --labels owner=engineering-team,env=production

API

환경을 만들 때 Environment 리소스에 환경의 라벨을 지정합니다.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "labels": {
    "LABEL_KEY": "LABEL_VALUE"
  }
}

다음과 같이 바꿉니다.

LABEL_KEY를 환경 라벨 키로 바꿉니다.
LABEL_VALUE를 환경 라벨 값으로 바꿉니다.

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


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "labels": {
    "owner": "engineering-team",
    "env": "production"
  }
}

Terraform

환경을 만들 때 labels 블록(config 블록 외부)에 라벨을 지정합니다.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  labels = {
    LABEL_KEY = "LABEL_VALUE"
  }

}

다음과 같이 바꿉니다.

LABEL_KEY를 환경 라벨 키로 바꿉니다.
LABEL_VALUE를 환경 라벨 값으로 바꿉니다.

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

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  labels = {
    owner = "engineering-team"
    env = "production"
  }

}

Cloud Composer 환경 만들기

시작하기 전에

1단계: 기본 설정

콘솔

gcloud

API

Terraform

2단계: (선택사항) 환경의 서비스 계정 선택

콘솔

gcloud

API

Terraform

3단계: Cloud Composer 서비스 계정에 필요한 권한 부여

콘솔

gcloud

API

Terraform

4단계: (선택사항) 환경 규모 및 성능 매개변수 구성

콘솔

gcloud

API

Terraform

5단계: (선택사항) 높은 복원력 모드 사용 설정

콘솔

gcloud

API

Terraform

6단계: (선택사항) 환경 데이터베이스의 영역 지정

콘솔

gcloud

API

Terraform

7단계: (선택사항) 환경의 네트워킹 구성

콘솔

gcloud

8단계: (선택사항) 네트워크 태그 추가

콘솔

gcloud

API

Terraform

9단계: (선택사항) 웹 서버 네트워크 액세스 구성

콘솔

gcloud

API

Terraform

10단계: (선택사항) Airflow 구성 재정의 및 환경 변수 지정

콘솔

gcloud

API

Terraform

11단계: (선택사항) 유지보수 기간 지정

콘솔

gcloud

API

Terraform

12단계: (선택사항) 데이터 계보 통합

콘솔

gcloud

13 단계 (선택사항) 데이터 암호화 구성(CMEK)

14단계: (선택사항) 커스텀 환경의 버킷 사용

15단계: (선택사항) 환경 라벨 지정

콘솔

gcloud

API

Terraform

다음 단계