MySQL용 RDS에서 무중단 Amazon Aurora 마이그레이션 따라하기
MySQL은 전 세계에서 가장 많이 사용되는 오픈 소스 데이터베이스입니다. 하지만 많은 고객이 MySQL 데이터베이스의 어렵고 획일적인 백업, 고가용성 구성 및 확장성이 복잡하거나 시간 소모적이라는 점을 인식하고 있습니다.
AWS 고객이 기존 EC2 설치형 MySQL에서 Amazon RDS for MySQL로 이전하는 주요한 이유 중 하나입니다. Amazon RDS는 특정 시점으로 복구, 고가용성 옵션과 같이 즉시 사용할 수 있는 기능을 제공합니다. RDS for MySQL은 심지어 소스별로 5개의 읽기 전용 복제본을 지원합니다. 따라서 바이너리 로그(binlog) 복제를 수동으로 구성하고 유지 관리할 필요 없이 읽기 워크로드를 손쉽게 확장할 수 있습니다.
만약 MySQL 호환성과 고사양 상용 데이터베이스의 성능 및 가용성을 원한다면, MySQL 데이터베이스를 Amazon Aurora로 마이그레이션하면 됩니다. MySQL 호환성을 갖춘 Amazon Aurora를 사용하면 빠른 데이터베이스 복제 및 autoscaling 복제본과 같은 기능을 활용할 수 있습니다. 또한, AWS Lambda 및 Amazon CloudWatch Logs와 같은 다른 AWS 서비스에도 기본적으로 통합됩니다. 이러한 기능과 더불어 Amazon Aurora는 3개의 가용 영역에 걸쳐 데이터를 복제함으로써 향상된 내구성도 제공합니다. 또한, 20밀리초 미만의 지연 시간으로 최대 15개의 Aurora 복제본으로 확장할 수 있습니다.
이 블로그 게시물에서는 최소한의 가동 중단으로 Amazon RDS for MySQL에서 Amazon Aurora MySQL로 마이그레이션하는 방법을 살펴보겠습니다.
마이그레이션 고려 사항
여타 마이그레이션과 마찬가지로 검토해야 할 몇 가지 고려 사항이 있습니다. 원본 소스, 이전 대상, 마이그레이션하는 데이터베이스에 종속된 클라이언트 애플리케이션, 그리고 마이그레이션 중 가용성과 관련된 비즈니스 요구 사항을 포함합니다. Amazon Aurora의 MySQL 에디션으로 마이그레이션할 때 선택에 따라 Aurora가 MySQL 5.6 및 MySQL 5.7과 애플리케이션 수준에서 호환 가능하다는 점에 유의해야 합니다. 다시 말해 애플리케이션 측면에서 보면 MySQL 5.6 또는 5.7과 Aurora 5.6 또는 5.7 간에 차이가 없다는 것입니다. 따라서 마이그레이션 프로세스 중에 기존 애플리케이션 코드를 변경할 필요가 없습니다.
애플리케이션의 코드는 변경할 필요가 없지만, 애플리케이션이 새로운 데이터베이스를 가리키도록 할 방법이 필요합니다. 물론 모든 애플리케이션의 모든 연결 문자열을 변경할 수도 있지만, 또 다른 일반적인 접근 방식은 DNS를 사용하여 이 작업을 수행하는 것입니다. 이 경우에는 연결 문자열에 데이터베이스 인스턴스의 실제 호스트 이름을 사용하지 않습니다. 대신, 데이터베이스 인스턴스의 호스트 이름을 가리키는 CNAME(정식 이름) 레코드를 만드는 것을 고려하십시오. 이렇게 하면 여러 연결 문자열 설정을 추적하고 수정하지 않고 단일 위치에서 애플리케이션이 가리키는 엔드포인트를 변경할 수 있습니다.
이 패턴을 사용하도록 선택하는 경우, CNAME 레코드의 TTL(Time To Live) 설정에 각별히 주의하십시오. 이 값을 너무 높게 설정하면 이 CNAME이 가리키는 호스트 이름이 불필요하게 오래 캐시될 수 있습니다. 이 값을 너무 낮게 설정하면 이 CNAME을 반복해서 확인해야 하므로 클라이언트 애플리케이션에 추가적인 오버헤드가 발생할 수 있습니다. 사용 사례마다 다르지만, 일반적으로 5초의 TTL이 좋은 시작점이 됩니다.
마이그레이션 단계
기존 RDS for MySQL 인스턴스를 Amazon Aurora 클러스터로 마이그레이션하는 첫 번째 단계는 Amazon RDS 관리 콘솔에서 인스턴스를 선택하는 것입니다. 그런 다음 Instance actions에서 Create Aurora read replica를 선택합니다.
이 옵션을 선택하면 Aurora 클러스터를 정의하는 몇 가지 파라미터를 지정해야 합니다. Amazon Aurora 클러스터의 마스터 사용자 이름과 마스터 암호는 소스 인스턴스와 동일합니다.
마이그레이션 프로세스를 시작하면, Amazon RDS가 기존 RDS for MySQL 인스턴스의 스냅샷을 생성하고 해당 스냅샷의 데이터를 새로 생성된 Amazon Aurora 클러스터에 복원합니다. 소스 데이터베이스의 크기에 따라 이 작업은 몇 시간이 걸릴 수 있습니다.
Amazon Aurora 클러스터가 생성되고 초기 데이터 세트가 로드되면, Amazon RDS는 RDS for MySQL 인스턴스에서 Amazon Aurora 클러스터로 binlog 복제를 설정합니다.
binlog 복제가 설정되고 복제가 시작되면, Amazon Aurora 클러스터에 대한 CloudWatch 지표인 Aurora Binlog Replica Lag를 모니터링하는 것이 좋습니다.
CloudWatch가 binlog replica lag에 대한 개괄적인 보기를 제공하지만, 새로 생성된 Amazon Aurora 클러스터에 로그인하여 좀 더 정밀한 측정치를 확인할 수 있습니다. 그렇게 하려면 MySQL 클라이언트를 사용하고 show slave statusG 명령을 실행합니다. 이 명령은 다수의 매우 유용한 정보를 반환하지만, 우리가 원하는 특정 지표는 Seconds_Behind_Master입니다. 이 지표가 0에 도달하면, 새로 생성된 Amazon Aurora 클러스터가 원래 RDS for MySQL 인스턴스와 동기화된 것입니다.
새로운 Amazon Aurora 클러스터가 원래 RDS for MySQL 인스턴스와 동기화되면, RDS for MySQL 인스턴스에 대한 쓰기를 중단해야 합니다. 그런 다음 새로운 Amazon Aurora 클러스터에 쓰기 시작합니다. 몇 가지 방법을 사용하여 이를 수행할 수 있습니다. 첫 번째 옵션은 다음과 같이 소스 인스턴스를 중단하는 것입니다. 이 접근 방식은 인스턴스를 종료하여 추가 쓰기를 방지합니다.
두 번째 옵션은 소스 인스턴스를 읽기 전용 상태로 전환하는 것입니다. RDS for MySQL을 사용해 이 작업을 수행하려면 인스턴스에 할당된 파라미터 그룹을 수정하면 됩니다. read_only 설정의 기본값은 {TrueIfReplica}입니다. 이 예에서는 이 값을 인스턴스가 읽기 전용 모드임을 나타내는 1로 명시적으로 설정하려고 합니다. 이 파라미터에는 동적 적용 유형이 있습니다. 즉, 설정이 즉시 적용되며 재부팅할 필요가 없습니다.
이제 소스 RDS for MySQL 인스턴스가 읽기 전용 모드이거나 중단된 상태입니다. 이 시점에 Seconds_Behind_Master 지표를 한 번 더 확인하여 모든 binlog가 적용되었는지 점검합니다.
그런 다음 Aurora 읽기 전용 복제본을 writer로 승격합니다. 이를 수행하려면 대상 Aurora 클러스터를 선택한 후, Instance actions에서 Promote read replica를 선택하면 됩니다. 선택하면 프로세스가 완료되는 데 몇 분 정도 걸립니다. 이 시점에서 이 게시물의 앞부분에서 설명한 대로 애플리케이션이 참조하는 CNAME을 변경합니다.
아래 그림에 나와 있듯이 새로운 Amazon Aurora 클러스터의 Recent events를 확인하면 프로세스가 완료되었는지 알 수 있습니다.
요약
이 블로그 게시물에서는 다운타임 없이 실시간으로 RDS for MySQL 인스턴스를 새로운 Amazon Aurora 클러스터로 마이그레이션하는 방법을 살펴보았습니다. RDS for MySQL에서 Aurora로 마이그레이션에 대한 좀 더 자세한 설명서는 마이그레이션 설명서를 참조하십시오.
이 글은 AWS Database 블로그에 실린 Best practices for migrating RDS for MySQL databases to Amazon Aurora의 한국어 번역입니다.
Source: MySQL용 RDS에서 무중단 Amazon Aurora 마이그레이션 따라하기
