데이터의 재해 복구 시나리오

Last reviewed 2024-08-05 UTC

이 문서는 Google Cloud의 재해 복구(DR)를 설명하는 시리즈 중 3부입니다. 여기에서는 데이터 백업 및 복구 시나리오를 설명합니다.

시리즈는 다음 세 부분으로 구성됩니다.

소개

재해 복구 계획은 재해 발생 시 데이터 손실을 피할 수 있는 방법을 지정해야 합니다. 여기서 데이터라는 용어는 두 가지 시나리오를 다룹니다. 데이터베이스, 로그 데이터, 기타 데이터 유형을 백업한 다음 복구하는 것은 다음 시나리오 중 하나에 해당됩니다.

  • 데이터 백업. 데이터만 백업하는 것은 일정한 양의 데이터를 한 위치에서 다른 위치로 복사하는 것을 말합니다. 백업은 프로덕션 환경에서 알려진 정상 상태로 직접 복원하거나 프로덕션 환경이 다운된 경우 DR 환경에서 데이터를 복원할 수 있도록 데이터 손상 복구 계획의 일환으로 진행됩니다. 일반적으로 데이터 백업에는 중소 규모의 RTO와 작은 RPO가 있습니다.
  • 데이터베이스 백업. 데이터베이스 백업은 일반적으로 특정 시점으로 복구해야 하기 때문에 약간 더 복잡합니다. 따라서 데이터베이스 백업을 백업 및 복원하는 방법을 고려하고, 복구 데이터베이스 시스템이 프로덕션 구성을 미러링하는지(동일한 버전, 미러링된 디스크 구성) 확인하는 것 외에 트랜잭션 로그를 백업하는 방법도 고려해야 합니다. 복구할 때는 데이터베이스 기능을 복원한 후 최신 데이터베이스 백업을 적용한 다음 마지막 백업 후 백업된 트랜잭션 로그의 복구된 버전을 적용해야 합니다. 데이터베이스 시스템에 고유한 복잡한 요소(예: 프로덕션 시스템과 복구 시스템 간 버전을 일치시켜야 함)로 인해 데이터베이스 서버를 사용할 수 없는 상황에서 복구하는 시간을 최소화하는 고가용성 우선 접근법을 채택하면 더 작은 RTO 및 RPO 값을 얻을 수 있습니다.

Google Cloud에서 프로덕션 워크로드를 실행할 때 전역으로 분산된 시스템을 사용하여 한 리전에서 문제가 발생할 경우, 애플리케이션의 가용성이 저하되더라도 계속 서비스를 제공할 수 있습니다. 기본적으로 이 애플리케이션은 DR 계획을 실행합니다.

이 문서의 나머지 부분에서는 RTO 및 RPO 목표 달성에 도움이 되는 데이터 및 데이터베이스 시나리오를 설계하는 방법의 예시를 설명합니다.

프로덕션 환경이 온프레미스일 경우

이 시나리오에서 프로덕션 환경은 온프레미스이며 재해 복구 계획에서는 Google Cloud를 복구 사이트로 사용합니다.

데이터 백업 및 복구

여러 가지 전략을 사용하여 온프레미스의 데이터를 Google Cloud에 정기적으로 백업하는 프로세스를 구현할 수 있습니다. 이 섹션에서는 가장 일반적인 두 가지 솔루션을 살펴봅니다.

솔루션 1: 예약 작업을 사용하여 Cloud Storage에 백업

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Cloud Storage

데이터를 백업하는 한 가지 옵션은 Cloud Storage로 데이터를 전송하는 스크립트 또는 애플리케이션을 실행하는 예약 작업을 만드는 것입니다. gcloud storage Google Cloud CLI 명령어를 사용하거나 Cloud Storage 클라이언트 라이브러리 중 하나를 사용하여 Cloud Storage에 대한 백업 프로세스를 자동화할 수 있습니다. 예를 들어 다음 gcloud storage 명령어는 원본 디렉터리의 모든 파일을 지정된 버킷으로 복사합니다.

gcloud storage cp -r SOURCE_DIRECTORY gs://BUCKET_NAME

SOURCE_DIRECTORY을 소스 디렉터리의 경로로 바꾸고 BUCKET_NAME을 원하는 버킷 이름으로 바꿉니다. 이름은 버킷 이름 요구사항을 충족해야 합니다.

다음 단계에서는 gcloud storage 명령어를 사용하여 백업 및 복구 프로세스를 구현하는 방법을 간략히 설명합니다.

  1. 데이터 파일을 업로드하는 데 사용할 온프레미스 머신에 gcloud CLI을 설치합니다.
  2. 데이터 백업 대상으로 버킷을 만듭니다.
  3. 서비스 계정을 만듭니다.
  4. IAM 정책을 만들어 버킷과 버킷의 객체에 액세스할 수 있는 사람을 제한합니다. 이 목적으로 특수하게 만든 서비스 계정을 포함합니다. Cloud Storage에 액세스할 수 있는 권한에 대한 자세한 내용은 gcloud storage에 대한 IAM 권한을 참고하세요.
  5. 서비스 계정 가장을 사용하여 로컬 Google Cloud 사용자 (또는 서비스 계정)가 방금 만든 서비스 계정을 가장할 수 있는 액세스 권한을 부여합니다. 또는 이 목적으로만 사용할 새 사용자를 만들 수 있습니다.
  6. 타겟 버킷에서 파일을 업로드 및 다운로드할 수 있는지 테스트합니다.
  7. Linux crontab 및 Windows 작업 스케줄러와 같은 도구를 사용하여 백업을 업로드하는 데 사용하는 스크립트의 일정을 설정합니다.
  8. gcloud storage 명령어를 사용하여 Google Cloud의 복구 DR 환경으로 데이터를 복구하는 복구 프로세스를 구성합니다.

gcloud storage rsync 명령어를 사용하여 데이터와 Cloud Storage 버킷 간에 실시간 증분 동기화를 수행할 수도 있습니다.

예를 들어 다음 gcloud storage rsync 명령어는 누락된 파일 또는 객체를 복사하거나 데이터가 변경된 항목을 복사하여 Cloud Storage 버킷의 콘텐츠를 소스 디렉터리의 콘텐츠와 동일하게 만듭니다. 연속된 백업 세션 간에 변경된 데이터 볼륨이 소스 데이터의 전체 볼륨에 비해 작은 경우 gcloud storage rsync를 사용하는 것이 gcloud storage cp 명령어를 사용하는 것보다 더 효율적일 수 있습니다. gcloud storage rsync를 사용하면 더 자주 백업 일정을 구현하고 RPO를 낮출 수 있습니다.

gcloud storage rsync -r SOURCE_DIRECTORY gs:// BUCKET_NAME

자세한 내용은 소량의 온프레미스 데이터 전송을 위한 gcloud storage 명령어를 참고하세요.

솔루션 2: Transfer Service for On Premises Data를 사용하여 Cloud Storage에 백업

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Cloud Storage
  • Transfer Service for On Premises Data

네트워크 전체에 대용량의 데이터를 전송하려면 신중한 계획과 강력한 실행 전략이 필요합니다. 확장 가능하고 안정적이며 유지관리할 수 있는 커스텀 스크립트를 개발하는 것은 간단한 작업이 아닙니다. 커스텀 스크립트를 사용하면 RPO 값이 낮아지고 데이터 손실 위험이 커질 수 있습니다.

온프레미스 위치에서 Cloud Storage로 대용량 데이터를 이동하는 방법에 관한 안내는 온프레미스 스토리지의 데이터 이동 또는 백업을 참고하세요.

솔루션 3: 파트너 게이트웨이 솔루션을 사용하여 Cloud Storage에 백업

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Cloud Interconnect
  • Cloud Storage 단계식 저장소

온프레미스 애플리케이션은 데이터 백업 및 복구 전략의 일부로 사용할 수 있는 타사 솔루션과 통합되는 경우가 많습니다. 이러한 솔루션은 가장 최근의 백업이 더 빠른 저장소에 있고, 이전 백업을 더 저렴한 저속 저장소로 천천히 이전하는 단계식 저장소 패턴을 사용하는 경우가 많습니다. Google Cloud를 대상으로 사용할 경우 여러 스토리지 클래스 옵션을 통해 저속 등급으로 사용할 수 있습니다.

이 패턴을 구현하는 한 가지 방법은 온프레미스 스토리지와 Google Cloud 간의 파트너 게이트웨이를 사용하여 데이터가 Cloud Storage로 용이하게 전송되도록 하는 것입니다. 다음 다이어그램은 온프레미스 NAS 어플라이언스 또는 SAN으로부터의 전송을 관리하는 파트너 솔루션을 사용하는 이러한 배치를 보여줍니다.

전용 상호 연결을 사용하여 Google Cloud에 연결된 온프레미스 데이터 센터를 보여주는 아키텍처 다이어그램

장애가 발생할 경우 백업되는 데이터를 DR 환경으로 복구해야 합니다. DR 환경은 프로덕션 환경으로 되돌릴 수 있을 때까지 프로덕션 트래픽을 제공하는 데 사용됩니다. 이를 달성하는 방법은 애플리케이션과 파트너 솔루션 및 아키텍처에 따라 다릅니다. (일부 엔드 투 엔드 시나리오는 DR 애플리케이션 문서에서 설명합니다.)

관리 Google Cloud 데이터베이스를 DR 대상 유형으로 사용할 수도 있습니다. 예를 들어 SQL Server용 Cloud SQL은 트랜잭션 로그 가져오기를 지원합니다. 온프레미스 SQL Server 인스턴스에서 트랜잭션 로그를 내보내 Cloud Storage에 업로드한 후 SQL Server용 Cloud SQL로 가져올 수 있습니다.

온프레미스에서 Google Cloud로 데이터를 전송하는 방법에 대한 자세한 지침은 빅데이터 세트를 Google Cloud로 전송을 참조하세요.

파트너 솔루션에 대한 자세한 내용은 Google Cloud 웹사이트의 파트너 페이지를 참조하세요.

데이터베이스 백업 및 복구

여러 가지 전략을 사용하여 온프레미스의 데이터베이스 시스템을 Google Cloud로 복구하는 프로세스를 구현할 수 있습니다. 이 섹션에서는 가장 일반적인 두 가지 솔루션을 살펴봅니다.

이 문서에서는 서드 파티 데이터베이스에 포함된 다양한 기본 제공 백업 및 복구 메커니즘을 자세하게 설명하지 않습니다. 이 섹션에서는 여기서 설명하는 솔루션에 구현된 일반적인 지침을 제공합니다.

솔루션 1: Google Cloud에서 복구 서버를 사용하여 백업 및 복구

  1. 데이터베이스 관리 시스템의 내장 백업 메커니즘을 사용하여 데이터베이스 백업을 만듭니다.
  2. 온프레미스 네트워크와 Google Cloud 네트워크를 연결합니다.
  3. 데이터 백업의 대상으로 Cloud Storage 버킷을 만듭니다.
  4. gcloud storagegcloud CLI 또는 파트너 게이트웨이 솔루션을 사용하여 백업 파일을 Cloud Storage에 복사합니다 (앞서 데이터 백업 및 복구 섹션에서 논의한 단계 참조). 자세한 내용은 Google Cloud로 마이그레이션: 대규모 데이터 세트 전송을 참고하세요.
  5. 트랜잭션 로그를 Google Cloud의 복구 사이트에 복사합니다. 트랜잭션 로그를 백업하면 RPO 값을 작게 유지하는 데 도움이 됩니다.

이 백업 토폴로지를 구성한 후에는 Google Cloud에 있는 시스템으로 복구할 수 있는지 확인해야 합니다. 이 단계는 일반적으로 백업 파일을 대상 데이터베이스로 복원할 뿐 아니라 트랜잭션 로그를 재생해 가장 작은 RTO 값에 도달합니다. 일반적인 복구 시퀀스는 다음과 같습니다.

  1. Google Cloud에서 데이터베이스 서버의 커스텀 이미지를 만듭니다. 데이터베이스 서버 이미지에는 온프레미스 데이터베이스 서버와 동일한 구성이 있어야 합니다.
  2. 온프레미스 백업 파일 및 트랜잭션 로그 파일을 Cloud Storage에 복사하는 프로세스를 구현합니다. 구현 예시는 솔루션 1을 참조하세요.
  3. 커스텀 이미지에서 최소 크기가 지정된 인스턴스를 시작하고 필요한 영구 디스크를 연결합니다.
  4. 영구 디스크의 자동 삭제 플래그를 false로 설정합니다.
  5. 백업 파일 복구를 위한 데이터베이스 시스템의 지침에 따라 이전에 Cloud Storage에 복사된 최신 백업 파일을 적용합니다.
  6. Cloud Storage에 복사된 최신 트랜잭션 로그 파일 세트를 적용합니다.
  7. 프로덕션 트래픽을 수용할 수 있는 더 큰 인스턴스로 최소 인스턴스를 바꿉니다.
  8. Google Cloud에서 복구된 데이터베이스를 가리키도록 클라이언트를 전환합니다.

프로덕션 환경이 실행 중이고 프로덕션 워크로드를 지원할 수 있으면 Google Cloud 복구 환경으로 장애 조치를 하기 위해 따른 단계를 반대로 수행해야 합니다. 프로덕션 환경으로 돌아가기 위한 일반적인 순서는 다음과 같습니다.

  1. Google Cloud에서 실행 중인 데이터베이스를 백업합니다.
  2. 프로덕션 환경에 백업 파일을 복사합니다.
  3. 프로덕션 데이터베이스 시스템에 백업 파일을 적용합니다.
  4. 데이터베이스 시스템 서비스를 중지하는 등, Google Cloud에서 클라이언트가 데이터베이스 시스템에 연결하는 것을 방지합니다. 이 시점부터 프로덕션 환경 복원을 마칠 때까지는 애플리케이션을 사용할 수 없습니다.
  5. 프로덕션 환경에 트랜잭션 로그 파일을 복사하고 적용합니다.
  6. 클라이언트 연결을 프로덕션 환경으로 리디렉션합니다.

솔루션 2: Google Cloud의 대기 서버에 복제

매우 작은 RTO 및 RPO 값을 얻는 한 가지 방법은 데이터를 단순히 백업하는 것이 아니라 복제하고 경우에 따라 데이터베이스 상태를 실시간으로 데이터베이스 서버의 복제본으로 복제하는 것입니다.

  1. 온프레미스 네트워크와 Google Cloud 네트워크를 연결합니다.
  2. Google Cloud에서 데이터베이스 서버의 커스텀 이미지를 만듭니다. 데이터베이스 서버 이미지에는 온프레미스 데이터베이스 서버와 동일한 구성이 있어야 합니다.
  3. 커스텀 이미지에서 인스턴스를 시작하고 필요한 영구 디스크를 연결합니다.
  4. 영구 디스크의 자동 삭제 플래그를 false로 설정합니다.
  5. 데이터베이스 소프트웨어에 대한 안내에 따라 온프레미스 데이터베이스 서버와 Google Cloud에 있는 대상 데이터베이스 서버 간에 복제를 구성합니다.
  6. 클라이언트는 정상 작동 상태에서 온프레미스의 데이터베이스 서버를 가리키도록 구성됩니다.

이 복제 토폴로지를 구성한 후 클라이언트가 Google Cloud 네트워크에서 실행 중인 대기 서버를 가리키도록 전환하세요.

프로덕션 환경을 백업하고 프로덕션 워크로드를 지원할 수 있게 되면 프로덕션 데이터베이스 서버를 Google Cloud 데이터베이스 서버와 다시 동기화한 다음 프로덕션 환경을 다시 가리키도록 클라이언트를 전환해야 합니다.

프로덕션 환경이 Google Cloud일 경우

이 시나리오에서는 프로덕션 환경과 재해 복구 환경이 모두 Google Cloud에서 실행됩니다.

데이터 백업 및 복구

데이터 백업의 일반적인 패턴은 계층형 스토리지 패턴을 사용하는 것입니다. 프로덕션 워크로드가 Google Cloud에 있을 때 계층형 스토리지 시스템은 다음 다이어그램과 같습니다. 백업된 데이터에 대한 액세스 요구는 거의 없기 때문에 스토리지 비용이 낮은 등급으로 데이터를 마이그레이션합니다.

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

데이터가 영구 디스크에서 Nearline, Coldline으로 마이그레이션됨에 따라 감소하는 비용을 나타내는 이미지를 보여주는 개념 다이어그램

Nearline, Coldline, Archive 스토리지 클래스는 자주 액세스하지 않는 데이터를 저장하기 위한 것이므로 이러한 클래스에 저장된 데이터나 메타데이터를 가져올 경우 추가 비용이 발생하며 최소 저장 기간에 대한 요금이 청구됩니다.

데이터베이스 백업 및 복구

자체 관리형 데이터베이스를 사용하는 경우(예: Compute Engine의 인스턴스에 MySQL, PostgreSQL 또는 SQL Server를 설치한 경우), 온프레미스의 프로덕션 데이터베이스를 관리할 때와 동일한 운영상의 문제가 적용되지만 더 이상 기본 인프라를 관리할 필요가 없습니다.

백업 및 DR 서비스는 클라우드 및 하이브리드 워크로드를 백업하고 복구하기 위한 중앙 집중식 클라우드 네이티브 솔루션입니다. 빠른 데이터 복구를 제공하고 중요한 비즈니스 운영을 신속하게 재개할 수 있도록 지원합니다.

Google Cloud의 자체 관리형 데이터베이스 시나리오에 백업 및 DR을 사용하는 방법에 관한 자세한 내용은 다음을 참고하세요.

또는 적절한 DR 구성 요소 기능을 사용하여 HA 구성을 설정하여 RTO를 작게 유지할 수 있습니다. 재해 발생 전의 상태와 최대한 비슷한 상태로 쉽게 복구할 수 있도록 데이터베이스 구성을 설계할 수 있습니다. 이렇게 하면 RPO 값을 작게 유지하는 데 도움이 됩니다. Google Cloud는 이 시나리오에 다양한 옵션을 제공합니다.

이 섹션에서는 Google Cloud의 자체 관리형 데이터베이스를 위한 데이터베이스 복구 아키텍처를 설계하는 두 가지 일반적인 방법을 설명합니다.

상태를 동기화하지 않고 데이터베이스 서버 복구

일반적인 패턴은 시스템 상태를 최신 대기 모드 복제본과 동기화할 필요가 없는 데이터베이스 서버 복구를 사용 설정하는 것입니다.

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Compute Engine
  • 관리형 인스턴스 그룹
  • Cloud Load Balancing(내부 부하 분산)

다음 다이어그램은 이 시나리오를 처리하는 아키텍처의 예를 보여줍니다. 이 아키텍처를 구현하면 수동으로 복구할 필요 없이 자동으로 장애에 대응하는 DR 계획을 수립할 수 있습니다.

한 영역의 영구 디스크에서 가져온 영구 디스크 이미지를 보여주는 아키텍처 다이어그램

다음 단계는 이 시나리오를 구성하는 방법에 대한 간략한 개요입니다.

  1. VPC 네트워크를 만듭니다.

  2. 다음을 수행하여 데이터베이스 서버로 구성된 커스텀 이미지를 만듭니다.

    1. 데이터베이스 파일과 로그 파일이 연결된 표준 영구 디스크에 기록되도록 서버를 구성합니다.
    2. 연결형 영구 디스크에서 스냅샷을 만듭니다.
    3. 스냅샷으로 영구 디스크를 만들고 디스크를 마운트하도록 시작 스크립트를 구성합니다.
    4. 부팅 디스크의 커스텀 이미지를 만듭니다.

  3. 이미지를 사용하는 인스턴스 템플릿을 만듭니다.

  4. 인스턴스 템플릿을 사용하여 대상 크기가 1인 관리형 인스턴스 그룹을 구성합니다.

  5. Cloud Monitoring 측정항목을 사용하여 상태 확인을 구성합니다.

  6. 관리형 인스턴스 그룹을 사용하여 내부 부하 분산을 구성합니다.

  7. 예약 작업을 구성하여 영구 디스크의 정기 스냅샷을 만듭니다.

대체 데이터베이스 인스턴스가 필요한 경우 이 구성은 자동으로 다음을 수행합니다.

  • 동일한 영역에서 올바른 버전의 다른 데이터베이스 서버를 가져옵니다.
  • 최신 백업 및 트랜잭션 로그 파일이 있는 영구 디스크를 새로 생성된 데이터베이스 서버 인스턴스에 연결합니다.
  • 이벤트에 응답하여 데이터베이스 서버와 통신하는 클라이언트를 재구성할 필요성을 최소화합니다.
  • 프로덕션 데이터베이스 서버에 적용되는 Google Cloud 보안 컨트롤(IAM 정책, 방화벽 설정)이 복구된 데이터베이스 서버에 적용되는지 확인합니다.

대체 인스턴스는 인스턴스 템플릿에서 만들어지기 때문에 원본에 적용된 컨트롤이 대체 인스턴스에 적용됩니다.

이 시나리오는 Google Cloud에서 사용할 수 있는 몇 가지 HA 기능을 활용합니다. 재해 발생 시 장애 조치 단계가 자동으로 발생하므로 따로 시작하지 않아도 됩니다. 내부 부하 분산기에서는 대체 인스턴스가 필요하더라도 데이터베이스 서버에 동일한 IP 주소가 사용됩니다. 인스턴스 템플릿과 커스텀 이미지가 있기 때문에 대체 인스턴스가 대체하는 인스턴스와 똑같이 구성됩니다. 영구 디스크의 정기적인 스냅샷을 생성하여 스냅샷에서 디스크를 재생성하고 대체 인스턴스에 연결할 때 대체 인스턴스는 스냅샷의 빈도로 지정된 RPO 값에 따라 복구된 데이터를 사용합니다. 이 아키텍처에서는 영구 디스크에 기록된 최신 트랜잭션 로그 파일도 자동으로 복원됩니다.

관리형 인스턴스 그룹에서 세부적인 HA를 제공합니다. 이는 애플리케이션 또는 인스턴스 레벨에서 장애에 대응하는 메커니즘을 제공하며, 이러한 시나리오가 발생하더라도 수동으로 개입할 필요가 없습니다. 대상 크기를 1로 설정하면 관리형 인스턴스 그룹에서 실행되고 트래픽을 처리하는 활성 인스턴스가 하나만 생깁니다.

표준 영구 디스크는 영역 단위이므로 영역 장애가 발생하면 스냅샷을 사용하여 디스크를 다시 만들어야 합니다. 또한 스냅샷을 리전 간에 사용할 수 있으므로 같은 디스크를 리전 내에서뿐만 아니라 다른 리전으로도 복원할 수 있습니다.

이 구성의 변형은 표준 영구 디스크 대신 리전 영구 디스크를 사용하는 것입니다. 이 경우 복구 단계에서 스냅샷을 복원할 필요가 없습니다

예산과 RTO 및 RPO 값에 따라 변형을 선택합니다.

초대형 데이터베이스의 부분 손상 복구

영구 디스크 비동기 복제는 리전 간 활성-수동 DR을 위해 낮은 RPO 및 RTO로 블록 스토리지 복제를 제공합니다. 이 스토리지 옵션을 사용하면 워크로드 수준이 아닌 인프라 수준에서 Compute Engine 워크로드의 복제를 관리할 수 있습니다.

페타바이트 단위의 데이터를 저장할 수 있는 데이터베이스를 사용하는 경우 일부 데이터에 영향을 주지만 모든 데이터에 영향을 주지는 않는 중단을 경험할 수 있습니다. 이 경우 복원해야 하는 데이터의 양을 최소화해야 합니다. 일부 데이터만 복원하기 위해 전체 데이터베이스를 복구할 필요가 없습니다.

채택할 수 있는 완화 전략에는 여러 가지가 있습니다.

  • 데이터를 특정 기간별로 여러 테이블에 나누어 저장합니다. 이 방법을 사용하면 전체 데이터 세트가 아닌 데이터의 하위 집합만 새 테이블로 복원하면 됩니다.

  • 원본 데이터를 Cloud Storage에 저장합니다. 이 방법을 사용하면 새 테이블을 만들고 손상되지 않은 데이터를 새로고침할 수 있습니다. 여기에서 새 테이블을 가리키도록 애플리케이션을 조정할 수 있습니다.

또한 RTO에서 허용하는 경우 손상되지 않은 데이터가 새 테이블로 복원될 때까지 애플리케이션을 오프라인 상태로 유지하여 손상된 데이터가 있는 테이블에 대한 액세스를 차단할 수 있습니다.

Google Cloud의 관리형 데이터베이스 서비스

이 섹션에서는 Google Cloud의 관리형 데이터베이스 서비스에 적합한 백업 및 복구 메커니즘을 구현하는 데 사용할 수 있는 몇 가지 방법을 설명합니다.

관리형 데이터베이스는 확장이 가능하도록 설계되었으므로 기존의 RDMBS에서 볼 수 있는 백업 및 복원 메커니즘은 일반적으로 사용할 수 없습니다. 자체 관리형 데이터베이스의 경우와 마찬가지로 페타바이트 단위의 데이터를 저장할 수 있는 데이터베이스를 사용하는 경우 DR 시나리오에서 복원해야 하는 데이터의 양을 최소화해야 합니다. 이 목표를 달성하는 데 도움이 되는 각 관리형 데이터베이스에 대한 여러 가지 전략이 있습니다.

Bigtable은 Bigtable 복제를 제공합니다. 복제된 Bigtable 데이터베이스는 단일 클러스터보다 높은 가용성, 추가 읽기 처리량, 영역 또는 리전 장애 발생 시 더 높은 내구성과 복원력을 제공합니다.

Bigtable 백업은 테이블의 스키마 및 데이터의 사본을 저장한 후 나중에 백업에서 새 테이블로 복원할 수 있게 해주는 완전 관리형 서비스입니다.

Bigtable의 테이블을 일련의 Hadoop 시퀀스 파일로 내보낼 수도 있습니다. 그런 다음 이러한 파일을 Cloud Storage에 저장하거나 Bigtable의 다른 인스턴스로 데이터를 다시 가져오는 데 사용할 수 있습니다. Google Cloud 리전 내의 영역 간에 Bigtable 데이터 세트를 비동기적으로 복제할 수 있습니다.

BigQuery. 데이터를 보관처리하려는 경우 BigQuery의 장기 스토리지를 활용할 수 있습니다. 연속으로 90일 동안 테이블을 수정하지 않으면 해당 테이블의 저장소 가격이 자동으로 약 50% 인하됩니다. 테이블이 장기 저장소로 간주되더라도 성능, 내구성, 가용성 또는 기타 기능은 저하되지 않습니다. 테이블을 수정하면 일반 저장소 가격으로 돌아가며, 90일 카운트다운이 다시 시작됩니다.

BigQuery는 단일 리전의 영역 2개에 복제되지만 테이블이 손상된 경우에는 도움이 되지 않습니다. 따라서 해당 시나리오에서 손상을 복구하기 위한 계획을 세워야 합니다. 예를 들어 다음을 수행할 수 있습니다.

  • 손상이 발생한 지 7일이 지나지 않은 경우 테이블을 과거의 특정 시점으로 쿼리하여 스냅샷 데코레이터를 통해 테이블을 손상 전 상태로 복구합니다.
  • BigQuery에서 데이터를 내보내고, 내보낸 데이터는 있지만 손상된 데이터는 제외된 새 테이블을 만듭니다.
  • 데이터를 특정 기간별로 여러 테이블에 나누어 저장합니다. 이 방법을 사용하면 전체 데이터 세트가 아닌 데이터의 하위 집합만 새 테이블로 복원하면 됩니다.
  • 특정 기간의 데이터 세트 사본을 만듭니다. 데이터 손상 이벤트가 특정 시점 쿼리에서 캡처할 수 있는 시점 이상으로 발생한 경우 (예: 7일 이상 경과) 이 사본을 사용할 수 있습니다. 또한 한 리전에서 다른 리전으로 데이터세트를 복사하여 리전 오류 발생 시 데이터 가용성을 보장할 수 있습니다.
  • 원본 데이터를 Cloud Storage에 저장하므로 새 테이블을 만들고 손상되지 않은 데이터를 새로고침할 수 있습니다. 여기에서 새 테이블을 가리키도록 애플리케이션을 조정할 수 있습니다.

Firestore 관리형 내보내기 및 가져오기 서비스를 사용하면 Cloud Storage 버킷을 사용하여 Firestore 항목을 가져오고 내보낼 수 있습니다. 그런 다음 실수로 삭제한 데이터를 복구하는 데 사용할 수 있는 프로세스를 구현할 수 있습니다.

Cloud SQL. 완전 관리형 Google Cloud MySQL 데이터베이스인 Cloud SQL을 사용하는 경우 Cloud SQL 인스턴스에 자동 백업 및 바이너리 로깅을 사용 설정해야 합니다. 이 방법을 사용하면 백업에서 데이터베이스를 복원하고 새로운 Cloud SQL 인스턴스로 복구하는 PITR(point-in-time recovery)을 수행할 수 있습니다. 자세한 내용은 Cloud SQL 백업 정보 및 Cloud SQL의 재해 복구 (DR) 정보를 참고하세요.

또한 HA 구성 및 리전 간 복제본에서 Cloud SQL을 구성하여 영역 또는 리전 장애 발생 시 가동 시간을 극대화할 수 있습니다.

Cloud SQL에 다운타임이 거의 없는 계획된 유지보수를 사용 설정한 경우 MySQL용 Cloud SQL 및 PostgreSQL용 Cloud SQL에서 다운타임이 거의 없는 계획된 유지보수 이벤트를 시뮬레이션하여 유지보수 이벤트가 인스턴스에 미치는 영향을 평가할 수 있습니다.

Cloud SQL Enterprise Plus 버전의 경우 고급 재해 복구 (DR)를 사용하여 리전 간 장애 조치를 실행한 후 데이터 손실 없이 복구 및 대체 프로세스를 간소화할 수 있습니다.

Spanner. Dataflow 템플릿을 사용하여 데이터베이스 전체를 Cloud Storage 버킷의 Avro 파일 집합으로 내보내고 다른 템플릿을 사용하여 내보낸 파일을 새 Spanner 데이터베이스에 다시 가져올 수 있습니다.

백업을 더 세부적으로 제어하려면 Dataflow 커넥터를 사용하여 Dataflow 파이프라인에서 데이터를 읽고 Spanner에 쓰는 코드를 작성하면 됩니다. 예를 들어 커넥터를 사용하여 Spanner의 데이터를 Cloud Storage에 백업 대상으로 복사할 수 있습니다. Spanner에서 데이터를 읽거나 다시 쓰는 속도는 구성된 노드의 수에 따라 다릅니다. 이는 RTO 값에 직접적인 영향을 줍니다.

Spanner 커밋 타임스탬프 기능을 사용하면 마지막 전체 백업 이후에 추가되거나 수정된 행만 선택할 수 있어 증분 백업에 유용합니다.

관리형 백업의 경우 Spanner 백업 및 복원을 사용하면 최대 1년 동안 보관할 수 있는 일관된 백업을 만들 수 있습니다. RTO 값은 복원 작업이 데이터를 복사하지 않고 백업을 직접 마운트하므로 내보내기에 비해 낮은 방법입니다.

RTO 값을 작게 하려면 필요한 저장 용량과 읽기 및 쓰기 요구량에 맞는 최소한의 노드 수로 구성된 웜 대기 Spanner 인스턴스를 설정하면 됩니다.

Spanner point-in-time-recovery(PITR)를 사용하면 과거의 특정 시점의 데이터를 복구할 수 있습니다. 예를 들어 운영자가 실수로 데이터를 쓰거나 애플리케이션 롤아웃이 데이터베이스를 손상시키는 경우 PITR을 사용하면 최대 7일 이내의 과거 시점으로 데이터를 복구할 수 있습니다.

Cloud Composer. Cloud Composer(Apache Airflow의 관리형 버전)를 사용하여 여러 Google Cloud 데이터베이스의 정기 백업을 예약할 수 있습니다. 일정에 따라(예: 매일) 실행되는 Directed Acyclic Graph(DAG)를 만들어 데이터를 다른 프로젝트, 데이터세트 또는 테이블(사용되는 솔루션에 따라 다름)에 복사하거나 데이터를 Cloud Storage로 내보낼 수 있습니다.

데이터 내보내기 또는 복사는 다양한 Cloud Platform 연산자를 사용하여 할 수 있습니다.

예를 들어 DAG를 만들어 다음을 수행할 수 있습니다.

프로덕션 환경이 또 다른 클라우드일 경우

이 시나리오에서 프로덕션 환경은 다른 클라우드 제공업체를 사용하며 재해 복구 계획에는 Google Cloud를 복구 사이트로 사용하는 방안이 포함됩니다.

데이터 백업 및 복구

DR 시나리오에서는 객체 저장소 간에 데이터를 전송하는 것이 일반적입니다. Storage Transfer Service는 Amazon S3와 호환되며, Amazon S3에서 Cloud Storage로 객체를 전송할 때 권장되는 방법입니다.

파일 생성 날짜, 파일 이름 필터, 선호하는 데이터 전송 시간을 기준으로 고급 필터를 사용하면 전송 작업을 구성하여 데이터 소스와 데이터 싱크 간에 주기적인 동기화 일정을 예약할 수 있습니다. 원하는 RPO를 달성하려면 다음 요소를 고려해야 합니다.

  • 변경 빈도 특정 기간 동안 생성되거나 업데이트되는 데이터 양입니다. 변경 속도가 높을수록 각 증분 전송 기간 동안 변경사항을 대상 위치로 전송하는 데 더 많은 리소스가 필요합니다.

  • 전송 성능 파일을 전송하는 데 걸리는 시간 대용량 파일 전송의 경우 일반적으로 소스와 대상 사이의 가용 대역폭에 따라 결정됩니다. 그러나 전송 작업이 다수의 작은 파일로 구성된 경우에는 QPS가 제한 요소가 될 수 있습니다. 이 경우 충분한 대역폭을 사용할 수 있는 한 여러 동시 작업을 예약하여 성능을 확장할 수 있습니다. 실제 데이터의 대표적인 하위 집합을 사용해 전송 성능을 측정하는 것이 좋습니다.

  • 빈도 백업 작업 사이의 간격 대상 데이터의 최신 정보는 전송 작업이 마지막으로 예약된 날짜입니다. 따라서 연속 전송 작업 사이의 간격이 RPO 목표보다 길면 안 됩니다. 예를 들어 RPO 목표가 1일인 경우 전송 작업은 하루에 최소 1회 예약해야 합니다.

  • 모니터링 및 알림 Storage Transfer Service는 다양한 이벤트에서 Pub/Sub 알림을 제공합니다. 작업 완료 시 예기치 않은 오류 또는 변경을 처리하려면 이러한 알림을 구독하시는 것이 좋습니다.

데이터베이스 백업 및 복구

이 문서에서는 서드 파티 데이터베이스에 포함된 다양한 기본 제공 백업 및 복구 메커니즘 또는 다른 클라우드 제공업체에서 사용되는 백업 및 복구 기술을 자세하게 설명하지 않습니다. 컴퓨팅 서비스에서 관리되지 않는 데이터베이스를 운영하는 경우 프로덕션 클라우드 제공업체가 제공하는 HA 기능을 활용할 수 있습니다. 이러한 기능을 확장하여 HA 배포판을 Google Cloud에 통합하거나 Cloud Storage를 데이터베이스 백업 파일의 콜드 스토리지에 대한 최종 대상으로 사용할 수 있습니다.

다음 단계