5.5 Schema 변경과 Blue/Green
새 schema를 적용한 사본에서 시험을 끝냈어도 운영 전환 준비는 더 필요합니다. 시험 중 운영 DB에 들어온 주문과 수정 내역을 어디까지 반영했는지 확인해야 합니다. 새 schema로 기록한 데이터를 이전 애플리케이션이 읽는지도 확인해야 합니다. 이 장에서는 schema 변경 배포와 DB 환경 전체 전환을 나누어 판단합니다. 두 경로의 검토 항목은 겹치지만, 변경 추종 대상과 되돌리기 단위는 다릅니다.
검토 문서에는 사본을 만든 시각보다 운영 반영의 전제 조건을 먼저 적습니다. 대상 엔진, 변경 SQL, 원본 추종 방식, 쓰기 중단 구간, 실패 시 복귀 지점을 명시합니다. 아래 부하 점검과 승인 절차는 운영 정책 제안입니다. 공개 고객 사례에서 확인하지 못한 임계값이나 내부 절차는 해당 고객사의 정책으로 소개하지 않습니다.
적용 계층과 제품
PlanetScale Vitess의 deploy request는 개발 branch의 schema 차이를 검토합니다. 이후 대상 branch에 배포하는 절차입니다. 개발 branch에서 추가한 시험 행을 운영 데이터와 3-way 머지하는 기능은 아닙니다. 이 Vitess 절차의 적용 대상은 PlanetScale Vitess로 한정합니다. PlanetScale Postgres의 branch는 빈 DB와 backup 복원 경로를 구분합니다. 부모와는 지속 복제되지 않습니다. PlanetScale Postgres 문서의 범위를 함께 확인합니다.
Vitess의 일반 온라인 변경 경로에서는 변경 대상 테이블의 사본을 만듭니다. 새 schema를 적용한 뒤 원본 데이터와 동기화합니다. 준비된 테이블로 교체하는 단계가 cutover입니다. 자동 적용을 해제한 deploy request는 동기화 완료 후 사람이 cutover 시점을 선택하도록 구성합니다. 이 설명은 테이블 복사 경로에 한정하며, 별도 instant 배포와 구분합니다. Deploy request 문서가 적용 방식의 근거입니다.
Superwall은 branching과 deploy request를 사용합니다. GitHub Actions와 API를 연결해 PR마다 branch를 만드는 사례입니다. 신뢰도는 보통입니다. 고객 인터뷰를 포함한 공급사 자료에서 도입을 확인합니다. 다만 개별 DDL의 운영 지연과 rollback 성공률은 확인하지 못했습니다. 공개된 애플리케이션 사용 규모는 애플리케이션 규모를 설명하는 데 한정합니다. Superwall 사례는 자동화 연결의 근거로 사용합니다.
Aurora Blue/Green은 운영 스토리지의 clone으로 green 환경을 준비합니다. 여기에 변경 동기화를 결합합니다. 전환 대상은 테이블 교체보다 넓은 DB 환경입니다. 공식 기능 근거의 신뢰도는 높음입니다. 조사 자료에서 관리형 Blue/Green을 사용한 실명 고객의 상세 운영 사례는 미확인입니다. Aurora Blue/Green 문서의 기능 설명과 고객 도입 증거를 구분합니다.
Aurora PostgreSQL에는 major version 업그레이드 절차도 공개되어 있습니다. fast clone과 논리 replication을 결합한 절차입니다. 이 수동 구성 절차와 관리형 Blue/Green의 명령 흐름은 구분합니다. 또한 Blue/Green이라는 이름만으로 임의의 schema 변경을 허용하지 않습니다. 선택한 엔진과 버전의 DDL 제약을 먼저 확인합니다. 허용되지 않는 변경은 별도 배포로 분리합니다. 논리 replication 업그레이드 문서를 참고합니다.
운영 DB에 주는 부하
온라인 DDL의 테이블 복사와 변경 추종은 운영 작업과 동시에 진행합니다. 따라서 운영 영향은 복사 시작 전, 복사 진행 중, cutover 대기 중에 따로 측정합니다. 애플리케이션 쿼리 지연, DB CPU, 읽기와 쓰기 입출력을 관찰합니다. 변경 추종 지연과 임시 테이블 공간도 관찰 항목에 포함합니다. 온라인이라는 표현을 부하가 없다는 의미로 사용하지 않습니다.
부하 리허설은 변경 SQL을 한 번 실행하는 데서 그치지 않습니다. 대표 시간대의 쓰기를 유지하면서 복사 진행률과 운영 지연을 함께 기록합니다. 복사 속도를 낮춘 시험도 수행합니다. 운영 응답을 보호하면서 허용된 배포 시간 안에 끝나는지 비교합니다. 동일 테이블이나 큰 테이블 여러 개의 변경이 겹치는 상황은 별도 시험으로 관리합니다. 이 절차는 특정 공급사의 성능 보장 여부와 관계없이 수행합니다.
Aurora clone의 초기 공유는 전체 데이터 복사를 줄입니다. 이후 원본이나 clone의 쓰기는 추가 page 공간을 요구합니다. green의 변경량만 보고 총 저장량을 예측하지 않습니다. blue의 일상적인 갱신과 green의 업그레이드 및 시험을 같은 관찰 기간에 포함합니다. 공유 page와 추가 공간의 관계는 Aurora clone 문서에서 설명합니다.
논리 replication을 쓰는 경로에서는 WAL 생성, 보존, 전송과 적용 지연을 관찰합니다. green에서 무거운 시험을 시작한 뒤 지연이 줄어드는지 계속 증가하는지 확인합니다. 작업을 중단했을 때 정상 추종 상태로 돌아오는 시간도 기록합니다. clone 자체의 존재와 원본 WAL 보존의 원인을 혼동하지 않도록 합니다. 이를 위해 어떤 replication 경로가 어떤 로그를 유지하는지 구성도에 표시합니다.
운영 중단 기준은 시험 전에 정합니다. 예를 들어 서비스의 기존 지연 목표를 넘으면 cutover를 보류하도록 설계합니다. 복제 지연이 승인된 전환 시간 안에 해소되지 않을 때도 보류하도록 합니다. 저장 공간의 안전 여유가 부족해질 때도 같은 기준을 적용합니다. 숫자는 서비스별 측정 결과로 채웁니다. 별도 branch에서 migration의 시간과 lock 대기를 기록하는 실습도 연결합니다. 해당 실습은 Neon Schema Migration 리허설입니다.
흔한 실패
첫 번째 실패 가설은 단순 clone을 만든 뒤 원본 추종을 구성했다고 착각하는 경우입니다. 검증 문서에는 분기 시점과 최종 동기화 확인 시점을 별도로 적습니다. 운영 쓰기를 계속 허용하는 시험이라면 그 사이의 변경이 green에 반영되는지 확인해야 합니다. 전환 직전 행 수가 비슷하다는 관찰만으로 변경 누락 여부를 판정하지 않도록 합니다. 이를 위해 대조 절차를 둡니다.
두 번째는 schema를 되돌리면 데이터도 항상 보존된다고 가정하는 경우입니다. PlanetScale 공식 문서는 일반 deploy request의 revert를 배포 후 30분까지 설명합니다. instant 배포는 제외합니다. revert로 새 테이블이나 새 컬럼이 없어지면 해당 객체에 쓴 데이터도 사라집니다. 컬럼을 확장한 뒤 이전 크기에 맞지 않는 값을 기록했다면 revert가 실패할 조건도 있습니다. 따라서 되돌리기 시간과 데이터 호환 조건을 함께 검토합니다.
예를 들어 문자열 컬럼의 길이를 늘리는 변경을 시험한다고 가정합니다. 새 애플리케이션이 이전 길이를 넘는 값을 쓰는 경우도 시험에 넣도록 제안합니다. 이 시험에서는 배포 성공 여부와 이전 schema로의 복귀 가능 여부를 따로 기록합니다. 이후 쓰기를 허용할 값의 범위를 제한할지 배포 전에 결정합니다. 복귀 대신 후속 수정으로 대응할지도 함께 결정합니다.
Aurora는 switchover의 사전 검사에서 replication 상태와 지연 등을 확인합니다. 전환 중에는 쓰기와 연결을 제한한 뒤 동기화를 기다립니다. 전환 완료 전 실패한 작업의 rollback은 완료 후 이전 환경으로 돌아가는 작업과 구분해야 합니다. 공식 문서는 완료 후 blue와 green 사이의 replication이 중단된다고 설명합니다. 따라서 새 운영 환경의 쓰기를 이전 blue가 자동으로 보유한다고 가정하지 않습니다. Switchover 문서를 기준으로 복귀 계획을 작성합니다.
운영 정책 제안
변경 요청은 schema-변경번호, 환경은 green-릴리스번호로 식별하도록 제안합니다. 요청에는 작성자, DBA, 애플리케이션 담당자, 최종 승인자와 실행 담당자를 기록합니다. migration 파일의 checksum과 검증한 코드 버전을 고정합니다. 검토 이후 SQL이 바뀌면 기존 승인을 재사용하지 않도록 절차를 정합니다. 변경 대상 테이블과 서비스의 연결 관계도 같은 요청에 남깁니다.
cutover 승인에는 schema 검토 완료, 허용된 DDL 범위, 변경 추종 정상을 포함합니다. 최근 지연 추세, 쓰기 차단 및 연결 재시도 시험도 포함합니다. 모니터링 화면의 한 번의 정상 표시보다 일정 관찰 기간의 결과를 사용합니다. 전환 중 판단 담당자가 자리를 비우거나 관찰 지표가 끊기면 작업을 시작하지 않습니다. 시간 제한에 걸린 뒤 같은 요청을 재시도할 조건도 정합니다.
rollback 계획은 전환 전 취소, 전환 도중 실패, 새 환경에서 쓰기를 받은 뒤의 장애로 나누어 작성합니다. 각 단계에 보존할 데이터, 재시작할 코드, 허용할 중단 시간과 데이터 대조 담당자를 적습니다. 특히 새 운영 쓰기 이후에는 이전 환경으로 접속 경로만 돌리는 절차를 승인하지 않습니다. 미반영 변경을 처리할 방법을 확인한 뒤 복귀 여부를 판단하도록 제안합니다.
이전 환경의 TTL은 전환 성공 이벤트만으로 짧게 고정하지 않습니다. 관찰 기간, 데이터 대조 완료, 복구 계획의 변경과 보존 비용을 함께 검토해 종료일을 정합니다. 종료일은 반드시 정해 두도록 합니다. 연장이 필요하면 사유와 다음 검토 날짜를 기록합니다. 삭제 작업에는 대상 식별자를 다시 대조하는 절차를 둡니다. 마지막 승인 기록에는 남겨 둔 자원과 삭제할 자원을 구분해 적습니다.
도식
아래 그림은 두 제품의 반영 단위를 비교합니다. 실선은 데이터 준비와 변경 추종을 나타냅니다. 점선은 검토와 승인 후 실행하는 제어 흐름을 나타냅니다. Vitess의 테이블 사본과 Aurora의 green 환경은 복제 단위의 크기가 다릅니다. 그림의 대기 상태는 본 장의 운영 정책 제안입니다. 모든 서비스에 같은 상태 이름이 존재한다는 뜻은 아닙니다.
리허설 결과에는 각 화살표의 시작과 종료 시각을 붙이도록 제안합니다. 특히 변경 추종 시작 전의 준비 시간과 cutover 직전 대기 시간을 따로 남깁니다. 전환이 지연되면 어느 단계에서 지연이 늘었는지 비교합니다. 다음 실행에서는 해당 단계의 동시 작업이나 승인 절차를 조정합니다.