Passwd

[Airflow] Connection 테스트 활성화

개요보통 소프트웨어에서 다른 소프트웨어와 연동할 때, 대표적으로 데이터베이스와 연동하는 경우 접속 테스트 기능을 통해 테스트를 하곤 한다. 그런데 Airflow는 연결 테스트 기능은 제공하지만 기본적으로 비활성화 상태로 제공하는 것 같다.연결 테스트 기능을 활성화하는 방법을 적어둔다. TEST_CONNECTION공식 문서를 찾아보니 보안 상의 이유로 테스트 연결 기능은 비활성화한 상태로 제공된다고 한다. 연결 테스트 기능을 활성화하고 싶다면 airflow.cfg 파일을 수정하거나 환경 변수를 수정하는 방법이 있다. 제어하는 변수의 이름은 test_connection이며 아래의 값을 허용한다.- Disable : (기본값) 연결 테스트 기능을 비활성화하고 UI에서 연결 테스트 버튼을 비활성화한다. - E..

개요새로운 Airflow 환경을 사용하게 되었는데, 이번 환경에서는 Connections라는 기능을 사용하고 있어 어떤 기능인지 정리해보려고 한다. ConnectionsAirflow는 다른 시스템과 통신하기 위한 자격 증명 등을 저장하는 Connections라는 개념을 사용한다. 다른 시스템에서 데이터를 가져오거나 내보내기 위해 사용하며, 기본적으로 사용자 이름, 비밀번호, 호스트, 연결 시스템 유형, conn_id 등의 속성으로 구성되어 있다.Connection은 Web UI 또는 CLI를 통해 관리할 수 있고, Hooks나 jinja templetes을 통해 사용할 수 있다. Connections 생성이번 글에서는 Web UI를 통해 신규 Connection을 생성해본다. 연결할 시스템은 Post..

개요Airflow에서 dag_id는 유일해야 하기 때문에 dag_id에 중복이 발생하면 의도하지 않게 동작할 수 있다. 하지만 Dag의 오류 사항을 확인할 수 있는 Web UI에서는 dag_id에 중복 발생 여부를 확인할 수 없어 디버깅하기 조금 힘든데, cli를 활용하면 바로 확인할 수 있는 것을 알게 되어 적어둔다. 확인 방법dag_id 중복 시 발생하는 예외는 AirflowDagDuplicatedIdException이다. 즉, 2024.11.30-[Airflow] Dag Import Error 확인하기에서 확인한 airflow cli의 list-import-errors 명령어를 사용하면 dag_id의 중복 발생 여부를 확인할 수 있다. 참고로 Github에서 명령어의 동작 방식을 확인해 보니 DA..

현상업무를 하던 중, Dag 파싱이 정상적으로 이루어지지 않는 현상을 확인했다. Airflow Web UI에서 Dag의 코드를 확인하면 언제 파싱이 이루어졌는지 확인할 수 있는데, 확인 당시 기준 2일 전에 마지막으로 Dag 파싱이 이뤄지고 더 이상 파싱이 이뤄지지 않는 상태였다.원인을 파악하고 문제를 해결한 이력을 적어둔다. 원인먼저 Dag 파싱을 담당하는 DagFileProcessor의 로그가 존재하는지 확인했는데, 각 Dag 정의 파일의 파싱 이력 정도만 찾고 별도의 로그 파일은 확인하지 못했다.하지만 스케쥴러 로그 파일에서 아래와 같은 로그가 반복적으로 발생하고 있는 것을 확인했다.DagFileProcessorManager (PID=) last sent a heartbeat 51.22 seco..

현상Airflow에서 Dag를 개발하다 보면 어떠한 이유로 오류가 나서 Dag가 생성되지 않는 경우가 발생할 수 있다. 이번 글에서는 import error에 대한 정보를 CLI로 확인하는 방법을 적어둔다.  CLI 외 다른 방법이전에 작성했던 글이 있어 CLI를 활용하지 않고 확인하는 방법을 먼저 작성한다.참고 : 2024.11.30-[Airflow] Dag Import Error 확인하기간단하게 Airflow Web UI를 통해 확인하거나, Airflow Meta DB의 import_error 테이블을 조회하는 방식으로 확인할 수 있다.   CLI 사용CLI를 통해 사용할 때는 dags list-import-errors를 통해 확인할 수 있다.airflow dags list-import-errors참..

개요2025.01.23-[Airflow] 2.5.1 -> 2.8.2 업그레이드 후 Trigger DAG w/ config 미노출 현상에서 Dag의 매개변수를 전달하는 새로운 방법이 있다는 것을 알게 되었다. 해당 글에서는 기존 매개변수 전달 방식을 유지하기 위한 방법에 초점을 맞춘 글을 작성했는데, 이번에는 새로운 매개변수 전달 및 사용 방법에 대해서 알아보려고 한다.  ParamsAirflow Params는 Dag에 런타임 구성을 제공하여, Dag와 Task에 값을 전달하는 방법이다. Dag 정의 코드에서 구성하면 Dag를 트리거할 때 추가로 매개변수를 전달하거나 기존에 설정되어 있던 값을 덮어쓴다. 또한 Trigger UI Form을 렌더링 하는 데 사용한다. Dag 수준 매개변수Task에 전달되는 ..

개요Airflow 버전 2.5.1에서 취약점이 발견되어 2.8.2 버전으로 업그레이드를 진행했다. 진행 후에 Airflow WebServer에서 Dag Trigger 시 Trigger DAG w/ config 버튼이 노출되지 않는 것을 확인했다. 기존 (2.5.1) 현재 (2.8.2) 원인을 파악하고 수정해 보자.  원인 - Trigger UI Form이 현상의 원인은 Airflow 2.6.0에서 도입된 Trigger UI Form 기능과 관련이 있다.Airflow 2.6.0에서는 Dag 수준에서 params 매개변수가 정의되어 있으면 사용자 친화적인 트리거 양식을 렌더링 해준다. 트리거 양식은 Trigger DAG 버튼을 누르면 제공된다.렌더링 되는 트리거 양식은 DAG 객체의 params로 전달된 값..

개요Airflow를 사용하다 보면 Web UI에서 다음과 같은 Import 에러가 발생하는 모습을 확인할 수 있다.Import Errors가 발생하면 Dag 활성화 자체가 되지 않기 때문에 주기적으로 동작 확인이 필요한 경우에는 별도로 모니터링이 필요해 보였다. 관련하여 알람 등을 구성하기 위해 프로그래밍적인 방법으로 확인할 수 있는 방법이 있는지 확인해본다.   import_error 테이블잠깐 Airflow Meta DB 스키마를 확인해 봤더니 바로 import_error 테이블이 존재하는 모습을 확인할 수 있다.-- airflow.import_error definitionCREATE TABLE `import_error` ( `id` int NOT NULL AUTO_INCREMENT, `times..

개요Airflow WebServer는 Dag의 상태를 일정 주기마다 새로 고침하는 auto-refesh 기능을 제공한다.다만 이 기능은 Dag가 너무 많거나, Dag의 Task가 많으면 너무 많은 데이터를 너무 잦게 데이터베이스에서 조회하게 되어 시스템 부하를 줄 수도 있는 것 같다. 때문에 기본적으로 비활성화 상태를 기본으로 둘 수 있는 방법을 찾았는데, 그런 기능은 지원하지 않는 것으로 보인다.이번 글에서는 Auto-refesh 관련 설정에 대해서만 간단히 짚고 넘어가려고 한다.  관련 설정auto_refresh_intervalAuto-refesh 기능이 켜져있을 때 Dag 데이터가 자동으로 새로고침되는 빈도에 해당된다.airflow.cfg나 환경변수로 설정할 수 있는데 Webserver 관련 설정값..

개요Airflow에서 많은 Dag, 많은 Task를 실행할 때 서로 다른 Dag 간의 Task 간의 실행 순서를 결정하기 위해 우선순위를 가질 수 있다. 이번 글에서는 Airflow가 Task의 실행 순서를 결정하는 규칙에 대해서 먼저 알아본다.  priority_weightAirflow는 Executor에서의 task 실행 순서를 결정하기 위해 priority_weight과 weight_rule이라는 두 가지 개념을 사용한다.그중 priority_weight은 Executor의 큐에서의 우선순위를 정의한다. 기본값은 1이며, 각 task는 weight_rule에 의해 계산된 유효한 priority_weight에 따라 실행 순서, 우선순위가 결정된다.Task의 priority_weight 값이 높을 수록..