데이터 엔지니어를 힘들게 하는 데이터 파이프라인 실패 복구

데이터 조직이 생기고 데이터 웨어하우스를 만들고 운영을 하다보면 다수의 데이터 파이프라인이 생긴다. 근데 대부분이 외부에 있는 데이터를 읽어오는 것이다 보니 외부 데이터 소스에 문제가 생기면 방법이 없다. 99.5%의 uptime을 자랑하는 API라 하더라도 사실 일년으로 치면 1.825일(0.005*365) 동안은 동작하지 않음을 의미한다. 만일 이런 데이터 파이프라인이 100개 정도 돌아간다고 치면 평균적으로 매일 1-2개의 데이터 파이프라인은 외부 데이터 소스 이슈로 실패한다. 실패한 것들은 찾아서 나중에 다시 실행해주어야 것이 필요한데 이는 증분 업데이트를 하는 경우 더 중요해진다.

데이터 파이프라인의 업데이트 방식: 전체 업데이트 vs. 증분 업데이트

데이터 파이프라인이 데이터를 읽어오는 방법에는 크게 두 가지가 있다. 하나는 매번 소스에서 전체 데이터를 다 읽어오는 것인데 이를 보통 전체 업데이트(Full Refresh)라고 부른다. 다른 하나는 매일 혹은 매시간 그 전날 혹은 전시간에 바뀐 내용(새 레코드와 변경된 레코드)만 읽어오는 것인데 이를 증분 업데이트(Incremental Update)라고 부른다. 전체 업데이트가 여러모로 편리한데 데이터의 크기가 커지면 이 방식은 사용할 수가 없다. 읽어다가 업데이트하는데 하루 이상이 걸리기 시작하기 때문이다. 어느 시점부터는 증분 업데이트로 넘어가야 하는데 이 때부터는 운영상의 난이도가 올라가기 시작한다.

증분 업데이트의 문제

증분 업데이트가 가능하려면 먼제 데이터 소스가 스마트해서 어느 시간 범위 내에서 변경되거나 새로 생긴 레코드들만 리턴할 수 있어야 한다. 다음으로 여러 이유로 어느 특정 시간 대의 증분 업데이트가 실패하면 데이터에 구멍이 생기기 때문에 운영에 있어서 실패한 데이터 파이프라인들을 찾아내서 재실행해주는 것이 필요하다. 이를 Backfill이라고 부르며 Backfill의 용이성이 데이터 엔지니어의 삶에 큰 영향을 끼친다. 이게 쉽지 않으며 매번 Backfill하느라 다른 일을 못 한다. 잘 만들어진 데이터 파이프라인은 과거 문제를 해결하기 위해 재실행이 쉬운 데이터 파이프라인이다.

Airflow의 등장

야후, 메타 등에서 데이터 엔지니어로 일한 Maxime Beauchemin은 Airbnb에 조인한 뒤 2014년부터 본인의 경험을 집대성(?)해서 Airflow라는 데이터 파이프라인 작성 및 운영 프레임워크를 만들었고 이를 2015년에 오픈소스로 릴리스했다. 10년이 지난 지금 뒤에 쫓아오는 다른 프레임워크들이 있지만 커뮤니티의 크기가 인기도에 있어서 비교가 불가능한 일등 프레임워크로 자리잡았고 그 이유 중의 하나가 바로 Backfill을 쉽게 만드는 아키덱처를 갖고 있기 때문이다. 단 Backfill을 구현하는 건 새로운 개념의 이해와 Airflow의 동작방식의 이해를 필요로 하기에 약간의 시간이 필요하다.

실리콘밸리 데이터 리더가 알려주는 Airflow 기초

2012년말부터 본의 아니게 데이터 도메인으로 넘어가 다양한 회사에서 데이터 일을 하면서 Airflow를 사용해볼 기회도 많았기에 내부 동작에 대해서는 누구보다 잘 안다고 생각한다. 이를 바탕으로 프로그래머스에서 기수제로 15기수에 걸쳐 500여명의 수강생들에게 가르쳐보기도 했고 SK텔레콤의 데이터 엔지니어들을 대상으로 가르쳐보기도 했으며 지금은 산호세 주립대에서 응용 데이터 과학 석사 과정 학생들에게 가르치고 있다. 이 경험을 총정리해서 Docker 위에서 Airflow를 실행하며 Snowflake을 데이터 웨어하우스로 사용하는 총 11시간짜리 강의를 인프런 위에서 만들었다. 이 강의의 "Airflow 기초 프로그래밍" 섹션에서 Backfill의 구현 방법에 대해 집중 설명한다. 데이터 일을 하거나 관심이 있는 사람이라면 강추!

https://inf.run/qRing