AWS에서 Google Cloud로 마이그레이션: PostgreSQL용 Amazon RDS 및 Amazon Aurora에서 PostgreSQL용 Cloud SQL 및 AlloyDB로 마이그레이션

Last reviewed 2024-09-12 UTC

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

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

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

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

Google Cloud로의 마이그레이션의 경우 Google Cloud로 마이그레이션: 시작하기에 설명된 마이그레이션 프레임워크를 따르는 것이 좋습니다.

다음 다이어그램은 마이그레이션 과정을 보여줍니다.

4가지 단계로 구성된 마이그레이션 경로

일련의 반복 작업을 통해 원본 환경에서 Google Cloud로 마이그레이션할 수 있습니다. 예를 들어 일부 워크로드를 먼저 마이그레이션하고 나중에 다른 워크로드를 마이그레이션할 수 있습니다. 개별 마이그레이션을 반복할 때마다 일반 마이그레이션 프레임워크 단계를 수행합니다.

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

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

효과적인 마이그레이션 계획을 설계하려면 계획의 각 단계를 검증하고 롤백 전략이 있는지 확인하는 것이 좋습니다. 마이그레이션 계획을 검증하려면 Google Cloud로 마이그레이션: 마이그레이션 계획 검증 권장사항을 참조하세요.

원본 환경 평가

평가 단계에서는 원본 환경을 Google Cloud로 마이그레이션하기 위한 요구사항과 종속 항목을 결정합니다.

평가 단계는 마이그레이션의 성공에 매우 중요합니다. 마이그레이션하려는 워크로드, 요구사항, 종속 항목, 현재 환경에 대해 자세히 알고 있어야 합니다. Google Cloud 마이그레이션을 성공적으로 계획하고 실행하려면 시작점을 이해해야 합니다.

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

  1. 워크로드의 포괄적인 인벤토리를 빌드합니다.
  2. 워크로드의 속성과 종속 항목에 따라 워크로드를 분류합니다.
  3. 팀에 Google Cloud 교육을 실시합니다.
  4. Google Cloud에서 실험 및 개념 증명을 빌드합니다.
  5. 대상 환경의 총 소유 비용(TCO)을 계산합니다.
  6. 워크로드에 적합한 마이그레이션 전략을 선택합니다.
  7. 마이그레이션 도구를 선택합니다.
  8. 마이그레이션 계획 및 타임라인을 정의합니다.
  9. 마이그레이션 계획을 검증합니다.

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

다음 섹션은 Google Cloud로 마이그레이션: 워크로드 평가 및 검색을 기반으로 하며 해당 문서의 정보를 통합합니다.

Amazon RDS 또는 Amazon Aurora 인스턴스의 인벤토리 빌드

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

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

벤치마킹은 마이그레이션할 워크로드를 더 효과적으로 이해하고 마이그레이션 대상 환경의 올바른 아키텍처를 정의하는 데 도움이 됩니다. 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 서비스 제어를 사용해서 PostgreSQL용 Cloud SQL 인스턴스에 대한 액세스를 제어하고 VPC 내부의 데이터를 제한할 수 있습니다.

  • 인스턴스 패치 적용 및 구성 기존 배포 도구를 업데이트해야 할 수 있습니다. 예를 들어 Amazon 매개변수 그룹 또는 Amazon 옵션 그룹에서 커스텀 구성 설정을 사용 중일 수 있습니다. Cloud Storage 또는 Secret Manager를 사용해서 이러한 커스텀 구성 목록을 읽도록 프로비저닝 도구를 조정해야 할 수 있습니다.

  • 모니터링 및 알림 인프라 관리 Amazon 소스 데이터베이스 인스턴스의 측정항목 카테고리는 마이그레이션 프로세스 중 관측 가능성을 제공합니다. 측정항목 카테고리에는 Amazon CloudWatch, 성능 통계, 향상된 모니터링, OS 프로세스 목록이 포함될 수 있습니다.

평가 완료

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

기반 계획 및 빌드

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

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

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

  1. 리소스 계층 구조를 빌드합니다.
  2. Google Cloud의 Identity and Access Management(IAM)를 구성합니다.
  3. 결제 설정.
  4. 네트워크 연결을 설정합니다.
  5. 보안을 강화합니다.
  6. 로깅, 모니터링, 알림을 설정합니다.

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

마이그레이션에 Database Migration Service를 사용할 계획이라면 PostgreSQL용 Cloud SQL의 네트워킹 방법을 참고하여 마이그레이션 시나리오에 사용할 수 있는 네트워킹 구성을 알아보세요.

모니터링 및 경고

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

PostgreSQL용 Amazon RDS 및 Amazon Aurora 인스턴스를 PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB로 마이그레이션

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

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

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

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

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

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

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

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

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

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

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

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

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

마이그레이션 전략 선택

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

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

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

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

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

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

마이그레이션 전략 선택을 도와주는 플로우 차트

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

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

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

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

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

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

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

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

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

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

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

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

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

마이그레이션 도구 선택

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

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

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

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

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

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

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

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

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

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

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

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

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

PostgreSQL용 Cloud SQL 또는 PostgreSQL용 AlloyDB로 일회성으로 이전하는 경우 데이터베이스 엔진 백업을 사용하여 소스 인스턴스에서 데이터를 내보내고 대상 인스턴스로 가져오는 것이 좋습니다. 데이터베이스 이전 서비스에서는 일회성 이전 작업이 지원되지 않습니다.

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

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

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

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

  • 백업은 특히 수동으로 수행할 때 오류가 발생하기 쉽습니다.
  • 스냅샷이 올바르게 관리되지 않으면 데이터가 안전하지 않을 수 있습니다.
  • 백업은 적절한 모니터링 기능이 부족합니다.
  • 백업은 많은 데이터베이스를 이전할 때 확장하는 데 노력이 필요합니다.

PostgreSQL 기본 제공 백업 유틸리티인 pg_dump 및 pg_dumpall를 사용하여 PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB를 모두 마이그레이션할 수 있습니다. 그러나 pg_dump 및 pg_dumapall 유틸리티에는 다음과 같은 일반적인 제한사항이 있습니다.

  • 크기가 500GB 이하인 데이터베이스를 마이그레이션하려면 내장된 백업 유틸리티를 사용해야 합니다. 대규모 데이터베이스를 덤프하고 복원하는 데 시간이 오래 걸릴 수 있으며 상당한 디스크 공간과 메모리가 필요할 수 있습니다.
  • pg_dump 유틸리티에는 사용자와 역할이 포함되지 않습니다. 이러한 사용자 계정과 역할을 이전하려면 pg_dumpall 유틸리티를 사용하면 됩니다.
  • Cloud Storage는 최대 단일 객체 크기를 5테라바이트 (TB)까지 지원합니다. 데이터베이스가 5TB보다 크면 Cloud Storage로 내보내기 작업이 실패합니다. 이 경우 내보내기 파일을 보다 작은 세그먼트로 분할해야 합니다.

이러한 유틸리티를 사용하는 경우 다음과 같은 제한사항과 권장사항을 고려하세요.

  • 데이터를 압축하여 비용과 전송 시간을 줄입니다. pg_dump 명령어와 함께 --jobs 옵션을 사용하여 지정된 수의 덤프 작업을 동시에 실행합니다.
  • pg_dump 명령어와 함께 -z 옵션을 사용하여 사용할 압축 수준을 지정합니다. 이 옵션에 허용되는 값의 범위는 0~9입니다. 기본값은 6 수준으로 압축하는 것입니다. 값이 클수록 덤프 파일의 크기는 줄어들지만 클라이언트 호스트에서 리소스 소비가 많아질 수 있습니다. 클라이언트 호스트에 리소스가 충분하면 압축 수준을 높여 덤프 파일 크기를 더 줄일 수 있습니다.
  • SQL 덤프 파일을 만들 때 올바른 플래그를 사용합니다.
  • 가져온 데이터베이스를 확인합니다. 복원 프로세스 중에 pg_restore 유틸리티의 출력에서 오류 메시지가 있는지 모니터링합니다. 복원 프로세스 중에 PostgreSQL 로그에서 경고나 오류가 있는지 검토합니다. 기본 쿼리와 테이블 수를 실행하여 데이터베이스 무결성을 확인합니다.

제한사항 및 권장사항에 관한 자세한 내용은 다음 리소스를 참고하세요.

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

내장된 백업 유틸리티 이외의 접근 방식을 사용하면 예약된 유지보수 마이그레이션의 제어 수준과 유연성이 향상될 수 있습니다. 이러한 다른 유형의 접근 방식을 사용하면 마이그레이션하는 동안 데이터에 대해 변환, 검사 또는 기타 작업을 실행할 수 있습니다. 여러 인스턴스 또는 데이터베이스를 단일 인스턴스 또는 데이터베이스로 통합할 수 있습니다. 인스턴스를 통합하면 운영 비용을 줄이고 확장성 문제를 해결하는 데 도움이 됩니다.

백업 유틸리티의 대안 중 하나는 플랫 파일을 사용하여 데이터를 내보내고 가져오는 것입니다. 플랫 파일 가져오기에 관한 자세한 내용은 PostgreSQL용 Cloud SQL용 CSV 파일을 사용하여 내보내기 및 가져오기를 참고하세요.

관리형 가져오기를 사용하여 외부 PostgreSQL 데이터베이스에서 복제를 설정하는 것도 또 다른 방법입니다. 관리형 가져오기를 사용하면 외부 데이터베이스에서 PostgreSQL용 Cloud SQL 인스턴스로 초기 데이터가 로드됩니다. 이 초기 로드에는 외부 서버(RDS 또는 Aurora 인스턴스)에서 데이터를 추출하고 PostgreSQL용 Cloud SQL 인스턴스로 직접 가져오는 서비스가 사용됩니다. 자세한 내용은 관리형 가져오기를 사용하여 외부 데이터베이스에서 복제 설정을 참고하세요.

일회성 데이터 마이그레이션을 수행하는 다른 방법은 소스 PostgreSQL 데이터베이스에서 CSV 또는 SQL 파일로 테이블을 내보내는 것입니다. 그런 다음 CSV 또는 SQL 파일을 PostgreSQL용 Cloud SQL 또는 PostgreSQL용 AlloyDB로 가져올 수 있습니다. 소스 인스턴스의 날짜를 내보내려면 PostgreSQL용 aws_s3 확장 프로그램을 사용하면 됩니다. 또는 Amazon Database Migration Service와 S3 버킷을 타겟으로 사용할 수 있습니다. 이 접근 방식에 관한 자세한 내용은 다음 리소스를 참고하세요.

PostgreSQL용 AlloyDB 인스턴스로 데이터를 수동으로 가져올 수도 있습니다. 지원되는 형식은 다음과 같습니다.

  • CSV: 이 파일 형식의 각 파일에는 데이터베이스의 한 테이블의 콘텐츠가 포함됩니다. psql 명령줄 프로그램을 사용하여 데이터를 CSV 파일에 로드할 수 있습니다. 자세한 내용은 CSV 파일 가져오기를 참고하세요.
  • DMP: 이 파일 형식에는 전체 PostgreSQL 데이터베이스의 보관 파일이 포함되어 있습니다. pg_restore 유틸리티를 사용하여 이 파일에서 데이터를 가져옵니다. 자세한 내용은 DMP 파일 가져오기를 참고하세요.
  • SQL: 이 파일 형식에는 PostgreSQL 데이터베이스의 텍스트 재구성이 포함되어 있습니다. 이 파일의 데이터는 psql 명령줄을 사용하여 처리됩니다. 자세한 내용은 SQL 파일 가져오기를 참고하세요.

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

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

지속적 복제 마이그레이션을 위한 도구를 선택하는 데 도움이 되는 플로우 차트

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

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

    • 그렇다면 복제 단계가 진행되는 동안 몇 초 동안의 쓰기 다운타임을 감당할 수 있나요?

      • 그렇다면 Database Migration Service를 사용하세요.
      • 그렇지 않으면 다른 이전 옵션을 살펴봅니다.

    • 그렇지 않은 경우 데이터베이스 엔진 기본 제공 복제가 지원되는지 평가해야 합니다.

      • 그렇다면 기본 제공 복제를 사용하는 것이 좋습니다.
      • 그렇지 않은 경우 다른 마이그레이션 옵션을 살펴보는 것이 좋습니다.

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

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

Database Migration Service는 연속 마이그레이션을 위한 특정 작업 유형을 제공합니다. 이러한 연속 마이그레이션 작업은 PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB로의 고화질 마이그레이션을 지원합니다.

Database Migration Service를 사용하여 PostgreSQL용 Cloud SQL 또는 PostgreSQL용 AlloyDB로 마이그레이션할 때는 각 대상 인스턴스와 관련된 기본 요건 및 제한사항이 있습니다.

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

데이터베이스 엔진 기본 제공 복제는 지속적인 마이그레이션을 위한 Database Migration Service의 대안 옵션입니다.

데이터베이스 복제는 기본 데이터베이스라는 데이터베이스에서 복제본이라는 다른 데이터베이스로 데이터를 복사하고 배포하는 프로세스를 나타냅니다. 데이터 액세스 가능성을 높이고 데이터베이스 시스템의 내결함성과 안정성을 개선하기 위한 것입니다. 데이터베이스 마이그레이션은 데이터베이스 복제의 기본 목적은 아니지만 이 목표를 달성하기 위한 도구로 성공적으로 사용할 수 있습니다. 데이터베이스 복제는 일반적으로 기본 데이터베이스에 데이터가 삽입, 업데이트 또는 삭제될 때 실시간으로 발생하는 진행 중인 프로세스입니다. 데이터베이스 복제는 일회성 작업 또는 일련의 일괄 작업으로 실행할 수 있습니다.

대부분의 최신 데이터베이스 엔진은 데이터베이스 복제를 달성하는 다양한 방법을 구현합니다. 한 가지 유형의 복제는 기본의 쓰기 전 로그 또는 트랜잭션 로그를 복제본으로 복사하여 전송하는 방식으로 실행할 수 있습니다. 이러한 접근 방식을 물리적 또는 바이너리 복제라고 합니다. 다른 복제 유형은 파일 시스템 수준 변경사항을 복제하는 대신 기본 데이터베이스가 수신하는 원시 SQL 문을 배포하여 작동합니다. 이러한 복제 유형을 논리적 복제라고 합니다. PostgreSQL의 경우 미리 쓰기 로깅(WAL)을 기반으로 논리적 복제를 구현하는 서드 파티 확장 프로그램(예: pglogical)도 있습니다.

Cloud SQL은 PostgreSQL용 복제를 지원합니다. 하지만 몇 가지 기본 요건과 제한사항이 있습니다.

다음은 PostgreSQL용 Cloud SQL의 제한사항 및 기본 요건입니다.

  • 다음 Amazon 버전이 지원됩니다.

    • Amazon RDS 9.6.10 이상, 10.5 이상, 11.1 이상, 12, 13, 14
    • Amazon Aurora 10.11 이상, 11.6 이상, 12.4 이상, 13.3 이상

  • VPC 네트워크의 비공개 서비스 액세스에 할당된 내부 IP 범위를 허용하도록 외부 서버의 방화벽을 구성해야 합니다. PostgreSQL용 Cloud SQL 복제본 데이터베이스는 VPC 네트워크를 비공개 네트워크로 사용합니다.

  • 소스 데이터베이스의 방화벽은 VPC 네트워크의 비공개 서비스 연결에 할당된 전체 내부 IP 범위를 허용하도록 구성해야 합니다. PostgreSQL용 Cloud SQL 대상 인스턴스는 IpConfiguration 설정의 privateNetwork 필드에서 이 VPC 네트워크를 사용합니다.

  • PostgreSQL용 Cloud SQL 인스턴스에 pglogical 확장 프로그램을 설치할 때는 enable_pglogical 플래그를 on (예: cloudsql.enable_pglogical=on)로 설정해야 합니다.

  • shared_preload_libraries 매개변수에 소스 인스턴스의 pglogical 확장 프로그램 (예: shared_preload_libraries=pg_stat_statements,pglogical)이 포함되어 있는지 확인합니다. rds.logical_replication 매개변수를 1로 설정합니다. 이 설정을 사용하면 논리적 수준에서 미리 쓰기 로그를 사용 설정할 수 있습니다.

    이러한 변경사항을 적용하려면 기본 인스턴스를 다시 시작해야 합니다.

PostgreSQL용 Cloud SQL을 복제에 사용하는 방법에 관한 자세한 내용은 PostgreSQL 복제 섹션의 외부 서버 체크리스트와 Cloud SQL 공식 문서의 PostgreSQL의 논리적 복제 및 디코딩 설정을 참고하세요.

PostgreSQL용 AlloyDB는 pglogical 확장 프로그램을 통한 복제를 지원합니다. 복제에 pglogical 확장 프로그램을 사용 설정하려면 CREATE EXTENSION 명령어를 사용하면 됩니다. 이 명령어를 사용하기 전에 먼저 확장 프로그램을 사용하려는 PostgreSQL용 AlloyDB 인스턴스에서 데이터베이스 플래그 alloydb.enable_pglogical 및 alloydb.logical_decoding를 on로 설정해야 합니다. 이 플래그를 설정하려면 인스턴스를 다시 시작해야 합니다.

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

Datastream을 사용하여 소스 PostgreSQL 인스턴스의 변경사항을 거의 실시간으로 복제할 수 있습니다. Datastream은 변경 데이터 캡처(CDC) 및 복제를 사용하여 데이터를 복제하고 동기화합니다. 그런 다음 Datastream을 사용하여 Amazon RDS 및 Amazon Aurora에서 지속적으로 복제할 수 있습니다. Datastream을 사용하여 PostgreSQL 인스턴스에서 BigQuery 또는 Cloud Storage로 변경사항을 복제합니다. 그런 다음 복제된 데이터를 Dataflow Flex 템플릿을 사용하거나 Dataproc을 사용하여 Dataflow와 함께 PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB 인스턴스로 가져올 수 있습니다.

Datastream 및 Dataflow 사용에 관한 자세한 내용은 다음 리소스를 참고하세요.

지속적 복제 마이그레이션을 위한 서드 파티 도구

경우에 따라 대부분의 데이터베이스 엔진에 하나의 서드 파티 도구를 사용하는 것이 더 나을 수 있습니다. 이러한 경우는 관리형 마이그레이션 서비스를 사용하고 싶고 대상 데이터베이스가 항상 소스와 거의 실시간으로 동기화되어야 하는 경우 또는 마이그레이션 프로세스 중에 데이터 정리, 재구성, 적응과 같은 더 복잡한 변환이 필요한 경우일 수 있습니다.

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

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

  • 장점:

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

  • 단점:

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

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

  • 장점:

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

  • 단점:

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

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

Fivetran은 클라우드 데이터 플랫폼에서 데이터를 이동하거나 여러 클라우드 데이터 플랫폼 간에 데이터를 이동하는 자동화된 데이터 이동 플랫폼입니다.

  • 장점:

    • 사전 구성된 연결 템플릿과 노 코드 파이프라인을 지원합니다.
    • 소스에서 대상 데이터베이스로 스키마 변경사항을 전파합니다.
    • 데이터 변경사항이 정확히 한 번만 전송되므로 중복 처리가 필요하지 않습니다.

  • 단점:

    • 오픈소스가 아닙니다.
    • 복잡한 데이터 변환 지원은 제한적입니다.

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

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

마이그레이션 범위를 정의하면 데이터베이스 마이그레이션 프로세스를 시작 하기 전과 진행 하는 동안 그리고 이후에 수행해야 하는 작업 태스크를 알 수 있습니다. 예를 들어 데이터베이스에서 특정 테이블을 마이그레이션하지 않도록 결정한 경우에는 이러한 필터링을 구현하기 위해 마이그레이션 이전 또는 마이그레이션 이후 태스크가 필요할 수 있습니다. 또한 데이터베이스 마이그레이션이 기존 서비스수준계약(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 또는 Amazon Aurora 인스턴스 준비 및 기본 요건
  • 소스 데이터베이스 준비 및 기본 요건
  • PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB 인스턴스 설정
  • 마이그레이션 관련 설정

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

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

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

  • 필요한 포트에서 원격 연결을 허용하도록 새 보안 그룹을 구성하고 Amazon RDS 또는 Amazon Aurora 인스턴스에 보안 그룹을 적용해야 할 수 있습니다.

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

  • Amazon RDS에서 이전하는 경우 Amazon RDS 인스턴스의 전체 로드 작업이 진행되는 동안 미리 쓰기 로그를 버퍼링할 만큼 충분한 여유 디스크가 있는지 확인합니다.

  • 진행 중인 복제 (CDC를 통한 변경사항 스트리밍)를 위해서는 읽기 복제본이 아닌 전체 RDS 인스턴스를 사용해야 합니다.

  • 기본 제공 복제를 사용하는 경우 PostgreSQL 복제를 위해 Amazon RDS 또는 Amazon Aurora 인스턴스를 설정해야 합니다. 기본 제공 복제 또는 기본 제공 복제를 사용하는 도구에는 PostgreSQL용 논리 복제가 필요합니다.

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

인스턴스 준비 및 기본 요건에 관한 자세한 내용은 PostgreSQL 복제를 위한 외부 서버 설정을 참고하세요.

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

  • Database Migration Service를 사용하려면 소스 데이터베이스에 연결하기 전에 소스 데이터베이스를 구성하세요. 자세한 내용은 PostgreSQL용 소스 구성 및 PostgreSQL용 소스를 PostgreSQL용 AlloyDB로 구성을 참고하세요.

  • 기본 키가 없는 테이블의 경우 Database Migration Service가 초기 백업을 마이그레이션한 후 CDC 단계에서 INSERT 문만 대상 데이터베이스로 마이그레이션됩니다. 이러한 테이블의 경우 DELETE 및 UPDATE 문이 마이그레이션되지 않습니다.

  • PostgreSQL의 논리적 디코딩 기능이 대규모 객체의 변경사항 디코딩을 지원하지 않으므로 Database Migration Service로 대규모 객체를 복제할 수 없습니다.

  • 기본 제공 복제를 사용하려면 데이터 정의 언어 (DDL) 명령어, 시퀀스, 대규모 객체와 관련된 제한사항이 있는 논리적 복제를 고려하세요. CDC를 사용 설정하고 많은 업데이트를 거치는 테이블에는 기본 키가 있어야 하며 기본 키가 추가되어야 합니다.

  • 일부 서드 파티 이전 도구에서는 모든 대형 객체 열이 null 허용 여부가 설정되어야 합니다. NOT NULL인 대규모 객체 열은 이전 중에 제약 조건을 삭제해야 합니다.

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

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

PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB 인스턴스 설정

대상 인스턴스의 성능 수준을 소스 인스턴스의 성능 수준과 비슷하게 하려면 대상 PostgreSQL 데이터베이스 인스턴스의 크기와 사양을 소스 인스턴스의 크기와 사양과 일치하도록 선택합니다. 특히 디스크 크기와 처리량, 초당 입력/출력 작업 수 (IOPS), 가상 CPU 수 (vCPU)에 주의해야 합니다. 잘못된 크기 조정은 마이그레이션 시간 장기화, 데이터베이스 성능 문제, 데이터베이스 오류, 애플리케이션 성능 문제로 이어질 수 있습니다. PostgreSQL용 Cloud SQL 또는 PostgreSQL용 AlloyDB 인스턴스를 결정할 때는 디스크 성능이 디스크 크기와 vCPU 수를 기반으로 한다는 점에 유의하세요.

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

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

  • PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB에서 일치하는 주 버전으로 마이그레이션합니다. 예를 들어 Amazon RDS 또는 Amazon Aurora에서 PostgreSQL 14.x를 사용하는 경우 PostgreSQL 버전 14.x의 경우 Cloud SQL 또는 PostgreSQL용 AlloyDB로 마이그레이션해야 합니다.

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

  • 데이터베이스 엔진 특정 구성 플래그를 검토하고 소스 및 대상 인스턴스 값을 비교합니다. 해당 영향을 파악하고 동일해야 하는지 여부를 확인합니다. 예를 들어 PostgreSQL을 사용할 때는 소스 데이터베이스의 pg_settings 테이블 값을 PostgreSQL용 Cloud SQL 및 AlloyDB 인스턴스의 값과 비교하는 것이 좋습니다. 소스 설정을 복제하도록 대상 데이터베이스 인스턴스에서 필요에 따라 플래그 설정을 업데이트합니다.

  • 워크로드의 특성에 따라 데이터베이스를 지원하기 위해 특정 확장 프로그램을 사용 설정해야 할 수도 있습니다. 워크로드에 이러한 확장 프로그램이 필요한 경우 지원되는 PostgreSQL 확장 프로그램과 PostgreSQL용 Cloud SQL 및 AlloyDB에서 이를 사용 설정하는 방법을 검토하세요.

PostgreSQL용 Cloud SQL 설정에 관한 자세한 내용은 인스턴스 구성 옵션, 데이터베이스 엔진별 플래그, 지원되는 확장 프로그램을 참고하세요.

PostgreSQL용 AlloyDB 설정에 관한 자세한 내용은 지원되는 데이터베이스 플래그 및 지원되는 확장 프로그램을 참고하세요.

마이그레이션 관련 설정

다운타임이 허용되는 경우 SQL 덤프 파일을 PostgreSQL용 Cloud SQL 및 AlloyDB로 가져올 수 있습니다. 이 경우 데이터베이스 덤프를 저장할 Cloud Storage 버킷을 만들어야 할 수 있습니다.

복제를 사용하는 경우 PostgreSQL용 Cloud SQL 및 AlloyDB 복제본에 기본 (소스) 데이터베이스에 대한 액세스 권한이 있는지 확인해야 합니다. 이 액세스 권한은 문서화된 연결 옵션을 사용하여 얻을 수 있습니다.

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

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

PostgreSQL용 AlloyDB로 마이그레이션하는 경우 PostgreSQL용 Cloud SQL 인스턴스를 대체 시나리오의 잠재적 대상으로 사용하는 것이 좋습니다. pglogical 확장 프로그램을 사용하여 해당 Cloud SQL 인스턴스에 논리 복제를 설정합니다.

자세한 내용은 다음 리소스를 참조하세요.

실행 태스크 정의

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

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

pg_dump 유틸리티를 사용하여 백업을 만듭니다. 이 유틸리티를 사용하여 데이터를 가져오고 내보내는 방법에 관한 자세한 내용은 다음 리소스를 참고하세요.

Database Migration Service 마이그레이션 작업

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

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

Database Migration Service에서 마이그레이션은 색인 및 제약 조건이 없는 초기 스키마 덤프 및 복원으로 시작하여 데이터 복사 작업이 이어집니다. 데이터 복사가 완료되면 색인과 제약 조건이 복원됩니다. 마지막으로 소스에서 대상 데이터베이스 인스턴스로의 변경사항의 연속 복제가 시작됩니다.

Database Migration Service는 소스에서 대상 데이터베이스 인스턴스로의 복제에 pglogical 확장 프로그램을 사용합니다. 이 확장 프로그램은 마이그레이션을 시작할 때 소스 Amazon RDS 또는 Amazon Aurora 인스턴스의 모든 테이블에 대한 독점적인 단기 잠금을 요구하여 복제를 설정합니다. 따라서 데이터베이스가 가장 비활성 상태일 때 마이그레이션을 시작하고 덤프 및 복제 단계에서는 소스의 문을 피하는 것이 좋습니다. DDL 문은 복제되지 않기 때문입니다. DDL 작업을 실행해야 하는 경우 'pglogical' 함수를 사용하여 소스 인스턴스에서 DDL 문을 실행하거나 초기 덤프 단계가 완료된 후에만 이전 대상 인스턴스에서 동일한 DDL 문을 수동으로 실행합니다.

Database Migration Service를 사용한 이전 프로세스는 승격 작업으로 종료됩니다. 데이터베이스 인스턴스를 승격하면 대상 데이터베이스가 소스 데이터베이스에서 발생하는 변경사항 흐름에서 연결 해제되고 이제 독립형 대상 인스턴스가 기본 인스턴스로 승격됩니다. 이 접근 방식을 프로덕션 전환이라고도 합니다.

자세한 마이그레이션 설정 프로세스는 PostgreSQL 및 PostgreSQL에서 PostgreSQL용 AlloyDB로의 빠른 시작 가이드를 참고하세요.

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

Cloud SQL은 PostgreSQL의 기본 제공 논리 복제와 pglogical 확장 프로그램을 통한 논리 복제라는 두 가지 유형의 논리 복제를 지원합니다. PostgreSQL용 AlloyDB의 경우 복제에 pglogical 확장 프로그램을 사용하는 것이 좋습니다. 각 유형의 논리적 복제에는 고유한 기능과 제한사항이 있습니다.

기본 제공 로직 복제에는 다음과 같은 기능과 제한사항이 있습니다.

  • PostgreSQL 10 이상에서 사용할 수 있습니다.
  • 모든 변경사항과 열이 복제됩니다. 게시물은 테이블 수준에서 정의됩니다.
  • 데이터는 기본 테이블에서 기본 테이블로만 복제됩니다.
  • 시퀀스 복제는 수행하지 않습니다.
  • 기본 키가 없는 테이블이 많은 경우 권장되는 복제 유형입니다. 기본 제공 PostgreSQL 논리 복제를 설정합니다. 기본 키가 없는 테이블의 경우 기본 키 대신 전체 행을 고유 식별자로 사용하도록 REPLICA IDENTITY FULL 양식을 적용합니다. 그러면 기본 키가 없는 테이블의 경우 기본 키 대신 전체 행을 고유 식별자로 사용하도록 REPLICA IDENTITY FULL 양식을 적용합니다.

pglogical 논리적 복제에는 다음과 같은 기능과 제한사항이 있습니다.

  • 모든 PostgreSQL 버전에서 사용할 수 있으며 교차 버전 지원을 제공합니다.
  • 소스에서 행 필터링을 사용할 수 있습니다.
  • UNLOGGED 및 TEMPORARY 테이블은 복제되지 않습니다.
  • UPDATE 및 DELETE 변경사항을 캡처하려면 테이블에 기본 키 또는 고유 키가 필요합니다.
  • 시퀀스 복제를 사용할 수 있습니다.
  • 복제가 지연될 수 있습니다.
  • 게시자가 여러 개이거나 복제된 데이터와 로컬 변경사항 간에 충돌이 있는 경우 충돌 감지 및 구성 가능한 해결 방법을 제공합니다.

PostgreSQL용 Amazon RDS 또는 Amazon Aurora와 같은 외부 서버에서 기본 제공 PostgreSQL 논리 복제를 설정하는 방법에 관한 안내는 다음 리소스를 참고하세요.

타사 도구

선택한 제3자 도구에 대한 모든 실행 태스크를 정의합니다.

이 섹션에서는 Striim을 예로 들고 설명합니다. Striim은 다양한 소스에서 데이터를 획득하고 데이터를 처리한 다음 다른 애플리케이션이나 타겟에 데이터를 전송하는 애플리케이션을 사용합니다.

하나 이상의 흐름을 사용하여 맞춤 애플리케이션 내에서 이러한 이전 프로세스를 구성합니다. 맞춤 애플리케이션을 코딩하려면 그래픽 프로그래밍 도구 또는 텅스텐 쿼리 언어 (TQL) 프로그래밍 언어 중에서 선택할 수 있습니다.

Striim 사용 방법에 관한 자세한 내용은 다음 리소스를 참고하세요.

Striim을 사용하여 데이터를 마이그레이션하려면 Striim을 사용하여 데이터를 Google Cloud로 마이그레이션하는 방법에 관한 다음 가이드를 참고하세요.

대체 시나리오 정의

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

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

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

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

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

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

단순 대체

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

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

역방향 복제

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

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

정방향 복제

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

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

중복 쓰기

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를 마이그레이션 도구로 사용하는 경우 '마이그레이션 확인' 주제의 PostgreSQL 또는 PostgreSQL에서 PostgreSQL용 AlloyDB로 버전을 참고하세요.

데이터 검증 도구

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

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

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

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

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

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

마이그레이션 수행

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

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

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

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

프로덕션 컷오버 수행

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

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

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

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

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

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

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

소스 환경 정리 및 PostgreSQL용 Cloud SQL 또는 AlloyDB 인스턴스 구성

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

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

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

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

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

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

또는 다른 인스턴스를 사용하고 변경사항을 해당 인스턴스에 복제할 수 있습니다. 예를 들어 PostgreSQL용 AlloyDB가 마이그레이션 대상인 경우 대체 시나리오를 위해 PostgreSQL용 Cloud SQL 인스턴스에 대한 복제를 설정하는 것이 좋습니다.

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

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

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

PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB 인스턴스의 유지보수 및 권장사항에 관한 자세한 내용은 다음 리소스를 참고하세요.

유지보수 및 권장사항에 대한 자세한 내용은 Cloud SQL 인스턴스의 유지보수 정보를 참고하세요.

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

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

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

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

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

최적화 요구사항 설정

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

데이터베이스의 안정성과 가용성 증가

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

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

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

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

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

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

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

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

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

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

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

PostgreSQL용 Amazon RDS 및 Aurora에서 PostgreSQL용 Cloud SQL로 마이그레이션할 때는 다음 가이드라인을 고려하세요.

  • 캐싱을 사용하여 읽기 성능을 개선합니다. pg_stat_database 뷰에서 다양한 통계를 검사합니다. 예를 들어 blks_hit / (blks_hit + blks_read) 비율은 99%보다 커야 합니다. 이 비율이 99%를 초과하지 않으면 인스턴스의 RAM 크기를 늘리는 것이 좋습니다. 자세한 내용은 PostgreSQL 통계 수집기를 참고하세요.
  • 공간을 확보하고 색인 성능 저하를 방지합니다. 데이터가 변경되는 빈도에 따라 PostgreSQL용 Cloud SQL에서 VACUUM 명령어를 실행하는 일정을 설정합니다.
  • Cloud SQL Enterprise Plus 버전을 사용하여 머신 구성 한도와 데이터 캐시를 늘립니다. Cloud SQL Enterprise Plus에 대한 자세한 내용은 Cloud SQL 버전 소개 를 참고하세요.
  • PostgreSQL용 AlloyDB로 전환합니다. 전환하면 처리 데이터베이스에서 완전한 PostgreSQL 호환성, 향상된 트랜잭션 처리, 빠른 트랜잭션 분석 워크로드를 지원할 수 있습니다. 색인 자문 기능을 사용하여 새 색인에 관한 추천도 받을 수 있습니다.

PostgreSQL용 Cloud SQL 데이터베이스 인프라의 성능을 높이는 방법에 관한 자세한 내용은 PostgreSQL용 Cloud SQL 성능 개선 문서를 참고하세요.

PostgreSQL용 Amazon RDS 및 PostgreSQL용 Aurora에서 PostgreSQL용 AlloyDB로 마이그레이션할 때 PostgreSQL용 AlloyDB 데이터베이스 인스턴스의 성능을 높이려면 다음 가이드라인을 고려하세요.

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

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

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

    • Cloud Monitoring을 사용해서 사용 중인 서비스 및 Google Cloud 리소스에 대한 측정값을 수집합니다. Cloud Monitoring에는 Cloud SQL 모니터링 대시보드를 비롯하여 여러 Google Cloud 제품에 대해 사전 정의된 대시보드가 포함되어 있습니다.
    • 적시에 알림을 받을 수 있도록 측정항목을 모니터링하고 알림 정책을 설정하는 데 도움이 되는 커스텀 대시보드를 만들 수 있습니다.
    • 또는 Datadog 및 Splunk와 같이 Google Cloud에 통합된 서드 파티 모니터링 솔루션을 사용하는 것이 좋습니다.

  • Cloud Logging은 일반적인 애플리케이션 구성요소에서 로깅 데이터를 수집합니다.

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

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

데이터베이스 인프라의 관측 가능성을 높이는 방법에 관한 자세한 내용은 다음 문서 섹션을 참고하세요.

일반적인 Cloud SQL 및 PostgreSQL용 AlloyDB 권장사항 및 운영 가이드라인

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

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

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

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

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

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

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

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

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

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

PostgreSQL용 Cloud SQL 및 PostgreSQL용 AlloyDB의 경우 다음 권장사항을 고려하세요.

  • 기본 인스턴스에서 트래픽을 오프로드하려면 읽기 복제본을 추가하세요. HAProxy와 같은 부하 분산기를 사용하여 복제본에 대한 트래픽을 관리할 수도 있습니다. 하지만 복제본이 너무 많으면 VACUUM 작업이 방해받으므로 주의하세요. HAProxy 사용에 관한 자세한 내용은 공식 HAProxy 웹사이트를 참고하세요.
  • 시스템 메모리와 maintenance_work_mem 매개변수를 늘려 VACUUM 작업을 최적화합니다. 시스템 메모리를 늘리면 각 반복에서 더 많은 튜플을 일괄 처리할 수 있습니다.
  • 색인 크기가 크면 색인 스캔에 상당한 시간을 소비하므로 INDEX_CLEANUP 매개변수를 OFF로 설정하여 테이블 데이터를 빠르게 삭제하고 고정합니다.
  • PostgreSQL용 AlloyDB를 사용할 때는 PostgreSQL용 AlloyDB 시스템 통계 대시보드와 감사 로그를 사용하세요. PostgreSQL용 AlloyDB 시스템 통계 대시보드는 사용하는 리소스의 측정항목을 표시하고 이를 모니터링할 수 있도록 지원합니다. 자세한 내용은 PostgreSQL용 AlloyDB 문서의 인스턴스 모니터링 주제에 나온 가이드라인을 참고하세요.

자세한 내용은 다음 리소스를 참조하세요.

다음 단계

참여자

저자:

다른 참여자: 솜디유티 폴 | 데이터 관리 전문가