Apache Airflow에 대한 6가지 불편한 진실(그리고 이에 대한 대처 방법)

복잡한 통합 프로세스를 처리하는 데이터 팀은 Apache Airflow를 선호합니다.

Python으로 워크플로를 정의할 수 있고, 시스템은 광범위한 확장성을 갖추고 있으며, 다양한 플러그인을 제공합니다. 사용자의 86%가 Apache Airflow에 만족하며, 다른 워크플로 엔진이 아닌 이 엔진을 계속 사용할 계획이라고 응답했습니다. 또한 사용자의 86%는 해당 제품을 추천한다고 응답했습니다.

그러나 모든 소프트웨어, 특히 오픈 소스 소프트웨어와 마찬가지로 Airflow는 보완해야 할 격차와 단점이 많습니다. 이제 막 입문한 개발자에게 시작은 느리고 진행 과정은 험난합니다. 이 글에서는 이러한 문제와 몇 가지 가능한 해결 방법에 대해 설명합니다.

Airflow는 눈먼 도구입니다. 즉, 데이터에 문제가 생기면 이를 바로잡는 데에는 아무런 도움이 되지 않으며, 파이프라인에 관한 문제를 수정할 때만 유용합니다. 거의 모든 사용자는 Airflow에서 작업이 완료되었다는 메시지를 받고 데이터를 확인한 결과, 열이 누락되어 모든 것이 잘못되었거나 실제로 시스템을 통과한 데이터가 전혀 없다는 사실을 발견한 경험이 있습니다.

이는 데이터 구성이 성숙해지고 데이터 비순환 그래픽(DAG)이 10개에서 수천 개로 늘어나면 특히 더 그러합니다. 이러한 상황에서는 DAG를 사용하여 외부 데이터 소스 및 API에서 데이터를 수집할 가능성이 높습니다. 이로 인해 Airflow에서 데이터 품질을 제어하기가 훨씬 더 어려워집니다. 소스 데이터 세트를 '정리'하거나 거버넌스 정책을 데이터 세트에 구현할 수 없습니다.

각 실행을 수동으로 확인하기 위해 Slack 알림을 생성할 수 있지만, Airflow를 데이터 엔지니어링 조직의 유용한 부분으로 통합하고 SLA를 충족하려면 품질 검사를 자동화해야 합니다. 그러기 위해서는 작업이 실행되었는지 여부뿐만 아니라 올바르게 실행되었는지 여부도 파악해야 합니다. 작업이 올바르게 실행되지 않았다면 그 이유와 오류가 발생한 위치도 파악해야 합니다. 그렇지 않으면 모든 문제가 반복될 것입니다.

이는 간단한 문제가 아니며, IBM® Databand가 만들어진 이유이기도 합니다. Datadog 및 New Relic 같은 대다수의 제품 관측 가능성 툴은 파이프라인을 분석하도록 설계되지 않았으므로 문제가 발생한 위치를 분리하거나, 동시에 발생하는 문제를 그룹화하여 근본 원인을 제안하거나 수정 사항을 제안할 수 없습니다.

그러나 관측 가능성의 필요성은 Airflow 커뮤니티도 아직 완전히 이해하지 못했습니다. 현재 데이터 품질 측정을 시행했다고 답한 사람은 32%에 불과하지만, 설문조사 작성자들이 이러한 질문을 한다는 사실 자체가 개선의 징후입니다. 2019년 또는 2020년 설문조사에서는 아무도 이 질문을 하지 않았습니다.

Airflow에서 데이터 품질을 모니터링하려면 어떻게 해야 하나요? 사실 Airflow는 절반의 도움을 줍니다. 유지보수 담당자가 지적하듯이, '워크플로가 코드로 정의되면 유지 관리, 버전 관리, 테스트 및 협업이 더욱 쉬워집니다.'.

Airflow는 이러한 공식적인 코드 표현을 제공합니다. 필요한 것은 데이터 파이프라인을 모니터링하기 위해 특별히 구축된 관측 가능성 도구입니다. 제품을 모니터링하도록 구축된 도구는 아직 중간 단계이지만, 이미 해당 라이선스를 보유하고 있기 때문에 보통 여정의 일부로 기능합니다.

엔지니어링 조직이 완전한 관측 가능성 성숙도를 향한 여정에서 거치는 몇 가지 단계가 있습니다.

• 인식 전: 데이터 품질을 모니터링하지 않음(Airflow 커뮤니티의 68%).
• 덕트 테이프와 베일 와이어: 이상적이지는 않지만, 제품 관측 가능성 도구를 빌려서 제대로 작동하도록 합니다.
• 목적에 맞게 구축된 솔루션: Databand와 같은 풀 파이프라인 관측 가능성 툴을 도입하여 알림을 자동화하고 근본 원인을 격리하며 문제를 더 빠르게 해결합니다. 예상 데이터 매개변수에 대한 머신 러닝을 설정하고, Airflow Scheduler에서 누락된 데이터 또는 스키마 변경 사항을 나타내는 Slack 알림을 받고, 문제 계보를 역추적하고 과거 데이터를 백테스트합니다.

Airflow를 학습하려면 시간을 투자해야 합니다. 수많은 문서와 Stack Overflow 스레드에는 '내가 예약한 작업이 왜 시작되지 않았을까?' 와 같은 기본적인 질문 때문에 고민하는 개발자들의 고난이 기록되어 있습니다. (일반적인 답변: Airflow Scheduler는 예정된 기간의 시작이 아닌 예약된 기간이 끝날 때 스케줄링을 시작합니다. 이 부분은 나중에 더 자세히 살펴보겠습니다.)

또한 Airflow를 능숙하게 다루려면 Celery Executor와 RabbitMQ 또는 Redis를 배워야 하며, 이 문제를 우회할 방법은 없습니다.

이러한 불편으로 인해 CMS 소프트웨어 회사인 Bluecore와 같은 일부 조직은 본질적으로 자체 Airflow 인터페이스를 코딩하는 것이 더 쉽겠다고 결정했습니다. 이렇게 하면 고용하거나 배정한 모든 신입 개발자가 새로운 연산자를 모두 배울 필요 없이 이미 익숙한 Kubernetes를 활용할 수 있습니다.

이러한 학습 장애물은 커뮤니티에서 반복적으로 발생하는 문제로, Airflow의 2021년 커뮤니티 설문조사(아래 그림)에서 '온보딩 문제'라는 질문이 나올 정도였습니다.

사용자의 가장 큰 불만 중에는 'DAG 개발 모범 사례 부족'과 '쉽게 시작할 수 있는 옵션이 없음'이 있었습니다. 후자의 문제는 설문조사 후 릴리스된 Airflow 버전 2.0에서 부분적으로 해결되었지만, 이 버전은 병렬화가 불가능하고 모든 것이 순차적으로 일어나는 SQLite 데이터베이스에서 실행됩니다.
Airflow의 빠른 시작 가이드에서는 '이는 매우 제한적'이며 '금세 사용자의 성장 속도에 따라가지 못하게 될 것'이라고 지적합니다.

Airflow의 주요 사용 사례는 잦은 실행이 아닌 정기적인 배치 예약이며, Airflow의 문서에조차 '워크플로는 대부분 정적이거나 천천히 변화할 것으로 예상된다'고 명시되어 있습니다. 즉, 임시적이고 지속적으로 데이터를 샘플링하거나 푸시해야 하는 사용자를 위한 기능이 거의 없으므로 일부 ETL 및 데이터 과학 사용 사례에는 적합하지 않습니다.

게다가, 앞서 언급한 바와 같이 Airflow Scheduler는 Airflow Scheduler 시작 간격의 시작이 아닌 시작 구간이 끝날 때 Schedule_interval 작업을 실행합니다.

또한 이러한 예약된 작업을 제대로 실행하려면 운영자와 작업 간의 Airflow 관련 뉘앙스, DAG 작동 방식, 기본 인수, Airflow 메타데이터 데이터베이스, DAG 배포를 위한 홈 디렉터 등을 배워야 합니다.

이의 해결을 위해서는 자체 그래픽 사용자 인터페이스를 개발하고 운영자의 이름을 더 이해하기 쉬운 용어로 변경하는 6%의 Airflow 사용자가 되는 방안을 고려해 볼 수 있습니다.

Airflow에는 기존의 소프트웨어 개발 및 DevOps 관행이 많이 빠져 있는데, 그중 가장 큰 것이 바로 파이프라인의 버전을 유지 관리하는 기능입니다. 구축한 모든 사항을 문서화하고 필요한 경우 이전 버전으로 되돌릴 수 있는 쉬운 방법이 없습니다. 예를 들어, DAG에서 작업을 삭제하고 재배포하면 작업 인스턴스의 관련 메타데이터가 손실됩니다.

이로 인해 Airflow가 다소 취약해지며, 이를 직접 캡처하는 스크립트를 작성하지 않으면 디버깅 문제가 훨씬 더 어려워집니다. 가능한 수정을 과거 데이터에 대해 백테스트하여 검증하는 것도 불가능합니다.

다시 말하지만, Airflow는 공식적인 코드 표현을 제공합니다. 다만 부족한 기능을 채우기 위해 다른 소프트웨어 개발 및 DevOps 도구를 적용하기가 어렵습니다.

말 그대로입니다. 기본 리포지토리에 속하지 않은 특정 Docker Compose 파일을 사용하지 않는 한 불가능합니다.

Airflow Scheduler가 작동하지 않는다면 커피를 충분히 내려 두세요. 오랜 시간이 소요되는 디버깅이 필요할 수 있습니다.

이는 저희 생각에 Airflow가 오케스트레이션하는 운영자와 실행하는 운영자를 충분히 구분하지 못하기 때문입니다. 많은 운영자가 두 작업을 모두 수행합니다. 이는 플랫폼의 초기 코딩에는 도움이 되었을 수 있으나, 디버깅을 매우 어렵게 만드는 치명적인 요소입니다. 문제가 생기면 개발자들이 매번 DataFlow 매개변수를 먼저 점검한 다음 연산자 자체를 확인해야 합니다.

이러한 이유로 Databand와 같은 도구가 큰 도움이 될 수 있습니다. Databand는 Airflow 전역, DAG, 작업 및 사용자 대상 등 모든 수준에서 인프라의 상황을 이해하는 데 매우 도움이 됩니다. Databand를 사용하면 데이터 엔지니어는 데이터 엔지니어링에 할애해야 할 시간에 매우 구체적인 기능을 학습하는 대신 비즈니스 문제 해결에 집중할 수 있습니다.

저희는 새로운 변경 사항을 제안하는 데 시간을 할애하는 모든 오픈 소스 기여자와 마찬가지로 이 글도 애정의 표현으로 해석되기를 바랍니다. Databand의 일원들은 Airflow 커뮤니티에 적극적으로 기여하고 있으며, Airflow가 기존의 한계를 뛰어넘어 성장하고 더 많은 ETL 및 데이터 과학 사용 사례에 보다 나은 서비스를 제공하기를 열망하고 있습니다.

앞서 언급했듯이 사용자의 86%는 다른 운영 엔진이 아닌 Apach Airflow를 계속 사용할 예정이며, 86%는 이 제품을 적극 추천할 의향이 있다고 응답했습니다. 저희는 이 두 그룹 모두에 속한다고 자신할 수 있으며, Apach Airflow가 훌륭한 도구라고 생각합니다. 이제 막 Airflow에 대해 알아보는 분들은 앞서 언급한 문제를 염두에 두고 작업을 진행한다면 Airflow Scheduler는 충분한 가치를 제공한다는 점을 명심하세요. Databand가 모든 Airflow 관측 가능성 활동을 통합하여 Apache Airflow 관측 가능성을 단순화하고 중앙 집중화하는 방법을 알아보세요. 더 자세히 살펴볼 준비가 되셨다면 지금 바로 데모를 예약하세요.