Airflow

메타데이터 DB 유지보수

시간이 지날수록 Dag/태스크 실행 이력과 이벤트 로그가 쌓이면서 메타데이터 데이터베이스의 저장 공간이 계속 늘어난다. Airflow CLI의 ``airflow db clean`` 명령으로 오래된 데이터를 정리할 수 있다.

업그레이드/다운그레이드 - DB 백업과 스케줄러 비활성화

데이터베이스를 수정하는 작업(업그레이드 등)을 하기 전에는 항상 메타데이터 데이터베이스를 백업하는 것이 현명하다.

이런 유지보수 동안에는 Airflow 클러스터를 비활성화하는 것을 고려할 수 있다. 한 가지 방법은 ``[scheduler] > use_job_schedule`` 파라미터를 ``False``로 설정하고 실행 중인 Dag가 끝날 때까지 기다리는 것이다 - 이후 외부에서 트리거하지 않는 한 새로운 Dag Run은 생성되지 않는다.

좀 더 나은(하지만 다소 수작업인) 방법은 ``dags pause`` 명령을 쓰는 것이다. 이 작업을 시작하기 전에 어떤 Dag가 pause되어 있었는지 기록해두어야, 유지보수 후 어떤 것을 다시 unpause해야 하는지 알 수 있다. 먼저 ``airflow dags list``를 실행해 pause되지 않은 Dag 목록을 저장한 뒤, 유지보수 전에는 이 목록의 각 Dag에 ``dags pause``를, 유지보수 후에는 ``dags unpause``를 실행한다. 이 방식의 장점은, 업그레이드 후 (가급적 전용 :ref:`테스트 Dag <integration-test-dags>` 같은) 한두 개 Dag만 먼저 unpause해 보고 정상 동작을 확인한 뒤 나머지를 전부 되돌릴 수 있다는 점이다.

통합 테스트 Dag 추가와 업그레이드 전 데이터 정리

생태계에서 쓰는 공통 서비스(S3, Snowflake, Vault 등)를 테스트 리소스나 'dev' 계정으로 사용하는 '통합 테스트' Dag 몇 개를 추가해두면 도움이 된다. 이런 테스트 Dag는 업그레이드 후 *가장 먼저* 켜볼 수 있는 대상이 되어야 한다 - 이 Dag가 실패해도 상관없고, 문제가 있으면 백업으로 되돌리면 되기 때문이다. 반대로 성공한다면, 클러스터가 필요한 라이브러리·서비스로 태스크를 실행할 수 있음을 입증하는 것이다.

예를 들어 외부 시크릿 백엔드를 쓴다면 커넥션을 조회하는 태스크가 있어야 한다. ``KubernetesPodOperator``를 쓴다면 ``sleep 30; echo "hello"``를 실행하는 태스크를 추가한다. S3에 쓰기가 필요하다면 테스트 태스크에서 실제로 써본다. 데이터베이스 접근이 필요하다면 서버에서 ``select 1``을 실행하는 태스크를 추가한다.

메타데이터 데이터베이스가 매우 크다면 일부 데이터베이스 마이그레이션은 시간이 오래 걸릴 수 있다. 업그레이드를 수행하기 전에 :ref:`db clean<cli-db-clean>` 명령으로 오래된 데이터를 미리 정리해두는 것을 고려할 수 있다. *단, 주의해서 사용해야 한다.*