Airflow

복잡도에 대한 공식 지표는 없다 - Dag 작성자가 통제한다

Airflow는 많은 태스크와 의존성을 가진 여러 Dag를 잘 처리하지만, 복잡한 Dag가 많아지면 그 복잡도가 스케줄링 성능에 영향을 줄 수 있다. Airflow 인스턴스를 성능 좋고 잘 활용되도록 유지하는 방법 중 하나는 가능한 한 Dag를 단순화하고 최적화하는 것이다 - Dag 파싱·생성 과정은 결국 Python 코드를 실행하는 것일 뿐이며, 그것을 최대한 성능 좋게 만드는 것은 전적으로 Dag 작성자의 몫이다. Dag를 '덜 복잡하게' 만드는 마법 같은 공식은 없다 - 이것이 Python 코드인 이상, 코드의 복잡도를 통제하는 것은 Dag 작성자다.

Dag 복잡도를 재는 '지표'는 없으며, 특히 어떤 Dag가 '충분히 단순한지' 알려주는 지표도 없다. 하지만 다른 Python 코드와 마찬가지로, 최적화된 Dag 코드가 더 '단순'하거나 '빠른'지는 분명히 판단할 수 있다.

네 가지 최적화 방향

Dag를 최적화하고 싶다면 다음 네 가지 조치를 취할 수 있다.

첫째, Dag가 더 빠르게 로드되도록 만든다. 이는 스케줄러 성능에 가장 큰 영향을 미치는 단일 개선책이다. 성능 개선이 목표라면 Dag를 빠르게 로드시킬 기회가 있을 때마다 그렇게 해야 한다. top-level 코드 최적화 지침과, Dag 로딩 시간을 측정하는 Dag Loader Test를 참고하라.

둘째, Dag가 더 단순한 구조를 생성하도록 만든다. 태스크 간 의존성 하나하나가 스케줄링과 실행에 추가적인 처리 오버헤드를 더한다. ``A -> B -> C``처럼 단순한 선형 구조를 가진 Dag는, 예를 들어 지수적으로 늘어나는 의존 태스크를 가진 깊게 중첩된 트리 구조의 Dag보다 태스크 스케줄링 지연을 덜 겪는다. Dag를 더 선형적으로 만들어서 - 실행의 어느 한 시점에 실행 후보가 될 수 있는 태스크가 적을수록 - 전반적인 스케줄링 성능이 개선될 가능성이 높다.

셋째, 파일당 Dag 개수를 줄인다. Airflow 2는 한 파일에 여러 Dag를 두는 경우에 맞춰 최적화되어 있지만, 시스템의 일부 부분은 이 경우 오히려 덜 성능이 좋거나, 여러 파일에 나눠 둔 경우보다 더 큰 지연을 유발할 수 있다. 단적으로 한 파일은 하나의 FileProcessor만 처리할 수 있어 확장성이 떨어진다. 한 파일에서 생성되는 Dag가 많다면, Dag 파일 변경이 Airflow UI에 반영되는 데 오래 걸린다고 느껴질 경우 이를 분할하는 것을 고려해야 한다.

넷째, 효율적인 Python 코드를 작성한다. 파일당 적은 Dag 수를 유지하는 것과, 전체적으로 코드량을 줄이는 것 사이에서 균형을 맞춰야 한다. Dag를 기술하는 Python 파일 작성은 설정 파일 취급이 아니라 좋은 프로그래밍 관행을 따라야 한다. 비슷한 코드를 공유하는 Dag가 많다면 이를 대량의 거의 동일한 소스 파일에 반복해서 복사하면 안 된다 - 동일 리소스에 대한 불필요한 반복 import를 유발하기 때문이다. 대신 모든 Dag에 걸쳐 반복되는 코드를 최소화해 애플리케이션이 효율적으로 실행되고 쉽게 디버깅되도록 해야 한다. 비슷한 코드로 여러 Dag를 만드는 방법은 동적 Dag 생성 섹션을 참고한다.