SoundCloud, 문서화되지 않은 100개의 ETL을 6가지 원칙의 데이터 거버넌스로 대체하다

2019년 중반까지 SoundCloud의 데이터 웨어하우스는 더 이상 타당하지 않은 결정들이 6년간 쌓인 결과물이었습니다. 작은 팀 하나가 Amazon Redshift에서 100개가 넘는 ETL 파이프라인을 담당하고 있었고, 대부분은 문서가 거의 없었으며 서로 불일치가 있어 비즈니스 팀과 제품 팀이 데이터를 안정적으로 셀프서비스할 수 없었습니다. Google BigQuery로 이전하는 계약은 팀에게 처음부터 다시 시작할 이유를 주었지만, 2018년 초의 이전 '리프트 앤 시프트(lift and shift)' 마이그레이션 시도는 이미 한 번 중단된 상태였습니다.

새로운 Data Corpus 팀은 테이블을 재구축하기 전에 미션 선언문과 여섯 가지 거버넌스 원칙을 작성했습니다. 품질, 규정 준수, 적시성, 사용성, 효율성, 유지보수성으로, ISO 표준에서 차용한 것입니다. 품질은 새 ETL 버전을 배포된 버전과 비교(diff)하여 의도한 변경만 드러나게 하는 도구를 의미했습니다. 적시성은 모든 ETL과 그 의존성의 착지 시간(landing time)을 매핑하는 것을 의미했으며, 필요한 테이블을 무관한 더 느린 테이블로부터 분리함으로써 파이프라인에서 4시간을 줄였습니다. 유지보수성은 '80퍼센트 원칙'을 의미했습니다. 즉, 엣지 케이스가 아니라 대다수의 요청을 위해 구축하는 것입니다.

재구축은 단계적으로 진행되었습니다. 2019년 12월의 중간 Corpus 릴리스는 여전히 기존 웨어하우스에서 읽었고, 2020년 4월의 Corpus Alpha는 기존 웨어하우스로부터 완전히 독립한 첫 버전이었으며, 2020년 7월의 Corpus 1.0은 여섯 가지 원칙을 모두 충족한 첫 릴리스였습니다. 2021년 4월의 Corpus 2.2에 이르러, 그 결과물인 BigQuery 프로젝트는 읽어 들이는 원시 데이터보다 저장 공간을 약 90퍼센트 덜 사용했으며, 기본 SQL을 다룰 줄 아는 이해관계자들은 문서화되고 설명이 붙은 테이블을 통해 대부분의 질문을 셀프서비스로 해결할 수 있었습니다.

테이블을 단 하나도 작성하기 전에 거버넌스 원칙을 작성하라

자동화된 버전 비교(diff)는 '이 변경이 다운스트림에서 무언가를 망가뜨렸는가'라는 질문을 코드 리뷰의 판단에 맡기는 문제에서 모든 ETL 업데이트마다 실행되는 기계적 점검으로 바꿔 놓았습니다.

80퍼센트 원칙은 범위 확장(scope-creep) 논쟁에 대해 팀이 일관되게 적용할 수 있는 답을 제공했고, 그 덕분에 테이블은 엣지 케이스 복잡성이 쌓이는 대신 비전문가도 질의할 수 있을 만큼 단순하게 유지되었습니다.

ETL 의존성과 착지 시간을 매핑함으로써 막연한 '데이터가 때때로 늦게 도착한다'는 불만이 구체적인 수정, 즉 두 테이블의 분리로 바뀌었고, 측정된 4시간의 개선을 이루었습니다.

약 18개월에 걸쳐 단계별 버전으로 릴리스하고 각 버전을 동일한 여섯 가지 원칙에 비추어 평가함으로써, 팀은 되돌리기 가장 어려운 설계 결정을 내리기 전에 BigQuery의 기능을 익힐 수 있었습니다.

문서화되지 않은 채 성장한 시스템을 마이그레이션할 때는, 새 시스템이 같은 방식으로 썩지 않게 해줄 원칙을 문서로 적고, 그런 다음 각 원칙을 아무도 강제하지 않는 지침이 아니라 자동화된 점검으로 전환하십시오.

SoundCloud는 2.2 이후에도 추가 Corpus 버전을 계속 릴리스하며, 거버넌스 모델을 일회성 마이그레이션 산출물로 취급하지 않고 제품이 발전함에 따라 테이블 적용 범위를 확장했습니다. 팀은 Corpus를 지속적으로 진화하는 프로젝트로 규정하며, 현재 설계가 결국 마이그레이션 이전의 웨어하우스만큼이나 구식으로 보이게 될 것이라고 명시적으로 예상하고, 언제 변경할지를 결정하는 상시 프레임워크로서 동일한 원칙을 유지하고 있습니다.