Google Cloud 리전 간 마이그레이션: 리전 간 마이그레이션을 위한 데이터 및 일괄 워크로드 준비

Last reviewed 2023-12-08 UTC

이 문서에서는 향후 다른 리전으로의 확장이나 리전 간 마이그레이션으로 인한 영향을 최소화하기 위해 Google Cloud에서 데이터 플랫폼을 설계하는 방법을 설명합니다. 이 문서는 데이터 플랫폼을 다른 리전으로 확장할 때의 영향을 이해하는 데 도움이 되는 시리즈의 일부입니다. 다음 작업을 수행하는 방법을 알아봅니다.

  • 데이터 및 데이터 파이프라인 이동 준비
  • 마이그레이션 단계 중 확인 설정
  • 데이터 스토리지와 데이터 연산을 분리하여 유연한 마이그레이션 전략 생성

이 시리즈의 안내는 리전 간 마이그레이션 또는 여러 리전으로의 확장을 미리 계획하지 않은 경우에도 유용합니다. 이 경우 리전 간에 마이그레이션하고 여러 리전으로 확장할 수 있도록 인프라, 워크로드, 데이터를 준비하기 위한 추가 노력이 필요할 수 있습니다.

이 문서는 다음 시리즈의 일부입니다.

이 문서는 사용자가 다음 문서를 읽고 숙지했다고 가정하고 작성되었습니다.

다음 다이어그램은 마이그레이션 과정을 보여줍니다.

4가지 단계로 구성된 마이그레이션 경로

마이그레이션 단계별로 Google Cloud로 마이그레이션: 시작하기에서 정의된 단계를 수행합니다.

  1. 워크로드 평가 및 검색
  2. 기반 계획 및 구축
  3. 워크로드 배포
  4. 환경 최적화

Google Cloud의 최신 데이터 플랫폼

이 섹션에서는 최신 데이터 플랫폼의 여러 부분과 이러한 요소가 일반적으로 Google Cloud에서 구성되는 방식을 설명합니다. 일반적인 개념으로 사용되는 데이터 플랫폼은 다음 두 가지 섹션으로 나눌 수 있습니다.

  • 데이터 스토리지 레이어는 데이터가 저장되는 위치입니다. 저장할 데이터는 Hadoop 분산 파일 시스템(HDFS) 또는 Cloud Storage와 같은 파일 시스템에서 실제 바이트를 관리하는 파일 형식이거나 도메인별 언어(DSL)를 사용하여 데이터베이스 관리 시스템의 데이터를 관리할 수도 있습니다.
  • 데이터 연산 레이어는 스토리지 시스템 위에서 활성화할 수 있는 모든 데이터 처리입니다. 스토리지 레이어와 마찬가지로 여러 가지 구현이 가능하며, 일부 데이터 스토리지 도구도 데이터 연산을 처리합니다. 플랫폼에서 데이터 연산 레이어의 역할은 스토리지 레이어에서 데이터를 로드하고, 데이터를 처리한 후 대상 시스템에 결과를 저장하는 것입니다. 대상 시스템은 소스 스토리지 레이어일 수 있습니다.

일부 데이터 플랫폼은 데이터 스토리지 레이어에 여러 스토리지 시스템을 사용하고 데이터 처리 레이어에 여러 데이터 연산 시스템을 사용합니다. 대부분의 경우 데이터 스토리지 레이어와 데이터 연산 레이어는 분리됩니다. 예를 들어 다음 Google Cloud 서비스를 사용하여 데이터 스토리지 레이어를 구현했을 수 있습니다.

다음과 같은 다른 Google Cloud 서비스를 사용하여 데이터 연산 레이어를 구현했을 수 있습니다.

통신 시간 및 지연 시간, 아웃바운드 데이터 전송 비용, 스토리지 레이어와 연산 레이어 간의 I/O 작업 수를 줄이려면 데이터를 처리하는 동일한 영역에 저장하는 것이 좋습니다.

또한 데이터 스토리지 레이어를 데이터 연산 레이어와 별도로 유지하는 것이 좋습니다. 이러한 레이어를 별도로 유지하면 연산 레이어를 변경하고 데이터를 마이그레이션할 수 있는 유연성이 향상됩니다. 레이어를 별도로 유지하면 연산 레이어를 항상 실행할 필요가 없으므로 리소스 사용도 줄어듭니다. 따라서 데이터 스토리지와 데이터 연산을 동일한 영역과 리전의 개별 플랫폼에 배포하는 것이 좋습니다. 예를 들어 데이터 스토리지를 HDFS에서 Cloud Storage로 이동하고 연산을 위해 Dataproc 클러스터를 사용할 수 있습니다.

환경 평가

평가 단계에서는 배포한 일괄 데이터 파이프라인을 마이그레이션하기 위한 요구사항과 종속 항목을 결정합니다.

  1. 데이터 파이프라인의 포괄적인 인벤토리를 빌드합니다.
  2. 파이프라인의 속성과 종속 항목에 따라 파이프라인을 분류합니다.
  3. 팀에 Google Cloud 교육을 실시합니다.
  4. Google Cloud에 대한 실험 및 개념 증명을 빌드합니다.
  5. 대상 환경의 총소유비용(TCO)을 계산합니다.
  6. 먼저 마이그레이션할 워크로드를 선택합니다.

평가 단계 및 이러한 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색을 참조하세요. 다음 섹션은 해당 문서의 정보를 기반으로 합니다.

인벤토리 빌드

마이그레이션 범위를 지정하려면 데이터 파이프라인이 배포되는 데이터 플랫폼 환경을 이해해야 합니다.

  1. 데이터 스토리지 및 배치 데이터 처리에 사용하는 스토리지 레이어와 연산 레이어가 서로 다른 데이터 인프라의 인벤토리를 생성합니다.
  2. 마이그레이션이 예약된 데이터 파이프라인의 인벤토리를 만듭니다.
  3. 데이터 파이프라인에서 읽고 마이그레이션해야 하는 데이터 세트의 인벤토리를 만듭니다.

데이터 플랫폼의 인벤토리를 빌드하려면 데이터 인프라의 각 부분에 대해 다음 사항을 고려하세요.

  • 스토리지 레이어. Cloud Storage와 같은 표준 스토리지 플랫폼과 함께 Firebase, BigQuery, Bigtable, Postgres 등의 데이터베이스와 같은 다른 스토리지 레이어나 Apache Kafka 같은 다른 클러스터도 고려합니다. 각 스토리지 플랫폼에는 마이그레이션을 완료하기 위한 자체 전략과 메서드가 있습니다. 예를 들어 Cloud Storage에는 데이터 마이그레이션 서비스가 있고 데이터베이스에는 기본 제공 마이그레이션 도구가 있을 수 있습니다. 데이터 스토리지에 사용 중인 각 제품을 대상 환경에서 사용할 수 있는지, 아니면 호환 가능한 대체 제품이 있는지 확인합니다. 관련된 각 스토리지 플랫폼에 대한 기술 데이터 전송 프로세스를 연습하고 확인합니다.
  • 연산 레이어. 각 연산 플랫폼에 대해 배포 계획을 확인하고 다른 플랫폼에 대해 수행한 구성 변경사항을 확인합니다.
  • 네트워크 지연 시간. 원본 환경과 대상 환경 간의 네트워크 지연 시간을 테스트하고 확인합니다. 데이터를 복사하는 데 걸리는 시간을 이해하는 것이 중요합니다. 또한 원본 환경과 비교하여 클라이언트 및 외부 환경(예: 온프레미스 환경)에서 대상 환경까지의 네트워크 지연 시간을 테스트해야 합니다.

  • 구성 및 배포. 각 데이터 인프라 제품에는 자체 설정 방법이 있습니다. 각 구성요소에 대해 만든 커스텀 구성과 각 플랫폼의 기본 버전(예: Dataproc 버전 또는 Apache Kafka 버전)을 사용하는 구성요소의 인벤토리를 가져옵니다. 이러한 구성을 자동 배포 프로세스의 일부로 배포할 수 있는지 확인합니다.

    특히 마이그레이션 중에 처리 레이어 프레임워크가 변경되는 경우 연산 엔진이 구성된 것과 다르게 동작할 수 있으므로 각 구성요소가 어떻게 구성되는지 알아야 합니다. 예를 들어 대상 환경에서 다른 버전의 Apache Spark를 실행하는 경우 Spark 프레임워크의 일부 구성이 버전 간에 변경되었을 수 있습니다. 이러한 종류의 구성 변경 시 출력, 직렬화, 연산이 변경될 수 있습니다.

    마이그레이션하는 동안 자동화된 배포를 사용하여 버전 및 구성이 동일하게 유지되게 하는 것이 좋습니다. 버전과 구성을 동일하게 유지할 수 없는 경우 프레임워크에서 계산하는 데이터 출력의 유효성을 검사하는 테스트를 실행해야 합니다.

  • 클러스터 크기. 장기 지속 Dataproc 클러스터 또는 Compute Engine에서 실행되는 Apache Kafka 클러스터와 같은 자체 관리형 클러스터의 경우 클러스터의 각 노드에 대한 노드 및 CPU 수와 메모리를 기록합니다. 다른 리전으로 마이그레이션하면 배포에서 사용하는 프로세서가 변경될 수 있습니다. 따라서 마이그레이션된 인프라를 프로덕션에 배포한 후 워크로드를 프로파일링하고 최적화하는 것이 좋습니다. 구성요소가 완전 관리형이거나 서버리스인 경우(예: Dataflow) 크기 조정은 클러스터 자체의 일부가 아니라 각 개별 작업의 일부가 됩니다.

인벤토리에서 평가하는 다음 항목은 데이터 파이프라인에 중점을 둡니다.

  • 데이터 소스 및 싱크. 각 데이터 파이프라인에서 데이터를 읽고 쓰는 데 사용하는 소스 및 싱크를 고려해야 합니다.
  • 서비스수준계약(SLA) 및 서비스 수준 목표(SLO) 일괄 데이터 파이프라인 SLA와 SLO는 일반적으로 완료까지 측정되지만, 사용된 컴퓨팅 성능과 같은 다른 방법으로 측정될 수도 있습니다. 이 비즈니스 메타데이터는 영역 또는 리전 장애가 발생할 경우 가장 중요한 파이프라인의 일부를 다른 리전으로 장애 조치하는 등 비즈니스 연속성 및 재해 복구 계획 프로세스(BCDR)를 추진하는 데 중요합니다.
  • 데이터 파이프라인 종속 항목. 일부 데이터 파이프라인은 다른 데이터 파이프라인에서 생성된 데이터에 의존합니다. 파이프라인을 마이그레이션 스프린트로 분할할 때는 데이터 종속 항목을 고려해야 합니다.
  • 생성 및 사용된 데이터 세트. 각 데이터 파이프라인에 대해 파이프라인에서 사용하는 데이터 세트와 생성하는 데이터 세트를 식별합니다. 이렇게 하면 파이프라인 간, 전체 아키텍처의 다른 시스템 또는 구성요소 간의 종속 항목을 식별하는 데 도움이 됩니다.

인벤토리에서 평가하는 다음 항목은 마이그레이션할 데이터 세트에 중점을 둡니다.

  • 데이터 세트. 대상 환경으로 마이그레이션해야 하는 데이터 세트를 식별합니다. 데이터가 보관처리되고 활발하게 사용되지 않는 경우 일부 과거 데이터가 마이그레이션에 필요하지 않거나 다른 시간에 마이그레이션되는 것으로 생각할 수 있습니다. 마이그레이션 프로세스와 마이그레이션 스프린트에 대한 범위를 정의하여 마이그레이션 관련 위험을 줄일 수 있습니다.
  • 데이터 크기. 파일을 전송하기 전에 압축하려면 압축 전후의 파일 크기를 기록해 둡니다. 데이터 크기는 소스에서 대상으로 데이터를 복사하는 데 필요한 시간과 비용에 영향을 줍니다. 이러한 요소를 고려하면 이 문서의 뒷부분에 설명된 대로 다운타임 전략 중에서 선택하는 데 도움이 됩니다.
  • 데이터 구조. 마이그레이션할 각 데이터 세트를 분류하고 데이터가 정형, 반정형, 비정형인지 알아야 합니다. 데이터 구조를 이해하면 데이터가 올바르고 완전하게 마이그레이션되었는지 확인하는 방법에 대한 전략을 파악할 수 있습니다.

평가 완료

Kubernetes 클러스터 및 워크로드와 관련된 인벤토리를 빌드한 후 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색에서 평가 단계의 나머지 활동을 완료합니다.

기반 계획 및 빌드

Google Cloud로의 마이그레이션 계획 및 빌드 단계는 다음과 같은 작업으로 구성됩니다.

  1. 리소스 계층 구조를 빌드합니다.
  2. Identity and Access Management(IAM) 구성
  3. 결제 설정.
  4. 네트워크 연결을 설정합니다.
  5. 보안을 강화합니다.
  6. 로깅, 모니터링, 알림을 설정합니다.

이러한 각 작업에 대한 자세한 내용은 Google Cloud로 마이그레이션: 기반 구축을 참조하세요.

데이터 및 데이터 파이프라인 마이그레이션

다음 섹션에서는 데이터 및 일괄 데이터 파이프라인 마이그레이션 계획의 일부 측면을 설명합니다. 마이그레이션 계획을 만들 때 이해해야 하는 중요한 데이터 파이프라인의 특성에 대한 몇 가지 개념을 정의합니다. 또한 데이터 마이그레이션에 대한 신뢰도를 높이는 데 도움이 되는 몇 가지 데이터 테스트 개념에 대해서도 설명합니다.

마이그레이션 계획

마이그레이션 계획에 데이터 전송을 완료하는 데 필요한 시간을 포함해야 합니다. 계획 시 네트워크 지연 시간, 데이터 완전성을 테스트하고 마이그레이션에 실패한 데이터를 가져오는 데 필요한 시간 및 네트워크 비용을 고려해야 합니다. 데이터가 한 리전에서 다른 리전으로 복사되므로 네트워크 비용에 대한 계획에는 리전 간 네트워크 비용이 포함되어야 합니다.

여러 파이프라인과 데이터 세트를 스프린트로 분할하고 개별적으로 마이그레이션하는 것이 좋습니다. 이 접근 방식은 각 마이그레이션 스프린트의 위험을 줄이는 데 도움이 되며 각 스프린트를 개선할 수 있게 해줍니다. 마이그레이션 전략을 개선하고 문제를 조기에 발견하려면 더 크고 중요한 워크로드를 마이그레이션하기 전에 더 작고 중요하지 않은 워크로드를 우선적으로 마이그레이션하는 것이 좋습니다.

마이그레이션 계획의 또 다른 중요한 부분은 연산 레이어와 다른 데이터 파이프라인의 전략, 종속성 및 특성을 설명하는 것입니다. 데이터 스토리지 레이어와 데이터 연산 레이어가 동일한 시스템에 빌드된 경우 데이터를 복사하는 동안 시스템 성능을 모니터링하는 것이 좋습니다. 일반적으로 많은 양의 데이터를 복사하면 시스템에 I/O 오버헤드가 발생하고 연산 레이어의 성능이 저하될 수 있습니다. 예를 들어 워크로드를 실행하여 Kafka 클러스터에서 일괄적으로 데이터를 추출하는 경우 대량의 데이터를 읽기 위한 추가 I/O 작업으로 인해 원본 환경에서 여전히 실행 중인 활성 데이터 파이프라인의 성능이 저하될 수 있습니다. 이러한 시나리오에서는 기본 제공 측정항목 또는 커스텀 측정항목을 사용하여 시스템 성능을 모니터링해야 합니다. 시스템에 과부하가 발생하지 않게 하려면 데이터 복사 프로세스 중에 일부 워크로드를 사용 중단하거나 복사 단계를 제한하는 계획을 세우는 것이 좋습니다.

데이터 복사로 인해 마이그레이션이 장기 실행 프로세스가 되므로 마이그레이션 중에 발생할 수 있는 문제를 해결하기 위한 비상 계획을 세우는 것이 좋습니다. 예를 들어 데이터 이동이 예상보다 오래 걸리거나 새 시스템을 온라인 상태로 전환하기 전에 무결성 테스트가 실패하는 경우 롤백할지 아니면 실패한 작업을 수정하고 다시 시도할지 고려하세요. 롤백이 보다 깔끔한 솔루션일 수 있지만 대규모 데이터 세트를 여러 번 복사하는 데 많은 시간과 비용이 소요될 수 있습니다. 어떤 조건에서 어떤 작업을 수행해야 하는지, 패치 생성을 시도하는 데 허용되는 시간, 완전한 롤백을 수행하는 시기를 결정하려면 명확한 이해와 미리 정의된 테스트를 수행하는 것이 좋습니다.

마이그레이션에 사용하는 도구 및 스크립트, 복사 중인 데이터를 구분하는 것이 중요합니다. 데이터 이동을 롤백한다는 것은 데이터를 다시 복사하고 이미 복사한 데이터를 재정의하거나 삭제해야 함을 의미합니다. 도구와 스크립트에 대한 변경사항을 롤백하는 것은 잠재적으로 더 쉽고 비용이 적게 들지만 도구를 변경하면 데이터를 다시 복사해야 할 수 있습니다. 예를 들어 Cloud Storage 위치를 동적으로 생성하는 스크립트에 새 대상 경로를 만드는 경우 데이터를 다시 복사해야 할 수 있습니다. 데이터 재복사를 방지하려면 재개 및 멱등성을 허용하도록 스크립트를 빌드합니다.

데이터 파이프라인 특성

최적의 마이그레이션 계획을 만들려면 여러 데이터 파이프라인의 특성을 이해해야 합니다. 데이터를 쓰는 일괄 파이프라인이 데이터를 읽는 일괄 파이프라인과 다르다는 점에 유의해야 합니다.

  • 데이터를 쓰는 데이터 파이프라인: 소스 시스템의 상태가 변경되므로 데이터를 대상 환경으로 복사하는 동시에 원본 환경에 데이터를 쓰기 어려울 수 있습니다. 데이터를 쓰는 파이프라인의 런타임을 고려하고 전체 프로세스 초기에 마이그레이션 우선순위를 지정합니다. 이렇게 하면 데이터를 읽는 파이프라인을 마이그레이션하기 전에 대상 환경에서 데이터를 준비할 수 있습니다.
  • 데이터를 읽는 데이터 파이프라인: 데이터를 읽는 파이프라인은 데이터 최신 상태에 대한 요구사항이 다를 수 있습니다. 소스 시스템에서 데이터를 생성하는 파이프라인이 중지되면 데이터가 대상 환경으로 복사되는 동안 데이터를 읽는 파이프라인이 실행될 수 있습니다.

데이터는 상태이며, 리전 간 데이터 복사는 원자적 작업이 아닙니다. 따라서 데이터가 복사되는 동안 상태 변경사항을 알고 있어야 합니다.

또한 마이그레이션 계획에서 시스템을 구분하는 것이 중요합니다. 시스템에 따라 다른 기능 및 비기능적 요구사항이 있을 수 있습니다(예: 일괄 처리용 시스템 및 스트리밍용 시스템). 따라서 계획에는 각 시스템을 마이그레이션하기 위한 다양한 전략이 포함되어야 합니다. 시스템 간 종속 항목을 지정하고 마이그레이션 각 단계에서 각 시스템의 다운타임을 줄일 방법을 지정해야 합니다.

마이그레이션 스프린트에 대한 일반적인 계획에는 다음이 포함되어야 합니다.

  • 일반 전략. 이 스프린트에서 마이그레이션을 처리하기 위한 전략을 설명합니다. 일반적인 전략은 워크로드 배포를 참조하세요.
  • 데이터 복사 및 리소스 배포를 위한 도구 및 메서드 목록. 데이터를 복사하거나 대상 환경에 리소스를 배포하는 데 사용할 도구를 지정합니다. 이 목록에는 Cloud Storage 애셋을 복사하는 데 사용되는 커스텀 스크립트, gsutil과 같은 표준 도구 및 마이그레이션 서비스와 같은 Google Cloud 도구가 포함되어야 합니다.
  • 대상 환경에 배포할 리소스 목록. 대상 환경에 배포해야 하는 모든 리소스를 나열합니다. 이 목록에는 Cloud Storage 버킷, BigQuery 데이터 세트 및 Dataproc 클러스터와 같은 모든 데이터 인프라 구성요소가 포함되어야 합니다. 일부 경우 조기 마이그레이션 스프린트에는 더 작은 용량의 크기 조정된 클러스터(예: Dataproc 클러스터) 배포가 포함되며, 이후 스프린트에는 새로운 워크로드에 맞춘 크기 조정이 포함됩니다. 계획에 잠재적인 크기 조정이 포함되어 있는지 확인합니다.
  • 복사할 데이터 세트 목록. 각 데이터 세트에 대해 다음 정보를 지정해야 합니다.
    • 복사 순서(해당하는 경우): 대부분의 전략에서는 작업 순서가 중요합니다. 이 문서의 뒷부분에서 설명하는 예약된 유지보수 전략은 예외에 해당합니다.
    • 크기
    • 주요 통계: 데이터 세트가 성공적으로 복사되었는지 확인하는 데 도움이 되는 행 번호와 같은 주요 통계를 차트로 표시합니다.
    • 복사 예상 시간: 마이그레이션 계획에 따라 데이터 전송을 완료하는 데 걸리는 시간입니다.
    • 복사 방법: 이 문서 앞부분에서 설명한 도구 및 메서드 목록을 참조하세요.
    • 검증 테스트: 데이터가 완전히 복사되었는지 확인하기 위해 완료할 테스트를 명시적으로 나열합니다.
    • 비상 계획: 검증 테스트가 실패할 경우 수행할 작업을 설명합니다. 비상 계획에서는 복사를 재시도하고 재개하거나 공백을 메울 시기, 전체 롤백을 수행하고 전체 데이터 세트를 다시 복사할 시기를 지정해야 합니다.

테스트

이 섹션에서는 계획할 수 있는 일반적인 테스트 유형을 설명합니다. 테스트는 데이터 무결성 및 완전성을 보장하는 데 도움이 될 수 있습니다. 또한 연산 레이어가 예상대로 작동하고 데이터 파이프라인을 실행할 준비가 되었는지 확인하는 데 도움이 될 수 있습니다.

  • 요약 또는 해싱 비교: 데이터를 복사한 후 데이터 완전성을 검증하려면 원본 데이터 세트를 대상 환경의 새 복사본과 비교해야 합니다. 데이터가 BigQuery 테이블 내에 구조화되어 있으면 테이블이 다른 리전에 있으므로 모든 데이터가 있는지 확인하기 위해 두 테이블을 쿼리에 조인할 수 없습니다. 비용 및 지연 시간으로 인해 BigQuery에서는 쿼리가 리전 간에 데이터를 조인하는 것을 허용하지 않습니다. 대신 비교 방법은 각 데이터 세트를 요약하고 결과를 비교해야 합니다. 데이터 세트 구조에 따라 요약 방법이 다를 수 있습니다. 예를 들어 BigQuery 테이블은 집계 쿼리를 사용할 수 있지만 Cloud Storage의 파일 집합은 Spark 파이프라인을 사용하여 각 파일의 해시를 계산한 다음 해시를 집계할 수 있습니다.

  • 카나리아 흐름: 카나리아 흐름은 데이터 무결성 및 완전성을 검증하도록 빌드된 작업을 활성화합니다. 데이터 분석과 같은 비즈니스 사용 사례를 계속 사용하기 전에 카나리아 흐름 작업을 실행하여 입력 데이터가 일련의 기본 요건을 준수하는지 확인하는 것이 좋습니다. 카나리아 흐름을 커스텀 데이터 파이프라인으로 구현하거나 Cloud Composer 기반 DAG의 흐름으로 구현할 수 있습니다. 카나리아 흐름을 통해 특정 필드에 누락된 값이 없는지 확인하거나 특정 데이터 세트의 행 수가 예상 수와 일치하는지 확인하는 등의 작업을 완료하는 데 도움이 됩니다.

    또한 카나리아 흐름을 사용하여 열 또는 데이터 하위 집합의 다이제스트나 기타 집계를 만들 수 있습니다. 그런 다음 카나리아 흐름을 사용하여 데이터를 데이터 사본에서 가져온 유사한 다이제스트 또는 집계와 비교할 수 있습니다.

    카나리아 흐름 메서드는 Cloud Storage 맨 위에 있는 Avro 파일과 같이 파일 형식으로 저장 및 복사되는 데이터의 정확성을 평가해야 하는 경우에 유용합니다. 카나리아 흐름은 일반적으로 새 데이터를 생성하지 않지만 입력 데이터 내에서 일련의 규칙이 충족되지 않으면 실패합니다.

  • 테스트 환경: 마이그레이션 계획을 완료한 후 테스트 환경에서 계획을 테스트해야 합니다. 네트워크를 통해 데이터를 복사하는 데 걸리는 시간을 예측하려면 테스트 환경에 샘플링된 데이터를 복사하거나 다른 리전으로 데이터를 스테이징하는 것이 포함되어야 합니다. 이 테스트는 마이그레이션 계획의 문제를 파악하고 데이터를 성공적으로 마이그레이션할 수 있는지 확인하는 데 도움을 줍니다. 테스트에는 기능 테스트와 비기능적 테스트가 모두 포함되어야 합니다. 기능 테스트는 데이터가 올바르게 마이그레이션되었는지 확인합니다. 비기능 테스트는 마이그레이션이 성능, 보안, 기타 비기능적 요구 사항을 충족하는지 확인합니다. 계획의 각 마이그레이션 단계에는 단계가 완료된 것으로 간주되는 시점을 자세히 설명하는 검증 기준이 포함되어야 합니다.

데이터 검증 도구(DVT)를 사용하여 데이터 검증을 지원할 수 있습니다. 이 도구는 테이블 수준에서 행 수준까지 여러 수준의 데이터 검증 기능을 수행하고 소스 및 대상 시스템의 결과를 비교하는 데 도움이 됩니다.

테스트에서 연산 레이어 배포를 확인하고 복사된 데이터 세트를 테스트해야 합니다. 이를 위한 한 가지 방법은 복사된 데이터 세트의 일부 집계를 계산할 수 있는 테스트 파이프라인을 구성하고 소스 데이터 세트와 대상 데이터 세트가 일치하는지 확인하는 것입니다. 리전 간에 복사하는 파일이 소스 시스템과 대상 시스템 간의 정확한 바이트 복사 표현이 아닌 경우(예: 파일 형식 변경 또는 파일 압축 시) 일반적으로 소스 데이터 세트와 대상 데이터 세트 간 불일치가 발생합니다.

예를 들어 줄바꿈으로 구분된 JSON 파일로 구성된 데이터 세트를 가정해 보겠습니다. 파일은 Cloud Storage 버킷에 저장되며 BigQuery에 외부 테이블로 마운트됩니다. 네트워크를 통해 이동하는 데이터 양을 줄이려면 대상 환경에 파일을 복사하기 전에 마이그레이션의 일부로 Avro 압축을 수행할 수 있습니다. 이 변환에는 여러 이점이 있지만 대상 환경에 기록되는 파일이 원본 환경의 파일 바이트 복사본 표현이 아니므로 몇 가지 위험도 있습니다.

변환 시나리오의 위험을 완화하기 위해 Dataflow 작업을 만들거나 BigQuery를 사용하여 데이터 세트의 일부 집계 및 체크섬 해시를 계산할 수 있습니다(예: 각 숫자 열에 대한 합계, 평균 또는 분위수 계산). 문자열 열의 경우 문자열 길이 상단 또는 해당 문자열의 해시 코드에서 집계를 계산할 수 있습니다. 각 행에 대해 다른 모든 열의 조합에서 집계된 해시를 계산할 수 있으므로 하나의 행이 원래 행과 동일한지 여부를 높은 정확도로 확인할 수 있습니다. 이러한 계산은 원본 환경과 대상 환경 모두에서 수행된 다음 비교됩니다. 예를 들어 데이터 세트가 BigQuery에 저장되어 있는 경우와 같이 원본 환경과 대상 환경이 서로 다른 리전에 있어 테이블을 조인할 수 없으므로 두 환경 모두에 연결할 수 있는 클라이언트를 사용해야 합니다.

이전 테스트 방법을 BigQuery 또는 일괄 작업(예: Dataflow)으로 구현할 수 있습니다. 그런 다음 집계 작업을 실행하고 원본 환경에서 계산된 결과를 대상 환경에서 계산된 결과와 비교할 수 있습니다. 이 방법을 사용하면 데이터가 완전하고 정확한지 확인할 수 있습니다.

연산 레이어를 테스트하는 또 다른 중요한 측면은 모든 종류의 처리 엔진과 연산 방법을 포함하는 파이프라인을 실행하는 것입니다. BigQuery 또는 Dataflow와 같은 관리형 컴퓨팅 엔진에서는 파이프라인 테스트가 덜 중요합니다. 그러나 Dataproc과 같은 비관리형 컴퓨팅 엔진의 경우 파이프라인을 테스트하는 것이 중요합니다. 예를 들어 Apache Spark, Apache Hive, Apache Flink 또는 Apache 맵리듀스와 같은 여러 유형의 연산을 처리하는 Dataproc 클러스터가 있는 경우 각 런타임을 테스트하여 다른 워크로드 유형을 전송할 준비가 되었는지 확인해야 합니다.

마이그레이션 전략

적절한 테스트로 마이그레이션 계획을 확인한 후 데이터를 마이그레이션할 수 있습니다. 데이터를 마이그레이션할 때 여러 워크로드에 대해 다른 전략을 사용할 수 있습니다. 다음은 필요에 따라 그대로 사용하거나 맞춤설정할 수 있는 마이그레이션 전략 예시입니다.

  • 예약된 유지보수: 컷오버 기간이 시작되는 시기를 계획합니다. 이 전략은 데이터를 자주 변경하고 SLO 및 SLA가 다운타임을 견딜 수 있을 때 효과적입니다. 이 전략은 데이터가 복사되는 동안 완전히 비활성 상태가 되므로 전송된 데이터에 대한 높은 신뢰도를 제공합니다. 자세한 내용은 'Google Cloud로 마이그레이션: 대규모 데이터 세트 전송'의 예약된 유지보수를 참조하세요.
  • 읽기 전용 컷오버: 예약된 유지보수 전략의 변형으로, 소스 시스템 데이터 플랫폼에서 데이터 복사 중에 읽기 전용 데이터 파이프라인을 사용하여 데이터를 계속 읽을 수 있도록 합니다. 이 전략은 일부 데이터 파이프라인이 계속 작동하고 최종 시스템에 대한 통계를 제공할 수 있기 때문에 유용합니다. 이 전략의 단점은 소스 데이터가 업데이트되지 않으므로 마이그레이션되는 동안 생성된 데이터가 비활성 상태라는 것입니다. 따라서 최종 시스템의 비활성 데이터를 고려하려면 마이그레이션 이후 따라잡기 전략을 채택해야 할 수도 있습니다.
  • 완전 활성: 원본 환경이 읽기 및 쓰기 데이터 파이프라인 모두에 대해 여전히 활성화되어 있는 동안 특정 타임스탬프에서 데이터를 복사합니다. 데이터를 복사하고 새 배포로 전환한 후 델타 복사 단계를 수행하여 원본 환경에서 마이그레이션 타임스탬프 이후에 생성된 데이터를 가져옵니다. 이 방식은 다른 전략에 비해 더 많은 조정과 고려가 필요합니다. 따라서 마이그레이션 계획에는 소스 데이터에 대해 업데이트 및 삭제 작업을 처리하는 방법이 포함되어야 합니다.
  • 이중 쓰기: 데이터 파이프라인은 데이터가 복사되는 동안 원본 환경과 대상 환경 모두에서 실행할 수 있습니다. 이 전략은 완전 활성 또는 읽기 전용 전략을 사용하는 경우 데이터를 백필하는 데 필요한 델타 복사 단계를 방지합니다. 그러나 데이터 파이프라인이 동일한 결과를 생성하는지 확인하려면 마이그레이션 전에 이중 쓰기 전략에 더 많은 테스트가 필요합니다. 사전 테스트를 수행하지 않으면 분할 브레인 시나리오를 통합하려 할 때 문제가 발생합니다. 이중 쓰기 전략에는 동일한 워크로드를 서로 다른 리전에서 두 번 실행하는 데 필요한 잠재적인 비용이 발생합니다. 이 전략은 다운타임 없이 플랫폼을 마이그레이션할 수 있지만 올바르게 실행하려면 훨씬 많은 조정이 필요합니다.

마이그레이션 후 테스트

마이그레이션이 완료되면 데이터 완전성을 테스트하고 데이터 파이프라인의 유효성을 테스트해야 합니다. 스프린트에서 마이그레이션을 완료하는 경우 각 스프린트 후 이러한 테스트를 수행해야 합니다. 이 단계에서 수행하는 테스트는 통합 테스트와 유사합니다. 즉, 전체 프로덕션 등급의 데이터를 입력으로 사용하여 비즈니스 사용 사례를 실행하는 데이터 파이프라인의 유효성을 테스트한 후 해당 출력의 유효성을 검사합니다. 원본 환경과 대상 환경에서 동일한 데이터 파이프라인을 실행하여 통합 테스트의 출력을 원본 환경의 출력과 비교할 수 있습니다. 이러한 유형의 테스트는 데이터 파이프라인이 확정적이고 두 환경의 입력이 동일한지 확인할 수 있는 경우에만 작동합니다.

원본 환경의 데이터가 대상 환경의 데이터와 동일하거나 충분히 유사한 사전 정의된 기준 집합을 충족할 때 데이터가 완료되었는지 확인할 수 있습니다. 이전 섹션에서 사용한 전략에 따라 데이터가 일대일로 일치하지 않을 수 있습니다. 따라서 사용 사례에 대한 데이터 완전성을 설명하는 기준을 사전 정의해야 합니다. 예를 들어 시계열 데이터의 경우 최신 레코드가 현재 타임스탬프보다 5분 이상 늦으면 데이터가 완료된 것으로 간주할 수 있습니다.

컷오버

대상 환경에서 데이터 및 데이터 파이프라인을 확인하고 테스트한 후 컷오버 단계를 시작할 수 있습니다. 이 단계를 시작하면 클라이언트가 새 시스템을 참조하도록 구성을 변경해야 할 수 있습니다. 일부 경우에는 구성이 소스 시스템을 가리키는 구성과 동일하지 않을 수 있습니다. 예를 들어 서비스가 Cloud Storage 버킷에서 데이터를 읽어야 하는 경우 클라이언트는 사용할 버킷에 대한 구성을 변경해야 합니다. Cloud Storage 버킷 이름은 전역적으로 고유하므로 대상 환경인 Cloud Storage 버킷은 원본 환경과 다릅니다.

컷오버 단계 중에는 원본 환경 워크로드를 사용 중지하고 예약을 취소해야 합니다. 롤백해야 하는 경우를 위해 원본 환경 데이터를 일정 기간 유지하는 것이 좋습니다.

마이그레이션하기 전 테스트 단계는 데이터 파이프라인의 프로덕션 실행 단계만큼 완전하지 않습니다. 따라서 컷오버가 완료되고 대상 시스템이 작동한 후 데이터 파이프라인의 측정항목, 런타임, 시맨틱 출력을 모니터링해야 합니다. 이 모니터링은 테스트 단계에서 놓칠 수 있는 오류를 포착하고 마이그레이션의 성공을 보장하는데 도움이 됩니다.

환경 최적화

최적화는 마이그레이션의 마지막 단계입니다. 이 단계에서는 환경이 최적화 요구사항을 충족할 때까지 반복 가능한 루프를 여러 번 반복 실행하여 환경을 더 효율적으로 만듭니다.

  1. 현재 환경, 팀 및 최적화 루프를 평가합니다.
  2. 최적화 요구사항 및 목표를 설정합니다.
  3. 환경 및 팀을 최적화합니다.
  4. 최적화 루프를 조정합니다.

Google Cloud 환경을 최적화하는 방법에 대한 자세한 내용은 Google Cloud로 마이그레이션: 환경 최적화를 참조하세요.

리전 간 마이그레이션을 위해 Google Cloud 데이터 및 컴퓨팅 리소스 준비하기

이 섹션에서는 Google Cloud의 데이터 및 컴퓨팅 리소스에 대한 개요와 리전 간 마이그레이션을 준비하기 위한 설계 원칙에 대해 설명합니다.

BigQuery

BigQuery는 서버리스 SQL 데이터 웨어하우스이므로 연산 레이어를 배포할 필요가 없습니다. 일부 BigQuery 클라이언트가 처리할 리전을 지정하는 경우 해당 클라이언트를 조정해야 합니다. 그렇지 않으면 BigQuery는 원본 환경과 대상 환경에서 동일합니다. BigQuery 데이터는 두 가지 종류의 테이블에 저장됩니다.

  • BigQuery 테이블: BigQuery 형식의 테이블입니다. BigQuery가 데이터 파일을 관리해 준다는 의미입니다. BigQuery 형식의 데이터 마이그레이션에 대한 자세한 내용은 데이터 세트 관리를 참조하세요.
  • BigQuery 외부 테이블: 데이터가 BigQuery 외부에 저장되는 테이블입니다. 데이터를 이동한 후에는 새 대상에 외부 테이블을 다시 만들어야 합니다. 외부 테이블 마이그레이션에 대한 자세한 내용은 외부 테이블 소개를 참조하세요.

Cloud Storage

Cloud Storage는 데이터를 마이그레이션하는 데 도움이 되는 Storage Transfer Service를 제공합니다.

Dataflow(일괄)

Dataflow는 Google 관리형 데이터 처리 엔진입니다. Dataflow 마이그레이션을 간소화하고 작업이 모든 리전에 쉽게 배포되도록 하려면 모든 입력과 출력을 작업에 매개변수로 삽입해야 합니다. 소스 코드에 입력 및 출력 데이터 위치를 작성하는 대신 Cloud Storage 경로 및 데이터베이스 연결 문자열을 인수 또는 매개변수로 전달하는 것이 좋습니다.

Dataproc

Dataproc은 Apache Hadoop 프레임워크와 호환되는 모든 워크로드를 실행할 수 있는 관리형 Apache Hadoop 환경입니다. Apache Spark, Apache Flink, Apache Hive와 같은 프레임워크와 호환됩니다.

다음과 같은 방법으로 Dataproc을 사용할 수 있습니다. 이 방법은 리전 간에 Dataproc 환경을 마이그레이션하는 방법에 영향을 줍니다.

  • Cloud Storage에 데이터가 있는 임시 클러스터: 클러스터는 특정 작업을 실행하도록 빌드되며 작업이 완료된 후에는 해당 클러스터가 폐기됩니다. 즉, HDFS 레이어 또는 클러스터의 다른 상태도 폐기됩니다. 구성이 다음 기준을 충족하면 이러한 유형을 사용할 때 다른 유형에 비해 마이그레이션이 더 용이합니다.
    • 작업에 대한 입력 및 출력은 소스 코드에서 하드코딩되지 않습니다. 대신 작업에서 입력 및 출력을 인수로 수신합니다.
    • 환경에서 사용 중인 개별 프레임워크에 대한 구성을 포함하여 Dataproc 환경 프로비저닝이 자동화됩니다.
  • 외부 데이터가 있는 장기 실행 클러스터: 하나 이상의 클러스터가 있으며 장기 실행 클러스터입니다. 클러스터에 실행 중인 작업이 없더라도 클러스터가 계속 실행 중입니다. 데이터가 Cloud Storage 또는 BigQuery와 같은 Google Cloud 솔루션의 클러스터 외부에 저장되므로 데이터와 컴퓨팅이 별개입니다. 이 모델은 일반적으로 클러스터에서 상시 실행 중인 작업이 있을 때 효과적이므로 임시 모델에서와 같이 클러스터를 분리하고 설정하는 것은 의미가 없습니다. 데이터와 컴퓨팅이 별개이므로 마이그레이션은 임시 모델의 마이그레이션과 유사합니다.
  • 클러스터에 데이터가 있는 장기 실행 클러스터: 클러스터는 수명이 길지만 클러스터 내부의 상태, 데이터 또는 둘 모두를 유지하며 가장 일반적으로 HDFS의 데이터로 사용됩니다. 이러한 사용 유형으로 인해 데이터와 컴퓨팅이 분리되지 않기 때문에 마이그레이션 작업이 복잡해지며, 데이터 또는 컴퓨팅 없이 마이그레이션할 경우 불일치가 발생할 위험이 높습니다. 이 시나리오에서는 마이그레이션하기 전에 데이터와 상태를 클러스터 외부로 이동하여 둘을 분리하는 것이 좋습니다. 그렇게 할 수 없는 경우 데이터 불일치를 일으킬 위험을 줄이기 위해 예약된 유지보수 전략을 사용하는 것이 좋습니다.

잠재적 프레임워크가 많고 이러한 프레임워크의 버전 및 구성이 많으므로 마이그레이션 계획을 실행하기 전에 철저하게 테스트해야 합니다.

Cloud Composer

Cloud Composer는 흐름 조정 및 예약을 위한 Apache Airflow의 Google Cloud 관리형 버전입니다. DAG, 구성 및 로그는 Cloud Composer 배포로 마이그레이션되어야 하는 Cloud Storage 버킷에서 관리됩니다. Cloud Composer 배포 상태를 마이그레이션하려면 환경 스냅샷을 저장하고 로드하면 됩니다.

Cloud Composer 인스턴스에 커스텀 플러그인을 배포한 경우 코드형 인프라 방법론을 적용하여 환경을 완전히 자동화된 방식으로 다시 생성하는 것이 좋습니다.

Cloud Composer는 데이터를 관리하지 않지만 다른 데이터 처리 프레임워크 및 플랫폼을 활성화합니다. 따라서 Cloud Composer의 마이그레이션은 데이터에서 완전히 격리될 수 있습니다. 또한 Cloud Composer는 데이터를 처리하지 않으므로 배포가 데이터와 동일한 리전에 있을 필요가 없습니다. 따라서 대상 환경에서 Cloud Composer 배포를 만들고 여전히 원본 환경에서 파이프라인을 실행할 수 있습니다. 경우에 따라 전체 플랫폼이 마이그레이션되는 동안 서로 다른 리전에서 서로 다른 파이프라인을 운영하는 데 유용할 수 있습니다.

Cloud Data Fusion

Cloud Data Fusion은 비주얼 편집기를 사용하여 데이터 파이프라인을 빌드하는 데 도움이 되는 시각적 통합 도구입니다. Cloud Data Fusion은 오픈소스 프로젝트 CDAP를 기반으로 합니다. Cloud Composer와 마찬가지로 Cloud Data Fusion은 데이터 자체를 관리하지 않지만 다른 데이터 처리 프레임워크 및 플랫폼을 활성화합니다. 다음 방법 중 하나를 사용하여 Cloud Data Fusion 파이프라인을 원본 환경에서 내보내고 대상 환경으로 가져와야 합니다.

마이그레이션해야 하는 흐름의 양에 따라 다른 방법보다 그 어떤 한 가지 방법을 선호할 수 있습니다. CDAP API를 사용하여 마이그레이션 스크립트를 빌드하는 것이 어려울 수 있으며 더 많은 소프트웨어 엔지니어링 기술이 필요합니다. 하지만 흐름이 많거나 흐름이 비교적 자주 변경되는 경우 자동화된 프로세스가 가장 좋은 방법일 수 있습니다.

다음 단계

참여자

저자:

기타 참여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.