AWS Hands-on Lab #8 DB 마이그레이션입니다. 그런데 이제 SCT를 곁들인
Witten by Minhyeok Cha
이기종 DB 마이그레이션 해야 하는 이유로는 벤더 종속 기간, 라이선스 감사, 값비싼 라이선스 및 비용 등이 있습니다. 특히 오라클의 정가는 코어당 모델을 기준으로 하며 파티셔닝 및 고가용성 같은 기능에 대한 추가 비용이 부과됩니다.
이러한 이유로 많은 조직에서 AWS로 마이그레이션 할 때 오라클 데이터베이스를 오픈 소스 데이터베이스 (예: PostgreSQL, MySQL 또는 MariaDB) 또는 AWS 클라우드 네이티브 데이터베이스 (예: Amazon Aurora 또는 Amazon DynamoDB) 로 마이그레이션을 선택합니다.
AWS에는 데이터베이스 마이그레이션을 도와주는 서비스인 AWS DMS(Database Migration Service)가 있으며 이기종 데이터베이스 스키마 변환 툴인 SCT(Schema Conversion Tool)가 있습니다.
AWS를 사용한 이기종 데이터베이스 마이그레이션
마이그레이션에서 소스 데이터베이스 엔진과 대상 데이터베이스 엔진이 서로 다른 경우 데이터베이스의 스키마 구조, 데이터 유형 및 데이터베이스 코드가 다를 수 있기 때문에 마이그레이션 진행 단계 전에 스키마 및 코드 변환이 필요합니다.
따라서 SCT를 사용하여 소스 데이터베이스의 스키마와 코드를 대상 데이터베이스와 일치하도록 전환 후 DMS를 통해 마이그레이션을 진행합니다.
SCT 및 DMS 진행 과정
온프레미스에서 클라우드로의 마이그레이션을 동시에 진행할 경우 위와 같이 진행하는 것이 맞습니다.
그러나 본 글은 이기종 데이터베이스 마이그레이션이기 때문에 AWS 안에서 전부 해결해 보도록 하겠습니다.
진행은 다음과 같습니다.
원격으로 서버에 접근하여 SCT설치 - 시작
소스/타겟의 DB를 선택 후 연결 대상의 DB 설정
평가를 진행 후 스키마 마이그레이션을 진행 및 애플리케이션 소스 코드 마이그레이션
💡 SCT는 윈도우 상에서만 호환되기 때문에 EC2에 원격 접속하여 테스트를 진행
1. SCT 설치 이후 세팅
1. SCT 설치 링크
AWS SCT docs 링크를 통해 SCT를 설치합니다.
2. 소스 DB 선택
이번 글에서는 오라클 → PostgreSQL로 전환할 예정이기 때문에 소스 DB를 Oracle로 설정합니다.
3. 스키마 선택
💡 샘플 데이터가 없어서 회사 DB를 뽑아서 사용했습니다. 사진은 예시 사진으로 대체함
스키마를 선택하여 다음으로 넘어가면 각 DB 엔진과 컨버전하면서 호환성을 한눈에 파악할 수 있습니다.
4. 타겟 DB 선택
AWS 콘솔에 미리 만들어 둔 타겟 DB에 대한 정보를 기입하고 다음으로 넘어갑니다.
5. 스키마 변환
AWS SCT에서 소스 및 대상 데이터베이스에 액세스할 수 있으므로 대상 데이터베이스와 호환되는 스키마 변환을 시작하겠습니다.
SQL 프로시저 및 애플리케이션 코드 변환
간단한 데이터를 마이그레이션 했기 때문에 아무런 이슈 사항이 나오지 않습니다.
예시로 다음 이슈 사진을 보면 초록색 느낌표가 있는 것을 확인할 수 있습니다.
이때 이슈 앞에 있는 느낌표의 색마다 경고하는 바가 다릅니다. 초록색은 큰 신경을 쓰지 않아도 되지만, 파란색 느낌표가 떠 있다면 다시 한번 확인하여 쿼리문 혹은 코드를 수정할 필요가 있습니다.
💡 해당 사진은 테스트용 덤프 데이터이며 이슈 확인용입니다.
SQL 문 수정 후 스키마 변환을 스키마 컨버터 이후 타겟 데이터베이스에 스키마를 적용하면 Oracle에서 Aurora PostgreSQL로 변환했습니다.
2. DMS를 사용한 데이터베이스 마이그레이션
AWS DMS는 기본적으로 소스와 타겟 데이터베이스의 엔드포인트를 만들어 그사이에 복제본 인스턴스를 하나 생성합니다.
마이그레이션은 복제 인스턴스에서 원본 데이터를 읽고 타겟 데이터 스토어에 소모할 수 있도록 데이터 형식을 지정합니다. 복제 인스턴스는 데이터를 타겟 데이터 스토어에 로드하며 이 절차는 대부분 메모리를 사용합니다. 그렇지만 일부 트랜잭션은 디스크에서 버퍼링이 필요할 수 있습니다.
캐시 된 트랜잭션과 로그 파일도 디스크에 기록됩니다.
1. 복제 인스턴스 생성
복제 인스턴스를 사용하면 이중화를 통해 함께 고가용성 및 장애 조치 지원을 받을 수 있습니다. 그렇지만 이번 글에서는 단일 AZ로 사용하도록 하겠습니다.
2. 각 엔드포인트 생성
💡 사진과 같이 하나의 엔드포인트 생성란에 소스와 타겟이 있기 때문에 각각 하나씩 개별로 생성해야 합니다.
3. 마이그레이션 작업 생성 및 결과
마이그레이션이 완료되었다면 각 DB에 들어가 테이블을 확인합니다.
각 Oracle과 PostgreSQL의 같은 테이블 조회 값입니다.
💡 기존 Oracle에 미리 넣어둔 데이터가 잘 넘어간 것을 확인!
마무리
AWS SCT(Schema Conversion Tool) 및 AWS DMS(Database Migration Service)를 사용하면 이기종 엔진 간에 DB 마이그레이션을 쉽게 할 수 있었습니다.
사실 간단한 데이터 셋이라 이전에 큰 문제는 없었지만, 실무로 사용 중인 복잡한 DB 구조가 붙으면 SCT가 어떻게 보일지조차 어지럽긴 합니다.
본 글에서는 간단한 덤프 데이터로 진행을 해서 상관없었지만, 실무로 사용되는 prod 데이터 셋이라면 DMS 레플리카 인스턴스 사양을 높여야 좋을 것 같습니다. 하단에 보이는 데이터 뿐만 아니라 덤프 데이터도 마이그레이션 해버릴 때 사양이 낮으니 마이그레이션 진행률이 너무 느려서 죽을 뻔했습니다. (실수로 스키마 테이블 전체로 할당해 버렸는데 알아챈 사실…)
Comments