이 페이지에서는 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)에서 새로 생성된 리전 간 복제본을 승격합니다.
- 승격된 인스턴스가 원래 HA 복제본으로 생성되지 않은 경우 영역 장애로부터 보호하기 위해 인스턴스에 HA를 사용 설정합니다.
- 새 기본 인스턴스에 연결하도록 애플리케이션을 다시 구성합니다.
- DR 리전(R2)에서 새 기본 인스턴스의 리전 간 복제본을 만듭니다.
- (선택사항) 여러 개의 독립적인 기본 인스턴스를 실행하지 않도록 하려면 DR 리전(R2)에서 기본 인스턴스를 삭제합니다.