Aurora Serverless v1 작동 방식 - Amazon Aurora
Aurora Serverless v1 아키텍처AutoScaling제한 시간 조치일시 중지 및 다시 시작max_connections 결정파라미터 그룹로깅유지 관리장애 조치스냅샷

Aurora Serverless v1 작동 방식

다음으로 Aurora Serverless v1 작동 방식을 알아볼 수 있습니다.

Aurora Serverless v1 아키텍처

다음 이미지는 Aurora Serverless v1 아키텍처의 개요를 보여줍니다.

Aurora Serverless v1 아키텍처

데이터베이스 서버를 프로비저닝 및 관리하는 대신 ACU(Aurora 용량 단위)를 지정합니다. 각 ACU는 약 2GB 메모리, 해당 CPU 및 네트워킹의 조합입니다. 데이터베이스 스토리지는 표준 Aurora DB 클러스터의 스토리지와 동일한 10기비바이트(GiB)~128 tebibytes (TiB) 범위에서 자동으로 규모를 조정합니다.

최소 및 최대 ACU를 지정할 수 있습니다. 최소 Aurora 용량 단위는 DB 클러스터를 축소할 수 있는 가장 낮은 ACU입니다. 최대 Aurora 용량 단위는 DB 클러스터를 확장할 수 있는 가장 높은 ACU입니다. Aurora Serverless v1는 설정에 따라 CPU 사용률, 연결 및 가용 메모리 임계값에 대한 조정 규칙을 자동으로 생성합니다.

Aurora Serverless v1는 조정 시간을 최소화하기 위해 AWS 리전에서 리소스의 웜 풀을 관리합니다. Aurora Serverless v1이 Aurora DB 클러스터에 새 리소스를 추가하면 라우터 플릿을 사용하여 활성 클라이언트 연결을 새 리소스로 전환합니다. 특정 시간에 Aurora DB 클러스터에서 사용 중인 ACU에 대해서 비용이 청구됩니다.

Aurora Serverless v1에서의 Auto Scaling

Aurora Serverless v1 DB 클러스터에 할당된 용량은 클라이언트 애플리케이션에서 생성된 로드에 따라 원활하게 확장 및 축소됩니다. 여기서 부하는 CPU 사용률과 연결 수입니다. 이 중 하나에 의해 용량이 제한되는 경우, Aurora Serverless v1가 확장됩니다. 또한 Aurora Serverless v1는 이를 통해 해결할 수 있는 성능 문제를 감지한 경우에도 확장됩니다.

Aurora Serverless v1의 AWS Management Console 클러스터에 대한 크기 조정 이벤트를 볼 수 있습니다. Auto Scaling 동안 Aurora Serverless v1는 EngineUptime 지표를 재설정합니다. 재설정 지표 값은 원활한 크기 조정에 문제가 있다거나 Aurora Serverless v1 연결이 끊어졌음을 의미하지 않습니다. 이는 단순히 새로운 용량에서의 가동 시간 시작점일 뿐입니다. 지표에 대해 자세히 알아보려면 Amazon Aurora 클러스터에서 지표 모니터링 섹션을 참조하세요.

Aurora Serverless v1 DB 클러스터에 활성 연결이 없는 경우 용량을 0(ACU 0)으로 축소할 수 있습니다. 자세한 내용은 Aurora Serverless v1 일시 중지 및 다시 시작 단원을 참조하십시오.

크기 조정 작업을 수행해야 하는 경우, Aurora Serverless v1는 먼저 쿼리가 처리되지 않는 순간을 의미하는 조정점을 찾으려 합니다. 다음과 같은 이유로 Aurora Serverless v1가 조정점을 찾지 못할 수 있습니다.

  • 장기 실행 쿼리

  • 진행 중인 트랜잭션

  • 임시 테이블 또는 테이블 잠금

조정점을 찾을 때 Aurora Serverless v1 DB 클러스터의 성공률을 높이려면 장기 실행 쿼리와 장기 실행 트랜잭션을 피하는 것이 좋습니다. 크기 조정을 저해하는 작업과 이러한 작업을 방지하는 방법에 대한 자세한 내용은 Aurora Serverless v1 작업 모범 사례를 참조하세요.

기본값으로 Aurora Serverless v1은(는) 5분(300초) 동안 크기 조정점을 찾으려고 시도합니다. 클러스터를 생성하거나 수정할 때 다른 제한 시간을 지정할 수 있습니다. 제한 시간은 60초에서 10분(600초) 사이일 수 있습니다. Aurora Serverless v1이(가) 지정 기간 내에 크기 조정점을 찾지 못하면 자동 크기 조정 작업 시간이 초과됩니다.

Auto Scaling이 시간 초과되기 전에 조정점을 찾지 못할 경우, 기본적으로 Aurora Serverless v1는 클러스터를 현재 용량으로 유지합니다. 이 기본 동작은 Aurora Serverless v1 DB 클러스터를 생성하거나 수정할 때 용량 변경 강제 적용 옵션을 선택하여 변경할 수 있습니다. 자세한 내용은 용량 변경을 위한 제한 시간 조치 섹션을 참조하세요.

용량 변경을 위한 제한 시간 조치

크기 조정점 찾기로 인해 자동 크기 조정이 시간 초과되면 기본적으로 Aurora는 현재 용량을 유지합니다. [용량 변경 강제 적용(Force capacity change)] 옵션을 활성화하여 Aurora가 용량 변경을 강제 적용하도록 선택할 수 있습니다. 이 옵션은 클러스터를 생성할 때 데이터베이스 생성(Create database) 페이지의 자동 크기 조정 시간 초과 및 작업(Autoscaling timeout and action) 섹션에서 사용할 수 있습니다.

기본적으로 [용량 변경 강제 적용(Force capacity change)] 옵션은 선택되어 있지 않습니다. 크기 조정 지점을 찾지 못하고 크기 조정 작업이 시간 초과될 경우 Aurora Serverless v1 DB 클러스터의 용량이 변경되지 않도록 하려면 이 옵션을 선택하지 않은 상태로 둡니다.

이 옵션을 선택하면 조정점 없이도 Aurora Serverless v1 DB 클러스터에 용량 변경이 적용됩니다. 이 옵션을 선택하기 전에 이 선택의 결과를 고려해야 합니다.

  • 진행 중인 트랜잭션이 중단되고 다음과 같은 오류 메시지가 나타납니다.

    Aurora MySQL 버전 2 - 오류 1105(HY000): 원활한 크기 조정으로 인해 마지막 트랜잭션이 중단되었습니다. 다시 시도하세요.

    Aurora Serverless v1 DB 클러스터를 사용할 수 있게 되는 즉시 트랜잭션을 다시 제출할 수 있습니다.

  • 임시 테이블 및 잠금에 대한 연결이 삭제됩니다.

    끊긴 연결이나 불완전한 트랜잭션으로부터 애플리케이션을 복구할 수 있는 경우에만 [용량 변경 강제 적용(Force capacity change)] 옵션을 선택하는 것이 좋습니다.

AWS Management Console DB 클러스터를 생성할 때 Aurora Serverless v1에서 선택하는 옵션은 ScalingConfigurationInfo 객체의 SecondsBeforeTimeout 및 TimeoutAction 속성에 저장됩니다. TimeoutAction 속성의 값은 클러스터를 생성할 때 다음 값 중 하나로 설정됩니다.

  • RollbackCapacityChange - 이 값은 용량 변경 롤백 옵션을 선택할 때 설정됩니다. 이는 기본 설정 동작입니다.

  • ForceApplyCapacityChange - 이 값은 용량 변경 강제 수행 옵션을 선택할 때 설정됩니다.

다음과 같이 describe-db-clusters Aurora Serverless v1 명령을 사용하여 기존 AWS CLI DB 클러스터에서 이 속성 값을 가져올 수 있습니다.

Linux, macOS, Unix:

aws rds describe-db-clusters --region region \
  --db-cluster-identifier your-cluster-name \
  --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Windows의 경우:

aws rds describe-db-clusters --region region ^
  --db-cluster-identifier your-cluster-name ^
  --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

예를 들어 다음은 미국 서부(캘리포니아 북부) 리전의 west-coast-sles(이)라는 Aurora Serverless v1 DB 클러스터에 대한 쿼리 및 응답을 보여줍니다.

$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles 
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

[
    {
        "ScalingConfigurationInfo": {
            "MinCapacity": 1,
            "MaxCapacity": 64,
            "AutoPause": false,
            "SecondsBeforeTimeout": 300,
            "SecondsUntilAutoPause": 300,
            "TimeoutAction": "RollbackCapacityChange"
        }
    }
]

응답에서 알 수 있듯이, 이 Aurora Serverless v1 DB 클러스터는 기본 설정을 사용합니다.

자세한 내용은 Aurora Serverless v1 DB 클러스터 생성 섹션을 참조하세요. Aurora Serverless v1를 생성한 후 시간 초과 작업 및 기타 용량 설정을 언제든지 수정할 수 있습니다. 자세한 방법은 Aurora Serverless v1 DB 클러스터 수정 단원을 참조하십시오.

Aurora Serverless v1 일시 중지 및 다시 시작

활동 없이 지정된 시간이 경과하면 Aurora Serverless v1 DB 클러스터를 일시 중지하도록 선택할 수 있습니다. DB 클러스터를 일시 중지하기 전에 활동 없이 경과하는 시간을 지정합니다. 이 옵션을 선택하면 활동이 없는 기본 시간은 5분이지만 이 값을 변경할 수 있습니다. 이는 선택적 설정입니다.

DB 클러스터가 일시 중지되면 컴퓨팅 또는 메모리 활동이 발생하지 않고 스토리지에 대한 요금만 청구됩니다. Aurora Serverless v1 DB 클러스터가 일시 중지되었을 때 데이터베이스 연결이 요청되면 DB 클러스터가 자동으로 작동을 재개해 연결 요청을 처리합니다.

DB 클러스터가 활동을 재개하면 Aurora이 클러스터를 일시 중지했을 때와 동일한 용량을 갖게 됩니다. ACU의 수는 클러스터를 일시 중지하기 전에 Aurora이 클러스터를 확장하거나 축소한 정도에 따라 달라집니다.

참고

DB 클러스터가 8일 이상 일시 중지된 경우 스냅샷을 사용하여 DB 클러스터를 백업할 수 있습니다. 이 경우 Aurora은 연결 요청이 있을 때 스냅샷에서 DB 클러스터를 복원합니다.

Aurora Serverless v1에 대한 최대 데이터베이스 연결 수 결정

다음은 MySQL 5.7과 호환되는 Aurora Serverless v1 DB 클러스터에 대한 예입니다. 액세스를 구성한 경우 MySQL 클라이언트 또는 쿼리 편집기를 사용할 수 있습니다. 자세한 내용은 쿼리 편집기에서 쿼리 실행 섹션을 참조하세요.

최대 데이터베이스 연결 수를 확인하려면

  1. AWS CLI를 사용하여 Aurora Serverless v1 DB 클러스터의 용량 범위를 확인합니다.

    aws rds describe-db-clusters \
    --db-cluster-identifier my-serverless-57-cluster \
    --query 'DBClusters[*].ScalingConfigurationInfo|[0]'

    그 결과 용량 범위가 1~4 ACU임을 알 수 있습니다.

    {
    "MinCapacity": 1,
    "AutoPause": true,
    "MaxCapacity": 4,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

  2. 다음 SQL 쿼리를 실행하여 최대 연결 수를 확인합니다.

    select @@max_connections;

    결과로 클러스터의 최소 용량인 1 ACU가 표시됩니다.

    @@max_connections
90

  3. 클러스터를 8~32 ACU로 확장합니다.

    조정에 대한 자세한 내용은 Aurora Serverless v1 DB 클러스터 수정 섹션을 참조하세요.

  4. 용량 범위를 확인합니다.

    {
    "MinCapacity": 8,
    "AutoPause": true,
    "MaxCapacity": 32,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

  5. 최대 연결 수를 확인합니다.

    select @@max_connections;

    결과로 클러스터의 최소 용량인 8 ACU가 표시됩니다.

    @@max_connections
1000

  6. 클러스터를 가능한 최대 범위인 256~256 ACU로 확장합니다.

  7. 용량 범위를 확인합니다.

    {
    "MinCapacity": 256,
    "AutoPause": true,
    "MaxCapacity": 256,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

  8. 최대 연결 수를 확인합니다.

    select @@max_connections;

    결과로 256 ACU가 표시됩니다.

    @@max_connections
6000
    참고

    max_connections 값은 ACU 수에 따라 선형적으로 확장되지 않습니다.

  9. 클러스터를 1~4 ACU로 다시 축소합니다.

    {
    "MinCapacity": 1,
    "AutoPause": true,
    "MaxCapacity": 4,
    "TimeoutAction": "RollbackCapacityChange",
    "SecondsUntilAutoPause": 3600
}

    이번에는 max_connections 값이 4 ACU로 나타납니다.

    @@max_connections
270

  10. 클러스터를 2 ACU로 축소합니다.

    @@max_connections
180

    일정한 유휴 시간이 지나면 일시 중지하도록 클러스터를 구성한 경우 0 ACU로 축소됩니다. 단, max_connections는 1 ACU 값 이하로 줄어들지 않습니다.

    @@max_connections
90

Aurora Serverless v1 파라미터 그룹

Aurora Serverless v1 DB 클러스터를 생성할 때 특정 Aurora DB 엔진과 관련 DB 클러스터 파라미터 그룹을 선택합니다. 프로비저닝된 Aurora DB 클러스터와 달리, Aurora Serverless v1 DB 클러스터에는 별도의 DB 파라미터 그룹이 없고 하나의 DB 클러스터 파라미터 그룹으로만 구성된 단일 읽기/쓰기 DB 인스턴스가 있습니다.— Auto Scaling 중에 Aurora Serverless v1는 증가 또는 감소된 용량에 가장 적합하도록 클러스터의 파라미터를 변경할 수 있어야 합니다. 즉, Aurora Serverless v1 DB 클러스터의 경우, 특정 DB 엔진 유형에 대한 파라미터 변경 사항 중 일부가 적용되지 않을 수 있습니다.

예를 들어 Aurora PostgreSQL–기반 Aurora Serverless v1 DB 클러스터는 프로비저닝된 Aurora PostgreSQL DB 클러스터에서 쿼리 계획 관리에 사용되는 apg_plan_mgmt.capture_plan_baselines 및 기타 파라미터를 사용할 수 없습니다.

describe-engine-default-cluster-parameters CLI 명령을 사용하고 AWS 리전을 쿼리하여 다양한 Aurora DB 엔진의 기본 파라미터 그룹의 기본값 목록을 가져올 수 있습니다. --db-parameter-group-family 옵션에 사용할 수 있는 값은 다음과 같습니다.

Aurora MySQL 버전 2

aurora-mysql5.7

Aurora PostgreSQL 버전 11

aurora-postgresql11

Aurora PostgreSQL 버전 13

aurora-postgresql13

AWS CLI 명령을 사용하기 전에 AWS 액세스 키 ID 및 AWS 보안 액세스 키를 사용하여 AWS 리전를 구성하고 AWS CLI를 설정하는 것이 좋습니다. CLI 구성에 리전을 설정하면 명령을 실행할 때 --region 파라미터를 입력할 필요가 없습니다. AWS CLI 구성에 대한 자세한 내용은 AWS Command Line Interface 사용 설명서에서 구성 기본 사항을 참조하세요.

다음 예시에서는 Aurora MySQL 버전 2의 기본 DB 클러스터 그룹에서 파라미터 목록을 가져옵니다.

Linux, macOS, Unix:

aws rds describe-engine-default-cluster-parameters \
  --db-parameter-group-family aurora-mysql5.7 --query \
  'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
  --output text

Windows의 경우:

aws rds describe-engine-default-cluster-parameters ^
   --db-parameter-group-family aurora-mysql5.7 --query ^
   "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
   --output text

Aurora Serverless v1의 파라미터 값 수정

파라미터 그룹 작업에서 설명한 것처럼, 유형(DB 클러스터 파라미터 그룹, DB 파라미터 그룹)에 관계없이 기본 파라미터 그룹에서 값을 직접 변경할 수는 없습니다. 대신, 기본 DB 클러스터 파라미터 그룹을 기반으로 Aurora DB 엔진에 사용할 사용자 지정 파라미터 그룹을 생성하고 해당 파라미터 그룹에서 필요에 따라 설정을 변경합니다. 예를 들어 다음과 같이 Amazon CloudWatch에 쿼리를 로깅하거나 DB 엔진별 로그 업로드하도록 Aurora Serverless v1 DB 클러스터의 일부 설정을 변경할 수 있습니다.

사용자 지정 DB 클러스터 파라미터 그룹을 생성하려면

  1. AWS Management Console에 로그인하고 ttps://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 파라미터 그룹을 선택합니다.

  3. [파라미터 그룹 생성(Create parameter group)] 선택하여 파라미터 그룹 세부 정보 창을 엽니다.

  4. DB 클러스터에 사용할 DB 엔진에 적합한 기본 Aurora Serverless v1 DB 클러스터 그룹을 선택합니다. 다음과 같은 옵션을 선택할 수 있습니다.

    1. [파라미터 그룹 패밀리(Parameter group family)]에서, 선택한 DB 엔진에 적합한 패밀리를 선택합니다. 선택 항목의 이름에 aurora- 접두어가 있어야 합니다.

    2. [Type]에서 [DB Cluster Parameter Group]을 선택합니다.

    3. [그룹 이름(Group name)] 및 [설명(Description)] 에 Aurora Serverless v1 DB 클러스터 및 해당 파라미터로 작업해야 하는 사용자가 알기 쉬운 이름을 입력합니다.

    4. 생성을 선택합니다.

사용자 지정 DB 클러스터 파라미터 그룹이 AWS 리전에서 사용할 수 있는 파라미터 그룹 목록에 추가됩니다. 새 DB 클러스터를 생성할 때 사용자 지정 Aurora Serverless v1 DB 클러스터 파라미터 그룹을 사용할 수 있습니다. 사용자 지정 Aurora Serverless v1 DB 클러스터 파라미터 그룹을 사용하도록 기존 DB 클러스터를 수정할 수도 있습니다. Aurora Serverless v1 DB 클러스터가 사용자 지정 DB 클러스터 파라미터 그룹을 사용하기 시작하면 AWS Management Console 또는 AWS CLI를 사용하여 동적 파라미터의 값을 변경할 수 있습니다.

다음 스크린샷과 같이 콘솔을 사용하여 사용자 지정 DB 클러스터 파라미터 그룹의 값을 기본 DB 클러스터 파라미터 그룹의 값과 나란히 비교할 수도 있습니다.

CloudWatch Logs for Aurora MySQL 및 Aurora PostgreSQL Aurora Serverless v1 DB 클러스터에 게시된 로그

활성 DB 클러스터의 파라미터 값을 변경하면 Aurora Serverless v1는 파라미터 변경 사항을 적용하기 위해 원활한 크기 조정을 시작합니다. Aurora Serverless v1 DB 클러스터가 일시 중지됨 상태인 경우 변경 작업을 수행할 수 있도록 클러스터가 다시 시작되어 크기 조정을 시작합니다. 파라미터 그룹의 크기 조정 작업은 항상 용량 변경을 강제로 적용하므로 크기 조정 기간 동안 조정점을 찾을 수 없는 경우 파라미터를 수정하면 연결이 끊어질 수 있습니다.

Aurora Serverless v1의 로깅

Aurora Serverless v1의 오류 로그는 기본적으로 활성화되고 Amazon CloudWatch에 자동으로 업로드됩니다. Aurora 데이터베이스 엔진별 로그를 CloudWatch에 DB 클러스터를 업로드하도록 할 수도 있습니다. 이를 위해 사용자 지정 DB 클러스터 파라미터 그룹에서 구성 파라미터를 활성화합니다. 그런 다음 Aurora Serverless v1 DB 클러스터는 사용 가능한 모든 로그를 Amazon CloudWatch에 업로드합니다. 이 시점에서 CloudWatch를 통해 로그 데이터에 대한 분석을 수행할 수 있으며 경보를 만들고 지표를 볼 수 있습니다.

Aurora MySQL의 경우 다음 표에 나와 있는 로그를 활성화할 수 있습니다. 로그가 활성화되면 Aurora Serverless v1 DB 클러스터에서 Amazon CloudWatch로 자동 업로드됩니다.

Aurora MySQL 로그 설명

general_log

일반 로그를 생성합니다. 활성화하려면 1로 설정합니다. 기본값은 비활성화(0)입니다.

log_queries_not_using_indexes

인덱스를 사용하지 않는 느린 쿼리 로그에 모든 쿼리를 로깅합니다. 기본값은 비활성화(0)입니다. 이 로그를 활성화하려면 1로 설정합니다.

long_query_time

빠른 실행 쿼리가 느린 쿼리 로그에 로깅되지 않도록 합니다. 0에서 3,1536,000 사이의 부동 소수점 값으로 설정할 수 있습니다. 기본값은 0(비활성화)입니다.

server_audit_events

로그에 캡처할 이벤트 목록입니다. 지원되는 값은 CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML 및 TABLE입니다.

server_audit_logging

서버 감사 로깅을 활성화하려면 1로 설정합니다. 이 옵션을 설정하면 server_audit_events 매개 변수에 감사 이벤트를 CloudWatch 나열하여 보낼 감사 이벤트를 지정할 수 있습니다.

slow_query_log

느린 쿼리 로그를 생성합니다. 느린 쿼리 로그를 활성화하려면 1로 설정합니다. 기본값은 비활성화(0)입니다.

자세한 내용은 Amazon Aurora MySQL DB 클러스터에서 고급 감사 사용 섹션을 참조하세요.

Aurora PostgreSQL의 경우 다음 표에 나와 있는 로그를 활성화할 수 있습니다. 로그가 활성화되면 일반적인 오류 로그와 함께 Aurora Serverless v1 DB 클러스터에서 Amazon CloudWatch로 자동 업로드됩니다.

Aurora PostgreSQL 로그 설명

log_connections

기본적으로 켜지며 변경할 수 없습니다. 모든 새 클라이언트 연결에 대한 세부 정보를 로깅합니다.

log_disconnections

기본적으로 켜지며 변경할 수 없습니다. 모든 클라이언트 연결 해제를 로깅합니다.

log_hostname

기본적으로 비활성화 상태이며 값을 변경할 수 없습니다. 호스트 이름은 로깅되지 않습니다.

log_lock_waits

기본값은 0(비활성화)입니다. 잠금 대기를 로깅하려면 1로 설정합니다.

log_min_duration_statement

로깅하기 전에 문을 실행할 최소 시간(밀리초)입니다.

log_min_messages

기록되는 메시지 수준을 설정합니다. 지원되는 값은 debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic입니다.

성능 데이터를 postgres 로그에 로깅하려면 이 값을 debug1로 설정합니다.

log_temp_files

지정된 KB(킬로바이트)를 초과하는 임시 파일 사용을 로깅합니다.

log_statement

로깅되는 특정 SQL 문을 제어합니다. 지원되는 값은 none, ddl, mod 및 all입니다. 기본값은 none.

Aurora Serverless v1 DB 클러스터에 대해 Aurora MySQL 또는 Aurora PostgreSQL 로그를 활성화하고 나면, CloudWatch에서 로그를 볼 수 있습니다.

Amazon CloudWatch를 사용하여 Aurora Serverless v1 로그 보기

Aurora Serverless v1은 사용자 지정 DB 클러스터 파라미터 그룹에서 활성화한 모든 로그를 Amazon CloudWatch에 자동으로 업로드('게시')합니다. 따라서 로그 유형을 선택하거나 지정할 필요가 없습니다. 로그 구성 파라미터를 활성화하는 즉시 로그 업로드가 시작됩니다. 나중에 로그 파라미터를 비활성화하면 추가 업로드가 중지됩니다. 하지만 CloudWatch에 이미 게시된 모든 로그는 삭제할 때까지 유지됩니다.

Aurora MySQL 로그에 CloudWatch을 사용하는 방법에 대한 자세한 내용은 Amazon CloudWatch에서 로그 이벤트 모니터링 섹션을 참조하세요.

CloudWatch 및 Aurora PostgreSQL에 대한 자세한 내용은 Amazon CloudWatch Logs에 Aurora PostgreSQL 로그 게시 단원을 참조하십시오.

Aurora Serverless v1 DB 클러스터에 대한 로그를 보려면

  1. https://console.aws.amazon.com/cloudwatch/에서 CloudWatch 콘솔을 엽니다.

  2. AWS 리전를 선택합니다.

  3. 로그 그룹을 선택합니다.

  4. 목록에서 Aurora Serverless v1 DB 클러스터 로그를 선택합니다. 오류 로그의 경우 이름 지정 패턴은 다음과 같습니다.

    /aws/rds/cluster/cluster-name/error

예를 들어 다음 스크린샷에는 Aurora Serverless v1라는 Aurora PostgreSQL western-sles DB 클러스터에 대해 게시된 로그의 목록이 나와 있습니다. 또한 Aurora MySQL Aurora Serverless v1 DB 클러스터 west-coast-sles에 대한 몇 가지 목록이 나와 있습니다. 관심 있는 로그를 선택하여 해당 콘텐츠를 탐색할 수 있습니다.

CloudWatch Logs for Aurora MySQL 및 Aurora PostgreSQL Aurora Serverless v1 DB 클러스터에 게시된 로그

Aurora Serverless v1 및 유지 관리

Aurora Serverless v1 DB 클러스터에 대한 유지 관리(예: 최신 기능, 수정, 보안 업데이트 적용)가 자동으로 수행됩니다. Aurora Serverless v1에는 유지 관리 기간이 있으며 Aurora Serverless v1 DB 클러스터에 대한 유지 관리 및 백업의 AWS Management Console에서 확인할 수 있습니다. 다음 그림과 같이 유지 관리가 수행될 수 있는 날짜 및 시간과 Aurora Serverless v1 DB 클러스터에 대해 대기 중인 유지 관리 작업을 확인할 수 있습니다.

예시 Aurora Serverless v1 DB 클러스터의 유지 관리 기간(대기 중인 유지 관리 없음)

Aurora Serverless v1 DB 클러스터를 생성할 때 유지 관리 기간을 설정하고 나중에 기간을 수정할 수 있습니다. 자세한 내용은 기본 DB 클러스터 유지 관리 기간 조정 섹션을 참조하세요.

유지 관리 기간은 예약된 메이저 버전 업그레이드에 사용됩니다. 마이너 버전 업그레이드 및 패치는 규모 조정 중에 즉시 적용됩니다. 규모 조정은 다음과 같은 TimeoutAction 설정에 따라 이루어집니다.

  • ForceApplyCapacityChange - 변경 사항이 즉시 적용됩니다.

  • RollbackCapacityChange - Aurora가 첫 번째 패치를 시도한 지 3일 후에 클러스터를 강제로 업데이트합니다.

적절한 조정점 없이 강제로 변경되는 여타의 경우와 마찬가지로, 이로 인해 워크로드가 중단될 수 있습니다.

Aurora Serverless v1는 가능하면 운영 중단 없이 유지 관리 작업을 수행합니다. 유지 관리가 필요한 경우 Aurora Serverless v1 DB 클러스터는 필요한 작업을 처리할 수 있도록 용량을 확장합니다. Aurora Serverless v1은 크기 조정 전에 크기 조정 시점을 찾습니다. 필요한 경우 최대 3일 동안 이를 수행합니다.

결국 Aurora Serverless v1가 조정점을 찾지 못하면 클러스터 이벤트를 생성합니다. 이 이벤트는 대기 중인 유지 관리 작업과 유지 관리를 수행하기 위해 확장해야 하는 필요성을 알려줍니다. 알림에는 Aurora Serverless v1가 DB 클러스터를 강제로 확장할 수 있는 날짜가 포함됩니다.

자세한 내용은 용량 변경을 위한 제한 시간 조치 섹션을 참조하세요.

Aurora Serverless v1 및 장애 조치

Aurora Serverless v1 DB 클러스터의 DB 인스턴스를 사용할 수 없게 되거나 가용 영역(AZ)에 장애가 발생하면 Aurora가 다른 AZ에서 DB 인스턴스를 재생성합니다. 그러나 Aurora Serverless v1 클러스터는 다중 AZ 클러스터가 아닙니다. 이는 단일 AZ의 단일 DB 인스턴스로 구성되기 때문입니다. 이러한 장애 조치 메커니즘은 Aurora 프로비저닝된 클러스터보다 시간이 오래 걸립니다. Aurora Serverless v1 장애 조치 시간은 해당 AWS 리전 내 다른 AZ의 수요 및 용량 가용성에 따라 다르기 때문에 정의되어 있지 않습니다.

Aurora는 컴퓨팅 용량과 스토리지를 분리하기 때문에 클러스터의 스토리지 볼륨은 다중 AZ로 분산됩니다. 따라서 시스템 중단으로 DB 인스턴스 또는 연결된 AZ가 영향을 받더라도 데이터는 계속해서 사용할 수 있습니다.

Aurora Serverless v1 및 스냅샷

Aurora Serverless v1 클러스터의 클러스터 볼륨은 항상 암호화됩니다. 암호화 키를 선택할 수 있지만 암호화를 비활성화할 수는 없습니다. Aurora Serverless v1 클러스터의 스냅샷을 복사하거나 공유하려면 사용자 고유의 AWS KMS key을(를) 사용해 스냅샷을 암호화합니다. 자세한 내용은 DB 클러스터 스냅샷 복사 섹션을 참조하세요. 암호화 및 Amazon Aurora에 대한 자세한 내용은 Amazon Aurora DB 클러스터 암호화 섹션을 참조하세요.