소스 데이터베이스와 사용량이 Spanner에 매핑되는 방식을 평가하려면 비즈니스, 기술, 운영, 재무 니즈를 평가해야 합니다. 평가 시 다음과 같은 주요 영역을 다루는 것이 좋습니다.
비즈니스 목표: 확장성, 가용성, 일관성과 같은 Spanner가 해결하는 구체적인 비즈니스 문제를 정의합니다. 지연 시간 감소, 트랜잭션 볼륨 증가, 비용 절감과 같은 측정 가능한 성공 기준을 수립합니다.
비용 분석: Spanner 사용 시 발생할 수 있는 총 비용(컴퓨팅, 스토리지, 네트워크)을 계산하고 이를 현재 데이터베이스 비용과 비교합니다.
일회성 마이그레이션 비용과 지속적인 운영 비용을 고려합니다. 자세한 내용은 Spanner 가격 책정을 참조하세요.
스키마 호환성: 데이터 유형, 제약 조건, 색인 또는 저장 프로시저와 같은 Spanner와의 잠재적 비호환성에 대해 기존 소스 데이터베이스 스키마를 분석합니다. 소스 데이터베이스 스키마를 Spanner에 적절하게 매핑하도록 스키마 수정과 데이터 변환을 계획합니다. 자세한 내용은 스키마 설계 권장사항을 참조하세요.
데이터 일관성 및 트랜잭션: Spanner의 외부 일관성 모델과 소스 데이터베이스 트랜잭션 모델과의 차이점을 이해합니다. 애플리케이션 로직에 미치는 영향을 평가합니다. 자세한 내용은 Spanner: TrueTime 및 외부 일관성을 참조하세요.
데이터 위치 및 리전 구성: 사용자 위치, 지연 시간 요구사항, 비용 고려사항에 따라 리전, 이중 리전 또는 멀티 리전 배포와 같은 최적의 Spanner 배포 토폴로지를 결정합니다. 자세한 내용은 인스턴스 구성을 참조하세요.
애플리케이션 코드 호환성: 애플리케이션 코드와의 모든 데이터베이스 상호작용을 인벤토리합니다. SQL 언어, 클라이언트 라이브러리, 트랜잭션 관리의 차이로 인해 수정해야 하는 영역을 식별합니다.
성능 및 확장성 요구사항: 읽기 및 쓰기 비율, 트랜잭션 비율, 데이터 볼륨과 같은 현재 및 예상 워크로드를 정의합니다.
허용 가능한 지연 시간과 처리량을 결정합니다. Spanner 성능에 대한 자세한 내용은 성능 개요를 참조하세요.
마이그레이션 전략 및 다운타임: 데이터 추출, 변환, 로드, 유효성 검사를 포함하여 자세한 마이그레이션 계획을 개발합니다. 다운타임이 문제가 되지 않으면 일회성 일괄 로드 및 컷오버를 수행할 수 있습니다. 그렇지 않은 경우 다운타임을 최소화하는 것이 좋습니다. 롤백 계획을 정의합니다.
운영 고려사항: 데이터베이스 관리, 모니터링, 재해 복구의 변경사항을 계획합니다. 팀의 학습 곡선을 평가합니다.
Spanner를 기존 운영 도구 및 프로세스와 통합합니다. 자세한 내용은 재해 복구 개요를 참조하세요.
보안: 인증, 승인, 암호화와 같은 Spanner 보안 기능을 검토합니다. 관련 규정을 준수합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Assess your migration\n\nAssessing your source database and how its usage maps to Spanner\nrequires evaluating your business, technical, operational,\nand financial needs. We recommend covering the following key areas for your\nassessment:\n\n- **Business goals**: Define the specific business problems Spanner solves, such as scalability, availability, and consistency. Establish measurable success criteria, such as reduced latency, increased transaction volume, and cost reduction.\n\n\u003c!-- --\u003e\n\n- **Cost analysis** : Calculate the potential total cost of using Spanner (compute, storage, and network) and compare it to your current database costs. Factor in one-time migration costs and ongoing operational expenses. For more information, see [Spanner pricing](/spanner/pricing).\n\n\u003c!-- --\u003e\n\n- **Schema compatibility** : Analyze the existing source database schema for\n possible incompatibilities with Spanner such as data types, constraints,\n indexes, or stored procedures. Plan for schema modifications and data\n transformations to appropriately map your source database schema to Spanner. For\n more information, see\n [Schema design best practices](/spanner/docs/schema-design).\n\n- **Data consistency and transactions** : Understand Spanner's\n external consistency model and its differences from your source database\n transaction model. Evaluate the impact on your application logic. For more\n information, see\n [Spanner: TrueTime and external consistency](/spanner/docs/true-time-external-consistency).\n\n- **Data locality and regional configurations** : Determine optimal\n Spanner deployment topology such as regional, dual-region, or multi-region\n deployments based on user locations, latency requirements, and cost\n considerations. For more information, see\n [Instances configurations](/spanner/docs/instance-configurations#configuration).\n\n- **Application code compatibility**: Inventory all database interactions with\n your application code. Identify areas that require modification because of\n differences in SQL dialect, client libraries, and transaction management.\n\n- **Performance and scalability requirements** : Define current and projected\n workloads such as read and write ratios, transaction rates, and data volume.\n Determine acceptable latency and throughput. For more information on\n Spanner's performance, see\n [Performance overview](/spanner/docs/performance#typical-workloads).\n\n- **Migration strategy and downtime**: Develop a detailed migration plan,\n including data extraction, transformation, loading, and validation. If downtime isn't a concern,\n you can perform a one-time bulk load and cutover. Otherwise, consider minimizing\n downtime. Define a rollback plan.\n\n- **Operational consideration** : Plan for changes in database administration,\n monitoring, and disaster recovery. Assess the learning curve for the team.\n Integrate Spanner with existing operational tools and processes\n For more information, see\n [Disaster recovery overview](/spanner/docs/backup/disaster-recovery-overview).\n\n- **Security** : Review Spanner's security features such as\n [authentication](/spanner/docs/authentication), [authorization](/spanner/docs/iam),\n and [encryption](/spanner/docs/encryption-in-transit). Ensure compliance with relevant\n regulations.\n\nSource specific guides\n----------------------\n\n- MySQL: [Migrate from MySQL to Spanner](/spanner/docs/migrating-mysql-to-spanner)."]]