SoundCloudは100本の文書化されていないETLを6原則のデータガバナンスで置き換えた

2019年半ばまでに、SoundCloudのデータウェアハウスはもはや意味をなさない6年分の決定の積み重ねになっていた。小規模な単一チームがAmazon Redshift上の100本以上のETLパイプラインを所有し、そのほとんどがほとんど文書化されておらず、相互に不整合があったため、ビジネスチームやプロダクトチームはデータを信頼してセルフサービスで利用できなかった。Google BigQueryへの移行契約はチームにやり直す理由を与えたが、2018年初頭の初期の「リフト・アンド・シフト」方式の移行試行はすでに一度中止されていた。

新しいData Corpusチームは、テーブルを再構築する前にミッションステートメントと6つのガバナンス原則を書いた。品質、コンプライアンス、適時性、使いやすさ、効率性、保守性であり、ISO標準から適応したものだった。品質とは、新しいETLバージョンをデプロイ済みのものと差分比較するツールを意味し、意図した変更だけが現れるようにした。適時性とは、すべてのETLとその依存関係のランディング時刻をマッピングすることを意味し、必要なテーブルを無関係な遅いテーブルから切り離すことでパイプラインから4時間を削減した。保守性とは「80パーセント原則」を意味し、エッジケースではなく大多数のリクエストのために構築することだった。

再構築は段階的に行われた。2019年12月の中間的なCorpusリリースは依然として旧ウェアハウスから読み取っていた。2020年4月のCorpus Alphaはそれから完全に独立した最初のバージョンであり、2020年7月のCorpus 1.0は6つの原則すべてを満たす最初のリリースだった。2021年4月のCorpus 2.2までに、結果として得られたBigQueryプロジェクトは、読み取り元の生データと比べてストレージ使用量が約90パーセント少なくなり、基本的なSQLが使えるステークホルダーは文書化・説明されたテーブルを通じてほとんどの質問をセルフサービスで解決できるようになった。

テーブルを1つ書く前にガバナンス原則を書く

自動化されたバージョン差分比較により、「この変更が下流で何かを壊したか」という問いが、コードレビューでの判断から、ETL更新のたびに実行される機械的なチェックへと変わった。

80パーセント原則により、チームはスコープクリープの議論に対する常設の答えを得たため、テーブルはエッジケースの複雑さを蓄積するのではなく、非専門家でもクエリできるほどシンプルに保たれた。

ETLの依存関係とランディング時刻をマッピングすることで、漠然とした「データが時々遅れる」という不満が、2つのテーブルを切り離すという具体的な修正へと変わり、測定された4時間の改善が得られた。

約18か月にわたって段階的なバージョンでリリースし、それぞれを同じ6つの原則に照らして評価したことで、チームは最も覆しにくい設計上の決定を行う前にBigQueryの機能を学ぶことができた。

文書化されないまま成長したシステムを移行するときは、新しいシステムが同じように腐敗するのを防ぐ原則を書き留め、それぞれを誰も強制しないガイドラインではなく自動チェックに変えよ。

SoundCloudは2.2以降もさらにCorpusのバージョンをリリースし続け、ガバナンスモデルを一度きりの移行成果物として扱うのではなく、プロダクトの進化に合わせてテーブルのカバレッジを拡大した。チームはCorpusを継続的に進化するプロジェクトと位置づけ、現在の設計がいずれ移行前のウェアハウスと同じように時代遅れに見えるようになることを明示的に予期しており、いつ変更すべきかを判断するための常設の枠組みとして同じ原則を維持している。