AWS Organizations에서 Amazon Aurora 및 Amazon RDS 자동 마이너 버전 업그레이드를 위한 업그레이드 롤아웃 정책 지원

이 글은 AWS Database Blog에 게시된 AWS Organizations now supports upgrade rollout policy for Amazon Aurora and Amazon RDS automatic minor version upgrades by Sukhpreet Kaur Bedi, Jonathan Topping, Aditya Khosla, and William Doan을 한국어 번역 및 편집하였습니다.

데이터베이스 엔진을 마이너 버전 업그레이드로 최신 상태로 유지하는 것은 안전하고 신뢰할 수 있는 애플리케이션을 유지하는 데 중요합니다. 이러한 업그레이드는 새로운 기능, 확장 업데이트, 보안 패치 및 버그 수정을 제공합니다. Amazon Aurora와 Amazon Relational Database Service (Amazon RDS)는 고객이 이러한 업데이트를 최신 상태로 유지할 수 있도록 관리형 서비스 제공의 일부로 자동 마이너 버전 업그레이드(AmVU)를 제공합니다.

고객들은 AWS Organizations를 사용하여 조직 전체에서 운영을 간소화하고 리소스 관리를 표준화합니다. 기업이 AWS 사용 범위를 확장함에 따라 보안 및 규정 준수 모범 사례를 따르면서 환경 전반에서 데이터베이스 버전 업그레이드를 관리하는 중앙 집중식 메커니즘이 필요합니다. 일반적으로 조직에서는 잠재적인 장애 위험을 최소화하기 위해 비즈니스 크리티컬 환경으로 이동하기 전에 덜 중요한 환경에서 먼저 배포하여 이러한 변경 사항은 수동 배포를 통해 단계적으로 적용합니다.

AWS Organizations는 이제 업그레이드 롤아웃 정책을 지원합니다. 이는 데이터베이스 플릿 전반의 자동 마이너 버전 업그레이드를 관리할 수 있는 간소화된 솔루션을 제공하는 새로운 기능입니다. 이 기능은 Amazon Aurora MySQL 호환 에디션, Amazon Aurora PostgreSQL 호환 에디션 및 Amazon RDS 데이터베이스 엔진 MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, Db2를 지원합니다. 수백 개의 리소스와 계정에 걸친 업그레이드를 조율하는 운영 오버헤드를 제거하는 동시에, 프로덕션 환경에 도달하기 전에 덜 중요한 환경에서 변경 사항을 검증할 수 있습니다. 업그레이드를 수동으로 관리하거나 사용자 지정 도구를 유지 관리하는 대신, 이제 환경 전반에 걸쳐 업그레이드 순서를 자동으로 제어하는 정책을 정의할 수 있습니다.

이 게시물에서는 업그레이드 롤아웃 정책이 어떻게 작동하는지, 주요 이점 및 조직 전반에서 데이터베이스 유지 관리에 대한 체계적인 접근 방식을 구현하는 데 어떻게 활용할 수 있는지 살펴봅니다.

AWS Organizations 업그레이드 롤아웃 정책 자세히 살펴보기

AWS Organizations 업그레이드 롤아웃 정책은 데이터베이스 플릿 전반에 걸쳐 자동 마이너 버전 업그레이드를 체계적으로 단계화할 수 있도록 정책을 정의하는 기능입니다.이 정책을 통해 소프트웨어 개발 라이프사이클에 맞는 업그레이드 순서(first, second, last)를 지정할 수 있습니다. 예를 들어, 개발 환경을 첫 번째 업그레이드 순서에, 테스트 환경을 두 번째에, 프로덕션 환경은 마지막에 할당할 수 있습니다. 이러한 순서는 계정 수준에서 적용하거나 태그를 사용하여 특정 리소스에 적용할 수 있어, 업그레이드 전략에 대한 유연한 제어할 수 있습니다.

새로운 마이너 버전이 자동 업그레이드 대상이 되면, 정책은 정의된 순서에 따라 리소스를 업그레이드합니다. 각 업그레이드 단계에는 지정된 검증 기간이 포함되어 있어, 다음 환경을 업그레이드하기 전에 애플리케이션을 철저히 테스트할 수 있습니다. 관찰 가능성을 위해 이 기능은 AWS Health 이벤트와 Amazon RDS 이벤트를 통해 포괄적인 모니터링을 제공합니다. AWS Health 알림은 캠페인 진행 상황, 단계 전환 및 플릿 전체 상태에 대한 정보를 제공하고, Amazon RDS 이벤트는 업그레이드 적격성, 일정, 완료 상태를 포함한 리소스별 업데이트를 제공합니다. 문제가 감지되면 자동 진행을 비활성화할 수 있으므로 업그레이드 과정을 완전히 제어할 수 있습니다.

업그레이드 롤아웃 정책은 어떻게 작동하나요?

리소스는 리소스 태그, 조직 단위(OU) 또는 계정 레벨을 통해 업그레이드 순서 (first, second, last)를 할당받을 수 있습니다. 특정 순서가 정의되지 않은 경우, 리소스는 자동으로 기본 순서인 second를 가정합니다. AWS가 업데이트를 릴리스하면, 미리 정해진 이 순서를 자동으로 따릅니다.

first로 표시된 리소스는 예약된 유지 관리 기간 동안 업데이트를 받습니다.
AWS가 지정한 대기 기간 후, second 그룹의 리소스(기본 순서를 가진 리소스 포함)가 업그레이드 대상이 됩니다.
마지막으로, 또 다른 AWS 지정 대기 기간 후, last로 표시된 리소스가 업그레이드를 받습니다.

업그레이드 롤아웃 정책이 어떻게 작동하는지 이해하기 위해, 여러 환경에서 매일 수십억 건의 트랜잭션을 처리하는 회사를 예로 들어보겠습니다. 이 회사는 세 개의 AWS 계정에 걸쳐 데이터베이스 인프라를 관리합니다:

개발 계정: 새로운 기능 테스트를 위한 10개의 Aurora PostgreSQL 에디션 클러스터
QA 계정: 통합 테스트를 위한 5개의 클러스터
프로덕션 계정: 실시간 트랜잭션을 처리하는 8개의 클러스터

각 클러스터는 환경 (Dev, QA, Prod)을 식별하기 위해 적절히 태그가 지정되어 있습니다. 회사의 개발팀은 자동 마이너 버전 업그레이드를 비활성화하고 환경 전반에서 버전 업그레이드를 수동으로 관리하고 있었습니다. 개발 클러스터보다 프로덕션 클러스터가 먼저 업그레이드될 위험이 있어 중요한 비즈니스 운영에 잠재적으로 영향을 줄 수 있기 때문에 자동 마이너 버전 업그레이드에 의존할 수 없었습니다. 팀은 이러한 수동 업그레이드를 계획하고 실행하는 데 상당한 엔지니어링 시간을 투자했으며, 이 시간은 핵심 비즈니스 이니셔티브에 사용될 수 있었습니다.

업그레이드 롤아웃 정책을 통해, 회사는 이제 업그레이드 순서를 자동으로 관리하는 단일 조직 차원의 정책을 정의합니다. 개발 계정 리소스는 첫 번째 업그레이드 순서에, QA 계정 리소스는 두 번째 순서에, 프로덕션 계정 리소스는 마지막 순서에 할당됩니다. 새로운 마이너 버전이 사용 가능해지면, 개발 클러스터가 유지 관리 기간 동안 먼저 업그레이드되고, 테스트를 위한 검증 기간이 따릅니다. 그런 다음 업그레이드는 QA 클러스터로 진행되어 추가 검증 시간을 허용한 후, 마지막으로 프로덕션 클러스터를 업그레이드합니다. 이 과정 전반에 걸쳐 AWS Health 알림과 Amazon RDS 이벤트는 업그레이드 진행 상황에 대한 포괄적인 가시성을 제공하고, 내장된 검증 기간은 단계 간 테스트 시간을 제공합니다.

이러한 자동화된 접근 방식은 변경 사항이 프로덕션에 도달하기 전에 하위 환경에서 철저히 테스트된다는 확신을 회사에 제공합니다. 개발팀은 이제 AWS Organizations를 통해 업그레이드 프로세스에 대한 완전한 제어를 유지하면서, 업그레이드 순서를 관리하는 대신 비즈니스 이니셔티브에 집중할 수 있습니다.

사전 요구 사항

롤아웃 정책으로 업그레이드를 관리하려면 다음과 같은 몇 가지 사전 요구 사항을 충족해야 합니다:

AWS Organizations가 계정에서 활성화되어야 하고, 위임된 사용자가 업그레이드 롤아웃 정책을 활성화하고 관리할 수 있는 권한이 있어야 합니다
업그레이드 롤아웃 정책으로 관리하고자 하는 모든 데이터베이스 리소스에 대해 자동 마이너 버전 업그레이드가 활성화되어야 합니다
각 데이터베이스 리소스에는 업그레이드가 예약될 수 있는 정의된 유지 관리 기간이 필요합니다. Amazon RDS 콘솔의 유지 관리 섹션에서 클러스터의 유지 관리 기간을 검토하고 업데이트할 수 있습니다
특정 데이터베이스 리소스의 업그레이드 순서를 결정하기 위해 환경별 태그를 정의합니다. 업그레이드 순서는 계정 또는 조직 단위(OU) 수준에서 적용될 수 있지만, 태그는 여러 환경의 리소스를 포함하는 계정에 추가적인 유연성을 제공합니다.

다음으로, 업그레이드 롤아웃 정책을 생성하는 과정을 안내하겠습니다.

AWS Organizations에서 정책 생성 및 연결

AWS Organizations 콘솔에서 정책 섹션으로 이동합니다. 다음 단계를 따릅니다:

1. 업그레이드 롤아웃 정책을 활성화합니다. 활성화된 후 다음 스크린샷에 표시된 대로 Create policy을 선택합니다.
2. 다음 스크린샷에 표시된 대로 Policy name과 Policy description을 제공하여 정책을 생성합니다.
3. 비주얼 에디터를 사용하여 Upgrade rollout settings을 정의합니다.
  기본적으로 모든 리소스는 second 업그레이드 순서로 할당됩니다. 환경을 통한 제어된 업그레이드 진행을 구현하려면 이러한 기본 설정을 재정의할 수 있습니다. 이를 통해 덜 중요한 리소스(개발 등)를 첫 번째 순서로 먼저 업그레이드하고 중요한 프로덕션 리소스를 마지막 순서로 마지막에 업그레이드하여 프로덕션에 도달하기 전에 변경 사항을 검증할 수 있습니다. 세 가지 정책 업그레이드 순서에 대한 태그 키 값을 정의할 수 있습니다 (예: Key: env, Values: first의 경우 dev, second의 경우 qa, last의 경우 prod).

예제 JSON 정책은 다음과 같습니다.

{
  "upgrade_rollout": {
    "default": {
      "patch_order": {
        "@@assign": "second"
      }
    },
    "tags": {
      "env": {
        "tag_values": {
          "dev": {
            "patch_order": {
              "@@assign": "first"
            }
          },
          "qa": {
            "patch_order": {
              "@@assign": "second"
            }
          },
          "prod": {
            "patch_order": {
              "@@assign": "last"
            }
          }
        }
      }
    }
  }
}

AWS accounts로 이동하여 업그레이드를 관리하고자 하는 AWS 계정 또는 OU에 정책을 연결합니다. 이 경우 다음 스크린샷에 표시된 대로 조직 단위 TestOU-1에 연결하며, 이는 해당 OU의 모든 하위 계정에 영향을 줍니다.

모범 사례로, 중요한 워크로드에 대한 중단 위험 없이 동작과 영향을 검증하기 위해 비중요한 환경의 단일 계정에서 테스트 정책으로 작게 시작한 다음, 정책이 예상대로 작동함을 확인한 후 더 많은 계정과 조직 단위를 포함하도록 조직 구조를 통해 점진적으로 확장해야 합니다. 업그레이드 롤아웃 정책의 추가 모범 사례에 대해서는 AWS Organizations 사용 설명서의 작게 시작하고 점진적으로 확장을 참조합니다.

데이터베이스 리소스 태그 지정 및 확인

리소스 수준 태그는 보다 세분화된 조직, 비용 할당 및 액세스 제어를 위해 개별 리소스 (예: Amazon RDS)에 적용됩니다. 태그 지정에 대한 자세한 내용은 AWS Organizations 리소스 태그 지정을 참조합니다. 다음 예시에서는 Amazon Aurora와 같은 개별 리소스에 업그레이드 롤아웃 정책을 적용하는 방법을 살펴봅니다.

Amazon RDS 콘솔에서 DB 클러스터를 선택하고 다음 스크린샷에 표시된 대로 탐색 모음에서 Tags 탭을 엽니다.
다음 스크린샷과 같이 Manage tags를 선택합니다.
다음 스크린샷과 같이 Add new tag를 선택합니다.
Tag Key와 Tag Value를 입력합니다(예: 키: env, 값: prod). 다음 스크린샷에 표시된 대로 Save changes을 선택합니다.

AWS Command Line Interface (AWS CLI)를 사용하여 동일한 절차를 수행할 수도 있습니다.

aws rds add-tags-to-resource \
--resource-name <db-cluster-arn> \
--tags Key=<tag-key>,Value=<tag-value>

플레이스홀더를 클러스터 Amazon Resource Name (ARN)과 태그 키 및 값으로 바꿉니다.

--resource-name: DB 클러스터의 ARN (예: arn:aws:rds:us-west-2:123456789012:cluster:my-aurora-cluster)
--tags: 환경을 정의하는 태그 key-value 쌍 (예: Key=env, Value=dev)

한 번에 여러 클러스터에 태그를 지정하려면 Tag Editor 콘솔을 사용하거나 다음 AWS CLI 명령을 입력할 수 있습니다.

for cluster in <cluster_identifier_1> <cluster_identifier_2> <cluster_identifier_3>
do
  aws rds add-tags-to-resource \
    --resource-name arn:aws:<region>:<account-id>:cluster:$cluster \
    --tags Key=<tag_key>,Value=<tag_value>
done

플레이스홀더 값을 다음으로 바꿉니다.

<cluster_identifier_1> <cluster_identifier_2> <cluster_identifier_3>: 클러스터 식별자의 공백으로 구분된 목록
<region>: AWS 리전 (예: us-west-2)
<account-id>: AWS 계정 ID
<tag_key> 및 <tag_value>: 적용하고자 하는 환경 태그 (예: Key=env, Value=prod)

또는 AWS CloudFormation template을 사용하여 데이터베이스 클러스터에 태그를 추가할 수 있습니다. 생성된 기존 클러스터의 경우 CloudFormation 템플릿을 수정하고 Properties 아래에 태그를 추가할 수 있습니다. 다음은 예시입니다.

Resources:
  DBCluster:
    Type: AWS::RDS::DBCluster
    DeletionPolicy: Retain
    Properties:
      Engine: <DBEngine>
      EngineVersion: <Engine-Version>
      DBClusterIdentifier: <DB-Cluster-Identifier>
      DatabaseName: <DB-Name>
      MasterUsername: <DB-User>
      MasterUserPassword: <DB-Pass>
      Tags:
        - Key: <tag-key>
          Value: <tag-value>

업데이트된 Upgrade rollout order를 확인합니다. Amazon RDS 콘솔에서 DB 클러스터 세부 정보를 보고 다음 스크린샷에 표시된 대로 Upgrade rollout order 필드를 확인합니다.

AWS CLI를 사용하여 Upgrade rollout order를 확인하려면 다음 명령을 입력합니다.

aws rds describe-db-clusters —db-cluster-identifier <db-cluster-identifier> —-query 'DBClusters[*].[DBClusterIdentifier ,Engine,UpgradeRolloutOrder]'

AWS CLI 출력은 다음과 같습니다.

진행 상황 모니터링 및 검증 기간

AWS Health Dashboard는 AWS 서비스 상태와 계정별 리소스에 대한 중앙 집중식 보기를 제공하며, 공개 서비스 상태 정보와 인프라에 영향을 주는 이벤트에 대한 개인화된 알림을 결합합니다. 업그레이드 롤아웃 정책의 경우, 대시보드는 계정 또는 조직 전반의 모든 자동 마이너 버전 업그레이드를 볼 수 있는 단일 창 역할을 하며, 각 리소스의 패치 순서와 유지 관리 적용 시간을 표시하여 전체 데이터베이스 플릿에 걸친 업그레이드 순서를 확인할 수 있도록 돕습니다.

업그레이드 캠페인이 사용 가능해지면, 포괄적인 가시성과 제어를 제공하기 위해 여러 채널을 통해 알림을 받게 됩니다:

AWS Health Dashboard – 상세한 캠페인 타임라인, 리소스별 업그레이드 일정 및 상태 추적을 제공합니다
Amazon RDS 이벤트 알림 – 데이터베이스 업그레이드 활동에 대한 실시간 업데이트를 전달합니다
Describe Pending Maintenance Actions – 버전 업그레이드가 필요한 리소스에 대한 대기 중인 유지 관리 작업을 보여주는 Amazon RDS API입니다

이러한 병렬 알림 채널은 함께 작동하여 업그레이드 프로세스에 대한 완전한 감독을 제공합니다. 다음 예제들은 각 알림 유형에 대한 자세한 내용과 AmVU 캠페인 중에 효과적으로 사용하는 방법을 제공합니다.

AWS Health 알림

엔진 팀이 AmVU 캠페인을 시작하면, AWS Health Dashboard와 통합되어 이러한 전달 채널로 전송될 수 있는 포괄적인 알림을 받게 됩니다.

업그레이드 캠페인이 사용 가능해지면, 다음 스크린샷과 같이 AWS Health Dashboard의 Scheduled changes 섹션에서 RDS 엔진 업그레이드 이벤트의 상태, 영향을 받는 리전, 시작 및 종료 시간, 영향을 받는 리소스 수와 함께 알림을 받게 됩니다.

이벤트를 열면 다음 스크린샷에 표시된 대로 배포되는 엔진 버전과 유지 관리 기간 설정에 기반한 업그레이드 타임라인을 포함하는 RDS 업그레이드 캠페인에 대한 상세한 메시지가 표시됩니다.

다음 스크린샷에 표시된 Affected resources 탭은 할당된 업그레이드 롤아웃 순서와 예약된 유지 관리 적용 시간(구성된 유지 관리 기간 기반)과 함께 각 데이터베이스 클러스터의 ARN 또는 식별자를 보여줍니다. Pending 상태의 리소스는 아직 자동으로 업그레이드되지 않았으며 패치 순서 할당에 따라 예약된 유지 관리 기간을 기다리고 있습니다.

유지 관리 기간 동안 리소스의 업그레이드가 완료되면, 다음 스크린샷에 표시된 대로 리소스 상태가 Resolved로 변경됩니다.

대기 중인 유지 관리 작업 설명(DPMA)

Amazon RDS 콘솔에서 데이터베이스 클러스터를 선택하고 Maintenance & backups 탭을 엽니다. Pending maintenance 아래에서 다음 스크린샷에 표시된 대로 대기 중인 작업과 해당 Apply date를 찾을 수 있습니다.

또한 DescribePendingMaintenanceActions API를 사용하여 클러스터에 대해 어떤 유지 관리가 보류 중인지 확인할 수 있습니다.

Amazon RDS 이벤트 구독

Amazon RDS 이벤트 알림을 사용하여 장애, 구성 변경 또는 유지 관리 활동과 같은 다양한 이벤트에 대한 경고를 설정할 수 있습니다. Amazon Simple Notification Service(Amazon SNS)를 통해 RDS 이벤트 알림을 구독하여 이메일로 경고를 받거나 자동화된 워크플로 트리거를 위해 모니터링 및 경고 시스템에 Amazon EventBridge를 구성할 수 있습니다.

업그레이드 관련 알림의 경우, 데이터베이스 유형에 따라 특정 이벤트를 통해 사전 알림을 받게 됩니다: RDS 인스턴스의 경우 RDS-EVENT-0155, Aurora 클러스터의 경우 RDS-EVENT-0156입니다. 이러한 이벤트는 리소스가 자동 마이너 버전 업그레이드 대상이 되기 최소 2주 전에 발생하며, 패치가 사용 가능함을 나타냅니다.

업그레이드 순서 간 검증 기간

업그레이드 롤아웃 정책에는 업그레이드 순서 간 내장된 검증 기간이 포함되어 있어, 업그레이드가 더 중요한 환경으로 진행되기 전에 데이터베이스 안정성을 확인할 수 있는 중요한 시간을 제공합니다. 업그레이드 순서 간 이러한 대기 기간 동안 다음을 수행할 수 있습니다.

데이터베이스 변경 사항 검증 – 올바른 데이터베이스 엔진 버전을 확인하여 자동 마이너 버전 업그레이드가 성공했는지 확인
테스트 수행 – 업그레이드 후 성능 테스트를 수행하고 애플리케이션 기능을 검증
문제 식별 및 해결 – 검증 중에 문제를 발견하면 조사하고 해결할 시간이 있음
캠페인 진행 제어 – 문제가 감지되면 후속 업그레이드 순서의 데이터베이스 클러스터에 대한 자동 마이너 버전 업그레이드를 비활성화하여 더 중요한 리소스(last로 태그된 프로덕션 데이터베이스 등)가 영향을 받는 것을 방지

이러한 체계적인 접근 방식을 통해 문제가 중요한 환경으로 확산되는 것을 방지하는 내장된 안전 메커니즘과 함께 전체 업그레이드 프로세스에 대한 완전한 제어와 가시성을 유지할 수 있습니다.

다음은 주목해야 할 몇 가지 중요한 사항입니다.

데이터베이스 클러스터에 태그가 지정되지 않은 경우, 정책의 기본 설정에 지정된 대로 자동으로 second 업그레이드 순서로 기본 설정됩니다.
Amazon Aurora의 경우, 업그레이드 롤아웃 정책은 클러스터 수준 태그만 인식합니다. Aurora 업그레이드는 클러스터 수준에서 수행되어 클러스터의 모든 인스턴스에 함께 영향을 주기 때문에 인스턴스 수준 태그는 무시됩니다.
진행 중인 업그레이드 캠페인에 참여하는 경우, 리소스는 현재 실행 중인 업그레이드 순서를 따르며 구성된 정책을 기다리지 않습니다.

요약

이 게시물에서는 업그레이드 롤아웃 정책이 Amazon Aurora 및 Amazon RDS 마이너 버전 업그레이드에 대한 구조화되고 체계적인 접근 방식을 제공하는 방법에 대해 논의했습니다. 업그레이드 롤아웃 정책에 대한 자세한 내용은 AWS Organizations 설명서의 업그레이드 롤아웃 정책을 참조합니다.

AWS 기술 블로그