Cloud SQL MySQL blue-green 미리보기: 업그레이드 전 비용·전환 조건 확인

Google Cloud가 2026년 10월 28일 Cloud SQL for MySQL의 관리형 blue-green 배포를 미리보기로 발표했습니다. 운영 중인 데이터베이스를 그대로 둔 채 별도 환경에서 변경을 검토하고, 준비가 됐을 때 연결을 전환하는 선택지입니다. 다만 미리보기를 모든 구성의 완전 무중단 업그레이드나 자동 원복 보장으로 읽으면 안 됩니다. 지원 조건, 실제 애플리케이션 검수, 두 환경을 유지하는 비용까지 함께 살펴봐야 합니다.

이 글은 11월 2일 공식 발표와 문서를 읽은 도입 판단 해설입니다. 데이터베이스를 만들거나 업그레이드·전환·복구를 실행하지 않았습니다. 아래 비교표와 검수 질문은 작성자의 제안이며 실제 고객 사례나 성능 시험 결과가 아닙니다. 11월 3일의 계정별 지원과 작업 성공을 보장하지 않고, 운영계에서 실행할 명령이나 삭제 절차도 제공하지 않습니다.

blue와 green은 무엇을 나누는 이름인가요?

10월 28일 공식 발표는 MySQL의 주 버전 업그레이드와 구성 변경을 검토하는 관리형 미리보기를 소개합니다. blue는 현재 서비스를 처리하는 원본 환경, green은 변경을 준비하는 별도 환경입니다. green을 동기화하며 검수한 뒤 계획된 switchover, 즉 서비스 연결 전환을 수행하는 흐름입니다. 발표에는 PostgreSQL 지원이 향후 계획으로 표시되어 있어 현재 지원으로 확대하지 않았습니다.

이 방식의 의미는 변경 준비와 실제 운영 전환을 분리해 생각할 수 있다는 데 있습니다. 새 버전이 만들어졌다는 상태, 필요한 업무를 확인했다는 상태, 실제 서비스가 새 환경을 이용한다는 상태는 다릅니다. 구매·운영 검토 문서에서도 세 상태를 하나의 완료 표시로 묶지 않는 편이 좋겠습니다. 준비 단계에서 확인할 시간을 확보하는 것과 최종 판단을 자동화하는 것은 같은 일이 아닙니다.

관리형 서비스 자체를 도입할지 고민하는 질문과, 이미 운영 중인 DB를 어떻게 바꿀지는 구분해 볼 만합니다. 전자의 책임 비교는 PostgreSQL을 예로 든 자체 운영·관리형 DB 선택 글에서 다뤘습니다. 이번 글은 다른 엔진인 MySQL의 새 변경 방식과 그 조건에 집중합니다.

현재 MySQL이면 모두 검토할 수 있나요?

생성·준비 문서는 정식 제공 전 약관과 제한된 지원 가능성을 명시합니다. 주 버전 업그레이드 경로는 MySQL 8.0에서 8.4로 설명하며 8.0.18은 지원하지 않습니다. 버전을 유지한 구성 검토와 버전을 바꾸는 작업의 조건도 구분합니다. 읽기 복제본, Private Service Connect outbound, IAM 그룹 인증 등 미지원 항목을 확인해야 합니다. 제품 이름만으로 자신의 구성이 대상이라고 판단할 수는 없습니다.

같은 문서는 자동 백업·바이너리 로그, 최신 유지보수 버전, 새 네트워크 아키텍처 등도 전제로 둡니다. 바이너리 로그는 데이터 변경 기록을 남기는 방식이며 여기서는 설정 방법을 안내하지 않습니다. 필요한 상태를 확인하는 일과 실제 운영 설정을 바꾸는 일은 별도 작업입니다. 도입 검토 중이라는 이유로 전제조건을 맞추려고 운영계를 즉시 변경할 필요는 없습니다.

우선 현재 엔진과 정확한 버전, 연결 구조, 복제본 사용 여부를 내부 목록으로 정리하는 방식을 제안합니다. 그다음 공식 지원 조건과 맞는 항목, 다르거나 알 수 없는 항목을 나눠 보세요. 미확인은 지원 불가와 같지 않지만, 준비 완료로 볼 수도 없습니다. 지원받을 수 있는 구성인지 먼저 확인하면 아직 적합하지 않은 기능을 전제로 일정을 잡는 일을 줄일 수 있습니다.

검토 항목	먼저 정리할 답
변경 목적	주 버전 변경인지, 같은 버전의 구성 검토인지
현재 환경	정확한 버전, 복제본, 네트워크와 인증 방식
준비 조건	백업·변경 기록·유지보수 상태의 확인 담당자
남은 질문	공식 지원 확인이 끝나지 않은 항목과 일정 영향

준비 완료 상태가 뜨면 검수도 끝난 건가요?

공식 전환 문서는 준비 상태인 SWITCHOVER_READY가 복제의 정상 상태를 뜻하며, 그 표시를 정할 때 복제 지연까지 평가하지는 않는다고 설명합니다. 전환 전에 업무 검수와 낮은 복제 지연을 확인해야 합니다. 복제 지연은 원본의 변경이 대상에 반영되기까지 뒤처진 정도를 말합니다. 준비 상태 하나로 애플리케이션 호환성이나 전환 시간을 확정할 수는 없습니다.

아래는 자체 검수 설계 제안입니다. 대표 화면이 열리는지만 보지 말고, 실제 업무에서 자주 쓰는 조회·집계 결과와 응답 조건을 정리해 보세요. 같은 입력과 확인 시점을 맞춰 비교하면 결과 차이가 데이터 시점 때문인지, 변경 영향 때문인지 구분하는 데 도움이 됩니다. 어떤 검사를 green에서 수행할 수 있는지는 권한과 서비스 제약 안에서 담당자가 정해야 합니다.

검수표에는 기능 이름보다 성공 조건을 적는 편이 좋습니다. 예를 들어 “보고서 확인”보다 “승인한 기준 자료의 합계와 항목이 맞는지 확인”이 판단하기 쉽습니다. 이는 가상의 업무 예시입니다. 여기서 실제 쿼리 결과나 처리 시간이 같았다고 주장하는 것은 아닙니다. 오래 걸리는 작업이 있다면 한 번의 화면 확인으로 대표했다고 처리하지 않도록 검수 범위에 따로 남겨 보세요.

운영 DB를 맡는 사람과 애플리케이션을 맡는 사람이 다르다면 각자 무엇을 확인했는지도 분리해 두세요. 플랫폼의 상태 확인, 업무 결과 확인, 오류 기록 확인은 서로 보완하는 자료입니다. “이상 없음”이 어느 검사 범위를 뜻하는지 적어 두면 다음 단계 승인도 구체적이 됩니다. 관리형 자동 점검이 회사 업무의 정답까지 알고 있다고 전제할 필요는 없습니다.

전환은 장애 복구와 어떻게 다른가요?

개요 문서는 blue-green 전환을 정상 실행 중인 원본을 전제로 하는 계획된 변경으로 구분합니다. green은 원본의 갑작스러운 장애를 대신 처리하는 자동 장애 전환 대상으로 쓰는 기능이 아닙니다. 따라서 고가용성이나 재해 복구 계획을 새 업그레이드 방식 하나로 대체한다고 판단하면 안 됩니다.

검토할 때는 “변경을 안전하게 진행하는 계획”과 “예상하지 못한 장애를 처리하는 계획”을 두 줄로 적어 보세요. 전자의 승인 시점과 검수 자료가 잘 정리되어 있어도 후자의 연락 체계와 복구 기준까지 완성되는 것은 아닙니다. 서로 다른 목적을 나누면 어떤 도구를 구매하거나 유지해야 하는지 설명하기도 쉬워집니다.

전환 문서는 연결이 잠시 끊길 수 있고 중단 시간은 에디션과 작업량·복제 지연에 따라 달라진다고 설명합니다. 복제 지연이 크거나 진행 중인 트랜잭션이 전환을 막으면 작업이 실패하고 원본이 계속 서비스할 수 있습니다. 공급자의 짧은 중단 시간 설명을 우리 시스템의 성공 약속으로 옮겨 읽기보다, 실제 업무가 허용하는 전환 창과 재연결 확인을 준비하는 편이 좋겠습니다.

사용자 관점의 완료 조건도 함께 제안합니다. 운영 환경이 바뀌었다는 상태 외에 필요한 화면과 처리 흐름이 새 환경에서 정상인지, 변경 시점에 걸쳐 있던 업무는 어떻게 확인할지 정해 보세요. 이 글은 무조건 재시도하라는 애플리케이션 설계를 권하는 것이 아닙니다. 업무에 따라 중복 처리나 누락을 확인할 책임과 근거가 달라지므로 해당 서비스의 승인된 방식으로 판단해야 합니다.

예전 blue를 남기면 곧바로 되돌릴 수 있나요?

개요 문서는 전환 후 green이 운영 읽기·쓰기를 맡고, blue는 독립적인 읽기·쓰기 인스턴스로 남으며 둘 사이의 기존 논리 복제는 종료된다고 설명합니다. 원본 인스턴스가 남아 있다는 사실과 전환 후 새 데이터까지 자동으로 같은 상태라는 사실은 다릅니다. 따라서 예전 blue가 있다는 이유만으로 언제든 자동 원복할 수 있다고 결론내리지 마세요.

복귀 판단을 검토한다면 데이터의 기준 시점부터 질문해 보세요. 언제까지의 자료가 각 환경에 있는지, 전환 후 발생한 업무가 무엇인지, 다시 운영 대상을 바꿀 때 어떤 검증이 필요한지 정해야 합니다. 이는 실행 지침이 아닌 계획 검토 질문입니다. 이 글은 독자의 쓰기 흐름이나 백업을 보지 못했으므로 안전한 복귀 순서나 데이터 일치 결과를 제시하지 않습니다.

가상의 주문 서비스에서 전환 뒤 새 주문을 받은 상황을 생각해 보겠습니다. 이전 환경에 접속할 수 있다는 사실만 확인하고 업무를 되돌리는 판단은 충분하지 않을 수 있습니다. 중요한 것은 예전 화면이 열리는지가 아니라 그 사이 처리한 업무의 기준과 책임입니다. 이 예시는 실제 사고 사례가 아니며, 어떤 복구 방식이 옳은지는 서비스별 자료와 승인 절차를 바탕으로 결정해야 합니다.

추가 요금이 없다면 비용도 그대로인가요?

개요 문서는 blue-green 기능 자체에 별도 사용 요금은 없지만, 두 환경이 존재하는 기간에는 blue와 green 인스턴스가 표준 요율로 청구된다고 설명합니다. 전환이 끝나도 이전 인스턴스를 남기면 그 비용은 계속될 수 있습니다. 정확히 두 배라고 계산할 근거는 여기서 확인하지 않았으며 구성과 유지 기간을 반영한 실제 견적이 필요합니다.

예산표에는 환경을 만드는 날뿐 아니라 검수 기간, 전환 후 관찰 기간, 정리 승인 시점을 적어 보는 것을 제안합니다. 기능 비용이 없다는 한 줄로 시작과 끝을 생략하면, 업무 일정이 미뤄졌을 때 왜 청구가 늘었는지 설명하기 어렵습니다. 날짜를 짧게 잡아 비용을 줄이는 것보다 검수를 완료할 수 있는 기간을 먼저 합의하는 편이 합리적입니다.

또한 최종 확인 담당자와 정리 담당자가 다르다면 두 사람 사이의 완료 조건을 맞춰 보세요. DB 전환 성공만 보고 정리를 서두르거나, 반대로 모두가 끝난 것으로 생각한 채 이전 환경을 계속 남기는 상황을 피하기 위한 제안입니다. 유지 이유와 다음 검토 시점이 있는 상태인지, 단지 담당자를 정하지 못해 남아 있는지 구분하면 비용 판단도 구체적이 됩니다.

취소와 정리는 같은 동작으로 봐도 될까요?

공식 삭제 문서는 전환 전 취소와 전환 후 정리의 동작을 나눠 설명합니다. 전환 전에는 green 준비 환경을 제거하고 운영 중인 blue를 유지합니다. 전환 후에는 배포 메타데이터만 지우면 두 인스턴스가 기본적으로 남고, 이전 blue를 제거하는 것은 별도 선택입니다. 같은 정리라는 이름만 보고 대상 자원을 추정하면 안 됩니다.

따라서 실제 작업 전 검토 자료에는 현재 단계, 운영 역할을 맡은 대상, 남겨야 하는 자료, 정리 후 청구 대상을 적어 보세요. 권한이 있다는 사실만으로 삭제 대상의 검증이 끝나는 것은 아닙니다. 이 글에서는 변경·삭제 명령을 제공하지 않으며, 실제 정리는 회사의 승인된 백업·보존·복구 기준에 따라 별도 검증할 일입니다.

판단 시점	다음 단계 전에 남길 답
준비 환경 검수 전	지원 조건과 검수할 업무 범위가 확인됐나요?
전환 결정 전	지연·진행 작업·업무 영향과 승인자가 확인됐나요?
전환 완료 후	실제 업무와 데이터 기준을 누가 확인했나요?
정리 결정 전	운영 대상·보존 목적·비용·복구 요구를 합의했나요?

자주 묻는 질문과 이번 확인의 한계

Cloud SQL PostgreSQL도 같은 방식으로 지원되나요? 이번 발표는 MySQL 미리보기이며 현재 문서는 PostgreSQL과 SQL Server를 미지원으로 구분합니다. 향후 계획과 지금 선택할 수 있는 기능은 다릅니다. 실제 엔진·버전의 현재 문서를 확인해 주세요.

준비 완료라면 전환 시간을 확정할 수 있나요? 상태 표시와 업무 검수, 복제 지연 확인은 별개입니다. 공급자가 설명한 전환 시간은 독자의 시스템에서 측정한 값이 아닙니다. 이 글은 무중단이나 특정 초 이내 완료를 보장하지 않습니다.

지금 도입 판단에 가장 필요한 것은 무엇일까요? 지원 조건에 맞는지, 회사가 필요한 업무를 검수할 수 있는지, 병렬 환경 비용과 전환 후 책임을 정할 수 있는지입니다. 미리보기 약관과 지원 조건도 구매 직전 다시 확인해 보세요. 새 기능의 존재와 우리 서비스에 적합하다는 결론 사이에 어떤 근거가 필요한지 정리하는 것이 좋은 출발점입니다.

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.