[운영관점 Spanner 시리즈] 데이터베이스 백업 및 복구 방법 알아보기

Cloud Spanner는 리전 구성을 통해 존(Zone) 간에 투명한 동기식 복제를 제공하며 멀티 리전 구성을 사용하면 리전 간 동기식 복제도 가능합니다. 이 아키텍처는 본질적으로 자연 재해 및 개별 머신 장애 등 기존 재해 복구 솔루션이 해결해야 하는 이슈의 몇 가지 원인을 방지합니다.

Cloud Spanner에서 제공하는 고가용성에도 불구하고 애플리케이션 소유자에게는 여전히 데이터 보호가 필요합니다. 사용자 오류나 애플리케이션 버그로 인해 데이터베이스에 잘못된 값이 저장될 가능성을 결코 배제할 수 없기 때문입니다. 이러한 니즈를 해소하기 위해 Cloud Spanner는 백업/복원 및 PITR(point-in-time recovery)을 제공합니다.

Cloud Spanner 백업은 트랜잭션 일관성이 있습니다. 백업이 생성되면 백업에서 백업 타임스탬프(마이크로초 단위의 트랜잭션 커밋 타임스탬프) 기준의 정확한 데이터베이스 콘텐츠를 캡처합니다. Cloud Spanner에서는 백업 타임스탬프를 포함해 그때까지 커밋된 트랜잭션과 관련된 모든 데이터를 백업에 포함시키고 커밋되지 않은 트랜잭션과 관련된 모든 부분 업데이트는 제외합니다. PITR을 사용하면 백업 타임스탬프와  동일한 의미의 사용자가 선택한 복원 타임스탬프부터 복구할 수 있습니다. 복원 타임스탬프를 포함해 그때까지 커밋된 모든 트랜잭션이 복원된 데이터베이스에 존재하며 다른 항목은 포함되지 않습니다.

대부분의 시스템에서 대규모 데이터베이스를 백업하는 데 많은 시간이 걸리며 데이터베이스의 CPU 부하가 증가할 수 있습니다. Cloud Spanner에서는 CPU에 최적화된 백업으로 이 문제를 해결했습니다. 이 기능을 통해 Cloud Spanner는 고객 데이터베이스 인스턴스에 사용되는 CPU 리소스와 백업 생성에 사용되는 CPU 리소스를 분리했습니다. 이 기능은 Cloud Spanner의 모든 백업에 지원됩니다.

Cloud Spanner는 데이터베이스 데이터를 읽고 백업본을 쓰는 배치 작업을 시작하여 데이터베이스 백업을 생성합니다. 모든 읽기-쓰기 및 모든 읽기 전용 존 등 데이터베이스의 전체 사본이 있는 각 GCP 존에서 이러한 작업이 이루어집니다. 각 존의 백업본은 독립적으로 쓰이며 해당 존 내에만 유지됩니다. 따라서 존 간 네트워크 트래픽 없이 고가용성 백업 및 빠른 복원이 가능합니다.

Spanner에서는 컴퓨팅과 스토리지가 항상 분리되어 왔습니다. 하지만 CPU에 최적화된 백업이 등장하기 전에는 각각의 백업 작업이 고객 인스턴스의 Cloud Spanner 서버에 데이터를 요청하여 수행 되었습니다. 서버의 로직이 백업에 포함할 올바른 데이터를 결정하는 데 중요한 역할을 했습니다. 다음의 다이어그램은 CPU에 최적화된 백업이 사용되지 않았을 때의 데이터 흐름을 보여줍니다.

CPU에 최적화된 백업에서는 이전의 서버측 로직을 백업 작업자 배치 작업의 일부로 실행합니다. 덕분에 백업에서 캡처해야 할 데이터와 제외해야 할 데이터를 구분하는 세부적인 처리를 수행할 수 있습니다. 여기서 고객 인스턴스 서버의 작업은 필요 없으며 백업 작업자 배치 작업에서 이 작업을 전부 처리해줍니다.

이는 고객에게 몇 가지 중요한 이점을 제공합니다.

• 고객은 더 이상 백업에 사용할 수 있는 CPU 여유 공간을 확보하기 위해 노드 또는 처리 단위로 측정된 추가 컴퓨팅 용량을 프로비저닝할 필요가 없습니다.
• 백업으로 인한 고객 인스턴스의 CPU 부하가 거의 사라집니다. 다시 말해 백업이 실행되는 동안 프로덕션 워크로드에 미치는 성능상의 영향이 없습니다.
• 백업을 만드는 배치 작업을 고객 인스턴스의 서버 수와 상관없이 확장할 수 있습니다. 기본 파일 시스템은 분산 수준이 높으며 본질적으로 읽기 대역폭을 무제한으로 허용합니다. 실제로는 배치 작업의 클라이언트 작업자 수에 따라 제한됩니다. CPU에 최적화된 백업에서는 백업 작업의 크기를 고객 인스턴스의 크기에서 분리하고 대규모 데이터베이스의 백업을 매우 큰 크기(대략 수천 개의 머신)로 확장할 수 있습니다. 

백업 성능은 스키마 세부정보와 같은 몇 가지 데이터베이스별 요인 등 다양한 요인에 따라 달라집니다. 따라서 구체적인 성능 예측이 제공되지 않습니다. 다만, 수십에서 수백 테라바이트 단위의 데이터베이스를 포함한 대부분의 데이터베이스 백업이 보통 1~2시간 내에 완료되는 것으로 확인되었습니다.

PITR(point-in-time-recovery)

Spanner는 백업 또는 내보내기가 실행된 마지막 상태로 데이터베이스를 복구하는 백업 및 복원과 가져오기/내보내기 기능을 이미 제공하고 있습니다. 이제는 PITR 기능을 통해 마이크로초 단위로 이전 데이터를 복구하는 기능과 더불어 지속적인 데이터 보호 기능을 제공할 수 있습니다. 이 기능을 통해 기업은 데이터 손상을 빠르게 해결하여 비즈니스의 위험과 손실을 경감하고 고객 경험에 미치는 영향을 최소화할 수 있습니다.

PITR은 사용하기에 간편하고 유연하며 더 세부적으로 제어 가능한 데이터 보호 기능을 제공합니다. 데이터와 스키마의 모든 버전을 최소 1시간에서 최대 7일까지 보관하도록 데이터베이스의 버전 보관 기간을 설정하기만 하면 Spanner가 나머지 작업을 알아서 처리해줍니다. 논리적인 데이터 손상이 발생한 경우에는 상황에 따라 데이터베이스를 완전히 복구하거나 데이터베이스의 특정 부분만 복구(전체 데이터베이스를 복구할 필요가 없는 경우)하도록 선택하여 소중한 시간과 리소스를 절약할 수 있습니다.

PITR 설정 및 전체 데이터베이스 복구

버전 보관 기간은 데이터베이스 수준에서 설정 가능하므로 새로운 보관 기간을 설정하기 위해서는 먼저 원하는 데이터베이스 세부정보 페이지로 이동해야 합니다. 기본적으로는 데이터베이스가 생성될 때마다 1시간으로 설정됩니다. PITR 기능 덕분에 이제 이 기간을 분, 시간, 일 단위로 최대 7일까지 설정할 수 있습니다.

아래의 그림은 UI 콘솔에서 데이터베이스의 보관 기간을 설정하는 방법을 보여줍니다.

인스턴스에서 각 데이터베이스의 보관 기간을 설정할 수 있습니다. 이제 UI에서 과거의 특정 시점(버전 시간)에 백업을 만들고 해당 백업에서 복원하는 방법을 살펴보겠습니다. 아래 그림은 UI에서 백업 생성 방법을 보여줍니다.

UI에서 데이터베이스의 백업을 나열해 보면 버전 시간이 백업 생성 시간과 다른 것을 볼 수 있는데, 이를 통해 해당 백업 데이터가 과거 특정 시점 데이터베이스 버전의 데이터임을 알 수 있습니다.

이제 데이터베이스를 복원하여 동일한 인스턴스 내에서 혹은 Spanner를 사용 중인 동일한 리전 또는 멀티 리전의 다른 인스턴스에서 전체 데이터베이스를 복구할 수 있습니다.

복원된 데이터베이스의 버전 보관 기간은 기본값인 1시간이 아니라 백업 생성 시점의 원본 데이터베이스와 동일하게 설정된다는 점에 유의하세요.

PITR의 최대 데이터 보관 기간인 7일이 충분하지 않은 경우 Spanner는 백업(최대 1년의 보관 기간)과 내보내기 기능을 통해 보관 기간이 더 긴 데이터 보호 옵션을 계속하여 제공하고 있습니다. 내보내기 기능의 경우 데이터를 CSV 혹은 Avro 파일 형식으로 내보내 원하는 기간만큼 데이터를 보관할 수 있습니다.

자세히 알아보기

PITR은 이제 Google이 관리하는 전 세계 모든 리전에서 사용할 수 있습니다. 버전 보관 기간 동안 키의 모든 버전을 저장하는 데 사용된 추가 스토리지에 대한 요금이 부과됩니다. 데이터를 복구에 백업/복원 혹은 가져오기/내보내기 기능을 사용하도록 선택하면 선택한 기능의 가격에 따라 요금이 부과됩니다.

PITR에 대해서 자세히 알아보려면 문서를 참조하세요.

PITR을 사용해 삭제된 테이블을 복원하는 방법은 이 블로그를 참조하세요.

Spanner를 시작하려면 인스턴스를 생성하거나 Spanner Qwiklab에서 사용해 보세요.

다음 게시물 예고

지금까지 Cloud Spanner의 백업 복구에 대해 알아봤습니다. 다음 게시물에서는 Cloud Spanner의 인스턴스 확장에 대해 알아보겠습니다.