기존 클러스터에서 Aurora Serverless v2 사용 프로비저닝된 클러스터에서 전환 Aurora Serverless v2 및 Aurora Serverless v1 비교 Aurora Serverless v1에서 Aurora Serverless v2로 업그레이드 Aurora Serverless v2로 온프레미스 데이터베이스 마이그레이션

Aurora Serverless v2로 마이그레이션

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

프로비저닝된 Aurora DB 클러스터에서 업그레이드합니다.
Aurora Serverless v1 클러스터에서 업그레이드합니다.
온프레미스 데이터베이스에서 Aurora Serverless v2 클러스터로 마이그레이션합니다.

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

참고

이 주제에서는 기존 DB 클러스터를 변환하는 방법을 설명합니다. 새로운 Aurora Serverless v2 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를 지원하지 않는 낮은 엔진 버전을 실행 중인 경우 다음과 같은 일반적인 단계를 수행합니다.

클러스터를 업그레이드합니다.
업그레이드된 클러스터에 대해 프로비저닝된 라이터 DB 인스턴스를 생성합니다.
Aurora Serverless v2 DB 인스턴스를 사용하도록 클러스터를 수정합니다.

중요

스냅샷 복원 또는 복제를 사용하여 Aurora Serverless v2 호환 버전으로 메이저 버전 업그레이드를 수행하는 경우 새 클러스터에 추가하는 첫 번째 DB 인스턴스는 프로비저닝된 DB 인스턴스여야 합니다. 이 추가는 업그레이드 프로세스의 마지막 단계를 시작합니다.

최종 단계가 완료될 때까지 클러스터에는 Aurora Serverless v2 지원에 필요한 인프라가 없습니다. 따라서 이러한 업그레이드된 클러스터는 항상 프로비저닝된 라이터 DB 인스턴스로 시작합니다. 그런 다음 프로비저닝된 DB 인스턴스를 Aurora Serverless v2 인스턴스로 변환하거나 장애 조치를 수행할 수 있습니다.

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

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

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

원래 Aurora MySQL 클러스터가 다음과 같은 경우	Aurora Serverless v2로 전환하려면 이렇게 하세요.
MySQL 8.0과 호환되는 Aurora MySQL 버전 3을 실행하는 프로비저닝된 클러스터	이는 기존 Aurora MySQL 클러스터에서 모든 변환을 위한 마지막 단계입니다. 필요한 경우 버전 3.02.0 이상으로 마이너 버전 업그레이드를 수행합니다. 라이터 DB 인스턴스에 프로비저닝된 DB 인스턴스를 사용합니다. 하나의 Aurora Serverless v2 리더 DB 인스턴스를 추가합니다. 라이터 DB 인스턴스를 만들기 위해 장애 조치를 수행합니다. (선택 사항) 클러스터의 다른 프로비저닝된 DB 인스턴스를 Aurora Serverless v2로 변환합니다. 또는 새 Aurora Serverless v2 DB 인스턴스를 추가하고 프로비저닝된 DB 인스턴스를 제거합니다. 전체 프로시저 및 예는 프로비저닝된 클러스터에서 Aurora Serverless v2로 전환 섹션을 참조하세요.
MySQL 5.7과 호환되는 Aurora MySQL 버전 2를 실행하는 프로비저닝된 클러스터	Aurora MySQL 버전 3.02.0 이상으로 메이저 버전 업그레이드를 수행합니다. 그런 다음 Aurora MySQL 버전 3에 대한 프로시저에 따라 Aurora Serverless v2 DB 인스턴스를 사용하도록 클러스터를 전환합니다.
MySQL 5.7과 호환되는 Aurora MySQL 버전 2를 실행하는 Aurora Serverless v1 클러스터	Aurora Serverless v1에서 전환을 계획하는 데 도움을 받으려면 먼저 Aurora Serverless v2 및 Aurora Serverless v1 비교에 문의하세요. 그런 다음 Aurora Serverless v1 클러스터에서 Aurora Serverless v2로 업그레이드의 절차를 따릅니다.

원래 Aurora MySQL 클러스터가 다음과 같은 경우

Aurora Serverless v2로 전환하려면 이렇게 하세요.

MySQL 8.0과 호환되는 Aurora MySQL 버전 3을 실행하는 프로비저닝된 클러스터

이는 기존 Aurora MySQL 클러스터에서 모든 변환을 위한 마지막 단계입니다.

필요한 경우 버전 3.02.0 이상으로 마이너 버전 업그레이드를 수행합니다. 라이터 DB 인스턴스에 프로비저닝된 DB 인스턴스를 사용합니다. 하나의 Aurora Serverless v2 리더 DB 인스턴스를 추가합니다. 라이터 DB 인스턴스를 만들기 위해 장애 조치를 수행합니다.

(선택 사항) 클러스터의 다른 프로비저닝된 DB 인스턴스를 Aurora Serverless v2로 변환합니다. 또는 새 Aurora Serverless v2 DB 인스턴스를 추가하고 프로비저닝된 DB 인스턴스를 제거합니다.

전체 프로시저 및 예는 프로비저닝된 클러스터에서 Aurora Serverless v2로 전환 섹션을 참조하세요.

MySQL 5.7과 호환되는 Aurora MySQL 버전 2를 실행하는 프로비저닝된 클러스터

Aurora MySQL 버전 3.02.0 이상으로 메이저 버전 업그레이드를 수행합니다. 그런 다음 Aurora MySQL 버전 3에 대한 프로시저에 따라 Aurora Serverless v2 DB 인스턴스를 사용하도록 클러스터를 전환합니다.

MySQL 5.7과 호환되는 Aurora MySQL 버전 2를 실행하는 Aurora Serverless v1 클러스터

Aurora Serverless v1에서 전환을 계획하는 데 도움을 받으려면 먼저 Aurora Serverless v2 및 Aurora Serverless v1 비교에 문의하세요.

그런 다음 Aurora Serverless v1 클러스터에서 Aurora Serverless v2로 업그레이드의 절차를 따릅니다.

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

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

원래 Aurora PostgreSQL 클러스터가 다음과 같은 경우	Aurora Serverless v2로 전환하려면 이렇게 하세요.
Aurora PostgreSQL 버전 13을 실행하는 프로비저닝된 클러스터	이는 기존 PostgreSQL 클러스터에서 모든 변환을 위한 마지막 단계입니다. 필요한 경우 버전 13.6 이상으로 마이너 버전 업그레이드를 수행합니다. 라이터 DB 인스턴스에 대해 프로비저닝된 DB 인스턴스를 하나 추가합니다. 하나의 Aurora Serverless v2 리더 DB 인스턴스를 추가합니다. 해당 Aurora Serverless v2 인스턴스를 라이터 DB 인스턴스로 만들기 위해 장애 조치를 수행합니다. (선택 사항) 클러스터의 다른 프로비저닝된 DB 인스턴스를 Aurora Serverless v2로 변환합니다. 또는 새 Aurora Serverless v2 DB 인스턴스를 추가하고 프로비저닝된 DB 인스턴스를 제거합니다. 전체 프로시저 및 예는 프로비저닝된 클러스터에서 Aurora Serverless v2로 전환 섹션을 참조하세요.
Aurora PostgreSQL 버전 11 또는 12를 실행하는 프로비저닝된 클러스터	Aurora PostgreSQL 버전 13.6 이상으로 메이저 버전 업그레이드를 수행합니다. 그런 다음 Aurora PostgreSQL 버전 13에 대한 절차에 따라 Aurora Serverless v2 DB 인스턴스를 사용하도록 클러스터를 전환합니다.
Aurora PostgreSQL 버전 11 또는 13을 실행하는 Aurora Serverless v1 클러스터	Aurora Serverless v1에서 전환을 계획하는 데 도움을 받으려면 먼저 Aurora Serverless v2 및 Aurora Serverless v1 비교에 문의하세요. 그런 다음 Aurora Serverless v1 클러스터에서 Aurora Serverless v2로 업그레이드의 절차를 따릅니다.

원래 Aurora PostgreSQL 클러스터가 다음과 같은 경우

Aurora Serverless v2로 전환하려면 이렇게 하세요.

Aurora PostgreSQL 버전 13을 실행하는 프로비저닝된 클러스터

이는 기존 PostgreSQL 클러스터에서 모든 변환을 위한 마지막 단계입니다.

필요한 경우 버전 13.6 이상으로 마이너 버전 업그레이드를 수행합니다. 라이터 DB 인스턴스에 대해 프로비저닝된 DB 인스턴스를 하나 추가합니다. 하나의 Aurora Serverless v2 리더 DB 인스턴스를 추가합니다. 해당 Aurora Serverless v2 인스턴스를 라이터 DB 인스턴스로 만들기 위해 장애 조치를 수행합니다.

전체 프로시저 및 예는 프로비저닝된 클러스터에서 Aurora Serverless v2로 전환 섹션을 참조하세요.

Aurora PostgreSQL 버전 11 또는 12를 실행하는 프로비저닝된 클러스터

Aurora PostgreSQL 버전 13.6 이상으로 메이저 버전 업그레이드를 수행합니다. 그런 다음 Aurora PostgreSQL 버전 13에 대한 절차에 따라 Aurora Serverless v2 DB 인스턴스를 사용하도록 클러스터를 전환합니다.

Aurora PostgreSQL 버전 11 또는 13을 실행하는 Aurora Serverless v1 클러스터

Aurora Serverless v1에서 전환을 계획하는 데 도움을 받으려면 먼저 Aurora Serverless v2 및 Aurora Serverless v1 비교에 문의하세요.

그런 다음 Aurora Serverless v1 클러스터에서 Aurora Serverless v2로 업그레이드의 절차를 따릅니다.

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

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

프로비저닝된 클러스터를 Aurora Serverless v2 DB 인스턴스와 함께 사용하기 위해 업그레이드해야 하는지 확인하세요. Aurora Serverless v2와 호환되는 Aurora 버전은 Aurora Serverless v2 요구 사항 및 제한 사항 섹션을 참조하세요.

프로비저닝된 클러스터가 Aurora Serverless v2에 사용할 수 없는 엔진 버전을 실행 중인 경우 클러스터의 엔진 버전을 업그레이드하세요.
- MySQL 5.7 호환 프로비저닝된 클러스터가 있는 경우 Aurora MySQL 버전 3에 대한 업그레이드 지침을 따릅니다. 현재 위치 업그레이드 수행 방법의 프로시저를 따르세요.
- PostgreSQL 버전 11~12를 실행하는 PostgreSQL 호환 프로비저닝된 클러스터가 있는 경우 Aurora PostgreSQL 버전 13에 대한 업그레이드 지침을 따르세요. 메이저 버전 업그레이드를 수행하는 방법의 프로시저를 따르세요.
Aurora Serverless v2 요구 사항 및 제한 사항의 Aurora Serverless v2 요구 사항과 일치하도록 다른 클러스터 속성을 구성합니다.
클러스터에 대한 크기 조정 구성을 구성합니다. 클러스터의 Aurora Serverless v2 용량 설정의 프로시저를 따르세요.
클러스터에 하나 이상의 Aurora Serverless v2 DB 인스턴스를 추가합니다. DB 클러스터에 Aurora 복제본 추가의 일반 절차를 따르세요. 각각의 새 DB 인스턴스에 대해 AWS Management Console에서 특수 DB 인스턴스 클래스 이름을 Serverless로 지정하거나 AWS CLI 또는 Amazon RDS API에서 db.serverless를 지정합니다.

경우에 따라 클러스터에 이미 하나 이상의 프로비저닝된 리더 DB 인스턴스가 있을 수 있습니다. 그렇다면 새 DB 인스턴스를 생성하는 대신 리더 중 하나를 Aurora Serverless v2 DB 인스턴스로 변환할 수 있습니다. 이 작업을 수행하려면 프로비저닝된 라이터 또는 리더를 Aurora Serverless v2로 변환의 프로시저를 따르세요.
장애 조치 작업을 수행하여 Aurora Serverless v2 DB 인스턴스 중 하나를 클러스터의 라이터 DB 인스턴스로 만듭니다.
(선택 사항) 프로비저닝된 DB 인스턴스를 Aurora Serverless v2로 변환하거나 클러스터에서 제거합니다. 프로비저닝된 라이터 또는 리더를 Aurora Serverless v2로 변환 또는 Aurora DB 클러스터에서 DB 인스턴스 삭제의 일반 절차를 따르세요.

작은 정보
프로비저닝된 DB 인스턴스를 꼭 제거해야 하는 것은 아닙니다. Aurora Serverless v2 및 프로비저닝된 DB 인스턴스를 모두 포함하는 클러스터를 설정할 수 있습니다. 그러나 Aurora Serverless v2 DB 인스턴스의 성능 및 조정 특성에 익숙해질 때까지는 모두 동일한 유형의 DB 인스턴스로 클러스터를 구성하는 것이 좋습니다.

다음 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 Serverless v1 사용 사례를 Aurora Serverless v2에 적용하기

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 요구 사항
DB 엔진	Aurora MySQL, Aurora PostgreSQL	Aurora MySQL, Aurora PostgreSQL
지원되는 Aurora MySQL 버전	Aurora MySQL을 사용하는 Aurora Serverless v2 섹션을 참조하세요.	Aurora MySQL을 사용하는 Aurora Serverless v1 섹션을 참조하세요.
지원되는 Aurora PostgreSQL 버전	Aurora PostgreSQL을 사용하는 Aurora Serverless v2 섹션을 참조하세요.	Aurora PostgreSQL을 사용하는 Aurora Serverless v1 섹션을 참조하세요.
DB 클러스터 업그레이드	프로비저닝된 DB 클러스터에서처럼, Aurora가 DB 클러스터를 업그레이드할 때까지 기다리지 않고 수동으로 업그레이드를 수행할 수 있습니다. 자세한 내용은 Amazon Aurora DB 클러스터 수정 단원을 참조하십시오. 참고 Aurora PostgreSQL 호환 DB 클러스터를 13.x에서 14.x 또는 15.x로 메이저 버전 업그레이드하려면 클러스터의 최대 용량이 2 ACU 이상이어야 합니다.	마이너 버전 업그레이드는 출시되는 즉시 자동으로 적용됩니다. 자세한 내용은 Aurora Serverless v1 및 Aurora 데이터베이스 엔진 버전 단원을 참조하십시오. 메이저 버전 업그레이드는 수동으로 수행할 수 있습니다. 자세한 내용은 Aurora Serverless v1 DB 클러스터 수정 단원을 참조하십시오.
프로비저닝된 DB 클러스터에서 변환	다음 방법을 사용할 수 있습니다. 기존 프로비저닝된 클러스터에 하나 이상의 Aurora Serverless v2 리더 DB 인스턴스를 추가합니다. 라이터에 Aurora Serverless v2를 사용하려면 Aurora Serverless v2 DB 인스턴스 중 하나로 장애 조치를 수행합니다. 전체 클러스터에서 Aurora Serverless v2 DB 인스턴스를 사용하려면 Aurora Serverless v2 DB 인스턴스를 라이터로 승격한 후 프로비저닝된 라이터 DB 인스턴스를 제거하세요. 적절한 DB 엔진 및 엔진 버전으로 새 클러스터를 생성합니다. 표준 방법을 사용합니다. 예를 들어 클러스터 스냅샷을 복원하거나 기존 클러스터의 복제본을 생성합니다. 새 클러스터의 일부 또는 모든 DB 인스턴스에 대해 Aurora Serverless v2를 선택합니다. 복제를 통해 새 클러스터를 생성하는 경우 엔진 버전을 동시에 업그레이드할 수 없습니다. 원래 클러스터가 이미 Aurora Serverless v2와 호환되는 엔진 버전을 실행 중인지 확인합니다.	프로비저닝된 클러스터의 스냅샷을 복원하여 새 Aurora Serverless v1 클러스터를 생성합니다.
Aurora Serverless v1 클러스터에서 변환	Aurora Serverless v1 클러스터에서 Aurora Serverless v2로 업그레이드의 프로시저를 따르세요.	해당 사항 없음
사용 가능한 DB 인스턴스 클래스	특수 DB 인스턴스 클래스 B1 AWS Management Console에서는 Serverless 레이블이 지정됩니다.	해당 사항 없음. Aurora Serverless v1은 `serverless` 엔진 모드를 사용합니다.
Port	MySQL 또는 PostgreSQL과 호환되는 모든 포트	기본 MySQL 또는 PostgreSQL 포트만
퍼블릭 IP 주소는 허용되나요?	예	아니요
Virtual Private Cloud(VPC)가 필요한가요?	예	예 각 Aurora Serverless v1 클러스터는 VPC에 할당된 2개의 인터페이스와 게이트웨이 로드 밸런서 엔드포인트를 사용합니다.

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 용량 단위(ACU)(Aurora MySQL)	0.5	클러스터가 실행 중이면 1, 클러스터가 일시 중지되면 0입니다.
최소 ACU(Aurora PostgreSQL)	0.5	클러스터가 실행 중이면 2, 클러스터가 일시 중지되면 0입니다.
최대 ACU(Aurora MySQL)	128	256
최대 ACU(Aurora PostgreSQL)	128	384
클러스터 중지	프로비저닝된 클러스터와 동일한 클러스터 중지 및 시작 기능을 사용하여 클러스터를 수동으로 중지 및 시작할 수 있습니다.	클러스터는 시간 초과 후 자동으로 일시 중지됩니다. 활동이 재개되면 사용할 수 있게 되기까지 시간이 걸립니다.
DB 인스턴스 크기 조정	최소 0.5 ACU 증분으로 스케일 업 및 다운합니다.	ACU를 두 배로 늘리거나 반으로 줄여 스케일 업 및 다운합니다.
DB 인스턴스 개수	프로비저닝된 클러스터와 동일: 1개의 라이터 DB 인스턴스, 최대 15개의 리더 DB 인스턴스	읽기 및 쓰기를 모두 처리하는 DB 인스턴스 1개
SQL 문이 실행되는 동안 확장이 발생할 수 있나요?	예. Aurora Serverless v2는 조용한 지점을 기다릴 필요가 없습니다.	아니요. 예를 들어 확장은 장기 실행 트랜잭션, 임시 테이블 및 테이블 잠금이 완료될 때까지 기다립니다.
리더 DB 인스턴스는 라이터와 함께 확장됩니다.	선택 사항입니다.	해당 사항 없음.
최대 스토리지	128TiB	128TiB 또는 64TiB, 데이터베이스 엔진 및 버전에 따라 다름
확장 시 버퍼 캐시가 보관됨	예. 버퍼 캐시는 동적으로 크기가 조정됩니다.	아니요. 버퍼 캐시는 크기 조정 후 다시 예열됩니다.
장애 조치	예. 프로비저닝된 클러스터와 동일합니다.	최상의 노력만, 용량 가용성에 따라 다름 Aurora Serverless v2에서보다 느림
다중 AZ 기능	예. 예, 프로비저닝된 것과 동일합니다. 다중 AZ 클러스터에는 두 번째 가용 영역(AZ)에 리더 DB 인스턴스가 필요합니다. 다중 AZ 클러스터의 경우 Aurora는 AZ 장애가 발생할 경우 다중 AZ 장애 조치를 수행합니다.	Aurora Serverless v1 클러스터는 단일 AZ에서 모든 컴퓨팅을 실행합니다. AZ 장애 발생 시 최선을 다해 복구하지만 용량 가용성에 따라 달라질 수 있습니다.
Aurora 글로벌 데이터베이스	예	아니요
메모리 압력에 따라 크기 조정	예	아니요
CPU 로드에 따라 크기 조정	예	예
네트워크 트래픽에 따라 크기 조정	예. 네트워크 트래픽의 메모리 및 CPU 오버헤드를 기준으로 합니다. B1 파라미터는 축소 시 연결 끊김을 방지하기 위해 일정하게 유지됩니다.	예. 연결 수에 따라 다릅니다.
크기 조정 이벤트에 대한 시간 초과 작업	아니요	예
B1를 통해 클러스터에 새 DB 인스턴스 추가	해당 사항 없음. 프로모션 티어 2~15에서 B1 리더 DB 인스턴스를 생성하고 낮은 용량으로 축소된 상태로 둘 수 있습니다.	아니요. 리더 DB 인스턴스는 사용할 수 없습니다.

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

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

Aurora Serverless v2에서는 사용할 수 있지만 Aurora Serverless v1에서는 사용할 수 없는 기능
Aurora Serverless v1과 Aurora Serverless v2에서 다르게 작동하는 기능
현재 Aurora Serverless v2에서 사용할 수 없는 기능

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

기능	Aurora Serverless v2 지원	Aurora Serverless v1 지원
클러스터 토폴로지	Aurora Serverless v2는 개별 DB 인스턴스의 속성입니다. 클러스터에는 여러 Aurora Serverless v2 DB 인스턴스 또는 Aurora Serverless v2와 프로비저닝된 DB 인스턴스의 조합이 포함될 수 있습니다.	Aurora Serverless v1 클러스터는 DB 인스턴스의 개념을 사용하지 않습니다. 클러스터를 생성한 후에는 Aurora Serverless v1 속성을 변경할 수 없습니다.
구성 파라미터	프로비저닝된 클러스터에서와 거의 동일한 파라미터를 수정할 수 있습니다. 자세한 내용은 Aurora Serverless v2에 대한 파라미터 그룹 작업 페이지를 참조하세요.	파라미터의 하위 집합만 수정할 수 있습니다.
파라미터 그룹	클러스터 파라미터 그룹 및 DB 파라미터 그룹 `SupportedEngineModes` 속성에 `provisioned` 값이 있는 파라미터를 사용할 수 있습니다. Aurora Serverless v1보다 개수가 더 많은 파라미터입니다.	클러스터 파라미터 그룹만 해당 `SupportedEngineModes` 속성에 `serverless` 값이 있는 파라미터를 사용할 수 있습니다.
클러스터 볼륨에 대한 암호화	선택 사항	필수 사항입니다. Amazon Aurora 암호화된 DB 클러스터의 제한의 제한 사항은 모든 Aurora Serverless v1 클러스터에 적용됩니다.
리전 간 스냅샷	예	스냅샷은 자신의 AWS Key Management Service(AWS KMS) 키로 암호화해야 합니다.
DB 클러스터 삭제 후 자동 백업 유지	예	아니요
TLS/SSL	예. 지원은 프로비저닝된 클러스터와 동일합니다. 사용 정보는 Aurora Serverless v2에서 TLS/SSL 사용 단원을 참조하세요.	예. 프로비저닝된 클러스터에 대한 TLS 지원과 몇 가지 차이점이 있습니다. 사용 정보는 Aurora Serverless v1에서 TLS/SSL 사용 단원을 참조하세요.
복제	Aurora Serverless v2와 호환되는 DB 엔진 버전에서/버전으로만 가능합니다. 복제를 사용하여 Aurora Serverless v1 또는 프로비저닝된 클러스터의 이전 버전에서 업그레이드할 수 없습니다.	Aurora Serverless v1와 호환되는 DB 엔진 버전에서/버전으로만 가능합니다.
Amazon S3와 통합	예	예
AWS Secrets Manager와의 통합	아니요	아니요
S3로 DB 클러스터 스냅샷 내보내기	예	아니요
IAM 역할 연결	예	아니요
Amazon CloudWatch에 로그 업로드	선택 사항입니다. 켤 로그와 CloudWatch에 업로드할 로그를 선택합니다.	켜져 있는 모든 로그는 CloudWatch에 자동으로 업로드됩니다.
데이터 API 사용 가능	예	예
쿼리 편집기 사용 가능	예	예
성능 개선 도우미	예	아니요
Amazon RDS 프록시 사용 가능	예	아니요
Babelfish for Aurora PostgreSQL 사용 가능	예. Babelfish 및 Aurora Serverless v2 모두와 호환되는 Aurora PostgreSQL 버전에서 지원됩니다.	아니요

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 인스턴스는 이와 달리 해당 수치 사이의 값으로 확장할 수 있습니다.

워크로드에 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 MySQL 버전 2(MySQL 5.7 호환)를 실행하는 Aurora Serverless v1 클러스터를 업그레이드하는 방법

Aurora Serverless v1 DB 클러스터를 프로비저닝된 Aurora MySQL 버전 2 클러스터로 변환합니다. Aurora Serverless v1에서 프로비저닝으로 변환의 프로시저를 따르세요.
블루/그린 배포를 생성합니다. 블루/그린 배포 생성의 프로시저를 따르세요.
그린 클러스터에는 Aurora Serverless v2와 호환되는 Aurora MySQL 버전을 선택하세요(예: 3.04.1).

호환 가능한 버전은 Aurora MySQL을 사용하는 Aurora Serverless v2 섹션을 참조하세요.
그린 클러스터의 라이터 DB 인스턴스를 수정하여 Serverless v2(db.serverless) DB 인스턴스 클래스를 사용하도록 합니다.

세부 정보는 프로비저닝된 라이터 또는 리더를 Aurora Serverless v2로 변환을 참조하세요.
업그레이드된 Aurora Serverless v2 DB 클러스터를 사용할 수 있게 되면 블루 클러스터에서 그린 클러스터로 전환합니다.

Aurora PostgreSQL 호환 DB 클러스터

블루/그린 배포를 사용하여 Aurora PostgreSQL 버전 11을 실행하는 Aurora Serverless v1 클러스터를 업그레이드하는 방법

Aurora Serverless v1 DB 클러스터를 프로비저닝된 Aurora PostgreSQL 클러스터로 변환합니다. Aurora Serverless v1에서 프로비저닝으로 변환의 프로시저를 따르세요.
블루/그린 배포를 생성합니다. 블루/그린 배포 생성의 프로시저를 따르세요.
그린 클러스터에는 Aurora Serverless v2와 호환되는 Aurora PostgreSQL 버전을 선택하세요(예: 15.3).

호환 가능한 버전은 Aurora PostgreSQL을 사용하는 Aurora Serverless v2 섹션을 참조하세요.
그린 클러스터의 라이터 DB 인스턴스를 수정하여 Serverless v2(db.serverless) DB 인스턴스 클래스를 사용하도록 합니다.

세부 정보는 프로비저닝된 라이터 또는 리더를 Aurora Serverless v2로 변환을 참조하세요.
업그레이드된 Aurora Serverless v2 DB 클러스터를 사용할 수 있게 되면 블루 클러스터에서 그린 클러스터로 전환합니다.

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

Aurora PostgreSQL 버전 11을 실행하는 Aurora Serverless v1 클러스터를 업그레이드하고 변환하는 방법

Aurora Serverless v1 클러스터를 Aurora Serverless v2와 호환되는 Aurora PostgreSQL 버전 13 버전(예: 13.12)으로 업그레이드합니다. 메이저 버전 업그레이드의 프로시저를 따르세요.

호환 가능한 버전은 Aurora PostgreSQL을 사용하는 Aurora Serverless v2 섹션을 참조하세요.
Aurora Serverless v1 DB 클러스터를 프로비저닝된 Aurora PostgreSQL 클러스터로 변환합니다. Aurora Serverless v1에서 프로비저닝으로 변환의 프로시저를 따르세요.
클러스터에 Aurora Serverless v2 리더 DB 인스턴스를 추가합니다. 자세한 내용은 Aurora Serverless v2 리더 추가 단원을 참조하십시오.
Aurora Serverless v2 DB 인스턴스에 대한 장애 조치:
1. DB 클러스터의 라이터 DB 인스턴스를 선택합니다.
2. 작업(Actions)으로 장애 조치(Failover)를 선택합니다.
3. 확인 페이지에서 장애 조치를 선택합니다.

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

Aurora PostgreSQL 버전 13을 실행하는 Aurora Serverless v1 클러스터를 업그레이드하려면

Aurora Serverless v1 DB 클러스터를 프로비저닝된 Aurora PostgreSQL 클러스터로 변환합니다. Aurora Serverless v1에서 프로비저닝으로 변환의 프로시저를 따르세요.
클러스터에 Aurora Serverless v2 리더 DB 인스턴스를 추가합니다. 자세한 내용은 Aurora Serverless v2 리더 추가 단원을 참조하십시오.
Aurora Serverless v2 DB 인스턴스에 대한 장애 조치:
1. DB 클러스터의 라이터 DB 인스턴스를 선택합니다.
2. 작업(Actions)으로 장애 조치(Failover)를 선택합니다.
3. 확인 페이지에서 장애 조치를 선택합니다.

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

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

MySQL 데이터베이스의 경우 mysqldump 명령을 사용할 수 있습니다. 자세한 내용은 가동 중지 시간을 단축하여 Amazon RDS MySQL MariaDB DB 인스턴스로 데이터 가져오기를 참조하세요.
PostgreSQL 데이터베이스의 경우 pg_dump 및 pg_restore 명령을 사용할 수 있습니다. 자세한 내용은 블로그 게시물 PostgreSQL 데이터베이스를 Amazon RDS 및 Amazon Aurora로 마이그레이션하기 위한 모범 사례를 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Aurora Serverless v2의 성능 및 크기 조정

사용 Aurora Serverless v1