기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
롤아웃 정책 구문 및 예제 업그레이드
업그레이드 롤아웃 정책은 AWS 서비스가 리소스 전체에 자동 업그레이드를 적용하는 방법을 정의합니다. 정책 구문을 이해하면 조직의 업그레이드 요구 사항에 맞는 효과적인 정책을 생성할 수 있습니다.
고려 사항
업그레이드 롤아웃 정책을 구현할 때는 다음과 같은 중요한 요소를 고려하세요.
-
정책 이름은 조직 내에서 고유해야 하며 명확하고 설명적이어야 합니다. 정책의 목적과 범위를 반영하는 이름을 선택합니다. 자세한 내용은 운영 효율성 최적화 단원을 참조하십시오.
-
광범위한 배포 전에 테스트가 중요합니다. 먼저 비프로덕션 환경에서 새 정책을 검증하고 점진적으로 확장하여 원하는 동작을 보장합니다. 자세한 내용은 작게 시작하고 점진적으로 확장 단원을 참조하십시오.
-
정책 변경이 조직 전체에 전파되는 데 몇 시간이 걸릴 수 있습니다. 그에 따라 구현을 계획하고 적절한 모니터링이 이루어지도록 합니다. 자세한 내용은 변경 사항 모니터링 및 전달 단원을 참조하십시오.
-
JSON 형식은 유효해야 하며 최대 정책 크기인 5,120바이트 이내로 유지되어야 합니다. 요구 사항을 충족하는 동시에 정책 구조를 최대한 단순하게 유지하세요.
-
정기적인 정책 검토는 효과를 유지하는 데 도움이 됩니다. 정책에 대한 정기 평가를 예약하여 조직의 요구 사항을 계속 충족하는지 확인합니다. 자세한 내용은 검토 프로세스 수립 단원을 참조하십시오.
-
할당된 업그레이드 순서가 없는 리소스의 기본값은 "초" 순서입니다. 기본값에 의존하지 않고 중요한 리소스에 대한 업그레이드 주문을 명시적으로 설정하는 것이 좋습니다. 자세한 내용은 정책 변경 사항을 효과적으로 검증 단원을 참조하십시오.
-
수동 업그레이드는 정책 정의 업그레이드 주문보다 우선합니다. 변경 관리 프로세스가 자동 및 수동 업그레이드 시나리오를 모두 고려하는지 확인합니다. 자세한 내용은 검토 프로세스 수립 단원을 참조하십시오.
참고
관리 계정에서 태그 기반 업그레이드 롤아웃 정책을 구현할 때 관리 계정은 멤버 계정의 리소스 수준 태그를 직접 보거나 액세스할 수 없습니다. 멤버 계정이 일관된 리소스 태그를 적용하는 프로세스를 설정한 다음 이러한 태그를 참조하는 조직 수준 정책을 생성하는 것이 좋습니다. 이렇게 하면 리소스 수준 태그 지정과 조직 정책 적용 간의 적절한 조정이 보장됩니다. 또한 – 태그 정책를 사용하여 조직 전체에서 리소스에 태그를 지정할 때 일관된 태그를 유지할 수 있습니다.
기본 정책 구조
업그레이드 롤아웃 정책은 다음 주요 요소를 포함하는 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" } } } } } } }
정책 구성 요소
업그레이드 롤아웃 정책은 리소스에 업그레이드가 적용되는 방식을 제어하기 위해 함께 작동하는 두 가지 주요 구성 요소로 구성됩니다. 이러한 구성 요소에는 기본 동작과 태그 기반 재정의 모두에 대한 구성 옵션이 포함됩니다. 이러한 구성 요소가 상호 작용하는 방식을 이해하면 조직의 요구 사항에 맞는 효과적인 정책을 만드는 데 도움이 됩니다.
기본 패치 순서 설정
리소스별 재정의를 지정하지 않고 업그레이드 롤아웃 정책을 생성하면 모든 리소스가 기본 업그레이드 순서로 기본 설정됩니다. 정책의 “기본값” 필드를 사용하여이 기본값을 설정할 수 있습니다. 태그를 통한 명시적 업그레이드 순서 할당이 없는 리소스는이 기본 순서를 따릅니다.
참고
현재 콘솔 환경을 사용하려면 기본 순서를 지정해야 합니다.
다음 예제에서는 태그로 재정의되지 않는 한 기본적으로 모든 리소스가 업그레이드를 받도록 설정하는 방법을 보여줍니다. 이 접근 방식은 업그레이드 주기 후반부에 대부분의 리소스가 업데이트되도록 하려는 경우에 유용합니다.
"upgrade_rollout": { "default": { "patch_order": "last" } }
태그를 통한 리소스 수준 재정의
태그를 사용하여 특정 리소스의 기본 업그레이드 순서를 재정의할 수 있습니다. 이를 통해 업그레이드를 받는 리소스의 순서를 세부적으로 제어할 수 있습니다. 예를 들어 환경 유형, 개발 단계 또는 워크로드 중요도에 따라 다른 업그레이드 주문을 할당할 수 있습니다.
다음 예제에서는 먼저 업그레이드를 수신하도록 개발 리소스를 구성하고 마지막으로 수신하도록 프로덕션 리소스를 구성하는 방법을 보여줍니다. 이 구성을 사용하면 개발 환경이 프로덕션에 도달하기 전에 업그레이드를 검증할 수 있습니다.
"upgrade_rollout": { "tags": { "environment": { "tag_values": { "development": { "patch_order": "first" }, "production": { "patch_order": "last" } } } } }
업그레이드 롤아웃 정책 예제
일반적인 업그레이드 롤아웃 정책 시나리오는 다음과 같습니다.
예제 1: 개발 환경 먼저
이 예제에서는 먼저 업그레이드를 받도록 개발 환경에서 리소스를 구성하는 방법을 보여줍니다. "개발" 환경 태그로 리소스를 대상으로 지정하면 개발 환경이 새 업그레이드를 가장 먼저 수신하고 검증할 수 있습니다. 이 패턴은 업그레이드가 더 중요한 환경에 도달하기 전에 잠재적 문제를 식별하는 데 도움이 됩니다.
{ "tags": { "environment": { "tag_values": { "development": { "upgrade_order": "first" } } } } }
예제 2: 프로덕션 환경 마지막
이 예제에서는 프로덕션 환경이 마지막으로 업그레이드를 받도록 하는 방법을 보여줍니다. 프로덕션 태그가 지정된 리소스를 마지막 업그레이드 주문으로 명시적으로 설정하면 프로덕션 환경에서 안정성을 유지하면서 사전 프로덕션 환경에서 적절한 테스트를 수행할 수 있습니다. 이 접근 방식은 엄격한 변경 관리 요구 사항이 있는 조직에 특히 유용합니다.
{ "tags": { "environment": { "tag_values": { "production": { "upgrade_order": "last" } } } } }
예제 3: 태그를 사용한 여러 업그레이드 주문
다음 예제에서는 값이 다른 단일 태그 키를 사용하여 세 가지 업그레이드 주문을 모두 지정하는 방법을 보여줍니다. 이 접근 방식은 단일 태그 지정 체계를 통해 업그레이드 주문을 관리하려는 경우에 유용합니다.
{ "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" } } } } } } }