Amazon Web Services 한국 블로그

MS SQL서버에서 AWS기반 MySQL 호환 DB 엔진으로 이전하기

이 게시물은 Microsoft SQL Server 데이터베이스를 Amazon RDS for MySQL, Amazon RDS for MariaDB 또는 Amazon Aurora MySQL 등 MySQL 호환 데이터베이스 엔진으로 마이그레이션할 수 있는 방법에 대한 개요를 제공합니다.

다음은 데이터베이스 마이그레이션의 두 가지 주요 부분입니다.

  1. 스키마 변환: 스키마 객체 변환은 일반적으로 다른 유형의 데이터베이스 마이그레이션에서 시간이 많이 소요되는 작업입니다. 이러한 변환은 데이터베이스의 토대이며, 잘 계획된 방식으로 처리해야 합니다. 스키마 변환이 적절하게 수행된 경우 다른 유형의 마이그레이션에 대한 중요한 마일스톤이 완료됩니다.
  2. 데이터 마이그레이션: 기본 데이터 요소는 앞에서 언급한 스키마 토대에 대한 빌딩 블록과 같습니다. 토대가 적절하게 배치될 경우 모범 사례를 따를 때 마이그레이션 중 이러한 블록의 배열이 비교적 간단합니다.

이 게시물에서는 SQL Server 데이터베이스를 Aurora MySQL, MySQL, MariaDB 등 자주 사용되는 MySQL 기반 데이터베이스 엔진으로 변환하기 위해 AWS SCT(AWS Schema Conversion Tool) 및 AWS DMS(AWS Database Migration Service)를 사용하는 방법을 살펴봅니다. 이 게시물에서 이러한 모든 데이터베이스 엔진을 MySQL이라고 합니다.

SQL Server 데이터베이스를 MySQL 호환 데이터베이스로 마이그레이션에서는 SQL Server와 MySQL 간의 데이터베이스 객체 시맨틱이 유사합니다. 하지만 SQL Server에서 MySQL로 마이그레이션할 때 고려해야 할 중요한 아키텍처 차이점이 있습니다. 예를 들어, MySQL에서는 “데이터베이스” 및 “스키마”가 모두 동일한 의미를 공유합니다. 데이터베이스와 스키마 간에 기능적 차이점이 없습니다. 다음 예는 이러한 점을 보여 줍니다.

SQL 
mysql> create schema test01;
Query OK, 1 row affected (0.01 sec)

mysql> create database test01;
ERROR 1007 (HY000): Can't create database 'test01'; database exists

예제에 표시된 대로 “데이터베이스” 및 “스키마”는 동일하며 별도의 의미가 없습니다. 데이터베이스 내의 테이블을 가리킬 경우 MySQL의 전체 테이블 식별자는 databasename.tablename과 같습니다.

반면에 SQL Server는 “데이터베이스” 및 “스키마” 키워드에 다른 의미와 기능을 부여합니다. SQL Server에서 데이터베이스는 모든 객체, 데이터 및 로그 파일을 저장하는 기본 컨테이너입니다. 스키마는 다른 데이터베이스 객체를 논리적으로 그룹화하는 특정 데이터베이스 내에 있는 객체입니다. SQL Server는 기본적으로 스키마 이름 dbo를 사용합니다. 그러나 조직, 기능 또는 비즈니스 요구 사항을 충족하기 위해 이러한 사항을 변경할 수 있습니다. SQL Server의 전체 테이블 식별자는 Databasename.Schemaname.tablename입니다.

 

마이그레이션 시나리오
SQL Server 데이터베이스 및 스키마를 MySQL 호환 데이터베이스로 마이그레이션할 경우 4개의 다른 시나리오가 있을 수 있습니다. 애플리케이션 및 데이터베이스 요구 사항에 따라 이러한 시나리오 중 하나(또는 조합)를 따를 수 있습니다.

시나리오 1: 기본 dbo 스키마 이름
SQL Server의 기본 스키마가 dbo인 경우, MySQL 데이터베이스로 마이그레이션하는 동안 dbo 스키마를 사용하지 않도록 선택하면 됩니다. SQL Server 데이터베이스 이름이 MySQL 데이터베이스 이름으로 변환됩니다. 예:

SQL Server: Db1.dbo.table1

MySQL: Db1.table1

(MySQL에서 데이터베이스 변환 중 dbo가 쉽게 삭제 가능)

전체 테이블 식별자 계층 구조 변경 사항을 반영하기 위해 애플리케이션 코드도 이에 따라 변경해야 합니다.

시나리오 2: 사용자 지정 스키마 이름
사용자 지정 스키마 이름이 있는 경우 데이터베이스 이름만 또는 스키마 이름만 MySQL 데이터베이스 이름으로 변환해야 하는지 여부를 결정해야 합니다. 예:

Db1.schema1.table1
db2.schema2.table2

데이터베이스 또는 스키마를 MySQL 데이터베이스로 변환할 때 애플리케이션 코드에 따라 스키마 또는 데이터베이스 이름이 계속 생략될 수 있습니다. 이 경우에는 다음과 같은 이름이 됩니다.

Db1.table1
Db1.table2

또는

Schema1.table1
Schema2.table1

시나리오 3: 다른 스키마에서 동일한 테이블 이름
이 시나리오에서는 동일한 테이블 이름이 동일한 데이터베이스의 다른 스키마에 있습니다.

Db1.schema1.table1
Db1.schema2.table1

이 경우, 데이터베이스 이름을 생략하고 MySQL 측에서 스키마 이름을 데이터베이스 이름으로 대신 사용합니다. 이렇게 하면 동일한 데이터베이스에서 동일한 테이블 이름의 혼동이 방지됩니다.

MySQL:

Db1.table1
Db2.table1

시나리오 4: 데이터베이스와 스키마 이름 조인
이 시나리오에서는 SQL Server의 데이터베이스 이름과 스키마 이름이 모두 조인되어 MySQL 측에서 데이터베이스를 생성할 수 있습니다. AWS SCT는 이 경로를 따릅니다. 예:

SQL Server: db1.schema1.table1

MySQL: db1_schema1.table1

여기에서, 데이터베이스 및 스키마 이름이 모두 밑줄로 조인되어 대상에 MySQL 데이터베이스를 생성합니다.

전체 마이그레이션 전략
한 엔진에서 다른 엔진으로 데이터베이스를 마이그레이션할 경우(여기에서는 SQL Server에서 MySQL 호환 엔진으로 마이그레이션), 다음 단계가 권장됩니다.

  1. 대상 데이터베이스에서 스키마를 생성합니다.
  2. 대상 데이터베이스에 보조 인덱스를 삭제하고 트리거를 비활성화합니다. AWS DMS는 전체 로드 단계 중 테이블별 로드를 수행하며, 이렇게 하려면 외래 키를 비활성화하는 것이 중요합니다. 이렇게 하려면 이 게시물의 후반부에 언급된 대상 엔드포인트 추가 연결 속성을 사용합니다.
  3. AWS DMS 작업을 설정하여 데이터를 복제(전체 로드 및 CDC(데이터 캡처 변경))합니다.
  4. 캐시된 변경 사항을 적용하기 전에 중지할 작업을 구성하고 대상 데이터베이스에 보조 인덱스를 추가합니다.
  5. CDC에 대한 AWS DMS 작업을 다시 시작합니다.
  6. 전환 후 트리거를 활성화합니다.

대상 MySQL 데이터베이스에 스키마 생성
스키마 객체를 분석하여 마이그레이션을 시작할 수 있습니다. 여기에서는 AWS SCT(AWS Schema Conversion Tool)를 사용하여 분석을 수행합니다. AWS SCT를 시작할 때 원본이 SQL Server이고 대상이 MySQL/Aurora인 새 프로젝트를 생성합니다. 연결되면 왼쪽에서 마이그레이션할 데이터베이스의 이름을 선택합니다. 데이터베이스 이름에 대한 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열고 [Convert Schema]를 선택합니다. 그런 다음 [View], [Assessment Report View]를 선택합니다.

AWS SCT 평가 보고서는 스키마 변환에 대한 높은 수준의 개요와 권장 사항을 제공합니다. 초기 평가 보고서에 따라 SQL Server 데이터베이스를 MySQL/Aurora로 변환하는 데에는 더 많은 노력이 필요할 수 있습니다. 다음은 평가 보고서에 대한 예시입니다.

보고서는 각 객체 유형별로 구분되며, 성공적으로 변환하기 위해 수동 작업 노력이 필요합니다. 일반적으로 패키지, 절차 및 기능에는 해결해야 할 몇 가지 문제가 있습니다. AWS SCT는 이러한 객체를 수정해야 하는 이유도 알려주며, 이를 수행하는 방법에 대한 힌트도 제공합니다.

스키마가 자동으로 변환되지 않는 경우, 여기 문제를 해결할 유용한 몇 가지 힌트가 있습니다.

  1. 스키마를 있는 그대로 변환하고 대상 MySQL 데이터베이스에 적용하기 전에 AWS SCT에서 생성된 스크립트를 수동으로 수정합니다.
  2. 변환할 수 없는 객체를 무시하고, 기능을 다른 AWS 제품 또는 애플리케이션 자체와 대체합니다. 예를 들어, Aurora MySQL에서 AWS Lambda 함수를 호출하여 알림 전송 등의 특정 기능을 수행할 수 있습니다.

대상 데이터베이스의 스키마를 검색하고 열 데이터 유형, 객체 이름 등의 모든 스키마 객체를 빠르게 확인하는 것이 좋습니다. 데이터 유형에 대한 자세한 내용은 원본 및 대상 데이터 유형에 대한 AWS Database Migration Service 설명서를 참조하십시오. 또한 SQL Server에서 MySQL로 변환되기 때문에, SQL Server는 기본 데이터 정렬에서 대문자를 지원하는 반면, MySQL은 기본적으로 소문자를 지원하므로 SQL Server에서 객체 이름은 대문자입니다.

이전 변환 실행에서 AWS SCT는 시나리오 4에 언급된 데이터베이스/스키마 이름 지정 규칙을 따릅니다. 원본 SQL Server 데이터베이스 및 스키마 이름에서 대상 MySQL 데이터베이스의 결합된 데이터베이스 및 스키마 이름으로 변환합니다. 이 dms_sample 데이터베이스 및 dbo 스키마는 대상의 dms_sample_dbo 데이터베이스로 변환됩니다.

데이터를 마이그레이션하도록 AWS DMS 작업 설정
이제 대상에 스키마가 준비되었으므로 AWS DMS를 사용하여 데이터를 마이그레이션할 준비가 되었습니다. 전체 로드 및 CDC에 AWS DMS를 사용하려면 다음 준비 작업을 완료했는지 확인하십시오.

  • SQL Server 및 MySQL에 대한 로그인에 문서화된 필수 권한이 있습니다.
  • CDC(변경 데이터 캡처)를 위해 SQL Server 복구 모델이 [Bulk logged] 또는 [Full]로 설정됩니다.
  • 추가적인 준비 정보는 AWS DMS의 SQL Server를 원본으로 사용에 대한 AWS DMS 설명서를 참조하십시오.

복제 인스턴스 생성
AWS 콘솔에서 AWS Database Migration Service를 엽니다. 먼저 복제 인스턴스를 생성해야 합니다. 복제 인스턴스는 AWS DMS 작업을 실행합니다. 이 인스턴스는 원본 SQL Server 데이터베이스와 대상 MySQL/Aurora 데이터베이스에 모두 연결되는 중간 서버입니다. 적절하게 프로비저닝된 복제 인스턴스를 선택하십시오(백서 AWS Database Migration Service 모범 사례에 언급된 모범 사례를 따름).

다음으로 원본 데이터베이스에 대한 엔드포인트와 대상 데이터베이스에 대한 다른 엔드포인트를 생성합니다. SQL Server 데이터베이스 및 MySQL 데이터베이스에 대한 모든 적절한 연결 정보를 입력합니다. MySQL 대상 엔드포인트에 다음 추가 연결 속성을 추가하여 외래 키 점검을 비활성화합니다.

SQL 
initstmt=SET FOREIGN_KEY_CHECKS=0

연결 테스트를 성공한 후 [Refresh schemas] 옵션을 선택하고, 각 엔드포인트 생성을 완료하기 전에 [Run test]를 선택해야 합니다.

SQL Server 엔드포인트를 생성하는 동안 데이터베이스 이름을 제공해야 합니다. 한 번에 데이터베이스 하나를 제공할 수 있으므로 엔드포인트는 데이터베이스 하나에만 연결할 수 있습니다. 즉, 작업마다 데이터베이스 하나를 마이그레이션할 수 있습니다. 여러 데이터베이스를 마이그레이션하려면 여러 AWS DMS 작업을 생성하고 모든 모범 사례를 따라 리소스 제약 문제가 발생하지 않도록 해야 합니다. 모든 AWS DMS 작업 생성은 AWS CLI를 통해 또는 AWS CloudFormation 템플릿을 사용하여 스크립팅 및 자동화할 수도 있습니다.

작업 구성
이제 작업을 생성할 준비가 되었습니다. 작업 이름을 입력하고, 생성한 복제 인스턴스를 선택하고, 원본 및 대상 엔드포인트를 선택합니다. [Migration type]에서는 [Migrate existing data and replicate ongoing changes]를 사용합니다. AWS SCT를 사용하여 스키마를 미리 생성하므로 [Target table preparation mode]에 대해 [Do nothing] 또는 [Truncate]를 선택합니다.

[Stop task after full load completes] 옵션에 대해 [Stop After Applying Cached Changes]를 선택합니다. 이렇게 하면 전체 로드가 완료되고 캐시된 변경 사항이 적용된 후 작업이 일시 중지됩니다. 캐시된 변경 사항은 전체 테이블 로드 프로세스가 실행되는 동안 발생하고 누적된 변경 사항입니다. 이는 CDC가 적용되기 바로 전의 단계입니다.

마지막으로, 작업에서 발생하는 오류나 경고를 확인하고 이러한 문제를 해결할 수 있도록 [Enable logging]을 선택하는 것이 좋습니다.

그런 다음 [Table mappings] 아래에서 마이그레이션할 스키마를 선택하고 [Add selection rule]을 선택합니다. [JSON] 탭을 선택합니다. [Enable JSON editing]을 선택하고 필수 JSON 문자열을 입력하여 테이블을 마이그레이션합니다. 다음은 그 예입니다.

Json 
JSON String: 
{
    "rules": [
        {
            "rule-type": "selection",
            "rule-id": "1",
            "rule-name": "1",
            "object-locator": {
                "schema-name": "dbo",
                "table-name": "person"
            },
            "rule-action": "include"
        },
        {a
            "rule-type": "selection",
            "rule-id": "2",
            "rule-name": "2",
                "object-locator": {
                "schema-name": "dbo",
                "table-name": "seat"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "selection",
            "rule-id": "3",
            "rule-name": "3",
            "object-locator": {
                "schema-name": "dbo",
                "table-name": "player"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "selection",
            "rule-id": "4",
            "rule-name": "4",
            "object-locator": {
                "schema-name": "dbo",
                "table-name": "seat_type"
            },
            "rule-action": "include"
        },
        {
            "rule-type": "transformation",
            "rule-id": "5",
            "rule-name": "5",
            "rule-target": "schema",
            "object-locator": {
                "schema-name": "dbo"
            },
            "rule-action": "rename",
            "value": "mysqldb"
        },
        {
            "rule-type": "transformation",
            "rule-id": "6",
            "rule-name": "6",
            "rule-target": "schema",
            "object-locator": {
                "schema-name": "%"
            },
            "rule-action": "convert-lowercase"
        },
        {
            "rule-type": "transformation",
            "rule-id": "7",
            "rule-name": "7",
            "rule-target": "table",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%"
            },
                "rule-action": "convert-lowercase"
        },
        {
            "rule-type": "transformation",
            "rule-id": "8",
            "rule-name": "8",
            "rule-target": "column",
            "object-locator": {
                "schema-name": "%",
                "table-name": "%",
                "column-name": "%"
            },
            "rule-action": "convert-lowercase"
        }
    ]
}

이전 JSON 문자열에서 테이블 이름에 대해 “%“를 선택하여 스키마 내에 있는 모든 테이블을 복사하도록 선택할 수 있습니다. 여기에서는 네 가지 특정 예제 테이블( person, player, seat및 seat_type)을 선택합니다. 또한 다음을 수행하기 위해 개별 변환 규칙 4개를 생성했습니다.

  1. SQL Server 대문자 스키마 이름을 대상에서 소문자 스키마 이름으로 변환합니다.
  2. SQL Server 대문자 테이블 이름을 대상에서 소문자 테이블 이름으로 변환합니다.
  3. SQL Server 대문자 열 이름을 대상에서 소문자 열 이름으로 변환합니다.
  4. 대상에서 dbo 스키마를 생성/복사하는 대신 기존 mysqldb 데이터베이스에 생성/복사합니다.

AWS DMS는 SQL Server 데이터베이스를 MySQL로 마이그레이션하는 동안 적용될 수 있는 여러 추가 변환 규칙을 제공합니다. 자세한 내용은 AWS DMS 설명서의 변환 규칙 및 작업을 참조하십시오.

JSON 문자열을 복사한 후 [Guided] 탭을 선택합니다. 이 탭에서는 선택과 변환 규칙 모두에 대해 모든 스키마가 자동으로 채워짐을 확인할 수 있습니다.

생성 시 [Start task on create] 옵션을 선택한 경우 작업을 생성하면 해당 작업이 자동으로 시작됩니다. AWS DMS 콘솔을 통해 작업을 선택하고 [Table statistics] 탭을 선택하여 진행률을 모니터링할 수 있습니다. 전체 로드가 완료되고 캐시된 변경 사항이 적용되면 작업 자체가 중지됩니다.

전체 로드가 완료되고 캐시된 변경 사항이 적용된 후 계속 진행하여 외래 키 및 보조 인덱스를 다시 생성합니다.

통계는 복사된 테이블과 오류를 수신한 테이블에 대한 높은 수준의 정보를 제공합니다. 그러나 로고를 검토하여 변환 및 마이그레이션 중 객체와 관련된 오류나 데이터 잘림 및 데이터 자체에 대한 경고가 없는지 확인해야 합니다.

연속 복제를 위한 DMS 작업 활성화
이제 외래 키와 보조 인덱스가 있으므로 AWS DMS 작업을 활성화하여 다음 단계인 CDC를 시작할 수 있습니다. 이 단계에서는 원본 데이터베이스에서 발생한 순서대로 변경 사항을 적용합니다. AWS DMS 콘솔로 이동하여 [Tasks]를 선택합니다. 목록에서 작업을 선택하고 [Start/Resume]을 선택합니다. [Start] 옵션을 선택한 다음 [Start task]를 선택합니다.

전환할 때까지 복제를 실행합니다. 전환 중 애플리케이션이 원본 데이터베이스에 액세스하는 것을 중지했는지 AWS DMS가 마지막 데이터 변경 사항을 대상 데이터베이스에 복제했는지 확인합니다. AWS DMS 콘솔에서 AWS DMS 작업을 중지하고 대상 데이터베이스에서 트리거를 활성화합니다. 마지막으로, 새 대상에 애플리케이션을 가리킵니다.

유용한 힌트

  1. 스키마를 쉽게 변환하려면 AWS SCT를 사용하여 평가 보고서를 받고 작업 항목을 통해 반복합니다. 대상 MySQL 스키마의 최종 버전을 얻을 때까지 대상 스키마를 여러 번 생성해야 할 수 있습니다.
  2. 새 플랫폼에 애플리케이션 쿼리가 작동하도록 하려면 대상 시스템에서 애플리케이션을 테스트하십시오. AWS SCT는 애플리케이션 쿼리를 MySQL로 변환할 수도 있습니다. 자세한 내용은 AWS SCT 설명서를 확인하십시오. 애플리케이션을 테스트하는 것은 다른 유형의 마이그레이션 성공을 위한 핵심입니다.
  3. 이전 마이그레이션 단계를 테스트하고 온프레미스 환경 및 비즈니스 요구 사항에 따라 프로세스를 간소화합니다. 이러한 단계는 시작점일 뿐이며, 각 데이터베이스는 자체적으로 고유해야 합니다.

결론
이 게시물은 특정 상황에 필요할 수 있는 가능한 모든 단계 또는 고려 사항을 설명하지 않습니다. 그러나 AWS SCT 및 AWS DMS를 사용하여 SQL Server 데이터베이스에서 MySQL 호환 데이터베이스 엔진으로 이동하는 방법을 이해할 수 있습니다. AWS Database Migration Service 및 AWS Schema Conversion Tool에 대한 자세한 내용은 AWS DMS 사용 설명서 및 AWS SCT 사용 설명서를 참조하십시오.

작성자 소개

Akm Raziul Islam은 Amazon Web Services에서 데이터베이스 및 분석에 집중하는 컨설턴트입니다. 고객과 협업하여 다양한 데이터베이스 및 분석 프로젝트에 대한 기술적 지원과 지침을 제공하며, AWS를 사용할 때 솔루션의 값을 향상하도록 지원합니다.

Arun Thiagarajan은 Amazon Web Services에서 DMS(Database Migration Service) 및 SCT(Schema Conversion Tool) 팀의 데이터베이스 엔지니어입니다. DB 마이그레이션 관련 문제점을 해결하고, 고객과 밀접하게 협업하여 DMS 제품의 진정한 잠재력을 이해하도록 지원합니다. DMS 및 SCT를 사용하여 AWS 클라우드로 100개의 데이터베이스를 마이그레이션하는 데 도움을 주었습니다.

이 글은 AWS Database Blog의 Migrating a SQL Server Database to a MySQL-Compatible Database Engine의 한국어 번역입니다.