기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 에서 컴퓨팅 환경 업데이트 AWS Batch
AWS Batch 는 컴퓨팅 환경을 업데이트하기 위한 여러 전략을 제공하며, 각 전략은 특정 업데이트 시나리오 및 요구 사항에 맞게 설계되었습니다. 이러한 접근 방식은 동일한 기본 업데이트 API를 사용하지만 업데이트를 효과적으로 관리하기 위한 다양한 규범적 방법을 사용합니다. AWS Batch 콘솔 또는를 사용하여 이러한 업데이트를 관리할 수 있습니다 AWS CLI. 이러한 전략을 이해하면 워크로드 중단을 최소화하면서 필요에 가장 적합한 방법을 선택하는 데 도움이 됩니다.
이 주제에서는 사용 가능한 업데이트 전략의 개요와 언제 각 접근 방식을 사용해야 하는지에 대한 지침을 제공합니다. 자세한 절차는 각 업데이트 전략의 개별 섹션을 참조하세요.
**중요**
AWS Batch 는 Amazon EC2 시작 템플릿, Amazon EC2 Auto Scaling 그룹, Amazon EC2 스팟 플릿, Amazon Amazon EC2 클러스터를 포함하여 사용자를 대신하여 계정 내에서 여러 AWS 리소스를 생성하고 관리합니다. 이러한 관리형 리소스는 최적의 AWS Batch 작동을 보장하도록 특별히 구성됩니다. AWS Batch 설명서에 명시적으로 명시되지 않는 한 이러한 AWS Batch관리형 리소스를 수동으로 수정하면 `INVALID` 컴퓨팅 환경, 최적화되지 않은 인스턴스 조정 동작, 워크로드 처리 지연 또는 예상치 못한 비용 등 예상치 못한 동작이 발생할 수 있습니다. 이러한 수동 수정은 AWS Batch 서비스에서 결정론적으로 지원할 수 없습니다. 항상 지원되는 AWS Batch APIs 또는 AWS Batch 콘솔을 사용하여 컴퓨팅 환경을 관리합니다.
지원되지 않는 수동 수정에는 자체 Amazon ECS 태스크 또는 서비스 AWS Batch관리형 Amazon ECS 클러스터 실행 또는 추가 프로세스, 데몬 또는 서비스 직접 AWS Batch관리형 인스턴스 시작이 포함됩니다. AWS Batch 는 관리형 컴퓨팅 환경에서 컴퓨팅 리소스를 완전히 제어하고 언제든지 인스턴스를 종료하거나 태스크를 중지하거나 클러스터를 확장할 수 있습니다. 이러한 관리형 리소스에서 AWS Batch 작업 제출 외부에서 실행하는 모든 워크로드는 경고 없이 중단될 수 있습니다. 비AWS Batch 워크로드 AWS Batch관리형 클러스터 및 인스턴스를 실행하면 AWS Batch 작업 예약 및 인스턴스 크기 조정에도 방해가 될 수 있습니다.
**Topics**
+ [컴퓨팅 환경 업데이트 전략](#update-strategies)
+ [올바른 업데이트 전략 선택](#choosing-update-strategies)
+ [AMI 업데이트 고려 사항](#ami-update-considerations)
+ [규모 조정 업데이트 수행](scaling-updates.md)
+ [인프라 업데이트 수행](infrastructure-updates.md)
+ [컴퓨팅 환경에 대한 블루/그린 업데이트 수행](blue-green-updates.md)
## 컴퓨팅 환경 업데이트 전략
규모 조정 또는 인프라 업데이트를 사용하면 컴퓨팅 환경이 그대로 업데이트됩니다. 블루/그린 업데이트 전략에서는 새 컴퓨팅 환경(그린)을 생성한 다음 이전 컴퓨팅 환경(블루)에서 새 컴퓨팅 환경(그린)으로 워크로드를 마이그레이션합니다.
AWS Batch 는 컴퓨팅 환경 업데이트를 위한 세 가지 전략을 제공합니다.
규모 조정 업데이트
규모 조정 업데이트는 기존 인스턴스를 교체하지 않고 인스턴스를 추가하거나 제거하여 컴퓨팅 환경의 용량을 조정합니다. 이는 가장 빠른 업데이트 시나리오이며 가동 중지 시간이 필요하지 않습니다. 용량 설정(vCPU)을 변경해야 하는 경우 규모 조정 업데이트를 사용합니다. 이러한 업데이트는 일반적으로 몇 분 내에 완료됩니다.
Fargate 업데이트는 규모 조정 업데이트와 동일한 절차를 사용하여 수행됩니다. 자세한 내용은 [규모 조정 업데이트 수행](scaling-updates.md) 단원을 참조하십시오.
인프라 업데이트
인프라 업데이트는 컴퓨팅 환경의 인스턴스를 설정이 업데이트된 새 인스턴스로 대체합니다. 이러한 업데이트에는 특정 서비스 역할 및 할당 전략 구성이 필요하지만 가동 중지 시간을 최소화할 수 있으며 실행 중인 작업이 중단될 가능성이 있습니다. 인스턴스 유형, AMI 구성, 네트워킹 설정, 서비스 역할, 환경 상태 또는 기타 인프라 구성 요소를 수정해야 하는 경우 인프라 업데이트를 사용합니다. 이러한 업데이트는 일반적으로 작업 완료에 따라 10\$130분 이내에 완료됩니다.
자세한 내용은 [인프라 업데이트 수행](infrastructure-updates.md) 단원을 참조하십시오.
블루/그린 업데이트
블루/그린 업데이트는 기존 환경 옆에 새로운 컴퓨팅 환경을 생성하여 가동 중지 없이 점진적인 워크로드 전환을 가능하게 합니다. 이 접근 방식은 가장 안전한 업데이트 경로를 제공하지만 일시적으로 두 개의 환경을 실행해야 합니다. 가동 중지 시간이 없어야 하거나, 전체 배포 전에 변경 사항을 테스트하고자 하거나, 빠른 롤백 기능이 필요하거나, 인프라 업데이트에 대해 지원되지 않는 구성을 사용하려는 경우 블루/그린 업데이트를 사용합니다. 완료 시간은 가변적이며 사용자가 제어합니다.
자세한 내용은 [컴퓨팅 환경에 대한 블루/그린 업데이트 수행](blue-green-updates.md) 단원을 참조하십시오.
## 올바른 업데이트 전략 선택
이 결정 가이드를 사용하여 필요에 가장 적합한 업데이트 전략을 선택합니다.
### 다음과 같은 경우 규모 조정 업데이트를 선택합니다.
컴퓨팅 용량(vCPU)만 조정해야 하는 경우 규모 조정 업데이트 전략을 선택합니다. 규모 조정 업데이트는 가동 중지 없이 빠른 업데이트가 필요하고 인프라 구성 변경이 필요하지 않은 경우에 이상적입니다.
자세한 절차는 [규모 조정 업데이트 수행](scaling-updates.md) 섹션을 참조하세요.
### 다음과 같은 경우 인프라 업데이트를 선택합니다.
인스턴스 유형, AMI 설정, 서비스 역할, 환경 상태 또는 네트워킹 구성을 수정해야 하는 경우 인프라 업데이트 전략을 선택합니다. 환경은 *AWSServiceRoleForBatch* 서비스 연결 역할과 `BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED` 또는 `SPOT_PRICE_CAPACITY_OPTIMIZED`의 할당 전략을 사용해야 합니다. 인프라 업데이트는 업데이트 중 일부 작업 중단이 허용되고 최신 Amazon ECS 최적화 AMI에 대한 자동 업데이트를 원하는 경우 잘 작동합니다.
자세한 절차는 [인프라 업데이트 수행](infrastructure-updates.md) 섹션을 참조하세요.
### 다음과 같은 경우 블루/그린 업데이트를 선택합니다.
워크로드에 가동 중지 시간이 없어야 하거나 프로덕션 워크로드를 전환하기 전에 변경 사항을 테스트해야 하는 경우 블루/그린 업데이트 전략을 선택합니다. 이 접근 방식은 빠른 롤백 기능이 중요하거나, 환경에서 `BEST_FIT` 할당 전략을 사용하거나, 환경에서 *AWSServiceRoleForBatch* 서비스 연결 역할을 사용하지 않는 경우에 필수적입니다. 블루/그린 업데이트는 수동 업데이트가 필요한 사용자 지정 AMI를 사용하거나 대대적인 구성 변경이 필요할 때도 최고의 선택입니다.
자세한 절차는 [컴퓨팅 환경에 대한 블루/그린 업데이트 수행](blue-green-updates.md) 섹션을 참조하세요.
## AMI 업데이트 고려 사항
AMIs를 업데이트하는 방법은 컴퓨팅 환경 구성에 따라 다릅니다.
### AWS Batch 제공된 기본 AMI를 최신으로 업데이트
AWS Batch 는 인프라 업데이트 중에 다음 조건이 모두 충족될 때 최신 Amazon ECS 최적화 AMI로 [](infrastructure-updates.md#infrastructure-updates.title) 업데이트할 수 있습니다.
**참고**
인프라 업데이트가 완료된 후 `updateToLatestImageVersion`은 `false`로 설정됩니다. 다른 업데이트를 시작하려면 `updateToLatestImageVersion`을 `true`로 설정해야 합니다.
+ 컴퓨팅 환경이 *AWSServiceRoleForBatch* 서비스 연결 역할을 사용합니다.
+ 할당 전략이 `BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED` 또는 `SPOT_PRICE_CAPACITY_OPTIMIZED`로 설정되었습니다.
+ `imageId`, `imageIdOverride` 또는 시작 템플릿에 명시적으로 지정된 AMI ID가 없습니다.
+ `updateToLatestImageVersion`이 `true`로 설정되었습니다.
### 블루/그린 배포를 사용한 AMI 업데이트
다음 시나리오에서 블루/그린 배포를 사용하여 AMI를 업데이트해야 합니다.
+ `BEST_FIT` 할당 전략을 사용하는 경우(인프라 업데이트를 지원하지 않음)
+ *AWSServiceRoleForBatch* [서비스 연결 역할](using-service-linked-roles-batch-general.md)을 사용하지 않는 경우
### 사용자 지정 AMI에 대한 AMI 업데이트
컴퓨팅 환경의 시작 템플릿에서 사용자 지정 AMI를 지정하는 경우 `imageId` 파라미터 또는 EC2 구성의 `imageIdOverride` 파라미터 AWS Batch 는 인프라 업데이트 중에 사용자 지정 AMI를 자동으로 업데이트하지 않습니다. 컴퓨팅 환경 생성 중에 원래 사용된 파라미터에 새 ID를 지정하여 사용자 지정 AMI ID를 업데이트할 수 있습니다. AWS Batch제공 AMI를 사용하여 로 전환하려는 경우 컴퓨팅 환경 업데이트에서 사용자 지정 AMI ID를 제거하여 전환할 수 있습니다.
# 규모 조정 업데이트 수행
규모 조정 업데이트는 인스턴스를 추가하거나 제거하여 컴퓨팅 환경의 용량을 조정합니다. 이는 가장 빠른 업데이트 전략이며 기존 인스턴스를 교체할 필요가 없습니다. 규모 조정 업데이트는 모든 서비스 역할 유형 및 할당 전략에서 작동하므로 가장 유연한 업데이트 옵션입니다.
## 규모 조정 업데이트를 트리거하는 변경 사항
다음 설정만 수정하면 AWS Batch 에서 규모 조정 업데이트를 수행합니다. 이러한 설정을 다른 컴퓨팅 환경 설정과 함께 수정하면가 인프라 [업데이트를](infrastructure-updates.md#infrastructure-updates.title) 대신 AWS Batch 수행합니다.
다음 설정은 독점적으로 수정될 때 규모 조정 업데이트를 트리거합니다.
+ `desiredvCpus` - 환경의 목표 vCPUs 수를 설정합니다.
+ `maxvCpus` - 시작할 수 있는 최대 vCPU 수를 정의합니다.
+ `minvCpus` - 유지할 최소 vCPU 수를 지정합니다.
+ `minScaleDownDelayMinutes` - 작업이 완료된 후 컴퓨팅 환경에서 인스턴스를 AWS Batch 계속 실행하는 최소 시간(분)을 지정합니다.
**참고**
`minScaleDownDelayMinutes`는 인프라 업데이트 중에 교체되는 인스턴스에는 적용되지 않습니다.
Fargate 컴퓨팅 환경의 경우, 규모 조정 업데이트를 위해 다음 설정을 수정할 수도 있습니다.
+ `securityGroupIds` - 컴퓨팅 환경의 보안 그룹 ID.
+ `subnets` - 컴퓨팅 환경의 서브넷.
**참고**
AWS Batch 가 `desiredvCpus`를 동적으로 조정하므로를 사용하여 조정 업데이트를 시작하지 않는 것이 좋습니다`desiredvCpus`. 대신에 `minvCpus`를 업데이트해야 합니다.
`desiredvCpus`를 업데이트할 때 값은 `minvCpus`와 `maxvCpus` 사이여야 합니다. 새 값은 현재 `desiredvCpus`보다 크거나 같아야 합니다. 자세한 내용은 [`desiredvCpus` 설정을 업데이트할 때 나타나는 오류 메시지](error-desired-vcpus-update.md) 단원을 참조하십시오.
**중요**
이러한 조정 설정을 다른 컴퓨팅 환경 설정(예: 인스턴스 유형, AMI IDs 또는 시작 템플릿)과 함께 수정하는 경우는 조정 업데이트 대신 인프라 업데이트를 AWS Batch 수행합니다. 인프라 업데이트는 더 오래 걸리며 기존 인스턴스를 대체할 수 있습니다.
------
#### [ Performing scaling updates using the AWS Management Console ]
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) AWS Batch 콘솔을 엽니다.
1. 탐색 창에서 **컴퓨팅 환경**을 선택한 다음 **컴퓨팅 환경** 탭을 선택합니다.
1. 업데이트할 컴퓨팅 환경을 선택합니다.
1. **작업**을 선택하고 **편집**을 선택합니다.
1. [규모 조정 업데이트를 지원하는 설정](#scaling-updates-triggers)을 하나 이상 수정합니다. 예제:
+ **최소 vCPU**에 최소 vCPU 수를 입력합니다.
+ **원하는 vCPU**에 원하는 vCPU 수를 입력합니다.
+ **최대 vCPU**에 최대 vCPU 수를 입력합니다.
1. **변경 사항 저장**을 선택합니다.
1. 컴퓨팅 환경 상태를 모니터링합니다. 업데이트는 규모 조정 작업만 수반되므로 빠르게 완료됩니다.
------
#### [ Performing scaling updates using the AWS CLI ]
**update-compute-environment** 명령을 사용하여 규모 조정 업데이트를 수행합니다. 다음 두 예제는 일반적인 규모 조정 작업을 보여줍니다. 다음과 같은 [규모 조정 업데이트를 지원하는 설정](#scaling-updates-triggers) 중 하나 이상을 수정할 수 있습니다.
+ 이 예제에서는 원하는 vCPU, 최소 vCPU 및 최대 vCPU를 업데이트합니다.
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources minvCpus=2,maxvCpus=8
```
------
## 규모 조정 업데이트 모니터링
AWS Batch 콘솔을 사용하여 조정 업데이트를 모니터링하여 컴퓨팅 환경 상태를 확인하고 인스턴스 수 및 vCPU 지표를 확인합니다. 명령과 AWS CLI 함께를 사용하여 상태를 **describe-compute-environments** 확인하고 인스턴스 수와 vCPU 값을 모니터링할 수도 있습니다.
# 인프라 업데이트 수행
인프라 업데이트는 컴퓨팅 환경의 인스턴스를 설정이 업데이트된 새 인스턴스로 대체합니다. 이 업데이트 전략은 규모 조정 업데이트보다 오래 걸리며 특정 서비스 역할 및 할당 전략 설정이 필요합니다. 인프라 업데이트는 서비스 가용성을 유지하면서 기본 컴퓨팅 환경 구성을 수정할 수 있는 방법을 제공합니다.
**중요**
인프라 업데이트에는 *AWSServiceRoleForBatch* 서비스 연결 역할과 `BEST_FIT_PROGRESSIVE`, `SPOT_CAPACITY_OPTIMIZED` 또는 `SPOT_PRICE_CAPACITY_OPTIMIZED`의 할당 전략이 필요합니다. 환경이 이러한 요구 사항을 충족하지 않는 경우, 대신 블루/그린 업데이트를 사용합니다.
## 인프라 업데이트를 트리거하는 변경 사항
다음 설정 중 하나를 수정하면가 인프라 업데이트를 AWS Batch 수행합니다. 인프라 업데이트는 규모 조정 업데이트 설정과 함께 이러한 설정을 수정할 때도 발생합니다.
다음 설정은 인프라 업데이트를 트리거합니다.
**컴퓨팅 구성**
+ `allocationStrategy` -가 인스턴스 유형을 AWS Batch 선택하는 방법을 결정합니다.
+ `instanceTypes` - 어느 EC2 인스턴스 유형을 사용할지를 지정합니다.
+ `bidPercentage` - 스팟 인스턴스에 대한 온디맨드 가격의 최대 백분율.
+ `type` - 컴퓨팅 환경 유형(`EC2` 또는 `SPOT`).
**AMI 및 시작 구성**
+ `imageId` - 인스턴스에 사용할 특정 AMI.
+ `ec2Configuration` - `imageIdOverride`를 포함한 EC2 구성.
+ `launchTemplate` - EC2 시작 템플릿 설정.
+ `ec2KeyPair` - 인스턴스 액세스를 위한 SSH 키 페어.
+ `updateToLatestImageVersion` - 자동 AMI 업데이트 설정.
**네트워킹 및 보안**
+ `subnets` - 인스턴스가 시작되는 VPC 서브넷(EC2 컴퓨팅 환경용).
+ `securityGroupIds` - 인스턴스의 보안 그룹(EC2 컴퓨팅 환경용).
+ `placementGroup` - EC2 배치 그룹 구성.
**기타 설정**
+ `instanceRole` - EC2 인스턴스에 대한 IAM 역할.
+ `tags` - EC2 인스턴스에 적용되는 태그.
**중요**
규모 조정 업데이트 설정(예: `desiredvCpus`, `maxvCpus` 또는 `minvCpus`)과 함께 인프라 업데이트 설정을 수정하면 AWS Batch 에서 인프라 업데이트를 수행합니다. 인프라 업데이트는 규모 조정 업데이트보다 더 오래 걸립니다.
## 인프라 업데이트 중 AMI 선택
인프라 업데이트 중에 AMI가 이 세 가지 설정 중 어디에 설정되었는지에 따라 컴퓨팅 환경의 AMI ID가 변경될 수 있습니다. AMI는 `imageId`(`computeResources`에서), `imageIdOverride`(`ec2Configuration`에서)에서 지정되거나 아니면 시작 템플릿이 `launchTemplate`에 지정됩니다. AMI ID가 아무런 설정에도 지정되어 있지 않고 `updateToLatestImageVersion` 설정이 `true`라고 가정해 보겠습니다. 그런 다음에서 지원하는 최신 Amazon ECS 최적화 AMI AWS Batch 가 모든 인프라 업데이트에 사용됩니다.
AMI ID가 이러한 설정 중 하나 중에 지정되면 업데이트 전에 사용한 AMI ID 제공 설정에 따라 업데이트가 달라집니다. 컴퓨팅 환경을 생성할 때 AMI ID 선택 우선 순위는 가장 먼저 시작 템플릿, 그리고 `imageId` 설정, 마지막으로 `imageIdOverride` 설정입니다. 하지만 사용한 AMI ID를 시작 템플릿에서 가져오면 `imageId` 또는 `imageIdOverride` 설정은 AMI ID를 업데이트하지 않습니다. 시작 템플릿에 선택된 AMI ID를 업데이트하는 유일한 방법은 시작 템플릿을 업데이트하는 것입니다. 시작 템플릿의 버전 파라미터가 `$Default` 혹은 `$Latest`인 경우 지정된 시작 템플릿의 기본 버전 또는 최신 버전이 평가됩니다. 기본적으로 다른 AMI ID를 선택하거나 시작 템플릿의 최신 버전을 선택한 경우 해당 AMI ID가 업데이트에 사용됩니다.
시작 템플릿에 AMI ID를 선택하지 않은 경우 `imageId` 또는 `imageIdOverride` 파라미터에 지정된 AMI ID가 사용됩니다. 둘 다 지정된 경우 `imageIdOverride` 파라미터에 지정된 AMI ID가 사용됩니다.
컴퓨팅 환경에 또는 `imageId`, `imageIdOverride`, 혹은 `launchTemplate` 파라미터로 지정한 AMI ID를 사용하고 AWS Batch에서 지원하는 최신 Amazon ECS 최적화 AMI를 사용하기를 원한다고 가정해 보겠습니다. 그러면 업데이트는 AMI ID를 제공한 설정을 제거해야 합니다. `imageId`의 경우, 해당 파라미터에 빈 문자열을 지정해야 합니다. `imageIdOverride`의 경우 `ec2Configuration` 파라미터에 빈 문자열을 지정해야 합니다.
AMI ID가 시작 템플릿에서 가져온 경우 다음 방법 중 하나를 사용하여에서 지원하는 최신 Amazon ECS 최적화 AMI AWS Batch 로 변경할 수 있습니다.
+ `launchTemplateId` 또는 `launchTemplateName` 파라미터에 빈 문자열을 지정하여 시작 템플릿을 제거합니다. 그러면 AMI ID만 제거되는 것이 아니라 전체 시작 템플릿이 제거됩니다.
+ 업데이트된 버전의 시작 템플릿에 AMI ID가 지정되지 않은 경우 `updateToLatestImageVersion` 파라미터를 `true`로 설정해야 합니.
## 업데이트 중 작업 처리
업데이트 정책을 사용하여 인프라 업데이트 중에 실행 중인 작업을 처리하는 방법을 구성합니다. `terminateJobsOnUpdate=true`를 설정하면 실행 중인 작업이 즉시 종료되고 `jobExecutionTimeoutMinutes` 설정이 무시되며 인스턴스를 교체할 수 있게 되는 즉시 업데이트가 진행됩니다. `terminateJobsOnUpdate=false`를 설정하면 지정된 제한 시간(기본 제한 시간은 30분) 동안 실행 중인 작업이 계속 진행되고 제한 시간을 초과하면 작업이 종료됩니다.
**참고**
업데이트 중에 종료된 작업을 재시도하려면 작업 재시도 전략을 구성합니다. 자세한 내용은 [작업 자동 재시도](job_retries.md) 단원을 참조하십시오.
------
#### [ Performing infrastructure updates using the AWS Management Console ]
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) AWS Batch 콘솔을 엽니다.
1. 탐색 창에서 **환경**을 선택한 다음 **컴퓨팅 환경** 탭을 선택합니다.
1. 업데이트할 컴퓨팅 환경을 선택합니다.
1. **작업**을 선택하고 **편집**을 선택합니다.
1. **업데이트 동작** 섹션에서 실행 중인 작업을 처리하는 방법을 구성합니다.
+ **최신 버전으로 AMI 업데이트**를 선택하여 AMI를 최신 버전으로 업데이트합니다.
+ 업데이트 프로세스가 실행된 후 작업을 종료하려면 **업데이트 즉시 작업 종료**를 선택합니다.
+ **작업 실행 제한 시간**에 업데이트 프로세스를 시작하기 전에 대기할 시간(분)을 입력합니다.
1. [인프라 업데이트가 필요한 설정](#infrastructure-updates-triggers)을 하나 이상 수정합니다. 예제:
+ **인스턴스 역할**
+ **EC2 스팟 인스턴스 사용**
+ **허용되는 인스턴스 유형**
+ **배치 그룹**
+ **EC2 키 페어**
+ **EC2 구성**
+ **시작 템플릿**
+ **서브넷**
+ **보안 그룹**
1. **변경 사항 저장**을 선택합니다.
1. 컴퓨팅 환경 상태를 모니터링합니다. 업데이트 프로세스 동안 환경은 `UPDATING`으로 표시됩니다.
------
#### [ Performing infrastructure updates using the AWS CLI ]
**update-compute-environment** 명령을 사용하여 [인프라 업데이트가 필요한 설정](#infrastructure-updates-triggers)을 하나 이상 변경합니다. 다음 세 가지 예제는 흔히 수행되는 인프라 작업입니다.
+ 이 예제는 인스턴스 유형을 업데이트하고 업데이트 정책을 구성합니다.
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources instanceTypes=default_x86_64 \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=30
```
+ 이 예제는 VPC 서브넷 및 보안 그룹을 업데이트합니다.
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources subnets=subnet-abcd1234,subnet-efgh5678 securityGroupIds=sg-abcd1234 \
--update-policy terminateJobsOnUpdate=true
```
+ 이 예제는 최신 Amazon ECS 최적화 AMI에 대한 자동 업데이트를 활성화합니다.
```
aws batch update-compute-environment \
--compute-environment your-compute-environment-name \
--compute-resources updateToLatestImageVersion=true \
--update-policy terminateJobsOnUpdate=false,jobExecutionTimeoutMinutes=60
```
------
## 인프라 업데이트 모니터링
AWS Batch 콘솔을 사용하여 인프라 업데이트를 모니터링하여 로의 컴퓨팅 환경 상태 변경을 모니터링하고`UPDATING`, 인스턴스 교체 진행 상황을 모니터링하고, 실패한 업데이트가 있는지 확인합니다. 컴퓨팅 환경 상태가 `VAILD`가 되면 업데이트가 성공한 것입니다. CloudWatch를 사용하여 인스턴스 종료 이벤트를 추적하고 업데이트 동안 작업 상태를 모니터링할 수도 있습니다. 에서 **describe-compute-environments** 명령을 AWS CLI사용하여 상태를 확인하고 인스턴스 수명 주기 이벤트를 모니터링합니다.
# 컴퓨팅 환경에 대한 블루/그린 업데이트 수행
블루/그린 업데이트는 기존 컴퓨팅 환경(블루)과 함께 새 컴퓨팅 환경(그린)을 생성하여 가동 중지 시간과 리스크를 줄이는 업데이트 전략입니다. 이 접근 방식은 기존 환경의 작동을 유지하면서 워크로드를 새 환경으로 점진적으로 전환할 수 있게 해 줍니다. 블루/그린 업데이트는 가장 안전한 업데이트 경로를 제공하며 모든 서비스 역할 유형 또는 할당 전략과 작동합니다.
## 개요
블루/그린 업데이트는 프로덕션 환경에 적합한 몇 가지 이점을 제공합니다. 업데이트 프로세스 중에 워크로드의 지속적인 실행을 유지하여 *가동 중지 시간을 0으로 유지*합니다. 이 접근 방식을 사용하면 *쉬운 롤백*이 가능하여 문제가 발생했을 때 원래 환경으로 빠르게 되돌릴 수 있습니다. *점진적 전환* 전략을 구현하여 프로덕션 워크로드를 완전히 전환하기 전에 새 환경의 성능을 확인할 수 있습니다. 또한 이 방법은 제거를 선택하기 전까지 원래 환경이 변경 없이 운영되므로 뛰어난 *위험 완화* 기능을 제공합니다.
### 블루/그린 업데이트가 필요한 경우
다음과 같은 상황에서는 블루/그린 업데이트를 사용해야 합니다.
+ 컴퓨팅 환경에서 `BEST_FIT` 할당 전략을 사용하는 경우(인프라 업데이트를 지원하지 않음)
+ 컴퓨팅 환경에서 *AWSServiceRoleForBatch* 서비스 연결 역할을 사용하지 않는 경우
+ 서로 다른 서비스 역할 유형 간에 전환해야 하는 경우
### 블루/그린 업데이트가 권장되는 경우
블루/그린 업데이트는 워크로드의 가동 중지 시간이 0이어야 하는 프로덕션 환경에 특히 권장됩니다. 이 접근 방식은 프로덕션 워크로드를 전환하기 전에 새 구성을 테스트하여 변경 사항이 성능 및 신뢰성 요구 사항을 충족하는지 확인해야 할 때 효과적입니다. 특히 상당한 변경 사항이 있는 사용자 지정 AMI를 업데이트하는 경우 등 운영에 있어 빠른 롤백 기능이 중요할 때 블루/그린 업데이트를 선택합니다. 이 방법은 변경 사항을 완전히 적용하기 전에 성능 특성 및 동작을 검증하여 업데이트 프로세스에 대한 신뢰도를 제공하려는 경우에도 이상적입니다.
### 사전 조건
블루/그린 업데이트를 수행하기 전에 다음을 확인합니다.
+ 컴퓨팅 환경을 생성 및 관리할 수 있는 적절한 [IAM 권한](IAM_policies.md#IAM_policies.title)
+ 작업 대기열 설정을 보고 수정할 수 있는 액세스 권한
+ 전환 중에 발생할 수 있는 장애를 처리하기 위해 작업 정의에 대해 구성된 작업 재시도 전략 자세한 내용은 [작업 자동 재시도](job_retries.md) 단원을 참조하십시오.
+ 새 컴퓨팅 환경의 AMI ID. 이는 다음 중 하나일 수 있습니다.
+ Amazon ECS 최적화 AMI의 승인된 최신 버전(기본적으로 사용됨)
+ Amazon ECS 컨테이너 인스턴스 AMI 사양을 충족하는 사용자 지정 AMI 사용자 지정 AMI를 사용하는 경우 다음 방법 중 하나로 지정할 수 있습니다.
+ EC2 구성에서 **이미지 ID 재정의** 필드 사용
+ 시작 템플릿에서 지정
자체 사용자 지정 AMI 생성에 대한 자세한 정보는 [자습서: 컴퓨팅 리소스 AMI 생성](create-batch-ami.md) 섹션을 참조하세요.
새 환경을 생성하기 전에 기존 컴퓨팅 환경의 구성을 기록해 두어야 합니다. AWS Management Console 또는를 사용하여이 작업을 수행할 수 있습니다 AWS CLI.
**참고**
다음 절차에서는 AMI만 변경하는 블루/그린 업데이트를 수행하는 방법을 자세히 설명합니다. 새 환경에 대한 다른 설정을 업데이트할 수 있습니다.
**중요**
이전(블루) 컴퓨팅 환경을 제거하면 인스턴스가 종료되므로 해당 인스턴스에서 현재 실행 중인 모든 작업이 실패합니다. 이러한 실패를 자동 처리하도록 작업 정의에 작업 재시도 전략을 구성하세요. 자세한 내용은 [작업 자동 재시도](job_retries.md) 단원을 참조하십시오.
새 환경에 대한 확신이 생기면:
작업 대기열을 편집하여 이전 컴퓨팅 환경을 제거합니다.
이전 환경에서 실행 중인 작업이 완료될 때까지 기다립니다.
이전 컴퓨팅 환경을 삭제합니다.
------
#### [ Performing blue/green updates using the AWS Management Console ]
1. 현재 컴퓨팅 환경 복제
1. [https://console.aws.amazon.com/batch/](https://console.aws.amazon.com/batch/) AWS Batch 콘솔을 엽니다.
1. 기존 컴퓨팅 환경을 선택합니다.
1. **작업**을 선택한 다음 **복제**를 선택합니다.
1. **이름**에 해당 컴퓨팅 환경의 고유한 이름을 입력합니다.
1. **다음**을 선택합니다.
1. **인스턴스 구성** 섹션에서 AMI 설정을 업데이트합니다.
1. **추가 구성**을 확장합니다.
1. **EC2 구성**에서 **이미지 유형**에 새 AMI 유형을 지정하고 **이미지 ID 재정의** 필드에 AMI ID를 지정합니다.
1. **다음**을 선택합니다.
1. **네트워크 구성**에서 **다음**을 선택합니다.
1. 기존 환경에서 자동으로 복사되는 다른 설정을 검토합니다.
1. **컴퓨팅 환경 생성**을 선택합니다.
1. 새 컴퓨팅 환경 상태가 `VALID`가 될 때까지 기다립니다.
1. 작업 대기열 순서 변경
1. 탐색 창에서 **작업 대기열**을 선택합니다.
1. 기존 컴퓨팅 환경과 연결된 작업 대기열을 선택합니다.
1. **편집**을 선택합니다.
1. **연결된 컴퓨팅 환경**에 새 컴퓨팅 환경을 추가합니다.
+ 기존 환경보다 순서 번호가 높게 새 컴퓨팅 환경을 추가하여 워크로드를 전환합니다.
+ 새 환경이 올바르게 작동하는지 확인한 후에는 더 낮은 순서 번호를 지정하여 기본 환경으로 만들 수 있습니다.
1. **작업 대기열 업데이트**를 선택합니다.
1. 정리
1. 새 환경에서 작업 실행을 모니터링하여 모든 것이 예상대로 작동하는지 확인합니다.
1. 새 환경에 대한 확신이 생기면:
1. 작업 대기열을 편집하여 이전 컴퓨팅 환경을 제거합니다.
1. 이전 환경에서 실행 중인 작업이 완료될 때까지 기다립니다.
1. 이전 컴퓨팅 환경을 삭제합니다.
------
#### [ Performing blue/green updates using the AWS CLI ]
1. 를 사용하여 구성을 가져오려면 다음 명령을 AWS CLI사용합니다.
```
aws batch describe-compute-environments \
--compute-environments your-compute-environment-name
```
새 환경을 생성할 때 참조할 수 있도록 출력을 저장해 둡니다.
1. 기존 환경의 구성을 사용하되 새 AMI를 사용하여 새 컴퓨팅 환경을 생성합니다. 다음은 명령 구조의 예입니다.
예제 값을 이전 단계의 실제 구성으로 바꿉니다.
```
cat < ./blue-green-compute-environment.json
{
"computeEnvironmentName": "your-new-compute-environment-name",
"type": "MANAGED",
"state": "ENABLED",
"computeResources": {
"instanceRole": "arn:aws:iam::012345678901:instance-profile/ecsInstanceRole",
"type": "EC2",
"minvCpus": 2,
"desiredvCpus": 2,
"maxvCpus": 256,
"instanceTypes": [
"optimal"
],
"allocationStrategy": "BEST_FIT_PROGRESSIVE",
"ec2Configuration": [
{
"imageType": "ECS_AL2023",
"imageIdOverride": "ami-0abcdef1234567890"
}
],
"subnets": [,
"subnet-0abcdef1234567890"
],
"securityGroupIds": [
"sg-0abcdef1234567890"
]
}
}
EOF
```
```
$ aws batch create-compute-environment --cli-input-json file://./blue-green-compute-environment.json
```
1. 새 환경을 사용할 수 있을 때까지 기다립니다.
```
aws batch describe-compute-environments \
--compute-environments your-new-compute-environment-name \
--query 'computeEnvironments[].status'
```
1. 작업 대기열에 새 컴퓨팅 환경을 추가합니다.
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-existing-environment \
order=2,computeEnvironment=your-new-compute-environment-name
```
1. 확인되면 다시 업데이트하여 새 환경을 기본 환경으로 만듭니다.
```
aws batch update-job-queue \
--job-queue your-job-queue \
--compute-environment-order order=1,computeEnvironment=your-new-compute-environment-name
```
이전 환경에서 모든 작업이 완료되면 해당 환경을 비활성화한 다음 삭제합니다.
```
aws batch update-compute-environment \
--compute-environment your-existing-environment \
--state DISABLED
```
```
aws batch delete-compute-environment \
--compute-environment your-existing-environment
```
------