백엔드
작은 수정이 전체를 깨뜨리기 시작했을 때: 옐로우버스 DB 재설계 이야기
두줄요약
옐로우버스 일정 시스템은 변경이 연쇄 전파되는 DB 구조 때문에 큰 비용을 치르고 있었습니다. 이를 append-only, decoupling, lazy generation으로 재설계해 안정성과 운영 효율을 높였습니다.
문제 상황
- 운행일정과 탑승일정이 강하게 결합된 구조에서 작은 수정도 전체 데이터 파편화와 대량 재생성으로 이어지는 병목 발생
- 운행일정은 UPDATE와 물리적 분할이 반복되며 추적이 어려워졌고, 탑승일정은 eager generation으로 인스턴스가 기하급수적으로 증가
- 변경 한 번에 수만~수백만 로우가 영향을 받아 운영 리스크와 I/O 비용이 크게 확대
원인 분석
- 데이터를 mutable하게 다루는 설계로 인해 변경이 연쇄 전파되는 구조
- 운행일정의 물리적 레코드를 탑승일정이 직접 참조해 도메인 간 의존성이 과도하게 높았음
- 미래 인스턴스를 미리 생성하는 방식이 저장·수정 비용을 불필요하게 키움
해결 방법
- 변경을 UPDATE가 아닌 INSERT로 표현하는 append-only 구조와 override_weight 기반 해석 도입
- 운행일정과 탑승일정을 논리적 식별자로 연결해 변경 전파를 차단
- 탑승일정 인스턴스는 필요한 시점에만 생성하는 lazy generation으로 전환
