AWS Database Migration Workshop

👉🏻 DMS

• 각종 데이터베이스를 DMS를 사용하여 AWS Cloud로 마이그레이션하거나, 온-프레미스 인스턴스 간, 또는 클라우드와 온-프레미스 설정의 조합 간에 마이그레이션을 할 수 있다.
• 동종 마이그레이션 뿐, 아니라 이기종 데이터베이스 플랫폼 간의 마이그레이션도 지원해준다.
• 쉽게 말하여 DMS Migration은 기존 DB의 데이터를 새 DB에 옮겨주는 이삿짐 센터라고 생각하면 좋다.

👉🏻 마이그레이션 유형

• 전체 로드 (기존 데이터 마이그레이션)
  • 기존 데이터를 복사할 수 있을 정도의 긴 중단을 감당할 수 있는 경우
• 전체 로드 및 CDC (기존 데이터 마이그레이션 및 변경 사항 복제)
  • 전체 로드 완료 후, CDC 작업을 통해 변경된 데이터를 복제함
• CDC Only
  • 대량의 데이터 동기화를 위해 사용

⁉️CDC란 무엇이고, 어떤 구조로 데이터를 복제할까?

• CDC (Change Data Capture)
  • 데이터에 대한 변경을 식별해 필요한 후속처리를 자동화 하는 기술 또는 설계 기법
• 구조
  • 테이블의 전체로드가 진행되는 동안, 로드되는 테이블에 대한 변경 사항은 복제 서버에 캐시된다.
  • 주어진 테이블에 대한 변경 사항 캡처는 해당 테이블에 대한 전체로드가 시작될 때까지는 시작되지 않는다는 것이 중요. 즉, 각 테이블 마다 변경 시작 캡처가 달라지게 된다.
  • 따라서 테이블에 대한 전체로드 완료 후, 캐시 된 변경 사항이 즉시 적용된다.
  • 이후, 모든 테이블이 로드 되면 지속적인 복제 단계로 넘어가며 해당 단계에서는 트랜잭션으로 변경 사항을 수집한다.
  • 캐시 된 모든 변경 사항이 적용된 후에는 테이블이 트랜잭션적으로 일관되고 지속적인 복제 단계로 이동하여 변경 사항을 트랜잭션으로 적용하게 된다.

• CDC 구현 기법
  • Time Stamp On Rows
    • 테이블 내, 마지막 변경 시점을 기록하는 타임스탬프 컬럼 존재
    • 최근 타임스탬프가 생기면 레코드가 변경된 것으로 식별
  • Version Numbers On Rows
    • 테이블 내, 버전을 기록하는 컬럼 존재
    • 더 높은 버전을 보유한 레코드가 발견되면 변경으로 식별
  • Status On Rows
    • 타임 스탬프 및 버전 넘버 기법에 대한 보완 용도로 활용
    • 타임 스탬프 및 버전에 따라 데이터 변경 여부를 True / False의 Boolean 값으로 저장하는 컬럼 존재
  • Time / Version / Status On Rows
    • 타임스탬프, 버전 넘버, 상태 값의 세가지 특성을 모두 활용한 기법
  • Event Programming
    • 데이터 변경 식별 기능을 애플리케이션에 구현
      • 애플리케이션의 복잡도 증가되나, 다양한 조건에 의한 CDC 매커니즘 구현 가능
  • Log Scanner On Database - DMS CDC 작업
    • 트랜잭션 로그에 대한 스캐닝 및 변경 내역에 대한 해석을 통해 CDC 매커니즘 구현

• CDC 구현 방식
  • PUSH 방식
    • 소스 시스템에서 변경을 식별하고 대상 시스템에서 변경 데이터를 적재해 주는 방식
  • POOL 방식
    • 대상 시스템에서 소스 시스템을 정기적으로 관찰하여, 필요 시 데이터를 다운로드 하는 방식
• DMS에서 해당 CDC 작업을 위해 Source Database의 Binary Log를 활성화하고, binlog_format 파라미터를 ROW로 설정해야 한다.

Binlog (Binary Log)는 데이터 변깅 시, 변경 내역들을 지정해 놓은 로그
- Row-based Type : 변경된 행 자체를 BASE64로 Encoding 하여 Binary Log에 기록하는 방식

⭐️ 지속적 복제에서 중간에 중단한다면 ?

• 복제된 위치(트렌젝션 ID)를 DMS 복제 인스턴스 내, Cache에 저장하기 때문에 해당 위치부터 다시 시작하는 것이 가능

👉🏻 AWS SCT (Schema Conversion Tool)

• 이기종 간의 데이터 마이그레이션을 진행하기 위해 스키마 생성이 선행되어야 한다.
• 이기종 간의 스키마 구조는 동일하게 하더라도, 데이터 타입은 각 벤더마다 지원하는 부분이 다르다.
  • 이처럼, 각 벤더사에서 제공하는 데이터 타입에서 불일치에 대한 변환 작업과, 수동 작업으로 발생하는 여러가지 문제를 해결하기 위한 솔루션
• 변환된 스키마는 Amazon RDS MYSQL, MariaDB, 오라클, SQL 서버, Aurora DB 클러스터, Amazon Redshift 클러스터에 적합하고, 변환된 스키마는 Amazon EC2 인스턴스에서 데이터베이스와 함께 사용하거나 S3 버킷에 데이터로 저장 할 수 있다.
• AWS Schema Conversion Tool은 이기종 데이터베이스 마이그레이션에서 가장 시간이 많이 걸리는 작업이지만 해당 툴을 사용하면 쉽게 변환이 된다.

 

👉🏻  실습 내용

• AWS Database Migration Service를 사용하여 Amazon EC2 인스턴스에서 실행 중인 원본 Microsoft SQL Server에서 대상 Amazon Aurora(MySQL)로 데이터를 마이그레이션
• 또한 AWS DMS를 사용하여 원본 데이터베이스에서 대상 데이터베이스로 데이터베이스 변경 사항을 지속적으로 복제
• AWS DMS는 데이터 마이그레이션과 특별히 관련이 없는 보조 인덱스, 시퀀스, 기본값, 저장 프로시저, 트리거, 동의어, 보기 및 기타 스키마 객체를 마이그레이션하지 않습니다. 이러한 객체를 Aurora MySQL 대상으로 마이그레이션하기 위해 이전 섹션에서 AWS Schema Conversion Tool을 사용했습니다.

• 대상 데이터베이스 엔진으로 자동 변환할 수 없는 스키마 항목의 경우, 요약에는 대상 DB 인스턴스에서 소스 내의 스키마 항목과 동일한 스키마 항목을 생성하는데 필요한 예상 노력이 요약되어 있다.
• 위의 보고서에는 스키마 항목을 변환하는 예상 시간을 아래와 같이 분류된다.
  • 변환된 항목
  • 2시간 이내 완료할 수 있는 작업
  • 더 복잡하고 2~6시간 내에 완료 할 수 있는 작업
  • 매우 복잡하고 완료하는데 6시간 이상 걸리는 작업

• 해당 작업 항목 탭에서는 SCT가 자동으로 변환할 수 없는 항목 목록들이 포함되어 있다.
• 해당 보고서에는 스키마 항목을 수동으로 변환하는 방법에 대한 권장사항들도 포함되어 있다.
• 하단 SQL 탭에서 수동으로 변환이 필요한 스키마를 변경하여 업데이트하면 프로젝트와 함께 자동 저장된다.

DMS 모니터링

• 작업 모니터링 - 작업 모니터링 탭은 전체 로드 처리량과 변경 캡처 및 적용 지연 시간에 대한 통찰력을 제공
• 테이블 통계 — 테이블 통계 탭은 처리된 행 수, 처리된 트랜잭션 유형 및 수에 대한 자세한 정보와 DDL 작업에 대한 정보를 제공
• 로그 — 로그 탭에서 작업의 로그 파일을 볼 수 있습니다(로그온을 켠 것으로 가정). 어떤 이유로 작업이 실패하면 이 파일에서 오류를 검색합니다. 또한 파일에서 경고를 찾을 수 있습니다. 작업의 모든 데이터 잘림은 로그 파일에 경고로 나타납니다. 필요한 경우 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 로깅 수준을 높일 수 있습니다