NFTBank에서 Airflow 파이프라인을 안전하게 빠르게 개발과 테스트를 할 수 있는 이유

Jensen Yap
NFT뱅크
Published in
10 min readFeb 5, 2022

--

배경

안녕하세요, NFTBank에서 Data Engineer로 일하는 젠슨입니다. 현재 NFTBank에 있는 모든 Data Infrastructure를 관리하고 있고 NFTBank에 있는 모든 hourly 데이터 파이프라인을 개발, 배포, 관리를 하고 있습니다. 또한, 저희 Data Scientist들이 데이터에 더 쉽게 접근할 수 있도록 Data LakeWarehouse도 운영하고 있습니다.

NFTBank에서는 현재 Blockchain에 있는 모든 데이터들을 NFTBank Data Warehouse에 hourly로 적재하고 있습니다. Ethereum, Matic, Klaytn, Ronin, Loom network의 데이터들을 적재하고 있고 계속 더 많은 onchain 데이터를 적재할 예정입니다. Onchain 데이터 뿐만 아니라 다양한 offchain 데이터도 hourly로 적재하고 있습니다.

이렇게 많은 데이터를 적재하고 있기 때문에 각각의 데이터 파이프라인을 빠른 속도로 개발하고, 테스트한 다음, Production에 배포해야 합니다. Airflow를 많이 써본 Data Engineer라면 Airflow DAG를 배포하기 위해 보통 Git Sync를 많이 쓰지만 git sync 방식을 쓰신다면 테스트 branch에서 작업할 때, 여러 명이 동시에 commit할 수가 없는 상태입니다. 서로가 개발, 테스트 배포하는 작업을 같은 branch에 하고 있어서 빠른 개발, 테스트와 배포가 어렵기 때문에 어떻게 하면 파이프라인을 작업하는 Data Engineer와 Data Scientist들이 제일 안전하고 빠른 방법으로 개발할 수 있을 지 고민하기 시작했습니다.

긴 고민과 논의한 후에 저희 팀은 아래와 같은 목표를 만들었습니다.

내가 DE팀이 아니더라도 데이터 파이프라인을 개발할 수 있다!

Warehouse에 있는 각 Stage를 Airflow에 모듈화 하자!
datasource부터 lake, ods, mart까지 각각의 stage에서 etl파이프라인을 다루기 때문에 모듈화를 통해 다른 팀도 쉽게 모듈을 활용하여 원하는 데이터를 수집하고 적재, 가공을 할 수 있게 하는 것입니다.

데이터 파이프라인을 쉽고 안전하게 테스트할 수 있는 환경을 만들자!

파이프라인을 개발하려면 Airflow 지식이 어느정도 필요하다고 생각합니다. 그리고 Warehouse에 대해서도 파악해야 돼서 보통 DE팀이 아닌 Engineer/Scientist들이 데이터 파이프라인을 직접 개발하지 않고 있습니다. 그렇지만 이 큰 장벽을 없애기 위해서 저희 DE팀이 안전하게 파이프라인을 개발할 수 있는 환경을 제공해야 한다고 생각했습니다. 그래야 software engineer와 data scientist들이 처음부터 쉽게 onboarding될 수 있고, 모듈화 되어 있는 예시를 따라하거나 코드를 추가해도 쉽게 검증할 수 있는 테스트 진행함으로써 테스트 결과와 코드를 리뷰 받고 안전하게 새로운 pipeline을 Production에 rollout할 수 있다고 생각합니다.

그러므로 이번 글을 통해 저희 NFTBank DE팀이 어떻게 누구나 데이터 파이프라인을 안전하게 개발할 수 있게 Airflow 테스트 환경을 준비하고 제공하고 있는지 보여 드리도록 하겠습니다.

계획

Airflow DAG를 테스트할 수 있는 방법들은 여러 가지가 존재합니다. 간혹 테스트를 안하고 바로 배포하는 경우도 있습니다. 그렇지만 파이프라인을 개발할 때 제일 좋은 개발 환경은 사실 각자의 고유한 테스트 환경이 있는 것입니다. 공용 테스트 환경을 쓰게 되면 항상 배포하기 전에 공유해야 되기 때문에 자유롭게 commit push을 못 했게 되어서 개발이 어려워지게 됩니다.

테스트 환경의 목표 셋업

  1. branch를 만들 때마다 테스트Airflow가 setup되어야 한다
  2. PR단계에서 테스트Airflow를 setup와 tear down 가능해야 된다
  3. 테스트 Airflow에서 만든 데이터셋과 파일들이 따로 테스트 버켓이나 database에 저장되어야 한다
  4. 테스트하는 쿼리들의 비용이 얼마인지 자동으로 Pull Request에서 보여 준다

PoC 전에 혼자서 brainstorming

제가 데이터 파이프라인을 개발한다면 어떤 어려움이 있는지, 또한 어떤 환경이 제공되어야 사람들이 안전하게 쉽게 개발하고 배포할 수 있는지에 대해서 계속 고민했습니다.

데이터 파이프라인을 개발하면 제일 무서운 것은 제가 개발하는 코드가 저도 모르게 Production 파이프라인에 영향을 미치는 것입니다. 그러므로 일단 Production 테스트 환경을 분리 시켜야 됩니다. 그리고 테스트에서 아무리 코드를 코밋하고 테스트 파이프라인을 돌려도 Production 파이프라인을 영향 주지 않고 Production BigQuery 테이블을 쓰지 않아야 됩니다.

Okay, 그러면 개발하려면 git branch 만들어서 제 git branch에 있는 코드를 테스트 Airflow 서버에 반영해야 되지만, 어떻게 해야 테스트 Airflow 서버를 빠르게 deploy와 tear down할 수 있는지 고민해 봤습니다. 로컬에서 Airflow을 각자 배포하는 게 좋을까요? 아니면 공용 테스트 서버가 더 좋을까요? 라고 고민하면서 마침 저희가Kubernetes Cluster를 쓰고 있어서 ArgoCD, Airflow Helm ChartGithub Action을 활용할 수 있을 것 같아서 빠르게 PoC(Proof of Concept)해 봤습니다.

Airflow 테스트 Process

테스트 Process를 그려보고 나서 PoC를 바로 진행했습니다.

Test Process

위와 같은 Process가 있다면 데이터 파이프라인을 개발할 때,

  1. Data Pipeline Repository에서 개발 git branch 생성하고
  2. Github에서 Pull Request를 만들고
  3. Github Pull Request의 Comment에서 /test 치면

혼자 쓸 수 있는 테스트 Airflow 서버가 제공될 겁니다. 쉽죠?

그러면 테스트 환경 만들자!

필요한 테스트 Airflow 서버를 helm chart로 작성하고 나서 Github Action으로 Triggering하고 ArgoCD로 Airflow Scheduler, Webserver를 배포할 수 있게 만들었습니다.

코드를 보여 줄 수 없지만 Github에서 issue comment할 때, 아래와 같이 kubernetes에서 테스트 Airflow를 배포할 겁니다.

name: deploy-test-serveron:
issue_comment:
types:
- created

그리고 Pull Request를 머지 하게 되면 Tear Down하는 Github Action도 필요합니다.

name: tear-down-test-serveron:
pull_request:
types:
- closed

저희팀은 1주일 안에 Airflow 테스트 서버를 개발 성공했고 다행히 지금까지 모든 팀들이 잘 활용하고 있습니다.

데모

a. Airflow DAG Pipeline Github Repo에서 테스트 DAG을 추가

b. Airflow에 있는 example dag을 추가했습니다.

c. 테스트 branch 만들고 Pull Request 만들어 보겠습니다.

create development branch
create pull request

d. Pull Request에서 /test 를 comment하면 kubernetes에서 테스트 Airflow가 배포되고 테스트 Airflow 링크와 권한을 Comment으로 보입니다.

github action trigger with /test
deployed airflow testing server

e. 테스트 Airflow 접속하면 제가 테스트로 example dag을 올린 DAG이 보일 겁니다.

Airflow Testing Webserver UI

f. 그리고 자유롭게 테스트 DAG를 돌려볼 수 있습니다.

Run Testing DAG

g. 그리고 Pull Request를 머지되거나 close하면 테스트 Airflow를 teardown될 겁니다.

뽀너쓰

저희가 BigQueryExecuteOperator를 customize하고 테스트에서 돌린 SQL의 scanned bytes와 billing도 같이 Pull Request에서 출력했습니다. 아래와 같은 Job Cost Statistics도 출력하여 개발하는 분과 리뷰하는 분들에게 많이 도움이 되고 있습니다.

SQL Job Statistics in Airflow Testing Server

마무리

테스트 Airflow을 배포하고 나서 저희가 parallel하게 기존에 있는 Daily 파이프라인을 Hourly로 개발할 수도 있고 다양한 모듈도 계속 개발하고 테스트할 수 있었습니다. 그리고 현재도 Data ScientistMLOps 엔지니어들이 MLOps 파이프라인을 Airflow에서 개발하고 모델과 데이터 모니터링 파이프라인도 자유롭게 개발할 수 있게 되었습니다. 과정이 쉽지 않았지만 저희 팀뿐만 아니라 다른 팀들도 데이터 파이프라인을 개발하게 되어서 데이터에 대한 Ownership 스스로 생긴 것 같다고 생각합니다.

긴 글을 읽어주셔서 감사합니다. 저희 Airflow 테스트 하고 있는 방법이 도움될 수 있기를 바랍니다.

NFTBank는 오늘도 좋은 제품을 개발하기 위해 열심히 일에 몰두하고 있지만, 
저희가 가야 할 길은 아직 멀고 험난합니다.
그래서 이 글을 읽고 계신 당신 같은 유능한 분들이 필요해요https://nftbank.breezy.hr/

--

--

A data enthusiast that is eager to see data being utilized to it’s full potential. Working as a Data Engineer in the blockchain industry currently.