대용량 DB(RDS) Table to S3 마이그레이션 방안

2020-09-03

.

Data_Engineering_TIL(20200903)

AWS 사용자모임 게시판 글을 읽고 배운 내용을 정리하였습니다.

해당 게시판글 URL : https://awskrug.slack.com/archives/C3D5K9LHY/p1599010948010900

# 해당 게시판글 요약

방안 1) RDS 스냅샷 to S3 for Parquet file

https://aws.amazon.com/ko/blogs/korea/new-exporting-db-snapshot-data-to-amazon-s3-in-apache-parquet-format/

https://chang12.github.io/rds-snapshot-export-to-s3/

주의사항 : 2020년 9월 3일 현재 해당 방안은 일부리전에서만 가능, 서울리전 불가

** Amazon RDS 스냅샷 S3으로 내보내기는 PostgreSQL 용 Amazon RDS, MariaDB 용 Amazon RDS, MySQL 용 Amazon RDS, Amazon Aurora PostgreSQL 및 Amazon Aurora MySQL 스냅 샷에서 데이터를 내보낼 수 있으며, 현재 미국 동부 (버지니아 북부), 동부 (오하이오), 미국 서부 (오레곤), 유럽 (아일랜드) 및 아시아 태평양 (도쿄) 리전에서 사용할 수 있습니다.

방안 2) DMS 서비스를 이용

https://aws.amazon.com/ko/blogs/database/replicate-data-from-amazon-aurora-to-amazon-s3-with-aws-database-migration-service/

** DMS 사용시 주의사항

RDS에서 schema evolution이 일어날 때 마다 DMS task가 fail 할 수도 있음

관련 게시판글

질문자 : RDS -> S3를 DMS로 사용중인데 RDS에서 schema evolution이 일어날 때 마다 DMS task가 fail합니다. 그래서 RDS table의 schema가 변경되면 (적절한 처리 후) DMS task를 재시작해야 하는 번거로움이 있더라고요. AWS engineer와 얘기해도 DMS는 (full load이든 cdc이든) 이럴 경우 적절하지 않다고 하던데 혹 이런 문제를 겪고 계신지 궁금합니다.

답변자 : 저희는 RDS -> S3를 Spark를 통해서 직접 구현하고 있는데 위와 같은 schema evolution 상황을 감지해서 resolve 하는 Glue 코드를 사용하고 있습니다. (요것도 수동으로 구현) column append 같은 경우에는 자동으로 resolve 하고 삭제는 (거의 일어나지 않지만) exception 내고 사람이 수동으로 대응하고 있습니다. DMS는 아무래도 그런 자유도가 떨어지다보니 DMS 내에서 해결하는 건 어려울 것 같습니다.

질문자 : 아 그것도 방법이군요. DMS는 역시 schema가 (자주) 바꾸지 않는상황에서 유용한 거 같네요

방안 3) Glue나 Spark 등을 이용 (파이썬 코딩 포함)

# 해당 게시판글 원문

  • 질문자 : 서울 리전에 약 100억건의 row가 있는 오로라 DB 테이블의 모든 데이터들을 S3로 내보내는데 제일 효과적인 방법은 무엇일까요? mysqldump, dms 등을 생각하고 있습니다.

  • 유저 A : Parquet 형태로 내보낸다면 Snapshot을 S3로 보내는 기능이 있긴 한데… 아직 서울리전에서 지원을 하지 않네요.

다음 URL을 참고하세요

https://aws.amazon.com/ko/blogs/korea/new-exporting-db-snapshot-data-to-amazon-s3-in-apache-parquet-format/

https://chang12.github.io/rds-snapshot-export-to-s3/

  • 유저 A : DMS가 나을거 같습니다.

https://aws.amazon.com/ko/blogs/database/replicate-data-from-amazon-aurora-to-amazon-s3-with-aws-database-migration-service/

  • 유저 B : 1회성이라면 DMS도 괜찮을 거 같고요. 자주 하셔야 한다면 Glue ETL이나 (Aurora에서 S3로 내리는 기능을 지원합니다) Spark에서 직접 구현하셔도 좋을 것 같습니다. 저는 10억 건 정도 있는 table을 Spark를 통해서 매일 내리고 있는데 10분 미만으로 소요되는 거 같아요.

  • 질문자 : 오오! 질문들 추가로 몇가지 하겠습니다!

질문 1) Aurora에서 S3로 내리는 기능은 어떤건가요??

질문 2) 10억건 데이터를 Spark에서 JDBC를 이용해서 내리시나요??

질문 3) 어느정도 크기의 EMR cluster를 사용하시나요??

  • 유저 B :

질문 1) 에 대한 답변 : 저도 그냥 듣기만 한 거라서 다른 분들 설명을 참고하시면 될 거 같습니다!

질문 2) 에 대한 답변 : 네. Spark JDBC를 통해서 내리는데 당연히 단일 쿼리는 아니고, 각 executor가 병렬로 처리하도록 했습니다.

질문 3) 에 대한 답변 : spot으로 4xlarge 1대 혹은 2대 사용합니다. 인스턴스 1대당 executor 3대가 뜹니다. (5 thread씩)

개인적으로 다른 솔루션에 비해 Spark JDBC가 fully customize도 가능하고 속도도 매우 빠르기 때문에 사내에서 널리널리 이용 중입니다. (format conversion, masking 등등 다양한 전처리를 하고 있어서…)

  • 질문자 : 저희도 제일 처음에 EMR에서 JDBC를 사용하는 방안을 테스트 했었는데 문제가 있어서 다른 방향을 여쭤보았습니다. 잘 사용하고 계시다니 저희쪽에서 뭔가 문제가 있어서 동작하지 않았었나 봅니다

  • 유저 A :

질문 1)에 대한 답변 : Aurora to S3는 아래를 참고하시면 될 거 같습니다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.SaveIntoS3.html

질문 2)에 대한 답변 : 아마도 그럴거 같습니다.

질문 3)에 대한 답변 : 이건 뭐 테이블 크기나 작업마다 다르지 않을까 싶네요. 보통 높은 인스턴스로 하면 작업이 빠르게 처리되니, spot 같은걸 써도 될 거 같습니다.

  • 유저 C : 그냥 스냅샷만 다른 리전으로 복사해서 s3 로 내보내도 좋을 것 같아요. 이 과정할 때 엔진 버전이 더 문제였어요. mysqldump 나 aurora to s3 를 쿼리로 하게 된다면 단일 테이블에 100억건이 있지 않는 이상 데이터 싱크를 맞추려면 데이터베이스에 락을 걸어야 할 거 같아요

  • 질문자 : 감사합니다. 1번은 제가 검토해봤던 방식이긴 하네요. 매일같이 몇백대의 SPOT을 쓸 수는 없어서 증분 데이터 처리 방식으로 구성해놓긴 했습니다만 그 전에 존재하는 데이터의 이동때문에 질문 드렸었습니다. 저희가 데이터를 다른 리전으로는 보내지 못 하게 되어있습니다. ㅠㅠ 단일 테이블에 100억건이 넘는 row가 있어서 고민중이었습니다.

  • 유저 D : 제가 과거에 사용했던 방식을 조금 설명드리면 1개의 테이블에 데이터량이 많을때 EMR의 Spark을 이용하시면 로딩할때 시간이 오래 걸렸습니다. Spark에 옵션을 주면 좀더 빠르게 데이터를 가져올수는 있으나 오라클이 버틸지 확인해보셔야합니다. 같은 테이블을 DMS로 이용했을때 좀더 속도가 좋았습니다. 병렬로 처리를 해서 그런지 source rdbms 에 적은 resouce를 사용하면서 데이터를 가져왔습니다. 참고하세요..