듀얼 쓰기 프록시를 사용하여 Cassandra에서 Bigtable로 마이그레이션

듀얼 쓰기 프록시를 사용하여 Cassandra에서 Bigtable로 마이그레이션

이 Codelab 정보

subject최종 업데이트: 4월 15, 2025
account_circle작성자: Louis Cheynel

1. 소개

Bigtable은 대규모 분석 및 운영 워크로드를 위해 설계된 완전 관리형 고성능 NoSQL 데이터베이스 서비스입니다. Apache Cassandra와 같은 기존 데이터베이스에서 Bigtable로 마이그레이션하려면 다운타임과 애플리케이션 영향을 최소화하기 위해 신중하게 계획해야 하는 경우가 많습니다.

이 Codelab에서는 프록시 도구 조합을 사용하여 Cassandra에서 Bigtable로의 마이그레이션 전략을 보여줍니다.

  1. Cassandra-Bigtable 프록시: Cassandra 클라이언트와 도구 (예: cqlsh 또는 드라이버)가 쿼리를 변환하여 Cassandra 쿼리 언어 (CQL) 프로토콜을 사용하여 Bigtable과 상호작용할 수 있도록 합니다.
  2. Datastax Zero Downtime Migration (ZDM) 프록시: 애플리케이션과 데이터베이스 서비스 (Cassandra-Bigtable 프록시를 통한 원본 Cassandra 및 대상 Bigtable) 사이에 있는 오픈소스 프록시입니다. 이 도구는 이중 쓰기를 조정하고 트래픽 라우팅을 관리하여 최소한의 애플리케이션 변경과 다운타임으로 이전할 수 있도록 지원합니다.
  3. Cassandra Data Migrator (CDM): 소스 Cassandra 클러스터에서 대상 Bigtable 인스턴스로 이전 데이터를 일괄적으로 이전하는 데 사용되는 오픈소스 도구입니다.

학습할 내용

  • Compute Engine에서 기본 Cassandra 클러스터를 설정하는 방법
  • Bigtable 인스턴스를 만드는 방법
  • Cassandra 스키마를 Bigtable에 매핑하도록 Cassandra-Bigtable 프록시를 배포하고 구성하는 방법
  • 이중 쓰기를 위해 Datastax ZDM 프록시를 배포하고 구성하는 방법
  • Cassandra Data Migrator 도구를 사용하여 기존 데이터를 일괄 마이그레이션하는 방법
  • 프록시 기반 Cassandra-to-Bigtable 마이그레이션의 전반적인 워크플로

필요한 항목

  • 결제가 사용 설정된 Google Cloud 프로젝트. 신규 사용자는 무료 체험판을 이용할 수 있습니다.
  • 프로젝트, Compute Engine, VPC 네트워크, 방화벽 규칙과 같은 Google Cloud 개념에 대한 기본적인 지식 Linux 명령줄 도구에 대한 기본적인 지식
  • gcloud CLI가 설치되고 구성된 머신에 액세스하거나 Google Cloud Shell을 사용합니다.

이 Codelab에서는 네트워킹을 간소화하기 위해 동일한 VPC 네트워크 및 리전 내의 Compute Engine 가상 머신 (VM)을 주로 사용합니다. 내부 IP 주소를 사용하는 것이 좋습니다.

2. 환경 설정

1. Google Cloud 프로젝트 선택 또는 만들기

Google Cloud 콘솔로 이동하여 기존 프로젝트를 선택하거나 새 프로젝트를 만듭니다. 프로젝트 ID를 기록해 둡니다.

2. 필요한 API 사용 설정

프로젝트에 Compute Engine API 및 Bigtable API가 사용 설정되어 있는지 확인합니다.

gcloud services enable compute.googleapis.com bigtable.googleapis.com bigtableadmin.googleapis.com --project=<your-project-id>

를 실제 프로젝트 ID로 바꿉니다.

3. 리전 및 영역 선택

리소스의 리전 및 영역을 선택합니다. us-central1 및 us-central1-c를 예로 들겠습니다. 편의를 위해 다음을 환경 변수로 정의합니다.

export PROJECT_ID="<your-project-id>"
export REGION="us-central1"
export ZONE="us-central1-c"

gcloud config set project $PROJECT_ID
gcloud config set compute/region $REGION
gcloud config set compute/zone $ZONE

4. 방화벽 규칙 구성

기본 VPC 네트워크 내의 여러 포트에서 VM 간의 통신을 허용해야 합니다.

  • Cassandra/프록시 CQL 포트: 9042
  • ZDM 프록시 상태 점검 포트: 14001
  • SSH: 22

이러한 포트에서 내부 트래픽을 허용하는 방화벽 규칙을 만듭니다. 태그 cassandra-migration를 사용하여 이 규칙을 관련 VM에 쉽게 적용합니다.

gcloud compute firewall-rules create allow-migration-internal \
--network=default \
--action=ALLOW \
--rules=tcp:22,tcp:9042,tcp:14001 \
--source-ranges=10.128.0.0/9 # Adjust if using a custom VPC/IP range \
--target-tags=cassandra-migration

3. Cassandra 클러스터 배포 (Origin)

이 Codelab에서는 Compute Engine에 간단한 단일 노드 Cassandra 클러스터를 설정합니다. 실제 시나리오에서는 기존 클러스터에 연결합니다.

1. Cassandra용 GCE VM 만들기

gcloud compute instances create cassandra-origin \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

2. Cassandra 설치

# Install Java (Cassandra dependency)
sudo apt-get update
sudo apt-get install -y openjdk-11-jre-headless

# Add Cassandra repository
echo "deb [https://debian.cassandra.apache.org](https://debian.cassandra.apache.org) 41x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl [https://downloads.apache.org/cassandra/KEYS](https://downloads.apache.org/cassandra/KEYS) | sudo apt-key add -

# Install Cassandra
sudo apt-get update
sudo apt-get install -y cassandra

3. 키스페이스 및 테이블 만들기

직원 테이블 예시를 사용하고 'zdmbigtable'이라는 키스페이스를 만듭니다.

cd ~/apache-cassandra
bin/cqlsh <your-localhost-ip? 9042  #starts the cql shell

cqlsh 내부:

-- Create keyspace (adjust replication for production)
CREATE KEYSPACE zdmbigtable WITH replication = {'class':'SimpleStrategy', 'replication_factor':1};

-- Use the keyspace
USE zdmbigtable;

-- Create the employee table
CREATE TABLE employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

-- Exit cqlsh
EXIT;

SSH 세션을 열어 두거나 이 VM의 IP 주소 (hostname -I)를 기록해 둡니다.

4. Bigtable 설정 (타겟)

길이 0:01

Bigtable 인스턴스를 만듭니다. zdmbigtable을 인스턴스 ID로 사용합니다.

gcloud bigtable instances create zdmbigtable \ 
--display-name="ZDM Bigtable Target" \ 
--cluster=bigtable-c1 \ 
--cluster-zone=$ZONE \ 
--cluster-num-nodes=1 # Use 1 node for dev/testing; scale as needed

Bigtable 테이블 자체는 나중에 Cassandra-Bigtable 프록시 설정 스크립트에 의해 생성됩니다.

5. Cassandra-Bigtable 프록시 설정

1. Cassandra-Bigtable 프록시용 Compute Engine VM 만들기

gcloud compute instances create bigtable-proxy-vm \ 
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

bigtable-proxy-vm에 SSH를 통해 연결합니다.

gcloud compute ssh bigtable-proxy-vm

VM 내에서:

# Install Git and Go
sudo apt-get update
sudo apt-get install -y git golang-go

# Clone the proxy repository
# Replace with the actual repository URL if different
git clone https://github.com/GoogleCloudPlatform/cloud-bigtable-ecosystem.git
cd cassandra-to-bigtable-proxy/

# Set Go environment variables
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin

2. 프록시 구성

nano config.yaml

다음 변수를 업데이트합니다. 고급 구성의 경우 GitHub에 제공된 이 예시를 사용하세요.

#!/bin/bash
cassandraToBigtableConfigs
:
  # Global default GCP Project ID
  projectId: <your-project-id>

listeners
:
- name: cluster1
  port: 9042
  bigtable:
    #If you want to use multiple instances then pass the instance names by comma seperated
    #Instance name should not contain any special characters except underscore(_)
    instanceIds: zdmbigtable

    # Number of grpc channels to be used for Bigtable session.
    Session:
      grpcChannels: 4

otel
:
  # Set enabled to true or false for OTEL metrics/traces/logs.
  enabled: False

  # Name of the collector service to be setup as a sidecar
  serviceName: cassandra-to-bigtable-otel-service

  healthcheck:
    # Enable the health check in this proxy application config only if the
    # "health_check" extension is added to the OTEL collector service configuration.
    #
    # Recommendation:
    # Enable the OTEL health check if you need to verify the collector's availability
    # at the start of the application. For development or testing environments, it can
    # be safely disabled to reduce complexity.

    # Enable/Disable Health Check for OTEL, Default 'False'.
    enabled: False
    # Health check endpoint for the OTEL collector service
    endpoint: localhost:13133
  metrics:
    # Collector service endpoint
    endpoint: localhost:4317

  traces:
    # Collector service endpoint
    endpoint: localhost:4317
    #Sampling ratio should be between 0 and 1. Here 0.05 means 5/100 Sampling ratio.
    samplingRatio: 1

loggerConfig
:
  # Specifies the type of output, here it is set to 'file' indicating logs will be written to a file.
  # Value of `outputType` should be `file` for file type or `stdout` for standard output.
  # Default value is `stdout`.
  outputType: stdout
  # Set this only if the outputType is set to `file`.
  # The path and name of the log file where logs will be stored. For example, output.log, Required Key.
  # Default `/var/log/cassandra-to-spanner-proxy/output.log`.
  fileName: output/output.log
  # Set this only if the outputType is set to `file`.
  # The maximum size of the log file in megabytes before it is rotated. For example, 500 for 500 MB.
  maxSize: 10
  # Set this only if the outputType is set to `file`.
  # The maximum number of backup log files to keep. Once this limit is reached, the oldest log file will be deleted.
  maxBackups: 2
  # Set this only if the outputType is set to `file`.
  # The maximum age in days for a log file to be retained. Logs older than this will be deleted. Required Key.
  # Default 3 days
  maxAge: 1

  # Set this only if the outputType is set to `file`.
  # Default value is set to 'False'. Change the value to 'True', if log files are required to be compressed.
  compress: True

파일을 저장하고 닫습니다 (nano에서 ctrl+X, Y, Enter).

3. Cassandra-Bigtable 프록시 시작

프록시 서버를 시작합니다.

# At the root of the cassandra-to-bigtable-proxy directory
go run proxy.go

프록시는 포트 9042에서 수신 대기하고 들어오는 CQL 연결을 시작합니다. 이 터미널 세션을 실행 상태로 유지합니다. 이 VM의 IP 주소를 확인합니다 (호스트 이름 -I).

4. CQL을 통한 테이블 만들기

cqlsh를 Cassandra-Bigtable 프록시 VM의 IP 주소에 연결합니다.

cqlsh에서 다음 명령어를 실행합니다.

-- Create the employee table
CREATE TABLE zdmbigtable.employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

Google Cloud 콘솔에서 Bigtable 인스턴스에 직원 테이블과 메타데이터 테이블이 있는지 확인합니다.

6. ZDM 프록시 설정

ZDM 프록시에는 트래픽을 처리하는 프록시 노드 1대 이상과 Ansible을 통한 배포 및 오케스트레이션에 사용되는 'Jumphost' 등 두 대 이상의 머신이 필요합니다.

1. ZDM 프록시용 Compute Engine VM 만들기

zdm-proxy-jumphost 및 zdm-proxy-node-1이라는 두 개의 VM이 필요합니다.

# Jumphost VM 
gcloud compute instances create zdm-jumphost \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

# Proxy Node VM 
gcloud compute instances create zdm-proxy-node-1 \
--machine-type=e2-standard-8 \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

두 VM의 IP 주소를 확인합니다.

2. 점프 호스트 준비

zdm-jumphost에 SSH 연결

gcloud compute ssh zdm-jumphost
# Install Git and Ansible

sudo apt
-get update
sudo apt
-get install -y git ansible

점프 호스트 내부

git clone https:\/\/github.com/datastax/zdm-proxy-automation.git 

cd zdm
-proxy-automation/ansible/

기본 구성 파일 vars/zdm_proxy_cluster_config.yml을 수정합니다.

origin_contact_points 및 target_contact_points를 각각 Cassandra VM 및 Cassandra-Bigtable 프록시 VM의 내부 IP 주소로 업데이트합니다. 인증은 설정하지 않았으므로 주석 처리된 상태로 둡니다.

##############################
#### ORIGIN CONFIGURATION ####
##############################
## Origin credentials (leave commented if no auth)
# origin_username: ...
# origin_password: ...

## Set the following two parameters only if Origin is a self-managed, non-Astra cluster
origin_contact_points
: <Your-Cassandra-VM-Internal-IP> # Replace!
origin_port
: 9042

##############################
#### TARGET CONFIGURATION ####
##############################
## Target credentials (leave commented if no auth)
# target_username: ...
# target_password: ...

## Set the following two parameters only if Target is a self-managed, non-Astra cluster
target_contact_points
: <Your-Bigtable-Proxy-VM-Internal-IP> # Replace!
target_port
: 9042

# --- Other ZDM Proxy settings can be configured below ---
# ... (keep defaults for this codelab)

이 파일을 저장하고 닫습니다.

3. Ansible을 사용하여 ZDM 프록시 배포

점프호스트의 ansible 디렉터리에서 Ansible 플레이북을 실행합니다.

ansible-playbook deploy_zdm_proxy.yml -i zdm_ansible_inventory

이 명령어는 프록시 노드 (zdm-proxy-node-1)에 필요한 소프트웨어 (예: Docker)를 설치하고, ZDM 프록시 Docker 이미지를 가져오고, 제공된 구성으로 프록시 컨테이너를 시작합니다.

4. ZDM 프록시 상태 확인

점프 호스트에서 zdm-proxy-node-1 (포트 14001)에서 실행 중인 ZDM 프록시의 준비 상태 엔드포인트를 확인합니다.

# Replace <zdm-proxy-node-1-internal-ip> with the actual internal IP.
curl
-G http://<zdm-proxy-node-1-internal-ip>:14001/health/readiness

출력에 출처 (Cassandra)와 대상 (Cassandra-Bigtable 프록시)이 모두 UP 상태임을 나타내는 다음과 유사한 출력이 표시됩니다.

{
 
"OriginStatus": {
   
"Addr": "<Your-Cassandra-VM-Internal-IP>:9042",
   
"CurrentFailureCount": 0,
   
"FailureCountThreshold": 1,
   
"Status": "UP"
 
},
 
"TargetStatus": {
   
"Addr": "<Your-Bigtable-Proxy-VM-Internal-IP>:9042",
   
"CurrentFailureCount": 0,
   
"FailureCountThreshold": 1,
   
"Status": "UP"
 
},
 
"Status": "UP"
}

7. 애플리케이션 구성 및 이중 쓰기 시작

길이 0:05

실제 이전의 이 단계에서는 ZDM 프록시 노드의 IP 주소(예: :9042)에 연결합니다.

애플리케이션이 ZDM 프록시에 연결되면 기본적으로 원본 (Cassandra)에서 읽기가 제공됩니다. 쓰기는 출처 (Cassandra)와 대상 (Cassandra-Bigtable 프록시를 통한 Bigtable) 모두로 전송됩니다. 이렇게 하면 애플리케이션이 정상적으로 계속 작동하는 동시에 새 데이터가 두 데이터베이스에 동시에 쓰여집니다. 점프 호스트 또는 네트워크의 다른 VM에서 ZDM 프록시를 가리키는 cqlsh를 사용하여 연결을 테스트할 수 있습니다.

Cqlsh <zdm-proxy-node-1-ip-address> 9042

데이터를 삽입해 보세요.

INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alice', 30, true); 
SELECT * FROM employee WHERE name = 'Alice';

이 데이터는 Cassandra와 Bigtable 모두에 작성해야 합니다. Bigtable에서 Google Cloud 콘솔로 이동하여 인스턴스의 Bigtable 쿼리 편집기를 열면 이를 확인할 수 있습니다. 'SELECT * FROM employee' 쿼리를 실행하면 최근에 삽입된 데이터가 표시됩니다.

8. Cassandra Data Migrator를 사용하여 이전 데이터 마이그레이션

이제 새 데이터에 이중 쓰기가 활성화되었으므로 Cassandra Data Migrator (CDM) 도구를 사용하여 Cassandra에서 Bigtable로 기존의 이전 데이터를 복사합니다.

1. CDM용 Compute Engine VM 만들기

이 VM에는 Spark를 위한 충분한 메모리가 필요합니다.

gcloud compute instances create cdm-migrator-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=40GB

2. 기본 요건 (Java 11, Spark) 설치

cdm-migrator-vm에 SSH를 통해 연결합니다.

gcloud compute ssh cdm-migrator-vm

VM 내에서:

# Install Java 11 
sudo apt-get update
sudo apt-get install -y openjdk-11-jdk
 
# Verify Java installation
java -version

# Download and Extract Spark (Using version 3.5.3 as requested)
# Check the Apache Spark archives for the correct URL if needed

wget  [https://archive.apache.org/dist/spark/spark-3.5.3/spark-3.5.3-bin-hadoop3-scala2.13.tgz](https://archive.apache.org/dist/spark/spark-3.5.3/spark-3.5.3-bin-hadoop3-scala2.13.tgz) tar -xvzf spark-3.5.3-bin-hadoop3-scala2.13.tgz
 
export SPARK_HOME=$PWD/spark-3.5.3-bin-hadoop3-scala2.13
export PATH=$PATH:$SPARK_HOME/bin

3. Cassandra Data Migrator 다운로드

CDM 도구 jar 파일을 다운로드합니다. Cassandra Data Migrator GitHub 출시 페이지에서 원하는 버전의 올바른 URL을 확인합니다.

# Example using version 5.2.2 - replace URL if needed
wget https://github.com/datastax/cassandra-data-migrator/releases/download/v5.2.2/cassandra-data-migrator-5.2.2.jar)

4. CDM 구성

cdm.properties라는 속성 파일을 만듭니다.

Nano cdm.properties

다음 구성을 붙여넣고 IP 주소를 바꾸고 TTL/Writetime 기능을 사용 중지합니다. Bigtable에서 동일한 방식으로 직접 지원하지 않기 때문입니다. auth는 주석 처리된 상태로 둡니다.

# Origin Cassandra Connection 
spark
.cdm.connect.origin.host <Your-Cassandra-VM-IP-Address> # Replace!
spark
.cdm.connect.origin.port 9042
spark
.cdm.connect.origin.username cassandra # Leave default, or set if auth is enabled #
spark
.cdm.connect.origin.password cassandra # Leave default, or set if auth is enabled #

# Target Bigtable (via Cassandra-Bigtable Proxy)
Connection spark.cdm.connect.target.host <Your-Bigtable-Proxy-VM-IP-Address> # Replace!
spark
.cdm.connect.target.port 9042
spark
.cdm.connect.target.username cassandra # Leave default, or set if auth is enabled #
spark
.cdm.connect.target.password cassandra # Leave default, or set if auth is enabled #

# Disable TTL/Writetime features (Important for Bigtable compatibility via Proxy)
spark
.cdm.feature.origin.ttl.automatic false
spark
.cdm.feature.origin.writetime.automatic false
spark
.cdm.feature.target.ttl.automatic false
spark
.cdm.feature.target.writetime.automatic false

파일을 저장하고 닫습니다.

5. 마이그레이션 작업 실행

spark-submit을 사용하여 마이그레이션을 실행합니다. 이 명령어는 Spark에 속성 파일을 사용하고 마이그레이션할 키스페이스와 테이블을 지정하여 CDM jar를 실행하도록 지시합니다. VM 크기와 데이터 양에 따라 메모리 설정 (–driver-memory, –executor-memory)을 조정합니다.

CDM jar 및 속성 파일이 포함된 디렉터리에 있는지 확인합니다. 다른 버전을 다운로드한 경우 'cassandra-data-migrator-5.2.2.jar'를 교체합니다.

./spark-3.5.3-bin-hadoop3-scala2.13/bin/spark-submit \ --properties-file cdm.properties \ --master "local[*]" \ --driver-memory 4G \ --executor-memory 4G \ --class com.datastax.cdm.job.Migrate \ cassandra-data-migrator-5.2.2.jar &> cdm_migration_$(date +%Y%m%d_%H%M).log

마이그레이션은 백그라운드에서 실행되며 로그는 cdm_migration_...에 작성됩니다. .log. 로그 파일에서 진행 상황과 오류를 모니터링합니다.

tail -f cdm_migration_*.log

6. 데이터 마이그레이션 확인

CDM 작업이 완료되면 Bigtable에 이전 데이터가 있는지 확인합니다. Cassandra-Bigtable 프록시에서 CQL 읽기를 허용하므로 이전 후 읽기를 타겟으로 라우트하거나 그렇게 구성할 수 있는 ZDM 프록시에 연결된 cqlsh 또는 Cassandra-Bigtable 프록시에 직접 연결된 cqlsh를 다시 사용하여 데이터를 쿼리할 수 있습니다. ZDM 프록시를 통해 연결:

cqlsh <zdm-proxy-node-1-ip-address> 9042

cqlsh 내부:

SELECT COUNT(*) FROM zdmbigtable.employee; -- Check row count matches origin 
SELECT * FROM employee LIMIT 10; -- Check some sample data

또는 cbt 도구 (CDM VM 또는 Cloud Shell에 설치된 경우)를 사용하여 Bigtable에서 직접 데이터를 조회할 수 있습니다.

# First, install cbt if needed
# gcloud components update
# gcloud components install cbt

# Then lookup a specific row (replace 'some_employee_name' with an actual primary key)
cbt
-project $PROJECT_ID -instance zdmbigtable lookup employee some_employee_name

9. 컷오버 (개념적)

Cassandra와 Bigtable 간의 데이터 일관성을 철저히 확인한 후 최종 컷오버를 진행할 수 있습니다.

ZDM 프록시를 사용하면 전환 시 출처 (Cassandra) 대신 대상 (Bigtable)에서 주로 읽도록 재구성해야 합니다. 이는 일반적으로 ZDM 프록시 구성을 통해 이루어지며, 애플리케이션의 읽기 트래픽을 Bigtable로 효과적으로 전환합니다.

Bigtable이 모든 트래픽을 올바르게 제공한다고 확신하면 다음 작업을 수행할 수 있습니다.

  • ZDM 프록시를 재구성하여 이중 쓰기를 중지합니다.
  • 원래 Cassandra 클러스터를 사용 중단합니다.
  • ZDM 프록시를 삭제하고 애플리케이션을 Cassandra-Bigtable 프록시에 직접 연결하거나 Java용 네이티브 Bigtable CQL 클라이언트를 사용하세요.

전환을 위한 ZDM 프록시 재구성의 세부정보는 이 기본 Codelab의 범위를 벗어나지만 Datastax ZDM 문서에 자세히 설명되어 있습니다.

10. 삭제

요금이 청구되지 않도록 이 Codelab에서 만든 리소스를 삭제합니다.

1. Compute Engine VM 삭제

gcloud compute instances delete cassandra-origin-vm zdm-proxy-jumphost zdm-proxy-node-1 bigtable-proxy-vm cdm-migrator-vm --zone=$ZONE --quiet

2. Bigtable 인스턴스 삭제

gcloud bigtable instances delete zdmbigtable

3. 방화벽 규칙 삭제

gcloud compute firewall-rules delete allow-migration-internal

4. Cassandra 데이터베이스 삭제 (로컬에 설치되었거나 지속된 경우)

여기에서 만든 Compute Engine VM 외부에 Cassandra를 설치한 경우 적절한 단계에 따라 데이터를 삭제하거나 Cassandra를 제거합니다.

11. 축하합니다.

Apache Cassandra에서 Bigtable로 프록시 기반 마이그레이션 경로를 설정하는 프로세스를 완료했습니다.

지금까지 다음 방법을 배웠습니다.

Cassandra 및 Bigtable을 배포합니다.

  • CQL 호환성을 위해 Cassandra-Bigtable 프록시를 구성합니다.
  • Datastax ZDM 프록시를 배포하여 이중 쓰기 및 트래픽을 관리합니다.
  • Cassandra 데이터 이전 도구를 사용하여 이전 데이터를 이동합니다.

이 접근 방식을 사용하면 프록시 레이어를 활용하여 다운타임을 최소화하고 코드를 변경하지 않고도 마이그레이션할 수 있습니다.

다음 단계

  • Bigtable 문서 살펴보기
  • 고급 구성 및 전환 절차에 관한 자세한 내용은 Datastax ZDM 프록시 문서를 참고하세요.
  • 자세한 내용은 Cassandra-Bigtable 프록시 저장소를 참고하세요.
  • 고급 사용법은 Cassandra Data Migrator 저장소를 확인하세요.
  • 다른 Google Cloud Codelab 사용해 보기