관리형 Airflow (3세대) | 관리형 Airflow (2세대) | 관리형 Airflow (기존 1세대)
이 페이지에서는 DAG, 데이터, 구성을 Airflow 2가 포함된 기존 관리형 Airflow (3세대) 환경에서 Airflow 3이 포함된 관리형 Airflow (3세대) 환경으로 전송하는 방법을 설명합니다.
기타 마이그레이션 가이드
| 보낸사람 | 받는사람 | 메서드 | 가이드 |
|---|---|---|---|
| 관리형 Airflow (3세대), Airflow 2 | 관리형 Airflow (3세대), Airflow 3 | 단계별 수동 전송 | 이 가이드에서 |
| Managed Airflow (2세대) | 관리형 Airflow (3세대) | 마이그레이션 스크립트를 사용하여 단계별 마이그레이션 | 스크립트 이전 가이드 |
| Managed Airflow (2세대) | 관리형 Airflow (3세대) | 스냅샷을 사용하여 단계별 마이그레이션 | 스냅샷 마이그레이션 가이드 |
| 관리형 Airflow (기존 1세대), Airflow 2 | 관리형 Airflow (3세대) | 스냅샷을 사용하여 단계별 마이그레이션 | 스냅샷 마이그레이션 가이드 |
| 관리형 Airflow (기존 1세대), Airflow 2 | Managed Airflow (2세대) | 스냅샷을 사용하여 단계별 마이그레이션 | 스냅샷 마이그레이션 가이드 |
| 관리형 Airflow (기존 1세대), Airflow 2 | Managed Airflow (2세대) | 단계별 수동 전송 | 수동 마이그레이션 가이드 |
| 관리형 Airflow (기존 1세대), Airflow 1 | 관리형 Airflow (2세대), Airflow 2 | 스냅샷을 사용하여 단계별 마이그레이션 | 스냅샷 마이그레이션 가이드 |
| 관리형 Airflow (기존 1세대), Airflow 1 | 관리형 Airflow (2세대), Airflow 2 | 단계별 수동 전송 | 수동 마이그레이션 가이드 |
| 관리형 Airflow (기존 1세대), Airflow 1 | 관리형 Airflow (기존 1세대), Airflow 2 | 단계별 수동 전송 | 수동 마이그레이션 가이드 |
Airflow 3에 도입된 변경사항
Airflow 3으로 Managed Airflow 환경을 시작하기 전 Airflow 3으로 Managed Airflow (3세대) 환경에 적용되는 변경사항을 고려합니다.
커뮤니티 버전의 Airflow 3에 도입된 변경사항에 대한 개요는 Apache Airflow 3 정식 출시를 참고하세요.
DAG 버전 관리
Airflow 3에서는 DAG 실행 중에 새 버전이 업로드되더라도 시작 시 버전을 기반으로 DAG가 완료될 때까지 실행됩니다.
- 이제 Airflow UI의 모든 DAG 실행이 해당 DAG 버전 (실행 시점의 버전)과 연결됩니다. 여기에는 작업 구조와 DAG 코드가 포함됩니다.
백필 개선
Airflow 3에서는 백필 (이전 데이터의 파이프라인 재실행) 처리 방식이 크게 개편되었습니다. 백필이 수동 프로세스에서 핵심 Airflow 엔진에 통합된 완전 관찰 가능한 기능으로 이동하고 있습니다.
- 이제 백필은 별도의 수동 프로세스로 취급되지 않고 Airflow 스케줄러 내에서 직접 관리됩니다. 이렇게 하면 확장성이 향상되고 더 정확하게 제어할 수 있습니다.
- 이제 Airflow CLI 외에도 Airflow UI 또는 API 호출을 통해 직접 백필 진행 상황을 트리거, 중지, 모니터링할 수 있습니다.
- Airflow 스케줄러는 이전 백필 실행의 상태와 상태에 대한 가시성을 개선합니다.
- 머신러닝 커뮤니티에서 오래된 데이터로 모델을 재학습하기 위해 많이 요청했지만, 백필 개선사항은 모든 ETL/ELT 워크플로에 적용됩니다.
보안 및 안정성 개선
Airflow 3에서는 태스크가 태스크 SDK를 통해 중앙 API 서버와만 통신합니다 (Airflow 2에서는 태스크가 데이터베이스에 직접 액세스할 수 있음). API 서버는 이러한 연결을 효율적으로 풀링합니다. 데이터베이스가 연결 급증으로부터 보호되므로 과부하 상태에서도 전체 환경이 더 안정적입니다.
새로운 작업 실행 인터페이스를 활용하여 Airflow 3는 작업 간의 격리를 개선하여 한 작업이 다른 작업의 데이터를 방해하거나 액세스하지 못하도록 합니다.
Airflow 3의 CLI는 직접 데이터베이스 액세스에서 벗어나고 있습니다. 새로운
airflowctl명령줄 인터페이스는 API를 통한 원격 액세스를 위해 특별히 설계된 별도의 패키지입니다. 데이터베이스에 직접 액세스하는 대신 API를 통해 Airflow와 상호작용하므로 더 안전합니다.
이벤트 기반 예약 및 데이터 애셋
데이터 세트가 데이터 애셋으로 발전했습니다. 데이터 애셋을 사용하면 Airflow가 Airflow 외부 시스템에서 생성되거나 업데이트된 데이터를 더 잘 추적하고 이에 대응할 수 있습니다.
Airflow 3에서는 워처라는 새로운 개념이 도입되었습니다. 이러한 구성요소는 데이터 애셋의 변경사항을 모니터링하여 데이터가 도착하는 순간 Airflow가 워크플로를 트리거할 수 있도록 합니다. 이제 폴링 (파일이 있는지 매분 확인)하는 대신 메시지가 메시지 대기열에 도달하는 순간 DAG를 즉시 트리거할 수 있습니다.
Airflow 3에서는 Python 데코레이터를 사용하는 새로운 애셋 중심 구문을 도입하여 개발자가 코드를 더 명확하고 직관적으로 작성할 수 있습니다.
최신 Airflow UI
- Airflow UI는 React (프런트엔드)와 FastAPI (백엔드)를 사용하여 처음부터 다시 작성되었습니다.
- 새 Airflow UI는 표준화된 REST API와 UI 작업을 위한 특수 API를 통해 작업을 실행합니다.
- Flask 구현을 FastAPI로 대체하면 Airflow UI의 응답성이 크게 향상됩니다.
- 그리드 뷰와 그래프 뷰가 통합되어 워크플로가 더 원활해졌으며, 대략적인 DAG 구조와 특정 작업 로그 간에 더 쉽게 이동할 수 있습니다.
Airflow 3의 브레이킹 체인지
Airflow 3에는 다음과 같은 주요 변경사항이 도입되었습니다.
- Airflow 2의 기존 DAG가 Airflow 3에서 기본적으로 작동된다는 보장이 없습니다. 가져오기, DAG 매개변수, 기타 구현 세부정보를 변경하여 테스트하고 조정해야 합니다.
일부 Airflow 2 구성 옵션은 Airflow 3에서 이름이 변경되거나 삭제됩니다. 매개변수에 대한 자세한 내용은 Airflow 구성 참조를 참고하세요.
작업 코드에서 Airflow 데이터베이스 액세스에 직접 액세스할 수 없습니다.
- 작업 코드에서 더 이상 Airflow 데이터베이스 세션이나 모델을 직접 가져와 사용할 수 없습니다.
airflow_db연결에서는PostgresHook및PostgresOperator를 사용할 수 없습니다.
일부 맞춤 PyPI 패키지는 새 버전의 Airflow 및 종속 항목과 호환되지 않을 수 있습니다.
REST API (
/api/v1)가/api/v2로 대체되었습니다.SubDAG는 TaskGroup, 애셋, 데이터 인식 스케줄링으로 대체됩니다.
SLA는 지원 중단되었으며 삭제되었습니다. 기한 알림으로 대체됩니다.
CLI 명령어의 subdir 인수가 삭제되었습니다.
일부 Airflow 컨텍스트 변수가 삭제되었습니다. 자세한 내용은 Airflow 문서의 호환성이 깨지는 변경사항을 참고하세요.
이제
catchup_by_defaultDAG 매개변수가 기본적으로False입니다.이제
create_cron_data_intervals구성이 기본적으로False입니다. 즉,CronDataIntervalTimetable대신CronTriggerTimetable가 기본적으로 사용됩니다.
Airflow 3 및 Airflow 2 환경의 차이점
Airflow 2를 사용하는 관리형 Airflow 환경과 Airflow 3를 사용하는 환경의 주요 차이점은 다음과 같습니다.
Airflow 3 환경의 워크로드 구성:
Airflow 3 구성요소의 다양한 메모리 사용량을 수용하도록
[celery]worker_concurrency구성 옵션의 자동 계산이 변경됩니다.Airflow 3에서는 작업 코드에서 직접 Airflow 데이터베이스에 액세스할 수 없습니다.
Airflow 3에서는
airflowctl명령줄 유틸리티를 사용하여 Airflow CLI 명령어를 실행합니다.Airflow 3 환경에서는 사전 설치된 PyPI 패키지가 다릅니다. 사전 설치된 PyPI 패키지 목록은 사전 설치된 패키지 변경 로그를 참고하세요.
Airflow 3로 나란히 마이그레이션
나란히 마이그레이션 프로세스는 다음 단계로 구성됩니다.
- Airflow 3와의 호환성을 확인합니다.
- Airflow 3 환경을 만들고 구성 재정의 및 환경 변수를 전송합니다.
- Airflow 3 환경에 PyPI 패키지를 설치합니다.
- 변수, 연결, 풀을 Airflow 3으로 전송합니다.
- Airflow 2.* 환경 버킷에서 다른 데이터를 전송합니다.
- 사용자 및 역할을 이전합니다.
- DAG가 Airflow 3에 맞게 준비되었는지 확인합니다.
- DAG를 Airflow 3 환경으로 전송합니다.
- Airflow 3 환경을 모니터링합니다.
1단계: Airflow 3 호환성 확인
Airflow 3와의 호환성을 확인하려면 다음 단계를 따르세요.
- 환경에서 Airflow 버전 2.7 이상을 사용하는지 확인합니다. 먼저 최신 Airflow 2 버전으로 업그레이드한 후 Airflow 3로 마이그레이션하는 것이 좋습니다.
- 환경이 정상이고 한동안 문제 없이 실행되는지 확인합니다.
- DAG 및 Airflow 구성에서 Airflow 3에서 삭제된 기능이나 기능을 사용하지 않는지 확인합니다.
- Airflow 3와 호환되도록 DAG를 변경하는 방법을 참고하여 마이그레이션 프로세스 중에 DAG를 변경해야 하는지 확인하세요.
- 커뮤니티 버전의 Airflow에서 제공하는
ruff도구를 사용하여 Airflow DAG의 호환성을 확인합니다. 자세한 내용은 Airflow 문서의 Airflow DAG의 호환성 확인을 참고하세요.
2단계: Airflow 3 환경 만들기와 구성 재정의 및 환경 변수 전송
이 단계에서는 Airflow 3으로 새 관리형 Airflow (3세대) 환경을 만들고 Airflow 2 환경에서 구성 매개변수 전송을 시작합니다.
관리형 Airflow (3세대) 환경 만들기 단계에 따라 다음을 실행합니다.
- Airflow 빌드를 선택할 때 Airflow 3가 포함된 빌드를 선택합니다.
Airflow 2 환경에서 호환되는 모든 Airflow 구성 옵션 재정의를 복사합니다.
Airflow 2 환경의 모든 환경 변수를 복사합니다.
Airflow 3으로 환경을 만듭니다.
다음 표에는 몇 가지 Airflow 구성 옵션 변경사항이 나와 있습니다. 이 목록은 일부 예시일 뿐 모든 내용을 포함하지는 않습니다. Airflow 구성 옵션의 변경사항에 대한 자세한 내용은 Airflow 문서의 Airflow 구성 참조 및 Airflow 출시 노트를 참고하세요.
| Airflow 2 옵션 | Airflow 3 옵션 |
|---|---|
[scheduler]min_file_process_interval
|
[dag_processor]min_file_process_interval
|
[webserver]rbac_user_registration_role
|
[api]rbac_user_registration_role
|
[core]dag_file_processor_timeout
|
[dag_processor]dag_file_processor_timeout
|
[scheduler]dag_dir_list_interval
|
[dag_processor]refresh_interval
|
[scheduler]max_threads
|
[dag_processor]parsing_processes
|
[scheduler]parsing_processes
|
[dag_processor]parsing_processes
|
[webserver]instance_name
|
[api]instance_name
|
[scheduler]scheduler_zombie_task_threshold
|
[scheduler]task_instance_heartbeat_timeout
|
[webserver]rbac
|
지원 중단됨 |
[api]auth_backend=airflow.api.auth.backend.deny_all
|
지원 중단됨 |
[api]auth_backends=airflow.api.auth.backend.deny_all
|
지원 중단됨 |
[api]composer_auth_user_registration_role
|
지원 중단됨 |
3단계: Airflow 3 환경에 PyPI 패키지 설치
Airflow 3 환경이 생성되면 여기에 PyPI 패키지를 설치합니다.
- Airflow 2 환경에서 PyPI 패키지 요구사항을 복사합니다.
- PyPI 패키지 업데이트 작업을 시작하고 환경이 업데이트될 때까지 기다립니다.
Airflow 3 환경에서는 다른 사전 설치된 패키지 집합을 사용하므로 업데이트 작업 중에 PyPI 패키지 충돌이 발생할 수 있습니다. PyPI 패키지 충돌 문제 해결에 관한 자세한 내용은 사전 설치된 PyPI 패키지와의 충돌을 참고하세요.
4단계: Airflow 2에서 변수, 연결, 풀 내보내기
변수나 연결이 없는 경우 해당 내보내기 및 가져오기 명령어를 건너뜁니다.
default_pool 이외의 커스텀 풀이 있다면 풀만 전송하면 됩니다. 그 밖의 경우에는 풀을 내보내고 가져오는 명령어를 건너뜁니다.
Airflow 2 환경에서 변수를 내보냅니다.
gcloud composer environments run AIRFLOW_2_ENV \ --location AIRFLOW_2_LOCATION \ variables -- export /home/airflow/gcs/data/variables.json다음을 바꿉니다.
AIRFLOW_2_ENV: Airflow 2 환경의 이름입니다.AIRFLOW_2_LOCATION: Airflow 2 환경이 있는 리전입니다.
Airflow 2 환경에서 연결을 내보냅니다.
gcloud composer environments run AIRFLOW_2_ENV \ --location AIRFLOW_2_LOCATION \ connections -- export /home/airflow/gcs/data/connections.json다음을 바꿉니다.
AIRFLOW_2_ENV: Airflow 2 환경의 이름입니다.AIRFLOW_2_LOCATION: Airflow 2 환경이 있는 리전입니다.
Airflow 2 환경에서 풀을 내보냅니다.
gcloud composer environments run AIRFLOW_2_ENV \ --location AIRFLOW_2_LOCATION \ pools -- export /home/airflow/gcs/data/pools.json다음을 바꿉니다.
AIRFLOW_2_ENV: Airflow 2 환경의 이름입니다.AIRFLOW_2_LOCATION: Airflow 2 환경이 있는 리전입니다.
Airflow 2 환경 버킷의 이름을 가져옵니다.
gcloud composer environments describe AIRFLOW_2_ENV \ --location AIRFLOW_2_LOCATION \ --format="value(storageConfig.bucket)"다음을 바꿉니다.
AIRFLOW_2_ENV: Airflow 2 환경의 이름입니다.AIRFLOW_2_LOCATION: Airflow 2 환경이 있는 리전입니다.
Airflow 2 환경 버킷의
/data디렉터리에서variables.json,connections.json,pools.json파일을 로컬 디렉터리로 다운로드합니다.gcloud storage cp gs://AIRFLOW_2_BUCKET/data/variables.json ./variables.json gcloud storage cp gs://AIRFLOW_2_BUCKET/data/connections.json ./connections.json gcloud storage cp gs://AIRFLOW_2_BUCKET/data/pools.json ./pools.json다음을 바꿉니다.
AIRFLOW_2_BUCKET: 이전 단계에서 가져온 Airflow 2 환경의 버킷 이름입니다.
5단계: Airflow 3로 변수, 연결, 풀 가져오기
변수나 연결이 없는 경우 해당 내보내기 및 가져오기 명령어를 건너뜁니다.
default_pool 이외의 커스텀 풀이 있다면 풀만 전송하면 됩니다. 그 밖의 경우에는 풀을 내보내고 가져오는 명령어를 건너뜁니다.
Airflow 3 환경의 Airflow CLI 명령어를 실행하도록
airflowctl구성airflowctl를 사용하여 변수, 연결, 풀을 Airflow 3 환경으로 가져옵니다.airflowctl variables import ./variables.json airflowctl connections import ./connections.json airflowctl pools import ./pools.json변수, 연결, 풀이 Airflow 3 환경으로 가져와졌는지 확인합니다.
airflowctl variables list airflowctl connections list airflowctl pools listJSON 파일 정리:
gcloud storage rm gs://AIRFLOW_2_BUCKET/data/variables.json gcloud storage rm gs://AIRFLOW_2_BUCKET/data/connections.json gcloud storage rm gs://AIRFLOW_2_BUCKET/data/pools.json rm ./variables.json rm ./connections.json rm ./pools.json다음을 바꿉니다.
AIRFLOW_2_BUCKET: Airflow 2 환경의 버킷 이름입니다.
6단계: Airflow 2 환경 버킷에서 기타 데이터 전송
이 단계에서는 Airflow 2 환경의 버킷에서 남은 데이터를 전송합니다.
Airflow 3 환경의 버킷 이름을 가져옵니다.
gcloud composer environments describe AIRFLOW_3_ENV \ --location AIRFLOW_3_LOCATION \ --format="value(storageConfig.bucket)"다음을 바꿉니다.
AIRFLOW_3_ENV: Airflow 3 환경의 이름입니다.AIRFLOW_3_LOCATION: Airflow 3 환경이 있는 리전입니다.
Airflow 2 환경의 버킷에서 Airflow 3 환경의 버킷에 있는
/plugins디렉터리로 플러그인을 내보냅니다.gcloud composer environments storage plugins export \ --destination=AIRFLOW_3_BUCKET/plugins \ --environment=AIRFLOW_2_ENV \ --location=AIRFLOW_2_LOCATION다음을 바꿉니다.
AIRFLOW_3_BUCKET: 이전 단계에서 가져온 Airflow 3 환경의 버킷 이름입니다.AIRFLOW_2_ENV: Airflow 2 환경의 이름입니다.AIRFLOW_2_LOCATION: Airflow 2 환경이 있는 리전입니다.
/plugins디렉터리를 성공적으로 가져왔는지 확인합니다.gcloud composer environments storage plugins list \ --environment=AIRFLOW_3_ENV \ --location=AIRFLOW_3_LOCATION다음을 바꿉니다.
AIRFLOW_3_ENV: Airflow 3 환경의 이름입니다.AIRFLOW_3_LOCATION: Airflow 3 환경이 있는 리전입니다.
/data디렉터리를 Airflow 2 환경에서 Airflow 3 환경으로 내보냅니다.gcloud composer environments storage data export \ --destination=AIRFLOW_3_BUCKET/data \ --environment=AIRFLOW_2_ENV \ --location=AIRFLOW_2_LOCATION다음을 바꿉니다.
AIRFLOW_3_BUCKET: 이전 단계에서 가져온 Airflow 3 환경의 버킷 이름입니다.AIRFLOW_2_ENV: Airflow 2 환경의 이름입니다.AIRFLOW_2_LOCATION: Airflow 2 환경이 있는 리전입니다.
/data폴더를 성공적으로 가져왔는지 확인합니다.gcloud composer environments storage data list \ --environment=AIRFLOW_3_ENV \ --location=AIRFLOW_3_LOCATION
7단계: 사용자 및 역할 전송
airflowctl에서는 아직 users 및 roles 명령어를 지원하지 않으므로 사용자 및 역할을 이전할 수 없습니다.
8단계: DAG가 Airflow 3에 맞게 준비되었는지 확인
Airflow 3과 호환되도록 Airflow DAG를 조정합니다.
직접 Airflow 데이터베이스 액세스를 위해 맞춤 작성된 작업을 검토합니다.
Airflow 3에서는 연산자가 데이터베이스 세션을 사용하여 Airflow 메타데이터 데이터베이스에 직접 액세스할 수 없습니다. 맞춤 연산자가 있는 경우 코드를 검토하여 직접 데이터베이스 액세스 호출이 없는지 확인하세요.
다음 대체 방법을 사용하여 작업에서 직접 Airflow 데이터베이스 액세스를 이전할 수 있습니다.
Airflow 데이터베이스 콘텐츠를 Cloud SQL 인스턴스로 내보내기를 통해 Airflow 데이터베이스에 액세스합니다.
Airflow Python 클라이언트를 사용합니다. Airflow 커뮤니티 버전에서 제공하는 Python 클라이언트에는
DagRuns,TaskInstances,Variables,Connections,XComs등 대부분의 테이블에 정의된 API가 있습니다.apache-airflow-client패키지는 관리형 Airflow Airflow 3 빌드에 이미 사전 설치되어 있습니다.DAG에서
BashOperator을 통해airflowctl를 실행합니다.
내보낸 Airflow 데이터베이스를 쿼리하는 것이 사용 사례에 적합하지 않고 Airflow Python 클라이언트와
airflowctl모두 필요한 기능을 제공하지 않는 경우 Airflow 커뮤니티 버전에서 새 API 엔드포인트 또는 작업 SDK 기능을 요청하는 것이 좋습니다.KubernetesExecutor작업이 있는 경우queue="kubernetes"을executor="KubernetesExecutor"로 바꿔 연산자 정의를 조정합니다.Airflow 3의
KubernetesExecutor작업 예시:PythonOperator( task_id="airflow3_kubernetes_executor_task", dag=dag, python_callable=f, executor="KubernetesExecutor", )작업 코드에서
AIRFLOW__WEBSERVER__BASE_URL환경 변수를 사용하는 경우[api]base_urlAirflow 구성 옵션으로 대체합니다.Airflow 3에서 이 값을 가져오는 예:
from airflow.configuration import conf webserver_base_url = conf.get("api", "base_url")
9단계: DAG를 Airflow 3 환경으로 전송
환경 간에 DAG를 전송할 때는 다음과 같은 잠재적 문제가 발생할 수 있습니다.
두 환경 모두에 DAG가 사용 설정(일시중지되지 않음)된 경우 각 환경은 예약된 일정에 따라 자체 DAG 사본을 실행합니다. 그로 인해 동일한 데이터 및 실행 시간에 동시 DAG 실행이 발생할 수 있습니다.
DAG 포착 때문에 Airflow에서 DAG에 지정된 시작 날짜부터 시작되는 추가 DAG 실행을 예약합니다. 새 Airflow 인스턴스가 Airflow 2 환경의 DAG 실행 기록을 고려하지 않기 때문입니다. 이로 인해 지정된 시작 날짜부터 시작되는 다수의 DAG 실행 작업이 예약될 수 있습니다.
동시 DAG 실행 방지
Airflow 3 환경에서 dags_are_paused_at_creation Airflow 구성 옵션을 재정의합니다. 이 변경 후에는 모든 새로운 DAG가 기본적으로 일시중지됩니다.
| 섹션 | 키 | 값 |
|---|---|---|
core |
dags_are_paused_at_creation |
True |
추가 또는 누락 DAG 실행 방지
Airflow 3 환경으로 전송하는 DAG에 새 정적 시작 날짜를 지정합니다.
논리적 날짜의 차이 및 중복을 막으려면 Airflow 3 환경에서 첫 번째 DAG 실행이 일정 간격의 다음 어커런스에 이루어져야 합니다. 이를 위해서는 DAG의 새 시작 날짜를 Airflow 2 환경의 마지막 실행 날짜 이전으로 설정합니다.
예를 들어 DAG가 Airflow 2 환경에서 매일 15:00, 17:00, 21:00에 실행되면 마지막 DAG 실행이 15:00에 수행되며 DAG를 15:15에 전송하면 Airflow 3 환경의 시작 날짜는 오늘 14:45일 수 있습니다. Airflow 3 환경에서 DAG를 사용 설정하면 Airflow는 DAG 실행을 17:00으로 예약합니다.
또 다른 예시로, DAG가 Airflow 2 환경에서 매일 00:00에 실행되는 경우, DAG 실행이 2026년 3월 26일 00:00에 수행되었고, 2026년 3월 26일 13:00에 DAG 전송을 계획한 경우 Airflow 3 환경의 시작 날짜는 2026년 3월 25일 23:45일 수 있습니다. Airflow 3 환경에서 DAG를 사용 설정한 다음 Airflow는 2026년 3월 27일 00:00에 DAG 실행을 예약합니다.
DAG를 하나씩 Airflow 3 환경으로 전송
각 DAG를 다음 절차에 따라 전송합니다.
DAG의 새 시작 날짜가 이전 섹션에서 설명한 대로 설정되었는지 확인합니다.
Airflow 3 환경으로 업데이트된 DAG를 업로드합니다. 구성 재정의로 인해 이 DAG가 Airflow 3 환경에서 일시 중지되므로, DAG 실행이 아직 예약되지 않았습니다.
Airflow 웹 인터페이스에서 DAG로 이동하여 보고된 DAG 문법 오류를 확인합니다.
DAG를 전송할 계획인 경우:
Airflow 2 환경에서 DAG를 일시중지합니다.
Airflow 3 환경에서 DAG의 일시중지를 해제합니다.
새 DAG 실행이 올바른 시간에 예약되었는지 확인합니다.
Airflow 3 환경에서 DAG 실행이 이루어질 때까지 기다린 후 실행이 성공했는지 확인합니다.
DAG 실행 성공 여부에 따라 다음을 수행합니다.
DAG 실행이 성공하면 계속 진행하여 Airflow 3 환경에서 DAG를 사용할 수 있습니다. Airflow 2 버전 DAG는 삭제하는 것이 좋습니다.
DAG 실행이 실패하면 Airflow 3에서 성공적으로 실행될 때까지 DAG 문제 해결을 시도합니다.
필요한 경우 언제든지 DAG의 Airflow 2 버전으로 돌아갈 수 있습니다.
Airflow 3 환경에서 DAG를 일시중지합니다.
Airflow 3 환경에서 DAG의 일시중지를 해제합니다. 그러면 실패한 DAG 실행과 동일한 날짜 및 시간에 새 DAG 실행이 예약됩니다.
Airflow 3 버전의 DAG를 계속 진행할 준비가 되면 시작 날짜를 조정하고 새 버전의 DAG를 Airflow 3 환경에 업로드한 후 절차를 반복합니다.
10단계: Airflow 3 환경 모니터링
모든 DAG 및 구성을 Airflow 3 환경으로 전송한 후 잠재적 문제, 실패한 DAG 실행, 전반적인 환경 상태를 모니터링합니다. Airflow 3 환경이 충분한 시간 동안 문제없이 실행되면 Airflow 2 환경을 삭제해도 됩니다.