Python 사용기 - Airflow

Posted by 엘키의 주절 주절 on December 16, 2017

파이썬을 업무적으로 다시 사용하게 될 계기가 생겼다.

Airflow를 사용하게 되면서, Airflow 스크립트 작성에 Python을 사용하게 됐는데, 그 과정에서 느낀 점을 말해보고자 한다.

Airflow에서 파이썬 스크립트를 사용한다기에, 매뉴얼을 보며, 샘플을 보며, 동료가 작성한 스크립트를 보며 적용하려 했다.

헌데 숨겨진 제약이 아주 많았는데, 그 제약 중에서는 참조 할 수 있는 인스턴스 변수가 달라지는 상황이 아주 많았다.

1
어라? 이런 상황은 C++이나 자바같은 복잡한 언어에서 있는 일 아닌가?

나 역시 이와 같은 편견을 가지고 있었는데, 그것이 정말 편견이었다.

라이브러리 가져다 쓰는 상황에서도 매뉴얼에 설명 되어 있지 않은 가정이 자주 존재하는데, 이는 동적 언어에서 발생했을 때 조금 더 크리티컬하다.

헌데 airflow는 한 술 더 떠서 등록해놓은 task (operator)를 불러주는 시점에 대한 런타임 디버깅을 모듈차원에서 지원하지 않는다.

Operator를 등록하는 과정까지만 디버깅을 지원하고, 이후의 과정은 개입할 수 없었다.

이 과정에서 두가지 모호한 포인트가 있었는데, 바로 어떤 코드가 operator 등록 시점의 코드이고, 어떤 코드가 operator가 동작하는 시점에서의 코드인지를 사용하면서 이해해야 했다.

단순히 디버깅이 지원 안되는 것도 크리티컬 하지만, 그럴 수 있다고 본다. 하지만 중요 로직을 작성해야 되는 지점이 callback이 불려 질 타이밍이라는 점, 해당 시점에서만 airflow가 제공해주는 환경 변수의 핵심인 task_instance 변수가 제공된다는 점이 크리티컬 했다.

아주 중요한 전제임에도 불구하고, 튜토리얼에서 중요하게 다뤄지지 못했다.

좋은 프레임워크는 큰 가정과 제약에 대해 잘 설명하는게 당연함에도, 오픈소스는 이게 부족한 경우가 많다.

정적 언어에 비해 이런 상황의 오류 발생률과 리스크는 훨씬 큰 편임에도 말이다.

흔히들 스크립트 언어를 흔히 쉽게 접하고, 쉽게 익숙해 질 것처럼 치부하지만 절대 그렇지 않다.

오히려 프로덕션 레벨에서 사용하기엔 훨씬 어려운 언어다.

정적 타입 언어가 수많은 예외 케이스나, 실수를 빌드 타임에 잡아준다는 것, 또한 성능상의 제약을 우회하기 쉽다는 것, 정적인 타입 제약 등으로 암묵적인 제약을 표현할 수 있고, 이에 대해서는 자연스레 매뉴얼에 반영되곤 한다는 점 등이 이를 반증한다.

동적 타입 언어가 가장 큰 리스크는, 데이터에 의해 동작이 달라질 때다. 가장 자주 겪는 문제가 인코딩 계열인데, 이런 문제가 항상 생기는게 아니라 특정 데이터 조건에 한해서만 생긴다는 것이 큰 리스크다.

내 경험상 안정적인 스크립트 셋을 만드는 건 꼼꼼하고 계획적인 사람들만 그렇게 했다. 추가로 내 경험상 그런 사람들의 비율은 한 팀에 10~30% 내외의 사람들이었다. 나머지 사람들은 스크립트 언어를 프로덕션에서 사용하기에 부적절하다는 의미다.

이를 위해선 배보다 배꼽이 더 클 수 있는 커버리지 확보를 정적언어보다 훨씬 더 많이 해야만 한다. 그래야 안정적인 스크립트 셋을 구축할 수 있다.

이 이야기를 왜 굳이했냐하면, 내가 여타 언어를 적응하면서 겪었던 고난보다 airflow가 가장 큰 고생을 시켰기 때문이다.

rails, django, flask, .net core, java spring boot, netty, akka 등…그 어떤 오픈소스도 이런 중요한 기본적(=핵심적)인 제약을 문서나, 튜토리얼, 예제등에서 가르쳐주지 않은 적이 없었다.

내가 놓쳤을 지언정 note나 warning 문구에서 충분히 설명하고 넘어갔다.

그래서 아직 incubating apache project겠지만 나도 오픈소스 작업을 하게되면서 이런 부분을 많이 신경써야겠다라는 생각도 같이 갖게 됐다.

결국 디버깅을 할 수 있도록 지원하는 mocking을 전방위적으로 구성하고, 커버리지를 위해 파이썬 코드를 전반적으로 스크립트셋을 구축하는 방법으로 마무리했다.

내가 작성한 파이썬 코드가 airflow 상에서만 테스트가 가능한 상태에서, 로컬에서의 독립적인 디버깅이 가능하도록 확장 작업을 했다.

결국 얘기가 돌았지만 하고자 하는 이야기의 핵심은 오픈소스에서는 airflow 만치 암묵적인 축약이 있는 경우가 많다. 하지만 콜백 호출시의 디버깅이 안되는 점과 파이썬이라는 동적언어를 사용한 점까지 물려서 복잡한 로직을 작성해야 하는 경우의 개발과 관리 코스트를 높여버렸다는 점이다.

다수의 다른팀의 사례는 Data Workflow로써 사용하던데, 다수의 팀은 디버깅이 필요할만큼의 복잡한 작업을 진행하지 않았고, 로직 코딩보다는 Bash Script를 대행하는 역할에 근접하게 사용했다고 한다. 그래서 Bash 파일을 독립적으로 잘 구성하고 순차적 Bash 파일을 호출함으로써 사용했다면 큰 문제는 없었을 것이다.

그럼에도 나는 airflow가 숨겨놓은 핵심 제약은 반드시 설명해야 하는 핵심 포인트이며, 이 제약이 어떤 의미를 가지고 어떠한 사용법으로써 사용하길 권고하는지 알려줘야 한다고 본다. 아니면 실행인자나 설정 파일을 통한 디버깅 환경을 위한 mocking을 제공하던지 말이다.