Airflow Design Patterns
댁을 작성하면서 반성하면서 생각한 주제
에어플로 센서와 DAG 작성에 관한 이야기
이하 DAG는 에어플로 DAG를 칭함
Deferrable Operator
기존의 오퍼레이터는, 실행되면 CPU와 리소스를 끝날 때까지 점유.
👉🏿 Polling을 하는 등 대기하는 작업에는 쥐약...
👉🏿 Deferrable Operator는 작업이 바로 끝나지 않더라도, Triggerer 프로세스로 제어권 넘기고, 리소스 반환.
👉🏿 특정 이벤트가 발생하거나 polling 결과가 변화했을 때 컨티뉴.
👉🏿 HttpSensor, S3KeySensor, SQLSensor 요런거.
👉🏿 비동기 방식으로 리소스 사용을 최적화.
👉🏿 커스텀 트리거를 만들어서, 커스텀 오퍼레이터에서 사용하면 커스텀 센서를 만들 수 잇다. execute 메소드를 활용하는/안하는 방법이 있는데, 그건 에어플로 똑큐먼트를 찾아보자...
Operator Pattern과 Event-driven 패턴
🍕 Operator Pattern
👉🏿 모든 작업은 Operator의 인스턴스가 정의하고, 각각의 Operator는 하나의 작업만을 수행해야 함.
👉🏿 즉, DAG 안에서 복잡한 비즈니스 로직을 작성하거나, if-else 문으로 흐름을 분기하면 ❌.
👉🏿 그런 건 따로 분리하고, 인자값과 함께 Operator를 호출만 하는 식으로 설계해야 함.
🍔 Event-driven Pattern
👉🏿 S3에 파일이 생기면 시작하는, Kafka 토픽에 메시지가 들어오면 트리거 되는 파이프라인 등.
👉🏿 에어플로 시점에서 볼 떄, Deferrable Operator나 External Trigger등은 이걸 따라가려고 도입함.
👉🏿 그래도 에어플로는 Schedule 기반! 완전한 이벤트 드리븐 패러다임으로 구현하기엔 무리.
👉🏿 에어플로는 polling 등으로 체크하는 pull-base 라는 점과 카프카, 람다 등은 이벤트에 반응하는 push-base라는 점.
그래도 로직이 넣구싶어요
DAG는 워크플로우를 정의하는 블루프린트임.
여기에 빋닏 로직을 직접 넣기 시작하면...🤪
☝🏿 테스트: 로직에 대해서 유닛 테스트 어터게 할거임?
🤞🏿 재사용성: 로직이랑 댁이 결합도가 높은식으로 만들면, 오퍼레이터 날마다 맹글어야겟네?
🤟🏿 가독성: 스압... ctrl + f 로 찾는것도 한계가 잇찌 🤮
로직은 별도의 Python 모듈로 작성하고 DAG에서 모듈 import하고... 그렇게는 하지 맙시다 😇
하지마 제발 (나한테)
구럼 쏀써 사용은 에어플로 철학에 어긋나니 쓰면 안되나
센서 사용 자체가 잘못된 것은 아니지만,
✔ 가능하면 Deferrable Sensor를 써서 리소스 아끼기
✔ 한 DAG가 다른 DAG 실행 여부를 감시/기다리는 구조 피하기
에어플로 디자인 철학 중 하나인 DAG 간의 독립성을 고려했을 때,
DAG가 다른 DAG의 상태나 결과를 알아야 한다면,
DAG간 결합도가 높음을 의미,
전체 시스템 복잡도가 높아짐.
API 호출로 다른 DAG를 트리거하거나, 메시지 브로커를 사용해서 트리거할 수 있다면 (일적으로 오버헤드가 증가하긴 하지만...) 더 자연스러워지지 않을까유💤
TL;DR
에어플로 설계와 운영 원칙
- 워크플로우와 비즈니스 로직의 분리.
- Deferrable Operator로 리소스 최적화. reschedule!!
- 센서 사용은 필요할 때만, 가능하면 이벤트 기반으로.
- DAG간의 의존(결합)을 최소화, 시스템 확장성과 유지보수 고려.
👿 안 그러면 복잡해진 DAG를 보면서 울고 리뷰어의 철퇴를 맞을것임. 🔨