Category: AWS Database Migration Service


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 ServerMySQL에 대한 로그인에 문서화된 필수 권한이 있습니다.
  • 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, seatseat_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의 한국어 번역입니다.

MySQL에서 다운타임 거의 없이 DynamoDB로 마이그레이션하기

많은 고객들이 MySQL 과 같은 관계형 데이터베이스에서 Amazon DynamoDB으로 마이그레이션 하고자 합니다. 왜냐하면, 완전 관리형, 고성능, 높은 확장성과 유연성을 갖춘 NoSQL 데이터베이스 서비스이기 때문입니다.  DynamoDB의 경우, 트래픽 및 비즈니스 요구 사항에 따라 용량을 유연하게 증가 및 감소시킬 수 있기 때문에 서비스에 필요한 총 비용을 기존의 서버 기반의 RDBMS보다 더 쉽게 최적화 하는 것이 가능합니다.

하지만, 마이그레이션 작업은 통상적으로 다음과 같은 두 가지 이슈가 있을 수 있습니다:

  • 고객서비스가 반드시 24/7/365 가용 해야 할 경우 다운타임으로 인한 서비스 중단을 어떻게 최소화할 것인가?
  • RDBMS와 DynamoDB의 서로 다른 Key Design을 어떻게 반영할 것인가?

이 글에서는 다운타임을 최소화하면서 MySQL의 주요 DB 디자인을 NoSQL에 적합한 형태로 변환한 후,  MySQL의 기존 데이터를 DynamoDB로 원활하게 마이그레이션하는 두 가지 방법을 소개합니다.

마이그레이션을 위한 AWS 서비스 빌딩 블록
이 글에서 포함된 예제 코드들은 다음 AWS 서비스을 사용합니다:

  • AWS 데이터 마이그레이션 서비스(AWS DMS) 는 가장 범용적으로 사용되는 상용 및 오픈소스 데이터베이스 사이의 데이터 마이그레이션을 가능하게 해줍니다. AWS DMS는 서로 다른 데이터베이스 플랫폼 간의 동종 및 이종 데이터 마이그레이션을 지원합니다.
  • Amazon EMR은 방대한 양의 데이터를 신속하게 처리할 수 있도록 하는 관리형 Hadoop 프레임워크입니다. Hive 및 다른 비지니스 소프트웨어를 포함하는 이미 설정된 소프트웨어 스택들로 구성된 EMR 클러스터를 손쉽게 구축할 수 있습니다.
  • Amazon Kinesis는 실시간 트랜잭션, 로그 데이터, 클릭 스트림과 같은 방대한 양의 실시간 데이터를 최대 7일까지 지속적으로 저장하고 유지할 수 있습니다.
  • AWS Lambda는 서버를 준비하거나 운영하지 않고, 원하는 코드를 클라우드 상에서 직접 실행할 수 있도록 해 줍니다. AWS Lambda에서 실행되는 코드는 Amazon Kinesis Stream과 같은 다른 AWS 서비스들에 의해 자동으로 호출되도록 설정할 수 있습니다.

마이그레이션 방안

이 글에서는 다음 두가지 데이터 마이그레이션 옵션을 설명합니다.

  1.  AWS DMS 사용: AWS DMS는 DynamoDB 테이블을 타겟으로 마이그레이션을 지원합니다. 객체 매핑을 사용하여 마이그레이션 과정 중에 원본 데이터를 DynamoDB에서 요구하는 데이터 구조에 적합하게 재구성하는 것이 가능합니다.
  2. Amazon EMR, Kinesis 및 AWS Lambda 커스텀 스크립트 사용: 보다 복잡한 변환 과정 및 유연성이 요구될 때는 EMR, Kinesis, Lambda를 이용한 마이그레이션을 고려할 수 있습니다. MySQL 레코드를 더 적은 DynamoDB 항목으로 그룹화하고, 속성 이름을 동적으로 결정하고, 마이그레이션 중에 프로그래밍 방식으로 비즈니스 로직을 추가하고, 더 많은 데이터 유형을 지원하거나 하나의 큰 테이블에 대해 병렬 제어를 추가하려면 세분화된 사용자 제어가 필요합니다.

데이터 초기 적재 및 벌크 입력을 완료한 후에 가장 최근의 실시간 데이터를 CDC(Change Data Capture)로 처리하고 나면 최종적으로 애플리케이션이 DynamoDB를 바라보도록 설정을 변경하게 됩니다.

이 접근방법에서 변경데이터를 캡처하는 방법에 대한 상세한 내용은 AWS 데이터베이스 블로그 포스팅의 Streaming Changes in a Database with Amazon Kinesis에서 다루고 있습니다. 이 블로그 포스팅에서 사용한 모든 코드 및 테스트 코드는 big-data-blog GitHub 저장소를 통해 얻을 수 있습니다.

마이그레이션 솔루션 아키텍쳐

두 접근 방법의 전반적인 아키텍처는 다음과 같습니다.

방안 1:  AWS DMS 사용

이 절에서는 DMS를 이용하여 어떻게 MySQL 데이터베이스에 접속하고, 원본 데이터를 읽고, 데이터를 대상 DynamoDB 데이터베이스에 적재하기 위해 데이터를 정형화하는지에 대해 설명합니다.

1. 복제 인스턴스 생성 및 원본 및 대상 엔드포인트 설정하기

AWS Database Migration Service Best Practices를 참고하여 마이그레이션을 수행하기에 충분한 저장소와 처리능력을 갖춘 복제 인스턴스를 생성합니다. 예를 들어, 마이그레이션 대상 테이블이 많거나 동시에 여러 복제 작업을 수행할 계획이라면 더 큰 크기의 인스턴스들을 사용하는 것을 고려하여야 합니다. 데이터 복제 서비스는 상당한 양의 메모리와 CPU 리소스를 사용합니다.

MySQL 사용자 정보를 사용하여 MySQL에 접속하고 SUPER, REPLICATION CLIENT 권한으로 데이터를 추출합니다. MySQL 설정에서 Binary log를 활성화하고 CDC를 위해 binlog_format 파라미터를 ROW로 설정합니다. DMS를 사용하는 방법에 대한 더 상세한 정보는 AWS Database Migration Service 사용자 가이드의 Getting Started 문서를 참조합니다.

mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'welcome1'; mysql> GRANT all ON <database name>.* TO 'repl'@'%'; mysql> GRANT SUPER,REPLICATION CLIENT ON *.* TO 'repl'@'%';

DMS에서 DynamoDB 데이터베이스를 대상으로 설정하기 전에, DMS가 사용할 IAM Role을 생성하고 DynamoDB 대상 테이블에 접근할 권한을 부여해야 합니다. 원본 및 대상 데이터베이스에 접근할 엔드포인트들도 다음 스크린샷과 같이 설정합니다.

다음 스크린샷은 source-mysql의 상세 정보 화면입니다.

객체 매핑 규칙 설정 및 작업 생성하기

다음 예제에서는, MySQL 테이블이 복합 프라이머리 키( customer id + ordered + productid )를 가지고 있다고 가정합니다. 이와 같은 경우, 객체 매핑 규칙을 사용하여 DynamoDB에서 요구하는 데이터 구조에 적합하게 키를 재구성할 수 있습니다.

여기에서는 대상 DynamoDB 테이블은 customer idorder id 컬럼의 조합을 hash key로 설정하고 product id 컬럼을 sort key로 설정합니다. 하지만, 실제 마이그레이션 상황에서는 데이터 적재 및 접근 패턴에 따라 파티션 키를 결정해야 합니다. 보통 카디널리티가 높은 속성을 파티션키로 사용하게 됩니다. DynamoDB에서 올바른 파티션 키를 결정하는 방법에 대한 상세한 내용은 Choosing the Right DynamoDB Partition Key 블로그를 참조하십시오.

여기서 rule-action을 map-record-to-record로 설정하였고 해당 컬럼을 제외 대상 컬럼(exclude-columns) 속성 리스트에 포함시키지 않았기 때문에, DMS 서비스는 원본 데이터의 quantity 컬럼을 대상 DynamoDB 테이블에 자동으로 생성합니다. map-record-to-recordmap-record-to-document 설정에 대한 상세 내용은 AWS Database Migration Service에서 Amazon DynamoDB 데이터베이스를 대상으로 사용 문서를 참조하십시오.

마이그레이션은 작업 생성시 Start task on create 옵션을 해제하지 않을 경우, 작업이 생성되는 즉시 시작됩니다. 마이그레이션 작업이 백그라운드에서 수행되는 동안 어떤 일이 발생하는지 확인하기 위하여 enabling logging을 선택하는 것을 추천합니다.

다음 스크린샷은 작업 생성 페이지를 보여줍니다.

콘솔에서 마이그레이션 개별 데이터베이스 테이블과 마이그레이션에 필요한 변환을 포함한 스키마를 지정할 수 있습니다. Guided 탭의 Where 항목에서 스키마, 테이블을 설정하고 Action 항목에서 포함/불포함 여부를 설정합니다. Filter 항목에서 테이블 내의 컬럼명 및 적용할 조건을 설정합니다.

테이블 매핑 정보는 JSON 형태로 생성할 수도 있습니다. JSON 탭에서 Enable JSON editing 체크박스를 선택하십시오.

다음은 원본데이터가 대상 테이블의 어디에 위치할지 결정하는 객체 매핑 규칙에 대한 예제입니다. 아래 예제를 복사하여 사용할 경우, 아래 속성들을 실제 사용하는 값으로 변경해야 합니다. 보다 많은 예제들은 AWS Database Migration Service에서 Amazon DynamoDB 데이터베이스를 대상으로 사용 문서를 참조하십시오.

  • schema-name
  • table-name
  • target-table-name
  • mapping-parameters
  • attribute-mappings
{
  "rules": [
   {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "mydatabase",
        "table-name": "purchase"
      },
      "rule-action": "include"
    },
    {
      "rule-type": "object-mapping",
      "rule-id": "2",
      "rule-name": "2",
      "rule-action": "map-record-to-record",
      "object-locator": {
        "schema-name": "mydatabase",
        "table-name": "purchase"
 
      },
      "target-table-name": "purchase",
      "mapping-parameters": {
        "partition-key-name": "customer_orderid",
        "sort-key-name": "productid",
        "exclude-columns": [
          "customerid",
          "orderid"           
        ],
        "attribute-mappings": [
          {
            "target-attribute-name": "customer_orderid",
            "attribute-type": "scalar",
            "attribute-sub-type": "string",
            "value": "${customerid}|${orderid}"
          },
          {
            "target-attribute-name": "productid",
            "attribute-type": "scalar",
            "attribute-sub-type": "string",
            "value": "${productid}"
          }
        ]
      }
    }
  ]
}

마이그레이션 작업 시작하기
만약 target-table-name 속성에 정의된 대상 테이블이 DynamoDB에 존재하지 않을 경우, DMS는 데이터 변환 참조와 추가 주제를 포함하는 AWS Database Migration Service 참조 문서에서 설명하는 원본 데이터 형식대상 데이터 형식에  대한 데이터형 변환 규칙에 따라 테이블을 생성합니다. 마이그레이션 작업의 진행상황을 모니터링하는 많은 지표들이 제공됩니다. 보다 상세한 모니터링 관련 정보는 AWS Database Migration Service 작업 모니터링 문서에서 확인하실 수 있습니다.

다음 스크린샷은 CloudWatch Logs에 기록된 이벤트들과 오류 샘플입니다.

마이그레이션에 사용한 DMS 복제 인스턴스들은 모든 마이그레이션 작업이 완료된 후에는 삭제되어야 합니다. 보유기간이 경과한 Cloudwatch log들은 자동으로 삭제됩니다.

방안 2: EMR, Amazon Kinesis, Lambda 사용

이 절에서는 보다 정교한 제어와 유연성을 제공하기 위하여 EMR과 Amazon Kinesis, Lamdba를 사용하는 다른 방안에 대해 다룹니다. 만약 작업환경에 MySQL replica가 포함된다면, replica로부터 데이터를 마이그레이션하는 것을 추천합니다.

키 디자인 변경하기
데이터베이스를 RDBMS에서 NoSQL로 변경하기로 결정했다면, 성능 및 비용 효율성을 위해서 데이터 키를 NoSQL에 더 적합하도록 설계할 필요가 있습니다.

방안 #2에서는 방안 #1과 비슷하게 MySQL 데이터베이스 원본이 복합 프라이머리 키 (customerid + orderid + productid)를 가지고 있다고 가정합니다. 하지만, 여기서는 MySQL 레코드들을 customerid(hash key)와 orderid(sort key)를 사용하여 더 적은 DynamoDB 아이템들로 그룹화합니다. 이를 위하여, MySQL의 복합키 중 마지막 컬럼 (productid)을 복합키에서 제거하는 대신 DynamoDB의 속성 이름으로 하고, Quantity 컬럼을 해당 속성의 값으로  변환합니다.

이런 변환법을 통해 전체 아이템의 수를 줄일 수 있으며, 같은 양의 정보를 더 적은 RCU(Read Capacity Unit)을 사용하여 조회할 수 있어 비용을 절감하면서 더 나은 성능을 얻을 수 있습니다. RCU/WCU(Read Capacity Unit/Write Capacity Unit)를 어떻게 계산하는지에 대한 더 상세한 정보는 프로비저닝된 처리량 문서를 확인하시기 바랍니다.

단계별 마이그레이션

방안 #2는 다음 두 단계의 마이그레이션이 동시에 진행됩니다.:

  • 일괄 처리: MySQL 데이터 export, export파일의 S3 업로드, S3 데이터 DynamoDB에 import
  • 실시간 처리: MySQL의 변경 데이터 캡처, insert/update/delete 트랜잭션을 Kinesis Stream에 송신, DynamoDB에 데이터를 입력하기 위한 Lambda 함수 호출.

데이터의 일관성과 무결성을 유지하기 위해 데이터를 캡처하고 Amazon Kinesis Stream에 밀어넣는 작업은 일괄 처리 프로세스 전에 시작되어야 하고, EMR에서 처리되는 일괄처리 프로세스가 종료되기 전까지 Lambda 함수는 실행되지 않고 캡처된 데이터가 스트림에 유지되어야 합니다. 다음 순서와 같이 진행됩니다.:

  1. Amazon Kinesis Stream에 대해 데이터 실시간 처리를 시작합니다.
  2. 실시간 처리 프로세스가 시작되자마자, 일괄 처리 프로세스를 시작합니다.
  3. 일괄 처리 프로세스가 완료되면 Amazon Kinesis Stream으로 부터 데이터를 추출하여 DynamoDB에 put_item 함수를 실행하는 Lambda 함수를 호출합니다.
  4. 애플리케이션의 엔드포인트를 MySQL에서 DynamoDB를 바라보도록 설정을 변경합니다.

단계 1:  변경데이터캡처및 Amazon Kinesis Streams에밀어넣기

먼저, MySQL으로부터 트렌젝션 데이터를 캡처할 Amazon Kinesis Stream을 생성합니다. Data retention period 값을 일괄 처리 프로세스의 예상 처리시간에 맞춰 설정합니다. 데이터 무결성을 위해서는 데이터 보관 기간을 일괄 처리 프로세스가 실행되는 기간 동안 발생하는 모든 트랜잭션을 보관하기 충분할 정도로 길게 설정해야 하지만, 보관 기간을 반드시 최대값으로 설정할 필요는 없습니다. 마이그레이션 대상 데이터의 양에 따라 설정합니다.

MySQL 설정에서, BinLogStreamReader 모듈이 트랜잭션 데이터를 캡처할수 있도록 binlog_format 설정값을 ROW로 설정합니다. Binlog를 활성화하려면 log_bin 매개변수도 설정되어야 합니다. 더 상세한 내용은 AWS 데이터베이스 블로그의 Streaming Changes in a Database with Amazon Kinesis 포스트를 참조하시기 바랍니다.

[mysqld]
secure-file-priv = ""
log_bin=/data/binlog/binlog
binlog_format=ROW
server-id = 1
tmpdir=/data/tmp

다음 예제 코드는 트랜잭션 데이터를 캡처하여 Amazon Kinesis Stream으로 밀어넣는 Python 예제 코드입니다.

#!/usr/bin/env python
from pymysqlreplication import BinLogStreamReader
from pymysqlreplication.row_event import (
  DeleteRowsEvent,
  UpdateRowsEvent,
  WriteRowsEvent,
)

def main():
  kinesis = boto3.client("kinesis")

  stream = BinLogStreamReader(
    connection_settings= {
      "host": "<host IP address>",
      "port": <port number>,
      "user": "<user name>",
      "passwd": "<password>"},
    server_id=100,
    blocking=True,
    resume_stream=True,
    only_events=[DeleteRowsEvent, WriteRowsEvent, UpdateRowsEvent])

  for binlogevent in stream:
    for row in binlogevent.rows:
      event = {"schema": binlogevent.schema,
      "table": binlogevent.table,
      "type": type(binlogevent).__name__,
      "row": row
      }

      kinesis.put_record(StreamName="<Amazon Kinesis stream name>", Data=json.dumps(event), PartitionKey="default")
      print json.dumps(event)

if __name__ == "__main__":
main()

다음 코드는 위 Python 스크립트에 의해 생성된 JSON 데이터 예제입니다. 각 트랜잭션은 JSON 데이터에 다음과 같은 type 속성으로 기록됩니다:

  • WriteRowsEvent = INSERT
  • UpdateRowsEvent = UPDATE
  • DeleteRowsEvent = DELETE
{"table": "purchase_temp", "row": {"values": {"orderid": "orderidA1", "quantity": 100, "customerid": "customeridA74187", "productid": "productid1"}}, "type": "WriteRowsEvent", "schema": "test"}
{"table": "purchase_temp", "row": {"before_values": {"orderid": "orderid1", "quantity": 1, "customerid": "customerid74187", "productid": "productid1"}, "after_values": {"orderid": "orderid1", "quantity": 99, "customerid": "customerid74187", "productid": "productid1"}}, "type": "UpdateRowsEvent", "schema": "test"}
{"table": "purchase_temp", "row": {"values": {"orderid": "orderid100", "quantity": 1, "customerid": "customerid74187", "productid": "productid1"}}, "type": "DeleteRowsEvent", "schema": "test"}

단계 2. MySQL에서 DynamoDB로 데이터 덤프하기

DMS를 사용하는 가장 손쉬운 방법 중 하나는, 최근 추가된 Amazon S3를 마이그레이션 대상으로 사용하는 것입니다. S3를 대상으로 할 경우, full load 및 CDC 데이터가 CSV 형식으로 저장됩니다. 그러나, CDC의 경우에는 UPDATE 및 DELETE 문의 지원되지 않아 마이그레이션에 적합하지 않습니다. 보다 상세한 내용은 AWS Database Migration Service에서 Amazon S3를 대상으로 사용 문서를 참조하십시오.

Amazon S3로 데이터를 업로드하는 다른 방법은 스크립트에서 INTO OUTFILE SQL 절과 aws s3 sync CLI 명령어를 병렬로 사용하는 것입니다. 병렬 처리 수준은 서버 용량 및 로컬 네트워크 대역폭에 따라 달라집니다. pt-archiverPercona Toolkit 에 포함된 도구입니다. 상세 내용은 appendix를 참조하십시오. )와 같은 3rd party 도구도 유용하게 사용할 수 있습니다.

SELECT * FROM purchase WHERE <condition_1>
INTO OUTFILE '/data/export/purchase/1.csv' FIELDS TERMINATED BY ',' ESCAPED BY '\\' LINES TERMINATED BY '\n';
SELECT * FROM purchase WHERE <condition_2>
INTO OUTFILE '/data/export/purchase/2.csv' FIELDS TERMINATED BY ',' ESCAPED BY '\\' LINES TERMINATED BY '\n';
...
SELECT * FROM purchase WHERE <condition_n>
INTO OUTFILE '/data/export/purchase/n.csv' FIELDS TERMINATED BY ',' ESCAPED BY '\\' LINES TERMINATED BY '\n';

여기에서 다루는 사용사례의 경우 aws s3 sync 명령어를 추천합니다. 이 명령어는 내부적으로 S3 multipart 업로드기능을 사용하여 동작하고 패턴 매칭을 통해 특정파일을 포함하거나 제외시킬 수 있습니다. 또한, sync 명령어는 로컬 버전과 S3 버전 간에 파일 크기와 수정시간을 비교하여 서로 다른 경우에만 동기화를 수행하기 때문에 동기화 프로세스가 처리 도중에 중단되더라도 동일한 파일을 다시 업로드할 필요가 없습니다. 더 상세한 내용은 AWS CLI 명령어 참조문서의 sync command를 참고하시기 바랍니다.

$ aws s3 sync /data/export/purchase/ s3://<your bucket name>/purchase/ 
$ aws s3 sync /data/export/<other path_1>/ s3://<your bucket name>/<other path_1>/
...
$ aws s3 sync /data/export/<other path_n>/ s3://<your bucket name>/<other path_n>/ 

모든 데이터가 S3로 업로드된 후, 데이터를 DynamoDB에 밀어넣기 위해서는 다음과 같은 두가지 방법이 있습니다.:

  • 외부 테이블을 이용하여 Hive사용
  • MapReduce 코드 작성

외부 테이블을 이용하여 Hive 사용

S3의 데이터에 대해서 Hive 외부테이블을 생성하고 org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler 속성을 사용하여 생성한 DynamoDB 테이블을 대상으로 하는 다른 외부 테이블에 S3와 연결된 외부 테이블의 내용을 밀어넣습니다. 더 나은 생산성과 확장성을 위해 Hive용 UDF 모음인 Brickhouse를 사용하는 것을 고려해 볼 수 있습니다.

다음 샘플 코드는 DynamoDB용 Hive 테이블이 ARRAY<STRING> 타입의 products 컬럼으로 생성되었다고 가정합니다. Productidquantity 컬럼은 customeridorderid별로 그룹화되어 Brickhouse에서 제공하는 CollectUDAF 컬럼을 사용하여 products 컬럼에 삽입됩니다.

hive> DROP TABLE purchase_ext_s3; 
--- To read data from S3 
hive> CREATE EXTERNAL TABLE purchase_ext_s3 (
customerid string,
orderid    string,
productid  string,
quantity   string) 
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' 
LOCATION 's3://<your bucket name>/purchase/';

Hive> drop table purchase_ext_dynamodb ; 
--- To connect to DynamoDB table  
Hive> CREATE EXTERNAL TABLE purchase_ext_dynamodb (
      customerid STRING, orderid STRING, products ARRAY<STRING>)
      STORED BY 'org.apache.hadoop.hive.dynamodb.DynamoDBStorageHandler' 
      TBLPROPERTIES ("dynamodb.table.name" = "purchase", 
      "dynamodb.column.mapping" = "customerid:customerid,orderid:orderid,products:products");

--- Batch-puts to DynamoDB using Brickhouse 
hive> add jar /<jar file path>/brickhouse-0.7.1-SNAPSHOT.jar ; 
hive> create temporary function collect as 'brickhouse.udf.collect.CollectUDAF';
hive> INSERT INTO purchase_ext_dynamodb 
select customerid as customerid , orderid as orderid
       ,collect(concat(productid,':' ,quantity)) as products
      from purchase_ext_s3
      group by customerid, orderid; 

불행히도 DynamoDBStorageHandler클래스는 MAP, LIST, BOOLEAN 및 NULL  데이터형을 지원하지 않기 때문에 ARRAY<STRING> 데이터형을 선택하였습니다. Hive의 ARRAY<STRING> 형식의 products 컬럼은 DynamoDB의 StringSet데이터형 속성으로 변환됩니다. 샘플코드는 Brickhouse가 어떤 식으로 동작하는지, 어떻게 원하는 복수의 레코드들을 골라 DynamoDB의 하나의 StringSet  데이터형 속성으로 병합할 수 있는지 보여줍니다.

Hadoop Streaming으로 Python MarReduce 코드 작성하기
맵퍼 작업은 S3의 입력데이터로부터 각 레코드를 읽고 입력 키-값 쌍을 중간 키-값 쌍으로 매핑합니다. S3의 원본 데이터를 탭 문자(“\t)로 구분된 키 부분과 값 부분의 두 부분으로 나눕니다. 맵퍼 데이터는 중간 키(customeridorderid) 값으로 정렬되어 reducer로 전송됩니다. reducer단계에서 각 레코드들이 DynamoDB에 저장합니다.

#!/usr/bin/env python
import sys
 
# get all lines from stdin
for line in sys.stdin:
    line = line.strip()
    cols = line.split(',')
# divide source data into Key and attribute part.
# example output : “cusotmer1,order1	product1,10”
    print '%s,%s\t%s,%s' % (cols[0],cols[1],cols[2],cols[3] )

일반적으로 reduce 작업은 매핑( 키 / 값 목록의 쌍 ) 프로세스가 생성한 결과값을 수신한 뒤 각 키에 대해 값의 목록에 대한 작업을 수행합니다.

여기서는 reducer를 STDIN/STDOUT/Hadoop streaming을 기반으로 하여 Python으로 작성하였습니다. 문제는 이와 같은 경우 열거형 데이터 형식을 사용할 수 없다는 것입니다. 이와 같은 경우 reducer를 매퍼의 중간 키값 – 이 경우, customeridoerderid(cols[0],cols[1]) -으로 정렬된 데이터를 수신하고 모든 속성을 item_data dictionary의 특정 키로 저장합니다. Item_data dictionary의 속성들은 sys.stdin에서 새 중간 키가 들어올 대마다 DynamoDB에 입력되거나 플러싱됩니다.

#!/usr/bin/env python
import sys
import boto.dynamodb
 
# create connection to DynamoDB
current_keys = None
conn = boto.dynamodb.connect_to_region( '<region>', aws_access_key_id='<access key id>', aws_secret_access_key='<secret access key>')
table = conn.get_table('<dynamodb table name>')
item_data = {}

# input comes from STDIN emitted by Mapper
for line in sys.stdin:
    line = line.strip()
    dickeys, items  = line.split('\t')
    products = items.split(',')
    if current_keys == dickeys:
       item_data[products[0]]=products[1]  
    else:
        if current_keys:
          try:
              mykeys = current_keys.split(',') 
              item = table.new_item(hash_key=mykeys[0],range_key=mykeys[1], attrs=item_data )
              item.put() 
          except Exception ,e:
              print 'Exception occurred! :', e.message,'==> Data:' , mykeys
        item_data = {}
        item_data[products[0]]=products[1]
        current_keys = dickeys

# put last data
if current_keys == dickeys:
   print 'Last one:' , current_keys #, item_data
   try:
       mykeys = dickeys.split(',')
       item = table.new_item(hash_key=mykeys[0] , range_key=mykeys[1], attrs=item_data )
       item.put()
   except Exception ,e:
print 'Exception occurred! :', e.message, '==> Data:' , mykeys

MapReduce 작업을 실행하려면 EMR 마스터 노드에 접속하여 Hadoop 스트리밍 작업을 실행하십시오. hadoop-streaming.jar 파일 위치 및 파일 이름은 EMR 버전에 따라 다를 수 있습니다. reducer가 실행되는 동안 발생하는 exception 메시지들은 -output 옵션으로 지정한 디렉토리에 저장됩니다. 예외 또는 오류의 원인이되는 데이터를 식별하기 위해 해시 키 및 범위 키 값들도 기록됩니다.

$ hadoop fs -rm -r s3://<bucket name>/<output path>
$ hadoop jar /usr/lib/hadoop-mapreduce/hadoop-streaming.jar \
           -input s3://<bucket name>/<input path> -output s3://<bucket name>/<output path>\
           -file /<local path>/mapper.py -mapper /<local path>/mapper.py \
           -file /<local path>/reducer.py -reducer /<local path>/reducer.py

위 스크립트와 자체 생성한 테스트 데이터를 사용하여 수행한 마이그레이션 테스트에서 데이터베이스 크기 및 데이터 마이그레이션을 완료하기까지 걸린 시간은 다음과 같습니다.

Server MySQL instance m4.2xlarge
EMR cluster master : 1 x m3.xlarge

core  : 2 x m4.4xlarge

DynamoDB 2000 write capacity unit
Data Number of records 1,000,000,000
Database file size (.ibc) 100.6 GB
CSV files size 37 GB
Performance (time) Export to CSV 6 min 10 sec
Upload to S3 (sync) 3 min 30 sec
Import to DynamoDB depending on write capacity unit

다음 스크린샷은 마이그레이션 작업 도중 write capacity 사용 결과를 보여줍니다.

성능 결과는 사용한 서버 용량과 네트워크 대역폭, 병렬 처리 수준, 변환 로직, 사용 프로그램 언어 및 기타 조건에 달라질 수 있습니다. 이 경우 프로비저닝된 write capacity unit이 모두 데이터 import를 위해 사용한 MapReduce 작업에 의해 소비되었으므로, EMR 클러스터의 크기 및 DynamoDB 테이블의 write capacity unit을 늘릴 수록 데이터 이전작업 완료에 걸리는 시간을 단축할 수 있습니다. Jave 기반 MapReduce 코드를 사용할 경우 MapReduce 프레임워크 사용 및 함수 작성시 보다 많은 유연성을 제공합니다.

단계 3: Amazon Lambda 함수를 사용하여 Amazon Kinesis로부터 데이터를 읽고 DynamoDB에 업데이트하기

AWS Lambda 콘솔에서 Create a Lambda functionkinesis-process-record-python blueprint를 선택합니다. 다음 버튼을 클릭하고 Configure triggers 페이지에서 생성한 Kinesis stream을 선택합니다.

생성한 Lambda 함수가 Amazon Kinesis 스트림을 읽고 데이터를 DynamoDB에 쓸 수 있도록 해당 권한을 가진 IAM role을 설정하여야 합니다.

Lambda 함수는 각 레코드의 type 속성을 확인하여 트랜잭션 유형을 식별합니다. 트랜잭션 유형에 따라 변환 및 업데이트 방법이 결정됩니다.

예를 들어 JSON 레코드가 함수에 전달되면 함수는 type 속성을 확인하고 DynamoDB 테이블에 들어온 레코드와 동일한 키를 가진 아이템이 이미 존재하는지 확인합니다. 만약 동일한 키를 가진 아이템이 이미 있다면 기존 아이템을 조회하여 dictionary 변수 (다음 코드에서는 item 변수)에 저장하고 DynamoDB 테이블에 저장하기 전에 dictionary 변수에 저장된 기존 아이템 정보에 새로 전달된 정보를 반영하여 저장합니다. 이렇게 해서 들어오는 레코드가 기존 항목을 덮어 쓰지 않도록 합니다.

from __future__ import print_function

import base64
import json
import boto3

print('Loading function')
client = boto3.client('dynamodb')

def lambda_handler(event, context):
    #print("Received event: " + json.dumps(event, indent=2))
    for record in event['Records']:
        # Amazon Kinesis data is base64-encoded so decode here
        payload = base64.b64decode(record['kinesis']['data'])
        print("Decoded payload: " + payload)
        data = json.loads(payload)
        
        # user logic for data triggered by WriteRowsEvent
        if data["type"] == "WriteRowsEvent":
            my_table = data["table"]
            my_hashkey = data["row"]["values"]["customerid"]
            my_rangekey = data["row"]["values"]["orderid"]
            my_productid = data["row"]["values"]["productid"]
            my_quantity = str( data["row"]["values"]["quantity"] )
            try:
                response = client.get_item( Key={'customerid':{'S':my_hashkey} , 'orderid':{'S':my_rangekey}} ,TableName = my_table )
                if 'Item' in response:
                    item = response['Item']
                    item[data["row"]["values"]["productid"]] = {"S":my_quantity}
                    result1 = client.put_item(Item = item , TableName = my_table )
                else:
                    item = { 'customerid':{'S':my_hashkey} , 'orderid':{'S':my_rangekey} , my_productid :{"S":my_quantity}  }
                    result2 = client.put_item( Item = item , TableName = my_table )
            except Exception, e:
                print( 'WriteRowsEvent Exception ! :', e.message  , '==> Data:' ,data["row"]["values"]["customerid"]  , data["row"]["values"]["orderid"] )
        
        # user logic for data triggered by UpdateRowsEvent
        if data["type"] == "UpdateRowsEvent":
            my_table = data["table"]
            
        # user logic for data triggered by DeleteRowsEvent    
        if data["type"] == "DeleteRowsEvent":
            my_table = data["table"]
            
            
    return 'Successfully processed {} records.'.format(len(event['Records']))

단계 4:  애플리케이션 엔드포인트를 MySQL에서 DynamoDB로 변경하기

애플리케이션이 MySQL 대신 DynamoDB를 데이터베이스로 사용하려면 애플리케이션 코드를 리팩토링해야 합니다. 애플리케이션의 데이터베이스 액세스에 대한 모든 경우를 여기에서 다루기는 어렵기 때문에, 여기서는 다음의 간단한 자바 코드로 데이터베이스 연결 및 쿼리 부분이 어떻게 바뀌어야 하는지 확인해 보겠습니다. 더 자세한 내용에 대해서는 DynamoDB 및 AWS SDK를 사용한 프로그래밍 문서를 참조하시기 바랍니다.

MySQL 쿼리 코드 예제

다음 샘플 코드는 MySQL 데이터베이스에 연결하고 데이터를 조회하는 일반적인 방법을 보여줍니다.

import java.sql.* ;
...
try {
    Connection conn =  DriverManager.getConnection("jdbc:mysql://<host name>/<database name>" , "<user>" , "<password>");
    stmt = conn.createStatement();
    String sql = "SELECT quantity as quantity FROM purchase WHERE customerid = '<customerid>' and orderid = '<orderid>' and productid = '<productid>'";
    ResultSet rs = stmt.executeQuery(sql);

    while(rs.next()){ 
       int quantity  = rs.getString("quantity");   //Retrieve by column name 
       System.out.print("quantity: " + quantity);  //Display values 
       }
} catch (SQLException ex) {
    // handle any errors
    System.out.println("SQLException: " + ex.getMessage());}
...
==== Output ====
quantity:1

DynamoDB 쿼리 코드 예제

DynamoDB에서 데이터를 조회하려면 다음 단계를 따르면 됩니다:

  1. AmazonDynamoDBClient 및 ProfileCredentialProvider를 이용하여 DynamoDB 클래스의 인스턴스 생성
  2. DynamoDB 클래스 인스턴스의 getTable method를 사용하여 대상 Table 클래스 인스턴스 획득
  3. withHashKey및 withRangeKeyCondition method를 사용하여 QuerySpec 클래스 인스턴스 생성
  4. QuerySpec 클래스 인스턴스를 사용하여 Table 클래스 인스턴스의 query method를 실행. 결과값이 JSON 형식으로 반환되므로, 결과값에 대하여 특정 속성 값을 확인하기 위하여 getJSON method 사용
...
DynamoDB dynamoDB = new DynamoDB( new AmazonDynamoDBClient(new ProfileCredentialsProvider()));

Table table = dynamoDB.getTable("purchase");

QuerySpec querySpec = new QuerySpec()
        .withHashKey("customerid" , "customer1")  // hashkey name and its value 
        .withRangeKeyCondition(new RangeKeyCondition("orderid").eq("order1") ) ; // Ranage key and its condition value 

ItemCollection<QueryOutcome> items = table.query(querySpec); 

Iterator<Item> iterator = items.iterator();          
while (iterator.hasNext()) {
Item item = iterator.next();
System.out.println(("quantity: " + item.getJSON("product1"));   // 
}
...
==== Output ====
quantity:1

맺음말
이 글에서는 MySQL에서 DynamoDB로 데이터를 원활하게 마이그레이션하고 마이그레이션 중 중단 시간을 최소화하기 위한 두 가지 방안을 소개했습니다. 방안 #1에서는 DMS를 사용하였고, 방안 #2에서는 EMR, Amazon Kinesis 및 Lambda를 복합적으로 사용하였습니다. 또한 각 데이터베이스의 특성에 따라 키 디자인을 변환하여 읽기 및 쓰기 성능을 개선하고 비용을 절감하는 방법도 설명했습니다. 각 방안은 서로 장단점이 있으므로 비즈니스 요구 사항에 따라 어떤 접근방법을 취할지 고려할 필요가 있습니다.

여기에서 사용한 예제 코드들은 다양한 환경에서 완벽하고 효율적이며 신뢰할 수 있는 데이터 마이그레이션 용으로 재사용되기에 충분한 수준이 아닙니다. 데이터 마이그레이션을 시작하기 전에 참조용으로 사용하시고 실제 마이그레이션에서는 신뢰할 수 있는 마이그레이션을 수행할 수 있도록 모든 요소들을 충분히 고려하여 작성되어야 합니다.

이 글이 여러분의 데이터베이스 마이그레이션을 계획 및 구현하고 서비스 중단을 최소화하는데 도움이 되기를 바랍니다.

Appendix

Percona Toolkit 설치법:

# Install Percona Toolkit
$ wget https://www.percona.com/downloads/percona-toolkit/3.0.2/binary/redhat/6/x86_64/percona-toolkit-3.0.2-1.el6.x86_64.rpm
$ yum install perl-IO-Socket-SSL
$ yum install perl-TermReadKey
$ rpm -Uvh percona-toolkit-3.0.2-1.el6.x86_64.rpm

Pt-archiver 실행 예제:

# run pt-archiver
$ pt-archiver –source h=localhost,D=blog,t=purchase –file ‘/data/export/%Y-%m-%d-%D.%t’  –where “1=1” –limit 10000 –commit-each

이 글은 AWS 빅데이터 서비스의 기술 지원 엔지니어인 이용성님이 작성하신 글 Near Zero Downtime Migration from MySQL to DynamoDB을 AWS 솔루션즈 아키텍트인 김병수님이 번역해 주셨습니다.

Oracle 데이터베이스를 Amazon Aurora로 마이그레이션 하기

AWS Schema Conversion Tool(AWS SCT) 및 AWS Database Migration Service(AWS DMS) 를 사용하여 상용 데이터베이스를 Amazon Aurora로 마이그레이션하는 작업을 간소화하는 방법에 대한 개요를 제공합니다. 특히, Oracle 에서 MySQL과 호환되는 Amazon Aurora 로의 마이그레이션에 중점을 둡니다.

원문은 AWS Database Blog의 How to Migrate Your Oracle Database to Amazon Aurora 입니다.

데이터베이스 엔진 변경은 매우 어려울 수 있습니다. 그러나 Amazon Aurora와 같이 확장성이 뛰어나고 비용 효율적이며 완벽하게 관리되는 서비스의 많은 장점으로 인해 그 도전은 가치가 있습니다. 프로세스를 단순화 할 수 있는 도구가 있는 경우 특히 그렇습니다. 특정 엔진에서 다른 엔진으로 데이트베이스를 마이그레이션 할 때, 고려해야 할 사항이 두 가지 있습니다. 스키마와 코드 개체의 변환, 그리고 데이터 자체의 마이그레이션과 변환 등입니다. 다행히 AWS 는 데이터베이스의 변환 및 마이그레이션을 용이하게 하는 도구를 제공합니다.

AWS Schema Conversion Tool 은 원본 데이터베이스 스키마와 대다수의 사용자 정의 코드를 대상 데이터베이스와 호환되는 형식으로 자동 변환해 줌으로써 이기종 데이터베이스 마이그레이션을 단순화 합니다. 이 도구에서 변환하는 사용자 지정 코드에는 뷰(views), 저장 프로시저(stored procedures) 및 함수(functions)가 포함됩니다. 도구에서 자동으로 변환할 수 없는 코드는 사용자가 직접 변환할 수 있도록 명확하게 표시됩니다. AWS Database Migration Service는 다운타임을 최소화하면서 쉽고 안전하게 데이터를 마이그레이션 할 수 있도록 지원합니다.

좋습니다! 그럼 어디서 부터 시작해야 할까요?

AWS SCT로 작업하기
일반적으로, 모든 마이그레이션의 첫 번째 단계는 실행 가능성과 그에 따른 노력을 평가하는 것입니다. AWS SCT를 사용하여 오라클 데이터베이스를 Aurora로 변환하는데 필요한 개괄적인 노력을 평가해 볼 수 있습니다. AWS SCT는 여러 운영체제에서 실행할 수 있습니다. 이 글의 목적을 위해 Windows 에서 이 도구를 실행해 보도록 하겠습니다. AWS SCT를 다운로드 하려면 AWS Schema Conversion Tool 문서의 설치 및 업데이트를 참조하십시오. AWS SCT에 대한 전체 설명서를 보려면, AWS Schema Conversion Tool 이란 무엇인가? 를 확인하십시오.

이 글은 AWS SCT의 설치 및 구성을 다루지는 않지만, SCT를 원본 및 대상 데이터베이스에 연결하기 위해 Oracle 및 MySQL용 드라이버를 설치하는 것이 중요합니다. 원본 데이터베이스인 Oracle에 연결 한 후, 주어진 스키마를 마우스 오른쪽 단추로 클릭하고 평가 보고서를 생성할 수 있습니다. 이 평가 보고서는 Oracle 에서 Aurora로 변환할 수 있는 스키마의 양과 변환 후 남은 수동 작업을 매우 높은 수준에서 알려줍니다. 다음은 평가 보고서의 예제입니다.

AssessmentReport

평가 보고서 외에도, SCT는 각 객체가 정확히 어떻게 변환되는지 알려줍니다. 객체를 변환할 수 없는 경우, SCT는 그 이유를 알려주고 상황을 해결할 수 있는 방법에 대한 힌트를 제공합니다.

AssessmentReport1

스키마의 100%가 Oracle 에서 Aurora로 변환되지 않는 경우에는 다음가 같이 몇가지 방법으로 문제를 해결할 수 있습니다.

  • SCT가 Aurora로 변환할 수 있도록 원본 Oracle 데이터베이스의 개체를 수정합니다.
  • 스키마를 그대로 변환하고 Aurora 데이터베이스에 적용하기 전에 SCT가 생성한 스크립트를 수정하십시오.
  • 변환할 수 없는 객체를 무시하고 대상 데이터베이스에서 수정하십시오. 예를 들어, Oracle 에서dbms_random 패키지를 호출하는 함수가 있다고 가정하십시오. 이 패키지는 Aurora에는 존재하지 않습니다. 이 문제를 해결하려면 다음을 수행하십시오.
    • 랜덤 값 생성을 애플리케이션 코드로 푸시하고 매개변수로 함수에 전달하십시오. 변환 전에 원본 데이터베이스에서 또는 변환 후에 대상 데이터베이스에 이 수정작업을 하도록 선택할 수 있습니다.
    • SCT가 생성한 코드를 수정하여 MySQL 에서 사용할 수 있는RAND()함수를 사용하고 Aurora 데이터베이스에 새 코드를 적용합니다.

다른 예로, Oracle 에서 시퀀스를 사용하여 일부 고유 식별자를 채우는 경우를 가정해 보십시오. Aurora는 시퀀스를 지원하지 않으므로 이것을 해결하기 위해서 다음과 같이 할 수 있습니다.

  • Aurora의 자동 증가(auto-increment) 기능을 사용하여 고유한 식별자를 자동으로 채웁니다. 이 방법을 사용하는 경우 Aurora 데이터베이스에서 스키마를 작성한 후 대상 테이블을 수정하는 스크립트를 작성해야 할 수 있습니다.
  • 고유한 식별자(함수 또는 유사한 것을 사용)를 생성하는 대체 방법을 만들고 시퀀스에 대한 참조를 새 함수로 바꿉니다. 변환 전에 Oracle 소스에서 또는 변환 후에 Aurora 데이터베이스에서 이 작업을 수행할 수 있습니다.
  • 두가지 방법을 모두 사용해야 할 수도 있습니다.

일반적으로 마이그레이션 작업의 일부로 SCT를 사용하는 경우 다음과 같은 작업을 함께 진행하는 것이 좋은 방법입니다.

  • SCT 평가 보고서를 작성하고 그것을 사용하여 변환 작업의 부족한 부분을 채우기 위한 계획을 수립하십시오. 마이그레이션 후보 시스템이 여러 개인 경우 SCT 평가 보고서를 사용하여 먼저 진행해야 할 시스템을 결정하십시오.
  • 작업 항목을 검토하고 변환에 실패한 각 항목에 대한 적절한 해결책을 결정하십시오.
  • 이 프로세스를 반복하여 AWS Database Migration Service와 함께 사용하여 새로운 스키마에 데이터를 로드하고 새로운 Aurora 데이터베이스에 대해 애플리케이션을 테스트 할 수 있습니다.

AWS DMS로 넘어가 보겠습니다!

AWS DMS로 작업하기
AWS DMS를 사용하여 Oracle 원본 데이터베이스의 데이터를 새로운 대상인 Aurora 데이터베이스로 로드 할 수 있습니다. DMS의 가장 큰 장점은 대량 데이터를 로드 하는 것 외에도 진행중인 트랜잭션을 캡처하여 적용한다는 것입니다. Oracle 원본과 Aurora 대상 데이터베이스는 이전 할 때까지 동기화되어 유지됩니다. 이 방법을 사용하면 마이그레이션을 완료하는 데 필요한 중단 시간을 크게 줄일 수 있습니다. 모든 DMS 마이그레이션에는 다음 요소가 포함됩니다. 원본 엔드 포인트, Oracle; 대상 엔드 포인트, Aurora; 복제 서버; 및 작업.

Oracle 에서 Aurora로 마이그레이션 할 때 기존 데이터를 마이그레이션하고 진행중인 변경 사항을 복제하도록 작업 구성하기를 원할 겁니다. 이렇게 하면 대량 데이터를 마이그레이션하는 동안 DMS가 트랜잭션을 캡처하도록 합니다. 대량 데이터를 로드 한 후 DMS는 캡처 된 트랜잭션을 적용하기 시작하여 Oracle 및 Aurora 데이터베이스를 동기화 합니다. Aurora로 전환된 준비가 되면 애플리케이션을 중지하고, DMS가 마지막 트랜잭션을 적용하도록 하고, 새로운 Aurora 데이터베이스를 가리키는 애플리케이션을 시작합니다.

DMS를 사용하여 Oracle 에서 Aurora로 마이그레이션 할 때 고려해야 할 몇 가지 사항이 있습니다.

Supplemental logging. DMS가 원본 Oracle 에서 변경사항을 캡처하려면 보충 로깅(supplemental logging) 기능을 사용해야 합니다. 자세한 지침은 DMS 설명서 에서 찾을 수 있습니다.

DMS의 3단계. DMS는 데이터를 마이그레이션하고 진행중인 변경 사항을 복제할 때 세 단계를 거칩니다.

  • Bulk load:마이그레이션의 대량 로드(Bulk load) 단계에서 DMS는 한 번에 n개의 테이블을 개별적으로 로드 합니다. 디폴트로는 n=8 입니다. 이 값은 DMS 관리 콘솔 또는 AWS CLI를 사용하여 설정할 수 있습니다.
  • Application of cached transactions:대량 로드 단계에서 DMS는 원본 데이터베이스에 대한 변경 내용을 캡처합니다. 테이블에 대한 대량 로드가 완료되면 DMS는 대량 로드의 일부인 것처럼 최대한 빨리 캐시된 변경 내용을 해당 테이블에 적용합니다.
  • Transactional apply:모든 테이블에 대해 대량 로드가 완료되면 DMS는 캡처 된 변경 사항을 단일 테이블 업데이트가 아닌 트랜잭션으로 적용하기 시작합니다.

보조 색인(Secondary indexes). 경우에 따라 성능상의 이유로 대량 로드 단계에서 보조 인덱스를 제거 할 수 있습니다. 대량 로드 단계에서 보조 색인 일부 또는 전체를 제거하도록 선택하면 트랜잭션 적용 단계에서 마이그레이션을 일시 중지하고 다시 추가해야 합니다. 모든 테이블에 대해 전체 로드가 완료된 후 마이그레이션을 안전하게 일시 중지할 수 있습니다.

외래 키(Foreign keys), 트리거(triggers), 등. 대량 로드는 테이블 단위로 수행되기 때문에 마이그레이션의 대량 로드 및 캐시 된 트랜잭션 단계에서 대상 Aurora 데이터베이스의 외래 키 조건이 위반될 수 있습니다. 대상 Aurora 엔드 포인트 정의의 추가 연결 속성으로 다음을 추가하여 외래 키 점검을 불가능 하게 할 수 있습니다. initstmt=SET FOREIGN_KEY_CHECKS=0. 일반적으로 데이터의 대량 로드로 인해 혼란을 겪거나 부정적인 영향을 받을 수 있는 사항을 처리하기 위한 전략을 수립해야 합니다. 예를 들어, 문제가 발생하지 않도록 하려면 트리거 설치를 마이그레이션의 컷 오버 단계까지 연기 할 수 있습니다.

데이터 유형. 새로운 데이터베이스 엔진으로 마이그레이션 할 때, 지원되는 데이터 유형과, 원본 데이터 유형이 어떻게 새로운 대상 데이터 유형으로 변환되는 지를 이해하는 것은 중요합니다. 이 경우에는, DMS 설명서에 있는 Oracle 원본 데이터 유형Aurora 대상 데이터 유형을 확인해야 합니다

성능: 마이그레이션의 전체 성능은 원본 Oracle 데이터베이스의 데이터 양, 유형 및 분산에 따라 달라질 수 있습니다. 데이터베이스 마이그레이션 서비스 모범 사례 백서에는 마이그레이션 성능을 최적화 할 수 있는 몇가지 권장 사항이 있습니다.

프로세스를 요약하면 다음과 같습니다.

  1. SCT 평가 보고서를 사용하여 현재 진행중인 작업의 개요를 확인하십시오. Aurora 로의 마이그레이션 후보가 여러 개인 경우 이 보고서를 통해 어떤 것을 먼저 마이그레이션 할지 결정할 수 있습니다.
  2. 처리 전후에 필요할 수 있는 마이그레이션 단계를 없애기 위해 대상 스키마를 생성하는 것을 연습하고 DMS를 사용하여 로드 하십시오.
  3. 대상 시스템에서 애플리케이션을 테스트하여 새로운 환경에서 예상한대로 동작하는지 확인하십시오. 로드, 네트워크 구성 등 프로덕션 환경과 유사한 구성에서 애플리케이션을 테스트 해보십시오.
  4. 스키마 생성, 데이터 로딩, 후 처리 단계 적용, 원본과 동기화 된 대상 시스템 가져 오기 및 필요한 모든 단계를 포함하여 실제 마이그레이션을 실습하십시오.
  5. SCT나 DMS 는 전체 시스템을 한번에 마이그레이션 할 것을 요구하지 않습니다. 이러한 도구를 사용하여 원하는 경우 시스템을 효율적으로 마이그레이션하고 재구성(rearchitect) 할 수 있습니다.

실제 마이그레이션을 시작하기 전에, SCT와 DMS 에 대한 문서를 자세하게 읽는 것이 좋습니다. 또한 단계별 연습데이터베이스 마이그레이션 서비스 모범 사례 백서를 읽는 것이 좋습니다.

도구 사용에 대한 테스트를 위한 샘플 데이터베이스는 AWS Github 저장소에서 찾을 수 있습니다.

이 글은 여러분의 특정 상황에 필요한 모든 가능한 단계 또는 고려 사항을 설명하기 위한 것은 아니지만, SCT 및 DMS를 사용하여 상용 Oracle 데이터베이스의 구속을 어떻게 줄일 수 있는지에 대한 좋은 아이디어를 제공하기 위해 작성되었습니다. 마이그레이션에 행운과 행복이 가득하길!

더 자세한 것은 AWS Summit 2017 기술 세션 중 AWS DMS를 통한 오라클 DB 마이그레이션 방법 (발표 자료)동영상도 참고하시기 바랍니다.

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 양승도 솔루션즈 아키텍트께서 번역해주셨습니다.
sd-yang-photo

AWS 데이터베이스 마이그레이션, 2만회 돌파!

1년 전 AWS Database Migration Service 출시를 했을 때, 이미 1,000여 고객이 데이터베이스 이전 도구로서 DMS 서비스를 활용하고 있었습니다.

즉, AWS Database Migration ServiceSchema Conversion Tool (SCT)는 AWS 고객이 고가의 자체 데이터베이스와 데이터웨어 하우스에서 보다 비용 효율적인 Amazon Aurora, Amazon Redshift, MySQL, MariaDB PostgreSQL 같은 클라우드 기반 데이터베이스와 데이터웨어 하우스로 이동하고 있으며, 이를 통해 다운 타임을 최소화 한 상태에서 전환하게 되었습니다. 예를 들어 Amazon Aurora로 전환하면 상용 데이터베이스의 10 분의 1의 비용으로 MySQL과 PostgreSQL 호환 데이터베이스를 사용할 수 있습니다. Expedia, Thomas Publishing, Pega, Veoci 등 고객 사례는 AWS DMS 활용 사례에서 보실 수 있습니다.

20,000 데이터베이스 이전 달성
AWS 고객은 지금까지 AWS Database Migration Service 를 사용하여 20,000 건의  데이터베이스를 AWS로 이전하고 현재도 그 수는 늘어나고 있습니다. (2016 년 9 월에 10,000 건 기록).

지난해에도 DMS와 SCT 서비스에 몇 가지 새로운 기능을 추가했습니다.

  • 2016년 3월 – 8개 리전 정식 출시
  • 2016년 5월 – 전환 대상으로 Redshift 추가
  • 2016년 7월 – 지속적인 복제를 위한 고가용서 아키텍처 제공
  • 2016년 7월 – 전환 소스 및 타겟으로 SSL 엔드포인트 및 Sybase 엔진 지원
  • 2016년 8월 – Asia Pacific (Mumbai) , Asia Pacific (Seoul) , South America (Brazil) 리전 확장
  • 2016년 10월 – US East (Ohio) 리전 확장
  • 2016년 12월 – Oracle SSL 연결 기능제
  • 2016년 12월 – Canada (Central)와 Europe (London) 리전 확장
  • 2017년 1월 – 이벤트와 이벤트 구독 기능 추가
  • 2017년 2월 – Oracle and Teradata에서 Amazon Redshift 전환 지원

자세한 정보
데이터 베이스 마이그레이션을 위해서는  먼저 최근 온라인 세미나 및 상세한 기술 문서들을 참고하시기 바랍니다.

Migrating From Sharded to Scale-Up – 일부 고객은 스케일 아웃 전략을 통해 데이터베이스 샤딩으로 마이그레이션 효과를 극대화 하고 있습니다. 두 개 이상의 샤드를 하나의 Aurora 인스턴스에 정리 복잡성을 줄이고 신뢰성을 높이면서 비용 절감을 실현하는 방법에 대한 블로그 글, 세미나 동영상, 발표 자료를 참고 하시기 바랍니다.

Migrating From Oracle or SQL Server to Aurora – Oracle 또는 SQL Server와 같은 상용 데이터베이스에서 Aurora로 이전하고 있습니다. 관련 정보는 발표 자료동영상을 참고하시기 바랍니다.

그 밖에도 AWS Database Blog에 다양한 글이 있습니다.

기술 문서에도 다양한 정보를 제공하고 있습니다.

서울 Summit에서 만납시다!
오는 4월 19-20일 개최되는 AWS Summit 2017 서울 행사에서 다양한 데이터베이스 관련 세션을 마련하였습니다. 지금 등록하시고 많은 참여 바랍니다.

Jeff;

이 글은 AWS Database Migration Service – 20,000 Migrations and Counting의 한국어 요약입니다.

AWS Database Migration Service, 서울 리전 출시

AWS Database Migration Service는 기존 온-프레미스 데이터베이스를 AWS로 쉽고 안전하게 마이그레이션에 도움을 주는 클라우드 데이터 이전에 중요한 서비스입니다. 지난 3월 정식 서비스 개시 이후 오늘 부터 Asia Pacific (Seoul) 리전에서 사용가능합니다.

본 서비스는 Oracle에서 Oracle로의 동종 마이그레이션뿐 아니라 Oracle에서 Amazon Aurora 또는 Microsoft SQL Server에서 MySQL로의 마이그레이션과 같은 이기종 데이터베이스 플랫폼 간의 마이그레이션도 지원합니다. 또한 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SAP ASE(이전 Sybase ASE) 및 SQL Server를 포함해 지원되는 소스에서 Amazon Redshift로 데이터를 스트리밍하여 페타바이트 규모의 데이터 웨어하우스에서도 데이터 통합 및 용이한 분석이 가능합니다.

지난 7월 13일에는 몇 가지 신규 기능을 추가하였습니다. 지속적인 데이터 리플리케이션 기능을 추가하여, Multi-AZ 기능을 통해 좀 더 안정적인 리플리케이션을 제공합니다. 또한, SSL 엔드 포인트를 제공하여 좀 더 안전하게 정보를 제공할 수 있습니다. 좀 더 자세한 사항은 DMS 홈페이지DMS 기술 문서를 참고하시기 바랍니다.

AWS DMS 서비스 따라해 보기…

– AWS 코리아 마케팅팀;

AWS 데이터베이스 마이그레이션 서비스(DMS) 오픈!

여러분이 기존 환경에서 오라클, SQL서버, MySQL, MariaDB 및  PostgreSQL 데이터베이스를 운영하고 계시다면, AWS 클라우드로 이전하셔서 확장성이 높은 운영 효율적인 다양한 대용량 데이터 스토리지 옵션의 혜택을 누리실 수 있습니다.

그러면 어떻게 다운타임 없이 이전을 할 수 있을까요? 오늘 출시된 AWS Database Migration Service (DMS) 서비스가 바로 그 해답입니다. 작년 가을 AWS re:Invent 행사에서 미리 보기로 발표된 이후로 이미 우리 고객들의 1,000여개가 넘는 데이터베이스가 AWS로 이전하였습니다. 여러분도 바로 테라 바이트급 데이터베이스를 운영하는 도중이나 (신규 요구사항에 맞춤) 새로운 버전으로 업그레이드 하면서 라이브로 옮겨 보실 수 있습니다. 만약 클라우드로 옮기려고 하는 데이터베이스가 완전히 다른 엔진이라면 AWS Schema Conversion Tool 을 통해 스키마와 저장 프로시저를 새로운 환경으로 옮길 수 있습니다

AWS Database Migration Service는 AWS 상의 리플리케이션 인스턴스를 설정하여 동작하게 됩니다. 이 인스턴스는 기존 소스 데이터베이스에서 데이터를 업로드하고, 이전 대상 데이터베이스에 전송을 합니다. 이를 통해 최소한의 다운타임을 지원하는 리플리케이션 방식을 따라서 한번에 이전이 가능하다는 장점이 있습니다. DMS는 마이그레이션에 관련된 복잡한 문제들, 예를 들어 데이터 타입 변환, 데이터 플랫폼의 이전(오라클, Aurora 등)이 가능합니다. 또한, 리플리케이션 인스턴스 현황 및 헬스 체크 모니터링을 제공하며, 문제가 있을 때 알림을 보내고 필요하다면 자동으로 인스턴스를 대체할 수 있습니다. 

DMS는 다양한 이전 시나리오 및 네트워크 옵션을 제공합니다. 엔드 포인트가 AWS일 수도 있고, 기존 온-프레미스 환경일 수도 있습니다. 또한 EC2  인스턴스에 설치된 DB 혹은 RDS 인스턴스가 될 수도 있습니다. 소스 및 최종 이전 대상은 같은  Virtual Private Cloud (VPC)에 있거나, 두 개의 나눠진  VPC에서도 가능합니다. 여러분이 온-프레미스 데이터베이스를 이전하시려면, AWS Direct Connect.를 사용하여 전용 회선으로 연결하여 VPC 설정 후 사용 가능합니다.

데이터베이스 마이그레이션 하기
관리 콘솔에서 몇 번 클릭을 하기만 하면, 이전 작업을 시작할 수 있습니다. 먼저 이전을 원하는 데이터베이스를 선택하고, 스키마 이전, 리플리케이션 설정, 마이그레이션 시작을 하면 됩니다. 소스에서 이전이 완전히 완료가 되면, 애플리케이션에서 DB의 설정만 바꾸어 주면 됩니다.

AWS Database Migration Service 콘솔에서 DMS 를 클릭한 후, Create migration을 선택합니다.

콘솔에서는 마이그레이션 절차에 대해 간단하게 소개해 드립니다.

리플리케이션 인스턴스를 만들 각종 파라미터 값을 입력합니다.

이 글에서는 기존 VPC를 선택하고, Publicly accessible를 선택하지 않았습니다. 이전 대상 데이터베이스는 EC2 인스턴스에 있기 때문입니다.

리플리케이션 인스턴스가 만들어지면, 소스 및 최종 이동 대상 데이터베이스를 선택한 후   Run test를 선택합니다. 접속이 잘되는지 네트워크 이슈가 없는 지를 테스트해 볼 수 있습니다.

이제 실제 마이그레이션 작업이 진행되기 위해, Migration type을 설정하면, 기존 데이터, 이전 후 리플리케이션, 리플리케이션 등을 선택할 수 있습니다.

이제 Task Settings를 선택합니다. (LOBs는 Large Objects를 의미합니다).

마이그레이션 작업을 위해, Start/Resume를 선택하면 됩니다.

진행 사항을 보실 수 있으며, Table statistics를 통해 이전 사항을 확인할 수 있습니다. (아래 그림은 테스트 테이블입니다.)

이전이 완료되면, 간단한 테스트를 거쳐 애플리케이션의 DB 엔드포인트를 변경 한 후 배포하시면 됩니다.

AWS Database Migration Service는 다양한 선택 사항을 제공합니다. 예를 들어, 특정 테이블만 옮긴다던지, 여러 개의 다른 리플리케이션 작업을 할 수도 있고, 시간에 따라 작업을 활성화 시킬 수도 있습니다. 좀 더 자세한 사항은 DMS 기술 문서 (영문)을 참고하시면 됩니다.

여러분이 다양한 데이터베이스 세트를 옮기신다면, AWS Command Line Interface (CLI)나 the Database Migration Service API를 활용하시길 권장합니다.

가격 및 출시 리전
AWS Database Migration Service는 현재 US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore),  및 Asia Pacific (Sydney) 리전에 우선 출시되었으며, 향후 빠른 시일 내에 (서울 리전을) 비롯한 다른 리전에 출시될 예정입니다.

Jeff;

이 글은 AWS Database Migration Service의 한국어 번역입니다.