9강예상 3분중급
[요약] Part 2. 서비스 장애를 막는 마이그레이션 운영 규칙
Part 2. 운영의 공포를 없애는 롤백과 호환성의 핵심 내용을 불릿 포인트로 정리하고 복습하는 요약 회차입니다.
지금까지 Part 2에서 다룬 '운영의 공포를 없애는 롤백과 호환성'의 핵심 내용을 요약합니다. 데이터베이스 마이그레이션 시 발생할 수 있는 장애 상황을 피하고, 롤백과 호환성을 확보하기 위해 반드시 지켜야 할 실무 규칙들을 간결하게 복습해 봅시다.
1. 운영 서버 자동 실행의 위험성
- 자동 실행 금지
- 운영 환경(Production)에서 CI/CD 파이프라인이나 앱 구동 시 마이그레이션을 무조건 자동 실행하는 것은 위험합니다.
- 테이블 락(Lock)이 길어지면 서비스 전체가 멈추는 다운타임이 발생할 수 있습니다.
- 분리 실행의 원칙
- 마이그레이션 실행 시점은 애플리케이션 배포와 분리하여 개발자가 의도한 타이밍에 수동, 혹은 별도 트리거로 실행해야 합니다.
2. 파괴적 변경(Destructive Change) 회피
- 파괴적 쿼리의 종류
- `DROP TABLE`, `DROP COLUMN`, `ALTER COLUMN TYPE` 등 구조를 없애거나 데이터 형태를 강제로 바꾸는 작업입니다.
- 발생하는 문제점
- 복구하기 힘든 데이터 유실이 일어날 수 있습니다.
- 구버전 코드가 삭제된 컬럼을 찾다가 즉각적인 서비스 장애를 일으킵니다.
- 안전한 우회 전략
- 기존 컬럼을 바로 삭제하거나 수정하지 않고, 새로운 컬럼을 추가(`ADD`)하여 덮어쓰는 방식을 최우선으로 고려합니다.
3. 롤백(Rollback)과 Down 스크립트
- 양방향 스크립트 작성
- 마이그레이션 적용을 위한 Up 스크립트와, 장애 시 즉각 복구하기 위한 취소용 Down 스크립트를 항상 짝으로 만듭니다.
- 데이터 유실의 한계
- 스키마 구조는 Down 스크립트로 롤백할 수 있지만, 파괴적 변경으로 인해 한 번 날아간 데이터는 롤백으로 복구할 수 없습니다.
- 방어적 마이그레이션
- 완벽한 롤백이 가능하도록 파괴적인 마이그레이션은 아주 나중으로 미루거나 독립적으로 실행합니다.
4. 하위 호환성(Backward Compatibility) 타이밍 확보
- 엇박자의 원인
- 새로운 코드가 여러 서버에 점진적으로 배포되는 동안, 구버전 앱과 신버전 DB 스키마가 동시에 존재하게 됩니다.
- 추가할 때의 타이밍
- 항상 DB 마이그레이션(컬럼 추가)을 먼저 실행한 뒤, 신버전 앱을 배포합니다.
- 삭제할 때의 타이밍
- 항상 앱에서 참조 코드를 먼저 제거하고 배포를 완료한 뒤, 충분한 시간이 지나고 나서 DB 마이그레이션(컬럼 삭제)을 실행합니다.
운영 환경 마이그레이션 실무 체크리스트
- [ ] 구버전 앱과 호환되는 쿼리인가?
- [ ] 실행 중 테이블 락(Lock)이 얼마나 걸릴지 예상 가능한가?
- [ ] 실패 시 Down 스크립트로 1분 안에 롤백할 수 있는가?
- [ ] 롤백 시 데이터 유실이 없는가?
개념 퀴즈
퀴즈 답을 맞춰야 학습 완료가 됩니다.컬럼을 삭제하는 마이그레이션을 진행할 때, 앱 배포와 DB 마이그레이션의 순서로 가장 안전한 것은 무엇입니까?
3줄 요약
- 1운영 DB 마이그레이션은 자동 실행을 피하고, 파괴적 쿼리를 우회하여 락(Lock)과 데이터 유실을 막아야 합니다.
- 2Up 스크립트와 함께 장애 시 즉시 되돌릴 수 있는 Down 스크립트를 작성하는 습관이 중요합니다.
- 3추가할 때는 DB 먼저, 삭제할 때는 앱 배포 먼저라는 타이밍 원칙으로 하위 호환성을 지켜야 합니다.