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

이 문서는 Google Cloud Platform(GCP)의 재해 복구(DR)에 대해 다루는 시리즈 중 세 번째 부분입니다. 이 부분에서는 데이터 백업 및 복구 시나리오를 설명합니다.

시리즈는 다음과 같은 부분으로 구성됩니다.

소개

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

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

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

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

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

데이터 백업 및 복구

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

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

DR 구성요소:

  • Cloud Storage

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

gsutil -m cp -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

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

  1. 데이터 파일을 업로드하는 데 사용할 온프레미스 머신에 gsutil을 설치합니다.
  2. 데이터 백업 대상으로 버킷을 생성합니다.
  3. JSON 형식으로 전용 서비스 계정의 서비스 계정 키를 생성합니다. 이 파일은 자동 스크립트의 일부로 gsutil에 사용자 인증 정보를 전달하는 데 사용됩니다.
  4. 백업을 업로드하는 데 사용하는 스크립트를 실행하는 온프레미스 머신에 서비스 계정 키를 복사합니다.

  5. IAM 정책을 만들어 버킷과 버킷 객체에 액세스할 수 있는 사람을 제한합니다. 이 목적으로 특수하게 만든 서비스 계정과 온프레미스 운영자 계정을 포함합니다. Cloud Storage에 액세스하기 위한 권한에 대한 자세한 내용은 gsutil 명령어에 대한 IAM 권한을 참조하세요.

  6. 타겟 버킷에서 파일을 업로드 및 다운로드할 수 있는지 테스트합니다.

  7. 데이터 전송 작업 스크립팅의 지침을 따라 예약된 스크립트를 설정합니다.

  8. gsutil을 사용하여 GCP의 복구 DR 환경으로 데이터를 복구하는 복구 프로세스를 구성합니다.

자세한 내용은 전송 프로세스를 최적화하는 방법이 포함된 코로케이션 또는 온프레미스 저장소에서 전송을 참조하세요.

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

DR 구성요소:

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

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

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

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

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

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

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

데이터베이스 백업 및 복구

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

타사 데이터베이스에 포함된 다양한 내장 백업 및 복구 메커니즘에 대한 자세한 논의는 이 문서의 범위를 벗어납니다. 이 섹션에서는 여기서 설명하는 솔루션에 구현된 일반적인 지침을 제공합니다.

솔루션 1: GCP의 복구 서버를 사용한 백업 및 복구

  1. 데이터베이스 관리 시스템의 내장 백업 메커니즘을 사용하여 데이터베이스 백업을 만듭니다.
  2. 데이터 백업의 대상으로 Cloud Storage 버킷을 만듭니다.
  3. gsutil 또는 파트너 게이트웨이 솔루션을 사용하여 백업 파일을 Cloud Storage에 복사합니다(앞서 데이터 백업 및 복구 섹션에서 논의한 단계 참조). 자세한 내용은 빅데이터 세트를 GCP로 전송을 참조하세요.
  4. 트랜잭션 로그를 GCP의 복구 사이트에 복사합니다. 트랜잭션 로그를 백업하면 RPO 값을 작게 유지하는 데 도움이 됩니다.

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

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

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

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

솔루션 2: GCP의 대기 서버로 복제

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

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

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

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

프로덕션 환경이 GCP일 경우

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

데이터 백업 및 복구

데이터 백업의 일반적인 패턴은 계단식 저장소 패턴을 사용하는 것입니다. 프로덕션 작업 부하가 GCP에 있을 때 계단식 저장소 시스템은 다음 다이어그램과 같습니다. 백업된 데이터에 대한 액세스 요구는 거의 없기 때문에 저장소 비용이 낮은 등급으로 데이터를 이전합니다.

DR 구성요소:

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

Google Cloud Storage Nearline 및 Google Cloud Storage Coldline의 용도는 가끔 액세스하는 데이터를 저장하는 것이므로 이 등급에 저장된 데이터 또는 메타데이터를 가져올 경우 관련된 추가 요금은 물론 최소 저장 기간에 대한 요금이 발생합니다.

데이터베이스 백업 및 복구

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

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

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

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

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

DR 구성요소:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

지역별 관리형 인스턴스 그룹에서 HA를 제공합니다. 이는 애플리케이션, 인스턴스 또는 영역 레벨에서 장애에 대응하는 메커니즘을 제공하며, 이러한 시나리오가 발생하더라도 수동으로 개입할 필요가 없습니다. 대상 크기를 1로 설정하면 인스턴스가 항상 하나만 실행됩니다.

표준 영구 디스크는 영역 단위이므로 영역 장애가 발생하면 스냅샷을 사용하여 디스크를 다시 만들어야 합니다. 또한 스냅샷은 여러 지역 간에 사용할 수 있으므로 동일한 지역으로 디스크를 복원하는 것만큼 쉽게 다른 지역으로 디스크를 복원할 수 있습니다.

다음 다이어그램은 영구 디스크 스냅샷을 사용하여 다른 영역의 영구 디스크를 복원한 복구 시나리오를 보여줍니다.

두 번째 영역으로 복구하는 데 사용되는 영구 디스크 이미지를 보여주는 아키텍처 다이어그램

이 구성은 다음과 같이 변형될 수 있습니다.

  • 표준 영구 디스크 대신 지역 영구 디스크 사용. 이 경우 복구 단계에서 스냅샷을 복원할 필요가 없습니다
  • 지역별 관리형 인스턴스 그룹 대신 관리형 인스턴스 그룹을 사용하고, 실패한 인스턴스와 동일한 영역에서 시작된 대체 인스턴스에 영구 디스크 연결. 이 경우 영구 디스크 자동 삭제 설정을 no-auto-delete로 설정해야 합니다.

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

GCP에서 HA 및 DR 시나리오용으로 설계된 데이터베이스 구성에 대한 자세한 내용은 다음을 참조하세요.

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

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

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

  • 데이터를 특정 기간별로 여러 테이블에 나누어 저장합니다. 이 방법을 사용하면 전체 데이터세트가 아닌 데이터의 하위 집합만 새 테이블로 복원하면 됩니다.
  • 원본 데이터를 Cloud Storage에 저장합니다. 이렇게 하면 새 테이블을 만들고 손상되지 않은 데이터를 다시 로드할 수 있습니다. 여기에서 새 테이블을 가리키도록 애플리케이션을 조정할 수 있습니다.

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

GCP의 관리형 데이터베이스 서비스

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

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

Cloud BigtableCloud Bigtable 리전 복제를 제공합니다. 복제된 Cloud Bigtable 데이터베이스는 단일 클러스터보다 더 높은 가용성, 추가적인 읽기 처리량, 높은 내구성, 영역 오류 발생 시 장애 복원력을 제공할 수 있습니다.

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

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

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

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

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

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

또한 Cloud SQL을 HA로 구성하여 가동 시간을 극대화할 수도 있습니다.

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

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

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

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

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

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

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

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

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

데이터 백업 및 복구

DR 시나리오에서는 객체 저장소 간에 데이터를 전송하는 것이 일반적입니다. Storage Transfer Service는 Amazon S3와 호환되며, Amazon S3에서 Cloud Storage로 객체를 전송할 때 권장되는 방법입니다. 파일 생성 날짜, 파일 이름 필터, 데이터 가져오기 작업에 선호하는 시간을 기준으로 고급 필터를 사용하면 전송 작업을 구성하여 데이터 소스와 데이터 싱크 간에 주기적인 동기화 일정을 예약할 수 있습니다.

AWS에서 GCP로 데이터를 이동하는 또 다른 옵션은 Amazon S3 및 Cloud Storage와 호환되는 Python 도구인 boto를 사용하는 것입니다. 이는 gsutil 명령줄 도구에 대한 플러그인으로 설치할 수 있습니다.

데이터베이스 백업 및 복구

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

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...