AWS DMS를 통한 S3 데이터 레이크로의 관계형 DB 마이그레이션, 제1부

AWS

AWS 데이터베이스 마이그레이션 서비스는 관계형 데이터베이스, NoSQL 데이터베이스, 데이터 웨어하우스 및 모든 유형의 데이터 저장소를 AWS 클라우드로 또는 클라우드와 온프레미스 환경 간에 효율적이고 안전하게 마이그레이션하는 클라우드 서비스입니다. DMS는 Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift, S3 등과 같은 여러 유형의 소스 및 대상 데이터베이스를 지원합니다.

데이터 마이그레이션 중 관찰 사항

우리는 온프레미스의 Oracle, MS SQL Server, MySQL, Postgres SQL 및 MongoDB의 데이터 소스를 사용하여 AWS S3 데이터 레이크와 AWS Redshift에서 데이터 웨어하우스를 설계하고 생성하는 작업을 했습니다. 우리는 이러한 소스에서 AWS S3로 초기 전체 로드 및 일일 증분 데이터 전송을 위해 AWS DMS를 사용했습니다.

이 일련의 게시물에서는 다양한 관계형 데이터베이스를 사용한 실제 데이터 마이그레이션 중에 직면한 여러 가지 문제를 설명하고자 합니다.

1. 소스에서 수정된 날짜가 제대로 채워지지 않음

AWS DMS는 소스 데이터베이스에서 전체 로드 및 변경 데이터 캡처에 사용됩니다. AWS DMS는 트랜잭션 로그를 기반으로 변경된 레코드를 캡처하지만, 올바르게 업데이트된 수정 날짜 열은 중복 제거 로직을 적용하고 S3의 대상에서 주어진 행에 대한 최신 수정 레코드를 추출하는 데 도움이 될 수 있습니다.

테이블에 대해 수정된 데이터가 없거나 제대로 업데이트되지 않은 경우, AWS DMS는 소스 데이터베이스에서 데이터를 추출할 때 새 열을 추가하기 위한 변환 규칙 옵션을 제공합니다. 여기서 AR_H_CHANGE_SEQ 헤더는 소스 데이터베이스에서 타임스탬프와 자동 증가 번호로 구성된 고유 증가 번호로 값이 설정된 새 열을 추가하는 데 도움을 줍니다.

아래 코드 예제는 소스에서 고유 증가 번호를 가진 DMS_CHANGE_SEQ라는 새 열을 대상으로 추가합니다. 이는 첫 16자리가 타임스탬프이고 다음 19자리가 데이터베이스에 의해 증가된 레코드 ID 번호인 35자리의 고유 번호입니다.

JSON

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. 소스로서 오라클에 대한 보조 로깅 활성화

소스 데이터베이스로서 오라클의 경우, 진행 중인 변경 사항을 캡처하기 위해 AWS DMS는 소스 데이터베이스에서 최소한의 보조 로깅을 활성화해야 합니다. 이에 따라, 이는 소스에서 변경 사항을 식별하기 위한 추가 정보와 열을 redo 로그에 포함합니다.

모든 열에 대한 보조 로깅은 소스 데이터베이스의 테이블에 대한 모든 열을 캡처하고 대상 AWS S3 레이어에서 전체 레코드를 덮어쓰는 데 도움이 됩니다.

모든 열의 보조 로깅은 테이블의 모든 열이 로그에 기록되므로 redo 로그의 크기를 증가시킵니다. 추가 정보를 고려하기 위해 redo 및 아카이브 로그를 적절히 구성해야 합니다.

3. 소스와 대상 데이터베이스 간의 네트워크 대역폭

온프레미스 소스에서 Oracle, MS SQL Server 등으로의 초기 전체 로드는 잘 작동했으며 대부분의 경우 데이터 변경 캡처도 잘 수행되었습니다.

특정 월의 하루 중 대부분의 시간에는 적당한 수의 트랜잭션이 있었지만, 업무 종료 프로세스, 매일 자정 이후 및 월말 활동을 제외하고는 그러했습니다. 이 시간 동안 DMS 마이그레이션 작업이 동기화되지 않거나 실패하는 것을 관찰했습니다.

로그에서 소스, 대상 및 복제 인스턴스 메트릭을 검토한 결과 다음과 같은 관찰 결과를 발견했습니다:

CDCLatencySource – 소스 엔드포인트에서 캡처된 마지막 이벤트와 AWS DMS 인스턴스의 현재 시스템 타임스탬프 사이의 간격(초 단위)입니다.
CDCIncomingchanges – 대상에 적용되기를 기다리는 특정 시점의 변경 이벤트 총 수입니다. 이는 조정 활동 중 이른 아침에 0에서 수천으로 증가합니다.
CDCLatencySource – 소스 엔드포인트에서 마지막으로 캡처된 이벤트와 AWS DMS 인스턴스의 현재 시스템 타임스탬프 간의 차이(초)입니다. 이 값은 매일 자정 이후 조정 작업 중 0에서 몇 천 초에서 10-12K 초까지 증가합니다. 이 값은 월말 활동 중에는 40K까지 증가했습니다.

추가 로그 분석 및 다른 메트릭 검토를 통해 다음을 관찰했습니다:

AWS DMS 메트릭 NetworkReceiveThroughput은 고객 데이터베이스 및 DMS 트래픽을 위한 DMS 복제 인스턴스로의 들어오는 트래픽을 이해하는 데 도움이 됩니다. 이러한 메트릭은 소스 데이터베이스와 DMS 복제 인스턴스 간에 발생할 수 있는 네트워크 관련 문제를 이해하는 데 도움이 됩니다.

네트워크 수신 처리량이 소스와 AWS 간 VPN 연결로 인해 다른 응용프로그램과 공유되었던 30MB/s(즉, 250Mb/s)까지 증가했다는 사실을 관찰했습니다.

이 문제에 대한 최종 결론은 소스 및 대상 데이터베이스 간의 연결이 성공적인 데이터 마이그레이션에 중요하다는 것입니다. 실제 데이터 마이그레이션 전에 온프레미스 또는 다른 클라우드 소스 데이터베이스와 AWS 환경 간에 충분한 대역폭이 설정되어 있는지 확인해야 합니다.

AWS Site-to-Site VPN 또는 Oracle Cloud Infrastructure(OCI) Site-to-Site VPN(Oracle AWS)과 같은 VPN 터널을 통해 최대 1.25 Gbps의 처리량을 제공할 수 있습니다. 이는 소규모 테이블 마이그레이션이나 DML 트래픽이 적은 테이블 마이그레이션에 적합할 것입니다.
대규모 데이터 이관 시 테이블당 초당 무거운 트랜잭션이 발생하는 경우, AWS Direct Connect를 고려해야 합니다. 이는 1 Gbps, 10 Gbps 등의 대역폭을 지원하는 전용 프라이빗 연결 생성 옵션을 제공합니다.

결론

이것은 관계형 데이터베이스 이관을 위한 다중 파트 시리즈의 일부입니다. AWS DMS를 사용한 이러한 도전 과제와 구현된 해결책에 대해 다룹니다. 이 시리즈에서 언급된 대부분의 도전 과제는 데이터베이스 이관 과정 중 발생할 수 있으며 이러한 해결책을 참고할 수 있습니다.

Source:
https://dzone.com/articles/relational-databases-migration-to-aws-environment