개발자 이민재입니다.

POSTS

AWS DMS(Database Migration Service) 사용 후기

12min read

AWS DMS란?

AWS에서 제공하는 데이터베이스 마이그레이션 서비스입니다. DB 마이그레이션과 관련된 일반적인 솔루션이어서, 사용할 수 있는 여러 케이스가 있습니다. 직접 사용해본 경험으로는 온프레미스 DB를 RDS로 옮기는 등, AWS 서비스로 이관해야 하는 경우에 더 적합한 서비스인 것 같습니다.

사용 배경 - RDS for MySQL 5.7의 연장 지원모드 돌입

   일단 회사에서 메인 데이터베이스로 쓰고있던 AWS RDS for MySQL 5.7 버전이 2024년 2월 29일부로 자동 연장지원 모드로 들어갔습니다 (블로그 링크). AWS 측에서는 이전부터 이메일로 계속 경고했지만, 매번 우선순위에 밀려 무시했던 참이었습니다. 사실 아예 지원을 끊겠다는 것도 아니고 지원을 연장해준다고 했으므로 DB가 당장 셧다운 될 일도 아니라고 생각했기 때문이었습니다.
   근데 셧다운만큼이나 더 무서운 문제가 있었으니, 요금 폭탄이었습니다. 연장지원 모드에 들어가게 되면 해당 버전에 사용요금이 추가로 부과됐습니다. 실제로 요금계산서로 예상비용을 계산해보니, 사용 중인 인스턴스 유형에서 한달에 연장지원으로 치르는 비용만 1600 달러였습니다. 물론 인스턴스 비용은 별도였습니다. 마침 클라우드 비용 절감에 눈에 불을 키고 다니던 시점이어서, 당장 조치를 취하기로 했습니다.

DMS 적용 이유

   사실 MySQL 5.7을 MySQL 8.0으로 메이저 버전만 업그레이드 하는 것은 제약조건들에만 걸리지 않으면 어렵지 않은 편이었습니다. MySQL 공식문서에서도 쉘 명령어로 검증할 것들을 자동으로 제공해주고 있었고, 이전에 한번 테스트 해본 적도 있었습니다.
   심지어 RDS를 사용하는 경우 블루/그린 배포를 사용하면 일일이 명령어로 버전 업그레이드 할 것 없이 자동으로 업그레이드 해줍니다. 그럼에도 더 무거운 작업인 DMS를 사용한 이유가 있는데, 여러 조건을 동시에 만족해야 했기 때문이었습니다.

  1. MySQL을 5.7에서 8.0으로 업그레이드 할 것
  2. RDS for MySQL을 Aurora MySQL로 변경하고 클러스터 구조를 변경할 것
  3. 이전 DB가 속한 VPC(old VPC)를 새 VPC(new VPC)로 옮길 것
  4. 서비스 중단 없을 것

   여기서 1번만 해당하면 블루/그린 배포로 간단히 업그레이드 하면 됩니다. 블루그린 배포하면 서비스 중단도 없습니다. 2번부터 DMS 카드를 생각했는데, 기존 RDS 인스턴스의 복제본으로 Aurora 클러스터가 있는 상황이었습니다.
    RDS를 블루그린 배포로 패치할 시 RDS -> RDS 패밀리로는 가능한데, RDS -> Aurora 로는 변경이 불가능한 것 같았습니다. 즉, 인스턴스 클래스를 업그레이드 하거나, 엔진의 메이저 버전을 업그레이드 할 수는 있으나 인스턴스의 유형 자체를 바꾸는 옵션을 찾지 못했습니다. 3번 역시 문제였는데, 블루/그린 배포를 만들면 같은 가용영역 안에서만 배포가 생성됐고, 다른 vpc에 배포를 만들거나 하는 설정 역시 찾지 못했습니다.

   그럼 가능한 경우 최대한 블루/그린 배포를 사용하는 것이 좋긴 합니다. 먼저, 엔드포인트를 애플리케이션 코드에서 바꿀 필요가 없어 마이그레이션 과정에서 다운타임이 없습니다. 즉, 서비스 중단 없이 데이터베이스를 패치하므로 매우 편리합니다. 운영 오버헤드도 거의 없고요. 또한 논리적 복제가 계속 일어나고 있어, 전환 중에 old blue 배포에 쓰기 작업이 계속 진행되어도 new blue 배포에 그대로 반영되므로 데이터 유실의 문제도 없습니다. DMS의 경우에도 CDC로 이런 부분을 커버하고는 있으나, 엔드포인트를 애플리케이션 코드에서 갈아끼워야하므로 분산 서비스에서는 배포시간만큼의 중단시간이 발생하게 됩니다.

   3번은 테스트 당시에는 제약조건이라고 생각했는데, 어차피 복제를 만들고나면 VPC를 따로 변경해주면 되기 때문에 상관없는 문제인 것 같습니다. 다만 DMS로 대상 데이터베이스를 새 VPC에 만들어두고 작업하면 변경 없이 VPC를 작업할 수 있기는 합니다. 3번 때문에 마이그레이션 작업 시 VPC 피어링 설정이 추가로 필요했습니다.

DMS 적용 과정

   DMS의 구성 요소는 크게 소스/타겟 데이터베이스, 그리고 중간에 그 둘 간의 복제작업 컴퓨팅 리소스인 복제 인스턴스가 있습니다. 마지막으로 복제 작업 자체를 정의하는 태스크(Task)가 있습니다.
순서는 타겟 데이터베이스를 만들고(소스는 있을 것이므로), 복제 인스턴스를 생성한 다음, 소스/타겟 데이터베이스의 엔드포인트를 설정해서 복제 인스턴스와의 연결을 테스트합니다. 마지막으로 마이그레이션 태스크를 정의해서 마이그레이션을 어떻게 진행할 것인지 설정하면 바로 마이그레이션이 시작됩니다.

  1. (MySQL인 경우) 소스 데이터베이스 파라미터 변경

  변경 데이터 캡처(CDC) 설정을 하려면 MySQL 5.7의 경우 binlog_format 파라미터를 row로 설정해야 한다고 합니다. 정확히 어떤 맥락에서 이것이 필요한지는 더 공부해봐야겠지만 지속 복제 작업은 필수이므로 반드시 설정해줘야 합니다.

  1. 타겟 데이터베이스 생성

먼저 마이그레이션 타겟이 될 데이터베이스 인스턴스를 생성해야합니다.

  1. 복제 인스턴스 생성

복제 인스턴스를 생성하거나, 서버리스로 진행해서 인프라 관리를 AWS에 맡길 수도 있는데, 서버리스로 진행할 경우 2024-03-07 기준 마이그레이션 인스턴스 유형이 제한됩니다. 요금은 복제 인스턴스보다 서버리스가 더 저렴합니다. 그런데 마이그레이션이 며칠 단위로 걸리는 작업은 아니어서, 비용 상 유의미한 차이는 없었습니다.

  1. 소스 엔드포인트와 타겟 엔드포인트 연결

소스, 타겟 데이터베이스 연결을 담당할 엔드포인트를 각각 만들어줍니다. 마지막에 연결을 테스트해볼 수 있는데, 빼먹은 보안그룹 설정 같은 것들을 확인할 수 있으니 반드시 연결이 성공적으로 되는지 테스트해야 합니다.

  1. 태스크 생성

이제 마이그레이션 작업 전반을 정의할 태스크를 생성합니다. 태스크가 생성되면 실제로 마이그레이션 작업이 이뤄집니다.

   이렇게 4-5단계를 거치고 나면 아주 긴 시간동안 마이그레이션 작업이 진행됩니다. 이 동안 기존 데이터베이스에 부하가 많이 가는 것은 아닌가 했는데, 지표를 보면 딱히 큰 변화는 없었습니다. 마이그레이션 진행 중에 소스 데이터베이스에서 쓰기 작업이 발생해도 CDC가 적용되어 있으므로 타겟 데이터베이스에 변경사항이 그대로 반영되는 것을 확인할 수 있습니다.
   주의할 것은, 타겟 데이터베이스에 auto_increment나 cascade 설정들은 마이그레이션 되지 않는다는 것입니다. 이런 설정들이 같이 필요하면 스키마 마이그레이션이 선행되어야 합니다. ORM 등 툴을 이용해서 버전관리를 하고 있고, 타겟 데이터베이스의 인스턴스가 다르지 않다면 직접 스키마 마이그레이션 작업을 진행해도 될 것 같습니다. 그런 상황이 아니면 AWS에서 제공하는 SCT(Schema Conversion Tool)을 이용해서 스키마 마이그레이션을 진행하는 것이 좋을 것 같습니다.

참고자료