Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

Spanner에서 Spanner Omni로 데이터 복제

이 문서에서는Google Cloud 의 관리형 Spanner와 AWS 또는 온프레미스 데이터 센터와 같은 외부 환경의 Spanner Omni 간에 재해 복구 토폴로지를 설정하기 위한 패턴, 구성 단계, 운영 가이드를 설명합니다.

변경 내역을 사용한 트랜잭션 스트리밍과 Cross-Cloud Interconnect를 통한 전용 네트워크 연결을 결합하면 클라우드 경계 전반에서 낮은 복구 지점 목표 (RPO) 및 복구 시간 목표 (RTO)를 달성할 수 있습니다.

아키텍처 개요

크로스 클라우드 재해 복구 토폴로지에서Google Cloud 의 Spanner는 기본 데이터베이스 역할을 하고 Spanner Omni는 대기 배포 또는 보조 재해 복구 사이트 역할을 합니다. 변경 내역을 사용하여 트랜잭션 변경사항을 지속적으로 복제할 수 있습니다.

다음 표에서는 기본 Spanner 배포와 AWS의 보조 Spanner Omni 배포 간의 데이터베이스 기능, 역할, 운영 경계를 비교합니다.

기본 Spanner 및 보조 Spanner Omni 배포 비교
기능 또는 측정기준	기본 사이트: Google Cloud의 Spanner	보조 사이트: AWS의 Spanner Omni
배포 모델	Google Cloud의 완전 관리형 서비스입니다.	Amazon Elastic Compute Cloud(Amazon EC2) 또는 Amazon Elastic Kubernetes Service (Amazon EKS)와 같은 AWS의 자체 관리형 소프트웨어
가용성 SLA	멀티 리전 구성의 경우 최대 99.999%, 리전 구성의 경우 최대 99.99% 입니다. 자세한 내용은 Spanner SLA를 참조하세요.	고객이 관리하며 인프라 및 토폴로지에 따라 다릅니다.
복제 모드	영역 및 리전 간 동기식 Paxos 기반 복제	변경 내역을 사용하는 비동기식, 거의 실시간 변경 데이터 캡처 (CDC)
복구 지점 목표(RPO)	관리형 인스턴스 내에서 거의 0에 가깝습니다.	파이프라인 처리량 및 네트워크 지연 시간에 따라 클라우드 경계 간에 1초 미만에서 수초까지 소요됩니다.
복구 시간 목표(RTO)	복제본 간에 즉각적인 자동 장애 조치가 수행됩니다.	DNS 및 트래픽 전환 런북에 따라 다릅니다.
네트워크 전송 레이어	가상 프라이빗 클라우드 (VPC) 네트워크 피어링 또는 Cloud Interconnect	AWS Direct Connect에 연결된 Cross-Cloud Interconnect
백업 스토리지 대상	Google 관리 Spanner 백업: 관리형 Spanner로만 복원할 수 있습니다.	Cloud Storage 또는 Amazon Simple Storage Service (Amazon S3) - Spanner Omni로만 복원할 수 있습니다.

시작하기 전에

Spanner와 Spanner Omni 간에 복제를 구성하기 전에 환경이 다음 요구사항을 충족하는지 확인하세요.

일치하는 대상 용량 프로비저닝: 기본 Spanner 인스턴스의 CPU, 메모리, 스토리지 I/O 용량과 일치하도록 대상 Spanner Omni 배포의 크기를 조정합니다. 배포 크기를 너무 작게 설정하면 복제 지연이 발생하고 장애 조치 중에 대기 클러스터가 워크로드를 처리하지 못할 수 있습니다. 자세한 내용은 시스템 요구사항을 참조하세요.
데이터베이스 스키마 및 기준 데이터 동기화: 소스 Spanner 데이터베이스와 동일한 SQL 언어(GoogleSQL 또는 PostgreSQL) 및 스키마 정의를 사용하여 Spanner Omni에서 대상 데이터베이스와 테이블을 만듭니다. 관리형 Spanner 백업을 Spanner Omni로 복원할 수 없으므로 Spanner에서 Cloud Storage의 Avro 파일로 기존 데이터를 내보내고 Spanner Omni로 가져옵니다. 자세한 내용은 스키마 및 데이터 모델, Spanner Omni로 개발, Spanner에서 Avro로 데이터베이스 내보내기, 데이터 가져오기 및 내보내기를 참조하세요.
비공개 네트워크 연결 설정: 복제 작업자가 Spanner와 Spanner Omni gRPC 엔드포인트 모두에 연결할 수 있도록 Google Cloud VPC 네트워크와 외부 환경 간에 비공개 네트워크 라우팅을 구성합니다. 자세한 내용은 네트워크 연결 제품 선택 및 Cross-Cloud Interconnect를 사용한 복제 가속화를 참조하세요.

변경 내역을 사용하여 지속적으로 데이터 복제

크로스 클라우드 비즈니스 연속성이 필요한 애플리케이션의 경우 Spanner 변경 내역은 커밋 타임스탬프 순서로 트랜잭션 데이터 변경사항 (INSERT, UPDATE, DELETE 작업)을 출력합니다. 지속적 복제 파이프라인은 Google Cloud 의 Spanner에서 변경 레코드를 읽고 Spanner Omni 배포에 씁니다.

크로스 클라우드 복제에 변경 내역을 사용하면 다음과 같은 이점이 있습니다.

활성-수동 대기: 장애 조치를 시작할 때 워크로드를 제공할 준비가 된 Spanner Omni에서 웜 복제본을 유지합니다.
선택적 복제: 전체 데이터베이스를 감시하도록 변경 내역을 구성하거나 특정 테이블 및 열로 제한하여 크로스 클라우드 전송 비용을 줄일 수 있습니다.
언어 패리티: Spanner Omni는 Spanner와 동일한 GoogleSQL 및 PostgreSQL 언어와 스키마 시맨틱스를 지원하므로 전환 후 애플리케이션 쿼리가 수정 없이 실행됩니다.

1단계: 소스 데이터베이스에 변경 내역 만들기

소스 Spanner 데이터베이스에 변경 내역을 만들어 대상 테이블의 변경사항을 추적합니다. 예를 들어 Spanner 데이터베이스에서 다음 DDL 문을 실행합니다.

CREATE CHANGE STREAM CHANGE_STREAM_NAME
FOR TABLE_NAMES
OPTIONS (
  retention_period = '7d',
  value_capture_type = 'NEW_ROW_AND_OLD_VALUES'
);

다음을 바꿉니다.

CHANGE_STREAM_NAME: 변경 내역의 이름입니다(예: CsToOmniDrStream).
TABLE_NAMES: 추적할 테이블의 쉼표로 구분된 목록입니다(예: Customers, Orders, AccountBalances 또는 데이터베이스의 모든 테이블을 추적하는 ALL).

retention_period을 '7d'로 설정하면 변경 내역 레코드가 최대 7일 동안 보관되므로 복제 파이프라인에서 유지보수 또는 연결 중단이 연장되는 경우 데이터 손실을 방지할 수 있습니다. 자세한 내용은 변경 내역 만들기 및 관리를 참조하세요.

2단계: 변경 데이터 캡처 파이프라인 배포

Spanner에서 Spanner Omni로 변경사항을 스트리밍하려면 Apache Beam과 함께 Dataflow를 사용하여 지속적인 변경 데이터 캡처 (CDC) 파이프라인을 배포하거나 Google Kubernetes Engine (GKE) 또는 Amazon EKS에서 커스텀 워커 포드를 실행합니다.

프로덕션 복제 파이프라인은 다음 작업을 수행합니다.

파티션 읽기: Spanner 변경 내역 API 또는 Apache Beam SpannerIO 커넥터를 사용하여 동적 변경 내역 파티션에서 변경 레코드를 읽습니다. 자세한 내용은 변경 내역 파티션, 레코드, 쿼리 및 Dataflow를 사용하여 변경 내역 레코드 처리를 참조하세요.
변형 버퍼링 및 순서 지정: 키 범위 또는 테이블당 커밋 타임스탬프 (commit_timestamp)에 따라 트랜잭션의 순서를 지정하고 일괄 처리하여 트랜잭션 일관성을 유지하고 쓰기 처리량을 극대화합니다.
Spanner Omni에 쓰기: gRPC를 통해 Spanner Omni 배포의 비공개 엔드포인트에 연결하고 일괄 변형을 적용합니다. 암호화와 함께 Apache Beam SpannerIO 커넥터를 사용하는 경우 TLS에는 Apache Beam 2.69.0 이상을, 상호 TLS (mTLS)에는 2.75.0 이상을 사용합니다. 자세한 내용은 Apache Beam 및 SpannerIO를 사용하여 Spanner Omni에 연결 및 인증 및 승인을 참조하세요.
복제 지연 모니터링: 복제 지연에 대한 알림을 받을 수 있도록 현재 시간과 처리된 변경 레코드의 commit_timestamp 간의 차이를 추적합니다.

Dataflow 또는 Apache Beam을 사용하는 경우 Python SDK에 변경 내역 커넥터가 포함되어 있지 않으므로 Apache Beam Java SDK를 사용해야 합니다. 커스텀 작업자 포드의 경우 이 Python 예시에서는 TLS 암호화를 사용하여 Spanner Omni 클라이언트를 구성하고 변경 내역 변형 배치를 대상 데이터베이스에 적용하는 방법을 보여줍니다. 대용량 워크로드의 경우 한 번에 하나의 레코드를 커밋하는 대신 병렬 작업자 프로세스에서 커밋 타임스탬프 순서로 겹치지 않는 변형을 큐에 추가하고 일괄 처리합니다.

from google.cloud import spanner
from google.cloud.spanner_v1 import InstanceType

# Configure the Spanner Omni target client
omni_client = spanner.Client(
    client_options={"api_endpoint": "ENDPOINT"},
    instance_type=InstanceType.OMNI,
    ca_certificate="PATH_TO_CA_CERT",
)
# Spanner Omni uses "default" as the instance ID
omni_instance = omni_client.instance("default")
omni_database = omni_instance.database("DATABASE_ID")


def apply_cdc_mutations_to_omni(records):
    """Applies a batch of ordered change stream records to Spanner Omni."""

    def write_batch(transaction):
        for record in records:
            table_name = record["tableName"]
            mutation_type = record["mutationType"]  # INSERT, UPDATE, DELETE
            row_data = record.get("columnValues", {})

            if mutation_type in ("INSERT", "UPDATE"):
                transaction.insert_or_update(
                    table=table_name,
                    columns=list(row_data.keys()),
                    values=[list(row_data.values())],
                )
            elif mutation_type == "DELETE":
                key_columns = record["keyValues"]
                transaction.delete(
                    table=table_name,
                    keyset=spanner.KeySet(keys=[list(key_columns.values())]),
                )

    omni_database.run_in_transaction(write_batch)

다음을 바꿉니다.

ENDPOINT: Spanner Omni 인스턴스의 비공개 gRPC 엔드포인트 및 포트입니다(예: spanner-omni.internal.example.com:15000).
PATH_TO_CA_CERT: Spanner Omni 배포의 인증 기관 (CA) 인증서에 대한 파일 경로입니다.
DATABASE_ID: 대상 Spanner Omni 데이터베이스의 ID입니다.

클라이언트 연결 구성에 대한 자세한 내용은 Python 클라이언트 라이브러리를 사용하여 Spanner Omni에 연결을 참조하세요.

Cross-Cloud Interconnect를 사용한 복제 가속화

Google Cloud와 다른 클라우드 제공업체 간에 공개 인터넷 또는 IPsec VPN 터널을 사용하면 네트워크 지터, 패킷 손실, 대역폭 제한, 가변 복제 지연이 발생할 수 있습니다. 낮은 RPO가 필요한 프로덕션 워크로드의 경우 Cross-Cloud Interconnect를 사용하여Google Cloud 와 외부 클라우드 제공업체 간에 전용 고속 물리적 연결을 설정합니다.

다음 표에서는 공개 인터넷 또는 IPsec VPN 연결과 Cross-Cloud Interconnect 간의 네트워크 특성을 비교합니다.

크로스 클라우드 복제를 위한 네트워크 전송 옵션 비교
네트워크 측정항목	공개 인터넷 또는 IPsec VPN	Cross-Cloud Interconnect
링크 용량	터널당 1.25Gbps~3Gbps	링크당 10Gbps 또는 100Gbps의 전용 광학 대역폭
네트워크 지연 시간 및 지터	가변적이고 예측할 수 없는 인터넷 전송 경로	결정론적이고 지연 시간이 짧은 비공개 라우팅
가용성 SLA	엔드 투 엔드 성능 SLA가 없습니다.	중복 연결로 구성된 경우 99.9% 또는 99.99% 가용성 SLA
데이터 전송 암호화	IPsec 오버헤드 및 소프트웨어 암호화 한도	Cloud Interconnect용 MACsec (IEEE 802.1AE) 암호화의 회선 속도 자세한 내용은 Cloud Interconnect용 MACsec 개요를 참조하세요.
데이터 전송 비용	표준 인터넷 이그레스 요금	Cloud Interconnect 데이터 전송 요금 할인

개략적인 네트워크 구성 워크플로

복제 파이프라인에 Cross-Cloud Interconnect를 설정하려면 다음 대략적인 단계를 완료합니다.

Cross-Cloud Interconnect 연결 주문: 원격 클라우드 제공업체 위치와 페어링되는 코로케이션 시설에서 기본 및 중복 Cross-Cloud Interconnect 포트를 주문합니다. 예를 들어 gcloud compute interconnects create 명령어를 실행합니다.
```
gcloud compute interconnects create CONNECTION_NAME \
  --interconnect-type=DEDICATED \
  --link-type=CAPACITY \
  --requested-link-count=LINK_COUNT \
  --location=GOOGLE_CLOUD_LOCATION \
  --remote-location=REMOTE_LOCATION \
  --noc-contact-email=CONTACT_EMAIL
```
다음을 바꿉니다.
- CONNECTION_NAME: Cross-Cloud Interconnect 연결의 이름입니다.
- CAPACITY: 링크 용량(예: LINK_TYPE_ETHERNET_10G_LR 또는 LINK_TYPE_ETHERNET_100G_LR)
- LINK_COUNT: 요청할 링크 수입니다.
- GOOGLE_CLOUD_LOCATION: Google Cloud 위치의 에지 가용성 도메인입니다(예: iad-zone1-1).
- REMOTE_LOCATION: 원격 클라우드 제공업체 위치입니다(예: aws-us-east-1).
- CONTACT_EMAIL: 네트워크 운영 이메일 주소입니다.
자세한 내용은 위치 선택 및 AWS 포트 주문을 참조하세요.
Cloud Router 및 BGP 피어링 구성: VLAN 연결을 만들고 Google Cloud VPC 네트워크의 Cloud Router와 원격 클라우드 환경의 가상 프라이빗 게이트웨이 또는 직접 연결 게이트웨이 간에 경계 게이트웨이 프로토콜 (BGP) 세션을 구성합니다. 자세한 내용은 Cloud Router 개요, Google Cloud 리소스 구성, AWS 리소스 구성을 참조하세요.
경로 전파 검증: 두 네트워크의 경로 테이블이 겹치지 않는 CIDR 블록을 전파하여 CDC 파이프라인 작업자와 Spanner Omni 노드가 비공개 IP 주소를 통해서만 통신하는지 확인합니다. 자세한 내용은 연결 확인을 참조하세요.

전체 설정 안내는 Cross-Cloud Interconnect 문서의 Amazon Web Services에 연결을 참조하세요.

장애 조치 및 런북 체크리스트

Google Cloud 의 Spanner에서 Spanner Omni로 전환 또는 장애 조치를 실행할 때는 다음 운영 단계를 따르세요.

진행 중인 변경사항 드레이닝: 기본 Spanner 데이터베이스에 대한 애플리케이션 쓰기를 중지하고 (연결 가능한 경우) CDC 복제 파이프라인이 최신 커밋 타임스탬프까지 모든 변경 내역 레코드를 처리했는지 확인합니다.
애플리케이션 연결 리디렉션:Google Cloud의 Spanner 대신 Spanner Omni 엔드포인트에 연결하도록 애플리케이션 구성 프로필, 연결 문자열 또는 Kubernetes 보안 비밀을 업데이트합니다.
DNS 및 트래픽 라우팅 업데이트: DNS 레코드 또는 전역 부하 분산기 대상을 전환하여 클라이언트 트래픽을 애플리케이션 계층과 Spanner Omni 배포를 전면에 배치하는 부하 분산기로 라우팅합니다.
복구 후 재동기화: 기본Google Cloud 환경을 복원한 후 장애 복구 전에 복제 방향을 반대로 바꿉니다. 변경 내역과 Debezium 커넥터를 사용하여 Spanner Omni의 변경사항을 캡처하고, 변경사항을 Spanner에 적용하는 소비자를 통해 Apache Kafka에 변경사항을 게시합니다. 또는 Spanner Omni 데이터베이스를 Cloud Storage의 Avro 파일로 내보내고 Spanner로 가져올 수 있습니다. 자세한 내용은 데이터 가져오기 및 내보내기 및 Spanner Avro 파일 가져오기를 참조하세요.

Spanner에서 Spanner Omni로 데이터 복제 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.