실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
최홍식
Solutions Architect / Amazon Web Services
실전! AWS 기반
데이터베이스 마이그레이션

목차
• AWS 데이터베이스 마이그레이션
• 데이터베이스 마이그레이션 계획 수립
• AWS DMS를 이용한 실전 마이그레이션
• AWS DMS 마이그레이션 팁
• 고객 사례

AWS 데이터베이스 마이그레이션

데이터베이스 마이그레이션 사용 사례
현대화 마이그레이션 복제
• 리전 간 읽기 복제본 생성
• 클라우드에서 분석 실행
• 실행 개발/ 테스트 및 프로덕션을
동기화 상태 유지
• 이전 데이터베이스
엔진에서 데이터 추출 및
변환
• 어플리케이션 코드
업데이트
• 비지니스 어플리케이션을
Amazon RDS로 마이그레이션
• 데이터 웨어하우스를 Amazon
Redshift로 마이그레이션
• 데이터베이스 업그레이드 통합
및 보관

AWS로 DB 마이그레이션의 일반적인 과정
1. AWS 계정 생성
2. Region, AZ 선택 후 Virtual Private Cloud (VPC) 생성
3. VPN 또는 Direct Connect를 통한 AWS 접속
4. EC2 인스턴스에 새로운 DB 설치 및 설정
5. 기존 DB의 데이터 S3로 백업
6. 기존 DB 셧 다운
7. 새로운 EC2 DB 인스턴스에 백업 데이터 복구
8. 어플리케이션을 위한 EC2 인스턴스 설정
9. 접속을 기존 Database에서 AWS의 데이터베이스로 전환

AWS로 DB 마이그레이션의 일반적인 과정의 개선
1. AWS 계정 생성
2. Region, AZ 선택 후 Virtual Private Cloud (VPC) 생성
3. VPN 또는 Direct Connect를 통한 AWS 접속
4. EC2 인스턴스에 새로운 DB 설치 및 설정
5. 기존 DB의 데이터 S3로 백업
6. 기존 DB 셧 다운
7. 새로운 EC2 DB 인스턴스에 백업 데이터 복구
8. 어플리케이션을 위한 EC2 인스턴스 설정
9. 접속을 기존 Database에서 AWS의 데이터베이스로 전환

데이터베이스 마이그레이션은 ?
6<
1001001
0101001
1000100

AWS Database Migration Service
AWS 로 데이터베이스
마이그레이션

DMS 와 SCT?
AWS Database Migration Service (DMS) 는 데이터베이스나
데이터 웨어하우스를 AWS로 빠르고 안전하게 마이그레이션
또는 복제를 도와주는 서비스 입니다.
AWS Schema Conversion Tool (SCT) 는 데이터베이스 및 데이터웨어
하우스의 스키마를 오픈소스 엔진 또는 AWS에서 제공하는 서비스로
(Aurora and Amazon Redshift) 변환을 도와드립니다.

SCT를 이용한 스키마 변환
데이터웨어 하우스를 현대화하고
Amazon Redshift로 마이그레이션
(OLAP) Amazon Redshift
데이터베이스 영역 현대화
(OLTP)
Amazon Aurora
Amazon RDS

SCT를 이용한 테이블, 뷰, 코드의 변환 지원
시퀀스
사용자 정의 타입
패키지
스토어드 프로시저
함수
트리거
스키마
테이블
인덱스
뷰
소트, 분산 키

DMS를 이용한 마이그레이션 및 복제
대상
Amazon
DynamoDB
Amazon Redshift
Amazon S3
원본
동종 혹은 이종간
Amazon Aurora
Amazon Aurora
Amazon S3

데이터베이스 마이그레이션
계획 수립
(Oracle to RDS PostgreSQL)

1. 계획 단계
마이그레이션 대상 분석
1. 타임 라인, 공수 산정을 위한 마이그레이션 복잡성 분석:
• 스키마 변화 평가와 데이터베이스 오브젝트 분석
• 재 실행률 (redo) 와 TPS 예상 source
• PostgreSQL의 제한 사항으로 인한 영향 분석
(partitions, Materialized views, plan stability )
• 일반적인 마이그레이션시 발생 문제 숙지
(https://wiki.postgresql.org/wiki/Oracle_to_Postgres_Conversion)
2. 파일럿 범위 확인
3. 마이그레이션 수행 시 발생된 이슈와 해결 방안을 이용한 더 복잡한 마이그레이션 진행

1. 계획 단계
스키마 마이그레이션 복잡도 분석 ( 예 )
요소 포인트 Comment
Tables 0.5 Non-partitioned테이블은 자동 변환 ( Data type, Character set 유의)
Materialized Views 6 Fully refreshed Mviews 만 지원
Triggers 6 리뷰 및 로직 재작성
PL/SQL procedures 8 리뷰 및 로직 재작성
PL/SQL packages 30
3개 이상의 procedures , functions으로 만들어진 Packages의 경우
리뷰 및 로직 재작성
DB_link 2 postgres_fdw 익스텐션을 통한 DBLinks 전환
Partitions 1
모든 child partitions수동 생성
Functions과 triggers를 이용한 Partition Architecture 적용
LOB 2 LOB Columns들은 추가적 설정 필요

1. 계획 단계
마이그레이션 이슈를 풀기 위한 방안들
1. 응용 프로그램에서 실제 사용되고 있는 것 확인
o Top SQLs, ASH, DBA_HIST_% views를 통한 SQLs/Tables 최근 액세스 정보
2. 가능한 비지니스 로직을 어플리케이션으로 이동. PL/pgSQL 사용:
o 테이블 감사 처리, 마지막 업데이트 타임 스템프를 업데이트 하는 트리거 함수
3. 마이그레이션 전에 레거시 나 보관된 데이터 제거
o Amazon S3 나Amazon Glacier를 통한 이전
4. 데이터 복제, ETL, 레포팅 등과 같은 AWS의 기본 기능 활용
o 증분 데이터를 지속적으로 시스템과 맞추기 위한 DMS CDC

2. 마이그레이션 단계
1. Amazon CloudWatch 메트릭과 DMS 로깅 필수
2. 어플리케이션 설정 : UTC로 default time zone settings 설정
(JVM Arg <jvmarg value="-Duser.timezone=UTC“)
3. Partition 정리 필요
4. 공통적 요구사항 해결을 위한 DBA 작업 자동화
o DB 계정관리
o Connection pool client (C3P0)
o Secure JDBC Driver
o 표준 모니터링 툴킷(Amazon RDS Events notifications)
5. Vacuuming은 PostgreSQL 의 최적 성능을 위해 매우 중요한 요소
모범 사례 대로..

테스트 및 확인 전략
• 대상의 스냅샷으로 부터 새로운 인스턴스 생성
o 기능 테스트
o 부하 테스트
o 성능 테스트
• 테스트 전에 triggers, indexes 등 활성화
o CREATE TRIGGER table BEFORE INSERT OR UPDATEON table FOR EACH
ROWWHEN (session_user != 'replication_user')EXECUTE PROCEDURE audit ();
• Data validation 활성화 (SOX/ 보안 준수에 필수)
• DMS Task assessment 를 통한 데이터 타입 변환 문제 확인
• PostgreSQL에서 Query plan은 안정적이 않음(Index 나 rewrite query 사용)

DMS 사용시 Amazon RDS PostgreSQL 권장 파라미터
• shared_preload_libraries ='pg_stat_statements,auto_explain,pgaudit’
• log_statement = ddl
• log_connections =on
• log_disconnections =on
• log_lock_waits = on
• log_min_duration_statement = 5000
• rds.force_ssl = True (Infosec)
• Huge_pages = on (larger instance types)
• random_page_cost =1
• rds.logical_replication = 1 ( replication for rollback)
• Max_parallel_workers_per_gather = number of CPUs (Enable Parallelism)
• idle_in_transaction_session_timeout = 필요에 따라

3. 전환 단계
Amazon RDS Oracle을 통한 Fail back전환 전략 마련
AWS DMS
Oracle RDS
온프레미스
Oracle
DB
AWS DMS
1
2
온프레미스DB 을 RDS
PostgreSQL로
RDS PostgreSQL을 RDS Oracle
App1 App2
1
2
Amazon RDS
PostgreSQL

AWS DMS를 이용한
실전 마이그레이션

1. 준비 단계
원본 데이터베이스 준비사항 – Oracle
사전요구 사항
• Oracle 데이터베이스를 AWS DMS 에서 원본으로 사용
(https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/CHAP_Source.Oracle.html)
• Oracle 11g (11.2.0.3.v1이상) , 12.1 버전 이하
• ARCHIVELOG Mode 활성화
• Supplemental Logging 구성
• 오라클 사용자 계정 권한 설정
• Change Data Capture (CDC)를 위한 LogMiner(또는 Oracle Binary Reader) 사용 구성
• 제한 사항 확인
팁
• 데이터베이스별 parameter group 사용
• DMS 세션 모니터링과 task들의 병렬 처리 조절
• Oracle Undo 사용량, wait events 주의 깊게 모니터링 ( Snapshot 1555 error )

1. 준비 단계
대상 데이터베이스 준비사항 – PostgreSQL
사전요구 사항
• PostgreSQL 데이터베이스를 AWS DMS 에서 대상으로 사용
(https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/CHAP_Target.PostgreSQL.html)
• PostgreSQL 버전 9.4 이상
• session_replication_role 설정
• 제한 사항 확인
팁
• 데이터베이스별 parameter group 사용
• "Auto Minor Version Upgrade" 사용 않음
• Multi-AZ와 Backup retention 은 마이그레이션 이후 활성화
• Extensions 사용: pg_stat_statements, pg_audit, pgstattuple, pg_hint_plan,
pg_repack, log_fdw,auto_explain

2. SCT 마이그레이션 평가 보고서
• 원본과 대상 데이터 베이스 엔진,
Amazon RDS Mysql,
RDS PostgreSQL및 Aurora와
마이그레이션 호환성
• 최상의 대상 데이터베이스 엔진
추천
• 마이그레이션을 위한 세부 내역
제공

3. AWS DMS 구성
복제
인스턴스
원본 대상
AWS DMS의 구성
• 원본, 대상 엔드포인트
• 복제 인스턴스 준비

3. AWS DMS 구성
• 작업 방법 선택
• 하나의 복제 인스턴스에서 복수
작업 실행
• 테이블 매핑 사용
• 선택 룰 – 스키마 및 테이블 선택
• 변환 룰 – 스키마, 테이블, 컬럼 변경
• 필터 적용
• 조건에 따른 컬럼 필터링
작업 생성

3. AWS DMS 구성
작업 설정

3. AWS DMS 구성
테이블 매핑

3. AWS DMS 구성
테이블 변환

4. Oracle 에서 PostgreSQL 마이그레이션 Playbook
• Oracle 에서 Amazon Aurora(PostgreSQL)
마이그레이션 상세 가이드
• 각 기능 별 비교
SCT DMS Playbook
스키마 데이터 모범 사례
http://bit.ly/dbmig

AWS DMS
마이그레이션 팁

AWS DMS 마이그레이션 팁
1.1 TB 이상의 큰 테이블 마이그레이션시 ORA-01555 (Snapshot too old) 발생
2.Large Objects (LOBs) 마이그레이션
3.원본 데이터베이스의 높은 TPS 사용
4.데이터 타입 변환
5.UTF8 설정

1. 1 TB 이상의 큰 테이블 마이그레이션
발생내용
ORA-01555: snapshot too old: rollback segment number %n with name "%segname" too
small
이유
• Oracle 은 기본적으로 undo segments 이용한 read consistency mechanism 사용
• DMS는 Full load 시 전체 Table에 대한 “select * “
오라클 설정
• Long running 쿼리 : 시스템의 DML load 가 적을 때 수행
• Rollback segment (undo) size 추가

• 다수의 Task로 나눠서 작업
1. PK / Data range를 통한 분리
2. Full load를 위한 Task들 동시 실행
3. 전체 테이블 대상 하나의 CDC 실행
(사용자 지정 시간)
DMS 의 Table Mapping Filter 사용
• Active DataGuard를 통한 원본 영향 제거
1. 동기화가 멈춘 시간부터 원본으로부터
동기화 준비
2. Standby : Full Load 실행
3. Primary : CDC 실행 (사용자 지정 시간)
마이그레이션 원본

- 3TB 이상의 4개 Tables, 각 테이블은 60 TPS ( 대략 시간당 150,000 updates ) 사용 중예)
- PostgreSQL 로 마이그레이션 시 “Snapshot too old”
TPS 별 분기 방안
Low (3 to 6 TPS) • Active Dataguard standby를 full load 소스로 사용
• Standby가 만들어지고 실시간 데이터를 수집하기 전에 CDC 시작
High (~60 TPS) • 테이블당 10개의 replication instance를 통하여 ( 대략 테이블당 20개 Tasks )
Full Load 와 100 만개 row에 대한 CDC 동시 실행
• 테이블을 나눠서 동시 진행

2. LOBs (Large Objects)성능 이슈
필수
• LOBs 마이그레이션 시, Table 은 반드시 PK 또는 Unique index 포함.
( LOB 마이그레이션은 2 개 프로세스로 진행 )
해결방안
• LOBs 제외한 전체 row 부터 마이그레이션.
• 원본에서 LOB 데이터를 쿼리하고 LOB 데이터로 대상 테이블 업데이트.

1. LOB 값 null 아니면 원본에 LOB Lookup
2. OCILobRead2 이용.
- 원본의 첫번째 chunk 의 “full lob chunk size” 읽음
( default 는 64 KB)
- 타겟에 사이즈 전달
- 다음 Chunk 읽고, 타겟에 전달 ( LOB를 모두 읽을
때 까지 지속적 )
전체 LOB
1. MAZ LOB 사이즈 64KB 이하
- LOBs를 array mode로 읽음
(Default array size 1000)
2. MAX LOB 사이즈 64KB 이상
- LOB <= 64KB : 마이그레이션
- LOB > 64KB
CLOBs : Getdata(),
BLOBs : OCILobRead2
LOB 사이즈 별 대응

- 2 TB 데이터베이스마이그레이션시 500 GB의 LOBs 포함.예)
- 128KB 미만, 5MB 의 LOBs 가 섞여 있음.
LOB 크기 대응 방법
64 KB 미만 limited LOB mode 실행 및 최대 LOB 크기 설정.
64 KB ~ 128 KB 작은 테이블들은 limited LOB mode 실행.
수동으로 static LOB 마이그레이션.
128 KB 이상 아키텍처 변경하고 LOB를 S3로 이동.
( 큰 데이터는 RDB아닌 S3에 저장하는 방식으로 변경)

1.PK가 존재 하지 않고 LOBs를 포함한 테이블 확인
• Select owner,table_name FROM dba_tables where owner=‘schema_name' and
table_name NOT IN (SELECT table_name FROM dba_constraints WHERE
constraint_type ='P' and owner='schema_name ') and table_name in (select DISTINCT
table_name from dba_tab_cols where data_Type IN ('CLOB', 'LOB', 'BLOB') and owner
='schema_name ');
2.Oracle 시스템 테이블을 사용한 LOB 최대 크기 확인
• Select 'select (max(length(' || COLUMN_NAME || '))/(1024)) as "Size in KB" from ' ||
owner || '.' || TABLE_NAME ||';' "maxlobsizeqry" from dba_tab_cols where
owner=‘schema_name' and data_type in ('CLOB','BLOB','LOB’);
3.Stream Buffer 설정 (StreamBufferCount, StreamBufferSizeInMB, CtrlStreamBufferSizeInMB)
LOBs 마이그레이션시 중요한 사항

3. 원본 데이터베이스의 높은 TPS 사용
CDC 과정
원본 ( Select * ) -> Replication 인스턴스 메모리 (데이터) -> CSV 생성( comma Delimited ) 준비
-> 대상 PostgreSQL에 copy 명령 ( Replication 인스턴스 -> 대상 인스턴스 )
SORTER
IncomingStream
OutgoingStream
원본 대상

3. 원본 데이터베이스의 높은 TPS 사용
1. 원본엔진에서 변경 분 읽고 배치 생성
2. 대상 배치에 변경된 것과 함께
intermediate net changes 테이블 생성
3. net changes algorithm을 통해 변경 분
압축하고 적용
( 모든 insert, update, delete 같은 순서로)
배치 적용
1. DMS 기본
2. 원본과 동일한 적용 순서
3. 캐시 된 변경 사항 적용
4. 대상에 constraints 조건 적용
트랜잭션 적용

4. 데이터 타입 변환
동작방식
1. 원본 데이터 타입을 DMS 의 데이터 타입(SQLite)으로 변경
2. DMS의 데이터 타입(SQLite)을 대상 데이터 타입으로 변경
이슈내용
• Oracle 의 Number 가 PostgreSQL의 DOUBLE로 변경, 소수점 이후 0 붙음
( 컬럼의 값 : 2045 -> 2045.00 )
해결방안
1. 테이블이 적은 경우: Trigger 이용한 INT 나 BIGINT로 타겟에서 변경
2. 테이블이 많은 경우: 전체 Load 후 column definition 변경, CDC를 이용한 원하지 않는
소수점 제거

5. UTF8 설정
이슈내용
1. 현재 DMS는 4byte UTF8 마이그레이션 미지원
2. 마이그레이션 시 DMS 는 UTF-16 로 변경
해결방안
1. 원본에서 잘못된 캐릭터 제거 후 마이그레이션
2. 잘못된 캐릭터들을 파악하고, 마이그레이션 하는 동안 추가 connection attribute로 변경
4 Byte UTF8 컬럼 파악방안
• SELECT <Primary_Key_Column>||' '||<Problematic Column> FROM Table name WHERE
REGEXP_LIKE(<Problematic Column>, UNISTR('[D800-DFFF]'));

5. UTF8 설정
원본에서의 캐릭터 변환 방안
CREATE OR REPLACE FUNCTION remove_supp_char(v_string_in IN VARCHAR2) RETURN
VARCHAR2 IS
BEGIN
-- This function removes all 4-byte characters from an input string.
-- Used to convert AL32UTF8 4-byte character set to UTF-8 3-byte character set without
errors.
RETURN REGEXP_REPLACE(
v_string_in, '['
|| UNISTR('D800DC00')
|| '-‘ || UNISTR('DBFFDFFF')
|| ']', '');
END;
update <table_name> set <problematic_column>=remove_supp_char(problematic_column) ;

5. UTF8 설정
CSSCAN 이용
1. CSSCAN실행을 통한 4 Byte UTF8 캐릭터의 row ID 조회
• csscan TABLE='SCHEMA_NAME.TABLE_NAME' FROMCHAR=AL32UTF8
TOCHAR=UTF8 PROCESS=4 ARRAY=1024000 LCSD=Y LCSDDATA=ALL
2. 4 Byte UTF8 캐릭터를 바꾸기 위해 추가적 connect attribute 설정
ReplaceChars=EDA0BD,3F,EDB18D,3F,EDB89C,3F,EDB080,3F

고객 사례

Trimble 사례 (Oracle to RDS PostgreSQL)
• North American DB
6.5 TB + 매달 22GB 증가
• European DB
4.6 TB + 매달 44GB 증가
• 비용 절감, 가용성, 확장성
• SCT 평가레포트를 통한
마이그레이션 공수 확인
• 매우 간단하고 신속한 작업
http://amzn.to/2tW2Dei
- Todd Hofert, Director of
Infrastructure Operations, Trimble

본 강연이 끝난 후
https://aws.amazon.com/ko/dms/getting-started/
http://amzn.to/2tSsQuy
• DMS 사용 설명서 – Aurora, DynamoDB, Redshift
• SCT 설치 및 사용 설명서
• Oracle to Amazon Aurora (PostgreSQL)
http://bit.ly/dbmig
https://aws.amazon.com/ko/dms/free-dms/

AWS Summit 모바일 앱과 QR코드를
통해 강연 평가 및 설문 조사에 참여해
주시기 바랍니다.
내년 Summit을 만들 여러분의 소중한
의견 부탁 드립니다.
#AWSSummit 해시태그로 소셜 미디어에 여러분의 행사
소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로
공유될 예정입니다.
여러분의 피드백을 기다립니다!

실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018

More Related Content

What's hot

Similar to 실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018

More from Amazon Web Services Korea

실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018