재해 복구 사용 사례: 지역별로 제한된 데이터 분석 애플리케이션

Last reviewed 2022-01-07 UTC

이 문서는 Google Cloud의 재해 복구(DR)를 설명하는 시리즈 중 하나입니다. 이 문서에서는 지역별로 제한된 워크로드의 재해 복구 설계 문서의 지역별 제한을 데이터 분석 애플리케이션에 적용하는 방법을 설명합니다. 특히 이 문서에서는 데이터 분석 플랫폼에 사용되는 구성요소가 애플리케이션 또는 데이터에 영향을 줄 수 있는 지역별 제한을 충족하는 DR 아키텍처에 어떻게 적합한지에 대해 설명합니다.

이 시리즈는 다음 문서로 구성됩니다.

이 문서는 시스템 설계자 및 IT 관리자를 대상으로 합니다. 여기에서는 다음 지식과 기술이 있다고 가정합니다.

데이터 분석 플랫폼의 지역별 요구사항

데이터 분석 플랫폼은 일반적으로 저장 데이터가 보관되는 복잡한 다단계 애플리케이션입니다. 이러한 애플리케이션은 분석 시스템에서 처리 및 저장되는 이벤트를 생성합니다. 애플리케이션 자체와 시스템에 저장되는 데이터는 지역별 규제의 영향을 받습니다. 이러한 규정은 국가는 수직 업종에 따라서도 달라집니다. 따라서 DR 아키텍처 설계를 시작하기 전 데이터 지역별 요구사항에 대한 명확한 이해가 필요합니다.

다음 두 가지 질문을 통해 데이터 분석 플랫폼에 지역별 요구사항이 있는지 확인할 수 있습니다.

  • 애플리케이션을 배포해야 할 특정 리전이 있나요?
  • 저장 데이터가 특정 리전으로 제한되나요?

두 질문 모두 답변이 '아니요'라면 데이터 분석 플랫폼에 지역성과 관련된 요구사항이 없다고 볼 수 있습니다. 플랫폼에 지역별 요구사항이 없으므로 재해 복구 계획 가이드에 설명된 규정 준수 서비스 및 제품에 관한 DR 지침을 따르면 됩니다.

하지만 둘 중 하나라도 답변이 '예'라면 애플리케이션이 특정 지역별로 제한되었다고 볼 수 있습니다. 분석 플랫폼이 지역별로 제한되기 때문에 저장 데이터 요구사항을 완화하기 위한 암호화 기술을 사용할 수 있는가?라는 다음 질문을 살펴봐야 합니다.

암호화 기술을 사용할 수 있다면 Cloud 외부 키 관리자 및 Cloud Key Management Service의 멀티 리전 및 이중 리전 서비스를 사용할 수 있습니다. 그런 다음 데이터 재해 복구 시나리오에 설명된 표준 고가용성 및 재해 복구(HA/DR) 기술을 따를 수도 있습니다.

암호화 기술을 사용할 수 없으면 DR 계획을 위한 커스텀 솔루션 또는 파트너 제안 솔루션을 사용할 수 있습니다. DR 시나리오의 지역별 제한 해결을 위한 기법들에 대해 자세히 알아보려면 지역별로 제한된 워크로드의 재해 복구 설계를 참조하세요.

데이터 분석 플랫폼의 구성요소

지역별 요구사항을 이해한 다음에는 데이터 분석 플랫폼에 사용되는 구성요소에 대한 이해가 필요합니다. 데이터 분석 플랫폼에서 일반적인 구성요소에는 다음 목록에 표시된 것처럼 데이터베이스, 데이터 레이크, 처리 파이프라인, 데이터 웨어하우스가 있습니다.

  • Google Cloud에는 여러 사용 사례에 맞는 데이터베이스 서비스 집합이 있습니다.
  • 데이터 레이크, 데이터 웨어하우스, 처리 파이프라인은 정의가 약간 다를 수 있습니다. 이 문서에서는 Google Cloud 서비스를 참조하는 정의 집합이 사용됩니다.
    • 데이터 레이크는 여러 시스템에서 데이터를 수집하고 저장하기 위한 확장 가능한 보안 플랫폼입니다. 일반적인 데이터 레이크는 Cloud Storage를 중앙 스토리지 저장소로 사용할 수 있습니다.
    • 처리 파이프라인은 하나 이상의 시스템에서 데이터 또는 이벤트를 가져와서 이 데이터 또는 이벤트를 변환하고 이를 다른 시스템으로 로드하는 엔드 투 엔드 프로세스입니다. 파이프라인은 추출, 변환, 로드(ETL) 또는 추출, 로드, 변환(ELT) 프로세스를 따를 수 있습니다. 일반적으로 처리된 데이터가 로드되는 시스템이 바로 데이터 웨어하우스입니다. Pub/Sub, Dataflow, Dataproc는 일반적으로 사용되는 처리 파이프라인의 구성요소입니다.
    • 데이터 웨어하우스는 일반적으로 운영 데이터베이스에서 시작되는 분석 및 데이터 보고에 사용되는 엔터프라이즈 시스템입니다. BigQuery는 Google Cloud에서 실행되는 일반적으로 사용되는 데이터 웨어하우스 시스템입니다.

사용 중인 데이터 분석 구성요소 및 지역별 요구사항에 따라 실제 DR 구현이 달라질 수 있습니다. 다음 섹션에서는 두 가지 사용 사례에 따라 구현이 어떻게 달라지는지 보여줍니다.

일괄 사용 사례: 주기적인 ETL 작업

첫 번째 사용 사례에서는 소매 플랫폼이 여러 저장소에서 파일과 같은 판매 이벤트를 주기적으로 수집한 후 파일을 Cloud Storage 버킷에 기록하는 일괄 프로세스에 대해 설명합니다. 다음 다이어그램은 이러한 소매업체의 일괄 작업의 데이터 분석 아키텍처를 보여줍니다.

판매 시점 데이터가 포함된 일괄 사용 사례의 아키텍처 다이어그램입니다.

이 아키텍처에는 다음과 같은 단계 및 구성요소가 포함됩니다.

  • 수집 단계는 저장소에서 판매 시점(POS) 데이터를 Cloud Storage로 전송하는 과정으로 구성됩니다. 수집된 데이터는 처리를 기다립니다.
  • 조정 단계에서는 Cloud Composer를 사용하여 엔드 투 엔드 일괄 파이프라인을 조정합니다.
  • 처리 단계에서는 Dataproc 클러스터에서 Apache Spark 작업을 실행합니다. Apache Spark 작업은 수집된 데이터에 대해 ETL 프로세스를 수행합니다. 이 ETL 프로세스는 비즈니스 측정항목을 제공합니다.
  • 데이터 레이크는 처리된 데이터를 가져와서 정보를 다음 구성요소에 저장합니다.
    • 처리된 데이터는 일반적으로 Parquet 및 ORC와 같은 Cloud Storage 열 형식으로 저장됩니다 이러한 형식은 분석 워크로드를 위한 효율적인 스토리지와 빠른 액세스를 허용하기 때문입니다.
    • 프로세스 데이터(예: 데이터베이스, 테이블, 열, 파티션)에 대한 메타데이터는 Dataproc Metastore에서 제공하는 Hive 메타스토어 서비스에 저장됩니다.

지역별로 제한된 시나리오에서는 가용성 유지를 위해 중복된 처리 및 조정 기능을 제공하는 것이 어려울 수 있습니다. 데이터가 일괄 작업으로 처리되기 때문에 처리 및 조정 파이프라인이 다시 생성될 수 있고 재해 시나리오가 해결된 후 일괄 작업이 다시 시작될 수 있습니다. 따라서 재해 복구의 경우에는 수집된 POS 데이터, 데이터 레이크에 저장된 처리된 데이터, 데이터 레이크에 저장된 메타데이터와 같은 실제 데이터를 복구하는 데 중점을 두게 됩니다.

Cloud Storage로 수집

첫 번째 고려사항은 POS 시스템에서 데이터를 수집하기 위해 사용된 Cloud Storage 버킷의 지역별 요구사항입니다. 이러한 지역별 정보를 사용해서 다음 옵션을 고려하세요.

  • 지역별 요구사항에 따라 저장 데이터를 멀티 리전 또는 이중 리전 위치에 배치하는 것이 허용된다면 Cloud Storage 버킷을 만들 때 해당 위치 유형을 선택합니다. 선택한 위치 유형에 따라 저장 데이터를 복제하는 데 사용되는 Google Cloud 리전이 정의됩니다. 리전 중 하나에서 서비스 중단이 발생하더라도 멀티 리전 또는 이중 리전 버킷에 있는 데이터에 액세스할 수 있습니다.
  • Cloud Storage는 또한 고객 관리 암호화 키(CMEK) 및 고객 제공 암호화 키(CSEK)를 모두 지원합니다. 일부 지역별 규칙에서는 키 관리를 위해 CMEK 또는 CSEK를 사용할 때 여러 위치에서의 저장 데이터 보관이 허용됩니다. 지역별 규칙에 따라 CMEK 또는 CSEK 사용이 허용될 경우 Cloud Storage 리전을 사용하도록 DR 아키텍처를 설계할 수 있습니다.
  • 지역별 요구사항에 따라 위치 유형 또는 암호화 키 관리 사용이 허용되지 않을 수 있습니다. 위치 유형 또는 암호화 키 관리를 사용할 수 없을 때는 gsutil rsync 명령어를 사용해서 온프레미스 스토리지 또는 다른 클라우드 제공업체의 스토리지 솔루션과 같은 다른 위치에 데이터를 동기화할 수 있습니다.

재해가 발생하면 Cloud Storage 버킷에 수집된 POS 데이터 중 일부에는 아직 처리되어 데이터 레이크로 가져오지 않은 데이터가 포함될 수 있습니다. 또는 POS 데이터를 Cloud Storage 버킷으로 수집하지 못할 수도 있습니다. 이러한 경우에 사용 가능한 재해 복구 옵션은 다음과 같습니다.

  • POS 시스템이 작업을 재시도하도록 허용합니다. 시스템이 POS 데이터를 Cloud Storage에 기록할 수 없으면 데이터 수집 프로세스가 실패합니다. 이 상황을 해결하기 위해서는 POS 시스템이 데이터 수집 작업을 재시도하도록 잘린 지수 백오프 알고리즘을 구현할 수 있습니다. Cloud Storage는 99.999999999%의 내구성을 제공하기 때문에 Cloud Storage 서비스 재개 후 데이터 수집 및 후속 처리 파이프라인이 거의 데이터 손실 없이 재개됩니다.

  • 수집된 데이터를 복사합니다. Cloud Storage에는 멀티 리전 및 이중 리전 위치 유형이 모두 지원됩니다. 데이터 지역별 요구사항에 따라 데이터 가용성 증가를 위해 멀티 리전 또는 이중 리전 Cloud Storage 버킷을 설정할 수 있습니다. gsutil과 같은 도구를 사용하여 Cloud Storage와 다른 위치 간에 데이터를 동기화할 수도 있습니다.

수집된 POS 데이터 조정 및 처리

일괄 사용 사례에 대한 아키텍처 다이어그램에서 Cloud Composer에서는 다음 단계가 수행됩니다.

  • Cloud Storage 수집 버킷에 새 파일이 업로드되었는지 검증합니다.
  • 임시 Dataproc 클러스터를 시작합니다.
  • 데이터 처리를 위한 Apache Spark 작업을 시작합니다.
  • 작업 종료 시 Dataproc 클러스터를 삭제합니다.

Cloud Composer에서는 이러한 일련의 단계를 정의하는 방향성 비순환 그래프(DAG) 파일이 사용됩니다. 이러한 DAG 파일은 아키텍처 다이어그램에 표시되지 않은 Cloud Storage 버킷에 저장됩니다. 이중 리전 및 멀티 리전 지역성 측면에서 DAG 파일 버킷의 DR 고려사항은 수집 버킷에 대한 고려사항과 동일합니다.

Dataproc 클러스터는 임시적입니다. 즉, 처리 단계가 실행되는 동안만 클러스터가 존재합니다. 이러한 임시적인 특성에 따라 Dataproc 클러스터와 관련해서는 DR에 대해 어느 것도 명시적으로 수행할 필요가 없습니다.

Cloud Storage를 사용하는 데이터 레이크 스토리지

데이터 레이크에 사용하는 Cloud Storage 버킷에는 수집 버킷에 대해 논의한 것과 동일한 지역 고려 사항(이중 영역 및 다중 영역 고려 사항, 암호화 사용, gsutil rsync 사용)이 있습니다.

데이터 레이크의 DR 계획을 설계할 때는 다음 특성을 고려하세요.

  • 데이터 크기. 데이터 레이크는 데이터 볼륨이 클 수 있습니다. 많은 양의 데이터 볼륨을 복원하려면 시간이 소요됩니다. DR 시나리오에서는 데이터 레이크 볼륨에 따라 다음 기준을 충족시키는 지점까지 데이터를 복원하는 데 걸리는
    시간을 고려해야 합니다.

    현재 일괄 사용 사례에서는 Cloud Storage가 데이터 레이크 위치에 사용되고 99.999999999% 내구성을 제공합니다. 하지만 랜섬웨어 공격이 증가하고 있습니다. 이러한 공격에 대한 복구 기능을 갖추기 위해서는 Cloud Storage에서 99.999999999% 내구성을 제공하는 방법에 설명된 권장사항을 따르는 것이 좋습니다.

  • 데이터 종속 항목. 데이터 레이크의 데이터는 일반적으로 처리 파이프라인과 같은 데이터 분석 시스템의 다른 구성요소에서 소비됩니다. DR 시나리오에서 처리 파이프라인과 여기에 사용되는 데이터는 RTO가 동일해야 합니다. 여기에서는 시스템 사용 불가 상태가 허용되는 시간에 중점을 둡니다.

  • 데이터 기간. 과거 데이터는 높은 RPO가 허용될 수 있습니다. 이 유형의 데이터는 다른 데이터 분석 구성요소에서 이미 분석 또는 처리가 완료된 상태일 수 있고 자체 DR 전략이 있는 다른 구성요소에 저장된 상태일 수 있습니다. 예를 들어 Cloud Storage로 내보낸 영업 레코드를 분석을 위해 매일 BigQuery로 가져옵니다. BigQuery에 대해 적절한 DR 전략을 사용할 경우 BigQuery로 가져온 과거 영업 레코드는 아직 가져오지 않은 레코드보다 복구 목표가 낮을 수 있습니다.

Dataproc Metastore를 사용하는 데이터 레이크 메타데이터 스토리지

Dataproc Metastore는 완전 관리형, 고가용성, 자동 복구, 서버리스를 지원하는 Apache Hive Metastore입니다. 이 Metastore는 데이터 추상화 및 데이터 검색 기능을 제공합니다. 재해를 대비해서 이 Metastore를 백업 및 복원할 수 있습니다. 또한 Dataproc Metastore 서비스를 사용해서 메타데이터 내보내기 및 import를 수행할 수 있습니다. Metastore를 내보내고 ETL 작업과 함께 외부 백업을 유지보수하는 태스크를 추가할 수 있습니다.

메타데이터 불일치 상황이 발생하면 MSCK 명령어를 사용해서 데이터 자체로부터 Metastore를 다시 만들 수 있습니다.

스트리밍 사용 사례: ELT를 사용하여 변경 데이터 캡처

두 번째 사용 사례에서는 변경 데이터 캡처(CDC)를 사용해서 백엔드 인벤토리 시스템을 업데이트하고 실시간 영업 측정항목을 추적하는 소매 플랫폼에 대해 설명합니다. 다음 다이어그램은 Cloud SQL과 같은 트랜잭션 데이터베이스의 이벤트가 처리되어 데이터 웨어하우스에 저장되는 아키텍처를 보여줍니다.

소매 데이터의 변경 데이터 캡처가 포함된 스트리밍 사용 사례에 대한 아키텍처 다이어그램입니다.

이 아키텍처에는 다음과 같은 단계 및 구성요소가 포함됩니다.

  • 수집 단계는 수신되는 변경 이벤트가 Pub/Sub로 푸시되는 과정으로 구성됩니다. 메시지 전송 서비스로서 Pub/Sub는 스트리밍 분석 데이터를 안정적으로 수집하고 배포하기 위해 사용됩니다. Pub/Sub는 확장성과 서버리스라는 추가 이점이 있습니다.
  • 처리 단계에서는 Dataflow를 사용해서 수집된 이벤트에 대해 ELT 프로세스를 수행합니다.
  • 데이터 웨어하우스 단계에서는 BigQuery를 사용하여 처리된 이벤트를 저장합니다. 병합 작업은 BigQuery에 레코드를 삽입하거나 업데이트합니다. 이 작업은 BigQuery에 저장된 정보를 트랜잭션 데이터베이스에 맞게 최신 상태로 유지할 수 있게 해줍니다.

이 CDC 아키텍처에는 Cloud Composer가 사용되지 않지만 일부 CDC 아키텍처에서는 일괄 워크로드에 대한 스트리밍 통합 조정을 위해 Cloud Composer가 필요합니다. 이러한 경우 Cloud Composer 워크플로는 지연 시간 제약조건으로 인해 실시간으로 수행될 수 없는 무결성 검사, 백필, 프로젝션을 구현합니다. Cloud Composer의 DR 기술은 이 문서의 앞 부분에서 언급한 일괄 처리 사용 사례에 설명되어 있습니다.

스트리밍 데이터 파이프라인의 경우 DR 아키텍처를 계획할 때 다음을 고려해야 합니다.

  • 파이프라인 종속 항목. 처리 파이프라인은 하나 이상의 시스템(소스)에서 입력을 가져옵니다. 그런 후 이러한 입력을 처리 및 변환하고 일부 다른 시스템(싱크)에 저장합니다. 엔드 투 엔드 RTO를 달성할 수 있도록 DR 아키텍처를 설계해야 합니다. 데이터 소스 및 싱크의 RPO로 RTO를 충족시킬 수 있는지 확인해야 합니다. 또한 지역별 요구사항을 충족하도록 클라우드 아키텍처를 설계하는 것 외에도 엔드 투 엔드 RTO가 충족되도록 시작 CDC 소스를 설계해야 합니다.
  • 암호화 및 지역성. 암호화로 지역별 제한을 완화할 수 있는 경우에는 Cloud KMS를 사용해서 다음 목표를 달성할 수 있습니다.
    • 자체 암호화 키를 관리합니다.
    • 개별 서비스의 암호화 기능을 활용합니다.
    • 지역별 제한으로 인해 다른 경우에는 사용할 수 없는 리전에 서비스를 배포합니다.
  • 이동 데이터에 대한 지역별 규칙. 일부 지역별 규칙은 저장 데이터에만 적용되고 이동 데이터에 적용되지 않을 수 있습니다. 지역별 규칙이 이동 데이터에 적용되지 않을 경우 복구 목표 향상을 위해 다른 리전의 리소스를 활용하도록 DR 아키텍처를 설계합니다. 암호화 기술을 통합하여 리전별 접근 방식을 보완할 수 있습니다.

Pub/Sub로 수집

지역별 제한이 없으면 메시지를 전역 Pub/Sub 엔드포인트에 게시할 수 있습니다. 전역 Pub/Sub 엔드포인트는 모든 Google Cloud 위치에서 볼 수 있고 액세스할 수 있습니다.

지역별 요구사항에 따라 암호화 사용이 허용될 경우 전역 엔드포인트와 비슷한 수준의 고가용성을 달성하도록 Pub/Sub를 구성할 수 있습니다. 기본적으로 Pub/Sub 메시지가 Google 소유 및 Google 관리 키로 암호화되지만 대신 CMEK를 사용하도록 Pub/Sub를 구성할 수도 있습니다. CMEK와 Pub/Sub를 사용하면 고가용성을 유지하면서도 암호화에 대한 지역별 규칙을 충족시킬 수 있습니다.

일부 지역별 규칙에 따라서는 암호화 후에도 특정 위치에 메시지를 유지해야 합니다. 지역별 규칙에 이러한 제한이 포함된 경우 Pub/Sub 주제의 메시지 스토리지 정책을 지정하고 이를 리전으로 제한할 수 있습니다. 이러한 메시지 스토리지 접근 방법을 사용할 경우에는 특정 주제에 게시되는 메시지가 사용자가 지정하는 Google Cloud 리전 집합 외부에 저장되지 않습니다. 지역별 규칙에 따라 2개 이상의 Google Cloud 리전 사용이 허용될 경우에는 Pub/Sub 주제에서 해당 리전을 사용 설정하여 서비스 가용성을 늘릴 수 있습니다. Pub/Sub 리소스 위치를 제한하도록 메시지 스토리지 정책을 구현하기 위해서는 그로 인한 가용성 영향이 있다는 것에 주의해야 합니다.

Pub/Sub 구독을 사용하면 메시지 수에 대한 제한 없이 최대 7일까지 미확인 메시지를 저장할 수 있습니다. 서비스수준계약에 따라 데이터 지연이 허용될 경우에는 파이프라인 실행이 중지될 경우 이러한 데이터를 Pub/Sub 구독에 버퍼로 저장할 수 있습니다. 파이프라인이 다시 실행되면 백업된 이벤트를 처리할 수 있습니다. 이 설계는 RPO가 낮은 이점이 있습니다. Pub/Sub의 리소스 제한에 대한 자세한 내용은 Pub/Sub 할당량의 리소스 제한을 참조하세요.

Dataflow를 사용한 이벤트 처리

Dataflow는 다양한 데이터 처리 패턴을 실행하는 관리형 서비스입니다. Apache Beam SDK는 일괄 및 스트리밍 파이프라인을 모두 개발할 수 있는 오픈소스 프로그래밍 모델입니다. Apache Beam 프로그램을 사용하여 파이프라인을 만든 다음 Dataflow 서비스에서 파이프라인을 실행합니다.

지역별 제한을 설계할 때는 소스, 싱크, 임시 파일이 배치되는 위치를 고려해야 합니다. 이러한 위치가 해당 작업 리전 외부에 있으면 데이터가 리전 간에 전송될 수 있습니다. 지역별 규칙에 따라 다른 위치에서의 데이터 처리가 허용될 경우에는 고가용성 제공을 위해 다른 Google Cloud 리전에서 작업자를 배포하도록 DR 아키텍처를 설계합니다.

지역별 제한에 따라 단일 위치로 처리가 제한될 경우에는 특정 리전 또는 영역으로 제한되는 Dataflow 작업을 만들 수 있습니다. Dataflow 작업을 제출할 때는 리전 엔드포인트, 작업자 리전, 작업자 영역 매개변수를 지정할 수 있습니다. 이러한 매개변수는 작업자 배포 위치와 작업 메타데이터 저장 위치를 제어합니다.

Apache Beam은 여러 실행기 간에 파이프라인이 실행되도록 허용하는 프레임워크를 제공합니다. 이 기능을 활용하도록 DR 아키텍처를 설계할 수 있습니다. 예를 들어 Apache Spark 실행기를 사용해서 로컬 온프레미스 Spark 클러스터에서 실행되는 백업 파이프라인을 갖도록 DR 아키텍처를 설계할 수 있습니다. 특정 실행기로 특정 파이프라인 작업을 수행할 수 있는지에 대한 자세한 내용은 Beam 기능 표를 참조하세요.

암호화를 통해 지역별 제한을 완화할 수 있으면 Dataflow의 CMEK를 사용해서 파이프라인 상태 아티팩트를 암호화하고 Cloud KMS 키로 보호되는 소스 및 싱크에 액세스할 수 있습니다. 암호화를 사용하면 지역별 제한으로 인해 다른 경우에는 사용할 수 없는 DR 아키텍처를 설계할 수 있습니다.

BigQuery로 빌드된 데이터 웨어하우스

데이터 웨어하우스는 분석 및 의사결정을 지원합니다. 분석 데이터베이스 외에도 데이터 웨어하우스에는 여러 분석 구성요소와 프로시져가 포함됩니다.

데이터 웨어하우스의 DR 계획을 설계할 때는 다음 특성을 고려하세요.

  • 크기. 데이터 웨어하우스는 온라인 트랜잭션 처리(OLTP) 시스템보다 훨씬 큽니다. 데이터 웨어하우스에 수 테라바이트부터 수 페타바이트까지 데이터가 포함되는 것도 특별한 일은 아닙니다. RPO 및 RTO 값을 얻기 위해서는 이 데이터를 복원하는 데 걸리는 시간을 고려해야 합니다. DR 전략을 계획할 때는 수 테라바이트의 데이터를 복구하는 데 걸리는 비용도 고려해야 합니다. BigQuery의 DR 완화 기술에 대한 자세한 내용은 Google Cloud에서 관리형 데이터베이스 서비스를 위한 백업 및 복구 메커니즘에서 BigQuery 정보 섹션을 참조하세요.

  • 가용성: BigQuery 데이터 세트를 만들 때 데이터를 저장할 위치 즉, 리전 또는 멀티 리전을 선택합니다. 리전 위치는 아이오와(us-central1)나 몬트리올(northamerica-northeast1)과 같이 단일 특정 지리적 위치입니다. 멀티 리전 위치는 미국(US)이나 유럽(EU)과 같이 2개 이상의 지리적 장소가 포함된 대규모 지리적 영역입니다.

    지역별 제한을 충족하도록 DR 계획을 설계할 때는 머신, 영역, 리전 등 오류가 발생하는 위치에 따라 달라지는 장애 도메인이 정의된 RTO를 충족하는 데 직접적인 영향을 줍니다. 이러한 장애 도메인과 이것이 가용성에 미치는 영향에 대한 자세한 내용은 BigQuery 가용성 및 내구성을 참조하세요.

  • 데이터의 특성. 데이터 웨어하우스에는 과거 정보가 포함되고 이전 데이터는 대부분 정적입니다. 많은 데이터 웨어하우스가 추가 전용으로 설계됩니다. 데이터 웨어하우스가 추가 전용이면 추가되는 데이터만 복원하여 RTO를 달성할 수 있습니다. 이 접근 방법에서는 이 추가 데이터만 백업합니다. 재해가 발생하면 추가된 데이터를 복원하고 데이터 웨어하우스를 사용할 수 있지만 데이터 일부만 가능합니다.

  • 데이터 추가 및 업데이트 패턴. 데이터 웨어하우스는 일반적으로 ETL 또는 ELT 패턴을 사용해서 업데이트됩니다. 업데이트 경로를 제어한 경우 대체 소스로부터 최근 업데이트 이벤트를 재생성할 수 있습니다.

지역별 요구사항에 따라 데이터 웨어하우스에 대해 단일 리전 또는 멀티 리전을 사용할 수 있는지 여부가 제한될 수 있습니다. BigQuery 데이터 세트가 리전별로 존재할 수 있지만 재해 발생 시 데이터 가용성을 보장하기 위해서는 멀티 리전 스토리지가 가장 간단하고 비용 효율적인 방법입니다. 해당 리전에서 멀티 리전 스토리지를 사용할 수 없지만 다른 리전을 사용할 수 있으면 BigQuery Data Transfer Service를 사용해서 데이터 세트를 다른 리전에 복사합니다. 암호화를 사용해서 지역별 요구사항을 완화할 수 있으면 Cloud KMS 및 BigQuery를 사용해서 자체 암호화 키를 관리할 수 있습니다.

리전을 하나만 사용할 수 있으면 BigQuery 테이블 백업을 고려합니다. 테이블 백업을 위한 가장 비용 효율적인 방법은 BigQuery 내보내기를 사용하는 것입니다. Cloud Scheduler 또는 Cloud Composer를 사용해서 Cloud Storage에 기록하는 내보내기 작업을 주기적으로 예약합니다. SNAPPY 압축을 사용하는 Avro 또는 GZIP 압축을 사용하는 JSON과 같은 형식을 사용할 수 있습니다. 내보내기 전략을 설계할 때는 내보내기의 한도에 주의하세요.

또한 Parquet 및 ORC와 같은 열 형식으로 BigQuery 백업을 저장해야 할 수 있습니다. 이 방식은 높은 압축 성능을 제공하며 Hive 및 Presto와 같이 온프레미스 시스템에 사용될 수 있는 많은 오픈소스 엔진과의 상호 운용성을 허용합니다. 다음 다이어그램은 온프레미스 위치의 스토리지에 대해 BigQuery 데이터를 열 형식으로 내보내는 프로세스를 보여줍니다.

재해 복구를 위해 BigQuery 데이터를 열 형식 스토리지로 내보내는 과정을 보여주는 아키텍처 다이어그램입니다.

특히 온프레미스 스토리지 위치로 BigQuery 데이터를 내보내는 프로세스에서는 다음 단계가 수행됩니다.

  • BigQuery 데이터가 Dataproc의 Apache Spark 작업으로 전송됩니다. Apache Spark 작업 사용으로 스키마 개선이 허용됩니다.
  • Dataproc 작업으로 BigQuery 파일이 처리된 다음 처리된 파일이 Cloud Storage에 기록되고 온프레미스 DR 위치로 전송됩니다.
  • Cloud Interconnect를 사용하여 Virtual Private Cloud 네트워크를 온프레미스 네트워크에 연결합니다.
  • 온프레미스 DR 위치로 전송은 Spark 작업을 통해 수행될 수 있습니다.

웨어하우스 설계가 추가 전용이고 날짜별로 분할된 경우 새 테이블에서 BigQuery 내보내기 작업을 실행하기 전 새 테이블에서 필요한 파티션 사본을 만들어야 합니다. 그런 후 gsutil과 같은 도구를 사용해서 업데이트된 파일을 온프레미스 또는 다른 클라우드에 있는 백업 위치로 전송할 수 있습니다. (Google Cloud 외부로 데이터를 전송하면 이그레스 비용이 적용될 수 있습니다.)

예를 들어 현재 상태를 나타내는 파티션에 새 주문이 추가되는 orders 추가 전용 테이블로 구성된 영업 데이터 웨어하우스가 있습니다. 하지만 반품 정책에 따라 물품의 7일내 반품만 허용됩니다. 따라서 orders 테이블에서 이전 7일 이내의 레코드가 업데이트될 수 있습니다. 내보내기 전략에서는 이러한 반품 정책을 고려해야 합니다. 이 예시에서 orders 테이블 백업을 위한 내보내기 작업은 반품으로 인한 업데이트 누락을 방지하기 위해 이전 7일 이내의 주문을 나타내는 파티션도 내보내야 합니다.

다음 단계