[AWS RDS] AWS RDS for Oracle 교차 리전 자동 백업 – Part 1/2

-          교차 리전 자동 백업을 사용하여 RPO, RTO 효율화 하기

 

l  Version : AWS RDS for Oracle

 

AWS에서 관리형 데이터베이스로 제공하는 RDS for Oracle 사용하면 AWS 리전 내의 데이터베이스 인스턴스에 대한 향상된 가용성과 내구성을 얻을 있다. 여러 리전에 걸쳐 DR 구성을 하면 미션 크리티컬한 데이터베이스를 실행할 읽기 전용 RDS 사용할 있어, 사용자에게 가까운 다른 리전에서 프로덕션 읽기에 대한 워크로드를 처리할 있다. 또한 스냅샷과 아카이브된 redo로그를 포함하는 Oracle Amazon RDS 교차 리전 자동 백업을 사용하면 낮은RPO(복구 시점 목표) 감소된 RTO(복구 시간 목표) 비용 효율적인 교차 리전 DR 구성할 있다.

 

이번 포스트는 교차 리전 자동 백업에 대해서 2회에 걸쳐 설명하며 이번 포스트에서는 Part 1으로  개념에 대해서 설명한다.  AWS RDS for Oracle 중점을 두었지만 AWS RDS for PostgreSQL에서도 리전 자동 백업을 사용할 있다. 자세한 내용은 원문을 참고한다.

l  Managed disaster recovery with Amazon RDS for Oracle cross-Region automated backups – Part 1 : https://aws.amazon.com/blogs/database/managed-disaster-recovery-with-amazon-rds-for-oracle-cross-region-automated-backups-part-1/

 

교차 리전 자동 백업은 단일 리전에서 현재 Amazon RDS 백업 복구 자동화에 사용하는 것과 동일한 솔루션을 제공하지만 데이터베이스 인스턴스를 복원하는데 필요한 모든 데이터를 번째 리전에서 즉시 사용할 있도록 추가 보호 기능을 제공한다. 기능은 Amazon RDS 자동 백업 기능을 확장하여 기본 리전에서 보조 리전으로 스냅샷 아카이브된 redo 로그의 자동 복제를 설정할 있는 기능을 제공한다.

 

Amazon RDS for Oracle에서는 12.1(12.1.0.2 v10 부터)이상의 버전에 대해 교차 리전 자동 백업을 지원한다. 기능은 LI(License Included) 또는 BYOL(Bring Your Own License)모델로 Oracle Database 모든 에디션을 사용하는 Oracle Amazon RDS 고객에게 지원된다. BYOL 고객은 Oracle 계약을 검토하여 기능의 사용이 허용되는지 확인해야한다.

 

교차 리전 자동 백업을 사용하면 RDS 인스턴스가 상주하는 소스 리전에서 캡처 보관된 스냅샷, 아카이브된 redo 로그 백업이 자동으로 번째 리전에 복사된다. 그런 다음 RDS 선택한 백업 보존 기간에 따라 스냅샷 아카이브 로그를 유지관리하여 대상 리전에서 특정 시점 복원(PITR)기능을 활성화 한다.

 

 

Amazon RDS 리전 자동 백업을 사용하면 대상 리전에서는 원본 리전과 다른 복구 기간을 선택할 있다. 그리고 원본 리전의 로그가 즉시 번째 리전에 복사되므로 리전 자동 백업을 통해서 사이트와 장애조치 사이트를 장거리로 분리할 있다. 아래는 교차 리전 자동 백업에 대한 장점이다.

l  교차 리전 자동 백업은 컴퓨팅 경우에 따라 다른 리전에서 PITR 필요할 때까지 라이선스 비용을 절약하는데 도움이 되는 비용 효율적인 DR 기능이 필요한 경우에 이상 적이다.

l  교차 리전 자동 백업은 리전 간에 RDS 스냅샷을 복사하는 스크립팅에 시간과 리소스가 부족하고 수동 리전 스냅샷 복사 보다 낮은 RPO 필요한 경우에도 유용하다.

l  기능은 수동 스냅샷을 자동으로 복제하여 스냡샷이 복원된 적용해야 하는 redo 로그 양을 줄여 대상 리전에서 낮은 RTO 제공하는데 도움이 있다.

 

일반 작업 중에 자동 백업을 활성화하면 Amazon RDS 5 간격으로 인스턴스에서 생성된 아카이브된 redo 로그 복사와 함께 정의한 백업 기간 동안 RDS DB 인스턴스 스토리지의 일일 스냅샷을 만든다. 이러한 백업은 RDS DB 인스턴스가 있는 리전의 Amazon Simple Storage Service(Amazon S3) 저장된다. 교차 리전 자동 백업을 사용하면 이러한 동일한 스냅샷 아카이브된 로그가 소스 리전에서 사용 가능하게 되는 즉시 번째 리전에 복제된다.

 

스냅샷 생성은 RDS DB 인스턴스에서 5분마다 시작되기 때문에 원본 리전의 RDS 인스턴스에 대한 일반적인 RPO 5~10분이다. 원격 리전의 경우 복사 시간이 길기 때문에 교차 리전 백업의 RPO 소스 리전보다 10 이상 늦게 실행될 있다. redo 볼륨이 높은 데이터베이스 인스턴스는 번째 리전의 인스턴스에 대해 가장 최근에 복원 가능한 시간에 추가 지연이 발생할 있다. PITR 완료하는 걸리는 시간은 스냅샷이 복원된 적용해야 하는 redo 로그 양에 따라 크게 달라지며, 이는 교차 리전 자동 백업의 결과로 변경할 없는 부분이다. 리전 또는 리전 RDS 인스턴스 복원 작업에 대해 낮은 RTO 달성하려는 경우 인스턴스의 수동 스냅샷을 생성하여 복원의 redo 로그 단계의 시간을 줄일 있다.

 

아래 표는 Oracle Amazon RDS 다양한 HA DR 기능으로 얻을 있는 RPO RTO 지표이다.

Feature RPO (근사치) RTO(근사치) Licensing
RDS Multi-AZ 0 1 to 2 minutes License Included Standard Edition Two (SE2) or BYOL SE2 or Enterprise Edition
Snapshot restore Hours < 1 hour
PITR(in-Region) using Automated Backups 5 minutes Hours
PITR using cross-Region Automated Backups 25 minutes Hours
Mounted replica promotion (in-Region) Minutes Minutes Enterprise Edition
Mounted replica promotion (cross-Region) Minutes Minutes
Read replica promotion (in-Region) Minutes Minutes Enterprise Edition + Active Data Guard
Read Replica promotion (cross-Region) Minutes Minutes

 

AWS KMS 또는 Oracle TDE(투명한 데이터 암호화) 암호화된 RDS DB 인스턴스는 다른 리전에도 복제할 있다. Oracle TDE TDE 옵션을 통해 사용 중인 경우 Amazon RDS TDE 키를 대상 지역에 자동으로 복사하므로 Oracle wallet 해당 지역에서 관리될 있다. AWS KMS 암호화를 지원하는 교차 리전 자동 백업은 대상 리전의 기존 AWS KMS 고객 마스터 (CMK) 사용하여 복제된 백업을 암호화 한다.

 

AWS KMS 암호화를 사용하여 보호되는 RDS 인스턴스에 대해 교차 리전 자동 백업을 구현할 대상 리전에서 암호화 작업에 사용할 KMS ARN 지정해야 한다. 이는 Amazon RDS 기본 KMS 키가 없지만 AWS KMS 기본 서비스 키에 대한 교차 리전 액세스를 허용하지 않기 때문에 별도의 키여야 한다.

 

교차 리전 자동 백업은 리전 간에 DB 스냅샷 아카이브된 redo 로그를 복사하는 동안 전송된 데이터에 대해 요금이 부과된다. 기본 리전과 보조 리전 간의 데이터 전송 요금은 해당 리전의 데이터 전송 요금을 기준으로 청구되며 스냅샷이 복사된 대상 리전에 저장소 요금은 표준 데이터베이스 스냅샷 요금이 적용된다. 대상 리전에 아카이브된 redo 로그를 저장 하는데는 추가 요금이 부과되지 않는다. 인스턴스, 스토리지, 데이터 전송 지역별 가용성에 대한 최신 요금은 Oracle Amazon RDS 요금을 참고한다.

l  Amazon RDS for Oracle pricing : https://aws.amazon.com/rds/oracle/pricing/

 

 

[참고자료]

l  Managed disaster recovery with Amazon RDS for Oracle cross-Region automated backups – Part 1 : https://aws.amazon.com/blogs/database/managed-disaster-recovery-with-amazon-rds-for-oracle-cross-region-automated-backups-part-1/

l  Amazon RDS for Oracle pricing : https://aws.amazon.com/rds/oracle/pricing/

 

 

 

2022-04-14 / Sungwook Kang / http://sungwookkang.com

 

 

AWS Oracle RDS, Automated Backup, Cross Region Backup, 교차 리전 자동 백업, DR, RTO, RPO

[AWS CloudWatch] CloudWatch 활용한 SQL Server RDS 데드락 모니터링

 

l  Version : AWS CloudWatch, RDS for SQL Server

 

SQL Server 운영할 , 여러 성능 지표 모니터링은 필수이다. 하나가 데드락 모니터링이다. AWS RDS for SQL Server 환경에서 데드락 발생시 CloudWatch 활용하면 특별한 서드파티 모니터링 도구가 없어도 발생 즉시 알림을 받을 있다.

 

이번 포스트는 AWS 공식 블로그 내용을 요약한 것으로 자세한 내용은 원문을 참고한다.

l  Monitor deadlocks in Amazon RDS for SQL Server and set notifications using Amazon CloudWatch : https://aws.amazon.com/blogs/database/monitor-deadlocks-in-amazon-rds-for-sql-server-and-set-notifications-using-amazon-cloudwatch/

 

데드락 발생시 아래와 같은 이벤트 로그를 확인할 있다. 로그는 온프레미스 SQL Server 또는 클라우드 환경에서의 SQL Server 모두 동일하다. 데드락이 발생하면 현재 실행중인 프로세스들은 모두 대기하게 되므로, SQL Server 현재 데드락에 관련된 프로세스 하나를 강제로 종료시켜 문제를 해결한다. 그리고 아래와 같은 오류 로그를 기록한다.

Msg 1205, Level 13, State 51, Line 3
Transaction (Process ID xx) was deadlocked on {xxx} resources with another process
and has been chosen as the deadlock victim. Rerun the transaction

 

AWS RDS 사용하면 데드락을 모니터링 하고 이벤트가 발생하는 즉시 Amazon SNS(Simple Notification Service) 알림을 보낼 있다. 이렇게 알림 시스템을 구성할 경우 데드락 발생에 대한 알림을 자동화하고 데드락 예방을 위한 조치를 취하는데 도움이 된다. 아래는 데드락 발생시 알림을 보내는 아키텍처이지만 데드락 뿐만 아니라 다양한 오류 로그 사용자 정의 이벤트를 모니터링 있다.

1.        SQL Server RDS 대한 데드락 모니터링 감지를 활성화

2.        SQL Server 오류 로그를 CloudWatch 게시

3.        교착 상태 이벤트를 시뮬레이션

4.        필터 패턴과 CloudWatch 경보를 생성

5.        Amazon RDS 성능 개선 도우미를 사용하여 솔루션을 모니터링

 

데드락 모니터링을 활성화 하기 위해서는 파라메터 그룹에서 데드락 이벤트인 1204, 1222 선택하고 값을 1 설정한다. 파라메터 그룹 수정 적용을 위해서는 RDS 인스턴스를 재시작 해야 한다.

 

CloudWatch 오류 로그를 모니터링 있도록 Log exports에서 Error log항목을 선택한다. 변경 사항을 적용하려면 RDS DB 인스턴스 재시작이 필요하다.

 

설정이 완료되고 나면 CloudWatch 콘솔에서 로그가 기록되는 것을 확인할 있다. 로그 그룹은 /aws/rds/instance/<Your-RDS-Instance-Name>/error 형식으로 그룹화 되어 있다.

 

Metric filter 탭에서 데드락에 대한 이벤트를 입력한다. 이때 통계에서 최소를 선택하고 0 보다 경우 알림이 발생하도록 설정한다. (데드락은 1건만 있어도 알림을 받아야 한다.)

 

알림이 발생했을 수신할 이메일을 입력하여 SNS 주제를 생성하고 나면 실제 데드락 발생시 메일로 해당 알림을 받을 있다.

 

 

이번 포스트에서는 CloudWatch 사용하여 SQL Server RDS에서 발생하는 데드락에 대해서만 모니터링 하였지만, 실제 SQL Server 오류 로그에는 매우 다양한 이벤트 로그가 기록된다. 데드락 외에도 운영에 필요한 로그를 모니터링 하여 알림을 받을 있도록 한다.

 

l  SQL Server DBA 체크리스트 : https://blog.naver.com/jevida/221018122813

 

 

[참고자료]

l  Monitor deadlocks in Amazon RDS for SQL Server and set notifications using Amazon CloudWatch : https://aws.amazon.com/blogs/database/monitor-deadlocks-in-amazon-rds-for-sql-server-and-set-notifications-using-amazon-cloudwatch/

 

 

 

2022-04-12 / Sungwook Kang / http://sungwookkang.com

 

 

AWS SQL RDS, CloudWatch, 오류로그, 이벤트 로그, 장애알림, DB 모니터링

[AWS Aurora] Babelfish 사용하여 MS SQL 쿼리를 변경 없이 PostgreSQL에서 사용하기

-          SSRS에서 Babelfish 사용하여 쿼리 수정없이 리포트 실행 가능

 

l  Version : AWS Aurora Babelfish

 

앞에서 다루었던 AWS SCT (Schema Conversion Tool) AWS DMS (Database Migration Service) 서비스를 사용하여 이기종 간의 데이터베이스 스키마 전환 실시간 데이터베이스 마이그레이션에 대해서 살펴 보았다.

l  [AWS SCT] AWS SCT 활용하여 이기종 데이터베이스 스키마 전환하기 : https://sungwookkang.com/1497

l  [AWS DMS] AWS DMS 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기 : https://sungwookkang.com/1496

 

이렇게 이기종 데이터베이스 마이그레이션 작업이 진행되면, 기존 데이터베이스를 사용하던 애플리케이션 또한 새로운 데이터베이스에 맞게 변경 작업이 필요하다. 그런데 기업 입장에서 보면 이러한 변경에 따른 개발 리소스 비용이 증가하게 되어 부담되는 것이 현실이다. 만약 기존에 사용중인 데이터베이스가 Microsoft SQL Server이며 마이그레이션된 데이터베이스가 Aurora PostgreSQL이라면, AWS Aurora에서 제공하는 Babelfish 사용하여 기존 SQL Server에서 사용하던 쿼리 그대로 PostgreSQL에서 사용할 있다. 이번 포스트에서는 AWS에서 제공하는 Babelfish 대해서 알아본다.

 

Babelfish for Aurora PostgreSQL Amazon Aurora PostgreSQL 호환 에디션의 새로운 기능으로, 이를 통해 Aurora Microsoft SQL Server용으로 작성된 애플리케이션의 명령을 이해할 있다. Aurora PostgreSQL Babelfish 통해 Microsoft SQL Server 전용 SQL 언어인 T-SQL 이해하고 동일한 통신 프로토콜을 지원한다. 따라서 원래 SQL Server용으로 작성된 앱을 최소한의 코드 변경으로 Aurora에서 사용할 있다. 결과적으로, SQL Server 2005 이상에서 실행되는 애플리케이션을 수정하고 Aurora 이동하는 필요한 작업이 줄어들기 때문에 마이그레이션 속도를 높이고 위험을 낮추며 비용 효율성을 개선할 있다.

 

Babelfish Amazon Aurora 기본 제공 기능으로, 추가 비용 없이 사용할 있으며, RDS 관리 콘솔에서 클릭 번으로 Amazon Aurora 클러스터에서 Babelfish 사용하도록 설정할 있다. 아래 그림은 Babelfish for Aurora PostgreSQL 마이그레이션 되었을 , 기존의 SQL Server에서 사용하던 애플리케이션과 Aurora PostgreSQL 사용하는 애플리케이션이 어떻게 연결되고 통신하는지에 대한 다이어그램이다. 그림을 살펴보면, SQL Server 드라이버를 사용하는 애플리케이션은 Babelfish 통하여 Aurora 접근하게 되고, PostgreSQL 드라이버를 사용하는 애플리케이션은 PostgreSQL 커넥션을 사용하여 Aurora 접근되는 것을 있다.

 

Babelfish Aurora PostgreSQL 대한 SQL Server 데이터 형식, 구문 함수를 지원하여 T-SQL Microsoft SQL Server 동작을 지원한다. 방법을 사용하면 Aurora Aurora PostgreSQL SQL Server SQL 언어를 모두 지원할 있다. 또한 Babelfish SQL Server 와이어 레벨 프로토콜(TDS) 지원하므로 SQL Server 애플리케이션이 Aurora PostgreSQL 기본적으로 통신할 있다. 이렇게 하면 데이터베이스 객체, 저장 프로시저 애플리케이션 코드를 거의 변경하지 않고 마이그레이션할 있다.

 

Babelfish T-SQL 완벽하게 지원하지는 않지만 Aurora PostgreSQL SQL 명령을 사용하여 이러한 명령에서 일반적으로 처리하는 많은 작업을 수행할 있다. 예를 들어 Babelfish에서 지원하지 않는 특정 T-SQL 명령을 정기적으로 사용이 필요할 경우 Aurora PostgreSQL 포트에 연결하고 PostgreSQL SQL 명령을 사용할 있다. Aurora PostgreSQL 일반적으로 사용되는 많은 SQL Server 기능을 대체하는 기능을 제공한다.

아래 표는 Aurora PostgreSQL에서 사용 가능한 PostgreSQL 기능으로 대체할 있는 SQL Server 기능의 가지 예시이다.

SQL Server 기능 비교 가능한 PostgreSQL 기능
SQL Server 대량 복사 PostgreSQL COPY 기능
SQL Server Group By (Babelfish에서는 지원되지 않음) PostgreSQL Group By
SQL Server JSON 지원 PostgreSQL JSON 함수 연산
SQL Server XML 지원 PostgreSQL XML 함수
SQL Server 전체 텍스트 검색 PostgreSQL 전체 텍스트 검색
SQL Server 지역 데이터 형식 PostGIS 확장 (지역 데이터 작업용)

 

Babelfish 아직은 완벽히 T-SQL 지원하는 것은 아니므로 일부 시스템 함수나 일부 SQL Server 고유 함수는 지원되지 않는다. T-SQL 제한 사항 지원되지 않는 기능에 대해서는 Babelfish 버전에 따라 변경될 있으므로 아래 공식 문서를 참고한다. (현재 글을 쓰는 시점에서는 Babelfish 1.0.0 1.1.0 버전이 있다.)

l  T-SQL 제한 사항 지원되지 않는 기능 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/babelfish-compatibility.html

l  Babelfish 버전 버전에 따른 명령어 지원 여부 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/babelfish-releases-updates.html

 

 

아래 링크는 Babelfish  사용한 Aurora PostgreSQL 클러스터를 생성하는 방법과, MS SQL 서버 기반 앱을 Babelfish 연결하여 MS SQL 쿼리를 실행하는 방법을 설명한다.

l  Babelfish for Aurora PostgreSQL 정식 출시 레거시 MS SQL 서버 기반 호환 기능 제공 : https://aws.amazon.com/ko/blogs/korea/goodbye-microsoft-sql-server-hello-babelfish/

 

아래 그림은 실제로 필자가 실습한 내용으로 MS SQL Server AdventureWorks2016 데이터베이스를 AWS DMS 사용하여 Babelfish for Aurora PostgreSQL 마이그레이션 SSRS(SQL Server Reporting Service)에서 SQL Native Client 드라이버를 사용하여 MS SQL 쿼리를 사용하여 리포트를 생성하여 실행한 화면이다. 정상적으로 쿼리가 동작하고 리포트가 생성되는 것을 확인할 있다.

 

이처럼 Babelfish 활용하면 기존의 SQL Server사용시 발생할 있는 라이선스 비용을 저렴한 Aurora PostgreSQL 전환하며, 기존 애플리케이션에 대한 코드 변경을 최소화하고, 빠르고 경제적으로 플랫폼 환경을 전환할 있다.

 

[참고자료]

l  [AWS SCT] AWS SCT 활용하여 이기종 데이터베이스 스키마 전환하기 : https://sungwookkang.com/1497

l  [AWS DMS] AWS DMS 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기 : https://sungwookkang.com/1496

l  T-SQL 제한 사항 지원되지 않는 기능 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/babelfish-compatibility.html

l  Babelfish 버전 버전에 따른 명령어 지원 여부 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/babelfish-releases-updates.html

l  Babelfish for Aurora PostgreSQL 정식 출시 레거시 MS SQL 서버 기반 호환 기능 제공 : https://aws.amazon.com/ko/blogs/korea/goodbye-microsoft-sql-server-hello-babelfish/

l  https://aws.amazon.com/rds/aurora/babelfish/?nc1=h_ls

 

 

 

2022-04-08 / Sungwook Kang / http://sungwookkang.com

 

 

AWS Babelfish, AWS SCT, Schema Migration, 스키마 변경, 스키마 마이그레이션, 스키마 추출, 스키마 변환, 이기종 쿼리 실행

[AWS SCT] AWS SCT 활용하여 이기종 데이터베이스 스키마 전환하기

-          툴을 활용하여 쉽고 빠르게 이기종 데이터베이스 호환 스키마를 만들기

 

l  Version : AWS SCT

 

이전 포스팅에 AWS DMS 서비스를 소개하면서 이기종 간의 데이터 마이그레이션에 대해서 알아 보았다. AWS DMS 이기종간의 데이터 마이그레이션 뿐만 아니라, 실시간 마이그레이션, 그리고 마이그레이션 진행과정에서 데이터 마스킹등 다양한 기술을 지원한다.

l  [AWS DMS] AWS DMS 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기 : https://sungwookkang.com/1496

 

그렇다면 이기종 간의 데이터 마이그레이션을 진행하기 위해서는 스미카 생성이 선행되어야 하는데, 이기종 간의 스키마 구조는 동일하게 하더라도, 데이터 타입은 벤더 마다 지원하는 부분이 조금씩 다르다. 그리고 모든 스키마를 손으로 한땀 한땀 수정하기에는 적은 수의 테이블이면 상관이 없지만, 많은 수의 컬럼을 가진 테이블이나, 테이블 개수가 많다면 수작업으로 하기에는 많은 불편함이 있을 것이다. 이처럼 벤더사에서 제공하는 데이터 타입에서 불일치에 대한 변환 작업과, 수동 작업으로 발생하는 여러가지 문제를 해결하기 위해서 AWS에서는 SCT라는 솔루션을 제공하고 있다. 이번 포스트에서는 AWS SCT에서 대해서 알아본다.

 

AWS SCT(Schema Conversion Tool) 기존 데이터베이스 스키마를 데이터베이스 엔진에서 다른 데이터베이스 엔진으로 변환할 있는 기능을 제공한다. 변환된 스키마는 Amazon RDS (아마존 관계형 데이터베이스 서비스) MySQL, MariaDB, 오라클, SQL 서버, PostgreSQL DB, Amazon Aurora DB 클러스터 또는 Amazon Redshift 클러스터에 적합하다. 변환된 스키마는 Amazon EC2 인스턴스에서 데이터베이스와 함께 사용하거나 Amazon S3 버킷에 데이터로 저장할 있다.

 

아래 표는 AWS SCT에서 변환을 지원하는 OLTP 목록이다. 간략히 정리한 것으로 자세한 내용은 공식 문서를 참고할 있도록 한다.

l  What is the AWS Schema Conversion Tool? : https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html

 

원본 데이터베이스 대상 데이터베이스
IBM DB2 LUW (9.1 이상) Aurora MySQL, Aurora PostgreSQL, MariaDB 10.5, MySQL, PostgreSQL
Microsoft Azure SQL Aurora MySQL, Aurora PostgreSQL, MySQL, PostgreSQL
Microsoft SQL Server (2008 이상) Aurora MySQL, Aurora PostgreSQL, Aurora PostgreSQL, Microsoft SQL Server, MySQL, PostgreSQL
MySQL (5.5이상) Aurora PostgreSQL, MySQL, PostgreSQL
Oracle (10.2 이상) Aurora MySQL, Aurora PostgreSQL, MariaDB 10.5, MySQL, Oracle, PostgreSQL
PostgreSQL(9.1 이상) Aurora MySQL, Aurora PostgreSQL, MySQL, PostgreSQL
SAP ASE (12.5 이상) Aurora MySQL, Aurora PostgreSQL, MariaDB 10.5, MySQL, PostgreSQL

 

아래 표는 AWS SCT에서 변환을 지원하는 DW목록이다.

소스 데이터 웨어하우스 대상 데이터 웨어하우스
Amazon Redshift Amazon Redshift
Azure 시냅스 분석(10 이상)
Greenplum Database (4.3 이상)
Microsoft SQL Server (2008 이상)
Netezza (7.0.3 이상)
Oracle (10.2 이상)
Teradata (13 이상)
Vertica (7.2 이상)
스노우플레이크 (3이상)

 

AWS SCT툴은 설치형 프로그램으로 UI 인터페이스를 제공하므로 쉽게 설치 작동을 있다. 설치 가능한 운영체제로는 페도라 리눅스, 마이크로소프트 윈도우, 우분투 리눅스 15.04에서 사용할 있으며, 64비트 운영체제에서 실행 가능하다. 다운로드 설치 방법에 관해서는 아래 링크를 참고한다.  (설치 과정에 대한 부분을 포스팅에 다루지 않는 이유는 설치 과정 UI 언제든지 변경 가능성이 있기 때문에 최대한 공식 문서로 안내하고자 한다.)

l  Installing, verifying, and updating AWS SCT : https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Installing.html

 

아래 그림은 AWS SCT 프로그램 화면에 대한 소개로 자세한 내용은 공식 문서를 참고할 있도록 한다.

 

1.       왼쪽 패널에서 원본 데이터베이스의 스키마가 트리 뷰에 표시되며 항목을 선택하면AWS SCT소스 데이터베이스에서 현재 스키마를 가져오고 표시한다.

2.       상단 가운데 패널에는 대상 데이터베이스 엔진으로 자동으로 변환할 없는 소스 데이터베이스 엔진의 스키마 요소에 대한 작업 항목이 나타난다.

3.       오른쪽 패널에는 대상 DB 인스턴스의 스키마가 트리 보기로 표시되며 트리 뷰에서 항목을 선택할 AWS SCT대상 데이터베이스에서 현재 스키마를 가져오고 표시한다.

4.       왼쪽 하단 패널에서 스키마 요소를 선택하면 등록 정보가 표시된다. 소스 스키마 요소와 소스 데이터베이스에 해당 요소를 만들기 위한 정보를 나타낸다.

5.       오른쪽 하단 패널에서 스키마 요소를 선택하면 등록 정보가 표시된다. 대상 스키마 요소와 대상 데이터베이스에 해당 요소를 만들기 위한 SQL 명령을 나타낸다. SQL 명령을 편집하고 업데이트된 명령을 프로젝트와 함께 저장할 있다.

 

스키마 변환을 완료하면 오른쪽 패널에 제안된 스키마를 있으며 아직까지는 대상 데이터베이스에 스키마가 적용되지 않은 상태이다. 상태에서 스키마를 편집할 있으며 편집된 스키마는 프로젝트 일부로 저장되며 스키마 적용을 하면 대상 데이터베이스에 스키마가 적용된다.

 

변환된 데이터베이스 스키마를 대상 데이터베이스에 적용하려면 아래 그림처럼 [Apply to database] 실행하면 된다.

 

 

AWS SCT 사용할 경우 함수, 매개변수, 로컬 변수 일부 항목은 변환이 지원되지 않으므로 해당 내용은 자세히 확인 추가 작업을 진행할 있도록 한다.

 

Aws SCT 설치형 독립 프로그램이므로 가지 옵션을 조정하여 툴에 대한 성능 조정을 진행할 있다. 예를 들면 툴에서 사용할 메모리의 양을 늘려 성능을 빠르게 수도 있다. 다만 경우 데스크톱의 메모리를 많이 사용하기 때문에 실행되는 컴퓨터 리소스를 확인하여 적절하게 조절하여 사용할 있도록 한다.

AWS SCT에서 사용될 메모리 크기를 조절하는 방법은 AWS Schema Conversion Tool.cfg 파일의 내용을 수정하여 사용한다.

C:\Program Files\AWS Schema Conversion Tool\App\ AWS Schema Conversion Tool.cfg

 

JavaOption항목에서 최소 최대 메모리를 설정한다. 아래 예제는 최소 4GB, 최대 40GB 메모리를 사용하도록 설정한다.

[JavaOptions]
-Xmx48960M
-Xms4096M

 

메모리 설정 외에도 로깅 정보를 상세히 기록할 있다. 다만 경우 로깅 정보가 증가하면서 변환 속도가 약간 느려질 수도 있다. 로깅 설정을 변경하려면 아래와 같은 순서로 진행한다.

1.       setting메뉴에서 Global setting 선택

2.       Global setting 창에서 Logging 선택

3.       Debug 모드에서 True 선택

4.       주요 항목을 선택하여 로깅 정보를 선택한다. 예를 들면 변환 주요 문제에 대한 정보를 기록하기 위해 파서, 매핑 형식, 사용자 인터페이스 추적 등을 로깅할 있다.

 

[참고자료]

l  [AWS DMS] AWS DMS 활용하여 데이터 마이그레이션 과정에서 데이터 마스킹 하기 : https://sungwookkang.com/1496

l  What is the AWS Schema Conversion Tool? : https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html

l  Installing, verifying, and updating AWS SCT : https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Installing.html

l  Best practices for the AWS SCT :  https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_BestPractices.html

 

 

 

2022-04-07 / Sungwook Kang / http://sungwookkang.com

 

 

AWS DMS, AWS SCT, Schema Migration, 스키마 변경, 스키마 마이그레이션, 스키마 추출, 스키마 변환

 

+ Recent posts