워크플로 오케스트레이터

여러 작업을 정해진 시각에 돌리는 일은 오래 시간표로 해결했습니다. 새벽 3시에 이것, 3시 20분에 저것을 돌리라고 적어 두면 기계가 그 시각에 실행합니다. 시간표는 사람이 읽기에도 쉽고, 작업이 둘셋일 때는 이것으로 충분합니다.

페이지덱에서 그 방식이 깨진 날이 있었습니다. 원천 데이터를 가져오는 작업을 3시에, 그것을 다듬는 작업을 3시 20분에, 지표를 집계하는 작업을 3시 40분에 걸어 두었습니다. 꺼내고 바꾸고 넣는 이 순서를 ETL이라 부릅니다. 어느 날 가져오기가 20분이 아니라 40분 걸렸습니다.

다듬는 작업은 예정대로 3시 20분에 돌았습니다. 가져오기가 아직 끝나지 않았다는 사실을 모른 채 절반만 들어온 데이터를 다듬었고, 집계도 3시 40분에 그 결과로 돌았습니다. 아침에 지현이 열어 본 대시보드에는 전날 매출이 실제의 절반으로 적혀 있었습니다.

아무것도 실패하지 않았다는 점이 이 사고의 성질입니다. 세 작업 모두 자기 몫을 정상으로 끝냈고 오류도 나지 않았습니다. 어긋난 것은 순서에 대한 가정뿐입니다. 시간으로 순서를 표현하면 앞 작업이 예상보다 오래 걸리는 날마다 같은 일이 반복됩니다.

시각이 아니라 앞 작업의 성공을 조건으로 걸어 순서를 관리하는 도구가 그래서 자리를 잡았습니다.

다섯 가지를 처리합니다.

1. 순서를 관계로 적습니다. 3시 20분에 시작하라고 적는 대신 가져오기가 성공하면 시작하라고 적습니다. 작업이 열 개로 늘고 그중 셋이 서로를 기다려야 하면 시간표로는 표현할 방법이 없지만, 화살표로는 그대로 그려집니다.
2. 실패를 다룹니다. 몇 번까지 다시 시도할지, 얼마 간격을 둘지, 끝내 실패했을 때 뒤 작업을 멈출지 아니면 건너뛸지를 작업마다 정해 둡니다. 외부에서 데이터를 받는 작업은 두 번째 시도에서 성공하는 일이 잦아서 이 설정만으로 사람 손이 크게 줄어듭니다.
3. 부분만 다시 돌립니다. 다섯 작업 중 넷째에서 실패했을 때 처음부터 돌리면 앞의 세 작업 시간을 다시 씁니다. 실패한 지점부터, 그리고 어제 날짜 몫만 다시 돌릴 수 있게 해 주는 것이 이 도구의 실용적인 값입니다. 재실행할 수 있는 단위를 날짜로 잡아 두었는지가 이 값을 쓸 수 있는지를 가릅니다.
4. 보이게 만듭니다. 어느 작업이 몇 분 걸렸고 어디서 멈췄는지가 화면에 남습니다. 어제보다 오래 걸리기 시작한 작업을 미리 알아채는 자리가 여기입니다.
5. 알립니다. 실패했을 때뿐 아니라 정해진 시각까지 끝나지 않았을 때도 알림을 보냅니다. 뒤쪽이 더 중요합니다. 실패는 오류로 드러나지만 늦어지는 것은 아침에 빈 대시보드를 보기 전까지 아무도 모릅니다.

쓰는 모양은 대개 같습니다. 작업 하나하나를 코드로 적고 그 사이의 의존을 화살표로 이어 그래프를 만듭니다. 작업 안에서 실제로 하는 일은 질의 문장이거나 스크립트이고, 이 도구는 그것을 실행하고 결과를 확인할 뿐입니다. 지난 30일을 다시 계산해야 할 때도 같은 그래프에 날짜만 바꿔 넣습니다. 그래프가 코드로 남으므로 언제 무엇이 바뀌었는지도 이력으로 쌓입니다.

작업 수와 의존의 깊이에 따라 고르는 것이 넷입니다.

1. 시간 기반 스케줄러. 정해진 시각에 명령을 실행하는 가장 단순한 방식이고, 서로 기다릴 필요 없는 작업이 셋 안쪽이면 이쪽이 낫습니다. 작업 이름과 시각만 적으면 되니 배울 것도 없습니다. 앞에서 본 사고는 의존이 생긴 뒤에도 이 방식을 쓴 결과입니다.
2. 저장소 안에서 변환을 관리하는 도구. 원천 데이터를 먼저 넣고 저장소 안에서 다듬는 ELT 방식을 쓰면 변환 사이의 순서를 그 도구가 알아서 정해 줍니다. 다만 다루는 범위가 변환뿐이라, 원천에서 가져오는 일과 알림은 밖에 남습니다.
3. 관리형 서비스. 같은 기능을 직접 설치하고 운영하지 않고 빌려 씁니다. 서버를 돌볼 사람이 없는 팀에 맞고, 대신 비용이 작업 수에 따라 붙고 옮기기가 어려워집니다.
4. 손으로 돌리기. 초기에는 실제로 선택지입니다. 주에 한 번 집계 두 개를 돌리는 정도라면 도구를 들이는 값이 손으로 하는 값보다 큽니다.

고르는 기준은 셋입니다. 작업 수가 열을 넘는지, 서로 기다려야 하는 관계가 있는지, 그리고 실패했을 때 사람이 아침에 알아야 하는지입니다. 세 번째가 걸리면 대개 도구를 들일 시점입니다.

"가져오기가 늦어졌는데 집계가 그냥 돌았어요. 의존을 걸어야 합니다."

시각이 아니라 앞 작업의 성공을 조건으로 바꾸자는 말입니다.

"어제 날짜만 다시 돌려 주세요. 전체는 두 시간 걸려요."

부분 재실행이 왜 필요한지 보여 주는 요청입니다.

"실패 알림은 오는데 지연 알림이 없어요."

늦어지는 상황을 잡는 장치가 빠졌다는 지적입니다.

페이지덱에서는 태오가 그래프를 관리하고 지현이 결과를 씁니다. 새 지표를 추가할 때 태오가 먼저 묻는 것은 이 값이 언제까지 준비돼 있어야 하는지입니다. 아침 10시 회의에 쓰인다면 그 시각을 기준으로 역산해 알림을 걸고, 그날 안에만 맞으면 되는 값이면 알림 없이 목록에만 남깁니다.

그래프가 커지면 관리 대상이 됩니다. 지금은 쓰이지 않는 집계가 계속 돌고 있는 일이 생기므로, 분기마다 아무도 열어 보지 않는 결과를 찾아 그 작업을 그래프에서 뺍니다.

데이터를 처리하는 도구라고 여기는 경우가 많습니다. 데이터 파이프라인 이야기에서 가장 먼저 나오는 이름이니 그렇게 읽힙니다. 하지만 이 도구가 하는 일은 순서를 관리하고 실행을 확인하는 것뿐입니다. 이 도구는 작업이 성공했다고 답했는지만 봅니다. 실제로 데이터를 옮기고 다듬는 일은 각 작업 안의 코드가 하고, 무거운 계산은 대개 데이터 웨어하우스 쪽에서 돕니다. 이 구분을 놓치면 느린 집계의 원인을 도구에서 찾게 되고, 정작 고쳐야 할 질의 문장은 그대로 남습니다.

도구를 들이면 파이프라인이 안정된다고 보는 것도 흔합니다. 실패를 다루는 기능이 들어 있으니 그렇게 기대하게 됩니다. 그런데 재시도 횟수와 지연 알림과 부분 재실행은 모두 사람이 설정해야 동작합니다. 기본값으로만 두면 옮겨 온 시간표가 그래프 모양이 됐을 뿐이고, 사고는 같은 자리에서 다시 납니다. 도구를 들이는 값의 절반은 이 설정을 작업마다 정하는 데서 나옵니다.