Cassandra에서 Spanner로 마이그레이션

프리뷰 — Cassandra

이 기능에는 서비스별 약관의 일반 서비스 약관 항에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

이 페이지에서는 NoSQL 데이터베이스를 Cassandra에서 Spanner로 마이그레이션하는 방법을 설명합니다.

Cassandra와 Spanner 모두 높은 확장성과 짧은 지연 시간이 필요한 애플리케이션을 위해 빌드된 대규모 분산 데이터베이스입니다. 두 데이터베이스 모두 까다로운 NoSQL 워크로드를 지원할 수 있지만 Spanner는 데이터 모델링, 쿼리, 트랜잭션 작업에 사용되는 고급 기능을 제공합니다. Spanner는 Cassandra Query Language(CQL)를 지원합니다.

Spanner가 NoSQL 데이터베이스 기준을 충족하는 방법에 대한 자세한 내용은 비관계형 워크로드용 Spanner를 참조하세요.

마이그레이션 제약조건

Cassandra에서 Spanner의 Cassandra 엔드포인트로 원활하게 마이그레이션하려면 Cassandra 사용자를 위한 Spanner를 검토하여 Spanner 아키텍처, 데이터 모델, 데이터 유형이 Cassandra와 어떻게 다른지 알아보세요. 마이그레이션을 시작하기 전에 Spanner와 Cassandra의 기능적 차이점을 신중하게 고려하세요.

마이그레이션 프로세스

마이그레이션 프로세스는 다음 단계로 구분됩니다.

1. 스키마 및 데이터 모델 변환
2. 수신 데이터의 이중 쓰기 설정
3. Cassandra에서 Spanner로 이전 데이터 일괄 내보내기
4. 데이터를 검증하여 마이그레이션 프로세스 전반에서 데이터 무결성 보장
5. Cassandra 대신 Spanner를 가리키도록 애플리케이션 구성
6. 선택사항입니다. Spanner에서 Cassandra로 역방향 복제 수행

스키마 및 데이터 모델 변환

Cassandra에서 Spanner로 데이터를 마이그레이션하는 첫 번째 단계는 Cassandra 데이터 스키마를 Spanner의 스키마에 맞게 조정하는 동시에 데이터 유형 및 모델링의 차이점을 처리하는 것입니다.

테이블 선언 구문은 Cassandra와 Spanner에서 매우 유사합니다. 테이블 이름, 열 이름, 유형과 행을 고유하게 식별하는 기본 키를 지정합니다. 주요 차이점은 Cassandra는 해시로 파티셔닝되고 파티션 키와 정렬 키를 구분하는 반면 Spanner는 범위로 파티셔닝된다는 점입니다. Spanner는 정렬 키만 있고 파티션은 백그라운드에서 자동으로 유지된다고 생각하면 됩니다. Cassandra와 마찬가지로 Spanner는 복합 기본 키를 지원합니다.

Cassandra 데이터 스키마를 Spanner로 변환하려면 다음 단계를 따르는 것이 좋습니다.

1. Cassandra 개요를 검토하여 Cassandra와 Spanner 데이터 스키마의 유사점과 차이점을 이해하고 다양한 데이터 유형을 매핑하는 방법을 알아봅니다.
2. Spanner to Cassandra 스키마 도구를 사용하여 Cassandra 데이터 스키마를 추출하고 Spanner로 변환합니다.
3. 데이터 마이그레이션을 시작하기 전에 Spanner 테이블이 적절한 데이터 스키마로 생성되었는지 확인합니다.

수신 데이터의 라이브 마이그레이션 설정

Cassandra에서 Spanner로 다운타임 없이 마이그레이션하려면 수신 데이터의 라이브 마이그레이션을 설정합니다. 라이브 마이그레이션은 실시간 복제를 사용하여 다운타임을 최소화하고 애플리케이션의 지속적인 가용성을 보장하는 데 중점을 둡니다.

일괄 마이그레이션 전에 라이브 마이그레이션 프로세스를 시작합니다. 다음 다이어그램은 라이브 마이그레이션의 아키텍처 뷰를 보여줍니다.

라이브 마이그레이션 아키텍처에는 다음과 같은 주요 구성요소가 있습니다.

1. 출처: 소스 Cassandra 데이터베이스.
2. 대상: 마이그레이션하려는 대상 Spanner 데이터베이스. Cassandra 스키마와 호환되는 스키마(Spanner의 데이터 모델 및 기능에 필요한 조정 포함)로 이미 Spanner 인스턴스 및 데이터베이스를 프로비저닝했다고 가정합니다.

3. Datastax ZDM 프록시: ZDM 프록시는 Cassandra에서 Cassandra로의 마이그레이션을 위해 DataStax에서 빌드한 이중 쓰기 프록시입니다. 프록시는 애플리케이션 변경 없이 애플리케이션에서 프록시를 사용할 수 있도록 Cassandra 클러스터를 모방합니다. 이 도구는 애플리케이션이 소스 및 대상 데이터베이스에 이중 쓰기를 수행하기 위해 통신하고 내부적으로 사용하는 도구입니다. 일반적으로 Cassandra 클러스터와 함께 출처 및 대상 모두로 사용되지만, 이 설정에서는 Cassandra-Spanner 프록시(사이드카로 실행)를 대상으로 사용하도록 구성합니다. 이렇게 하면 모든 수신 읽기가 출처로만 전달되고 출처 응답이 애플리케이션으로 다시 반환됩니다. 또한 각 수신 쓰기는 출처와 대상 모두로 전달됩니다.

   • 출처와 대상 모두에 대한 쓰기가 성공하면 애플리케이션에 성공 메시지가 수신됩니다.
   • 출처에 대한 쓰기가 실패하고 대상에 대한 쓰기가 성공하면 애플리케이션에 출처의 실패 메시지가 수신됩니다.
   • 대상에 대한 쓰기가 실패하고 출처에 대한 쓰기가 성공하면 애플리케이션에 대상의 실패 메시지가 수신됩니다.
   • 출처와 대상 모두에 대한 쓰기가 실패하면 애플리케이션에 출처의 실패 메시지가 수신됩니다.

4. Cassandra-Spanner 프록시: Cassandra를 대상으로 하는 Cassandra Query Language(CQL) 트래픽을 가로채고 Spanner API 호출로 변환하는 사이드카 애플리케이션입니다. 이를 통해 애플리케이션과 도구가 Cassandra 클라이언트를 사용하여 Spanner와 상호작용할 수 있습니다.

5. 클라이언트 애플리케이션: 소스 Cassandra 클러스터에서 데이터를 읽고 쓰는 애플리케이션입니다.

프록시 설정

라이브 마이그레이션을 수행하는 첫 번째 단계는 프록시를 배포하고 구성하는 것입니다. Cassandra-Spanner 프록시는 ZDM 프록시의 사이드카로 실행됩니다. 사이드카 프록시는 Spanner에 대한 ZDM 프록시 쓰기 작업의 대상 역할을 합니다.

Docker를 사용한 단일 인스턴스 테스트

Docker를 사용하는 초기 테스트를 위해 프록시의 단일 인스턴스를 로컬로 실행하거나 VM에서 실행할 수 있습니다.

기본 요건

• 프록시가 실행되는 VM에 애플리케이션, 출처 Cassandra 데이터베이스, Spanner 데이터베이스와의 네트워크 연결이 있는지 확인합니다.
• Docker를 설치합니다.
• Spanner 인스턴스 및 데이터베이스에 쓰는 데 필요한 권한이 있는 서비스 계정 키 파일이 있는지 확인합니다.
• Spanner 인스턴스, 데이터베이스, 스키마를 설정합니다.
• Spanner 데이터베이스 이름이 출처 Cassandra 키스페이스 이름과 동일한지 확인합니다.
• Spanner 마이그레이션 도구 저장소를 클론합니다.

ZDM 프록시 다운로드 및 구성

1. sources/cassandra 디렉터리로 이동합니다.
2. entrypoint.sh 및 Dockerfile 파일이 Dockerfile과 동일한 디렉터리에 있는지 확인합니다.

3. 다음 명령어를 실행하여 로컬 이미지를 빌드합니다.

   docker build -t zdm-proxy:latest .
   

ZDM 프록시 실행

1. 다음 명령어가 실행되는 위치에서 로컬로 zdm-config.yaml 및 keyfiles가 있는지 확인합니다.
2. 샘플 zdm-config yaml 파일을 엽니다.
3. ZDM에서 허용하는 자세한 플래그 목록을 검토합니다.

4. 다음 명령어를 사용하여 컨테이너를 실행합니다.

   sudo docker run --restart always  -d -p 14002:14002 \
   -v zdm-config-file-path:/zdm-config.yaml  \
   -v local_keyfile:/var/run/secret/keys.json \
   -e SPANNER_PROJECT=SPANNER_PROJECT_ID \
   -e SPANNER_INSTANCE=SPANNER_INSTANCE_ID \
   -e SPANNER_DATABASE=SPANNER_DATABASE_ID   \
   -e GOOGLE_APPLICATION_CREDENTIALS="/var/run/secret/keys.json" \
   -e ZDM_CONFIG=/zdm-config.yaml \
   zdm-proxy:latest
   

프록시 설정 확인

1. docker logs 명령어를 사용하여 시작 시 프록시 로그에 오류가 있는지 확인합니다.

   docker logs container-id
   

2. cqlsh 명령어를 실행하여 프록시가 올바르게 설정되었는지 확인합니다.

   cqlsh VM-IP 14002
   

   VM-IP를 VM의 IP 주소로 바꿉니다.

Terraform을 사용한 프로덕션 설정:

프로덕션 환경에서는 제공된 Terraform 템플릿을 사용하여 Cassandra-Spanner 프록시 배포를 조정하는 것이 좋습니다.

기본 요건

• Terraform을 설치합니다.
• 애플리케이션에 리소스를 만들 수 있는 적절한 권한이 있는 기본 사용자 인증 정보가 있는지 확인합니다.
• 서비스 키 파일에 Spanner에 쓸 수 있는 관련 권한이 있는지 확인합니다. 이 파일은 프록시에서 사용합니다.
• Spanner 인스턴스, 데이터베이스, 스키마를 설정합니다.
• Dockerfile, entrypoint.sh, 서비스 키 파일이 main.tf 파일과 동일한 디렉터리에 있는지 확인합니다.

Terraform 변수 구성

1. 프록시 배포를 위한 Terraform 템플릿이 있는지 확인합니다.
2. 설정의 변수로 terraform.tfvars 파일을 업데이트합니다.

Terraform을 사용한 템플릿 배포

Terraform 스크립트는 다음을 수행합니다.

• 지정된 수를 기반으로 컨테이너 최적화 VM을 만듭니다.
• 각 VM에 대해 zdm-config.yaml 파일을 만들고 토폴로지 색인을 할당합니다. ZDM 프록시를 사용하려면 구성 yaml 파일의 PROXY_TOPOLOGY_ADDRESSES 및 PROXY_TOPOLOGY_INDEX 필드를 사용하여 토폴로지를 구성하기 위해 멀티 VM 설정이 필요합니다.
• 관련 파일을 각 VM으로 전송하고 Docker 빌드를 원격으로 실행하며 컨테이너를 실행합니다.

템플릿을 배포하려면 다음 단계를 따르세요.

1. terraform init 명령어를 사용하여 Terraform을 초기화합니다.

   terraform init
   

2. terraform plan 명령어를 실행하여 Terraform에서 인프라에 적용할 변경사항을 확인합니다.

   terraform plan -var-file="terraform.tfvars"
   

3. 리소스가 제대로 표시되면 terraform apply 명령어를 실행합니다.

   terraform apply -var-file="terraform.tfvars"
   

4. Terraform 스크립트가 중지되면 cqlsh 명령어를 실행하여 VM에 액세스할 수 있는지 확인합니다.

   cqlsh VM-IP 14002
   

   VM-IP를 VM의 IP 주소로 바꿉니다.

ZDM 프록시를 가리키도록 클라이언트 애플리케이션 구성

클라이언트 애플리케이션의 구성을 수정하여 원본 Cassandra 클러스터 대신 프록시를 실행하는 VM으로 담당자를 설정합니다.

애플리케이션을 철저히 테스트합니다. 쓰기 작업이 출처 Cassandra 클러스터에 모두 적용되고 있는지 확인하고 Spanner 데이터베이스를 확인하여 Cassandra-Spanner 프록시를 사용하여 Spanner에 도달하는지 확인합니다. 읽기는 출처 Cassandra에서 제공됩니다.

Spanner로 데이터 일괄 내보내기

일괄 데이터 마이그레이션은 데이터베이스 간에 대량의 데이터를 전송하는 것을 의미하며, 다운타임을 최소화하고 데이터 무결성을 보장하기 위해 신중하게 계획하고 실행해야 하는 경우가 많습니다. 기법에는 추출, 변환, 로드(ETL) 프로세스, 직접 데이터베이스 복제, 전문 마이그레이션 도구가 포함되며, 모두 데이터의 구조와 정확성을 유지하면서 데이터를 효율적으로 이동하는 것을 목표로 합니다.

Cassandra에서 Spanner로 데이터를 일괄 마이그레이션하려면 Spanner의 SourceDB To Spanner Dataflow 템플릿을 사용하는 것이 좋습니다. Dataflow는 Google Cloud 분산 추출, 변환, 로드(ETL) 서비스로, 데이터 파이프라인을 실행하여 대량의 데이터를 여러 머신에서 동시에 읽고 처리하기 위한 플랫폼을 제공합니다. SourceDB To Spanner Dataflow 템플릿은 Cassandra에서 고도로 병렬화된 읽기를 수행하고, 필요에 따라 소스 데이터를 변환하고, 대상 데이터베이스로 Spanner에 쓰도록 설계되었습니다.

Cassandra 구성 파일을 사용하여 Cassandra에서 Spanner로 일괄 마이그레이션 안내의 단계를 수행합니다.

데이터를 검증하여 무결성 확인

데이터베이스 마이그레이션 중 데이터 검증은 데이터 정확성과 무결성을 보장하는 데 중요합니다. 여기에는 소스 Cassandra와 대상 Spanner 데이터베이스 간의 데이터를 비교하여 누락되거나 손상되었거나 일치하지 않는 데이터와 같은 불일치를 식별하는 작업이 포함됩니다. 일반적인 데이터 검증 기법에는 체크섬, 행 수, 자세한 데이터 비교가 포함되며, 모두 마이그레이션된 데이터가 출처를 정확하게 표현하는지 보장하는 것을 목표로 합니다.

일괄 데이터 마이그레이션이 완료되고 이중 쓰기가 여전히 활성 상태인 동안 데이터 일관성을 검증하고 불일치를 수정해야 합니다. 다음과 같은 여러 가지 이유로 이중 쓰기 단계에서 Cassandra와 Spanner 간에 차이가 발생할 수 있습니다.

• 이중 쓰기 실패. 쓰기 작업이 한 데이터베이스에서는 성공하지만 일시적인 네트워크 문제나 기타 오류로 인해 다른 데이터베이스에서는 실패할 수 있습니다.
• 경량 트랜잭션(LWT). 애플리케이션에서 LWT(비교 및 설정) 작업을 사용하는 경우 데이터 세트의 차이로 인해 한 데이터베이스에서는 성공하지만 다른 데이터베이스에서는 실패할 수 있습니다.
• 단일 기본 키에 대한 높은 초당 쿼리 수(QPS). 동일한 파티션 키에 대한 쓰기 부하가 매우 높은 경우 네트워크 왕복 시간이 다르기 때문에 출처와 대상 간에 이벤트 순서가 다를 수 있으며, 이로 인해 불일치가 발생할 수 있습니다.

• 일괄 작업 및 이중 쓰기가 동시에 실행됨: 이중 쓰기와 동시에 실행되는 일괄 마이그레이션은 다음과 같은 다양한 경합 상태로 인해 차이가 발생할 수 있습니다.

  • Spanner의 추가 행: 이중 쓰기가 활성 상태인 동안 일괄 마이그레이션이 실행되면 애플리케이션에서 일괄 마이그레이션 작업에서 이미 읽고 대상에 쓴 행을 삭제할 수 있습니다.
  • 일괄 쓰기와 이중 쓰기 간의 경합 상태: 이중 쓰기가 완료된 후 수신 쓰기가 Spanner에서 행을 업데이트할 때 일괄 작업이 Cassandra에서 행을 읽고 행의 데이터가 비활성 상태가 되는 기타 경합 상태가 있을 수 있습니다.
  • 부분 열 업데이트: 기존 행에서 열 하위 집합을 업데이트하면 Spanner에 다른 열이 null인 항목이 생성됩니다. 일괄 업데이트는 기존 행을 덮어쓰지 않으므로 Cassandra와 Spanner 간에 행이 나뉘게 됩니다.

이 단계에서는 출처 데이터베이스와 대상 데이터베이스 간의 데이터를 검증하고 조정하는 데 중점을 둡니다. 검증은 출처와 대상을 비교하여 불일치를 식별하는 반면 조정은 이러한 불일치를 해결하여 데이터 일관성을 달성하는 데 중점을 둡니다.

Cassandra와 Spanner 간의 데이터 비교

행 수와 행의 실제 콘텐츠 모두에 대한 검증을 수행하는 것이 좋습니다.

데이터를 비교하는 방법(수 일치 및 행 일치 모두)은 애플리케이션의 데이터 불일치 허용 범위와 정확한 검증 요구사항에 따라 달라집니다.

데이터를 검증하는 방법에는 두 가지가 있습니다.

• 활성 검증은 이중 쓰기가 활성 상태인 경우 수행됩니다. 이 시나리오에서는 데이터베이스의 데이터가 계속 업데이트됩니다. Cassandra와 Spanner 간에 행 수 또는 행 콘텐츠를 정확하게 일치하지 않을 수도 있습니다. 이러한 차이가 나타나는 이유가 다른 오류가 아닌 데이터베이스의 활성 로드로 인한 것인지 확인해야 합니다. 불일치가 이 한도 내에 있으면 컷오버를 진행할 수 있습니다.

• 정적 검증에는 다운타임이 필요합니다. 요구사항에 따라 정확한 데이터 일관성을 보장하는 강력한 정적 검증이 필요한 경우 두 데이터베이스에 대한 모든 쓰기를 일시적으로 중지해야 할 수 있습니다. 그런 다음 Spanner 데이터베이스에서 데이터를 검증하고 차이점을 조정할 수 있습니다.

데이터 일관성과 허용 가능한 다운타임에 대한 구체적인 요구사항에 따라 검증 시기와 적절한 도구를 선택합니다.

Cassandra와 Spanner의 행 수 비교

데이터 검증 방법 중 하나는 소스 데이터베이스와 대상 데이터베이스의 테이블의 행 수를 비교하는 것입니다. 수 검증을 수행하는 방법에는 여러 가지가 있습니다.

• 소규모 데이터 세트(테이블당 1,000만 행 미만)를 마이그레이션하는 경우 이 일치하는 행 수 집계 스크립트를 사용하여 Cassandra와 Spanner의 행 수를 집계할 수 있습니다. 이 접근 방식은 단시간에 정확한 수를 반환합니다. Cassandra의 기본 제한 시간은 10초입니다. 스크립트가 집계를 완료하기 전에 제한 시간이 초과되는 경우 드라이버 요청 제한 시간과 서버 측 제한 시간을 늘리는 것이 좋습니다.

• 대규모 데이터 세트(테이블당 1,000만 행 이상)를 마이그레이션하는 경우 Spanner 집계 쿼리는 확장되지만 Cassandra 쿼리는 제한 시간이 초과되는 경향이 있습니다. 이 경우 DataStax 일괄 로더 도구를 사용하여 Cassandra 테이블에서 행 수를 가져오는 것이 좋습니다. Spanner 집계 시 대부분의 대규모 로드에는 SQL count(*) 함수를 사용하는 것으로 충분합니다. 모든 Cassandra 테이블에 대해 일괄 로더를 실행하고 Spanner 테이블에서 수를 가져와 두 수를 비교하는 것이 좋습니다. 이 작업은 수동으로 수행하거나 스크립트를 사용하여 수행할 수 있습니다.

행 불일치 검증

출처 데이터베이스와 대상 데이터베이스의 행을 비교하여 행 간의 불일치를 식별하는 것이 좋습니다. 행 검증을 수행하는 방법에는 두 가지가 있습니다. 사용하는 방법은 애플리케이션의 요구사항에 따라 다릅니다.

• 무작위 행 세트를 검증합니다.
• 전체 데이터 세트를 검증합니다.

무작위 행 샘플 검증

대규모 워크로드의 경우 전체 데이터 세트를 검증하는 데 많은 비용과 시간이 소요됩니다. 이 경우 샘플링을 사용하여 데이터의 무작위 하위 집합을 검증하여 행의 불일치를 확인할 수 있습니다. 그 방법 중 하나는 Cassandra에서 무작위 행을 선택하고 Spanner에서 해당 행을 가져온 다음 값(또는 행 해시)을 비교하는 것입니다.

이 방법의 장점은 전체 데이터 세트를 확인하는 것보다 더 빠르게 완료할 수 있고 간단하게 실행할 수 있다는 것입니다. 단점은 데이터의 하위 집합이므로 예외적인 상황에서 데이터에 여전히 차이점이 있을 수 있다는 것입니다.

Cassandra에서 무작위 행을 샘플링하려면 다음을 수행해야 합니다.

1. 토큰 범위 [-2^63, 2^63 - 1]에서 난수를 생성합니다.
2. WHERE token(PARTITION_KEY) > GENERATED_NUMBER 행을 가져옵니다.

validation.go 샘플 스크립트는 행을 무작위로 가져와 Spanner 데이터베이스의 행과 비교해 검증합니다.

전체 데이터 세트 검증

전체 데이터 세트를 검증하려면 출처 Cassandra 데이터베이스의 모든 행을 가져옵니다. 기본 키를 사용하여 상응하는 모든 Spanner 데이터베이스 행을 가져옵니다. 그런 다음 행을 비교하여 차이점을 확인할 수 있습니다. 대규모 데이터 세트의 경우 Apache Spark 또는 Apache Beam과 같은 맵리듀스 기반 프레임워크를 사용하여 전체 데이터 세트를 안정적이고 효율적으로 검증할 수 있습니다.

전체 검증의 장점은 데이터 일관성에 대한 신뢰도를 높일 수 있다는 것입니다. 단점은 Cassandra에 읽기 부하가 추가되고 대규모 데이터 세트를 위한 복잡한 도구를 빌드하는 데 투자가 필요하다는 것입니다. 대규모 데이터 세트에 대한 검증을 완료하는 데 훨씬 더 오래 걸릴 수도 있습니다.

이를 수행하는 한 가지 방법은 토큰 범위를 파티션하고 Cassandra 링을 동시에 쿼리하는 것입니다. 각 Cassandra 행의 경우 파티션 키를 사용하여 이에 상응하는 Spanner 행이 가져옵니다. 그런 다음 이 두 행을 비교하여 불일치가 있는지 확인합니다. 검사기 작업을 빌드할 때는 행 일치를 사용하여 Cassandra를 검증하는 데 도움이 되는 팁을 참조하세요.

참고: 이중 쓰기 중에 데이터베이스는 비정적 상태이므로 몇 가지 불일치가 발생할 수 있습니다. 이는 예상되는 불일치입니다.

데이터 또는 행 수 불일치 조정

데이터 일관성 요구사항에 따라 Cassandra에서 Spanner로 행을 복사하여 검증 단계에서 확인된 불일치를 조정할 수 있습니다. 조정을 수행하는 방법 중 하나는 전체 데이터 세트 검증에 사용되는 도구를 확장하고 불일치가 발견되면 Cassandra에서 대상 Spanner 데이터베이스로 올바른 행을 복사하는 것입니다. 자세한 내용은 구현 관련 고려사항을 참조하세요.

Cassandra 대신 Spanner를 가리키도록 애플리케이션 구성

마이그레이션 후 데이터의 정확성과 무결성을 검증하고 나면 Cassandra 대신 Spanner(또는 라이브 데이터 마이그레이션에 사용되는 프록시 어댑터)를 가리키도록 애플리케이션을 마이그레이션할 시간을 선택합니다. 이를 컷오버라고 합니다.

컷오버를 수행하려면 다음 단계를 따르세요.

1. 다음 방법 중 하나를 사용하여 Spanner 인스턴스에 직접 연결할 수 있도록 클라이언트 애플리케이션의 구성을 변경합니다.

   • Cassandra를 사이드카로 실행되는 Cassandra 어댑터에 연결합니다.
   • 드라이버 jar를 엔드포인트 클라이언트로 변경합니다.

2. 이전 단계에서 준비한 변경사항을 적용하여 Spanner를 가리키도록 애플리케이션을 구성합니다.

3. 오류 또는 성능 문제를 모니터링하도록 애플리케이션의 모니터링을 설정합니다. Cloud Monitoring을 사용하여 Spanner 측정항목을 모니터링합니다. 자세한 내용은 Cloud Monitoring으로 인스턴스 모니터링을 참조하세요.

4. 컷오버가 완료되고 안정적으로 작동하면 ZDM 프록시 및 Cassandra-Spanner 프록시 인스턴스를 사용 중단합니다.

Spanner에서 Cassandra로 역방향 복제 수행

Spanner to SourceDB Dataflow 템플릿을 사용하여 역방향 복제를 수행할 수 있습니다. 역방향 복제는 Spanner에 예상치 못한 문제가 발생하여 서비스 중단을 최소화하면서 원래 Cassandra 데이터베이스로 대체해야 하는 경우에 유용합니다.

행 일치를 사용하여 Cassandra를 검증하는 데 도움이 되는 팁

Cassandra(또는 다른 데이터베이스)에서 SELECT *를 사용하여 전체 테이블 스캔을 수행하는 것은 느리고 비효율적입니다. 이 문제를 해결하려면 Cassandra 데이터 세트를 관리 가능한 파티션으로 나누고 파티션을 동시에 처리합니다. 이렇게 하려면 다음 단계를 수행해야 합니다.

1. 데이터 세트를 토큰 범위로 분할
2. 파티션을 동시에 쿼리
3. 각 파티션 내에서 데이터 읽기
4. Spanner에서 해당 행 가져오기
5. 확장성을 위한 검증 도구 설계
6. 불일치 보고 및 로깅

데이터 세트를 토큰 범위로 분할

Cassandra는 파티션 키 토큰을 기반으로 노드에 데이터를 배포합니다. Cassandra 클러스터의 토큰 범위는 -2^63에서 2^63 - 1까지입니다. 크기가 동일한 고정된 수의 토큰 범위를 정의하여 전체 키스페이스를 더 작은 파티션으로 나눌 수 있습니다. 전체 범위를 빠르게 처리하도록 조정할 수 있는 구성 가능한 partition_size 매개변수를 사용하여 토큰 범위를 분할하는 것이 좋습니다.

파티션을 동시에 쿼리

토큰 범위를 정의한 후에는 각각 특정 범위 내에서 데이터를 검증하는 여러 병렬 프로세스 또는 스레드를 실행할 수 있습니다. 각 범위의 경우 파티션 키(pk)에 token() 함수를 사용하여 CQL 쿼리를 구성할 수 있습니다.

지정된 토큰 범위에 대한 샘플 쿼리는 다음과 같습니다.

SELECT *
FROM your_keyspace.your_table
WHERE token(pk) >= <var>partition_min_token</var> AND token(pk) <= <var>partition_max_token</var>;

정의된 토큰 범위를 반복하고 이러한 쿼리를 출처 Cassandra 클러스터(또는 Cassandra에서 읽도록 구성된 ZDM 프록시)에 대해 동시에 실행하면 분산된 방식으로 데이터를 효율적으로 읽을 수 있습니다.

각 파티션 내에서 데이터 읽기

각 병렬 프로세스는 범위 기반 쿼리를 실행하고 Cassandra에서 데이터의 하위 집합을 검색합니다. 병렬 처리와 메모리 사용량 간의 균형을 유지하기 위해 검색된 데이터 파티션의 양을 확인합니다.

Spanner에서 해당 행 가져오기

Cassandra에서 가져온 각 행의 경우 소스 row key를 사용하여 대상 Spanner 데이터베이스에서 해당 행을 검색합니다.

행을 비교하여 불일치 식별

Cassandra 행과 해당 Spanner 행(있는 경우)이 모두 있으면 필드를 비교하여 불일치를 식별해야 합니다. 이 비교에서는 잠재적인 데이터 유형 차이점과 마이그레이션 중에 적용된 변환을 고려해야 합니다. 애플리케이션의 요구사항에 따라 불일치에 대한 명확한 기준을 정의하는 것이 좋습니다.

확장성을 위한 검증 도구 설계

조정을 위해 확장할 수 있는 가능성을 염두에 두고 검증 도구를 설계합니다. 예를 들어 불일치가 식별된 경우 Cassandra에서 Spanner로 올바른 데이터를 쓰는 기능을 추가할 수 있습니다.

불일치 보고 및 로깅

식별된 불일치는 조사 및 조정을 위해 충분한 컨텍스트와 함께 로깅하는 것이 좋습니다. 여기에는 기본 키, 서로 다른 특정 필드, Cassandra와 Spanner의 값 등이 모두 포함될 수 있습니다. 발견된 불일치의 수와 유형에 대한 통계를 집계할 수도 있습니다.

구현 관련 고려사항

• 프레임워크 및 라이브러리: 확장 가능한 커스텀 검증의 경우 Apache Spark 또는 Dataflow(Beam)와 같은 맵리듀스 기반 프레임워크를 사용합니다. 지원되는 언어(Python, Scala, Java)를 선택하고 Cassandra 및 Spanner용 커넥터(예: 프록시 사용)를 사용합니다. 이러한 프레임워크를 사용하면 포괄적인 검증을 위해 대규모 데이터 세트를 효율적으로 병렬 처리할 수 있습니다.
• 오류 처리 및 재시도: 강력한 오류 처리를 구현하여 네트워크 연결 문제 또는 두 데이터베이스 중 하나의 일시적인 사용 불가능 상태와 같은 잠재적인 문제를 관리합니다. 일시적인 실패에 재시도 메커니즘을 구현하는 것이 좋습니다.
• 구성: 토큰 범위, 두 데이터베이스의 연결 세부정보, 비교 로직을 구성 가능하도록 설정합니다.
• 성능 조정: 동시 프로세스 수와 토큰 범위 크기를 실험하여 특정 환경 및 데이터 볼륨에 맞게 검증 프로세스를 최적화합니다. 검증 중에 Cassandra 및 Spanner 클러스터의 부하를 모니터링합니다.

다음 단계

• Cassandra 개요에서 Spanner 및 Cassandra 비교
• Cassandra 어댑터를 사용하여 Spanner에 연결하는 방법 알아보기