이 문서에서는 데이터를 손실과 다운타임으로부터 보호하는 데 도움이 되는 재해 복구 도구와 기법에 대한 정보를 제공합니다.
Spanner 재해 복구 기능
Spanner는 확장 가능하고 전역적으로 분산되도록 설계되었습니다. Spanner는 높은 데이터 가용성을 보장하는 데 도움이 되는 다음 기능을 제공합니다.
멀티 리전 구성: Spanner는 단일 리전이나 여러 리전 내 별도 영역에 데이터 복제본을 유지하여 영역이나 리전이 실패하더라도 데이터 가용성을 보장할 수 있습니다.
데이터베이스 삭제 보호: 데이터베이스를 삭제하는 데 필요한 Identity and Access Management(IAM) 권한이 있는 사용자나 서비스 계정에서 기존 데이터베이스를 실수로 삭제하지 않도록 보호할 수 있습니다.
데이터베이스 백업 및 복원: Spanner 데이터베이스 백업을 만들고 이를 복원하여 운영자 및 애플리케이션 오류로부터 보호할 수 있습니다. 모든 백업은 가용성이 높고 암호화되며 생성된 시점으로부터 최대 1년까지 보관될 수 있습니다. 주문형으로 또는 백업 일정을 사용하여 전체 백업을 만들 수 있습니다. 증분 백업을 만들려면 백업 일정을 사용해야 합니다.
내보내기 및 가져오기: Spanner 데이터베이스를 CSV 또는 Avro 형식으로 Cloud Storage로 내보낼 수 있습니다.
PITR(point-in-time recovery): Spanner PITR(point-in-time recovery)은 논리 데이터 손상, 실수로 인한 데이터베이스 삭제 또는 쓰기로부터 보호합니다. 예를 들어 운영자가 실수로 데이터를 쓰거나 애플리케이션 실행으로 인해 데이터베이스가 손상되는 경우 데이터를 이전 시점(최대 7일)으로 복구할 수 있습니다.
리전 간 복사: 백업을 여러 지리적 리전에 복사하여 데이터를 리전별 장애로부터 보호하거나 조직의 규정 준수 요구사항을 충족할 수 있습니다.
데이터베이스 백업 또는 내보내기 중에서 선택
데이터베이스 백업 또는 데이터베이스 내보내기를 사용하기 전에 이 둘을 비교합니다. 예를 들어 백업 최대 보관 기간은 1년입니다. 보관 기간을 1년 이상으로 설정하려면 데이터베이스를 내보내는 것이 좋습니다. 다음 표에서는 백업 및 복원 사용과 가져오기 및 내보내기 사용 간의 유사점과 차이점을 설명합니다.
| 백업 및 복원 | 가져오기 및 내보내기 | |
|---|---|---|
| 데이터 일관성 | 백업 및 내보낸 데이터베이스 모두 transactional consistency 및 external consistency를 갖습니다. | |
| 성능 영향 | 백업은 인스턴스 성능에 영향을 미치지 않습니다. Spanner는 인스턴스의 서버 리소스를 사용하지 않는 전용 작업을 사용하여 백업을 수행합니다. | 내보내기는 데이터베이스 성능에 미치는 영향을 최소화하기 위해 중간 우선순위 태스크로 실행됩니다. 자세한 내용은 태스크 우선순위를 참조하세요. |
| 스토리지 형식 | 빠른 복원을 위해 디자인된 고유 암호화 형식이 사용됩니다. | CSV 및 Avro 파일 형식이 모두 지원됩니다. |
| 이동성 | 소스 데이터베이스와 동일한 인스턴스에 백업을 create. 백업이 생성된 후 리전 간 또는 프로젝트 간 백업이 필요한 경우 다른 리전 또는 프로젝트의 인스턴스에 백업을 복사할 수 있습니다. 그런 다음 새 데이터베이스의 백업에서 동일한 프로젝트의 모든 인스턴스로 restore할 수 있습니다. 복원하려는 인스턴스는 백업이 저장된 인스턴스와 동일한 인스턴스 구성을 가져야 합니다. |
내보낸 데이터베이스는 Cloud Storage에 저장되고 데이터는 CSV 또는 Avro를 지원하는 시스템으로 마이그레이션될 수 있습니다. |
| 보관 | 백업을 최대 1년까지 보관할 수 있습니다. | 내보낸 데이터베이스는 Cloud Storage에 저장되며, 기본적으로 삭제되기 전까지 계속 보관됩니다. 수명 주기 및 보관 정책을 맞춤설정할 수 있습니다. |
| 가격 책정 | 백업은 단위 시간별로 사용된 스토리지를 기준으로 Spanner 프로젝트에 청구됩니다. 자세한 내용은 가격 책정 섹션을 참조하세요. | 가져오기 및 내보내기에 대한 청구는 Cloud Storage 및 Dataflow가 사용되므로 더욱 복잡합니다. 자세한 내용은 데이터베이스 내보내기 및 가져오기 가격 책정을 참조하세요. |
| 복원 시간 | 복원은 복원 및 최적화의 두 작업으로 수행됩니다. 데이터 복사 없이 데이터베이스가 백업을 직접 마운트하기 때문에 복원 작업은 빠른 첫 바이트 소요 시간을 제공합니다. 최적화하는 동안 읽기 대기 시간이 약간 더 높을 수 있지만 복원 작업이 완료된 다음에는 데이터베이스를 사용할 준비가 됩니다. 자세한 내용은 복원 작동 방법을 참조하세요. | 가져오기는 속도가 더 느립니다. 모든 데이터가 데이터베이스에 기록될 때까지 기다려야 합니다. |
재해 복구 기법
Spanner는 다음과 같은 재해로부터 데이터를 보호하는 재해 복구 기법을 제공합니다.
- 영역 장애: Spanner 리전 구성은 영역 장애에 대한 자동 보호 기능을 제공하므로 리전 내 한 영역에서 장애가 발생하더라도 애플리케이션은 계속 작동합니다.
- 리전 장애: 애플리케이션에 더 높은 데이터 가용성과 리전 장애에 대한 보호가 필요한 경우에는 99.999% 가용성을 제공하는 멀티 리전 구성을 사용합니다.
- 주요 지리적 재해: 여러 리전에서 백업을 사용할 수 있도록 Spanner 리전 간 백업 사본을 사용합니다.
- 논리적 손상: 보관 기간에 따라 다음과 같은 재해 복구 기법을 사용합니다.
- PITR(point-in-time recovery)을 설정하여 지난 7일 이내의 특정 시점의 데이터를 복원합니다.
- 요구사항을 충족하는 빈도로 전체 백업이나 증분 백업을 만드는 백업 일정을 설정합니다. 모든 백업을 최대 1년 동안 보관할 수 있습니다.
- 규정 준수, 분석 또는 보고를 위해 데이터를 보관할 수 있는 Cloud Storage로 데이터베이스를 내보냅니다.
- 실수로 데이터베이스 삭제: 필요한 IAM 권한이 있는 사용자나 서비스 계정에서 기존 데이터베이스를 실수로 삭제하지 않게 하려면 데이터베이스 삭제 보호를 사용합니다.
재해 복구 전략에 맞게 비용 최적화
다음과 같은 방법으로 Spanner 재해 복구 비용을 최적화할 수 있습니다.
- 멀티 리전 구성: 99.999% 가용성이 필요한 애플리케이션에만 멀티 리전 구성을 사용합니다. 읽기 전용 지연 시간이 필요한 애플리케이션의 경우 다른 리전의 읽기 복제본을 사용하는 것이 좋습니다.
- 백업 빈도: 요구사항을 충족하는 데 필요한 빈도로만 백업을 예약합니다.
- 백업 유형: 스토리지 비용을 절약하려면 증분 백업 일정을 사용합니다.
- 백업 보관 기간: 복구 및 규정 준수 니즈를 충족하는 데 필요한 최소 기간의 백업 보관 기간을 결정하고 설정합니다.
- 대규모 데이터 내보내기: 대규모 데이터 내보내기에 Spanner Data Boost를 사용하면 인스턴스에서 컴퓨팅 리소스를 오프로드하고 트랜잭션 성능에 부정적인 영향을 방지할 수 있습니다.
재해 복구 전략 테스트
재해 복구 계획의 다음 구성요소를 테스트하고 검증하는 것이 좋습니다.
- 조직에서 데이터 손실을 일으킬 가능성이 가장 높은 이벤트를 시뮬레이션합니다.
- 생성된 백업에서 데이터베이스 복원을 연습합니다. 데이터베이스 복원 방법에 대한 자세한 내용은 복원 개요를 참조하세요.
- 재해 복구 계획이 스토리지 사용량에 미치는 영향을 평가합니다.
- 백업 프로세스가 애플리케이션 성능에 미치는 영향을 평가합니다.
- 영역 또는 리전 장애를 시뮬레이션하여 장애 조치 및 복구 절차를 테스트합니다.