AWS DMS, MySQL 데이터베이스를 S3로 마이그레이션하기

AWS DMS

• AWS DMS는 아마존이 제공하는 서버리스 데이터 마이그레이션 서비스 상품이다. 이번 글에서는 운영 환경의 OLTP 데이터베이스에 대한 통계 지표 산출을 위해 ETL을 목적으로, 원본 데이터베이스의 데이터를 S3 버킷에 Parquet 형태로 복제하는 방법을 정리하였다.

복제 인스턴스 생성

• 가장 먼저 복제 인스턴스를 아래와 같이 생성한다.

AWS DMS 콘솔 접속
→ [복제 인스턴스] → [복제 인스턴스 생성]

# 복제 인스턴스 구성
→ 이름: foo-aurora-mysql-prod-replication-instance (입력)
→ 설명: foo-aurora-mysql-prod-replication-instance (입력)
→ 인스턴스 클래스: [dms.t3.medium] 선택
→ 엔진 버전: [3.4.6] 선택
→ 할당된 스토리지: 50 (입력)
→ VPC: (복제 인스턴스가 위치할 VPC 선택)
→ 다중 AZ: [프로덕션 워크로드(다중 AZ)] 선택
→ 퍼블릭 액세스 가능: (체크 해제)
→ [생성]

• 복제 인스턴스의 인스턴스 클래스의 메모리가 부족할 경우 OOM 오류가 발생할 수 있다. 원본 데이터베이스의 가장 크기가 큰 테이블의 크기를 감안하여 사양이 부족하지 않도록 적절히 선택해야 한다.

소스 엔드포인트 생성: MySQL

• 원본 데이터베이스에 접근할 소스 엔드포인트를 아래와 같이 생성한다.

AWS DMS 콘솔 접속
→ [엔드포인트] → [엔드포인트 생성]

# 엔드포인트 유형
→ 엔드포인트 유형: [소스 엔드포인트] 선택
→ RDS DB 인스턴스 선택: (체크)
→ RDS 인스턴스: (원본 데이터베이스 선택)

# 엔드포인트 구성
→ 엔드포인트 식별자: foo-aurora-mysql-prod-source-endpoint (입력)
→ 소스 엔진: [Amazon Aurora MySQL] 선택
→ 엔드포인트 데이터베이스에 액세서: [수동으로 액세스 정보 제공] 선택
→ 포트: 3306 (원본 데이터베이스 리스너 포트 입력)
→ Secure Socker Layer(SSL) 모드: [없음] 선택
→ 사용자 이름: (원본 데이터베이스 username 입력)
→ 암호: (원본 데이터베이스 password 입력)

# 엔드포인트 연결 테스트(선택 사항)
VPC: foo-prod-vpc (선택)
복제 인스턴스: foo-aurora-mysql-prod-replication-instance (선택)
[테스트 실행]
[엔드포인트 생성]

• 만약, 뒤에 생성할 데이터 마이그레이션 태스크의 마이그레이션 유형이 1회성 복제가 아닌 변경 사항을 지속적으로 변경하는 CDC일 경우 RDS 인스턴스는 반드시 리드가 아닌 라이터 인스턴스로 지정해야 한다. 또한 라이터 인스턴스에 아래 파라메터가 활성화되어 있어야 한다.

# 데이터베이스 인스턴스 재시작 필요
binlog_format = ROW

대상 S3 버킷 생성

• 원본 데이터베이스가 복제될 대상 S3 버킷을 생성한다.

대상 엔드포인트 정책 생성: S3

• 대상 엔드포인트 생성에 앞서 아래와 같이 정책을 생성한다. 대상 엔드포인트에서 앞서 생성한 S3 버킷에 접근할 수 있는 권한을 제공하는 것이 목적이다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:PutObjectTagging"
      ],
      "Resource": [
        "{앞서 생성한 S3 버킷의 ARN}/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "{앞서 생성한 S3 버킷의 ARN}"
      ]
    }
  ]
}

대상 엔드포인트 생성: S3

• 원본 데이터베이스를 S3 버킷으로 복제할 대상 엔드포인트를 아래와 같이 생성한다.

AWS DMS 콘솔 접속
→ [엔드포인트] → [엔드포인트 생성]

# 엔드포인트 유형
→ 엔드포인트 유형: [대상 엔드포인트] 선택

# 엔드포인트 구성
→ 엔드포인트 식별자: foo-aurora-mysql-prod-target-endpoint-s3 (입력)
→ 대상 엔진: [Amazon S3] (선택)
→ 서비스 액세스 역할 ARN: (앞서 생성한 대상 엔드포인트 역할의 ARN 입력)
→ 버킷 이름: (앞서 생성한 버컷의 이름 입력) (입력)
→ [새 설정 추가] → 설정: [DataFormat] (선택) → parquet (입력)

# 엔드포인트 연결 테스트
→ VPC: (복제 인스턴스와 동일한 VPC 선택)
→ 복제 인스턴스: foo-aurora-mysql-prod-replication-instance (선택)
→ [테스트 실행] 후 정상 작동 확인
→ [엔드포인트 생성]

데이터 마이그레이션 태스크 생성: MySQL to S3

• 이제 셋업을 위한 마지막 차례이다. 데이터 마이그레이션 태스크를 아래와 같이 생성한다.

AWS DMS 콘솔 접속
→ [데이터베이스 마이그레이션 태스크] → [태스크 생성]

# 태스크 구성
→ 태스크 식별자: foo-aurora-mysql-prod-data-migration-task (입력)
→ 복제 인스턴스: foo-aurora-mysql-prod-replication-instance (선택)
→ 소스 데이터베이스 엔드포인트: foo-aurora-mysql-prod-source-endpoint (선택)
→ 대상 데이터베이스 엔드포인트: foo-aurora-mysql-prod-target-endpoint (선택)
→ 마이그레이션 유형: [기존 데이터 마이그레이션] (선택)

# 태스크 설정
→ 대상 테이블 준비 모드: [대상에서 테이블 삭제] (선택)
→ 전체 로드 완료 후 태스크 중지: [중지 안 함] (선택)
→ 복제에 LOB 열 포함: [LOB 열 포함 안 함] (선택)
→ [태스크 생성]

# 테이블 맵핑
→ [새 선택 규칙 추가]
→ 스키마: [스키마를 입력하십시오] 선택
→ 스키마 이름: (복제할 스키마를 입력)
→ 테이블 이름: % (입력)
→ [태스크 생성]

• 대상 엔드포인트가 S3일 경우, 지속적인 복제보다는 특정 주기의 1회성 복제가 적합하다. 지속적인 동기화를 원한다면 대상 엔드포인트로 Amazon Redshift를 고려해야 한다.

데이터 마이그레이션 태스크 실행: MySQL to S3

• 모든 셋업을 완료했다. 이제 최초로 데이터 마이그레이션 태스크를 실행할 차례이다.

AWS DMS 콘솔 접속
→ [데이터베이스 마이그레이션 태스크]
→ (앞서 생성한 태스크 체크)
→ [작업] → [시작]

• 테스트 결과 약 40GB 크기의 데이터베이스를 S3로 마이그레이션하는데 약 15분이 소요되었다. 대상이 되는 S3 버킷에 각 테이블 이름이 폴더 이름이 되어 완전한 복수개의 Parquet 파일로 복제된 것을 확인했다.

코드 레벨로 태스크 실행: Kotlin

• AWS DMS의 단점으로 태스크의 실행에 대한 스케쥴링 기능을 제공하지 않는다. 방법은 코드 레벨로 태스크를 실행시키는 것인데 Kotlin으로는 아래와 같이 실행할 수 있다. 애플리케이션에서 스케쥴링하는 방법 또는 펑션의 형태로 AWS Lambda로 실행하면 된다.

val client = AWSDatabaseMigrationServiceClientBuilder.standard().build()
val request = StartReplicationTaskRequest()
    .withReplicationTaskArn("{실행할 태스크의 ARN}")
    .withStartReplicationTaskType("reload-target")
val response = client.startReplicationTask(request)

사용 소감

• 현업 부서 및 경영진에 필요한 통계 지표와 리포트 작업을 위해 사용했고, Amazon Athena에 연동하여 확인 쿼리 성능은 상당히 훌륭하다. 원본 데이터베이스에서 인덱스가 생성되지 않은 컬럼에 대해 풀스캔 쿼리를 실행한 결과 원본에서 수분이 소요되던 것이 수초만에 조회되었다.