이 페이지에서는 Cloud SQL의 재해 복구를 소개합니다.
개요
Google Cloud에서 데이터베이스 재해 복구(DR)는 특히 리전이 실패하거나 사용할 수 없게 될 때 처리의 연속성을 제공합니다. Cloud SQL은 리전 서비스입니다(Cloud SQL이 고가용성(HA)용으로 구성된 경우). 따라서 Cloud SQL 데이터베이스를 호스팅하는 Google Cloud 리전을 사용할 수 없으면 Cloud SQL 데이터베이스도 사용할 수 없게 됩니다.
처리를 계속하려면 최대한 빨리 보조 리전에서 데이터베이스를 사용할 수 있도록 해야 합니다. DR 계획을 사용하려면 Cloud SQL에서 리전 간 읽기 복제본을 구성해야 합니다. 내보내기/가져오기 또는 백업/복원에 기반한 장애 조치도 가능하지만 이 접근 방법은 특히 대규모 데이터베이스의 경우 시간이 더 오래 걸립니다.
다음 비즈니스 시나리오는 리전 간 장애 조치 구성을 적용하는 예시입니다.
- 비즈니스 애플리케이션의 서비스수준계약이 리전 Cloud SQL 서비스수준계약(Cloud SQL 버전에 따라 가용성 99.99%)보다 큽니다. 다른 리전으로 장애 조치를 수행하면 서비스 중단을 완화할 수 있습니다.
- 비즈니스 애플리케이션의 모든 등급은 이미 멀티 리전이며 리전 중단 발생 시 계속 처리를 진행할 수 있습니다. 리전 간 장애 조치 구성을 통해 데이터베이스를 계속 사용할 수 있습니다.
- 필수 복구 시간 목표(RTO)와 복구 지점 목표(RPO)는 시간 단위가 아니라 분 단위입니다. 다른 리전으로 장애 조치를 수행하는 것이 데이터베이스를 다시 만드는 것보다 더 빠릅니다.
일반적으로 DR 프로세스에는 두 가지가 있습니다.
- 데이터베이스가 보조 리전으로 장애 조치됩니다. 데이터베이스가 준비되고 애플리케이션에서 사용될 경우 이 데이터베이스는 새 기본 데이터베이스가 되고 기본 데이터베이스로 유지됩니다.
- 데이터베이스가 보조 리전으로 장애 조치되지만 기본 리전이 장애에서 복구된 후 기본 리전으로 대체됩니다.
이 Google Cloud SQL 데이터베이스 재해 복구 개요에서는 실패한 데이터베이스가 복구되고 기본 리전으로 되돌아가는 두 번째 변형을 설명합니다. 이 DR 프로세스 변형은 특히 네트워크 지연 시간으로 인해 또는 기본 리전에서만 일부 리소스를 사용할 수 있어 기본 리전에서 실행해야 하는 데이터베이스와 관련이 있습니다. 이 변형을 사용하면 데이터베이스는 기본 리전의 서비스 중단 기간 동안에만 보조 리전에서 실행됩니다.
재해 복구 아키텍처
다음 다이어그램은 HA Cloud SQL 인스턴스의 데이터베이스 DR을 지원하는 최소한의 아키텍처를 보여줍니다.
이 아키텍처는 다음과 같이 작동합니다.
- Cloud SQL의 두 인스턴스(기본 인스턴스 및 대기 인스턴스)는 단일 리전(기본 리전) 내의 두 영역에 있습니다. 인스턴스는 리전 영구 디스크를 사용하여 동기화됩니다.
- Cloud SQL의 인스턴스 중 하나(리전 간 읽기 복제본)는 두 번째 리전(보조 리전)에 있습니다. DR의 경우 비동기 복제를 사용하여 리전 간 읽기 복제본이 읽기 복제본 설정을 사용하는 기본 인스턴스와 동기화되도록 설정됩니다.
기본 인스턴스와 대기 인스턴스는 동일한 리전 디스크를 공유하므로 인스턴스의 상태가 동일합니다.
이 설정은 비동기 복제를 사용하기 때문에 리전 간 읽기 복제본이 기본 인스턴스보다 뒤쳐질 수 있습니다. 따라서 장애 조치가 발생하면 리전 간 읽기 복제본 RPO가 0이 아닐 가능성이 높습니다.
재해 복구(DR) 프로세스
재해 복구(DR) 프로세스는 기본 리전을 사용할 수 없게 되면 시작됩니다. 보조 리전에서 처리를 재개하려면 리전 간 읽기 복제본을 승격하여 기본 인스턴스의 장애 조치를 트리거합니다. DR 프로세스에는 리전 장애를 완화하고 보조 리전에서 실행되는 기본 인스턴스를 설정하기 위해 수동 또는 자동으로 수행해야 하는 작업 단계가 기술됩니다.
다음 다이어그램은 DR 프로세스를 보여줍니다.
이 DR 프로세스는 다음과 같은 단계로 구성됩니다.
- 기본 인스턴스를 실행하는 기본 리전(R1)은 사용할 수 없게 됩니다.
- 운영팀이 재해 상태를 인식하고, 공식적으로 재해를 인정하고, 장애 조치가 필요한지 여부를 결정합니다.
- 장애 조치가 필요한 경우 보조 리전(R2)의 리전 간 읽기 복제본을 새 기본 인스턴스로 승격하면 됩니다.
- 클라이언트 연결은 새로운 기본 인스턴스에서 처리를 재개하고 R2의 기본 인스턴스에 액세스할 수 있도록 재구성됩니다.
이 초기 프로세스는 작동하는 기본 데이터베이스를 다시 설정합니다. 하지만 새 기본 인스턴스 자체에 대기 인스턴스와 리전 간 읽기 복제본이 있는 완전한 DR 아키텍처는 설정하지 않습니다.
DR 프로세스를 완료하면 단일 인스턴스(새 기본 인스턴스)가 HA에 대해 사용 설정되고 리전 간 읽기 복제본을 포함하게 됩니다. 또한 DR 프로세스를 완료하면 원래 기본 리전의 원래 배포에 대한 대체를 제공합니다.
보조 리전으로 장애 조치
전체 DR 프로세스는 장애 조치 후 전체 DR 아키텍처를 설정하기 위한 단계를 추가하여 기본 DR 프로세스를 확장합니다. 다음 다이어그램은 장애 조치 후 전체 데이터베이스 DR 아키텍처를 보여줍니다.
전체 데이터베이스 DR 프로세스는 다음 단계로 구성됩니다.
- 기본 데이터베이스를 실행하는 기본 리전(R1)은 사용할 수 없게 됩니다.
- 운영팀이 재해 상태를 인식하고, 공식적으로 재해를 인정하고, 장애 조치가 필요한지 여부를 결정합니다.
- 장애 조치가 필요한 경우 보조 리전(R2)의 리전 간 읽기 복제본을 새 기본 인스턴스로 승격하면 됩니다.
- 클라이언트 연결은 새로운 기본 인스턴스(R2)에서 액세스하고 처리하도록 재구성됩니다.
- R2에서 새 대기 인스턴스가 생성되고 시작되어 기본 인스턴스에 추가됩니다. 대기 인스턴스는 기본 인스턴스와 다른 영역에 배치됩니다. 이제 기본 인스턴스를 위한 대기 인스턴스가 생성되었기 때문에 기본 인스턴스의 가용성이 높아집니다.
- 세 번째 리전(R3)에서는 새 리전 간 읽기 복제본이 생성되고 기본 인스턴스에 연결됩니다. 이 시점에서 전체 재해 복구 아키텍처가 다시 생성되고 작동됩니다.
6단계가 수행되기 전에 원래 기본 리전(R1)을 사용할 수 있게 되는 즉시, 리전 R3가 아닌 리전 R1에 리전 간 읽기 복제본을 배치할 수 있습니다. 이 경우에는 원래 기본 리전(R1)으로 대체하는 것이 쉽고 단계가 간단합니다.
분할 브레인 상태 방지
기본 리전(R1)에 장애가 발생하더라도 원래 기본 인스턴스와 대기 인스턴스가 자동으로 종료되거나, 삭제되거나, 혹은 R1이 다시 사용 가능해지면 액세스 불가 상태가 되는 것은 아닙니다. R1을 사용할 수 있게 되면 클라이언트는 원래 기본 인스턴스에서 우연히라도 데이터를 읽고 쓸 수 있습니다. 이 경우 분할 브레인 상황이 발생하여 일부 클라이언트가 이전 기본 데이터베이스의 비활성 데이터에 액세스하고 다른 클라이언트는 새 기본 데이터베이스의 최신 데이터에 액세스하여 비즈니스에 문제가 발생할 수 있습니다.
분할 브레인 상황을 방지하려면 R1을 사용할 수 있게 된 후에 클라이언트가 원래 기본 인스턴스에 액세스할 수 없도록 해야 합니다. 이상적으로는 클라이언트가 새 기본 인스턴스를 사용하기 전에 원래 기본 인스턴스에 액세스할 수 없게 만들고, 액세스할 수 없게 되는 즉시 원래 기본 인스턴스를 삭제하는 것이 좋습니다.
장애 조치 후 초기 백업 설정
장애 조치에서 리전 간 읽기 복제본을 새 기본 인스턴스로 승격하면 새 기본 인스턴스의 트랜잭션이 원래 기본 트랜잭션의 인스턴스와 완전히 동기화되지 않을 수 있습니다. 따라서 새 인스턴스에서 이러한 트랜잭션을 사용할 수 없습니다.
장애 조치 시작 시와 클라이언트가 데이터베이스에 액세스하기 전에 새 기본 인스턴스를 즉시 백업하는 것이 좋습니다. 이 백업은 장애 조치 시점에 알려진 일관적인 상태를 나타냅니다. 이러한 백업은 규제 목적으로 또는 클라이언트가 새 기본 인스턴스에 액세스할 때 문제가 발생하는 경우 알려진 상태로 복구하는 데 중요합니다.
원래 기본 리전으로 대체
앞에서 설명한 것처럼 이 문서에서는 원래 리전(R1)으로 대체하기 위한 단계를 제공합니다. 대체 프로세스에 두 가지 버전이 있습니다.
- 3차 리전(R3)에서 새 리전 간 읽기 복제본을 만든 경우, 기본 리전(R1)에서 다른(보조) 리전 간 읽기 복제본을 만들어야 합니다.
- 기본 리전(R1)에서 새로운 리전 간 읽기 복제본을 만든 경우 R1에 또 다른 리전 간 읽기 복제본을 만들 필요가 없습니다.
R1의 리전 간 읽기 복제본이 존재하는 경우 Cloud SQL 인스턴스가 R1로 대체될 수 있습니다. 대체 작업은 수동으로 트리거되고 서비스 중단을 기반으로 하지 않으므로 이 유지보수 활동에 적합한 날짜와 시간을 선택할 수 있습니다.
따라서 기본, 대기, 리전 간 읽기 복제본이 있는 완전한 DR을 실행하려면 두 개의 장애 조치가 필요합니다. 첫 번째 장애 조치는 서비스 중단(실제 장애 조치)에 의해 트리거되고 두 번째 장애 조치는 시작 배포(대체)를 재설정합니다.
원래 기본 리전(R1)으로의 대체는 다음 단계로 구성됩니다.
- 원래 기본 리전(R1)에서 새로 생성된 리전 간 복제본을 승격합니다.
- 새 기본 인스턴스에 연결하도록 애플리케이션을 다시 구성합니다.
- DR 리전(R2)에서 새 기본 인스턴스의 리전 간 복제본을 만듭니다.
- (선택사항) 여러 개의 독립적인 기본 인스턴스를 실행하지 않도록 하려면 DR 리전(R2)에서 기본 인스턴스를 삭제합니다.
연쇄 복제본
Cloud SQL을 사용하면 리전 간 재해 테스트 및 복구 시나리오에 사용할 복제본을 만들 수 있습니다. 기본 인스턴스와 다른 리전에서 cascadable-replica 플래그를 사용하여 복제본을 만들 수 있습니다. 기본 인스턴스의 리전에 재해가 발생하면 연쇄 가능한 복제본으로 장애 조치를 시작합니다.
원래 기본 인스턴스가 다시 온라인 상태가 되고 정상적인 복제본으로 작동하는 경우 전환 작업을 사용하여 원래 기본 인스턴스로 다시 전환할 수 있습니다.
연쇄 가능한 복제본에는 다른 읽기 복제본에는 없는 두 가지 추가 기능이 있습니다.
- 추가 읽기 복제본(연쇄 복제본)을 연쇄 읽기 복제본에 연결할 수 있습니다. Cloud SQL은 리전 간 복제 트래픽을 연쇄 가능한 복제본에 한 번만 전송한 후 연쇄 가능한 복제본이 트래픽을 리전 내 복제본으로 전달합니다. 이 아키텍처는 다른 리전에 여러 복제본이 있어야 하는 경우 리전 간 네트워크 데이터 전송 비용을 절약할 수 있습니다.
- 리전 간 재해 복구 시나리오에서 전환 및 장애 조치 작업의 대상으로 연쇄 읽기 복제본을 사용할 수 있습니다. 이러한 작업은 연쇄 가능한 복제본을 클러스터의 기본 인스턴스로 재구성합니다.
다음 두 가지 방법 중 하나로 재해 복구를 테스트할 수 있습니다.
- 복제본 승격
- 고급 재해 복구
고급 재해 복구(DR)
Cloud SQL Enterprise Plus 버전을 사용하는 경우 고급 DR을 활용할 수 있습니다. 고급 DR은 리전 간 장애 조치 후 복구 및 대체를 간소화합니다. 재해 복구 프로세스에 설명된 대로 DR을 수행할 때 이전 기본 인스턴스의 장애가 발생한 리전과 새 기본 인스턴스의 작동 리전 간의 연결을 삭제합니다. DR을 사용하여 원래 배포 리전에 대한 연결을 복원하고 이전 기본 인스턴스를 복구하려면 일련의 수동 대체 단계를 수행해야 합니다.
고급 DR을 사용하면 리전 장애가 발생할 때 복제본 장애 조치를 호출할 수 있습니다.
복제본 장애 조치를 사용하면 지정된 재해 복구(DR) 복제본을 승격한다는 점을 제외하면 일반 DR 수행과 유사한 리전 간 읽기 복제본을 승격합니다.
SQL 서버용 Cloud SQL의 경우 cascadable-replica 플래그를 사용하여 기본 인스턴스의 교차 리전 복제본을 만들어 DR 복제본을 만듭니다. DR 복제본 승격은 즉시 수행됩니다.
또한 새 기본 인스턴스를 만들거나 기존 기본 인스턴스에 DR 복제본을 지정하면 Cloud SQL에서 쓰기 엔드포인트를 만듭니다.
쓰기 엔드포인트는 기본 인스턴스의 IP 주소로 확인되는 DNS 이름입니다.
DR 복제본이 승격되면 쓰기 엔드포인트가 새로 승격된 기본 인스턴스를 가리키도록 업데이트됩니다. 이렇게 하면 쓰기 엔드포인트를 사용하여 연결하려는 모든 애플리케이션이 승격된 인스턴스로 리디렉션됩니다.
이전 기본 인스턴스를 삭제하는 대신 인스턴스는 Cloud SQL의 비동기 복제 토폴로지의 일부로 유지됩니다. DR 복제본이 새 기본 인스턴스로 승격되면 이전 기본 인스턴스(인스턴스 A)가 결국 DR 복제본(인스턴스 B)의 복제본이 됩니다.
이전 기본 인스턴스(A)가 복제본으로 전환된 다음 고급 DR의 마지막 단계를 수행할 수 있습니다. Cloud SQL 배포를 원래 상태로 되돌리고 이전 기본 인스턴스(A)를 데이터 손실 없이 기본 인스턴스로의 이전 역할로 복원할 수 있습니다. 이전 기본 인스턴스(A)에 대해 데이터 손실 없이 복원을 수행하려면 전환 작업을 사용하면 됩니다. 전환을 수행하면 지정된 DR 복제본(A)이 기본 인스턴스(B)를 따라잡을 때까지 기본 인스턴스(B)가 읽기 전용 모드로 유지되므로 데이터가 손실되지 않습니다. DR 복제본(A)이 모든 복제 업데이트를 수신하면 DR 복제본(A)이 기본 인스턴스의 역할을 하며 이전 기본 인스턴스(B)는 현재 기본 인스턴스(A)의 DR 복제본으로 자동으로 재구성됩니다. 인스턴스가 원래 역할로 돌아가므로 DR 및 복제본 장애 조치 이전의 원래 상태로 토폴로지가 돌아갑니다.
고급 DR이 진행되는 동안 복제본 장애 조치와 전환 작업에 관련된 모든 인스턴스는 IP 주소를 유지합니다.
고급 DR의 전환 작업을 사용하여 일상적인 DR 드릴을 실행할 수 있으며, 이를 통해 재해가 발생하기 전에 리전 간 장애 조치를 위한 Cloud SQL 토폴로지를 테스트하고 준비할 수도 있습니다. 실제 재해가 발생하면 이미 테스트한 리전 간 복제본 장애 조치를 수행하면 됩니다.
재해 복구(DR) 복제본
고급 DR의 필수 구성요소인 DR 복제본은 다음과 같은 특성을 갖습니다.
cascadable-replica 플래그로 만드는 연쇄 복제본이며 DR 복제본으로 작동하려면 연쇄 복제본이 기본 인스턴스와 별도의 리전에 있어야 합니다.또한 고급 DR을 사용한 후 RTO를 줄이려면 다음을 수행하는 것이 좋습니다.
- DR 복제본을 기본 인스턴스와 동일한 크기로 구성합니다.
- 기본 인스턴스에 HA가 사용 설정된 경우 DR 복제본에도 HA를 사용 설정하는 것이 좋습니다. 이렇게 하려면 먼저 기본 인스턴스에 HA가 사용 설정되어 있는지 확인합니다. 그런 다음 DR 복제본으로 전환을 수행합니다. 전환 작업이 완료되면 새 기본 인스턴스에서 HA를 사용 설정합니다. 그 다음 이전 기본 인스턴스로 다시 전환할 수 있습니다. DR 복제본은 다시 복제본이 된 후에도 HA 구성을 유지합니다.
복제본 장애 조치
복제본 장애 조치는 다음 단계로 구성됩니다.
- 복제본 장애 조치를 수행하기 전에 DR 복제본이 기본 인스턴스에 할당되어 있으며, 전환을 수행하여 프로세스를 테스트했을 수 있습니다.
- 기본 데이터베이스를 실행하는 기본 리전은 사용할 수 없게 됩니다.
- 운영팀이 재해 복구가 필요하다고 결정합니다.
- DR 복제본으로 복제본 장애 조치를 수행합니다.
- DR 복제본은 즉시 기본 인스턴스가 되어 들어오는 읽기 및 쓰기를 수락하기 시작합니다.
- 쓰기 엔드포인트가 업데이트되고 새 기본 인스턴스를 가리키기 시작합니다.
- 복제본이 승격된 후 Cloud SQL은 원래 기본 인스턴스가 다시 온라인 상태인지 주기적으로 확인합니다. 원래 기본 인스턴스가 온라인이면 Cloud SQL은 이전 기본 인스턴스를 승격된 인스턴스의 복제본으로 다시 구성합니다. 이전 기본 인스턴스는 IP 주소를 유지합니다.
- 이전 기본 인스턴스가 24시간 동안 가동되지 않으면 Cloud SQL은 새 기본 인스턴스 및 기타 복제본의 트랜잭션 로그가 무한대로 늘어나지 않도록 하기 위해 복제 토폴로지에서 해당 인스턴스를 삭제합니다.
복제본 장애 조치를 수행한 후 전환 작업을 수행하고 동일한 DR 복제본 및 기본 인스턴스 쌍을 반대로 바꿔 원래 리전에서 기본 인스턴스를 복원할 수 있습니다.
전환
전환은 다음 단계로 구성됩니다.
- 전환 작업을 시작하기 전에 기본 인스턴스에 DR 복제본을 할당해야 합니다.
- 기본 인스턴스가 정상인지 확인합니다. 기본 인스턴스와 DR 복제본이 모두 온라인 상태일 때만 전환을 수행할 수 있습니다.
- 전환을 시작합니다. 전환을 시작하면 DR 복제본에 대한 복제가 동기 모드로 전환됩니다.
- DR 복제본이 기본 인스턴스를 따라잡고 상태를 동기화됨으로 변경합니다.
- DR 복제본이 기본 인스턴스를 따라잡고 상태를 동기화됨으로 변경합니다.
- 복제 지연 시간이 0으로 떨어지면 DR 복제본이 새 기본 인스턴스로 승격됩니다. 새 기본 인스턴스가 애플리케이션 읽기 및 쓰기를 비롯한 수신 연결을 수락하기 시작합니다.
- 이전 기본 인스턴스는 읽기 복제본으로 재구성됩니다.
- 쓰기 엔드포인트가 업데이트되고 새 기본 인스턴스를 가리키기 시작합니다.
- 새 기본 인스턴스에 PITR이 자동으로 사용 설정됩니다. PITR은 첫 번째 자동 백업 후에만 가능합니다.
쓰기 엔드포인트
쓰기 엔드포인트는 기본 인스턴스의 IP 주소로 확인되는 DNS(도메인 이름 서비스) 이름입니다. 이 엔드포인트는 복제본 장애 조치 또는 전환 작업 시 들어오는 연결을 기본 인스턴스로 자동으로 리디렉션합니다. IP 주소 대신 SQL 연결 문자열에서 쓰기 엔드포인트를 사용할 수 있습니다. 쓰기 엔드포인트를 사용하면 리전의 서비스 중단이 발생할 때 애플리케이션 연결을 변경하지 않아도 됩니다.
쓰기 엔드포인트를 사용하려면 Cloud SQL Enterprise Plus 버전 기본 인스턴스를 만들거나 기존에 보유한 프로젝트에서 Cloud DNS API가 사용 설정되어 있어야 합니다.
비공개 IP 주소와 승인된 네트워크로 Cloud SQL Enterprise Plus 버전 인스턴스를 만들면 Cloud SQL에서 인스턴스의 쓰기 엔드포인트를 자동으로 생성합니다. Cloud SQL Enterprise Plus 버전 기본 인스턴스가 이미 있는 경우 DR 복제본(cascadable-replica 플래그로 만드는 리전 간 복제본)을 만들 때 Cloud SQL에서 쓰기 엔드포인트를 생성합니다.
전환 또는 복제본 장애 조치 작업으로 인해 기본 인스턴스가 변경된 경우 DR 복제본이 새 기본 인스턴스가 되면 Cloud SQL에서 DR 복제본에 쓰기 엔드포인트를 할당합니다.
인스턴스의 쓰기 엔드포인트를 가져오는 방법에 대한 자세한 내용은 인스턴스 정보 보기를 참조하세요. 쓰기 엔드포인트를 사용하여 인스턴스에 연결하는 방법에 관한 자세한 내용은 쓰기 엔드포인트를 사용하여 연결을 참조하세요.
다음 단계
- 고급 재해 복구(DR) 사용
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기