[DevOps/Database] 무중단 배포의 함정 : 신구 버전 공존 시 DB 데이터 정합성 문제 해결 전략

About this offer

무중단 배포(Rolling, Blue-Green 등)를 도입하면 서버 인스턴스가 순차적으로 교체되거나 일시적으로 구버전(v1)과 신버전(v2)이 동시에 라이브 환경에 공존하는 과도기(Transition Period)가 반드시 발생합니다. 이때 애플리케이션 코드는 바뀌었는데 데이터베이스(DB) 스키마나 데이터 구조가 이를 따라가지 못하면, 구버전 혹은 신버전 서버가 에러를 내며 서비스 장애로 이어지게 됩니다. 이를 흔히 DB 마이그레이션과 배포 간의 타임 라인 불일치 문제 라고 합니다. 안전한 무중단 배포를 위해 반드시 지켜야 할 DB 변경 및 호환성 유지 전략(Expand & Contract 패턴)을 정리해 봅니다. 1. 흔히 발생하는 데이터 정합성 파괴 시나리오 만약 사용자 테이블( users )의 phone 컬럼을 없애고 mobile_number 컬럼으로 이름을 변경해야 한다고 가정해 봅시다. 잘못된 배포 순서 DB에 직접 접속해 phone 컬럼을 mobile_number 로 바꿉니다. 그 후 신버전(v2) 코드를 배포합니다. 발생하는 문제 DB를 먼저 바꾸는 순간, 아직 떠 있는 구버전(v1) 서버들 은 여전히 phone 컬럼을 조회하거나 삽입하려고 시도합니다. 결과적으로 구버전 서버 전역에서 Column not found SQL 에러가 발생하며 장애가 터집니다. 반대로 코드를 먼저 바꾸면 신버전 코드가 새 컬럼을 찾는데 DB에는 아직 구형 컬럼만 있어 똑같이 에러가 발생합니다. 2. 해결책 : 확장 앤 컨트랙트 (Expand & Contract / Red-Green) 패턴 이 문제를 해결하는 전 세계 시니어 엔지니어들의 표준 디자인 패턴이 바로 확장(Expand)과 수축(Contract) 패턴 입니다. DB 변경 작업을 한 번에 끝내려 하지 말고, 여러 단계의 호환성 배포 단계 로 쪼개서 진행하는 방식입니다. Phase 1 : Expand (확장 단계 - 컬럼/테이블 추가) 기존 구조를 깨지 않고, 신버전이 필요로 하는 새로운 구조를 확장(추가)합니다. 이때 구버전 코드는 기존 구조를 그대로 사용하므로 장애가 발생하지 않습니다. DB 작업 : 기존 phone 컬럼은 그대로 둔 채, 새로운 mobile_number 컬럼을 추가 합니다. (이때 NOT NULL 제약조건은 걸지 않거나 기본값을 둡니다.) 코드 작업 : 구버전 코드는 손대지 않습니다. Phase 2 : Migrate (데이터 이중화 및 이관 단계) 구조가 확장되면, 기존 데이터를 새로운 구조로 옮겨 담거나 양쪽 모두에 동기화합니다. 동작 방식 : 백그라운드 스크립트나 배치 작업을 통해 기존 phone 데이터들을 읽어 mobile_number 로 복사합니다. 이중 쓰기(Dual Write) : 과도기 동안 앱에서 데이터를 쓸 때 구버전/신버전 모두 대응할 수 있도록 처리합니다. Phase 3 : Transition (신버전 배포 단계) 이제 새로운 구조를 이해하는 신버전 코드를 프로덕션에 배포 합니다. 동작 방식 : 롤링이나 블루-그린 배포를 통해 모든 서버를 신버전(v2)으로 교체합니다. 이제 모든 서버는 새로운 컬럼( mobile_number )을 바라보며 정상적으로 동작합니다. 안정성 : 만약 문제가 생겨도 아직 DB에 구형 컬럼( phone )이 살아있으므로 롤백이 매우 안전합니다. Phase 4 : Contract (수축 단계 - 구형 구조 제거) 신버전이 완전히 안착하고 구버전 코드가 완전히 사라진 것이 확인된 이후에야 구형 구조를 잘라냅니다(Contract). DB 작업 : 이제서야 안전하게 기존 phone 컬럼을 DROP COLUMN 으로 삭제합니다. 완료 : 깔끔하게 새로운 스키마만 남게 됩니다. 3. 실무에서 지켜야 할 DB 마이그레이션 3대 원칙 Breaking Change(파괴적 변경) 금지 컬럼명을 강제로 바꾸거나 삭제( DROP COLUMN , RENAME COLUMN )하는 작업은 신구 버전 공존 환경에서 100% 장애를 유발합니다. 반드시 "추가 ➔ 이관 ➔ 전환 ➔ 삭제" 단계를 거쳐야 합니다. 하위 호환성(Backward Compatibility) 유지 새로운 코드는 "구형 DB 스키마"와 " 신형 DB 스키마 "를 둘 다를 일시적으로 소화할 수 있어야 합니다. (예 : 코드가 컬럼이 없으면 구버전 필드를 대신 읽도록 방어 로직 작성) NOT NULL 제약조건 주의 테이블에 새로운 컬럼을 추가할 때 처음부터 NOT NULL 을 걸어버리면 데이터를 넣지 않는 구버전 서버가 인서트할 때 에러가 발생합니다. 처음에는 NULL 을 허용( DEFAULT NULL )했다가, 모든 서버가 신버전으로 교체된 후 NOT NULL 제약을 추가 해야 합니다. 🎯 요약 무중단 배포 시 데이터 정합성 문제는 "DB 변경을 한 번에 하려다 발생하는 시차 문제"입니다. 코드를 바꾸는 배포 주기와 DB 스키마를 바꾸는 마이그레이션 주기를 분리하고, Expand & Contract 패턴 을 적용하여 구버전과 신버전이 동시에 살아 있는 시간 동안에도 서로 충돌하지 않는 유연한 구조를 만드는 것이 핵심입니다.

Offer details

Provider

velog

Source