AWS 기존 IDC(MySQL)에서 RDS(MySQL)로 Migration 하기

안녕하세요.

금일은 IDC에서 AWS RDS로 Migration 하는 방법 및 테스트 결과를 블로깅 하도록 하겠습니다.

의식 흐름대로 테스트 및 글이 두서가 없습니다. 바쁘신 분은 결과만 보세요.

---------------------------------------------------------------------------------------------------------------------------------------

테스트 결과

MySQL 5.6.27 / sql File Size 4.5GB(wiki page .sql dump), DB Size 10 GB(단일 테이블 3,800만 row) / Full Dump 진행

(참고 - https://dumps.wikimedia.org/enwiki/latest/)

별첨. EC2(m4.10xlarge, 10G Network) -> RDS(t2.micro, Low Network, 100GB, 300 IOPS)  / 713min 소요

1. EC2(m4.10xlarge) -> RDS(m4.10xlarge, 10G Network, 100GB, 300 IOPS)  / 235min 소요

2. EC2(m4.10xlarge) -> RDS(m4.2xlarge, High Network, 100GB, 1000 PIOPS)  / 94min 소요

3. EC2(m4.10xlarge) -> RDS(m4.10xlarge, High Network 500GB, 5000 PIOPS)  / 67min 소요

(Default 기준 AWS RDS(MySQL) 최대 성능 IOPS 2000~2500, Throughput 80MB/s)

Mysql->RDS 데이터 이관(Default)에서 중요한 수치는 이관 대상 RDS의 IOPS 이며, 그 최대 IOPS 수치는 5000입니다.

그 외 Network Bandwidth, CPU, Memory는 크게 중요하지 않습니다.

---------------------------------------------------------------------------------------------------------------------------------------

Migration은 기존 서비스 유지하거나 점검 시간을 두어 진행하는 두 가지 방법이 있습니다. 

첫 번째, 기존 서비스 유지하면서 Migration 하는 방법은 sql dump file을 EC2로 업로드하고 RDS로 데이터를 옮긴 뒤, IDC MySQL에서 RDS로 Read Replica 설정 후 End-Point를 RDS로 넘기는 방법입니다. 다운타임은 없지만 데이터 정합성과 Master DB의 부하 등 예상하지 못한 문제가 발생될 수도 있습니다.

두 번째, 점검 시간 뒤 진행할 시에는 sql dump file을 압축한 뒤 EC2로 업로드한 후 RDS로 이관하면 됩니다. 다운타임은 발생하지만, 데이터 정합성이 보장되며 기타 문제가 발생할 가능성이 적습니다.

Migration 시간에 영향을 주는 항목은 Network, CPU, Memory, IOPS 입니다. 

위 방법은 AWS Document에 자세히 나와있습니다.

(참고 - http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.html)

그럼 데이터를 RDS로 이관하고 싶은데, 얼마나 시간이 걸릴지 궁금합니다. 

AWS에서는 500GB의 Oracle Data 이관 과정 및 결과를 SlideShare에 공유해놨습니다. 결과는 압축된 SQL 파일(170GB, 실 데이터 500GB)을 RDS 이관까지 6시간이 소요 됐다는 내용입니다. EC2에서 RDS까지는 3시간이 소요됐습니다. 500GB의 데이터라도 Data row count, VM Type 등에 따라 내용은 달라질 수 있습니다.

(참고 - http://www.slideshare.net/AmazonWebServices/dat308-28616289)

아래 문서를 보면 EC2 Instance -> RDS Data Import 시 VM CPU, I/O, Network에 따라 수행 성능이 영향을 받는다고 설명되어 있습니다. 그럼 제일 중요한 지표는 무엇일까요? 

(참고 - https://d0.awsstatic.com/product-marketing/Aurora/Aurora_Export_Import_Best_Practices_v1-3.pdf)

제일 중요한 지표를 알아보기 위해 테스트를 진행해보도록 하겠습니다. 또한 Oracle이 아닌 MySQL 기반의 데이터를 알고 싶습니다. MySQL Client에서 Network 병목이 없음을 가정하기 위해 10G Tpye을 선택해 테스트했습니다.

(참고 - http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html)

MySQL 5.6.27 / sql File Size 4.5GB(wiki page .sql dump), DB Size 10 GB(단일 테이블 3,800만 row) / Full Dump 진행

(참고 - https://dumps.wikimedia.org/enwiki/latest/)

결과

별첨. EC2(m4.10xlarge) -> RDS(t2.micro, Low Network, 100GB, 300 IOPS)  / 713min 소요

1. EC2(m4.10xlarge) -> RDS(m4.10xlarge, 10G Network, 100GB, 300 IOPS)  / 235min 소요

2. EC2(m4.10xlarge) -> RDS(m4.2xlarge, High Network, 100GB, 1000 PIOPS)  / 94min 소요

3. EC2(m4.10xlarge) -> RDS(m4.10xlarge, High Network 500GB, 5000 PIOPS)  / 67min 소요

아래는 각 테스트에 대한 Network, IOPS, DIsk Queue 사용률입니다. CPU/Memory는 의미가 없어 배제했습니다.

먼저 EC2(m4.10xlarge) -> RDS(m4.10xlarge, 100GB, 300 IOPS)를 확인해봅시다.

첫 번째, Network Bandwidth

X축 11:45분~15:45분까지 DB 이관 시간

11:45분~12:30분, 총 45분동안 .sql 파일이 RDS로 전송된 듯 합니다.

대충 계산하면 45min*60sec*3MB) / 2 = 4000MB(4GB)로 .sql file size가 나오네요.

두 번째, Disk IOPS

11:45분부터 Disk IOPS가 발생되었다. mysql은 block 단위로 수행된다. 12시30분까지 꾸준히 진행되다가 밀립니다.

버스팅으로 괜찮은 성능의 IOPS가 나오다가 버스팅 크레딧 소모로 100GB의 기준 성능 300으로 낮아졌습니다.

(참고 - http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)

세 번째, Queue Depth(FIFO Queue)

파일 전송은 대략 45분만에 끝났으나, Disk IOPS에서 병목이 발생해서 결과가 늦어진 듯 보입니다.

그럼 RDS Type이 낮음에도 불구하고 성능이 빨랐던 비교대상 EC2(m4.2xlarge) -> RDS(m4.2xlarge, 100GB, 1000 PIOPS)를 확인해봅시다.

첫 번째, Network Bandwidth

Disk IOPS를 올렸으나, Network은 3MB/S에서 점차 감소하며 1번 테스트와 비슷한 모양을 보여줍니다. 

결국 VM의 Network Type과 IOPS는 MySQL Application Network에 영향을 끼치는 요소는 아닌 듯 합니다.

두 번째, Disk IOPS

PIOS 1000으로 일관적인 그래프

세 번째, Queue Depth

이번 테스트 역시 IOPS가 밀려서 Surge Queue가 발생했으나 1번 테스트보단 준수한 수치입니다.

Write Throughput은 40MB/s

그렇다면 MySQL Client Application에서 3MB/S도 제대로 성능을 내지 못하는 것인가? 아니면 RDS IOPS로 인해 밀린 것인가? 아니면 RDS MySQL Application의 IOPS 한계인가?

마지막으로 테스트를 해봅니다. 돈이 없지만, 일단 결과를 내야하니...

EC2(m4.10xlarge) -> RDS(m4.10xlarge, 500GB, 5000 PIOPS) / 67min 소요

첫 번째, Network Bandwidth

IOPS를 높여도 3MB/s 수준은 변함 없습니다. 그렇다면 MySQL Client의 한계가 3MB/s로 보입니다.

두 번째, Disk IOPS

PIOPS 5000으로 진행했으나, 2500 이상 올라가지 않습니다. 어디서 Bottleneck이 있는걸까.. 

세 번째, Queue Depth

이전 테스트보단 좀 더 나아졌지만 Disk Queue는 4정도 수치로 계속 밀림.

Write Throughput은 80MB/s

결론, RDS Migration에서 가장 중요한 요소는 Disk IOPS다. Network 및 CPU, Memory는 크게 중요하지 않습니다.

본 테스트에서 RDS MySQL Server Application IOPS 한계는 2500, Write throughput은 80MB/s이었으며, EC2 MySQL Application Client는 3MB/s 수준의 한계를 보였습니다. 

테스트의 모든 설정은 Default이며, RDS에서 MySQL Configure는 VM Type에 따라 최적으로 구성되어 있는 것으로 알고 있습니다. 

실제 AWS RDS PIOPS 구축 기준으로 기대했던 퍼포먼스는 IOPS 5000, throughput 125MB/s 이상이었습니다. 그렇다면 MySQL Application 성능의 한계로 예상됩니다. 

초당 2500 / 80MB/s 

결국 MySQL 데이터 이관은 Disk IOPS 및 Through put이 가장 의미있는 수치라고 볼 수 있습니다.

다만 해당 내용은 결과를 바탕으로 한 추론이니 참고로 생각해주시기 바랍니다.

아래 데이터가 실제 결과 수치입니다.

MySQL 5.6.27 / sql File Size 4.5GB(wiki page .sql dump), DB Size 10 GB(단일 테이블 3,800만 row) / Full Dump 진행

결과

별첨. EC2(m4.10xlarge) -> RDS(t2.micro, 100GB, 300 IOPS)  / 713min 소요

1. EC2(m4.10xlarge) -> RDS(m4.10xlarge, 100GB, 300 IOPS)  / 235min 소요

2. EC2(m4.10xlarge) -> RDS(m4.2xlarge, 100GB, 1000 PIOPS)  / 94min 소요

3. EC2(m4.10xlarge) -> RDS(m4.10xlarge, 500GB, 5000 PIOPS)  / 67min 소요

감사합니다.

라고 생각했으나, 다시 곰곰히 문서를 확인하니 아래와 같은 그림을 보실 수 있습니다.

RDS의 경우 Block Size가 16K 이고, PIOPS가 5000이니 Througput은 80MB/s 수치가 맞습니다.(3st 테스트)

그래서 다시 테스트를 진행해봤습니다. 왜 하필 수치가...잘못 맞아서...

EC2(m4.10xlarge) -> RDS(m4.10xlarge, 2000GB, 20000 PIOPS), AWS 수치상 Throughput 300MB/s

첫 번째, Network Bandwidth

IOPS를 높여도 3MB/s 수준은 변함 없습니다. 그렇다면 MySQL Client의 한계가 3MB/s로 보입니다.

(테이블 별로 Client 프로세스 돌려도 동일합니다.)

두 번째, Disk IOPS

PIOPS 20000으로 진행했으나, 2500 이상 올라가지 않습니다. 

세 번째, Queue Depth

결국에도 Disk Queue는 4정도 수치로 계속 밀림.

네 번째, Write Throughput

Throughput 300을 예상했으나, 결국 80MB/s으로 밀림

다시 결과 레포트

MySQL 5.6.27 / sql File Size 4.5GB(wiki page .sql dump), DB Size 10 GB(단일 테이블 3,800만 row) / Full Dump 진행

별첨. EC2(m4.10xlarge) -> RDS(t2.micro, 100GB, 300 IOPS)  / 713min 소요

1. EC2(m4.10xlarge) -> RDS(m4.10xlarge, 100GB, 300 IOPS)  / 235min 소요

2. EC2(m4.10xlarge) -> RDS(m4.2xlarge, 100GB, 1000 PIOPS)  / 94min 소요

3. EC2(m4.10xlarge) -> RDS(m4.10xlarge, 500GB, 5000 PIOPS)  / 67min 소요

4. EC2(m4.10xlarge) -> RDS(m4.10xlarge, 2000GB, 20000 PIOPS), AWS 수치상 Throughput 300MB/s / 60min

결국 다시 원점으로 회귀해서.. RDS MySQL Application의 성능에 제약으로 판단됩니다. MySQL Dump 성능 및 최적화 방법 좀 구글링 해봐야겠습니다. 일단 Default 작업 시 결과는 위와 같습니다.

결국 MySQL 데이터 이관은 Disk IOPS 및 Through put이 가장 의미있는 수치라고 볼 수 있습니다.

(Default 기준 AWS RDS 최대 성능 IOPS 2000~2500, Throughput 80MB/s)

참고로 AWS와는 별도로 DB2 - ETL -> Oracle 4000만건 row는 6시간이 걸렸다는 레포트가 있습니다. 

이틀동안 업무 중에 계획없이 생각나는대로 테스트 해서 두서 없음...