스키마 변경은 코드 배포가 아니다

테이블을 하나 추가하는 변경을 코드와 함께 배포하려고 마이그레이션 파일을 넣었다. 배포 파이프라인을 확인하다 멈췄다.

Open Table of contents

한 그룹에만 있던 마이그레이션

배포 스크립트를 전부 찾아보니 마이그레이션을 실행하는 자리가 한 곳뿐이었다. 배포 그룹은 넷인데 그중 하나의 설치 후 훅에만 들어 있었다.

그리고 넷이 병렬로 나간다. 마이그레이션이 도는 그룹이 먼저 끝난다는 보장이 없다.

그러면 다른 그룹에 새 코드가 나가는데 테이블이 아직 없을 수 있다. 새 코드가 없는 테이블을 조회하고 오류를 낸다.

마이그레이션이 도는 그룹 안에서도 파일 교체와 마이그레이션 실행 사이에 창이 있다. 그 서버에서 스케줄러가 매분 도는데 그 창에 걸린 작업이 없는 테이블을 참조하고 변경이 클수록 창이 길어진다.

배포 훅에서 마이그레이션이 실패하면 그 그룹만 롤백되고 나머지 셋은 새 코드를 유지한다. 그러면 서로 다른 버전이 동시에 도는 상태가 된다.

한 단계의 실패가 전체를 되돌리지 못하고 일부만 되돌리는 구조라 수습에 사람이 개입해야 한다. 배포 단위와 스키마 적용 단위가 다르다는 것이 이 문제의 형태였다.

스키마 적용을 배포에서 빼고 먼저 적용한 뒤에 코드를 배포하는 순서로 나눴다. 순서가 명확해지고 각각의 실패가 나머지에 영향을 주지 않는다.

적용은 배포 도구가 아니라 별도 절차로 사람이 확인하며 하고 시간이 걸리는 변경은 트래픽이 적은 시간에 했다. 되돌릴 수 있게 적용 전 상태를 먼저 확보하는 것도 절차에 넣었다.

선행 적용이라도 롤백하면 코드는 옛것으로 돌아가고 테이블은 남는 구간이 생긴다. 그래서 새 코드에 테이블이 없을 때 조용히 넘어가지 않고 경고를 남기며 건너뛰는 처리를 넣었다.

이것은 임시 코드이므로 언제 뺄지를 주석에 적어 뒀다. 마이그레이션 파일이 여럿이면 이름의 시각으로 순서가 정해지므로 생성이 변경보다 앞서는지 확인했고 스케줄러가 어느 그룹에서 도는지는 확인하지 못해 미확인으로 적었다.