Tech
배포된 서비스가 변경 사항을 견딜 수 있는지 확인하기도 전에 스키마 마이그레이션이 실행되는 이유는 무엇인가?
83
기회
프로덕션 데이터베이스에 스키마 변경을 푸시하면, 현재 실행 중인 서비스 버전이 새로운 형태를 읽고 쓸 수 있는지 어떤 도구가 확인하기도 전에 마이그레이션이 실행된다. 삭제된 컬럼이나 이름이 바뀐 필드는 기존 파드가 드레이닝을 마치기 전에 데이터베이스에 반영되고, 롤백은 스키마를 복원하지만 그 사이 새 버전이 기록한 데이터는 되돌리지 못한다. ORM 도구는 diff에서 SQL을 생성하지만 배포 토폴로지, 동시 서비스 버전, 실시간 읽기/쓰기 패턴은 전혀 모델링하지 않는다. 팀들은 위키와 암묵적 지식에 문서화된 확장-축소(expand-contract) 관행으로 이를 보완하지만, 도구로 강제되지는 않는다. 순서 하나가 어긋나 멀티 서비스 연쇄 장애가 발생했고, 지난 1년간 450만 달러 규모의 사고가 공식 기록으로 남아 있다.
왜 중요한가
실제 서비스 토폴로지를 모델링하는 사전 호환성 검사가 있다면, 배포에서 가장 위험한 단계를 적용 버튼을 누르기 전에 충분히 검토할 수 있는 작업으로 바꿀 수 있다.
기회 평가 방식
기회 점수는 측정값이 아닌 제 주관적 평가입니다. 얼마나 불편한지, 얼마나 자주 발생하는지, 현재 해결책이 얼마나 부족한지를 반영합니다. 점수가 높을수록 만들 가치가 더 높다고 생각합니다.
심각도9/10
발생했을 때 얼마나 큰 불편을 초래하는지.
빈도8/10
실제로 얼마나 자주 접하게 되는지.
공백 영역7/10
현재 이를 해결할 만한 도구가 얼마나 부족한지.