Aurora Serverless v2로 마이그레이션

Aurora Serverless v2를 사용하도록 기존 DB 클러스터를 변환하려면 다음을 수행합니다.

업그레이드된 클러스터가 Aurora Serverless v2 요구 사항 및 제한 사항에 나열된 적절한 엔진 버전을 실행 중이면 여기에 Aurora Serverless v2 DB 인스턴스를 추가할 수 있습니다. 업그레이드된 클러스터에 추가하는 첫 번째 DB 인스턴스는 프로비저닝된 DB 인스턴스여야 합니다. 그런 다음 쓰기 워크로드, 읽기 워크로드 또는 둘 다에 대한 처리를 Aurora Serverless v2 DB 인스턴스로 전환할 수 있습니다.

Aurora Serverless v2를 사용하도록 기존 클러스터 업그레이드 또는 전환

프로비저닝된 클러스터에 Aurora Serverless v2를 지원하는 엔진 버전이 있는 경우 Aurora Serverless v2로 전환할 때 업그레이드가 필요하지 않습니다. 이 경우 Aurora Serverless v2 DB 인스턴스를 원래 클러스터에 추가할 수 있습니다. 모든 Aurora Serverless v2 DB 인스턴스를 사용하도록 클러스터를 전환할 수 있습니다. 동일한 DB 클러스터에서 Aurora Serverless v2와 프로비저닝된 DB 인스턴스를 조합하여 사용할 수도 있습니다. Aurora Serverless v2을 지원하는 Aurora 엔진 버전은 Aurora Serverless v2를 지원하는 리전 및 Aurora DB 엔진 섹션을 참조하세요.

Aurora Serverless v2를 지원하지 않는 낮은 엔진 버전을 실행 중인 경우 다음과 같은 일반적인 단계를 수행합니다.

Aurora Serverless v1에서 Aurora Serverless v2로 업그레이드하려면 프로비저닝된 클러스터를 중간 단계로 생성해야 합니다. 그런 다음 프로비저닝된 클러스터로 시작할 때와 동일한 업그레이드 단계를 수행합니다.

Aurora Serverless v2를 사용하기 위한 MySQL 호환 클러스터의 업그레이드 경로

원래 클러스터에서 Aurora MySQL을 실행 중인 경우 클러스터의 엔진 버전 및 엔진 모드에 따라 적절한 프로시저를 선택합니다.

Aurora Serverless v2를 사용하기 위한 PostgreSQL 호환 클러스터의 업그레이드 경로

원래 클러스터에서 Aurora PostgreSQL을 실행 중인 경우 클러스터의 엔진 버전 및 엔진 모드에 따라 적절한 프로시저를 선택합니다.

프로비저닝된 클러스터에서 Aurora Serverless v2로 전환

Aurora Serverless v2를 사용하도록 프로비저닝된 클러스터를 전환하려면 다음 단계를 따르세요.

다음 AWS CLI 예제는 Aurora MySQL 버전 3.02.0을 실행하는 프로비저닝된 클러스터를 사용하는 전환 프로세스를 보여줍니다. 클러스트 이름은 mysql-80입니다. 클러스터는 라이터와 리더인 provisioned-instance-1과 provisioned-instance-2라는 두 개의 프로비저닝된 DB 인스턴스로 시작합니다. 둘 다 db.r6g.large DB 인스턴스 클래스를 사용합니다.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' --output text
mysql-80
provisioned-instance-2     False
provisioned-instance-1     True

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-1 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-1     db.r6g.large

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-2 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-2     db.r6g.large

일부 데이터가 포함된 테이블을 만들었습니다. 이렇게 하면 전환 전후에 클러스터의 데이터와 동작이 동일한지 확인할 수 있습니다.

mysql> create database serverless_v2_demo;
mysql> create table serverless_v2_demo.demo (s varchar(128));
mysql> insert into serverless_v2_demo.demo values ('This cluster started with a provisioned writer.');
Query OK, 1 row affected (0.02 sec)

먼저 클러스터에 용량 범위를 추가합니다. 그렇지 않으면 클러스터에 Aurora Serverless v2 DB 인스턴스를 추가할 때 오류가 발생합니다. 이 절차에 AWS Management Console을 사용하는 경우 첫 번째 Aurora Serverless v2 DB 인스턴스를 추가할 때 해당 단계는 자동입니다.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql

An error occurred (InvalidDBClusterStateFault) when calling the CreateDBInstance operation:
Set the Serverless v2 scaling configuration on the parent DB cluster before creating a Serverless v2 DB instance.

$ # The blank ServerlessV2ScalingConfiguration attribute confirms that the cluster doesn't have a capacity range set yet.
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 --query 'DBClusters[*].ServerlessV2ScalingConfiguration'
[]

$ aws rds modify-db-cluster --db-cluster-identifier mysql-80 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
{
  "DBClusterIdentifier": "mysql-80",
  "ServerlessV2ScalingConfiguration": {
    "MinCapacity": 0.5,
    "MaxCapacity": 16
  }
}

원본 DB 인스턴스를 대신할 두 개의 Aurora Serverless v2 리더를 만듭니다. 이렇게 하려면 새로운 db.serverless DB 인스턴스에 DB 인스턴스 클래스를 지정합니다.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-2 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-2",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ # Wait for both DB instances to finish being created before proceeding.
$ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1 && \
  aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-2

장애 조치 작업을 수행하여 Aurora Serverless v2 DB 인스턴스 중 하나를 클러스터의 새 라이터로 만듭니다.

$ aws rds failover-db-cluster --db-cluster-identifier mysql-80 \
  --target-db-instance-identifier serverless-v2-instance-1
{
  "DBClusterIdentifier": "mysql-80",
  "DBClusterMembers": [
    {
      "DBInstanceIdentifier": "serverless-v2-instance-1",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "serverless-v2-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-1",
      "IsClusterWriter": true,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    }
  ],
  "Status": "available"
}

변경 사항이 적용되려면 몇 초가 걸립니다. 그 시점에서 Aurora Serverless v2 라이터와 Aurora Serverless v2 리더가 있습니다. 따라서 원래 프로비저닝된 DB 인스턴스가 필요하지 않습니다.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
mysql-80
serverless-v2-instance-1        True
serverless-v2-instance-2        False
provisioned-instance-2          False
provisioned-instance-1          False

전환 절차의 마지막 단계에서는 프로비저닝된 DB 인스턴스를 모두 삭제합니다.

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-2 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-2",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-1 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-1",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

최종 확인으로 Aurora Serverless v2 라이터 DB 인스턴스에서 원본 테이블에 액세스하고 쓸 수 있는지 확인합니다.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
+---------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into serverless_v2_demo.demo values ('And it finished with a Serverless v2 writer.');
Query OK, 1 row affected (0.01 sec)

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

또한 Aurora Serverless v2 리더 DB 인스턴스에 연결하여 새로 작성된 데이터도 사용할 수 있는지 확인합니다.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

Aurora Serverless v2 및 Aurora Serverless v1 비교

이미 Aurora Serverless v1을 사용하고 있다면 Aurora Serverless v1과 Aurora Serverless v2의 주요 차이점을 배울 수 있습니다. 리더 DB 인스턴스 지원과 같은 아키텍처상의 차이점은 새로운 유형의 사용 사례를 보여줍니다.

다음 테이블에서 Aurora Serverless v2과 Aurora Serverless v1의 가장 중요한 차이점을 이해할 수 있습니다.

Aurora Serverless v2 및 Aurora Serverless v1의 요구 사항 비교

다음 테이블에는 Aurora Serverless v2 또는 Aurora Serverless v1를 사용하여 데이터베이스를 실행하기 위한 다양한 요구 사항이 요약되어 있습니다. Aurora Serverless v2는 Aurora Serverless v1보다 더 높은 버전의 Aurora MySQL 및 Aurora PostgreSQL DB 엔진을 제공합니다.

Aurora Serverless v2 및 Aurora Serverless v1의 확장성과 가용성 비교

다음 테이블에는 확장성 및 가용성 측면에서 Aurora Serverless v2과 Aurora Serverless v1의 차이점이 요약되어 있습니다.

Aurora Serverless v2 확장은 Aurora Serverless v1의 확장보다 반응성이 더 크고 세분화되어 있으며 방해가 덜합니다. Aurora Serverless v2은 DB 인스턴스의 크기를 변경하고 DB 클러스터에 더 많은 DB 인스턴스를 추가하여 확장할 수 있습니다. 다른 AWS 리전의 클러스터를 Aurora 글로벌 데이터베이스에 추가하여 확장할 수도 있습니다. 이와 달리 Aurora Serverless v1은 라이터의 용량을 늘리거나 줄이는 방식으로만 확장됩니다. Aurora Serverless v1 클러스터의 모든 컴퓨팅은 단일 가용 영역과 단일 AWS 리전에서 실행됩니다.

Aurora Serverless v2 및 Aurora Serverless v1 기능 지원 비교

다음 테이블에는 이에 대한 내용이 요약되어 있습니다.

Aurora Serverless v2에는 Aurora Serverless v1에서 사용할 수 없는 프로비저닝된 클러스터의 많은 기능이 포함되어 있습니다.

Aurora Serverless v1 사용 사례를 Aurora Serverless v2에 적용하기

Aurora Serverless v1의 사용 사례에 따라 다음과 같이 Aurora Serverless v2 기능을 활용하기 위해 해당 접근 방식을 조정할 수 있습니다.

로드가 적은 Aurora Serverless v1 클러스터가 있고 우선 순위가 비용을 최소화하면서 지속적인 가용성을 유지하는 것이라고 가정합니다. Aurora Serverless v2를 사용하면 Aurora Serverless v1의 최소 ACU 1개와 비교하여 0.5의 더 작은 최소 ACU 설정을 구성할 수 있습니다. 리더 DB 인스턴스에도 최소 0.5개의 ACU가 있는 다중 AZ 구성을 생성하여 가용성을 높일 수 있습니다.

개발 및 테스트 시나리오에서 사용하는 Aurora Serverless v1 클러스터가 있다고 가정합니다. 이 경우 비용도 높은 우선 순위이지만 클러스터를 항상 사용할 수 있어야 하는 것은 아닙니다. 현재 Aurora Serverless v2은 클러스터가 완전히 유휴 상태일 때 자동으로 일시 중지되지 않습니다. 대신 클러스터가 필요하지 않을 때 수동으로 중지하고 다음 테스트 또는 개발 주기가 되면 시작할 수 있습니다.

워크로드가 많은 B1 클러스터가 있다고 가정합니다. Aurora Serverless v2를 사용하는 동등한 클러스터는 더 세분화하여 확장할 수 있습니다. 예를 들어 Aurora Serverless v1은 용량을 두 배로 늘려 확장합니다(예: 64에서 128 ACU로 확장). 반대로 Aurora Serverless v2 DB 인스턴스는 0.5ACU 단위로 스케일 인할 수 있습니다.

워크로드에 Aurora Serverless v1에서 사용 가능한 것보다 더 많은 총 용량이 필요하다고 가정합니다. 여러 Aurora Serverless v2 리더 DB 인스턴스를 사용하여 라이터 DB 인스턴스에서 워크로드의 읽기 집약적인 부분을 오프로드할 수 있습니다. 읽기 집약적 워크로드를 여러 리더 DB 인스턴스로 나눌 수도 있습니다.

쓰기 집약적인 워크로드의 경우 대규모 프로비저닝된 DB 인스턴스를 라이터로 사용하여 클러스터를 구성할 수 있습니다. 이때 하나 이상의 Aurora Serverless v2 리더 DB 인스턴스와 함께 사용할 수 있습니다.

Aurora Serverless v1 클러스터에서 Aurora Serverless v2로 업그레이드

DB 클러스터를 Aurora Serverless v1에서 Aurora Serverless v2로 업그레이드하는 프로세스는 여러 단계로 이루어집니다. Aurora Serverless v1에서 Aurora Serverless v2로 직접 변환할 수 없기 때문입니다. Aurora Serverless v1 DB 클러스터를 프로비저닝된 클러스터로 변환하는 중간 단계가 항상 있습니다.

Aurora MySQL 호환 DB 클러스터

Aurora Serverless v1 DB 클러스터를 프로비저닝된 DB 클러스터로 변환한 다음 블루/그린 배포를 사용하여 업그레이드하고 다시 Aurora Serverless v2 DB 클러스터로 변환할 수 있습니다. 프로덕션 환경에서 이 절차를 진행하는 것이 좋습니다. 자세한 내용은 데이터베이스 업데이트에 Amazon RDS 블루/그린 배포 사용 단원을 참조하십시오.

Aurora PostgreSQL 호환 DB 클러스터

Aurora Serverless v1 DB 클러스터를 프로비저닝된 DB 클러스터로 변환한 다음 블루/그린 배포를 사용하여 업그레이드하고 다시 Aurora Serverless v2 DB 클러스터로 변환할 수 있습니다. 프로덕션 환경에서 이 절차를 진행하는 것이 좋습니다. 자세한 내용은 데이터베이스 업데이트에 Amazon RDS 블루/그린 배포 사용 단원을 참조하십시오.

Aurora PostgreSQL 버전 11에서 버전 13으로 Aurora Serverless v1 DB 클러스터를 직접 업그레이드하고 프로비저닝된 DB 클러스터로 변환한 다음, 프로비저닝된 클러스터를 Aurora Serverless v2 DB 클러스터로 변환할 수도 있습니다.

Aurora PostgreSQL 버전 13을 실행하는 Aurora Serverless v1 DB 클러스터의 경우, Aurora Serverless v1 클러스터를 프로비저닝된 DB 클러스터로 변환한 다음, 프로비저닝된 클러스터를 Aurora Serverless v2 DB 클러스터로 변환합니다.

Aurora Serverless v2로 온프레미스 데이터베이스 마이그레이션

프로비저닝된 Aurora MySQL 및 Aurora PostgreSQL과 마찬가지로 온프레미스 데이터베이스를 Aurora Serverless v2로 마이그레이션할 수 있습니다.