기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 롤아웃 정책 업그레이드
<a name="orgs_manage_policies_upgrade_rollout"></a>

AWS Organizations 업그레이드 롤아웃 정책을 사용하면 조직의 여러 AWS 리소스 및 계정에서 자동 업그레이드를 중앙에서 관리하고 시차를 지정할 수 있습니다. 이러한 정책을 사용하면 리소스가 업그레이드를 받는 순서를 정의하여 프로덕션에 도달하기 전에 덜 중요한 환경에서 변경 사항을 검증할 수 있습니다.

오늘날의 복잡한 클라우드 환경에서는 수많은 리소스와 계정에서 업그레이드를 관리하는 것이 어려울 수 있습니다. 업그레이드 롤아웃 정책은 업그레이드 구현에 대한 체계적인 접근 방식을 제공하여이 문제를 해결합니다. 이러한 정책을 사용하면 업그레이드 프로세스를 조직의 변경 관리 관행에 맞게 조정하여 위험을 줄이고 운영 효율성을 개선할 수 있습니다.

업그레이드 롤아웃 정책은의 계층 구조를 활용하여 전체 조직 또는 특정 조직 단위(OUs)에 정책을 AWS Organizations 적용합니다. 이 통합을 통해 대규모 업그레이드를 관리할 수 있으므로 수동 조정 또는 사용자 지정 자동화 스크립트가 필요하지 않습니다.

## 주요 기능 및 이점
<a name="orgs_manage_policies_upgrade_features_benefits"></a>

업그레이드 롤아웃 정책은 업그레이드를 관리하는 포괄적인 기능을 제공하는 동시에 여러 계정 및 환경에서 리소스를 관리하는 조직에 상당한 이점을 제공합니다. 다음 표에는 주요 기능과 관련 이점이 요약되어 있습니다.


**업그레이드 롤아웃 정책의 기능 및 이점**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_manage_policies_upgrade_rollout.html)

정책 상속에 대한 자세한 내용은 섹션을 참조하세요[관리 정책 상속에 대한 이해](orgs_manage_policies_inheritance_mgmt.md).

## 업그레이드 롤아웃 정책이란 무엇입니까?
<a name="orgs_manage_policies_upgrade_rollout_what_are"></a>

업그레이드 롤아웃 정책은 AWS 리소스에 자동 업그레이드가 적용되는 방식과 시기를 결정하는 규칙 세트입니다. 이러한 정책을 사용하면 일반적으로 개발, 테스트 및 프로덕션 환경에 맞게 리소스에 대해 서로 다른 업그레이드 주문을 지정할 수 있습니다. 이렇게 하면 덜 중요한 시스템에 업그레이드를 먼저 적용하여 프로덕션 워크로드에 영향을 미치기 전에 문제를 식별하고 해결할 수 있습니다.

이 정책은 첫 번째, 두 번째, 마지막의 세 가지 업그레이드 주문을 지원합니다. 이러한 주문은 업그레이드에 대한 단계적 접근 방식을 생성하며, 리소스는 처음에 "첫 번째"로 지정되어 업그레이드를 수신하고, 대기 기간 후에는 "두 번째", 마지막으로 다른 대기 기간 후에는 "마지막"으로 지정됩니다. 이 시차를 둔 접근 방식을 사용하면 더 중요한 시스템으로 진행하기 전에 각 단계에서 업그레이드를 검증할 시간을 확보할 수 있습니다.

업그레이드 롤아웃 정책은 복잡한 다중 계정 구조 또는 엄격한 변경 관리 요구 사항이 있는 조직에 특히 유용합니다. 최신 up-to-date 시스템을 유지 관리하는 것과 중요한 서비스에 대한 업그레이드 관련 중단 위험을 최소화하는 것 사이의 균형을 제공합니다.

## 업그레이드 롤아웃 정책 작동 방식
<a name="orgs_manage_policies_upgrade_rollout_how_work"></a>

업그레이드 롤아웃 정책은 기존 AWS 인프라 및 프로세스와 원활하게 통합됩니다. 업그레이드 롤아웃 정책을 생성하여 조직 단위에 연결하면 해당 OU 내의 모든 계정에 적용됩니다. 그런 다음 리소스 태그 또는 패치 주문을 사용하여 어떤 리소스를 어떤 순서로 업그레이드해야 하는지 지정할 수 있습니다.

지원되는 AWS 서비스가 업그레이드를 릴리스하면 업그레이드 롤아웃 정책을 참조하여 리소스가 업그레이드를 받아야 하는 순서를 결정합니다. 서비스는 먼저 구성된 유지 관리 기간 동안 "First"로 표시된 리소스에 업그레이드를 적용합니다. 일반적으로 약 1주일 동안 서비스별 대기 기간이 지나면 "초"로 표시된 리소스가 업그레이드 대상이 됩니다. 마지막으로 다른 대기 기간이 지나면 "Last"로 표시된 리소스가 업그레이드를 받습니다.

이 프로세스를 통해 업그레이드가 조직 전체에 제어되고 예측 가능한 방식으로 적용되도록 할 수 있습니다. 이를 통해 각 단계에서 업그레이드의 영향을 모니터링하고 변경 사항이 가장 중요한 환경에 도달하기 전에 필요한 경우 수정 조치를 취할 수 있습니다. 이 프로세스의 자동화된 특성은 업그레이드 관리의 운영 오버헤드를 줄이는 동시에 AWS 리소스의 안정성과 보안을 유지하는 데 필요한 제어 및 가시성을 제공합니다.

## 용어
<a name="orgs_manage_policies_upgrade_syntax_terminology"></a>

다음은 업그레이드 롤아웃 정책을 사용할 때 이해해야 하는 주요 용어입니다.


**롤아웃 정책 약관 업그레이드**  

| 용어 | 정의 | 
| --- | --- | 
| 활성 날짜 | AmVU가 보류 중인 유지 관리 작업 설명 API에 표시되고 애플리케이션에 사용할 수 있게 되는 날짜입니다. | 
| AmVU(마이너 버전 자동 업그레이드) | 마이너 버전의 데이터베이스 엔진에 대한 자동 업그레이드 프로세스입니다. | 
| 유효 정책 | 상속되고 직접 연결된 모든 정책을 고려한 후 계정 또는 리소스에 적용되는 최종 규칙 세트입니다. | 
| 유지 관리 윈도우 | 리소스에 자동 업그레이드를 적용할 수 있는 반복 기간입니다. 업그레이드 롤아웃 정책은 이러한 구성된 유지 관리 기간 내에서 작동합니다. | 
| 조직 단위(OU) | 조직의 AWS 계정에 대한 컨테이너입니다. 업그레이드 롤아웃 정책은 OU 수준에서 연결하여 OU 내의 모든 계정에 영향을 미칠 수 있습니다. | 
| 패치 순서 | 리소스가 업그레이드를 받는 순서(첫 번째, 두 번째, 마지막). | 
| 정책 대상 | 업그레이드 롤아웃 정책이 적용되는 범위로, 전체 조직, 특정 OUs 또는 개별 계정이 될 수 있습니다. | 
| 리소스 태그 | 정책 내에서 특정 업그레이드 순서를 따라야 하는 리소스를 식별하는 데 사용할 수 있는 키-값 페어입니다. | 
| 예약 기간 | 특정 패치 주문의 리소스가 업그레이드를 받는 기간입니다. | 
| 서비스별 대기 기간 | 서로 다른 업그레이드 주문의 리소스 업그레이드 간의 지정된 시간 간격입니다. 이 기간은 AWS 서비스 및 업그레이드 유형에 따라 다릅니다. | 
| 업그레이드 순서 | 리소스가 다른 리소스와 관련된 업그레이드를 수신하는 시기를 결정하는 지정입니다. 첫 번째, 두 번째 또는 마지막으로 설정할 수 있습니다. | 
| 롤아웃 정책 업그레이드 | 리소스 간 업그레이드 일정을 관리하는 데 사용되는 AWS Organizations 정책 유형입니다. | 

## 업그레이드 롤아웃 정책의 사용 사례
<a name="orgs_manage_policies_upgrade_rollout_use_cases"></a>

다양한 규모와 산업을 가진 조직은 업그레이드 롤아웃 정책의 이점을 누릴 수 있습니다. 다음 가상 시나리오는 일반적인 업그레이드 관리 과제와 업그레이드 롤아웃 정책이 효율적인 솔루션을 제공하는 방법을 보여줍니다. 이 예제는 일반적인 고객 경험을 기반으로 하지만 주요 이점과 구현 패턴을 강조하기 위해 간소화되었습니다.

많은 조직이 비슷한 문제에 직면합니다. 프로덕션 환경에 대한 위험을 최소화하면서 최신 버전으로 리소스를 up-to-date 유지해야 합니다. 중앙 집중식 정책 기반 접근 방식이 없으면 팀은 수동 프로세스 또는 복잡한 자동화 스크립트에 의존하는 경우가 많습니다. 다음 예제에서는 서로 다른 두 조직이 업그레이드 롤아웃 정책을 사용하여 유사한 문제를 해결하는 방법을 보여줍니다.

### 사용 사례 예: Global Financial Services Company
<a name="orgs_manage_policies_upgrade_rollout_use_case_financial"></a>

금융 서비스 회사는 여러 AWS 계정에서 수백 개의 Aurora PostgreSQL 데이터베이스를 운영합니다. 업그레이드 롤아웃 정책 전에 DevOps 팀은 매월 며칠 동안 데이터베이스 업그레이드를 수동으로 조정하여 프로덕션 시스템에 도달하기 전에 개발 환경에서 변경 사항을 테스트했는지 확인했습니다. 업그레이드 롤아웃 정책을 구현하면 다음을 수행할 수 있습니다.
+ 업그레이드 순서가 "First"인 태그가 지정된 개발 데이터베이스
+ "Second" 순서 업그레이드에 QA 데이터베이스 할당
+ 업그레이드 주문 "Last"로 지정된 프로덕션 데이터베이스
+ 업그레이드 조정을 며칠에서 몇 분으로 줄임
+ 먼저 하위 환경에서 변경 사항을 자동으로 검증
+ 변경 관리 요구 사항 준수 유지

### 사용 사례 예: IoT 디바이스 플랫폼 공급자
<a name="orgs_manage_policies_upgrade_rollout_use_case_iot"></a>

한 IoT 회사가 여러 Amazon RDS 데이터베이스를 사용하여 매일 수백만 개의 디바이스 이벤트를 처리합니다. 마이너 버전 자동 업그레이드로 인해 프로덕션 서비스가 중단되지 않도록 해야 했습니다. 업그레이드 롤아웃 정책을 사용하면 다음을 수행할 수 있습니다.
+ 조직 구조에 적용되는 정책을 생성했습니다.
+ 먼저 업그레이드를 받도록 구성된 카나리아 환경
+ 조기 업그레이드 환경에서 모니터링 설정
+ 프로덕션 업그레이드 전에 문제를 감지하고 대응할 시간을 확보했습니다.
+ 복잡한 사용자 지정 업그레이드 자동화를 간단한 정책으로 대체
+ 데이터베이스 버전을 최신 상태로 유지하면서 프로덕션 워크로드의 고가용성 유지

## 지원되는 AWS 서비스
<a name="orgs_manage_policies_upgrade_services"></a>

업그레이드 롤아웃 정책은 자동 마이너 버전 업그레이드를 지원하면서 다음 AWS 서비스와 통합됩니다.


**업그레이드 롤아웃 정책에 지원되는 서비스**  

| 서비스 이름 | 용도 | 
| --- | --- | 
| Amazon Aurora PostgreSQL 호환 에디션 | [ 자동 마이너 버전 업그레이드](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) | 
| Amazon Aurora MySQL 호환 버전 | [ 자동 마이너 버전 업그레이드](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) | 
| Amazon Relational Database Service for PostgreSQL | [ 자동 마이너 버전 업그레이드](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html) | 
| SQL Server용 Amazon 관계형 데이터베이스 서비스 | [자동 마이너 버전 업그레이드](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.SQLServer.html) | 
| Amazon Relational Database Service for Oracle | [ 마이너 버전 자동 업그레이드](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Oracle.Minor.html#oracle-minor-version-upgrade-tuning-on) | 
| MariaDB용 Amazon Relational Database Service  | [ 자동 마이너 버전 업그레이드](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.Minor.html) | 
| Amazon Relational Database Service for MySQL | [ 마이너 버전 자동 업그레이드](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html) | 
| Amazon Relational Database Service for Db2 | [마이너 버전 자동 업그레이드](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Db2.Concepts.VersionMgmt.html) | 

## 사전 조건
<a name="orgs_manage_policies_upgrade_rollout_prerequisites"></a>

다음은에서 업그레이드 롤아웃 정책을 관리하는 데 필요한 사전 조건 및 필수 권한입니다 AWS Organizations.
+ AWS Organizations 관리 계정 또는 위임된 관리자 액세스
+ 지원되는 서비스의 리소스(현재 Amazon Aurora 및 Amazon Relational Database Service 데이터베이스 엔진)
+ 업그레이드 롤아웃 정책을 관리하기 위한 적절한 IAM 권한

## 다음 단계
<a name="orgs_manage_policies_upgrade_rollout_next_steps"></a>

업그레이드 롤아웃 정책 사용을 시작하려면:

1. [업그레이드 롤아웃 정책 시작하기](orgs_manage_policies_upgrade_getting_started.md)를 검토하여 정책을 생성하고 관리하는 방법을 알아봅니다.

1. 업그레이드 롤아웃 정책 구현 [업그레이드 롤아웃 정책 사용 모범 사례](orgs_manage_policies_upgrade_best_practices.md) 탐색

1. 이해 [롤아웃 정책 구문 및 예제 업그레이드](orgs_manage_policies_upgrade_syntax.md)

# 업그레이드 롤아웃 정책 시작하기
<a name="orgs_manage_policies_upgrade_getting_started"></a>

다음 단계에 따라 조직에서 업그레이드 롤아웃 정책을 구현합니다. 각 단계는 구현을 성공적으로 완료하는 데 도움이 되는 세부 정보로 연결됩니다.

## 시작하기 전 준비 사항
<a name="orgs_manage_policies_upgrade_getting_started_prerequisites"></a>

다음이 있는지 확인합니다.
+ 에 대한 관리 액세스 AWS Organizations
+ 지원되는 AWS 서비스의 리소스(예: Aurora 또는 Amazon Relational Database Service)
+ 구성된 필수 IAM 권한

## 구현 단계
<a name="orgs_manage_policies_upgrade_getting_started_steps"></a>

1. [조직에 대한 업그레이드 롤아웃 정책을 활성화합니다.](enable-policy-type.md)

1. [업그레이드 롤아웃 정책의 작동 방식을 이해합니다.](orgs_manage_policies_upgrade_rollout.md#orgs_manage_policies_upgrade_rollout_how_work)
   + 개발, 테스트 및 프로덕션 환경 식별
   + 어떤 리소스를 먼저, 두 번째, 마지막으로 업그레이드해야 하는지 결정합니다.
   + 리소스 식별을 위한 태그 지정 전략 문서화

1.  [업그레이드 롤아웃 정책 생성](orgs_policies_create.md#create-upgrade-rollout-policy-procedure): 
   + 기본 롤아웃 순서 정의(조직 단위 또는 계정 수준)
   + 태그를 사용하여 리소스 대상 지정
   + 정책 제외 구성

1. [테스트에 사용할 수 있는 단일 멤버 계정에 업그레이드 롤아웃 정책을 연결합니다.](orgs_policies_attach.md)
   + 테스트 조직 단위로 시작
   + 정책 상속 확인
   + 정책 연결 상태 확인

1. 업그레이드 주문 전략에 따라 리소스에 태그를 지정합니다.
   + 첫 번째 업그레이드를 위해 개발 리소스에 태그 적용
   + 2차 업그레이드를 위한 테스트 리소스에 태그 지정
   + 마지막 주문 업그레이드를 위한 프로덕션 리소스 지정

1. 정책을 모니터링하고 검증합니다.
   + 업그레이드 주문 할당 검토
   + 테스트 리소스에 대한 정책 영향 확인

1. 업그레이드 프로세스를 테스트합니다.
   + 서비스 업그레이드를 사용할 수 있을 때까지 기다립니다.
   + 환경을 통한 업그레이드 진행 상황 모니터링
   + 업그레이드가 지정된 순서를 따르는지 확인

1. 필요에 따라 추가 조직 단위에 대한 업그레이드 롤아웃 정책 활성화

**기타 정보**
+ [업그레이드 롤아웃 정책 구문 알아보기 및 정책 예제 참조](orgs_manage_policies_upgrade_syntax.md)

# 업그레이드 롤아웃 정책 사용 모범 사례
<a name="orgs_manage_policies_upgrade_best_practices"></a>

AWS 에서는 업그레이드 롤아웃 정책 사용에 대한 다음 모범 사례를 권장합니다.

**Topics**
+ [소규모로 시작하여 점진적으로 확장](#orgs_manage_policies_upgrade_best_practices_scale)
+ [검토 프로세스 수립](#orgs_manage_policies_upgrade_best_practices_review)
+ [정책 변경 사항을 효과적으로 검증](#orgs_manage_policies_upgrade_best_practices_validate)
+ [변경 사항 모니터링 및 전달](#orgs_manage_policies_upgrade_best_practices_monitor)
+ [규정 준수 및 보안 유지](#orgs_manage_policies_upgrade_best_practices_compliance)
+ [운영 효율성 최적화](#orgs_manage_policies_upgrade_best_practices_optimize)

## 소규모로 시작하여 점진적으로 확장
<a name="orgs_manage_policies_upgrade_best_practices_scale"></a>

중요하지 않은 환경의 단일 계정에 연결된 테스트 정책을 사용하여 구현을 시작합니다. 이 접근 방식을 사용하면 중요한 워크로드가 중단될 위험 없이 업그레이드 롤아웃 정책의 동작과 영향을 검증할 수 있습니다. 정책이 예상대로 작동하는지 확인한 후에는 더 많은 계정과 조직 단위를 포함하도록 조직 구조 위로 점진적으로 이동합니다.

이 점진적 조정은 구현 프로세스 초기에 문제를 식별하고 해결하는 데 도움이 됩니다. 환경의 다양성을 나타내지만 운영 위험은 최소화하는 리소스의 파일럿 그룹을 만드는 것이 좋습니다. 향후 정책 롤아웃 및 조정을 알리기 위해 각 확장 단계의 결과를 문서화합니다.

## 검토 프로세스 수립
<a name="orgs_manage_policies_upgrade_best_practices_review"></a>

정기 검토 프로세스를 구현하여 새 업그레이드 롤아웃 정책 속성을 모니터링하고 정책 예외를 평가합니다. 이러한 검토는 조직의 보안 및 운영 요구 사항에 부합해야 합니다. 정책 효과를 검토하기 위한 일정을 생성하고 조정 사항에 대한 문서를 유지 관리합니다.

검토 프로세스에는 정책이 적용되는 리소스에 대한 정기적인 평가, 업그레이드 주문이 의도한 전략과 일치하는지 확인, 정책 예외에 대한 평가가 포함되어야 합니다. 정책이 시간 경과에 따른 정책 변화를 추적하기 위해 변경 로그를 업데이트하고 유지 관리해야 하는 경우에 대한 기준을 설정하는 것이 좋습니다.

## 정책 변경 사항을 효과적으로 검증
<a name="orgs_manage_policies_upgrade_best_practices_validate"></a>

업그레이드 롤아웃 정책을 변경한 후 조직의 각 수준에서 대표 계정에 대한 유효 정책을 확인합니다. AWS 관리 콘솔 또는 `DescribeEffectivePolicy` API 작업을 사용하여 변경 사항이 의도한 영향을 미치는지 확인합니다. 이 검증에는 여러 조직 단위의 리소스를 확인하고 상속이 예상대로 작동하는지 확인하는 작업이 포함되어야 합니다.

명시적 업그레이드 주문이 할당된 리소스와 기본값을 사용하는 리소스에 특히 주의하십시오. 태그 기반 대상 지정 확인, 유지 관리 기간 정렬 확인, 정책 상속 테스트가 포함된 검증 체크리스트를 설정합니다.

## 변경 사항 모니터링 및 전달
<a name="orgs_manage_policies_upgrade_best_practices_monitor"></a>

업그레이드 롤아웃 정책에 대한 포괄적인 모니터링을 설정하고 업그레이드 관련 정보를 공유하기 위한 명확한 통신 채널을 생성합니다. 업그레이드 실패를 처리하기 위한 명확한 절차를 문서화하고 다양한 시나리오에 대한 대응 계획을 수립합니다.

업그레이드 정책의 영향을 받는 리소스를 관리하는 팀과 정기적으로 소통합니다. 향후 업그레이드와 환경 전반의 예상 진행 상황을 파악할 수 있는 대시보드를 만드는 것이 좋습니다.

## 규정 준수 및 보안 유지
<a name="orgs_manage_policies_upgrade_best_practices_compliance"></a>

업그레이드 롤아웃 정책을 정기적으로 감사하여 규정 준수 요구 사항에 부합하는지 확인합니다. 모든 정책 결정을 문서화하고 업그레이드 패턴 및 예외에 대한 명확한 기록을 유지합니다. 정책 수정에 대한 보안 제어를 구현하고를 사용하여 정책 변경에 대한 감사 추적을 유지 관리합니다 AWS CloudTrail.

정책 관리 함수에 대한 액세스 권한을 정기적으로 검토하고 정책 관리를 위한 최소 권한 액세스를 구현합니다. 긴급 정책 수정을 위한 절차를 생성하고 보안 관련 업그레이드 요구 사항에 대한 문서를 유지 관리합니다.

## 운영 효율성 최적화
<a name="orgs_manage_policies_upgrade_best_practices_optimize"></a>

필요한 제어를 유지하면서 운영 오버헤드를 최소화하도록 정책을 설계합니다. 의도하지 않은 동작을 방지하려면 여러 사용 사례에서 태그를 재사용하지 마십시오. 가능한 경우 정책 규정 준수 검사를 자동화하고 일반적인 정책 관리 작업을 위한 표준 운영 절차를 생성합니다.

다양한 유형의 업그레이드 시나리오에 대한 템플릿을 생성하고 성공적인 정책 패턴에 대한 문서를 유지 관리하는 것이 좋습니다. 운영 지표를 정기적으로 검토하면 정책 최적화 및 프로세스 개선 기회를 식별하는 데 도움이 될 수 있습니다.

# 롤아웃 정책 구문 및 예제 업그레이드
<a name="orgs_manage_policies_upgrade_syntax"></a>

업그레이드 롤아웃 정책은 AWS 서비스가 리소스 전체에 자동 업그레이드를 적용하는 방법을 정의합니다. 정책 구문을 이해하면 조직의 업그레이드 요구 사항에 맞는 효과적인 정책을 생성할 수 있습니다.

**Topics**
+ [고려 사항](#orgs_manage_policies_upgrade_syntax_considerations)
+ [기본 정책 구조](#orgs_manage_policies_upgrade_syntax_structure)
+ [정책 구성 요소](#orgs_manage_policies_upgrade_syntax_components)
+ [업그레이드 롤아웃 정책 예제](#orgs_manage_policies_upgrade_syntax_examples)

## 고려 사항
<a name="orgs_manage_policies_upgrade_syntax_considerations"></a>

업그레이드 롤아웃 정책을 구현할 때는 다음과 같은 중요한 요소를 고려하세요.
+ 정책 이름은 조직 내에서 고유해야 하며 명확하고 설명적이어야 합니다. 정책의 목적과 범위를 반영하는 이름을 선택합니다. 자세한 내용은 [운영 효율성 최적화](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_optimize) 단원을 참조하십시오.
+ 광범위한 배포 전에 테스트가 중요합니다. 먼저 비프로덕션 환경에서 새 정책을 검증하고 점진적으로 확장하여 원하는 동작을 보장합니다. 자세한 내용은 [소규모로 시작하여 점진적으로 확장](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_scale) 단원을 참조하십시오.
+ 정책 변경이 조직 전체에 전파되는 데 몇 시간이 걸릴 수 있습니다. 그에 따라 구현을 계획하고 적절한 모니터링이 이루어지도록 합니다. 자세한 내용은 [변경 사항 모니터링 및 전달](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_monitor) 단원을 참조하십시오.
+ JSON 형식은 유효해야 하며 최대 정책 크기인 5,120바이트 이내로 유지되어야 합니다. 요구 사항을 충족하는 동시에 정책 구조를 최대한 단순하게 유지하세요.
+ 정기적인 정책 검토는 효과를 유지하는 데 도움이 됩니다. 정책에 대한 정기 평가를 예약하여 조직의 요구 사항을 계속 충족하는지 확인합니다. 자세한 내용은 [검토 프로세스 수립](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review) 단원을 참조하십시오.
+ 할당된 업그레이드 순서가 없는 리소스의 기본값은 "초" 순서입니다. 기본값에 의존하지 않고 중요한 리소스에 대한 업그레이드 주문을 명시적으로 설정하는 것이 좋습니다. 자세한 내용은 [정책 변경 사항을 효과적으로 검증](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_validate) 단원을 참조하십시오.
+ 수동 업그레이드는 정책 정의 업그레이드 주문보다 우선합니다. 변경 관리 프로세스가 자동 및 수동 업그레이드 시나리오를 모두 고려하는지 확인합니다. 자세한 내용은 [검토 프로세스 수립](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review) 단원을 참조하십시오.

**참고**  
관리 계정에서 태그 기반 업그레이드 롤아웃 정책을 구현할 때 관리 계정은 멤버 계정의 리소스 수준 태그를 직접 보거나 액세스할 수 없습니다. 멤버 계정이 일관된 리소스 태그를 적용하는 프로세스를 설정한 다음 이러한 태그를 참조하는 조직 수준 정책을 생성하는 것이 좋습니다. 이렇게 하면 리소스 수준 태그 지정과 조직 정책 적용 간의 적절한 조정이 보장됩니다. 또한 [– 태그 정책](orgs_manage_policies_tag-policies.md)를 사용하여 조직 전체에서 리소스에 태그를 지정할 때 일관된 태그를 유지할 수 있습니다.

## 기본 정책 구조
<a name="orgs_manage_policies_upgrade_syntax_structure"></a>

업그레이드 롤아웃 정책은 다음 주요 요소를 포함하는 JSON 구조를 사용합니다.
+ 정책 메타데이터(예: 버전 정보)
+ 리소스 대상 지정 규칙
+ 업그레이드 주문 사양
+ 선택적 예외 메시지
+ 서비스별 속성

다음 예제에서는 기본 업그레이드 롤아웃 정책 구조를 보여줍니다.

```
{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}
```

## 정책 구성 요소
<a name="orgs_manage_policies_upgrade_syntax_components"></a>

업그레이드 롤아웃 정책은 리소스에 업그레이드가 적용되는 방식을 제어하기 위해 함께 작동하는 두 가지 주요 구성 요소로 구성됩니다. 이러한 구성 요소에는 기본 동작과 태그 기반 재정의 모두에 대한 구성 옵션이 포함됩니다. 이러한 구성 요소가 상호 작용하는 방식을 이해하면 조직의 요구 사항에 맞는 효과적인 정책을 만드는 데 도움이 됩니다.

### 기본 패치 순서 설정
<a name="orgs_manage_policies_upgrade_syntax_components_default"></a>

리소스별 재정의를 지정하지 않고 업그레이드 롤아웃 정책을 생성하면 모든 리소스가 기본 업그레이드 순서로 기본 설정됩니다. 정책의 “기본값” 필드를 사용하여이 기본값을 설정할 수 있습니다. 태그를 통한 명시적 업그레이드 순서 할당이 없는 리소스는이 기본 순서를 따릅니다.

**참고**  
현재 콘솔 환경을 사용하려면 기본 순서를 지정해야 합니다.

다음 예제에서는 태그로 재정의되지 않는 한 기본적으로 모든 리소스가 업그레이드를 받도록 설정하는 방법을 보여줍니다. 이 접근 방식은 업그레이드 주기 후반부에 대부분의 리소스가 업데이트되도록 하려는 경우에 유용합니다.

```
"upgrade_rollout": {
    "default": {
        "patch_order": "last"
    }
}
```

### 태그를 통한 리소스 수준 재정의
<a name="orgs_manage_policies_upgrade_syntax_components_tags"></a>

태그를 사용하여 특정 리소스의 기본 업그레이드 순서를 재정의할 수 있습니다. 이를 통해 업그레이드를 받는 리소스의 순서를 세부적으로 제어할 수 있습니다. 예를 들어 환경 유형, 개발 단계 또는 워크로드 중요도에 따라 다른 업그레이드 주문을 할당할 수 있습니다.

다음 예제에서는 먼저 업그레이드를 수신하도록 개발 리소스를 구성하고 마지막으로 수신하도록 프로덕션 리소스를 구성하는 방법을 보여줍니다. 이 구성을 사용하면 개발 환경이 프로덕션에 도달하기 전에 업그레이드를 검증할 수 있습니다.

```
"upgrade_rollout": {
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "patch_order": "first"
                },
                "production": {
                    "patch_order": "last"
                }
            }
        }
    }
}
```

## 업그레이드 롤아웃 정책 예제
<a name="orgs_manage_policies_upgrade_syntax_examples"></a>

일반적인 업그레이드 롤아웃 정책 시나리오는 다음과 같습니다.

### 예제 1: 개발 환경 먼저
<a name="orgs_manage_policies_upgrade_syntax_example1"></a>

이 예제에서는 먼저 업그레이드를 받도록 개발 환경에서 리소스를 구성하는 방법을 보여줍니다. "개발" 환경 태그로 리소스를 대상으로 지정하면 개발 환경이 새 업그레이드를 가장 먼저 수신하고 검증할 수 있습니다. 이 패턴은 업그레이드가 더 중요한 환경에 도달하기 전에 잠재적 문제를 식별하는 데 도움이 됩니다.

```
{
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "upgrade_order": "first"
                }
            }
        }
    }
}
```

### 예제 2: 프로덕션 환경 마지막
<a name="orgs_manage_policies_upgrade_syntax_example2"></a>

이 예제에서는 프로덕션 환경이 마지막으로 업그레이드를 받도록 하는 방법을 보여줍니다. 프로덕션 태그가 지정된 리소스를 마지막 업그레이드 주문으로 명시적으로 설정하면 프로덕션 환경에서 안정성을 유지하면서 사전 프로덕션 환경에서 적절한 테스트를 수행할 수 있습니다. 이 접근 방식은 엄격한 변경 관리 요구 사항이 있는 조직에 특히 유용합니다.

```
{
    "tags": {
        "environment": {
            "tag_values": {
                "production": {
                    "upgrade_order": "last"
                }
            }
        }
    }
}
```

### 예제 3: 태그를 사용한 여러 업그레이드 주문
<a name="orgs_manage_policies_upgrade_syntax_example3"></a>

다음 예제에서는 값이 다른 단일 태그 키를 사용하여 세 가지 업그레이드 주문을 모두 지정하는 방법을 보여줍니다. 이 접근 방식은 단일 태그 지정 체계를 통해 업그레이드 주문을 관리하려는 경우에 유용합니다.

```
{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}
```