AWS에서 Google Cloud로 마이그레이션: SQL 서버용 Amazon RDS에서 SQL 서버용 Cloud SQL로 마이그레이션

Last reviewed 2024-06-28 UTC

Google Cloud는 Amazon 관계형 데이터베이스 서비스(RDS)에서 SQL 서버용 Cloud SQL로 마이그레이션하기 위한 도구, 제품, 안내, 전문 서비스를 제공합니다.

이 문서는 데이터베이스 마이그레이션 프로젝트를 계획, 구현, 검증하려는 클라우드 및 데이터베이스 관리자를 대상으로 합니다. 또한 마이그레이션 기회를 평가 중이고 마이그레이션 결과에 대한 예시를 보고 싶은 의사 결정권자를 대상으로 합니다.

이 문서에서는 소스 및 대상 데이터베이스가 동일한 데이터베이스 기술에 해당하는 동종 데이터베이스 마이그레이션에 중점을 둡니다. 소스는 SQL 서버용 Amazon RDS이고 대상은 SQL 서버용 Cloud SQL입니다.

이 문서는 AWS에서 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부로서 이 시리즈에는 다음 문서가 포함됩니다.

• 시작하기
• Amazon EC2에서 Compute Engine으로 마이그레이션
• Amazon S3에서 Cloud Storage로 마이그레이션
• Amazon EKS에서 GKE로 마이그레이션
• AWS에서 Google Cloud로 마이그레이션: SQL 서버용 Amazon RDS에서 SQL 서버용 Cloud SQL로 마이그레이션(이 문서)

이 문서는 사용자가 다음 문서를 읽고 숙지했다고 가정하고 작성되었습니다.

• Google Cloud로 마이그레이션: 시작하기에서는 이 마이그레이션에서 따르는 일반적인 마이그레이션 프레임워크를 설명합니다.
• Google Cloud로 마이그레이션: 마이그레이션 계획 검증 권장사항: 마이그레이션 계획의 잠재적 변경사항 및 개선사항에 대해 설명합니다.

다음 다이어그램은 마이그레이션 과정을 보여줍니다. 마이그레이션 시나리오에서는 배포 단계가 마이그레이션 프로세스 수행에 해당합니다.

예를 들어 일부 데이터베이스 인스턴스를 먼저 마이그레이션하고 다른 인스턴스는 나중에 마이그레이션하는 등의 방식으로 일련의 반복 작업을 통해 Amazon RDS에서 Cloud SQL로 마이그레이션할 수 있습니다. 각 마이그레이션 작업을 반복할 때마다 다음과 같은 일반적인 마이그레이션 프레임워크 단계를 수행합니다.

1. 워크로드 및 데이터를 평가하고 탐색합니다.
2. Google Cloud에 대한 기초를 계획하고 빌드합니다.
3. 워크로드 및 데이터를 Google Cloud로 마이그레이션합니다.
4. Google Cloud 환경을 최적화합니다.

이 프레임워크 단계에 대한 자세한 내용은 Google Cloud로 마이그레이션: 시작하기를 참조하세요.

원본 환경 평가

평가 단계에서는 마이그레이션하려는 리소스의 요구사항과 종속 항목을 결정합니다.

평가 단계는 다음 작업으로 구성됩니다.

1. 워크로드의 포괄적인 인벤토리를 빌드합니다.
2. 워크로드의 속성과 종속 항목에 따라 워크로드를 분류합니다.
3. 데이터베이스 권장사항을 포함하여 Google Cloud에 대한 팀 학습 및 교육을 수행합니다.
4. Google Cloud에서 실험 및 개념 증명을 빌드합니다.
5. 대상 환경의 총 소유 비용(TCO)을 계산합니다.
6. 마이그레이션하려는 워크로드의 순서와 우선순위를 결정합니다.

데이터베이스 평가 단계에서는 비슷한 성능 요구의 소스와 일치하는 대상 Cloud SQL 데이터베이스 인스턴스의 크기와 사양을 선택할 수 있습니다. 특히 디스크 크기와 처리량, IOPS, vCPU 수에 주의해야 합니다. 마이그레이션은 잘못된 대상 데이터베이스 인스턴스 크기 조정으로 인해 실패하거나 문제가 발생할 수 있습니다. 잘못된 크기 조정은 마이그레이션 시간 장기화, 데이터베이스 성능 문제, 데이터베이스 오류, 애플리케이션 성능 문제로 이어질 수 있습니다. Cloud SQL 인스턴스를 결정할 때는 디스크 성능이 디스크 크기와 vCPU 수를 기반으로 한다는 것에 주의해야 합니다.

평가 단계와 이러한 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색을 참조하세요. 다음 섹션은 해당 문서의 정보를 기반으로 합니다.

Amazon RDS 인스턴스의 인벤토리 빌드

마이그레이션 범위를 정의하기 위해서는 인벤토리를 만들고 Amazon RDS 인스턴스에 대한 정보를 수집합니다. 이론적으로 이 프로세스는 자동화 방식으로 처리해야 합니다. 수동적인 접근 방식은 오류 가능성이 높고 잘못된 가정으로 이어질 수 있습니다.

Amazon RDS와 Cloud SQL은 특성, 인스턴스 사양, 작업이 비슷하지 않을 수 있습니다. 일부 기능은 다르게 구현되거나 제공되지 않을 수 있습니다. 이러한 차이점에는 인프라, 스토리지, 인증, 보안, 복제, 백업, 고가용성, 리소스 용량 모델, 특정 데이터베이스 엔진 기능 통합, 확장 프로그램이 포함될 수 있습니다. 데이터베이스 엔진 유형, 인스턴스 크기, 아키텍처에 따라 데이터베이스 매개변수 설정의 기본값에도 차이가 있습니다.

벤치마킹은 마이그레이션할 워크로드를 더 효과적으로 이해하고 마이그레이션 대상 환경의 올바른 아키텍처를 정의하는 데 도움이 됩니다. Google Cloud 대상 환경의 성능 요구를 측정하기 위해서는 성능에 대한 정보 수집이 중요합니다. 벤치마킹 개념과 도구는 마이그레이션 프로세스의 테스트 및 검증 수행 단계에서 자세히 설명하지만 인벤토리 빌드 단계에도 적용됩니다.

평가용 도구

현재 인프라에 대한 초기 개요 평가를 보려면 migVisor 및 데이터베이스 마이그레이션 평가 도구(DMA)와 같은 다른 전문적인 데이터베이스 평가 도구와 함께 Google Cloud Migration Center를 사용하는 것이 좋습니다.

Migration Center에서는 Google Cloud로의 데이터베이스 마이그레이션에 대한 기술 적합성을 포함하여 애플리케이션 및 데이터베이스 환경의 전체 평가를 수행할 수 있습니다. 각 소스 데이터베이스의 크기 및 구성 추천을 받고 서버 및 데이터베이스에 대해 총소유비용(TCO) 보고서를 작성합니다.

Migration Center를 사용해서 AWS 환경을 평가하는 방법은 다른 클라우드 제공업체에서 데이터 가져오기를 참조하세요.

Migration Center 외에도 전문화된 도구인 migVisor를 사용할 수 있습니다. migVisor는 다양한 데이터베이스 엔진을 지원하며 특히 이기종 마이그레이션에 적합합니다. migVisor 소개는 migVisor 개요를 참조하세요.

migVisor는 마이그레이션 오류를 일으킬 수 있는 아티팩트 및 호환되지 않는 고유 데이터베이스 기능을 식별하고 해결 방법을 안내할 수 있습니다. migVisor는 또한 초기 크기 조정과 아키텍처를 포함하여 대상 Google Cloud 솔루션을 추천할 수 있습니다.

migVisor 데이터베이스 평가 결과는 다음을 제공합니다.

• 현재 데이터베이스 배포에 대한 포괄적인 탐색 및 분석
• 데이터베이스에 사용되는 고유 기능을 기반으로 작성된 마이그레이션 복잡성에 대한 세부 보고서
• 마이그레이션 이후 절감 비용, 마이그레이션 비용, 새로운 운영 예산에 관한 세부정보가 포함된 재무 보고서
• 비즈니스에 대한 중단을 최소화하고 데이터베이스 및 관련 애플리케이션을 이동하기 위한 단계별 마이그레이션 계획

평가 결과에 대한 일부 예시를 보려면 migVisor - 클라우드 마이그레이션 평가 도구를 참조하세요.

migVisor는 일시적으로 데이터베이스 서버 활용률을 늘려줍니다. 일반적으로 이러한 추가 부하는 3% 미만이며 피크 시간이 아닌 시간에 실행할 수 있습니다.

migVisor 평가 결과는 RDS 인스턴스에 대해 전체 인벤토리를 빌드하는 데 도움이 됩니다. 이 보고서에는 데이터베이스 토폴로지 세부정보, 백업 정책, 매개변수 설정, 사용 중인 특수 맞춤설정은 물론 일반적인 속성(데이터베이스 엔진 버전과 에디션, CPU, 메모리 크기)이 포함됩니다.

오픈소스 도구 사용을 선호할 경우에는 언급한 도구와 함께 또는 이러한 도구 대신 데이터 수집기 스크립트를 사용할 수 있습니다. 이러한 스크립트는 워크로드, 특성, 데이터베이스 객체, 데이터베이스 코드에 대한 세부정보를 수집하고 데이터베이스 인벤토리를 빌드하는 데 도움이 될 수 있습니다. 또한 스크립트는 일반적으로 마이그레이션 작업 추정을 포함하여 자세한 데이터베이스 마이그레이션 평가를 제공합니다.

Google 엔지니어들이 제작한 오픈소스 도구인 DMA를 사용하는 것이 좋습니다. 이 도구는 사용 중인 특성, 데이터베이스 로직, 데이터베이스 객체(스키마, 테이블, 뷰, 함수, 트리거, 저장 프로시저 포함)를 포함하여 완전하고 정확한 데이터베이스 평가를 제공합니다.

DMA를 사용하려면 Git 저장소에서 데이터베이스 엔진에 대해 컬렉션 스크립트를 다운로드하고 안내를 따릅니다. 결과 파일을 분석을 위해 Google Cloud로 보냅니다. Google Cloud는 데이터베이스 평가 판독값을 작성하여 제공하고 마이그레이션 여정의 다음 단계를 안내합니다.

마이그레이션 범위 및 감당 가능한 다운타임을 파악하고 문서화

이 단계에서는 마이그레이션 전략 및 도구에 영향을 주는 필수 정보를 기술합니다. 이제 다음 질문에 답변할 수 있습니다.

• 데이터베이스가 5TB보다 큰가요?
• 데이터베이스에 대규모 테이블이 있나요? 16TB보다 큰가요?
• 데이터베이스의 위치(리전 및 영역)가 어디이고 애플리케이션에 얼마나 가까운가요?
• 데이터가 얼마나 자주 변경되나요?
• 데이터 일관성 모델은 무엇인가요?
• 대상 데이터베이스 옵션에는 무엇이 있나요?
• 소스 데이터베이스와 대상 데이터베이스가 얼마나 호환되나요?
• 데이터가 물리적 위치에 있어야 하나요?
• 압축 및 보관처리할 수 있는 데이터가 있나요? 또는 마이그레이션이 전혀 필요하지 않은 데이터가 있나요?

마이그레이션 범위를 정의하려면 보관할 데이터와 마이그레이션할 데이터를 결정해야 합니다. 모든 데이터베이스를 마이그레이션하기 위해서는 상당한 시간과 노력이 필요할 수 있습니다. 일부 데이터는 소스 데이터베이스 백업에 유지될 수 있습니다. 예를 들어 오래된 로깅 테이블이나 보관처리된 데이터는 필요하지 않을 수 있습니다. 또는 전략 및 도구에 따라 마이그레이션 프로세스 후에 데이터를 이동하도록 결정할 수 있습니다.

결과와 영향을 비교하고 평가하는 데 도움이 되는 데이터 마이그레이션 기준을 설정합니다. 이러한 기준은 마이그레이션 전후의 데이터 상태를 나타내는 참조로 사용되며 의사결정에 도움이 됩니다. 데이터 마이그레이션의 성공 여부를 평가하기 위해서는 소스 환경을 측정하는 것이 중요합니다. 이러한 측정에는 다음이 포함됩니다.

• 데이터의 크기와 구조
• 데이터의 완전성과 일관성
• 가장 중요한 비즈니스 트랜잭션 및 프로세스의 기간과 성능

감당할 수 있는 다운타임을 결정해야 합니다. 다운타임이 비즈니스에 미치는 영향은 무엇인가요? 다운타임의 영향을 받는 사용자 수가 적은 데이터베이스 활동량이 낮은 기간이 있나요? 그렇다면 그러한 기간이 얼마나 오래 지속되고 언제 발생하나요? 읽기 전용 요청을 계속 처리하면서 쓰기 작업에 대해서만 일시적으로 다운타임을 설정하는 방식을 고려해 보세요.

배포 및 관리 프로세스 평가

인벤토리를 빌드한 후에는 데이터베이스에 대해 운영 및 배포 프로세스를 평가하고 마이그레이션 지원을 위해 조정이 필요한 방식을 결정합니다. 이러한 프로세스는 프로덕션 환경을 준비하고 유지보수하는 방법의 기초입니다.

다음 태스크를 수행할 방법을 고려하세요.

• 인스턴스의 보안 정책 정의 및 적용: 예를 들어 Amazon 보안 그룹을 대체해야 할 수 있습니다. Google IAM 역할, VPC 방화벽 규칙, VPC 서비스 제어를 사용해서 Cloud SQL 인스턴스에 대한 액세스를 제어하고 VPC 내부의 데이터를 제한할 수 있습니다. SQL 서버용 Cloud SQL과 함께 Windows 인증을 사용하려는 경우 관리형 Microsoft AD를 배포하고 기존 Active Directory 인프라에 연결해야 합니다.
• 인스턴스 패치 적용 및 구성: 기존 배포 도구를 업데이트해야 할 수 있습니다. 예를 들어 Amazon 매개변수 그룹 또는 Amazon 옵션 그룹에서 커스텀 구성 설정을 사용 중일 수 있습니다. Google Cloud Storage 또는 Secret Manager를 사용해서 이러한 커스텀 구성 목록을 읽도록 프로비저닝 도구를 조정해야 할 수 있습니다.
• 모니터링 및 알림 인프라 관리: Amazon 소스 데이터베이스 인스턴스의 측정항목 카테고리는 마이그레이션 프로세스 중 관측 가능성을 제공합니다. 측정항목 카테고리에는 Amazon CloudWatch, 성능 통계, 향상된 모니터링, OS 프로세스 목록이 포함될 수 있습니다.

평가 완료

Amazon RDS 환경에서 인벤토리를 빌드한 후 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색에 설명된 대로 평가 단계의 나머지 활동을 완료하세요.

기반 계획 및 빌드

계획 및 빌드 단계에서는 다음을 수행하도록 인프라를 프로비저닝하고 구성합니다.

• Google Cloud 환경에서 워크로드를 지원합니다.
• AWS 환경과 Google Cloud 환경을 연결하여 마이그레이션을 완료합니다.

Google Cloud에서 기반 구축

계획 및 빌드 단계는 다음과 같은 태스크로 구성됩니다.

1. 리소스 계층 구조를 빌드합니다.
2. ID 및 액세스 관리를 구성합니다.
3. 결제를 설정합니다.
4. 네트워크 연결을 설정합니다.
5. 보안을 강화합니다.
6. 로깅, 모니터링, 알림을 설정합니다.

이러한 각 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 기초 빌드를 참조하세요.

모니터링 및 알림

Cloud SQL 모니터링 대시보드를 포함하여 여러 Google Cloud 제품에 대해 사전 정의된 대시보드가 포함된 Google Cloud Monitoring을 사용합니다. 또는 Datadog 및 Splunk와 같이 Google Cloud에 통합된 제3자 모니터링 솔루션 사용을 고려할 수 있습니다. 자세한 내용은 데이터베이스 관측 가능성 정보를 참조하세요.

SQL 서버용 Amazon RDS 인스턴스를 SQL 서버용 Cloud SQL로 마이그레이션

인스턴스를 마이그레이션하려면 다음을 수행합니다.

1. 지속적 복제 또는 예약된 유지보수 중에서 마이그레이션 전략을 선택합니다.

2. 선택한 전략 및 요구사항에 따라 마이그레이션 도구를 선택합니다.

3. 준비 및 실행 태스크를 포함하여 각 데이터베이스 마이그레이션에 대한 마이그레이션 계획과 타임라인을 정의합니다.

4. 마이그레이션 도구가 올바르게 작동하도록 수행해야 하는 준비 태스크를 정의합니다.

5. 마이그레이션을 구현하는 작업 활동이 포함된 실행 태스크를 정의합니다.

6. 각 실행 태스크에 대해 대체 시나리오를 정의합니다.

7. 별개의 스테이징 환경에서 수행할 수 있는 테스트 및 검증을 수행합니다.

8. 마이그레이션을 수행합니다.

9. 프로덕션 컷오버를 수행합니다.

10. 소스 환경을 정리하고 대상 인스턴스를 구성합니다.

11. 조정 및 최적화를 수행합니다.

각 단계에 대해서는 다음 섹션에서 설명합니다.

마이그레이션 전략 선택

이 단계에서는 각 데이터베이스의 사용 사례에 가장 적합한 마이그레이션 전략 중 하나를 평가하고 선택하기 위해 충분한 정보를 확인할 수 있습니다.

• 예약된 유지보수(일회성 마이그레이션): 이 접근 방법은 다운타임을 감당할 수 있을 때 이상적입니다. 이 옵션은 워크로드와 서비스에 많은 리팩터링이 필요하지 않기 때문에 비용과 복잡성이 비교적 낮습니다. 하지만 완료 전에 마이그레이션이 실패할 경우 프로세스를 다시 시작해야 하기 때문에 다운타임이 길어집니다.

• 지속적 복제(연속 마이그레이션): 미션 크리티컬 데이터베이스를 위한 이 옵션은 낮은 데이터 손실 위험과 니어제로 다운타임을 제공합니다. 작업이 여러 조각으로 분할되기 때문에 오류가 발생해도 롤백 및 반복 처리 시간이 줄어듭니다. 하지만 설정이 복잡하고 계획과 시간이 더 필요합니다. 또한 데이터베이스 인스턴스에 연결하는 애플리케이션을 리팩터링하기 위해 추가적인 노력이 필요합니다. 다음 변형 중 하나를 고려하세요.

  • 동시 마이그레이션의 한 형식인 Y(쓰기 및 읽기) 접근 방식을 사용해서 마이그레이션 중에 소스 및 대상 인스턴스 모두에서 데이터를 복제합니다.
  • Y(쓰기 및 읽기) 접근 방식에 필요한 리팩터링 노력을 줄여주는 데이터 액세스 마이크로서비스를 사용합니다.

데이터 마이그레이션 전략에 대한 자세한 내용은 데이터 마이그레이션 접근 방식 평가를 참조하세요.

다음 다이어그램은 단일 데이터베이스의 마이그레이션 전략을 결정할 때 발생 가능한 질문 예시를 기준으로 플로우 차트를 보여줍니다.

위 플로우 차트는 다음과 같은 선택 지점을 보여줍니다.

• 다운타임을 감당할 수 있나요?

  • 그렇지 않으면 지속적 복제 마이그레이션 전략을 채택합니다.
  • 그렇다면 다음 선택 지점으로 이동합니다.

• 데이터를 이전할 때 단순 이전 기간 동안 발생하는 다운타임을 감당할 수 있나요? 컷오버 창은 데이터베이스 백업을 수행하고, 이를 Cloud SQL로 전송하고, 복원하고, 애플리케이션을 새 데이터베이스로 전환하는 데 걸리는 시간을 나타냅니다.

  • 그렇지 않으면 지속적 복제 마이그레이션 전략을 채택합니다.
  • 그렇다면 예약된 유지보수 마이그레이션 전략을 채택합니다.

데이터베이스가 동일한 인스턴스에 있더라도 각 데이터베이스에 대한 전략이 달라질 수 있습니다. 다양한 전략을 혼합하여 최적의 결과를 생성할 수 있습니다. 예를 들어 작고 가끔 사용되는 데이터베이스는 예약된 유지보수 접근 방법을 사용해서 마이그레이션하고 다운타임 비용이 높은 미션 크리티컬 데이터베이스에는 지속적 복제를 사용할 수 있습니다.

일반적으로 마이그레이션은 초기 소스 인스턴스와 대상 인스턴스 사이의 전환이 발생할 때 완료된 것으로 간주됩니다. 복제가 사용되면 해당 마이그레이션이 중지되고 모든 읽기 및 쓰기 작업이 대상 인스턴스에서 수행됩니다. 두 인스턴스가 동기화되었을 때 전환을 수행하면 데이터 손실이 없고 다운타임이 최소화됩니다.

데이터 마이그레이션 전략 및 배포에 대한 자세한 내용은 데이터베이스 마이그레이션 분류 및 배포 전략을 참조하세요.

다운타임 및 마이그레이션 관련 영향 최소화

애플리케이션 다운타임이 없는 마이그레이션 구성은 더 복잡한 설정이 필요합니다. 설정의 복잡성과 트래픽이 낮은 영업시간 중에 예약되는 다운타임 간에 적절한 균형을 찾아야 합니다.

각 마이그레이션 전략에는 마이그레이션 프로세스와 연관된 영향과 장단점이 있습니다. 예를 들어 복제 프로세스에 따라 소스 인스턴스에 추가 부하가 발생하고 애플리케이션이 복제 지연의 영향을 받을 수 있습니다. 애플리케이션(및 고객)은 새 데이터베이스를 사용하기 전에 복제 지연이 지속되는 만큼 애플리케이션 다운타임을 기다려야 할 수 있습니다. 실제로는 다음과 같은 요인에 따라 다운타임이 증가할 수 있습니다.

• 데이터베이스 쿼리는 완료되는 데 몇 초 정도 시간이 걸릴 수 있습니다. 마이그레이션 중 실행 중인 쿼리가 중단될 수 있습니다.
• 데이터베이스가 크거나 버퍼 메모리가 크면 캐시를 채우는 데 시간이 걸릴 수 있습니다.
• 소스에서 중지되고 Google Cloud에서 재시작된 애플리케이션에서는 Google Cloud 데이터베이스 인스턴스 연결이 설정될 때까지 약간의 지연이 발생할 수 있습니다.
• 애플리케이션에 대한 네트워크 경로를 다시 라우팅해야 합니다. DNS 항목의 설정 방법에 따라 이 작업에 시간이 오래 걸릴 수 있습니다. DNS 레코드를 업데이트할 때는 마이그레이션 전에 TTL을 줄입니다.

다음과 같은 일반적인 방법은 다운타임 및 영향을 최소화하는 데 도움이 될 수 있습니다.

• 다운타임이 워크로드에 미치는 영향을 최소화할 수 있는 기간을 찾습니다. 예를 들어 정상 영업시간 이외의 시간이나 주말 또는 기타 예약된 유지보수 기간을 찾습니다.
• 여러 단계에서 마이그레이션 및 프로덕션 컷오버를 진행할 수 있는 워크로드 부분을 식별합니다. 애플리케이션에는 영향 없이 격리, 조정, 마이그레이션이 가능한 여러 구성요소가 포함될 수 있습니다. 예를 들어 프런트엔드, CRM 모듈, 백엔드 서비스, 보고 플랫폼 등이 있습니다. 이러한 모듈에는 프로세스 중 초반 또는 후반에 마이그레이션을 수행하도록 예약할 수 있는 자체 데이터베이스가 포함될 수 있습니다.
• 대상 데이터베이스에서 지연 시간을 어느 정도 감당할 수 있으면 점진적 마이그레이션 구현을 고려합니다. 소규모의 증분 배치를 사용해서 데이터를 전송하고 일부 워크로드를 수정하여 대상 인스턴스에서 오래된 데이터를 처리할 수 있습니다.
• 최소한의 마이그레이션 영향을 지원하기 위해 애플리케이션 리팩터링을 고려합니다. 예를 들어 소스 및 대상 데이터베이스 모두 쓰기를 수행하도록 애플리케이션을 수정하고 애플리케이션 수준의 복제를 구현할 수 있습니다.

마이그레이션 도구 선택

성공적인 마이그레이션을 위해 가장 중요한 요소는 올바른 마이그레이션 도구를 선택하는 것입니다. 마이그레이션 전략이 결정된 다음 마이그레이션 도구를 검토하고 결정합니다.

특정 마이그레이션 사용 사례에 맞게 최적화된 여러 도구를 사용할 수 있습니다. 사용 사례에는 다음이 포함될 수 있습니다.

• 마이그레이션 전략(예약된 유지보수 또는 지속적 복제)
• 소스 및 대상 데이터베이스 엔진과 엔진 버전
• 소스 인스턴스와 대상 인스턴스가 위치해 있는 환경
• 데이터베이스 크기. 데이터베이스가 클수록 초기 백업을 마이그레이션하는 데 시간이 오래 걸립니다.
• 데이터베이스 변경 빈도
• 마이그레이션을 위한 관리형 서비스 사용 가능성

원활한 마이그레이션 및 컷오버를 보장하기 위해서는 애플리케이션 배포 패턴, 인프라 조정, 커스텀 마이그레이션 애플리케이션을 사용할 수 있습니다. 그러나 관리형 마이그레이션 서비스라고 부르는 전문화된 도구는 한 환경에서 다른 환경으로 데이터, 애플리케이션, 심지어 전체 인프라를 이동하는 과정에 도움이 될 수 있습니다. 이러한 도구는 소스 데이터베이스에서 데이터 추출을 실행하고, 대상 데이터베이스로 데이터를 안전하게 전송하고, 전송 중 데이터를 선택적으로 수정할 수 있습니다. 이러한 기능을 통해 복잡한 마이그레이션 로직을 캡슐화하고 마이그레이션 모니터링 기능을 제공합니다.

관리형 마이그레이션 서비스는 다음과 같은 이점이 있습니다.

• 다운타임 최소화: 서비스가 사용 가능한 경우 데이터베이스 엔진의 기본 제공되는 복제 기능을 사용하고 복제본 승격을 수행합니다.

• 데이터 무결성 및 보안 보장: 소스에서 대상 데이터베이스로 데이터가 안전하게, 신뢰할 수 있는 방식으로 전송됩니다.

• 일관적인 마이그레이션 경험 제공: 관리 및 모니터링 가능한 데이터베이스 마이그레이션 실행 파일을 사용해서 여러 다른 마이그레이션 기법과 패턴을 일관적이고 공통적인 인터페이스로 통합할 수 있습니다.

• 탄력적이고 입증된 마이그레이션 모델 제공: 데이터베이스 마이그레이션은 자주 발생하지 않지만 치명적인 이벤트입니다. 초보자 실수와 기존 솔루션과의 문제를 방지하기 위해서는 커스텀 솔루션을 빌드하는 대신 숙련된 전문가의 도구를 사용할 수 있습니다.

• 비용 최적화: 관리형 마이그레이션 서비스는 커스텀 마이그레이션 솔루션을 위한 추가 서버 및 리소스를 프로비저닝하는 것보다 비용 효율적일 수 있습니다.

다음 섹션에서는 선택한 마이그레이션 전략에 따라 달라지는 마이그레이션 도구 추천에 대해 설명합니다.

예약된 유지보수 마이그레이션을 위한 도구

다음 하위 섹션에서는 일회성 마이그레이션에 사용할 수 있는 도구와 이러한 도구의 제한사항 및 권장사항에 대해 설명합니다.

기본 제공 데이터베이스 엔진 백업

허용 가능한 다운타임이 상당히 크고 소스 데이터베이스가 비교적 정적이면 데이터베이스 엔진의 기본 제공 백업 및 복원 기능을 사용할 수 있습니다.

특히 데이터베이스 수가 많을 때는 설정 및 동기화를 위한 노력이 필요하지만 일반적으로 데이터베이스 엔진 백업을 쉽게 직관적으로 사용할 수 있습니다. 이 방법은 모든 데이터베이스 크기에 적합하며 일반적으로 큰 인스턴스의 경우 다른 도구보다 효과적입니다.

데이터베이스 엔진 백업의 일반적인 제한사항은 다음과 같습니다.

• 백업은 특히 수동으로 수행할 때 오류가 발생하기 쉽습니다.
• 백업이 올바르게 관리되지 않을 경우에는 데이터가 안전하지 않습니다.
• 백업은 적절한 모니터링 기능이 부족합니다.

이 접근 방법을 선택할 경우에는 다음과 같은 제한사항과 권장사항을 고려하세요.

• 5TB보다 큰 데이터베이스 백업을 위해서는 스트라이프 처리된 백업(여러 파일의 백업)을 사용합니다.
• 스트라이프 처리된 백업을 사용할 때는 동시에 백업하거나 복원할 수 있는 백업 파일이 10개로 제한됩니다.
• 소스 데이터베이스 인스턴스의 동일한 Amazon 리전에 있는 Amazon S3 버킷에 백업해야 합니다.
• 데이터베이스 백업은 인스턴스 수준에서 관리되기 때문에 SQL 서버 로그인, 권한, 서버 역할을 포함하지 않습니다. 이러한 유형의 데이터를 소스 인스턴스에서 대상 인스턴스로 전송하려면 PowerShell 스크립트 또는 DBAtools와 같은 도구를 사용합니다.

제한사항과 권장사항에 대한 자세한 내용은 SQL 서버용 Cloud SQL로 데이터 가져오기 및 내보내기 권장사항 및 SQL 서버용 Cloud SQL 알려진 문제를 참조하세요.

예약된 유지보수 마이그레이션을 위한 기타 접근 방법

다른 접근 방법을 사용하면 예약된 유지보수 마이그레이션 프로세스의 제어 수준과 유연성이 향상될 수 있습니다.

예를 들어 데이터 내보내기 및 가져오기를 위해 플랫 파일을 사용하거나 커스텀 스크립트를 사용하여 다음을 수행할 수 있습니다.

• 마이그레이션 중 데이터에 대해 변환, 검사, 기타 작업을 수행합니다. 예를 들어 소스 데이터에 대해 검증, 집계, 정규화, 비정규화를 수행합니다.
• 마이그레이션할 구조와 남겨둘 항목을 선택합니다. 플랫 파일에서 가져오기에 사용할 일부 테이블만 추출하도록 선택할 수 있습니다.
• 도메인, 소스, 기간, 기타 커스텀 기준에 다라 데이터를 필터링하도록 선택합니다. 예를 들어 기간 기준점에 도달한 데이터를 제외하고, 마이그레이션 전에 이를 소스 데이터베이스의 파일 또는 최종 백업에 저장할 수 있습니다.
• 데이터베이스 구조를 리팩터링하고 발생하는 다운타임을 마이그레이션 다운타임과 동기화합니다.
• 여러 인스턴스 또는 데이터베이스를 단일 인스턴스 또는 데이터베이스에 통합하여 운영 비용을 줄이고 확장성 문제를 해결할 수 있습니다. 예를 들어 고객당 하나의 인스턴스, 데이터베이스, 스키마를 지정하는 접근 방법을 멀티 테넌시에 최적화된 단일 데이터베이스 구조로 변경할 수 있습니다.

다른 접근 방법은 다음과 같습니다.

• CSV 또는 JSON 파일 사용: 이 접근 방법에서는 데이터베이스의 데이터를 파일로 추출한 후 파일을 대상 인스턴스로 가져옵니다.

  • 이 접근 방법은 일반적으로 속도가 느리더라도 테이블 일부(또는 지정된 테이블 내의 데이터)를 마이그레이션하는 데 도움이 됩니다.
  • CSV 및 JSON 형식은 여러 도구에서 지원됩니다.
  • 프로세스를 자동화할 경우 일괄 처리된 지속적 복제 마이그레이션으로 전환하는 옵션을 선택할 수 있습니다.

• Microsoft의 SQL 서버 가져오기 및 내보내기 마법사 사용: 이 도구는 SQL 서버 통합 서비스(SSIS)를 사용하며, 데이터베이스 엔진 또는 플랫 파일과 같은 여러 소스로부터 데이터를 가져올 수 있게 해줍니다.

• SQL 서버 생성 및 게시 스크립트 마법사 및 bcp 유틸리티 사용: 이 도구는 Microsoft SQL Server Management Studio에 포함되어 있습니다.

  • 이 접근 방법을 사용하면 전체 데이터베이스 스키마에 대해 또는 그 중 일부에 대해서만 스크립트를 만들 수 있습니다.
  • bcp 유틸리티를 사용하면 데이터를 스크립트로 작성하고 파일로 내보낼 수 있습니다.

• 소스에 Amazon RDS 표준이 사용되는 경우 스냅샷 복제 사용:

  • 이 접근 방법에서는 RDS 인스턴스의 SQL 서버 백업을 Compute Engine에 있는 또 다른 SQL 서버 독립형 인스턴스로 복원합니다. 그런 후 스냅샷 복제를 사용해서 SQL 서버용 Cloud SQL로 마이그레이션합니다.
  • 스냅샷 생성은 소스 테이블을 계속 잠금 상태로 유지하여 워크로드에 영향을 줄 수 있습니다.
  • 스냅샷 복제는 Amazon RDS 서버에 대해 추가적인 부하를 일으킬 수 있습니다.
  • 하지만 마이그레이션 또는 복제할 객체를 유연하게 선택할 수 있습니다.
  • 자세한 내용은 스냅샷 복제를 사용하여 SQL Server 2017에서 SQL 서버용 Cloud SQL로 데이터 마이그레이션을 참조하세요.

지속적 복제 마이그레이션을 위한 도구

다음 다이어그램은 지속적 복제 마이그레이션 전략을 사용할 때 단일 데이터베이스를 위한 마이그레이션 도구를 선택하는 데 도움이 되는 질문이 포함된 플로우 차트를 보여줍니다.

위 플로우 차트는 다음과 같은 선택 지점을 보여줍니다.

• 관리형 마이그레이션 전략 사용을 선호하시나요?

  • 그렇다면 다음 선택 지점으로 넘어갑니다. 일정 수준의 최소 다운타임을 감당할 수 있고 데이터 변환 또는 실시간 동기화가 필요하지 않으면 Database Migration Service가 권장됩니다. 그렇지 않으면 제3자 옵션을 탐색합니다.
  • 그렇지 않으면 다음 선택 지점으로 진행합니다. 데이터베이스 엔진의 기본 제공 복제가 지원되는 경우 기본 제공 복제를 사용하는 것이 좋습니다. 그렇지 않으면 다른 마이그레이션 옵션을 탐색하는 것이 좋습니다.

• 최소한의 다운타임을 감당할 수 있고 데이터 변환 또는 실시간 동기화 없이 마이그레이션할 수 있나요?

  • 그렇다면 Database Migration Service가 권장됩니다.
  • 그렇지 않으면 제3자 옵션을 탐색합니다.

• 데이터베이스 엔진의 특정 기본 제공 복제가 지원되나요?

  • 그렇다면 기본 제공 복제를 사용하는 것이 좋습니다.
  • 그렇지 않으면 다른 마이그레이션 옵션을 탐색하는 것이 좋습니다.

다음 섹션에서는 지속적 복제 마이그레이션에 사용할 수 있는 도구와 그 제한사항 및 권장사항에 대해 설명합니다.

지속적 복제 마이그레이션을 위한 Database Migration Service

Database Migration Service는 소스가 Amazon RDS일 때 SQL 서버용 Cloud SQL로의 동종 마이그레이션을 지원합니다.

Database Migration Service는 비용 효율적이고 직관적인 도구입니다. 다음 상황에서는 Database Migration Service가 권장됩니다.

• 최소한의 다운타임을 감당할 수 있습니다.
• 실시간 동기화가 필요하지 않습니다.
• 마이그레이션 중에 데이터 변환을 수행할 필요가 없습니다.

이 도구를 선택할 경우에는 다음과 같은 제한사항과 권장사항을 고려하세요.

• 다운타임의 양은 트랜잭션 로그 백업의 빈도에 따라 달라집니다.
• 데이터베이스 백업은 인스턴스 수준에서 관리되기 때문에 SQL 서버 로그인, 권한, 서버 역할을 포함하지 않습니다. 마이그레이션하려면 소스 인스턴스에서 스크립트를 작성하고 PowerShell 스크립트 또는 DBAtools와 같은 도구를 사용하여 대상 인스턴스로 전송합니다.

제한사항의 전체 목록은 알려진 제한사항을 참조하세요.

데이터베이스 엔진 기본 제공 복제

Cloud SQL은 SQL 서버용 복제를 지원합니다. 하지만 SQL 서버용 표준 Amazon RDS는 구독자만 될 수 있습니다. Amazon RDS 표준의 기본 제공 복제는 사용할 수 없습니다. SQL 서버용 Amazon RDS 커스텀만 기본 제공 게시자로 설정할 수 있습니다.

Amazon RDS에서 지원되는 기능과 지원되지 않는 기능 목록은 Microsoft SQL Server용 Amazon RDS를 참조하세요.

지속적 복제 마이그레이션을 위한 다른 접근 방법

다른 지속적인 복제 마이그레이션 접근 방법에는 다음이 포함됩니다.

• Y(쓰기 및 읽기)를 수행하거나 데이터 액세스 마이크로서비스를 사용하도록 애플리케이션을 리팩터링합니다.

  • 지속적 복제는 애플리케이션에서 수행됩니다.
  • 마이그레이션 작업은 리팩터링 또는 데이터베이스 인스턴스에 연결하는 도구의 개발에 집중되어 있습니다.
  • 그런 후 리더 애플리케이션을 점진적으로 리팩터링하고 대상 인스턴스를 사용하도록 배포합니다.

• 소스 인스턴스에서 주기적으로 데이터를 쿼리하고, 새 데이터만 필터링하고, CSV, JSON, Parquet 파일에 데이터를 기록하는 함수를 구현합니다.

  • 이러한 파일은 Google Cloud Storage 버킷에 저장됩니다.
  • Cloud Functions를 사용해서 대상 데이터베이스 인스턴스에 즉시 파일을 기록할 수 있습니다.
  • 변경 데이터 캡처(CDC) 기능은 거의 실시간 복제 마이그레이션을 달성하는 데 도움이 될 수 있습니다.
  • AWS Database Migration Service(AWS DMS)를 사용해서 Parquet 형식으로 Amazon S3 데이터 레이크에 CDC를 스트리밍할 수 있습니다.
  • 파일을 읽고 콘텐츠를 Cloud SQL에 기록하는 커스텀 구현을 설정할 수 있습니다.

지속적 복제 마이그레이션을 위한 제3자 도구

제3자 도구를 사용하도록 결정할 때는 대부분의 데이터베이스 엔진에 사용할 수 있는 다음 권장사항 중 하나를 선택합니다.

Striim은 실시간으로 데이터 수집, 필터링, 변환, 강화, 집계, 분석, 제공을 수행할 수 있는 엔드 투 엔드 방식의 인메모리 플랫폼입니다.

• 장점:

  • 대용량 데이터 볼륨과 복잡한 마이그레이션을 처리합니다.
  • SQL 서버를 위한 기본 제공 변경 데이터 캡처를 지원합니다.
  • 사전 구성된 연결 템플릿과 노 코드 파이프라인을 지원합니다.
  • 트랜잭션 부하가 큰 상황에서 작동하는 미션 크리티컬 대규모 데이터베이스를 처리할 수 있습니다.
  • 일회만 전송을 지원합니다.

• 단점:

  • 오픈소스가 아닙니다.
  • 특히 긴 마이그레이션에는 비용이 증가할 수 있습니다.
  • 데이터 정의 언어(DDL) 작업이 전파되는 방식에 일부 제한이 있습니다. 자세한 내용은 지원되는 DDL 작업 및 스키마 개선 노트 및 제한사항을 참조하세요.

Striim에 대한 자세한 내용은 Google Cloud에서 Striim 실행을 참조하세요.

Debezium은 CDC를 위한 오픈소스 분산 플랫폼이며 데이터 변경사항을 외부 구독자로 스트리밍할 수 있습니다.

• 장점:

  • 오픈소스
  • 강력한 커뮤니티 지원
  • 비용 효율성
  • 행, 테이블, 데이터베이스에 대한 세분화된 제어
  • 데이터베이스 트랜잭션 로그에서 실시간 변경 캡처 특화 기능

• 과제:

  • Kafka 및 ZooKeeper에 대한 실무 경험이 필요합니다.
  • 데이터 변경사항이 최소 1회 이상 전달되므로 중복 처리가 필요합니다.
  • Grafana 및 Prometheus를 사용하는 수동 모니터링 설정
  • 증분 배치 복제 지원 없음

Debezium 마이그레이션에 대한 자세한 내용은 Debezium을 사용한 거의 실시간 데이터 복제를 참조하세요.

마이그레이션 계획 및 타임라인 정의

성공적인 데이터베이스 마이그레이션 및 프로덕션 컷오프를 위해서는 잘 정의된 포괄적인 마이그레이션 계획을 준비하는 것이 좋습니다. 비즈니스에 미치는 영향을 줄이기 위해서는 모든 필수 작업 항목을 목록으로 작성하는 것이 좋습니다.

마이그레이션 범위를 정의하면 데이터베이스 마이그레이션 프로세스를 시작 하기 전과 진행 하는 동안 그리고 이후에 수행해야 하는 작업 태스크를 알 수 있습니다. 예를 들어 데이터베이스에서 특정 테이블을 마이그레이션하지 않도록 결정한 경우에는 이러한 필터링을 구현하기 위해 마이그레이션 이전 또는 마이그레이션 이후 태스크가 필요할 수 있습니다. 또한 데이터베이스 마이그레이션이 기존 서비스수준계약(SLA) 및 비즈니스 연속성 계획에 영향을 주지 않도록 해야 합니다.

마이그레이션 계획 문서 작성에는 다음 문서를 포함하는 것이 좋습니다.

• 기술 설계 문서(TDD)
• RACI 표
• 타임라인(예: T-Minus 계획)

데이터베이스 마이그레이션은 반복적인 프로세스이며 첫 번째 마이그레이션은 이후의 마이그레이션보다 속도가 느린 경우가 많습니다. 일반적으로 잘 계획된 마이그레이션은 문제 없이 실행되지만 계획되지 않은 문제가 발생할 수도 있습니다. 항상 롤백 계획을 준비하는 것이 좋습니다. Google Cloud로 마이그레이션: 마이그레이션 계획 검증을 위한 권장사항을 따르세요.

TDD

TDD는 프로젝트에 대해 수행할 모든 기술적 결정을 문서로 작성합니다. TDD에 다음을 포함하세요.

• 비즈니스 요구사항과 심각성
• 복구 시간 목표(RTO)
• 복구 지점 목표(RPO)
• 데이터베이스 마이그레이션 세부정보
• 마이그레이션 작업 추정치
• 마이그레이션 검증 권장사항

RACI 표

일부 마이그레이션 프로젝트에는 RACI 표가 필요합니다. RACI 표는 마이그레이션 프로젝트 내에서 태스크 및 결과물을 담당할 개인 또는 그룹을 정의하는 공통 프로젝트 관리 문서입니다.

타임라인

마이그레이션해야 하는 각 데이터베이스의 타임라인을 준비합니다. 수행해야 하는 모든 작업 태스크와 정의된 시작 날짜와 예상 종료 날짜를 포함합니다.

각 마이그레이션 환경에 대해 T-minus 계획을 만드는 것이 좋습니다. T-minus 계획은 카운트다운 일정으로 구성되며 마이그레이션 프로젝트를 완료하는 데 필요한 모든 태스크와 함께 담당 그룹 및 예상 기간을 나열합니다.

타임라인은 마이그레이션 이전 준비 태스크 실행은 물론 데이터 전송이 수행된 이후 발생하는 태스크의 검증, 감사, 테스트도 고려해야 합니다.

마이그레이션 태스크의 기간은 일반적으로 데이터베이스 크기에 따라 달라지지만 비즈니스 로직 복잡성, 애플리케이션 사용량, 팀 가용성과 같은 다른 고려할 요소가 있습니다.

T-Minus 계획은 다음과 비슷할 수 있습니다.

날짜	단계	카테고리	태스크	역할	T-minus	상태
11/1/2023	마이그레이션 이전	평가	평가 보고서 작성	탐색팀	-21	완료
11/7/2023	마이그레이션 이전	대상 준비	설계 문서에 기술된 대로 대상 환경 설계	마이그레이션팀	-14	완료
11/15/2023	마이그레이션 이전	회사 거버넌스	마이그레이션 날짜 및 T-Minus 승인	경영진	-6	완료
11/18/2023	마이그레이션	DMS 설정	연결 프로필 빌드	클라우드 마이그레이션 엔지니어	-3	완료
11/19/2023	마이그레이션	DMS 설정	마이그레이션 작업 빌드 및 시작	클라우드 마이그레이션 엔지니어	-2	시작되지 않음
11/19/2023	마이그레이션	DMS 모니터링	소스 인스턴스에서 DMS 작업 및 DDL 변경사항 모니터링	클라우드 마이그레이션 엔지니어	-2	시작되지 않음
11/21/2023	마이그레이션	DMS 컷오버	DMS 복제본 승격	클라우드 마이그레이션 엔지니어	0	시작되지 않음
11/21/2023	마이그레이션	마이그레이션 검증	데이터베이스 마이그레이션 검증	마이그레이션팀	0	시작되지 않음
11/21/2023	마이그레이션	애플리케이션 테스트	기능 및 성능 테스트 실행	마이그레이션팀	0	시작되지 않음
11/22/2023	마이그레이션	회사 거버넌스	마이그레이션 검증 GO 또는 NO GO	마이그레이션팀	1	시작되지 않음
11/23/2023	마이그레이션 이후	모니터링 검증	모니터링 구성	인프라팀	2	시작되지 않음
11/25/2023	마이그레이션 이후	보안	DMS 사용자 계정 삭제	보안팀	4	시작되지 않음

여러 데이터베이스 마이그레이션

마이그레이션할 데이터베이스가 여러 개인 경우 마이그레이션 계획에 모든 마이그레이션에 대한 태스크를 포함해야 합니다.

이상적으로는 더 작고 미션 크리티컬하지 않은 데이터베이스를 마이그레이션하는 것으로 프로세스를 시작하는 것이 좋습니다. 이 접근 방법은 마이그레이션 프로세스 및 도구 설정에 대한 지식 및 신뢰도를 쌓는 데 도움이 될 수 있습니다. 또한 전체 마이그레이션 일정의 초기 단계에서 프로세스의 결점을 감지할 수 있습니다.

마이그레이션할 데이터베이스가 여러 개인 경우 타임라인을 병렬화할 수 있습니다. 예를 들어 다음 다이어그램에 표시된 것처럼 마이그레이션 프로세스 속도를 높이기 위해 크기가 작거나, 정적이거나, 미션 크리티컬 정도가 낮은 데이터베이스 그룹을 동시에 마이그레이션하도록 선택할 수 있습니다.

다이어그램에 표시된 예시에서 데이터베이스 1~4는 동시에 마이그레이션되는 소규모 데이터베이스 그룹입니다.

준비 태스크 정의

준비 태스크는 마이그레이션 기본 요건을 충족하기 위해 완료해야 하는 모든 활동입니다. 준비 태스크가 없으면 마이그레이션이 수행되지 않거나 마이그레이션된 데이터베이스가 사용 불가능한 상태로 될 수 있습니다.

준비 태스크는 다음과 같이 분류할 수 있습니다.

• Amazon RDS 인스턴스 준비 및 기본 요건
• 소스 데이터베이스 준비 및 기본 요건
• Cloud SQL 설정
• 마이그레이션 관련 설정

Amazon RDS 인스턴스 준비 및 기본 요건

다음과 같은 일반적인 설정 및 기본 요건 태스크를 고려하세요.

• 마이그레이션 경로에 따라 RDS 인스턴스에서 원격 연결을 허용해야 할 수 있습니다. RDS 인스턴스가 VPC에서 비공개로 구성된 경우 비공개 RFC 1918 연결이 Amazon 및 Google Cloud 사이에 존재해야 합니다.

• 필요한 포트에서 원격 연결을 허용하도록 새 보안 그룹을 구성해야 할 수 있습니다.

  • 기본적으로 AWS에서는 데이터베이스 인스턴스에 대해 네트워크 액세스가 해제되어 있습니다.
  • IP 주소 범위, 포트, 보안 그룹에서 액세스를 허용하는 규칙을 보안 그룹에 지정할 수 있습니다. 이 보안 그룹과 연결된 모든 데이터베이스 인스턴스에는 동일한 규칙이 적용됩니다.

• 진행 중인 복제(CDC를 통한 변경사항 스트리밍)를 위해서는 CDC를 사용 설정한 상태로 읽기 복제본이 아닌 전체 RDS 인스턴스를 사용해야 합니다. 자세한 내용은 SQL 서버에 변경 데이터 캡처 사용을 참조하세요.

• 제3자 도구를 사용하는 경우에는 일반적으로 해당 도구를 사용하기 전에 초기 설정과 구성이 필요합니다. 제3자 도구의 문서를 참조하세요.

소스 데이터베이스 준비 및 기본 요건

• 소스 데이터베이스에 마이그레이션 작업 중 사용 가능한 버퍼 스토리지와 메모리가 있는지 확인합니다. 예를 들어 트랜잭션 로그 백업 파일을 사용하는 경우 스토리지 사용을 모니터링하고 추가 버퍼 스토리지 공간을 마련합니다.
• 데이터베이스 매개변수 설정을 문서로 작성하고 마이그레이션 테스트 및 검증을 수행하기 전에 대상 인스턴스에서 이를 적용합니다.

• 프로덕션 소스 환경의 기준 측정을 수행합니다. 다음 사항을 고려하세요.

  • 데이터 크기와 워크로드 성능을 측정합니다. 중요한 쿼리 또는 트랜잭션 수행 시간이 평균 어느 정도인가요? 피크 타임에는 얼마나 오래 걸리나요?
  • 데이터베이스 마이그레이션의 충실도가 만족스러운지 확인하기 위해 나중에 비교할 수 있도록 기준 측정을 문서로 기록합니다. 프로덕션 워크로드를 전환하고 소스 환경을 사용 중단할지 아니면 대체 목적으로 여전히 필요한지 여부를 결정합니다.

Cloud SQL 설정

비슷한 성능 요구를 위해 소스와 일치하도록 대상 Cloud SQL 데이터베이스 인스턴스의 크기 및 사양을 신중하게 선택합니다. 특히 디스크 크기와 처리량, IOPS, vCPU 수에 주의해야 합니다. 잘못된 크기 조정은 마이그레이션 시간 장기화, 데이터베이스 성능 문제, 데이터베이스 오류, 애플리케이션 성능 문제로 이어질 수 있습니다.

대상이 올바르게 적합한지 확인합니다. Amazon RDS 구성 옵션이 Cloud SQL과 다를 수 있다는 것에 주의해야 합니다. Cloud SQL이 요구사항을 충족하지 않으면 Compute Engine의 데이터베이스를 포함하는 옵션을 고려합니다.

나중에 변경하려면 다시 만들어야 하기 때문에 Cloud SQL 인스턴스를 만들기 전에 다음 속성과 요구사항을 확인해야 합니다.

• 대상 Cloud SQL 인스턴스의 프로젝트 및 리전을 신중하게 선택해야 합니다. Cloud SQL 인스턴스를 Google Cloud 프로젝트와 리전 간에 마이그레이션하려면 데이터 전송이 필요합니다.

• Cloud SQL에서 일치하는 주 버전으로 마이그레이션합니다. 예를 들어 소스에 SQL 서버 15.0이 사용될 경우 SQL 서버용 Cloud SQL 15.0으로 마이그레이션합니다. 버전이 다르면 동일한 엔진 기능을 보장하기 위해 호환성 수준 설정이 동일해야 합니다.

• 기본 제공 데이터베이스 엔진 백업 또는 Database Migration Service를 사용하는 경우 사용자 정보를 개별적으로 복제합니다. 자세한 내용은 데이터베이스 엔진 특정 백업 섹션에서 제한사항을 검토하세요.

• 데이터베이스 엔진 특정 구성 플래그를 검토하고 소스 및 대상 인스턴스 값을 비교합니다. 해당 영향을 파악하고 동일해야 하는지 여부를 확인합니다. 예를 들어 소스 데이터베이스에서 sys.configurations 뷰의 값을 Cloud SQL 인스턴스의 값과 비교하는 것이 좋습니다. 모든 플래그가 동일해야 하는 것은 아니고 Cloud SQL 인스턴스에서는 일부 플래그 변경사항이 허용되지 않습니다.

Cloud SQL 설정에 대한 자세한 내용은 다음을 참조하세요.

• SQL 서버의 일반 권장사항
• SQL 서버의 인스턴스 구성 옵션
• SQL 서버의 데이터베이스 엔진 특정 플래그

마이그레이션 관련 설정

마이그레이션을 위해 파일 내보내기 및 가져오기를 사용하거나 Database Migration Service 마이그레이션 도구를 사용할 경우에는 Cloud Storage 버킷을 만들어야 합니다. 버킷에는 데이터베이스 및 트랜잭션 로그 백업 파일이 저장됩니다. Database Migration Service 사용에 대한 자세한 내용은 Cloud Storage 버킷에서 백업 파일 저장을 참조하세요.

복제를 사용하는 경우 Cloud SQL 복제본에 기본 데이터베이스에 대한 액세스 권한이 있는지 확인해야 합니다. 이 작업은 기술된 연결 옵션을 통해 수행할 수 있습니다.

시나리오 및 심각성에 따라 일반적으로 복제 방향을 되돌리는 작업이 포함된 대체 시나리오를 구현해야 할 수 있습니다. 이 경우 Cloud SQL에서 소스 Amazon 인스턴스로 다시 복제하는 추가적인 복제 메커니즘이 필요할 수 있습니다.

대부분의 제3자 도구에서는 마이그레이션 관련 리소스를 프로비저닝해야 합니다. 예를 들어 Striim의 경우 Google Cloud Marketplace를 사용해서 시작해야 합니다. 그런 후 Striim에서 마이그레이션 환경을 설정하기 위해 Flow Designer를 사용하여 애플리케이션을 만들고 변경하거나 기존 템플릿을 선택할 수 있습니다. 또한 텅스텐 쿼리 언어(TQL) 프로그래밍 언어를 사용하여 애플리케이션을 코딩할 수도 있습니다. 데이터 검증 대시보드를 사용하면 Striim 애플리케이션에서 처리되는 시각적 데이터 표현을 얻을 수 있습니다.

마이그레이션이 완료되고 검증된 후 Amazon 및 Google Cloud 환경을 연결하는 리소스를 사용 중단할 수 있습니다.

실행 태스크 정의

실행 태스크는 마이그레이션 작업 자체를 구현합니다. 태스크는 다음 하위 섹션에 설명된 대로 선택한 마이그레이션 도구에 따라 달라집니다.

데이터베이스 엔진 관련 백업

데이터베이스 관련 백업에 대한 자세한 내용 및 안내는 BAK 파일에서 SQL 서버용 Cloud SQL로 데이터 가져오기 및 SQL 서버용 RDS에서 데이터 내보내기를 참조하세요. 트랜잭션 로그 파일 업로드를 자동화하는 방법은 Amazon RDS의 트랜잭션 로그 파일 업로드 예약을 참조하세요.

Database Migration Service 마이그레이션 작업

소스 인스턴스에서 대상 데이터베이스로 데이터를 마이그레이션하기 위해 Database Migration Service에서 마이그레이션 작업을 정의하고 구성합니다. 마이그레이션 작업은 사용자 정의 연결 프로필을 통해 소스 데이터베이스 인스턴스에 연결됩니다.

작업이 성공적으로 실행될 수 있도록 모든 기본 요건을 테스트합니다. 워크로드가 마이그레이션 및 프로덕션 컷오버에 대해 약간의 다운타임을 감당할 수 있는 시간을 선택합니다.

마이그레이션 프로세스에는 일반적으로 다음 태스크가 포함됩니다.

• 소스 데이터베이스의 전체 백업을 내보내고 이를 Cloud Storage 버킷에 업로드합니다.
• 트랜잭션 로그 파일의 백업을 작성한 후 이를 동일한 Cloud Storage 버킷에 업로드합니다. 이 프로세스를 자동화하는 방법은 Amazon RDS의 트랜잭션 로그 파일 업로드 예약을 참조하세요.
• Database Migration Service에서 트랜잭션 로그 백업의 처리를 모니터링합니다.
• 소스 데이터베이스에 쓰기를 중지합니다.
• 소스와 대상이 동기화되어 최종 트랜잭션 로그 백업이 처리될 때까지 기다립니다.
• 진행 중인 복제를 중지하고 마이그레이션 작업을 승격합니다. 마이그레이션 작업을 승격하면 대상 Cloud SQL 인스턴스가 소스 데이터베이스 인스턴스에서 연결 해제되고 기본 인스턴스로 승격됩니다.
• 새 대상 데이터베이스를 가리키는 애플리케이션을 배포합니다.

자세한 마이그레이션 설정 프로세스는 SQL 서버 데이터베이스를 SQL 서버용 Cloud SQL로 마이그레이션을 참조하세요.

데이터베이스 엔진 기본 제공 복제

Amazon RDS 표준을 사용하는 경우 먼저 Amazon RDS 커스텀 버전으로 마이그레이션한 후 Cloud SQL로 마이그레이션해야 할 수 있습니다.

Cloud SQL은 SQL 서버용 복제를 지원합니다. 외부 서버에서 복제에 대한 자세한 내용은 스냅샷 복제를 사용하여 SQL Server 2017에서 SQL 서버용 Cloud SQL로 데이터 마이그레이션을 참조하세요.

제3자 도구

선택한 제3자 도구에 대한 모든 실행 태스크를 정의합니다. 예를 들어 Striim을 사용하도록 결정한 경우 네임스페이스에서 앱을 만들고 Amazon 인스턴스에 연결하도록 CDC 리더를 구성해야 합니다. 자세한 내용은 Striimㅇ에서 SQL 서버 설정 문서를 참조하세요.

대체 시나리오 정의

마이그레이션 프로세스 중에 발생할 수 있는 알 수 없는 문제로부터 보호하기 위해 각 마이그레이션 실행 태스크에 대해 대체 작업 항목을 정의합니다. 대체 태스크는 사용되는 마이그레이션 전략 및 도구에 따라 달라집니다.

대체를 사용하려면 일정 수준의 노력이 필요할 수 있습니다. 테스트 결과가 만족스러울 때까지는 프로덕션 컷오버를 수행하지 않는 것이 좋습니다. 심각한 중단을 방지하기 위해 데이터베이스 마이그레이션과 대체 시나리오 모두 올바르게 테스트해야 합니다.

모든 마이그레이션 실행 태스크에 대한 성공 기준과 기한을 정의합니다. 마이그레이션 테스트 실행을 수행하면 각 태스크의 예상 시간 정보를 수집하는 데 도움이 됩니다. 예를 들어 예약된 유지보수 마이그레이션의 경우 컷오버 기간으로 표시된 다운타임을 감당할 수 있습니다. 하지만 일회성 마이그레이션 작업 또는 백업 복원이 중간에 실패할 경우를 대비해서 그 다음의 작업을 계획하는 것이 중요합니다. 계획된 다운타임이 경과된 정도에 따라 마이그레이션 태스크가 예상한 기간 내에 완료되지 않을 경우 마이그레이션을 연기해야 할 수 있습니다.

대체 계획은 일반적으로 프로덕션 컷오버를 수행한 후 대상 인스턴스에 문제가 발생할 경우에 마이그레이션을 롤백하는 것을 의미합니다. 대체 계획을 구현할 때는 계획과 테스트를 포함하여 전체 데이터베이스 마이그레이션으로 처리해야 한다는 것을 기억해야 합니다.

대체 계획을 사용하지 않기로 선택한 경우에는 가능한 결과를 파악해야 합니다. 대체 계획이 없으면 예기치 않은 노력이 가중되고 마이그레이션 프로세스에서 피할 수 있었던 중단이 발생할 수 있습니다.

대체 계획은 마지막 수단으로만 사용되고 대부분의 데이터베이스 마이그레이션에서도 결국 대체 계획이 사용되는 일은 거의 없지만 항상 대체 전략을 준비하는 것이 좋습니다.

단순 대체

이 대체 전략에서는 애플리케이션을 원래 소스 데이터베이스 인스턴스로 다시 전환합니다. 대체 시 다운타임을 감당할 수 있거나 새 대상 시스템에서 트랜잭션을 커밋할 필요가 없으면 이 전략을 채택합니다.

대상 데이터베이스에서 모든 기록된 데이터가 필요하고 일부 다운타임을 감당할 수 있으면 대상 데이터베이스 인스턴스에 대한 기록을 중지하고, 소스 인스턴스에서 기본 제공 백업 및 복원을 수행하고, 애플리케이션을 초기 소스 데이터베이스 인스턴스에 다시 연결하는 방식을 고려할 수 있습니다. 워크로드의 특성과 대상 데이터베이스 인스턴스에 기록되는 데이터 양에 따라 특히 워크로드가 특정 레코드 생성 시간 또는 시간 순서 제약조건에 의존하지 않을 경우 나중에 초기 소스 데이터베이스 시스템으로 가져올 수 있습니다.

역방향 복제

이 전략에서는 프로덕션 컷오버 이후 새로운 대상 데이터베이스에서 발생하는 쓰기 작업을 초기 소스 데이터베이스로 다시 복제합니다. 이렇게 하면 원래 소스를 새로운 대상 데이터베이스와 동기화 상태로 유지하고 새 대상 데이터베이스 인스턴스에서 쓰기가 수행되도록 할 수 있습니다. 이 방법의 주요 단점은 대상 데이터베이스 인스턴스로 컷오버하기 전까지는 복제 스트림을 테스트할 수 없다는 것입니다. 따라서 엔드 투 엔드 방식의 테스트가 불가능하고 짧은 기간 동안 대체가 수행되지 않습니다.

이 접근 방법은 일정 시간 동안 소스 인스턴스를 유지할 수 있고 지속적 복제 마이그레이션을 사용하여 마이그레이션할 수 있을 때 선택합니다.

정방향 복제

이 전략은 역방향 복제의 변형입니다. 새로운 대상 데이터베이스의 쓰기 작업을 선택한 세 번째 데이터베이스 인스턴스에 복제합니다. 애플리케이션을 이 세 번째 데이터베이스에 연결할 수 있습니다. 이 데이터베이스는 서버에 연결하여 서버를 사용할 수 없는 동안 읽기 전용 쿼리를 실행합니다. 필요에 따라 복제 메커니즘을 사용할 수 있습니다. 이 접근 방법의 장점은 완전히 엔드 투 엔드 방식으로 테스트할 수 있다는 것입니다.

항상 대체를 지원하려는 경우 또는 프로덕션 컷오버 이후 잠시 초기 소스 데이터베이스를 삭제해야 하는 경우에 이 접근 방법을 선택합니다.

중복 쓰기

Y(쓰기 및 읽기) 또는 데이터 액세스 마이크로서비스 마이그레이션을 선택한 경우 이 대체 계획이 이미 설정되어 있습니다. 이 전략은 애플리케이션을 리팩터링하거나 데이터베이스 인스턴스에 연결되는 도구를 개발해야 하기 때문에 보다 복잡합니다.

애플리케이션은 초기 소스 및 대상 데이터베이스 인스턴스에 모두 쓰기를 수행합니다. 대상 데이터베이스 인스턴스만 사용할 때까지 점진적으로 프로덕션 컷오버를 수행할 수 있습니다. 문제가 있으면 다운타임 없이 초기 소스에 애플리케이션을 다시 연결합니다. 문제 발생 없이 마이그레이션이 수행된다고 고려될 때는 초기 소스 및 중복 쓰기 메커니즘을 삭제할 수 있습니다.

마이그레이션 다운타임을 없애는 것이 중요하고 신뢰할 수 있는 대체가 설정된 경우 그리고 애플리케이션 리팩터링을 수행할 시간과 리소스가 있는 경우에 이 접근 방법이 권장됩니다.

테스트 및 검증 수행

이 단계의 목적은 다음을 테스트하고 검증하는 것입니다.

• 데이터베이스에서 성공적인 데이터 마이그레이션
• 새로운 대상 인스턴스를 사용하도록 전환된 후 기존 애플리케이션과 통합

해당 마이그레이션에 대한 주요 성공 요소를 정의합니다. 다음은 이러한 요소의 예시입니다.

• 마이그레이션할 데이터. 일부 워크로드에서는 모든 데이터를 마이그레이션할 필요가 없을 수 있습니다. 이미 집계되었거나, 중복되었거나, 보관 처리되었거나, 오래된 데이터는 마이그레이션할 필요가 없을 수 있습니다. 이러한 데이터는 Cloud Storage 버킷에 백업으로 보관 처리할 수 있습니다.
• 허용되는 데이터 손실 비율. 이는 특히 분석 워크로드에 사용되는 데이터에 적용됩니다. 이 경우에는 데이터 일부의 손실이 워크로드의 성능 또는 일반적인 트렌드에 영향을 주지 않습니다.
• 소스 환경에 적용하고 마이그레이션 후 대상 환경과 비교할 수 있는 데이터 품질 및 수량 기준
• 성능 기준. 일부 비즈니스 트랜잭션은 대상 환경에서 속도가 더 느리더라도 처리 시간이 여전히 정의된 예상 범위 내에 있을 수 있습니다.

소스 환경에서 스토리지 구성은 Google Cloud 환경 대상에 직접 매핑되지 않을 수 있습니다. 예를 들어 IOPS 버스트 성능 또는 프로비저닝된 IOPS SSD를 지원하는 범용 SSD(gp2 및 gp3) 볼륨의 구성이 있습니다. 대상 인스턴스를 비교하고 적정 크기를 지정하려면 평가 및 검증 단계 모두에서 소스 인스턴스를 벤치마킹합니다.

벤치마킹 프로세스에서는 프로덕션과 비슷한 작업 순서를 데이터베이스 인스턴스에 적용합니다. 이 시간 동안 소스 및 대상 시스템의 상대적 성능을 측정하고 비교하기 위해 측정항목을 캡처하고 처리합니다.

기존 서버 기반 구성에서는 피크 부하 중 관측된 관련 측정값을 사용합니다. Aurora Serverless와 같은 유연한 리소스 용량 모델의 경우 기존 측정항목 데이터를 조사하여 확장 요구를 관찰하는 것이 좋습니다.

다음 도구는 테스트, 검증, 데이터베이스 벤치마킹을 위해 사용할 수 있습니다.

• HammerDB: 오픈소스 데이터베이스 벤치마킹 및 부하 테스트 도구입니다. 여러 데이터베이스 엔진의 산업 표준에 따라 복잡한 트랜잭션 및 분석 워크로드를 지원합니다(예: TPROC-C 및 TPROC-H). HammerDB에는 자세한 문서가 포함되어 있으며 다양한 사용자 커뮤니티를 지원합니다. 여러 데이터베이스 엔진과 스토리지 구성 간에 결과를 비공유하고 비교할 수 있습니다. 자세한 내용은 HammerDB를 사용하여 SQL 서버 테스트 로드 및 HammerDB를 사용하여 Amazon RDS SQL 서버 성능 벤치마킹을 참조하세요.
• DBT2 벤치마크 도구: MySQL를 위한 전문 벤치마킹을 지원합니다. 일련의 데이터베이스 워크로드 키트를 사용해서 웨어하우스를 소유하고 읽기 및 쓰기 트랜잭션을 조합하는 회사 애플리케이션을 시뮬레이션합니다. 이 도구는 미리 작성된 온라인 트랜잭션 처리(OLTP) 부하 테스트를 사용하려는 경우에 사용합니다.
• DbUnit: Java에서 관계형 데이터베이스 상호작용을 테스트하는 데 사용되는 오픈소스 단위 테스트 도구입니다. 설정과 사용이 직관적이고 여러 데이터베이스 엔진(MySQL, PostgreSQL, SQL Server 등)을 지원합니다. 하지만 데이터베이스 크기와 복잡성에 따라 테스트 실행 속도가 느려질 수 있습니다. 이 도구는 단순성이 중요할 때 권장됩니다.
• DbFit: 테스트 중심의 코드 개발 및 자동화된 테스트를 지원하는 오픈소스 데이터베이스 테스트 프레임워크입니다. 이 도구는 테스트 사례를 만들기 위한 기본 구문을 사용하고 데이터 중심 테스트, 버전 제어, 테스트 결과 보고를 지원합니다. 하지만 복잡한 쿼리 및 트랜잭션 지원이 제한적이고 다른 도구에 비해 대규모 커뮤니티 지원 또는 광범위한 문서 지원이 부족합니다. 이 도구는 쿼리가 복잡하지 않고 자동화된 테스트를 수행하고 지속적 통합 및 전송 프로세스와 함께 통합하려는 경우에 권장됩니다.

마이그레이션 계획 테스트를 포함하여 엔드 투 엔드 방식의 테스트를 실행하기 위해서는 항상 마이그레이션 테스트 실행 연습을 수행합니다. 테스트 실행은 프로덕션 워크로드 전환 없이 전체 범위의 데이터베이스 마이그레이션을 수행하고 다음과 같은 이점을 제공합니다.

• 모든 객체 및 구성이 올바르게 마이그레이션되도록 보장할 수 있습니다.
• 마이그레이션 테스트 사례를 정의하고 실행하는 데 도움이 됩니다.
• 실제 마이그레이션에 필요한 시간에 대한 인사이트를 제공하므로 타임라인을 보정할 수 있습니다.
• 마이그레이션 계획을 테스트, 검증, 조정할 수 있는 기회입니다. 경우에 따라서는 모든 것을 미리 계획할 수 없기 때문에 이렇게 하는 것이 문제를 발견하는 데 도움이 됩니다.

데이터 테스트는 마이그레이션할 데이터베이스의 일부 집합 또는 전체 집합에서 수행할 수 있습니다. 데이터베이스의 총 개수와 마이그레이션을 구현하는 데 사용되는 도구에 따라 위험 기반의 접근 방법을 채택하도록 결정할 수 있습니다. 이 접근 방법에서는 특히 이 도구가 관리형 마이그레이션 서비스인 경우에 동일한 도구를 통해 마이그레이션되는 데이터베이스 하위 집합에 대해 데이터 검증을 수행합니다.

테스트를 위해서는 소스 및 대상 데이터베이스 모두 액세스 권한이 있어야 하고 다음 태스크를 수행해야 합니다.

• 소스 및 대상 스키마를 비교합니다. 모든 테이블과 실행 파일이 있는지 확인합니다. 행 수를 확인하고 데이터베이스 수준에서 데이터를 비교합니다.
• 커스텀 데이터 검증 스크립트를 실행합니다.
• 대상 데이터베이스를 사용하도록 전환된 애플리케이션에서도 마이그레이션된 데이터가 표시되는지 테스트합니다(애플리케이션을 통해 마이그레이션된 데이터 읽기).
• 다양한 사용 사례를 테스트하여 전환된 애플리케이션과 대상 데이터베이스 사이의 통합 테스트를 수행합니다. 이 테스트에는 애플리케이션을 통해 대상 데이터베이스에 대한 데이터 읽기 및 쓰기가 모두 포함되므로 워크로드가 새로 생성된 데이터와 함께 마이그레이션된 데이터를 완전히 지원합니다.
• 가장 많이 사용된 데이터베이스 쿼리의 성능을 테스트하여 잘못된 구성 또는 잘못된 크기 조정에 따른 성능 저하가 없는지 확인합니다.

이상적으로 이러한 모든 마이그레이션 테스트 시나리오는 자동화된 방식으로 수행되며 모든 소스 시스템에서 반복 가능합니다. 자동화된 테스트 사례 모음은 전환된 애플리케이션에 대해 수행되도록 조정됩니다.

Database Migration Service를 마이그레이션 도구로 사용할 경우 마이그레이션을 확인합니다.

데이터 검증 도구

데이터 검증 수행을 위해서는 데이터 검증 도구(DVT)를 사용하는 것이 좋습니다. DVT는 Google에서 지원되는 오픈소스 Python CLI 도구이며, 여러 환경에서의 검증을 위해 자동화되고 반복 가능한 솔루션을 제공합니다.

DVT를 사용하면 맞춤설정된 다중 수준의 검증 기능을 제공하여 데이터 검증 프로세스를 원활하게 수행하고 테이블, 열, 행 수준에서 소스 및 대상 테이블을 비교할 수 있습니다. 검증 규칙을 추가할 수도 있습니다.

DVT는 PostgreSQL용 AlloyDB, BigQuery, Cloud SQL, Spanner, JSON, Cloud Storage의 CSV 파일을 포함하여 다양한 Google Cloud 데이터 소스를 지원합니다. 또한 이벤트 기반 트리거 및 조정을 위해 Cloud Functions 및 Cloud Run와 통합할 수 있습니다.

DVT는 다음 유형의 검증을 지원합니다.

• 스키마 수준 비교
• 열('AVG', 'COUNT', 'SUM', 'MIN', 'MAX', 'GROUP BY', 'STRING_AGG' 포함)
• 행(필드 비교의 해시 및 정확한 일치 포함)
• 커스텀 쿼리 결과 비교

DVT에 대한 자세한 내용은 Git 저장소 및 Google Cloud 데이터 검증 도구로 쉽게 수행되는 데이터 검증을 참조하세요.

마이그레이션 수행

마이그레이션 태스크에는 한 시스템에서 다른 시스템으로 전송을 지원하기 위한 활동이 포함됩니다.

데이터 마이그레이션에 대한 다음 권장사항을 고려하세요.

• 계획 단계가 시작되고 완료될 때마다 관련 팀에 알림을 제공합니다.
• 특정 단계가 예상한 것보다 오래 걸리면 해당 단계에 할당된 최대 시간과 실제 경과 시간을 비교합니다. 이러한 문제가 발생하면 관련 팀에 정기적으로 즉시 업데이트를 제공합니다.
• 계획에 있는 각 단계에 예약된 최대 시간보다 시간 범위가 더 크면 롤백을 고려합니다.
• 마이그레이션 및 컷오버 계획의 모든 단계에 대해 "go 또는 no-go" 결정을 내립니다.
• 각 단계에 대해 롤백 작업 또는 대체 시나리오를 고려합니다.

정의된 실행 태스크에 따라 마이그레이션을 수행하고 선택한 마이그레이션 도구의 문서를 참조합니다.

프로덕션 컷오버 수행

상위 수준의 프로덕션 컷오버 프로세스는 선택한 마이그레이션 전략에 따라 달라질 수 있습니다. 워크로드에서 다운타임을 감당할 수 있으면 소스 데이터베이스에 대한 쓰기를 중지하여 마이그레이션 컷오버를 시작합니다.

지속적 복제 마이그레이션의 경우에는 일반적으로 컷오버 프로세스에서 다음과 같은 상위 수준의 단계를 수행합니다.

• 소스 데이터베이스에 쓰기를 중지합니다.
• 소스를 드레이닝합니다.
• 복제 프로세스를 중지합니다.
• 새 대상 데이터베이스를 가리키는 애플리케이션을 배포합니다.

선택한 마이그레이션 도구를 사용하여 데이터를 마이그레이션한 후 대상 데이터베이스에서 데이터를 검증합니다. 소스 데이터베이스와 대상 데이터베이스가 동기화된 상태인지 확인하고 대상 인스턴스의 데이터가 선택한 마이그레이션 성공 기준을 준수하는지 확인합니다.

데이터 검증이 기준을 통과하면 애플리케이션 수준의 컷오버를 수행할 수 있습니다. 새 대상 인스턴스를 사용하도록 리팩터링된 워크로드를 배포합니다. 새로운 대상 데이터베이스 인스턴스를 가리키는 애플리케이션 버전을 배포합니다. 배포는 순차적 업데이트, 스테이징 출시, 블루-그린 배포 패턴을 사용해서 수행할 수 있습니다. 일부 애플리케이션 다운타임이 발생할 수 있습니다.

프로덕션 컷오버에 대한 권장사항을 따릅니다.

• 컷오버 이후 대상 데이터베이스에서 작동하는 애플리케이션을 모니터링합니다.
• 모니터링 기간을 정의하여 대체 계획을 구현해야 하는지 여부를 고려합니다.
• 일부 데이터베이스 플래그를 변경할 경우 Cloud SQL 또는 PostgreSQL용 AlloyDB 인스턴스를 다시 시작해야 할 수 있습니다.
• 마이그레이션을 롤백하는 작업이 대상 환경에 표시되는 문제를 해결하는 것보다 더 어려울 수 있다는 것을 고려합니다.

소스 환경 정리 및 Cloud SQL 인스턴스 구성

컷오버가 완료된 후 소스 데이터베이스를 삭제할 수 있습니다. 소스 인스턴스를 정리하기 전에 다음과 같은 중요한 작업을 수행하는 것이 좋습니다.

• 각 소스 데이터베이스의 최종 백업을 만듭니다. 이러한 백업은 소스 데이터베이스의 최종 상태를 제공합니다. 일부 경우에는 데이터 규정을 준수하기 위해 백업이 필요할 수도 있습니다.

• 소스 인스턴스의 데이터베이스 매개변수 설정을 수집합니다. 또는 인벤토리 빌드 단계에서 수집한 것과 일치하는지 확인합니다. 소스 인스턴스의 매개변수와 일치하도록 대상 인스턴스 매개변수를 조정합니다.

• 소스 인스턴스에서 데이터베이스 통계를 수집하고 이를 대상 인스턴스의 통계와 비교합니다. 통계가 서로 다르면 소스 인스턴스와 대상 인스턴스의 성능을 비교하기 어렵습니다.

대체 시나리오에서는 Cloud SQL 인스턴스에서 쓰기 작업의 복제를 다시 원래 소스 데이터베이스에 구현해야 할 수 있습니다. 이 설정은 마이그레이션 프로세스와 비슷하지만 역방향으로 수행되어, 초기 소스 데이터베이스가 새로운 대상이 됩니다.

컷오버 이후 소스 인스턴스를 최신 상태로 유지하기 위해서는 대상 Cloud SQL 인스턴스에서 수행된 쓰기 작업을 다시 소스 데이터베이스에 복제하는 것이 좋습니다. 롤백이 필요하면 최소한의 데이터 손실로 이전 소스 인스턴스로 대체할 수 있습니다.

소스 환경 정리 외에도 Cloud SQL 인스턴스에 대해 다음과 같은 중요한 구성을 수행해야 합니다.

• 기본 인스턴스의 유지보수 기간을 구성하여 방해가 되는 업데이트가 발생할 수 있는 시간을 제어하세요.
• Cloud SQL이 수행할 수 있는 중요한 데이터베이스 유지보수 작업을 수용하는 데 사용 가능한 공간이 최소 20% 이상 되도록 인스턴스에 스토리지를 구성합니다. 사용 가능한 디스크 공간이 20%보다 낮아졌을 때 알림을 받으려면 디스크 사용량 측정항목에 대해 측정항목 기반 알림 정책을 만듭니다.

이전 작업이 완료되기 전에 관리 작업을 시작하지 마세요.

자세한 내용은 다음을 참조하세요.

• Cloud SQL 인스턴스의 유지보수 정보
• SQL Server 엔진 관련 설정

마이그레이션 후 환경 최적화

최적화는 마이그레이션의 마지막 단계입니다. 이 단계에서는 환경이 최적화 요구사항을 충족할 때까지 최적화 태스크를 반복합니다. 이러한 반복 단계는 다음과 같습니다.

1. 현재 환경과 팀을 평가합니다.
2. 최적화 요구사항 및 목표를 설정합니다.
3. 환경 및 팀을 최적화합니다.
4. 최적화 프로세스를 조정합니다.

최적화 목표에 도달할 때까지 이 순서를 반복합니다.

Google Cloud 환경 최적화에 대한 자세한 내용은 Google Cloud로 마이그레이션: 환경 최적화 및 성능 최적화 프로세스를 참조하세요.

최적화 요구사항 설정

Google Cloud 환경에 대한 다음 최적화 요구사항을 검토하고 자신의 워크로드에 가장 적합한 항목을 선택합니다.

데이터베이스의 신뢰성 및 가용성 증가

Cloud SQL에서는 복구 시간 목표(RTO) 및 복구 지점 목표(RPO)에 맞는 고가용성 및 재해 복구 전략을 구현할 수 있습니다. 신뢰성과 가용성을 늘리려면 다음을 고려하세요.

• 읽기가 많은 워크로드의 경우에는 기본 인스턴스에서 트래픽을 오프로드하기 위해 읽기 복제본을 추가합니다.
• 미션 크리티컬 워크로드의 경우에는 고가용성 구성, 리전 장애 조치를 위한 복제본, 강력한 재해 복구 구성을 사용합니다.
• 중요도가 낮은 워크로드의 경우에는 자동화된 주문형 백업으로도 충분할 수 있습니다.
• 실수로 인한 인스턴스 삭제를 방지하려면 인스턴스 삭제 보호를 사용합니다.
• SQL 서버용 Cloud SQL 인스턴스에 대해 PITR(point-in-time recovery)을 사용 설정합니다.
• 유지보수 계획을 사용하여 SQL 데이터베이스 백업을 자동화합니다.

데이터베이스 인프라의 비용 효율성 증가

긍정적인 경제적 영향을 주기 위해서는 워크로드가 사용 가능한 리소스 및 서비스를 효율적으로 사용해야 합니다. 다음 옵션을 고려하세요.

• 다음을 수행하여 데이터베이스에 필요한 최소 스토리지 용량을 제공합니다.

  • 데이터 증가에 따라 스토리지 용량을 자동으로 확장하려면 자동 스토리지 증가를 사용 설정합니다. 하지만 피크 워크로드 시 버퍼가 일부 있도록 인스턴스를 구성해야 합니다. 데이터베이스 워크로드는 시간이 지남에 따라 증가하는 경향이 있습니다.

• 과도하게 추정되었을 수 있는 리소스를 식별합니다.

  • Cloud SQL 인스턴스를 올바른 크기로 설정하면 용량 관리 전략에 대한 추가 위험 부담 없이 인프라 비용을 줄일 수 있습니다.
  • Cloud Monitoring은 Cloud SQL을 포함하여 여러 Google Cloud 구성요소의 상태 및 용량 사용률을 식별하는 데 도움이 되는 사전 정의된 대시보드를 제공합니다. 자세한 내용은 커스텀 대시보드 만들기 및 관리를 참조하세요.

• 고가용성 또는 재해 복구 구성이 필요하지 않은 인스턴스를 식별하고 인프라에서 삭제합니다.

• 더 이상 필요하지 않은 테이블 및 객체를 삭제합니다. 전체 백업 또는 보관용 Cloud Storage 버킷에 저장할 수 있습니다.

• 사용 사례에 대해 가장 비용 효율적인 스토리지 유형(SSD 또는 HDD)을 평가합니다.

  • 대부분의 사용 사례에서는 SSD가 가장 효율적이고 비용 효율적인 옵션입니다.
  • 데이터가 10TB 이상으로 크고 지연 시간에 민감하지 않거나 자주 액세스되지 않으면 HDD가 더 적합할 수 있습니다.
  • 자세한 내용은 SSD 및 HDD 스토리지 중에서 선택을 참조하세요.

• 리소스 요구를 예측 가능한 워크로드의 경우 약정 사용 할인을 구매합니다.

• Active Assist를 사용해서 비용 인사이트 및 권장사항을 확인합니다.

자세한 내용 및 옵션은 적은 리소스로 효율성 향상: Active Assist를 사용하는 Cloud SQL 비용 최적화 권장사항 소개를 참조하세요.

특히 SQL 서버용 Cloud SQL의 라이선스 비용을 줄이려면 다음을 고려하세요.

• SLA가 해당 요구사항과 일치할 경우 SQL Server Standard Edition으로 마이그레이션합니다.
• 동시 멀티스레딩(SMT)을 해제하고 코어를 25% 더 추가합니다. 추가 코어는 SMT 해제로 인한 성능 영향을 보상할 수 있습니다. 이 전략은 라이선스 비용을 줄이는 데 도움이 되지만 인스턴스 성능에 영향을 줄 수 있습니다. SLA가 영향을 받지 않도록 보장하기 위해서는 인스턴스에서 부하 테스트를 수행하는 것이 좋습니다.
• 워크로드에 따라 SQL 서버용 Cloud SQL에서 PostgreSQL용 Cloud SQL 또는 PostgreSQL용 AlloyDB로 이기종 마이그레이션을 고려합니다.

데이터베이스 인프라 성능 증가

사소한 데이터베이스 관련 성능 문제도 전체 운영에 영향을 줄 가능성이 자주 있습니다. Cloud SQL 인스턴스 성능을 유지보수하고 늘리기 위해서는 다음 가이드라인을 고려하세요.

• 대량의 데이터베이스 테이블이 있으면 인스턴스 성능 및 가용성에 영향을 줄 수 있고 인스턴스가 SLA 지원 범위를 충족하지 못할 수 있습니다.

• 인스턴스의 메모리 또는 CPU가 제한되지 않도록 해야 합니다.

  • 성능 집약적인 워크로드의 경우 인스턴스에는 메모리가 최소 60GB 이상 있는지 확인합니다.
  • 데이터베이스 삽입, 업데이트, 삭제가 느린 경우 작성자와 데이터베이스의 위치를 확인합니다. 장거리로 데이터를 보내면 지연 시간이 발생합니다.

• Cloud Monitoring에서 사전 정의된 쿼리 통계 대시보드(또는 비슷한 데이터베이스 엔진 기본 제공 기능)를 사용해서 쿼리 성능을 개선합니다. 가장 비용이 높은 명령어를 식별하고 이를 최적화합니다.

• 데이터베이스 파일이 불필요하게 커지지 않도록 방지합니다. 요구사항에 적합한 증분 값을 사용해서 백분율 대신 MB로 autogrow를 설정합니다.

• 리더 및 데이터베이스 위치를 확인합니다. 지연 시간은 쓰기 성능보다 읽기 성능에 영향을 줍니다.

• 데이터 및 색인 단편화를 방지합니다. 데이터 변경 빈도에 따라 SQL 서버에서 색인을 다시 빌드하도록 일정을 설정합니다.

• Cloud SQL에 대해 최적의 방식으로 작동하도록 SQL Server 엔진 관련 설정을 변경합니다.

• 색인 및 통계 유지보수는 SQL Server 유지보수 솔루션을 참조하세요.

• SQL 서버용 Cloud SQL에서 정기적으로 통계를 업데이트합니다.

• 인스턴스 캐시에 영향을 줄 수 있으므로 읽기 복제본에서 ETL 작업 수행을 고려합니다.

성능 향상에 대한 자세한 내용은 "진단 이슈"의 성능 및 Cloud SQL - SQL 서버 성능 분석 및 쿼리 조정을 참조하세요.

데이터베이스 관측 가능성 기능 증가

데이터베이스 인스턴스에 연결하는 애플리케이션에서 진단 및 문제 해결은 어렵고 시간이 오래 걸릴 수 있습니다. 따라서 모든 팀원이 데이터베이스 및 인스턴스 수준에서 수행되는 작업을 볼 수 있는 중앙화된 위치가 필수적입니다. Cloud SQL 인스턴스는 다음과 같은 방법으로 모니터링할 수 있습니다.

• Cloud SQL은 기본 제공 메모리 커스텀 에이전트를 사용하여 쿼리 원격 분석을 수집합니다.

  • Cloud Monitoring을 사용해서 사용 중인 서비스 및 Google Cloud 리소스에 대한 측정값을 수집합니다.
  • 적시에 알림을 받을 수 있도록 측정항목을 모니터링하고 알림 정책을 설정하는 데 도움이 되는 커스텀 대시보드를 만들 수 있습니다.

• Cloud Logging은 일반적인 애플리케이션 구성요소에서 로깅 데이터를 수집합니다. 또한 Cloud SQL 인스턴스에 대해 로그를 보고 쿼리할 수도 있습니다.

• Cloud Trace는 애플리케이션을 통해 요청이 전파되는 방식을 추적할 수 있도록 애플리케이션에서 지연 시간 데이터 및 실행된 쿼리 계획을 수집합니다.

• 데이터베이스 센터는 AI로 지원되는 중앙화된 데이터베이스 Fleet 개요를 제공합니다. 데이터베이스 상태, 가용성 구성, 데이터 보호, 보안, 업계 규정 준수를 모니터링할 수 있습니다.

일반적인 Cloud SQL 권장사항과 운영 가이드라인

Cloud SQL 권장사항을 적용하여 데이터베이스를 구성하고 조정합니다.

몇 가지 중요한 Cloud SQL 일반 권장사항은 다음과 같습니다.

• 큰 인스턴스가 있으면 가능한 경우 작은 인스턴스로 분할하는 것이 좋습니다.
• 중요한 데이터베이스 유지보수를 지원하도록 스토리지를 구성합니다. Cloud SQL이 수행할 수 있는 모든 핵심적인 데이터베이스 유지보수 작업을 수용할 수 있도록 사용 가능한 공간을 최소 20% 이상 확보해야 합니다.
• 데이터베이스 테이블이 너무 많으면 데이터베이스 업그레이드 시간에 영향을 줄 수 있습니다. 이상적으로 인스턴스당 테이블 수를 10,000개 미만으로 포함하는 것이 좋습니다.
• 특히 쓰기 활동이 높은 인스턴스의 경우 트랜잭션(바이너리) 로그 보관을 고려해서 적절한 인스턴스 크기를 선택해야 합니다.

발생 가능한 데이터베이스 성능 문제를 효과적으로 처리하기 위해서는 문제가 해결될 때까지 다음 가이드라인을 참조하세요.

인프라 확장: 디스크 처리량, vCPU, RAM 등의 리소스를 늘립니다. 긴급 상황과 팀 가용성 및 경험에 따라 인스턴스를 수직 확장함으로써 대부분의 문제를 해결할 수 있습니다. 나중에 테스트 환경에서 발생하는 문제의 근본 원인을 추가적으로 조사하고 이를 없애는 옵션을 고려할 수 있습니다.

데이터베이스 유지보수 작업 수행 및 계획: 색인 스토리지 재구성, 통계 업데이트, 진공 분석 수행, 자주 수정되는 테이블에서 색인 재생성을 수행합니다. 특히 영향을 받는 객체(테이블, 색인)에서 이러한 유지보수 작업이 수행되었는지 여부와 마지막으로 수행된 시간을 확인합니다. 일반적인 데이터베이스 활동에 변경사항이 있었는지 확인합니다. 예를 들어 최근에 새 열을 추가했거나 테이블에서 업데이트가 많이 수행되었을 수 있습니다.

데이터베이스 조정 및 최적화 수행: 데이터베이스에 있는 테이블이 올바르게 구성되었나요? 열의 데이터 유형이 올바른가요? 데이터 모델이 워크로드 유형에 대해 올바른가요? 느린 쿼리와 실행 계획을 조사합니다. 사용 가능한 색인을 사용 중인가요? 색인 스캔, 잠금, 기타 리소스에서의 대기 상태를 확인합니다. 중요 쿼리를 지원하기 위한 색인 추가를 고려합니다. 중요하지 않은 색인과 외래 키를 삭제합니다. 복잡한 쿼리와 조인을 다시 작성합니다. 문제 해결에 걸리는 시간은 팀의 경험 및 가용성에 따라 달라지며 몇 시간에서 며칠까지 다양할 수 있습니다.

읽기 수평 확장: 읽기 복제본을 사용합니다. 수직 확장이 요구를 해결하는 데 충분하지 않고, 데이터베이스 조정과 최적화 측정이 도움이 되지 않으면 수평 확장을 고려하세요. 읽기 쿼리를 애플리케이션에서 읽기 복제본으로 라우팅하면 전반적인 데이터베이스 워크로드 성능이 향상됩니다. 하지만 읽기 복제본에 연결하도록 애플리케이션을 변경하기 위해서는 추가적인 노력이 필요할 수 있습니다.

데이터베이스 아키텍처 재구성: 데이터베이스 파티셔닝 및 색인 생성을 고려하세요. 이 작업은 데이터베이스 조정 및 최적화보다 상당히 많은 노력이 필요하며, 데이터 마이그레이션이 포함될 수 있지만 장기적인 해결 방법이 될 수 있습니다. 때로는 적합하지 않은 데이터 모델 설계로 인해 성능 문제가 발생하더라도 수직 확장을 통해 이를 부분적으로 보상할 수 있습니다. 하지만 장기적인 해결책은 적절한 데이터 모델입니다. 테이블 파티셔닝을 고려하세요. 가능한 경우에는 필요하지 않은 데이터를 보관 처리하세요. 데이터베이스 구조를 정규화할 수 있지만 비정규화 역시 성능을 향상시킬 수 있다는 것을 기억하세요.

데이터베이스 샤딩: 데이터베이스 샤딩을 통해 쓰기를 수평 확장할 수 있습니다. 샤딩은 복잡한 작업이며 특정 방식으로 데이터베이스 및 애플리케이션 아키텍처를 재구성하고 데이터 마이그레이션을 수행해야 합니다. 특정 파티셔닝 기준을 사용해서 여러 작은 인스턴스로 데이터베이스 인스턴스를 분할합니다. 기준은 고객 또는 주제에 따라 달라질 수 있습니다. 이 옵션을 선택하면 쓰기와 읽기를 모두 수평으로 확장할 수 있습니다. 하지만 데이터베이스 및 애플리케이션 워크로드의 복잡성도 증가합니다. 또한 핫스팟이라고 부르는 불균형적인 샤드로 이어져서 샤딩의 이점을 초과할 수 있습니다.

특히 SQL 서버용 Cloud SQL에서는 다음과 같은 권장사항을 고려하세요.

• Cloud SQL에서 최적 성능을 위해 SQL 서버 설정을 업데이트하려면 SQL 서버 설정을 참조하세요.
• SQL 서버를 배포하기 전 I/O 하위 시스템의 용량을 결정합니다.

• 대규모 인스턴스가 있으면 가능한 경우 이를 작은 인스턴스로 분할합니다.

  • 4TB 이상의 디스크 크기는 더 많은 처리량 및 IOPS를 제공합니다.
  • vCPU가 높을수록 더 많은 IOPS 및 처리량을 제공합니다. 더 높은 vCPU를 사용할 때는 함께 증가할 수 있는 동시 로드를 위한 데이터베이스 대기 시간을 모니터링하세요.

• 일부 상황에서 성능이 저하되면 SMT를 해제하세요. 예를 들어 애플리케이션이 병목 현상을 일으키는 스레드를 실행하여 CPU 아키텍처가 이를 효과적으로 처리하지 못할 수 있습니다.

• 데이터 변경 빈도에 따라 색인을 재구성하거나 다시 빌드하도록 계획을 설정하세요.

• 조각화를 줄이기 위해 적절한 채우기 요소를 설정합니다. SQL 서버에서 향상된 성능을 제공할 수 있는 누락된 색인이 있는지 모니터링하세요.

• 데이터베이스 파일이 불필요하게 커지지 않도록 방지합니다. 요구사항에 적합한 증분 값을 사용해서 백분율 대신 MB로 autogrow를 설정합니다. 또한 autogrow 기준점에 도달하기 전에 데이터베이스 증가를 사전에 관리하세요.

• 스토리지 용량을 자동으로 확장하려면 자동 스토리지 증가를 사용 설정합니다. 데이터베이스와 인스턴스에 공간이 부족해지면 Cloud SQL이 스토리지 공간을 추가할 수 있습니다.

• 사용 중인 데이터의 지역별 요구사항, 정렬 순서, 대소문자와 악센트 유무를 구별하는지 여부를 이해하는 것이 중요합니다. 서버, 데이터베이스, 열, 표현식에 대해 콜레이션을 선택하면 데이터에 특정 특성이 할당됩니다.

• 재귀 해시 조인 또는 해시 베일아웃으로 인해 서버의 성능이 저하됩니다. trace에 해시 경고 이벤트가 다수 표시되면 조인되는 열의 통계를 업데이트합니다. 자세한 내용은 해시 경고 이벤트 클래스를 참조하세요.

자세한 내용은 SQL 서버용 Cloud SQL에 대한 일반 권장사항과 운영 가이드라인을 참조하세요.

다음 단계

• Amazon EC2에서 Compute Engine으로 마이그레이션 방법 알아보기
• Amazon S3에서 Cloud Storage로 마이그레이션 방법 알아보기
• 기타 AWS에서 Google Cloud로의 마이그레이션 여정 알아보기
• AWS 및 Azure 서비스와 Google Cloud 서비스 비교 방법 알아보기
• 마이그레이션에 대한 도움을 찾는 방법 알아보기
• 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 Cloud 아키텍처 센터를 확인하세요.

참여자

저자:

• 알렉스 카시우 | 솔루션 설계자
• 마르코 페라리 | 클라우드 솔루션 설계자

기타 참여자:

• 더렉 다우니 | 개발자 관계 엔지니어
• 파웰 크렌토브스키 | 기술 작가
• 매튜 스미스 | 전략적 클라우드 엔지니어
• 솜디유티 폴 | 데이터 관리 전문가
• 자크 세일 | 네트워킹 전문가

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.