소개
AWS Database Migration Service는 데이터베이스를 AWS로 빠르고 안전하게 마이그레이션할 수 있도록 지원합니다. 마이그레이션하는 동안 소스 데이터베이스가 변함없이 운영되어 해당 데이터베이스를 사용하는 애플리케이션의 가동 중지 시간을 최소화할 수 있습니다. AWS Database Migration Service를 사용하면 가장 널리 사용되는 상용 및 오픈 소스 데이터베이스로(부터) 데이터를 마이그레이션할 수 있습니다.
AWS Database Migration Service는 Oracle에서 Oracle로의 마이그레이션과 같은 동종 마이그레이션뿐 아니라 Oracle 또는 Microsoft SQL Server에서 Amazon Aurora로의 마이그레이션과 같은 이기종 데이터베이스 플랫폼 간의 마이그레이션도 지원합니다. AWS Database Migration Service를 사용하면 고가용성으로 데이터를 연속적으로 복제할 수 있으며 Amazon Redshift 및 Amazon S3로 데이터를 스트리밍하여 페타바이트급 규모의 데이터 웨어하우스에 데이터베이스를 통합할 수 있습니다.
- 동종 마이그레이션 (동일한 엔진 유형 간의 마이그레이션)
- 이기종 마이그레이션 (다른 엔진 유형 간 마이그레이션)
데이터베이스를 Amazon Aurora, Amazon Redshift, Amazon DynamoDB 또는 Amazon DocumentDB(MongoDB 호환 가능)로 마이그레이션하는 경우 6개월 동안 DMS를 무료로 사용하실 수 있습니다
- 복제 인스턴스
- 상위 수준에서AWS DMS복제 인스턴스는 하나 이상의 복제 작업을 호스팅하는 관리형 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스일 뿐입니다.
- 복제 인스턴스 하나는 마이그레이션의 성격과 복제 서버의 용량에 따라 복제 작업을 한 개 이상 호스팅할 수 있습니다.
- AWS DMS는 다중 AZ 배포를 사용해 고가용성과 장애 조치 기능을 지원합니다. 다중 AZ 배포에서 AWS DMS는 자동으로 서로 다른 가용 영역에 복제 인스턴스의 예비 복제본을 프로비저닝하고 유지합니다. 기본 복제 인스턴스는 대기 복제본에 동기식으로 복제됩니다. 기본 복제 인스턴스에 장애가 발생하거나 무응답 상태가 되면 대기 복제본은 중단을 최소화하면서 실행 중이던 작업을 다시 시작합니다. 기본 복제본은 자신의 상태를 끊임없이 대기 복제본으로 복제하기 때문에 다중 AZ 배포는 약간의 성능 오버헤드를 발생시킵니다.
- Endpoint
- 소스
- 지원 범위
💡 소스 Database의 권한! → 소스 Database의 Tlog및 Redo Log를 읽을 수 있는 권한이 필요하기에 Admin에 준하는 권한을 요구함 - 대상
- 지원범위 :
- 마이그레이션 유형
- 전체 로드(기존 데이터 마이그레이션) - 기존 데이터를 복사할 수 있을 정도의 긴 중단을 감당할 수 있는 경우
- 전체 로드 및 CDC(기존 데이터 마이그레이션 및 변경 사항 복제) - 전체 로드 완료후 CDC 작업을 통하여 변경된 데이터를 복제함
- CDC Only - 서드파티 또는 AWS의 import/export 서비스를 사용후 대량 데이터 동기화를 위하여 사용
- 테이블 작업
- 아무 작업 안함 - 기존 테이블이 미리 생성 되어 있다는 가정하에 진행함
- 대상 테이블 삭제 - 테이블 drop 후 생성
- 자르기 - 대상 테이블이 없을경우 생성복제작업
- 소스
- 원본 데이터베이스 열 데이터 유형은 중간 AWS DMS 데이터 유형으로 변환됩니다.
- AWS DMS 데이터 유형은 대상 데이터 유형으로 변환됩니다.
💡 CDCLatencyTarget 및 CDCLatencySource 그래프는 페이지 하단에 표시됩니다. 대상 지연 시간을 표시하는 작업이 있다면 애플리케이션 속도를 높이는 데 필요한 대상 엔드포인트 튜닝이 있을 가능성이 있습니다.
전체로드 중에 데이터는 소스 데이터베이스의 테이블에서 대상 데이터베이스의 테이블로 한 번에 8 개 테이블 (기본값)로로드됩니다. 전체로드가 진행되는 동안로드되는 테이블에 대한 변경 사항은 복제 서버에 캐시됩니다. 이것은 캐시 된 변경 사항입니다. 주어진 테이블에 대한 변경 사항 캡처는 해당 테이블에 대한 전체로드가 시작될 때까지 시작되지 않는다는 것을 아는 것이 중요합니다. 즉, 각 개별 테이블의 변경 시작 캡처가 달라집니다. 주어진 테이블에 대한 전체로드가 완료된 후 해당 테이블에 대해 캐시 된 변경 사항을 즉시 적용 할 수 있습니다. 모든 테이블이로드되면 지속적인 복제 단계에 대한 트랜잭션으로 변경 사항을 수집하기 시작합니다. 캐시 된 모든 변경 사항이 적용된 후에는 테이블이 트랜잭션 적으로 일관되고 지속적인 복제 단계로 이동하여 변경 사항을 트랜잭션으로 적용합니다.
지속적인 복제 단계에 처음 진입하면 트랜잭션 백 로그가 발생하여 소스와 대상 데이터베이스간에 약간의 지연이 발생합니다. 이 백 로그를 처리 한 후 시스템은 결국 안정된 상태에 도달합니다. 이 시점에서 준비가되면 다음을 수행 할 수 있습니다.
그렇다면 CDC는 어떤 구조로 데이터를 복제할까?
Change Data Capture란 데이터에 대한 변경을 식별해 필요한 후속처리를 자동화 하는 기술 또는 설계 기법 이자 구조이며 실시간 또는 준 실시간 데이터 통합을 기반으로 하는 데이터 웨어하우스 및 기타 데이터 저장소 구축에 폭 넓게 사용되고 있다.
CDC 구현 기법
- Time Stamp on Rows
- 테이블 내 마지막 변경 시점을 기록하는 타임스탬프 컬럼 존재
- 최근 타임스탬프가 생기면 레코드가 변경된 것으로 식별
- Version Numbers on Rows
- 테이블 내 버전을 기록하는 컬럼 존재
- 더 높은 버전을 보유한 레코드가 발견되면 변경으로 식별
- Status on Rows
- 타임 스탬프 및 버전 넘버 기법에 대한 보완 용도로 활용
- 타임 스탬프 및 버전에 따라 데이터 변경의 여부를 True/False의 불린(boolean)값으로 저장하는 칼럼 존재
- 불린(boolean)값을 기반으로 변경 여부 판단
- Time/Version/Status on Rows
- 타임스탬프, 버전 넘버, 상태 값의 세가지 특성을 모두 활용하는 기법
- Triggers on Tables
- 데이터베이스 트리거를 활용 사전에 등록(Subscribe)된 다수 대상 시스템(Target)에 변경 데이터를 배포(Publish)하는 형태로 CDC를 구현
- 데이터베이스 트리거는 시스템 복잡도 증가, 변경 관리의 어려움, 확장성의 감소를 유발하는 등 시스템 유지보수성을 저하시키는 특성이 있음
- Event Programming
- 데이터 변경 식별 기능을 애플리케이션에 구현
- 이로인해 애플리케이션 개발 부담과 복잡도를 증가시키나, 다양한 조건에 의해 CDC 매커니즘을 구현
- Log Scanner on Database
- 트랜잭션 로그에 대한 스캐닝 및 변경 내역에 대한 해석을 통해 CDC 매커니즘을 구현
- 다수의 서로 다른 데이터베이스를 사용하는 환경에서 적용 시 작업 규모가 증가될 수 있으므로 주의가 필요
- 장점 : 데이터베이스와 사용 애플리케이션에 대한 영향도 최소화, 변경 식별 지연시간 최소화, 트랜잭션 무결성에 대한 영향도 최소화, 데이터베이스 스키마 변경 불필요
CDC 구현 방식
- 푸시(Push) 방식 : 데이터 원천(Source)에서 변경을 식별하고 대상 시스템(Target)에 변경 데이터를 적재해 주는 방식
- 풀(Pool) 방식 : 대상 시스템(Target0에서 데이터 원천(Source)을 정기적으로 살펴보고, 필요 시 데이터를 다운로드 하는 방식
AWS DMS의 CDC 작동방식
- MySQL 설정에서 Binary log를 활성화하고 CDC를 위해 binlog_format 파라미터를 ROW로 설정합니다.
위의 그림과 같이 AWS DMS CDC 작업은 Log Scanner on Database 방식으로 해당 Tlog 또는 Oracle의 경우 REDO 로그를 읽어 복제작업을 진행합니다.
💡 그렇다면 중간에 중지되면 어떻게 될까? → 복제된 위치(트렌젝션 ID)를 DMS 복제 인스턴스내 Cache에 저장하고 해당 위치부터 다시 시작하는것이 가능하다!
- Source Database에 대한 부하 감소 방안
- 마이그레이션 중에 AWS DMS는 처리중인 각 소스 테이블의 전체 테이블 스캔(일반적으로 병렬적 스캔)을 수행합니다. 또한 각 작업은 주기적으로 소스에서 변경 정보를 쿼리합니다. 변경 처리를 수행하려면 데이터베이스의 변경 로그에 기록되는 데이터의 양을 늘려야 할 수 있습니다. 소스 데이터베이스에 과부하가 걸린 경우 마이그레이션 작업 당 작업 또는 테이블 수를 줄일 수 있습니다. 소스에로드를 추가하지 않으려면 소스 시스템의 읽기 사본에서 마이그레이션을 수행하는 것이 좋습니다.
SCT(Schema Conversion Tool)
AWS Schema Conversion Tool은 소스 데이터베이스 스키마와 뷰, 저장 프로 시저 및 함수를 포함한 대부분의 데이터베이스 코드 객체를 대상 데이터베이스와 호환되는 형식으로 자동 변환하여 이기종 데이터베이스 마이그레이션을 예측 가능하게합니다. 자동으로 변환 할 수없는 개체는 마이그레이션을 완료하기 위해 수동으로 변환 할 수 있도록 명확하게 표시됩니다. SCT는 또한 임베디드 SQL 문에 대한 애플리케이션 소스 코드를 스캔하고이를 데이터베이스 스키마 변환 프로젝트의 일부로 변환 할 수 있습니다. 이 프로세스 동안 SCT는 레거시 Oracle 및 SQL Server 기능을 동등한 AWS 서비스로 변환하여 클라우드 네이티브 코드 최적화를 수행하므로 데이터베이스 마이그레이션과 동시에 애플리케이션을 현대화 할 수 있습니다.
사용 용도
- 이기종간 마이그레이션
- Oracle을 MySQL로 또는 SQL Server를 Oracle로 복사 하는 경우
- 데이터베이스 분석및 변환 복잡성 파악
- 데이터베이스 분석및 제약 사항 파악
- 라이선스 이슈 및 다운그레이드 가능 여부 파악
- 내장 SQL 코드 변환(프로시져, 트리거등)
- 간단한 ETL 작업(컬럼 제외 및 타입 변경등)
제약사항
- 기본 스키마 복사는 보조 인덱스, 외래 키 또는 저장 프로시저는 마이그레이션하지 않습니다.
- 대상(Target)이 Oracle Database인 경우 AWS DMS는 보안상의 이유로 스키마를 생성하지 않습니다.
💡 다만, AWS DMS는 테이블, 기본 키 및 경우에 따라 고유 인덱스를 생성합니다. → 마이그레이션이 이기종 인 경우 AWS Schema Conversion Tool (AWS SCT)을 사용하여 대상 스키마를 생성 할 수 있습니다.
'Server Infra > AWS' 카테고리의 다른 글
| EBS 지연 현상 (0) | 2022.01.11 |
|---|---|
| AWS Advanced Networking - Specialty 취득 후기 (4) | 2022.01.08 |
| DynamoDB (0) | 2022.01.05 |
| AWS Elasticsearch Service (0) | 2022.01.05 |
| Lambda란? (1) | 2022.01.05 |
