이 문서에서는 데이터베이스를 Spanner로 마이그레이션하는 프로세스를 설명합니다. 마이그레이션 단계와 소스 데이터베이스 및 기타 요소에 따라 각 단계에 권장되는 도구에 대해 설명합니다. 권장되는 도구로는 Google Cloud 제품, 상업용 서드 파티 및 오픈소스 도구가 있습니다. 이러한 도구를 함께 사용하면 마이그레이션을 가속화하고 위험을 줄일 수 있습니다.
모든 Spanner 마이그레이션에는 다음과 같은 핵심 단계가 포함됩니다.
- 마이그레이션 복잡성 평가
- 스키마 마이그레이션
- 애플리케이션 마이그레이션
- 성능 테스트 및 조정
- 데이터 마이그레이션
- 마이그레이션 검증
- 컷오버 및 장애 조치 메커니즘 구성
다음 다이어그램에서 이 프로세스를 볼 수 있습니다.
이러한 단계에서 마이그레이션 계획은 데이터베이스 소스 및 크기, 다운타임 요구사항, 애플리케이션 코드 복잡성, 샤딩 스키마, 커스텀 함수 또는 변환, 장애 조치 및 복제 전략과 같은 요소에 따라 크게 달라질 수 있습니다.
Google은 Amazon DynamoDB, MySQL, Oracle Database, PostgreSQL에 대한 마이그레이션 가이드를 제공합니다. 이러한 데이터베이스 중 하나에서 마이그레이션하는 경우 관련 가이드도 따르세요.
- MySQL에서 마이그레이션
- PostgreSQL에서 Spanner로 마이그레이션(GoogleSQL 언어)
- PostgreSQL에서 Spanner로 마이그레이션(PostgreSQL 언어)
- Oracle 데이터베이스에서 마이그레이션
- DynamoDB에서 마이그레이션
다른 데이터베이스에서 마이그레이션하는 경우 이 가이드에서 다루지 않는 추가 맞춤설정 및 도구가 필요할 수 있습니다.
마이그레이션 도구
다음 도구를 사용하면 소스 데이터베이스 및 기타 요소에 따라 다양한 마이그레이션 단계에서 도움이 될 수 있습니다. 일부 도구는 특정 소스 데이터베이스만 지원합니다. 프로세스의 일부 단계에서는 도구를 사용할 수 없으므로 해당 단계를 수동으로 완료하세요.
- Spanner 마이그레이션 도구는 기본 평가뿐만 아니라 스키마 및 데이터 마이그레이션을 수행하는 오픈소스 도구입니다.
- 데이터 유효성 검사 도구(DVT)는 Google에서 빌드하고 오픈소스 커뮤니티에서 지원하는 표준화된 데이터 유효성 검사 방법입니다. DVT를 기존 Google Cloud 제품에 통합할 수 있습니다.
- Datastream은 소스 데이터베이스에서 변경 데이터 캡처(CDC) 이벤트 및 일괄 데이터를 읽을 수 있게 해주는 Google Cloud 서비스입니다.
- Dataflow는 템플릿을 사용하여 Spanner에 대량의 데이터를 더욱 효율적으로 작성할 수 있게 해주는 Google Cloud 서비스입니다. 이러한 템플릿은 덤프 파일을 생성하지 않습니다. 덤프 파일은 소스 데이터베이스 도구 또는 서드 파티 도구에서 생성되어야 합니다.
다음 표에는 일반적인 소스 데이터베이스의 각 마이그레이션 단계에서 권장되는 기본 도구가 요약되어 있습니다. 맞춤설정을 사용하여 다른 데이터베이스에서 마이그레이션할 수 있습니다.
| 소스 데이터베이스 | 범위 평가 | 스키마 마이그레이션 | 앱 마이그레이션 | 데이터 이전하기 | 데이터 마이그레이션 검증 | 컷오버 및 장애 조치 구성 |
|---|---|---|---|---|---|---|
| MySQL | 수동 | Spanner 마이그레이션 도구 | 수동 | Spanner 마이그레이션 도구 | DVT | 수동 |
| PostgreSQL | 수동 | Spanner 마이그레이션 도구 | 수동 | Spanner 마이그레이션 도구 | DVT | 수동 |
| 기타 데이터베이스 | 수동 | Spanner 마이그레이션 도구 | 수동 | 수동 | DVT | 수동 |
마이그레이션 복잡성 평가
마이그레이션의 범위와 복잡성을 평가하고 접근 방식을 계획하려면 다음을 포함하여 소스 데이터베이스에 대한 데이터를 수집해야 합니다.
- 쿼리 패턴
- 저장 프로시저 및 트리거와 같은 데이터베이스 기능에 의존하는 애플리케이션 로직의 양
- 하드웨어 요구사항
- 총소유비용(TCO)
스키마 마이그레이션
스키마를 Spanner 스키마로 마이그레이션하기 전에 스키마 간의 호환성을 평가하고 Spanner에 맞게 스키마를 최적화합니다. 예를 들어 키를 변경하거나 색인을 삭제 또는 추가하거나 기존 테이블의 열을 추가 또는 삭제할 수 있습니다. Spanner에 맞게 스키마를 최적화하려면 스키마 설계 권장사항 및 권장되는 기본 키 마이그레이션 전략을 참조하세요.
Google 개발자가 만들고 커뮤니티에서 유지관리하는 오픈소스 도구인 Spanner 마이그레이션 도구는 소스 데이터베이스 스키마에서 Spanner 스키마를 자동으로 빌드합니다. Spanner 마이그레이션 도구의 스키마 어시스턴트를 사용하여 스키마를 맞춤설정할 수 있습니다.
Spanner 마이그레이션 도구는 다음 위치 중 하나에서 스키마와 데이터를 수집합니다.
- 로컬 위치 또는 Cloud Storage(MySQL, PostgreSQL, CSV)의 덤프 파일
- 소스 데이터베이스(MySQL, PostgreSQL)에서 직접
Spanner 마이그레이션 도구는 스키마 평가, 권장사항, 마이그레이션을 위해 다음 기능을 수행합니다.
- 데이터 유형 호환성 평가 및 권장사항
- 기본 키 수정 및 권장사항
- 보조 색인 수정 및 권장사항
- 테이블 수정 및 권장사항 인터리브 처리
- 일반 Spanner 스키마 설계 권장사항
- 스키마 버전 관리
- 공동 스키마 수정
Spanner 마이그레이션 도구를 사용한 스키마 마이그레이션에 대한 자세한 내용은 Spanner 마이그레이션 도구 README.md 파일을 참조하세요.
데이터 마이그레이션에도 Spanner 마이그레이션 도구를 사용합니다.
애플리케이션 마이그레이션
데이터베이스 마이그레이션에는 다른 드라이버와 라이브러리뿐 아니라 Spanner에서 지원하지 않는 기능에 대한 보완 기능이 필요합니다. 유사한 기능을 실행하고 Spanner 강도를 최적화하려면 코드, 애플리케이션 흐름, 아키텍처를 변경해야 할 수 있습니다.
애플리케이션을 Spanner로 마이그레이션하는 데 필요한 몇 가지 변경사항은 다음과 같습니다.
- Spanner는 데이터베이스 수준에서 사용자 코드 실행을 지원하지 않으므로 데이터베이스 수준에 저장된 모든 프로시저 및 트리거를 애플리케이션으로 이동해야 합니다.
- Spanner 클라이언트 라이브러리와 객체 관계형 매퍼(ORM)를 사용합니다. 자세한 내용은 API, 클라이언트 라이브러리, ORM 드라이버 개요를 참조하세요.
- 쿼리를 변환해야 하는 경우 쿼리를 수동으로 변환하거나 다른 서드 파티 도구를 사용합니다.
- Partitioned DML, 읽기 전용 트랜잭션, 커밋 타임스탬프, 읽기 타임스탬프, 애플리케이션 성능 최적화 방법을 기록합니다.
또한 트랜잭션 처리를 변경해야 할 수도 있습니다. 이 작업을 수행하는 데 사용할 수 있는 도구가 없으므로 이 단계를 수동으로 완료해야 합니다. 다음 사항에 유의하세요.
- 커밋당 변형 한도는 40,000개입니다. 테이블의 각 보조 색인은 행당 추가 변형입니다. 변형을 사용하여 데이터를 수정하려면 변형을 사용하여 데이터 삽입, 업데이트, 삭제를 참조하세요. 많은 양의 데이터를 삭제하려면 Partitioned DML을 사용합니다.
- 트랜잭션 격리 수준의 경우 Spanner 트랜잭션이 더 격리되므로 처리가 필요하지 않습니다.
- Spanner는 선형화될 수 있으므로 기본적으로 일관성 및 잠금을 처리합니다.
스키마 및 애플리케이션 성능 테스트 및 조정
성능 조정은 데이터 하위 집합을 기반으로 CPU 사용률 및 지연 시간과 같은 측정항목을 평가하고, 스키마와 애플리케이션을 조정하여 성능을 개선하고, 다시 테스트하는 반복 프로세스입니다.
예를 들어 스키마에서 색인을 추가 또는 변경하거나 기본 키를 변경할 수 있습니다. 애플리케이션에서 일괄 쓰기를 수행하거나 쿼리를 병합 또는 수정할 수 있습니다.
특히 프로덕션 트래픽의 경우 예상치 못한 상황을 방지하기 위해 성능 조정이 중요합니다. 성능 조정은 설정이 프로덕션 트래픽 처리량 및 데이터 크기에 가까울수록 더 효과적입니다.
스키마 및 애플리케이션 성능을 테스트하고 조정하려면 다음 단계를 따르세요.
- 데이터의 하위 집합을 Spanner 데이터베이스에 업로드합니다. 자세한 내용은 데이터 마이그레이션을 참조하세요.
- 애플리케이션이 Spanner를 가리키도록 합니다.
- 기본 흐름을 확인하여 정확성을 확인합니다.
- 애플리케이션에서 부하 테스트를 수행하여 성능이 기대에 부합하는지 확인합니다. 가장 비용이 많이 드는 쿼리를 식별하고 최적화하는 데 도움이 필요한 경우 쿼리 통계로 쿼리 성능 문제 감지를 참조하세요.
특히 다음 요소는 최적이 아닌 쿼리 성능에 기여할 수 있습니다.
- 비효율적인 쿼리: 효율적인 쿼리 작성에 대한 자세한 내용은 SQL 권장사항을 참조하세요.
- 높은 CPU 사용률: 자세한 내용은 높은 CPU 사용률 조사를 참조하세요.
- 잠금: 트랜잭션 잠금으로 인한 병목 현상을 줄이려면 긴 지연 시간을 초래할 수 있는 트랜잭션 식별을 참조하세요.
- 비효율적인 스키마 설계: 스키마가 제대로 설계되지 않으면 쿼리 최적화는 그다지 유용하지 않습니다.
- 부하 집중: Spanner의 부하 집중은 특히 QPS가 높은 애플리케이션의 쓰기 처리량을 제한합니다. 부하 집중 또는 안티패턴을 식별하려면 Google Cloud 콘솔에서 Key Visualizer 통계를 확인합니다. 부하 집중 방지에 대한 자세한 내용은 부하 집중을 방지하기 위한 기본 키 선택을 참조하세요.
- 스키마 또는 색인을 수정할 경우 만족스러운 결과를 얻을 때까지 정확성 및 성능 테스트를 반복합니다.
데이터베이스 성능 미세 조정에 대한 자세한 내용은 Spanner 지원에 문의하세요.
데이터 이전하기
Spanner 스키마를 최적화하고 애플리케이션을 마이그레이션한 후 데이터를 프로덕션 크기의 빈 Spanner 데이터베이스로 이동한 후 Spanner 데이터베이스로 전환합니다.
소스 데이터베이스에 따라 최소 다운타임으로 데이터베이스를 마이그레이션할 수도 있고 장시간 다운타임이 필요할 수도 있습니다.
최소 다운타임 마이그레이션과 장시간 다운타임 마이그레이션의 경우 Dataflow와 Spanner 마이그레이션 도구를 사용하는 것이 좋습니다.
다음 표에서는 지원되는 소스, 형식, 크기, 처리량을 비롯한 최소 다운타임 마이그레이션과 장시간 다운타임 마이그레이션의 차이점을 보여줍니다.
| 최소 다운타임 마이그레이션 | 다운타임을 통한 마이그레이션 | |
|---|---|---|
| 지원되는 소스 | MySQL, PostgreSQL | CSV 또는 Avro로 내보낼 수 있는 모든 데이터베이스 |
| 지원되는 데이터 형식 | 직접 연결합니다. MySQL 데이터베이스에 직접 연결을 참조하세요. | MySQL, PostgreSQL, CSV, Avro |
| 지원되는 데이터베이스 크기 | 제한 없음 | 제한 없음 |
| 최대 처리량 | 시간당 45GB | 시간당 200GB |
최소 다운타임 마이그레이션
Spanner는 MySQL, PostgreSQL, Oracle 데이터베이스에서 최소 다운타임 마이그레이션을 지원합니다. 최소 다운타임 마이그레이션은 두 가지 구성요소로 구성됩니다.
- 데이터베이스의 모든 데이터에 대한 일관된 스냅샷
- 해당 스냅샷 이후의 변경 내역(삽입 및 업데이트). 변경 데이터 캡처(CDC)라고도 합니다.
최소 다운타임 마이그레이션은 데이터 보호에 도움이 되지만 프로세스에는 다음을 비롯한 문제가 발생합니다.
- 스냅샷이 마이그레이션되는 동안 CDC 데이터 저장
- 들어오는 CDC 스트림을 캡처하는 동안 Spanner에 CDC 데이터 쓰기
- CDC 데이터를 Spanner로 마이그레이션하는 작업이 들어오는 CDC 스트림보다 빠르도록 보장
최소 다운타임 마이그레이션을 관리하기 위해 Spanner 마이그레이션 도구는 다음 프로세스를 자동으로 조정합니다.
- 스냅샷 마이그레이션이 진행되는 동안 소스 데이터베이스에 CDC 이벤트를 저장하도록 Cloud Storage 버킷을 설정합니다.
- CDC 데이터의 일괄 로드를 이동하고 증분 CDC 데이터를 Cloud Storage 버킷으로 지속적으로 스트리밍하는 Datastream 작업을 설정합니다. Spanner 마이그레이션 도구 내에서 소스 연결 프로필을 설정합니다.
- CDC 이벤트를 Spanner로 마이그레이션하도록 Dataflow 작업을 설정합니다.
Dataflow는 대부분의 데이터를 복사하면 소스 데이터베이스에 쓰기를 중지하고 데이터 마이그레이션이 완료될 때까지 기다립니다. 그러면 Spanner가 소스 데이터베이스를 추적하는 동안 다운타임이 짧아집니다. 그런 다음 애플리케이션을 Spanner로 컷오버할 수 있습니다.
다음 다이어그램에서 이 프로세스를 볼 수 있습니다.
다운타임을 통한 마이그레이션
MySQL, PostgreSQL 또는 Oracle 데이터베이스 이외의 데이터베이스의 경우 데이터베이스를 CSV 또는 Avro로 내보낼 수 있으면 다운타임을 통해 Spanner로 마이그레이션할 수 있습니다. Dataflow 또는 Spanner 마이그레이션 도구를 사용하는 것이 좋습니다.
다운타임을 통한 마이그레이션은 몇 시간의 다운타임을 허용할 수 있는 테스트 환경 또는 애플리케이션에만 권장됩니다. 라이브 데이터베이스에서는 다운타임을 통한 마이그레이션으로 인해 데이터가 손실될 수 있습니다.
다운타임 마이그레이션을 수행하려면 다음 상위 단계를 따르세요.
- 소스 데이터베이스에서 데이터의 덤프 파일을 생성합니다.
- 덤프 파일을 MySQL, PostgreSQL, Avro 또는 CSV 덤프 형식으로 Cloud Storage에 업로드합니다.
- Dataflow 또는 Spanner 마이그레이션 도구를 사용하여 덤프 파일을 Spanner에 로드합니다.
Spanner는 여러 덤프 파일을 동시에 읽을 수 있으므로 작은 덤프 파일을 여러 개 생성하면 Spanner에 더 빠르게 쓸 수 있습니다.
소스 데이터베이스에서 덤프 파일을 생성할 때 일관된 데이터 스냅샷을 생성하려면 다음 사항에 유의하세요.
- 덤프 파일을 생성하는 동안 데이터가 변경되지 않도록 하려면 덤프를 수행하기 전에 소스 데이터베이스에 읽기 잠금을 적용합니다.
- 복제가 사용 중지된 소스 데이터베이스에서 읽기 복제본을 사용하여 덤프 파일을 생성합니다.
일괄 마이그레이션에 권장되는 형식
Avro는 Spanner로의 일괄 마이그레이션에 권장되는 형식입니다. Avro를 사용하는 경우 다음을 고려하세요.
- 데이터의 Avro 덤프를 생성하려면 DBeam과 같은 도구를 사용합니다. Avro로 내보내는 방법에 대한 자세한 내용은 Spanner 이외의 데이터베이스에서 Avro 파일로 데이터 내보내기를 참조하세요.
- Avro 데이터를 가져오려면 Dataflow 가져오기 작업을 사용합니다. 자세한 내용은 Spanner 이외의 데이터베이스에서 Spanner로 Avro 파일 가져오기를 참조하세요.
CSV를 사용하는 경우 다음 사항을 고려하세요.
- 데이터의 CSV 덤프를 생성하려면 소스에서 지원하는 CSV 생성을 사용합니다. 데이터에 줄바꿈이 포함되어 있는 경우 커스텀 줄 구분 기호를 사용합니다.
- CSV 데이터를 가져오려면 Dataflow 가져오기 작업을 사용합니다. 자체 Dataflow 가져오기 템플릿을 만들거나 Google Cloud 가져오기 템플릿을 사용할 수 있습니다. 자세한 내용은 Dataflow 데이터 파이프라인 템플릿을 참조하세요.
MySQL이나 PostgreSQL을 사용하는 경우 Spanner 마이그레이션 도구를 사용할 수 있습니다.
커스텀 스크립트를 사용하여 Spanner에 데이터를 로드하는 방법은 일괄 로드 성능 가이드라인을 참조하세요.
데이터 마이그레이션 검증
데이터 검증은 소스 테이블과 대상 테이블의 데이터를 비교하여 일치하는지 확인하는 프로세스입니다.
데이터 검증 도구(DVT)는 데이터 스토어에 연결하고 소스와 Spanner 간에 검사를 수행할 수 있는 오픈소스 도구입니다. 이 도구는 다음과 같이 마이그레이션의 일부로 기본 검증을 수행하는 데 사용하는 것이 좋습니다.
- 모든 테이블이 생성되었고 모든 스키마 매핑이 올바른지 확인합니다.
- 각 테이블의 행 수가 일치합니다.
- 임의의 행을 추출하여 정확성을 확인합니다.
- 열(
count,sum,avg,min,max,group by)을 검증합니다. - 행 수준에서 순환 중복 검사 또는 해시 함수를 비교합니다.
보다 구체적인 검증을 수행하려면 마이그레이션 중에 커스텀 검사를 빌드하세요.
컷오버 및 장애 조치 메커니즘 구성
마이그레이션은 많은 시간이 소요되고 복잡할 수 있습니다. 마이그레이션 중에 오류가 발생할 경우 중대한 영향을 방지하기 위해 대체 데이터를 빌드하면 최소 다운타임으로 소스 데이터베이스로 다시 전환할 수 있습니다.
현재 변경 내역을 사용하여 역방향 복제를 수행하고 Pub/Sub와 같은 스트림을 통해 소스 데이터베이스나 Cloud Storage에 다시 쓰는 것이 좋습니다.
역방향 복제는 다음을 수행해야 합니다.
- 데이터 유형 또는 콘텐츠의 변경을 처리합니다.
- 마이그레이션 중에 수행된 모든 변환을 역전환합니다.
- 소스의 샤딩 스키마를 고려하여 적절한 대상으로 데이터를 푸시합니다.