Managed Airflow (3세대) | Managed Airflow (2세대) | Managed Airflow (기존 1세대)
이 페이지에는 알려진 Managed Airflow 문제가 나열되어 있습니다. 문제 수정에 대한 자세한 내용은 출시 노트를 참조하세요.
업로드된 DAG 파일의 첫 번째 DAG 실행에서 여러 개의 태스크가 실패함
DAG 파일을 업로드하면 첫 DAG의 처음 몇 개 태스크가 Unable to read remote log... 오류와 함께 실패하는 경우가 있습니다. 이 문제는 환경의 버킷, Airflow 작업자, 환경의 Airflow 스케줄러 간에 DAG 파일이 동기화되어 발생합니다. 스케줄러가 DAG 파일을 가져와 작업자가 실행하도록 예약하고 작업자에 아직 DAG 파일이 없으면 태스크 실행이 실패합니다.
이 문제를 완화하기 위해 Airflow 2를 사용하는 환경은 기본적으로 실패한 태스크에 대해 두 번의 재시도를 수행하도록 구성됩니다. 태스크가 실패하면 5분 간격으로 두 번 재시도됩니다
Managed Airflow는 Apache Log4j 2 취약점 (CVE-2021-44228)의 영향을 받지 않음
Apache Log4j 2 취약점 (CVE-2021-44228)에 대한 대응으로 Managed Airflow는 자세한 조사를 실시했으며 Managed Airflow는 이 취약점 공격에 노출되지 않는다고 보고 있습니다.
Airflow UI가 변경되면 플러그인이 다시 로드되지 않을 수 있음
플러그인이 다른 모듈을 가져오는 여러 파일로 구성된 경우 Airflow UI에서 플러그인이 다시 로드되어야 한다는 사실을 인식하지 못할 수 있습니다. 이 경우 환경의 Airflow 웹 서버를 다시 시작합니다.
Airflow UI에 액세스할 때 오류 504 발생
Airflow UI에 액세스할 때 504 Gateway Timeout 오류가 발생할 수 있습니다. 이 오류의 원인은 다음과 같습니다.
일시적인 통신 문제입니다. 이 경우 나중에 Airflow UI에 액세스해 보세요. Airflow 웹 서버를 다시 시작할 수도 있습니다.
(Managed Airflow (3세대)만 해당) 연결 문제입니다. Airflow UI를 영구적으로 사용할 수 없고 제한 시간 또는 504 오류가 발생하는 경우 환경에서
*.composer.googleusercontent.com에 액세스할 수 있는지 확인하세요.(Managed Airflow (2세대)만 해당) 연결 문제입니다. Airflow UI를 영구적으로 사용할 수 없고 제한 시간 또는 504 오류가 발생하는 경우 환경에서
*.composer.cloud.google.com에 액세스할 수 있는지 확인하세요. 비공개 Google 액세스를 사용하고private.googleapis.com가상 IP를 통해 트래픽을 전송하거나, VPC 서비스 제어를 사용하고restricted.googleapis.com가상 IP를 통해 트래픽을 전송할 경우 Cloud DNS가*.composer.cloud.google.com도메인 이름으로도 구성됐는지 확인하세요.응답 없는 Airflow 웹 서버 오류 504가 지속되더라도 특정 시점에 Airflow UI에 계속 액세스할 수 있으면 과부하가 발생하여 Airflow 웹 서버가 응답하지 않을 수 있습니다. 웹 서버의 확장 및 성능 매개변수를 늘려보세요.
Airflow UI에 액세스할 때 502 오류 발생
502 Internal server exception 오류는 Airflow UI가 들어오는 요청을 처리할 수 없음을 나타냅니다. 이 오류의 원인은 다음과 같습니다.
일시적인 통신 문제입니다. 나중에 Airflow UI에 액세스해 보세요.
웹 서버를 시작할 수 없습니다. 웹 서버를 시작하려면 먼저 구성 파일을 동기화해야 합니다. 웹 서버 로그에서
GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp또는GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp와 비슷하게 표시된 로그 항목을 확인합니다. 이러한 오류가 표시되면 오류 메시지에 언급된 파일이 아직 환경의 버킷에 있는지 확인합니다.보관 정책 구성 등으로 인해 실수로 삭제된 경우 복원할 수 있습니다.
환경에 새 환경 변수를 설정합니다. 모든 변수 이름과 값을 사용할 수 있습니다.
Airflow 구성 옵션을 재정의합니다. 존재하지 않는 Airflow 구성 옵션을 사용할 수 있습니다.
[webserver]analytics_tool을 재정의한 후 Airflow UI에 액세스할 때 오류 500 발생
Airflow 2 환경에서 익명 Airflow UI 사용 데이터를 분석 서비스 (예: Google 애널리틱스, Segment, MetaRouter, Matomo)로 라우팅하도록 [webserver]analytics_tool Airflow 구성 옵션을 재정의하는 경우 환경 업데이트가 성공한 후 Airflow UI에 액세스하면 (500) Internal Server Error 응답이 반환되고 Airflow 웹 서버 로그에 다음 오류 중 하나가 표시될 수 있습니다.
airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config
airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config
Airflow 2에서 [webserver]analytics_tool가 설정되면 Airflow 웹 서버에서 Airflow UI를 렌더링할 때 [webserver] 섹션의 컴패니언 분석 옵션도 정의해야 합니다.
Airflow 3에서는 [webserver]analytics_tool, [webserver]analytics_id, [webserver]analytics_url 구성 옵션이 삭제됩니다.
해결책:
[webserver]analytics_toolAirflow 구성 옵션의 재정의를 삭제합니다.- 필수 Airflow 구성 옵션을 모두 함께 지정합니다.
[webserver]analytics_tool[webserver]analytics_id[webserver]analytics_url(분석 도구에서 맞춤 URL을 사용하지 않더라도 Airflow 2.9 이상에서 필요)
트리 보기에서 태스크 인스턴스로 마우스를 가져가면 포착되지 않은 TypeError 발생
Airflow 2에서 기본이 아닌 시간대가 사용되면 Airflow UI의 트리 보기가 올바르게 작동하지 않는 경우가 있습니다. 이 문제를 해결하려면 Airflow UI에서 시간대를 명시적으로 구성합니다.
스케줄러 및 작업자의 빈 폴더
Managed Airflow는 Airflow 작업자 및 스케줄러에서 빈 폴더를 적극적으로 삭제하지 않습니다. 이러한 항목은 해당 폴더가 버킷에 있었고 결국 삭제되었을 때 환경 버킷 동기화 프로세스로 인해 생성될 수 있습니다.
권장사항: 이러한 빈 폴더를 건너뛸 수 있도록 DAG를 조정합니다.
이러한 항목은 환경 클러스터의 축소 또는 유지보수 작업의 결과 등에 따라 해당 구성요소를 다시 시작할 때 결국 Airflow 스케줄러 및 작업자의 로컬 스토리지에서 삭제됩니다.
Kerberos 지원
Managed Airflow는 Airflow Kerberos 구성을 지원하지 않습니다.
Managed Airflow (2세대) 및 Managed Airflow (3세대)에서 컴퓨팅 클래스 지원
Managed Airflow (3세대) 및 Managed Airflow (2세대)는 범용 컴퓨팅 클래스만 지원합니다. 즉, 다른 컴퓨팅 클래스(예: 분산 또는 수평 확장)를 요청하는 포드를 실행할 수 없습니다.
범용 클래스를 사용하면 컴퓨팅 클래스 최대 요청에 설명된 대로 최대 110GB의 메모리와 최대 30개의 CPU를 요청하는 포드를 실행할 수 있습니다.
ARM 기반 아키텍처를 사용하거나 CPU와 메모리가 더 필요하다면 Managed Airflow (3세대) 및 Managed Airflow (2세대) 클러스터 내에서 지원되지 않는 다른 컴퓨팅 클래스를 사용해야 합니다.
권장사항: GKEStartPodOperator를 사용하여 선택한 컴퓨팅 클래스를 지원하는 다른 클러스터에서 Kubernetes 포드를 실행하세요. 다른 컴퓨팅 클래스가 필요한 커스텀 포드를 실행하는 경우 Managed Airflow 이외의 클러스터에서도 실행해야 합니다.
Cloud SQL 스토리지를 줄일 수 없음
Managed Airflow는 Cloud SQL을 사용하여 Airflow 데이터베이스를 실행합니다. 시간이 지나면서 Cloud SQL 인스턴스의 디스크 스토리지가 증가할 수 있는데 이는 Airway 데이터베이스 증가 시 Cloud SQL 작업으로 저장된 데이터에 맞춰 디스크가 확장되기 때문입니다.
Cloud SQL 디스크 크기를 축소할 수는 없습니다.
최소 Cloud SQL 디스크 크기를 사용하려면 스냅샷을 사용하여 Managed Airflow 환경을 다시 만들면 됩니다.
Cloud SQL에서 레코드를 삭제한 후 데이터베이스 디스크 사용량 측정항목이 감소하지 않음
Postgres 또는 MySQL과 같은 관계형 데이터베이스는 삭제되거나 업데이트될 때 행을 물리적으로 삭제하지 않습니다. 대신 데이터 일관성을 유지하고 동시 실행 트랜잭션 차단을 방지하기 위해 이를 '데드 튜플'로 표시합니다.
MySQL과 Postgres는 모두 레코드 삭제 후 공간을 회수하는 메커니즘을 구현합니다.
데이터베이스가 사용되지 않은 디스크 공간을 강제로 회수하도록 할 수 있지만 이 작업은 리소스를 많이 소모하므로 데이터베이스를 추가로 잠가 Managed Airflow를 사용할 수 없게 됩니다. 따라서 사용되지 않은 공간을 회수하는 빌드 메커니즘을 사용하는 것이 좋습니다.
액세스 차단됨: 승인 오류
이 문제가 사용자에게 영향을 미치면 액세스 차단됨: 승인 오류 대화상자에 Error 400: admin_policy_enforced 메시지가 포함됩니다.
Google Workspace에서 API 제어 > 구성되지 않은 서드 파티 앱 > 사용자가 서드 파티 앱에 액세스하도록 허용하지 않음 옵션이 사용 설정되어 있고 Managed Airflow 앱의 Apache Airflow가 명시적으로 허용되지 않은 경우 사용자는 애플리케이션을 명시적으로 허용하지 않는 한 Airflow UI에 액세스할 수 없습니다.
액세스를 허용하려면 Google Workspace에서 Airflow UI에 대한 액세스 허용의 단계를 수행합니다.
Airflow UI에 액세스할 때 로그인 루프 발생
이 문제는 다음과 같은 원인으로 인해 발생할 수 있습니다.
Chrome Enterprise Premium 컨텍스트 인식 액세스 바인딩이 기기 속성에 의존하는 액세스 수준과 함께 사용되고 Managed Airflow 앱의 Apache Airflow가 제외되지 않은 경우 로그인 루프로 인해 Airflow UI에 액세스할 수 없습니다. 액세스를 허용하려면 컨텍스트 인식 액세스 바인딩에서 Airflow UI에 대한 액세스 허용의 단계를 수행합니다.
프로젝트를 보호하는 VPC 서비스 제어 경계에 인그레스 규칙이 구성되어 있고 Managed Airflow 서비스에 대한 액세스를 허용하는 인그레스 규칙이
ANY_SERVICE_ACCOUNT또는ANY_USER_ACCOUNTID 유형을 사용하는 경우 사용자가 Airflow UI에 액세스할 수 없어 로그인 루프가 발생합니다. 이 시나리오를 해결하는 방법에 대한 자세한 내용은 VPC 서비스 제어 인그레스 규칙에서 Airflow UI에 대한 액세스 허용을 참조하세요.
Airflow 웹 서버에서 /data 폴더를 사용할 수 없음
Managed Airflow (2세대) 및 Managed Airflow (3세대)에서 Airflow 웹 서버는 대부분 읽기 전용 구성요소이며 Managed Airflow는 data/ 폴더를 이 구성요소에 동기화하지 않습니다.
경우에 따라 Airflow 웹 서버를 포함한 모든 Airflow 구성요소 간에 공통 파일을 공유해야 할 수 있습니다.
해결책:
웹 서버와 공유할 파일을 PYPI 모듈에 래핑하고 일반 PYPI 패키지로 설치합니다. PYPI 모듈이 환경에 설치된 후에는 파일이 Airflow 구성요소의 이미지에 추가되고 이를 사용할 수 있습니다.
파일을
plugins/폴더에 추가합니다. 이 폴더는 Airflow 웹 서버와 동기화됩니다.
모니터링의 비연속 DAG 파싱 시간 및 DAG 모음 크기 다이어그램
모니터링 대시보드에 비연속 DAG 파싱 시간 및 DAG 모음 크기 다이어그램이 표시되면 DAG 파싱 시간이 길어(5분 초과) 문제가 있음을 나타냅니다.
해결책: 총 DAG 파싱 시간을 5분 미만으로 유지하는 것이 좋습니다. DAG 파싱 시간을 줄이려면 DAG 작성 가이드라인을 따르세요.
태스크 로그가 지연되어 표시됨
증상:
- Managed Airflow (3세대)에서는 Airflow 태스크 로그가 즉시 표시되지 않고 몇 분 정도 지연됩니다.
- Airflow 로그에
Logs not found for Cloud Logging filter메시지가 표시될 수 있습니다.
원인:
환경에서 동시에 많은 태스크를 실행하는 경우 환경 인프라 크기가 모든 로그를 충분히 빠르게 처리하기에 작으므로 태스크 로그가 지연될 수 있습니다.
해결책:
- 성능을 높이려면 환경 인프라 크기를 늘리는 것이 좋습니다.
- 태스크가 동시에 실행되지 않도록 시간 경과에 따라 DAG 실행을 분산합니다.
KubernetesPodOperator 및 KubernetesExecutor의 시작 시간 증가
KubernetesPodOperator로 생성된 포드와 KubernetesExecutor로 실행된 태스크의 시작 시간이 늘어납니다. Managed Airflow팀에서 해결 방법을 찾고 있으며 문제가 해결되면 공지할 예정입니다.
해결 방법:
- 더 많은 CPU로 포드를 시작합니다.
- 가능하면 이미지를 최적화합니다 (레이어 수 줄이기, 크기 줄이기).
프로젝트의 결제 계정이 삭제 또는 비활성화되거나 Cloud Composer API가 사용 중지된 후 환경이 오류 상태임
이러한 문제의 영향을 받는 Managed Airflow 환경은 복구할 수 없습니다.
- 프로젝트의 결제 계정이 삭제되거나 비활성화된 후 나중에 다른 계정이 연결된 경우에도 마찬가지입니다.
- 프로젝트에서 Cloud Composer API가 사용 중지된 후 나중에 사용 설정된 경우에도 마찬가지입니다.
다음과 같은 방법으로 문제를 해결할 수 있습니다.
환경의 버킷에 저장된 데이터에 계속 액세스할 수 있지만 환경 자체는 더 이상 사용할 수 없습니다. 새 Managed Airflow 환경을 만든 후 DAG와 데이터를 전송할 수 있습니다.
환경을 복구할 수 없게 만드는 작업을 수행하려면 환경의 스냅샷을 만들어 데이터를 백업해야 합니다. 이렇게 하면 다른 환경을 만들고 이 스냅샷을 로드하여 데이터를 전송할 수 있습니다.
[core]execute_tasks_new_python_interpreter가 True로 설정된 경우 Airflow 태스크의 로그가 수집되지 않음
[core]execute_tasks_new_python_interpreter Airflow 구성 옵션이 True로 설정된 경우 Managed Airflow는 Airflow 태스크의 로그를 수집하지 않습니다.
예시 답안:
- 이 구성 옵션의 재정의를 삭제하거나 값을
False로 설정합니다.
환경이 삭제될 때 네트워크 연결을 삭제하는 중에 오류가 발생했습니다.
동일한 네트워크 연결을 공유하는 여러 환경이 동시에 삭제되면 일부 삭제 작업이 오류와 함께 실패합니다.
증상
다음 오류가 생성됩니다.
Got error while removing Network Attachment: <error code>
보고된 오류 코드는 Bad request: <resource> is not ready 또는 Precondition failed: Invalid fingerprint일 수 있습니다.
가능한 해결 방법:
동일한 네트워크 연결을 사용하는 환경을 하나씩 삭제합니다.
환경을 삭제하기 전에 VPC 네트워크에 대한 연결을 사용 중지합니다. 자동 환경 삭제에는 이 해결 방법을 사용하는 것이 좋습니다.
여러 google-api-core 패키지 버전에서 환경 성능 저하
2.28.0~2.30.2 버전
2.28.0에서 2.30.2까지의 google-api-core 사전 설치된 패키지 버전으로 인해 환경 성능이 저하되어 태스크 실행 시간이 길어지고 태스크를 큐에 추가된 상태에서 실행 상태로 이동하는 데 시간이 더 오래 걸릴 수 있습니다.
영향을 받는 Managed Airflow (3세대) 빌드:
- composer-3-airflow-3.1.7-build.0~composer-3-airflow-3.1.7-build.5
- composer-3-airflow-3.1.0-build.5~composer-3-airflow-3.1.0-build.10
- composer-3-airflow-2.11.1-build.0
- composer-3-airflow-2.10.5-build.22에서 composer-3-airflow-2.10.5-build.33
- composer-3-airflow-2.9.3-build.42~composer-3-airflow-2.9.3-build.53
영향을 받는 Managed Airflow (3세대) 빌드:
- composer-2.16.10-airflow-2.11.1
- composer-2.16.0-airflow-2.10.5에서 composer-2.16.10-airflow-2.10.5로
- composer-2.16.0-airflow-2.9.3에서 composer-2.16.10-airflow-2.9.3으로
사전 설치된 google-api-core 버전 2.27.0이 포함되어 있고 이 문제의 영향을 받지 않는 다음 빌드 중 하나로 환경을 업그레이드합니다.
- composer-3-airflow-2.11.1-build.1
- composer-3-airflow-2.10.5-build.34
- composer-3-airflow-2.9.3-build.54
- composer-2.16.11-airflow-2.11.1
- composer-2.16.11-airflow-2.10.5
- composer-2.16.11-airflow-2.9.3
또는 google-api-core 2.43.1 이상이 포함된 이미지로 업그레이드하거나 호환되는 버전을 수동으로 설치합니다.
Python 3.11에서 google-api-core 버전 2.30.3~2.43.0은 2026년 10월 24일부터 별도의 성능 문제를 일으킵니다. 환경에서 Python 3.11을 실행하는 경우 Python 3.11의 버전 2.30.3~2.43.0에 나열된 해결 방법 중 하나를 적용합니다.
Python 3.11의 버전 2.30.3~2.43.0
2026년 10월 24일부터 google-api-core 패키지 버전 2.30.3~2.43.0은 새 Python 하위 프로세스에서 Google Cloud 클라이언트 라이브러리를 가져올 때마다 설치된 패키지 메타데이터를 스캔하는 Python 3.11 지원 중단 검사를 실행합니다.
Python 3.11을 실행하는 Managed Airflow 환경에서는 이 동작으로 인해 성능이 저하될 수 있습니다. 이 문제는 DAG가 많거나, 단기 실행 태스크가 자주 발생하거나, 데이터 계보 통합이 사용 설정된 환경에서 더 심각합니다.
증상은 다음과 같습니다.
- Airflow DAG 프로세서의 DAG 파싱 시간 및 CPU 사용량이 증가합니다.
- Airflow 작업자의 태스크 실행 시간이 길어지고 CPU 사용량이 증가합니다.
- Python 3.11 지원이 2027년 10월 24일에 종료된다는
google/api_core/_python_version_support.py의FutureWarning로그 항목이 자주 표시됩니다.
이 문제는 다음 빌드를 포함하여 google-api-core 버전 2.30.3~2.43.0이 사전 설치되거나 수동으로 설치된 모든 Python 3.11 환경에 영향을 미칩니다.
이 문제는 다음 Managed Airflow (3세대) 빌드에 영향을 미칩니다.
- composer-3-airflow-3.3.1-build.0~composer-3-airflow-3.3.1-build.5
- composer-3-airflow-3.2.2-build.0~composer-3-airflow-3.2.2-build.9
- composer-3-airflow-3.1.8-build.0~composer-3-airflow-3.1.8-build.4
- composer-3-airflow-3.1.7-build.7~composer-3-airflow-3.1.7-build.13
- composer-3-airflow-2.11.1-build.3~composer-3-airflow-2.11.1-build.22
- composer-3-airflow-2.10.5-build.36~composer-3-airflow-2.10.5-build.52
영향을 받는 Managed Airflow (3세대) 빌드:
- composer-2.17.0-airflow-2.11.1~composer-2.17.16-airflow-2.11.1
- composer-2.17.0-airflow-2.10.5~composer-2.17.13-airflow-2.10.5
해결 방법:
환경의 이미지 버전에 따라 다음 옵션 중 하나를 선택합니다.
옵션 1. Airflow 3을 사용하는 호환되는 Managed Airflow (3세대) 빌드만 해당:
>=2.43.1버전 제약 조건이 있는google-api-corePyPI 패키지를 설치합니다.호환되는 Managed Airflow (3세대) 빌드:
- composer-3-airflow-3.3.1-build.0~composer-3-airflow-3.3.1-build.5
- composer-3-airflow-3.2.2-build.1~composer-3-airflow-3.2.2-build.9
- composer-3-airflow-3.1.8-build.3에서 composer-3-airflow-3.1.8-build.4로
composer-3-airflow-3.2.2-build.0및composer-3-airflow-3.1.8-build.0~build.2를 포함한 Airflow 2 빌드 또는 이전 Airflow 3 빌드에서는 이 옵션을 사용하지 마세요. 이러한 빌드에서google-api-core2.43.1은opentelemetry-api>=1.44.0가 필요하므로 종속 항목 충돌을 일으킵니다. 이러한 빌드의 경우 옵션 2를 사용하세요.옵션 2. 영향을 받는 모든 Managed Airflow (3세대) 및 Managed Airflow (2세대) 빌드:
sitecustomize.py런타임 패치를 적용합니다.GitHub에서 sitecustomize.py를 다운로드합니다.
환경 버킷의
dags/patches폴더에sitecustomize.py를 업로드합니다.PYTHONPATH환경 변수를/home/airflow/gcs/dags/patches로 설정합니다.PYTHONPATH가 이미 설정된 경우 기존 값 앞에/home/airflow/gcs/dags/patches:를 추가합니다. 예를 들면/home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE입니다.
업그레이드 후 정리: 향후 Managed Airflow 출시 버전에서는
google-api-core패키지 버전 2.43.1 이상이 사전 설치됩니다.google-api-core2.43.1 이상이 포함된 이미지로 업그레이드한 후PYTHONPATH재정의를 삭제하고dags/patches/sitecustomize.py를 삭제할 수 있습니다.
TI가 더 이상 실행 상태가 아니며 Airflow 3에서 작업이 종료되고 작업 없음 오류가 발생함
Airflow 3에는 스케줄러가 다시 시작되는 동안 스케줄러가 태스크 상태를 손실하는 것과 관련된 두 가지 문제가 있습니다.
409 충돌 상태: 스케줄러의 경합 상태로 인해 중복 태스크 인스턴스 예약이 발생합니다(#59378, #60330에서 해결됨).
이 문제는 Airflow 3.2.2에서 해결되었습니다.
404 Not Found 오류: 스케줄러가
[scheduler]num_runs에 도달한 후 발생하는 정기적인 스케줄러 루프 재시작 중에 Airflow 작업자가 태스크 인스턴스를 추적하지 못합니다. 이렇게 하면 기존 태스크 인스턴스 ID가 변경되고 변경사항을 인식하지 못하는 작업자로부터 후속 404 오류가 생성됩니다(#53140, #60330, #61631에서 해결됨).이 문제는 Airflow 3.3.1에서 해결되었습니다.
증상
409 충돌: 다시 시작된 스케줄러의 분리된 정리 상태가 활성 태스크를
FAILED로 표시하여 작업자가 비정상적으로 종료됩니다.Server indicated the task shouldn't be running anymore [supervisor] detail={'detail': {'reason': 'not_running', 'message': 'TI is no longer in the running state and task should terminate', 'current_state': 'scheduled'}} status_code=409 ti_id=UUID('...')404 Not Found: 다시 시작된 스케줄러가 태스크 상태를 잃고 활성 작업자 펄스 검사에 실패합니다.
Server indicated the task shouldn't be running anymore [detail={'detail': {'reason': 'not_found', 'message': 'Task Instance not found'}}] [status_code=404] [ti_id=...]
해결책:
- 두 문제 모두 Airflow 버전 3.3.1 이상에서 해결되었습니다. Airflow 3.3.1을 사용하는 버전으로 환경을 업그레이드합니다.
가능한 해결 방법:
3.3.1 이전 버전의 Airflow에서는 문제를 완전히 완화할 수 없습니다. 단일 스케줄러가 예기치 않게 다시 시작되는 외부 이벤트는 404 및 409를 트리거합니다 (Airflow 버전 3.2.2 이전). 이러한 이벤트의 예시로는 환경 클러스터의 노드 자동 업그레이드, 포드의 OOM 조건, 스케줄러의 높은 메모리 및 CPU 소비가 있습니다.
환경을 스케줄러 하나로 축소하고
[scheduler]num_runs구성 옵션을-1로 설정하면 스케줄러의 경합 상태 원인이 완화됩니다.복원력이 우수한 (고가용성) 환경의 경우 스케줄러 수를 1개로 줄일 수 없습니다.
[scheduler]num_runs를-1로 설정할 수 있습니다.스케줄러의 메모리 및 CPU 소비가 사용 가능한 리소스 한도 내에 있는지 확인합니다.