3 <= 0.5 * 1 => 200| 3(계산된 값이 최솟값보다 작음) | | 25 |
3 <= 0.5 * 25 => 200| 13(값이 반올림됨) | | 400 |
3 <= 0.5 * 400 => 200| 200 | | 800 |
3 <= 0.5 * 800 => 200| 200(계산된 값이 최댓값보다 큼) | 예를 들어, 임계값이 3인 경우 회로 차단기는 실패 횟수가 0으로 설정된 상태에서 시작됩니다. 작업이 `RUNNING` 상태에 도달하지 못하면 배포 회로 차단기가 실패 횟수를 하나씩 늘립니다. 실패 횟수가 3과 같아지면 배포가 `FAILED`로 표시됩니다. 롤백 옵션을 사용하는 방법에 대한 추가 예제는 [Amazon ECS 배포 회로 차단기 발표](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/)를 참조하세요. # CloudWatch 경보가 Amazon ECS 배포 장애를 감지하는 방법 지정된 CloudWatch 경보가 `ALARM` 상태로 전환된 것을 탐지하면 배포를 실패로 설정하도록 Amazon ECS를 구성할 수 있습니다. 실패한 배포를 마지막으로 완료된 배포로 롤백하도록 구성을 설정할 수 있습니다. 다음 `create-service` AWS CLI 예제에서는 배포 경보에 롤백 옵션이 사용된 경우 Linux 서비스를 생성하는 방법을 보여줍니다. ``` aws ecs create-service \ --service-name MyService \ --deployment-controller type=ECS \ --desired-count 3 \ --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \ --task-definition sample-fargate:1 \ --launch-type FARGATE \ --platform-family LINUX \ --platform-version 1.4.0 \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}" ``` 서비스에서 Amazon CloudWatch 경보 메서드를 사용하는 경우 다음을 고려하세요. + 프로덕션 트래픽이 이동한 후 블루 및 그린 서비스 개정이 모두 동시에 실행되는 기간. Amazon ECS는 배포와 관련된 경보 구성을 기반으로 이 기간을 계산합니다. 이 값을 설정할 수 없습니다. + 이제 `deploymentConfiguration` 요청 파라미터에 `alarms` 데이터 유형이 포함됩니다. 경보 이름, 메서드 사용 여부 및 경보가 배포 실패를 나타내는 경우 롤백을 시작할지 여부를 지정할 수 있습니다. 자세한 내용은 **Amazon Elastic Container Service API 참조의 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)를 참조하세요. + `DescribeServices` 응답은 배포 상태인 `rolloutState` 및 `rolloutStateReason`에 대한 인사이트를 제공합니다. 새 배포가 시작되면 롤아웃 상태는 `IN_PROGRESS` 상태에서 시작됩니다. 서비스가 안정 상태에 도달하고 베이크 소요 시간이 완료되면 롤아웃 상태가 `COMPLETED`로 전환됩니다. 서비스가 안정 상태에 도달하지 못하고 경보가 `ALARM` 상태로 전환되면 배포가 `FAILED` 상태로 전환됩니다. `FAILED` 상태의 배포는 새로운 태스크를 시작하지 않습니다. + Amazon ECS는 시작되고 완료된 배포에 대해 서비스 배포 상태 변경 이벤트를 전송합니다. 또한 Amazon ECS는 해당 경보를 사용하는 배포가 실패할 경우 이벤트를 전송합니다. 이러한 이벤트는 배포가 실패한 이유 또는 롤백으로 인해 배포가 시작된 경우에 대한 세부 정보를 제공합니다. 자세한 내용은 [Amazon ECS 서비스 배포 상태 변경 이벤트](ecs_service_deployment_events.md) 섹션을 참조하세요. + 이전 배포가 실패하고 롤백이 켜졌기 때문에 새 배포가 시작된 경우 서비스 배포 상태 변경 이벤트의 `reason` 필드에 롤백 때문에 배포가 시작되었음이 표시됩니다. + 배포 회로 차단기와 Amazon CloudWatch 경보를 사용하여 실패를 탐지하는 경우 메서드 중 하나에 대한 기준이 충족되는 즉시 메서드 중 하나에서 배포 실패를 시작할 수 있습니다. 롤백은 배포 실패를 시작한 메서드에 대해 롤백 옵션을 사용할 때 발생합니다. + Amazon CloudWatch 경보는 롤링 업데이트(`ECS`) 배포 컨트롤러를 사용하는 Amazon ECS 서비스에만 지원됩니다. + Amazon ECS 콘솔 또는 AWS CLI를 사용하여 이 옵션을 구성할 수 있습니다. 자세한 내용은 *AWS Command Line Interface 참조*에서 [정의된 파라미터를 사용하여 서비스 생성](create-service-console-v2.md#create-custom-service) 및 [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)를 참조하세요. + 배포 상태가 장시간 동안 `IN_PROGRESS`로 유지되는 것을 알 수 있습니다. 그 이유는 활성 배포를 삭제할 때까지 Amazon ECS에서 상태가 변경되지 않기 때문이며 베이크 소요 시간이 지나야 이러한 상황이 발생하지 않습니다. 경보 구성에 따라 새 기본 작업 세트는 스케일 업되고 이전 배포는 스케일 다운되더라도 경보를 사용하지 않을 때보다 배포가 몇 분 더 오래 걸리는 것처럼 보일 수 있습니다. CloudFormation 제한 시간을 사용하는 경우 제한 시간을 늘리는 것이 좋습니다. 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [템플릿에 대기 조건 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html)을 참조하세요. + Amazon ECS는 `DescribeAlarms`를 호출하여 경보를 폴링합니다. `DescribeAlarms` 호출 수는 계정과 연결된 CloudWatch 서비스 할당량에 포함됩니다. `DescribeAlarms`를 호출하는 다른 AWS 서비스가 있는 경우 Amazon ECS에서 경보를 폴링하는 데 영향을 받을 수 있습니다. 예를 들어 다른 서비스가 할당량에 도달할 만큼 충분히 `DescribeAlarms`를 직접 호출하면 해당 서비스는 제한이 발생하고 Amazon ECS 역시 제한이 발생하여 경보를 폴링할 수 없습니다. 제한 기간에 경보가 생성되면 Amazon ECS에서 경보를 놓치고 롤백이 발생하지 않을 수 있습니다. 배포에 다른 영향을 미치지 않습니다. CloudWatch 서비스 할당량에 대한 자세한 내용은 *CloudWatch 사용 설명서*의 [CloudWatch 서비스 할당량](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm)을 참조하세요. + 배포 시작 시 경보가 `ALARM` 상태인 경우 Amazon ECS는 해당 배포 기간 동안 경보를 모니터링하지 않습니다(Amazon ECS는 경보 구성을 무시함). 이 동작은 초기 배포 실패를 수정하기 위해 새 배포를 시작하려는 경우를 다룹니다. ## 권장되는 경보 다음 경보 지표를 사용하는 것이 좋습니다. + Application Load Balancer를 사용하는 경우 `HTTPCode_ELB_5XX_Count` 및 `HTTPCode_ELB_4XX_Count` Application Load Balancer 지표를 사용합니다. 이러한 지표는 HTTP 급증을 확인합니다. Application Load Balancer 지표에 대한 자세한 내용은 Application Load Balancer 사용 설명서**의 [Application Load Balancer의 CloudWatch 지표](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)를 참조하세요. + 기존 애플리케이션이 있는 경우 `CPUUtilization` 및 `MemoryUtilization` 지표를 사용합니다. 이러한 지표는 클러스터 또는 서비스가 사용하는 CPU 및 메모리의 비율을 확인합니다. 자세한 내용은 [고려 사항](cloudwatch-metrics.md#enable_cloudwatch) 섹션을 참조하세요. + 작업에서 Amazon Simple Queue Service 대기열을 사용하는 경우 `ApproximateNumberOfMessagesNotVisible` Amazon SQS 지표를 사용합니다. 이 지표는 지연되어 즉시 읽을 수 없는 대기열의 메시지 수를 확인합니다. Amazon SQS 지표에 대한 자세한 내용은 *Amazon Simple Queue Service 개발자 안내서*의 [Amazon SQS에 사용 가능한 CloudWatch 지표](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)를 참조하세요. ## 베이크 소요 시간 서비스 배포에 대해 롤백 옵션을 사용하는 경우 Amazon ECS는 대상 서비스 개정이 배포된 후 CloudWatch 경보를 전송하기 전에 추가 시간을 기다립니다. 이를 베이크 소요 시간이라고 합니다. 이 시간은 다음 이후에 시작됩니다. + 대상 서비스 개정의 모든 태스크가 실행 중이고 정상 상태임 + 소스 서비스 개정은 0%로 스케일 다운됨 기본 베이크 소요 시간은 5분 미만입니다. 베이크 소요 시간이 만료되면 서비스 배포가 완료된 것으로 표시됩니다. 롤링 배포의 베이크 소요 시간을 구성할 수 있습니다. CloudWatch 경보를 사용하여 장애를 감지하고 베이크 소요 시간을 변경한 다음 Amazon ECS 기본값을 원하는 경우 베이크 소요 시간을 수동으로 설정해야 합니다. # Amazon ECS 서비스 배포에 대한 수명 주기 후크 배포가 시작되면 수명 주기 단계가 진행됩니다. 이러한 단계는 IN\$1PROGRESS 또는 성공과 같은 상태일 수 있습니다. Amazon ECS가 사용자를 대신해 지정된 수명 주기 단계에서 실행하는 Lambda 함수인 수명 주기 후크를 사용할 수 있습니다. 함수는 다음 중 하나일 수 있습니다. + 15분 이내에 상태 확인을 검증하는 비동기 API. + 수명 주기 후크 완료를 평가하는 다른 비동기 프로세스를 시작하는 폴링 API. 함수 실행이 완료된 후 배포를 계속하려면 `hookStatus`를 반환해야 합니다. `hookStatus`가 반환되지 않거나 함수에 실패하면 배포가 롤백됩니다. 다음은 `hookStatus` 값입니다. + `SUCCEEDED` - 배포는 다음 수명 주기 단계로 계속 진행됨 + `FAILED` - 배포는 마지막으로 성공한 배포로 롤백됩니다. + `IN_PROGRESS` - Amazon ECS는 짧은 시간 후에 함수를 다시 실행합니다. 기본적으로 30초 간격이지만 `hookStatus`와 함께 `callBackDelay`를 반환하여 이 값을 사용자 지정할 수 있습니다. 다음 예제에서는 사용자 지정 콜백 지연으로 `hookStatus`를 반환하는 방법을 보여줍니다. 이 예제에서 Amazon ECS는 기본 30초 대신 60초 후에 이 후크를 재시도합니다. ``` { "hookStatus": "IN_PROGRESS", "callBackDelay": 60 } ``` 롤백이 수행되면 Amazon ECS는 다음 수명 주기 단계에 대해 수명 주기 후크를 실행합니다. + PRODUCTION\$1TRAFFIC\$1SHIFT + TEST\$1TRAFFIC\$1SHIFT ## 수명 주기 페이로드 ECS 서비스 배포에 대한 수명 주기 후크를 구성하면 Amazon ECS는 배포 프로세스의 특정 단계에서 이 후크를 간접 호출합니다. 각 수명 주기 단계는 배포의 현재 상태에 대한 정보를 포함하는 JSON 페이로드를 제공합니다. 이 문서에서는 각 수명 주기 단계의 페이로드 구조를 설명합니다. ### 공통 페이로드 구조 모든 수명 주기 단계 페이로드는 다음과 같은 공통 필드를 포함합니다. + `serviceArn` - 서비스의 Amazon 리소스 이름(ARN). + `targetServiceRevisionArn` - 배포 중인 대상 서비스 개정의 ARN. + `testTrafficWeights` - 해당 테스트 트래픽 가중치 백분율에 대한 서비스 개정 ARN의 맵. + `productionTrafficWeights` - 해당 프로덕션 트래픽 가중치 백분율에 대한 서비스 개정 ARN의 맵. ### 수명 주기 단계 페이로드 #### RECONCILE\$1SERVICE 이 단계는 서비스가 조정될 때 배포 프로세스 시작 시점에 나타납니다. 다음은 이 수명 주기 단계의 페이로드 예제를 보여줍니다. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 }, "productionTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 } } ``` **이 단계에서 기대 사항:** + 기본 태스크 세트 규모가 0%임 #### PRE\$1SCALE\$1UP 이 단계는 새 태스크가 스케일 업되기 전에 나타납니다. 다음은 이 수명 주기 단계의 페이로드 예제를 보여줍니다. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **이 단계에서 기대 사항:** + 그린 서비스 개정 태스크 규모가 0%임 #### POST\$1SCALE\$1UP 이 단계는 새 태스크가 스케일 업되고 정상 상태가 된 후에 나타납니다. 다음은 이 수명 주기 단계의 페이로드 예제를 보여줍니다. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **이 단계에서 기대 사항:** + 그린 서비스 개정 태스크 규모가 100%임 + 그린 서비스 개정의 태스크가 정상 상태임 #### TEST\$1TRAFFIC\$1SHIFT 이 단계는 테스트 트래픽이 그린 서비스 개정 태스크로 전환될 때 나타납니다. 다음은 이 수명 주기 단계의 페이로드 예제를 보여줍니다. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 }, "productionTrafficWeights": {} } ``` **이 단계에서 기대 사항:** + 테스트 트래픽이 그린 서비스 개정 태스크로 이동하는 중입니다. #### POST\$1TEST\$1TRAFFIC\$1SHIFT 이 단계는 테스트 트래픽이 새 태스크로 완전히 전환된 후에 나타납니다. 다음은 이 수명 주기 단계의 페이로드 예제를 보여줍니다. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **이 단계에서 기대 사항:** + 테스트 트래픽의 100%가 그린 서비스 개정 태스크로 이동했습니다. #### PRODUCTION\$1TRAFFIC\$1SHIFT 이 단계는 프로덕션 트래픽이 그린 서비스 개정 태스크로 전환될 때 나타납니다. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": { "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100, "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0 } } ``` **이 단계에서 기대 사항:** + 프로덕션 트래픽이 그린 서비스 개정으로 이동하는 중입니다. #### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT 이 단계는 프로덕션 트래픽이 그린 서비스 개정 태스크로 완전히 전환된 후에 나타납니다. ``` { "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892", "testTrafficWeights": {}, "productionTrafficWeights": {} } ``` **이 단계에서 기대 사항:** + 프로덕션 트래픽의 100%가 그린 서비스 개정 태스크로 이동했습니다. ### 수명 주기 단계 범주 수명 주기 단계는 다음과 같은 두 가지 범주로 구분됩니다. 1. **단일 간접 호출 단계** - 이 단계는 서비스 배포 중에 한 번만 간접 호출됩니다. + PRE\$1SCALE\$1UP + POST\$1SCALE\$1UP + POST\$1TEST\$1TRAFFIC\$1SHIFT + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT 1. **반복 간접 호출 단계** - 롤백 작업이 수행되는 경우와 같이 서비스 배포 중에 이 단계는 여러 번 간접 호출될 수 있습니다. + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT ### 수명 주기 후크 중 배포 상태 수명 주기 후크가 실행되는 동안 배포 상태는 모든 수명 주기 단계에서 `IN_PROGRESS`입니다. | 수명 주기 단계 | 배포 상태 | | --- | --- | | RECONCILE\$1SERVICE | IN\$1PROGRESS | | PRE\$1SCALE\$1UP | IN\$1PROGRESS | | POST\$1SCALE\$1UP | IN\$1PROGRESS | | TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | POST\$1TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | # Amazon ECS 서비스 배포 중지 회로 차단기 또는 CloudWatch 경보에서 실패한 배포를 감지하지 못한 경우 배포를 수동으로 중지할 수 있습니다. 다음과 같은 중지 유형을 사용할 수 있습니다. + 롤백 - 이 옵션은 서비스 배포를 이전 서비스 개정으로 롤백합니다. 서비스 배포에 롤백 옵션을 구성하지 않은 경우에도 이 옵션을 사용할 수 있습니다. 다음 상태 중 하나에 있는 배포를 중지할 수 있습니다. 서비스 배포 상태에 대한 자세한 내용은 [Amazon ECS 서비스 배포를 사용하여 서비스 기록 보기](service-deployment.md) 섹션을 참조하세요. + PENDING - 서비스 배포가 ROLLBACK\$1REQUESTED 상태로 바뀐 다음 롤백 작업이 시작됩니다. + IN\$1PROGRESS - 서비스 배포가 ROLLBACK\$1REQUESTED 상태로 바뀐 다음 롤백 작업이 시작됩니다. + STOP\$1REQUESTED - 서비스 배포가 계속 중지됩니다. + ROLLBACK\$1REQUESTED - 서비스 배포가 롤백 작업을 계속합니다. + ROLLBACK\$1IN\$1PROGRESS - 서비스 배포가 롤백 작업을 계속합니다. ## 절차 시작하기 전에 서비스 배포를 보는 데 필요한 권한을 구성합니다. 자세한 내용은 [Amazon ECS 서비스 배포를 보는 데 필요한 권한](service-deployment-permissions.md) 섹션을 참조하세요. ------ #### [ Amazon ECS Console ] 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 섹션에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 표시됩니다. 1. 배포 세부 정보 페이지에서 **배포**를 선택합니다. 배포 페이지가 표시됩니다. 1. **진행 중인 배포**에서 **롤백**을 선택합니다. 그런 다음 확인 창에서 **롤백**을 선택합니다. ------ #### [ AWS CLI ] 1. `list-service-deployments`를 실행하여 서비스 배포 ARN을 검색합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. ``` aws ecs list-service-deployments --cluster cluster-name --service service-name ``` 중지하려는 배포의 `serviceDeploymentArn`을 기록해 둡니다. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095", "status": "SUCCESSFUL" } ] } ``` 1. `stop-service-deployments`를 실행합니다. `list-service-deployments`에서 반환된 `serviceDeploymentArn`을 사용합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. ``` aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK ``` ------ ## 다음 단계 서비스에 어떤 변경이 필요한지 결정한 다음 서비스를 업데이트합니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. # 태스크를 대체하여 Amazon ECS 서비스 배포 **롤링 업데이트(`ECS`) 배포 유형을 사용하는 서비스를 생성하면 Amazon ECS 서비스 스케줄러가 현재 실행 중인 태스크를 새 태스크로 대체합니다. 롤링 업데이트 중에 Amazon ECS가 서비스에 추가하거나 서비스에서 제거하는 작업의 수는 서비스 배포 구성으로 제어합니다. Amazon ECS에서는 태스크 수 결정에 다음과 같은 파라미터가 사용됩니다. + `minimumHealthyPercent`는 롤링 배포 중 또는 컨테이너 인스턴스가 드레이닝 시 서비스에 대해 정상 상태로 실행되어야 하는 태스크 수에 대한 하한을 서비스에 대해 원하는 태스크 수의 백분율로 나타냅니다. 이 값은 반올림됩니다. 예를 들어, 최소 정상 상태 백분율이 `50`이고 원하는 작업 수가 4인 경우 스케줄러는 두 개의 새 태스크를 시작하기 전에 두 개의 기존 태스크를 중지할 수 있습니다. 마찬가지로 최소 정상 상태 백분율이 75%이고 원하는 작업 수가 2이면 결과 값이 2이기 때문에 스케줄러는 태스크를 중지 할 수 없습니다. + `maximumPercent`는 롤링 배포 중 또는 컨테이너 인스턴스가 드레이닝 시 서비스에 대해 실행되어야 하는 태스크 수에 대한 상한을 서비스에 대해 원하는 태스크 수의 백분율로 나타냅니다. 이 값은 내림됩니다. 예를 들어 최대 백분율이 `200`이고 원하는 태스크 수가 4개인 경우 스케줄러는 4개의 기존 태스크를 중지하기 전에 4개의 새 태스크를 시작할 수 있습니다. 마찬가지로 최대 백분율이 `125`이고 원하는 작업 수가 3이면 결과 값이 3이기 때문에 스케줄러는 태스크를 시작할 수 없습니다. 롤링 배포 중에 작업이 비정상 상태가 되면 Amazon ECS가 이를 대체하여 서비스의 `minimumHealthyPercent`를 유지 관리하고 가용성을 보호합니다. 비정상 태스크는 해당 태스크가 속한 것과 동일한 서비스 개정을 사용하여 대체됩니다. 이를 통해 소스 개정의 비정상 태스크 교체가 대상 개정의 태스크 장애와 독립적으로 수행됩니다. `maximumPercent` 설정이 허용되면 스케줄러는 비정상 태스크를 중지하기 전에 교체 태스크를 시작합니다. `maximumPercent` 파라미터로 인해 스케줄러가 교체 태스크를 먼저 시작하지 못하면 스케줄러는 비정상 태스크를 한 번에 하나씩 임의로 중지하여 용량을 확보한 다음 교체 태스크를 시작합니다. **중요** 최소 정상 상태 백분율 또는 최대 백분율을 설정할 때는 배포가 시작될 때 스케줄러가 하나 이상의 작업을 중지하거나 시작할 수 있는지 확인해야 합니다. 서비스에 잘못된 배포 구성으로 인해 중단된 배포가 있는 경우 서비스 이벤트 메시지가 전송됩니다. 자세한 내용은 [서비스 배포 구성으로 인해 배포 중에 서비스(*service-name*)에서 태스크를 중지하거나 시작할 수 없습니다. minimumHealthyPercent 또는 maximumPercent 값을 업데이트하고 다시 시도하세요.](service-event-messages-list.md#service-event-messages-7) 섹션을 참조하세요. 롤링 배포에는 서비스 배포에 실패한 시점을 빠르게 식별하는 방법이 제공되는 두 가지 방법이 있습니다. + [Amazon ECS 배포 회로 차단기가 장애를 감지하는 방법](deployment-circuit-breaker.md) + [CloudWatch 경보가 Amazon ECS 배포 장애를 감지하는 방법](deployment-alarm-failure.md) 두 방법을 따로 또는 함께 사용할 수 있습니다. 두 방법을 모두 사용하는 경우 두 가지 실패 방법 중 하나에 대한 실패 기준이 충족되는 즉시 배포가 실패로 설정됩니다. 다음 가이드라인을 사용하면 사용할 방법을 결정하는 데 도움이 됩니다. + 회로 차단기 - 작업을 시작할 수 없을 때 배포를 중지하려는 경우 이 방법을 사용합니다. + CloudWatch 경보 - 애플리케이션 지표를 기반으로 배포를 중지하려는 경우 이 방법을 사용합니다. 두 가지 방법 모두 이전 서비스 개정으로 롤백이 지원됩니다. ## 컨테이너 이미지 확인 기본적으로 Amazon ECS에서는 태스크 정의에 지정된 컨테이너 이미지 태그를 컨테이너 이미지 다이제스트로 확인합니다. 단일 태스크가 실행되고 유지 관리되는 서비스를 생성하는 경우 태스크의 컨테이너에 대한 이미지 다이제스트 설정에 해당 태스크가 사용됩니다. 여러 태스크가 실행되고 유지 관리되는 서비스를 생성하는 경우 배포 중 서비스 스케줄러에 따라 시작된 첫 번째 태스크가 태스크의 컨테이너에 대한 이미지 다이제스트 설정에 사용됩니다. 컨테이너 이미지 다이제스트 설정 시도가 3회 이상 실패할 경우 이미지 다이제스트 확인 없이 배포가 계속됩니다. 배포 회로 차단기가 활성화된 경우 배포가 추가로 실패하고 롤백됩니다. 컨테이너 이미지 다이제스트가 설정되면 Amazon ECS에서는 이 다이제스트를 사용하여 필요한 모든 다른 작업을 시작하고 향후 서비스 업데이트를 진행합니다. 따라서 서비스의 모든 작업이 항상 동일한 컨테이너 이미지를 실행하게 되므로 소프트웨어의 버전 일관성이 유지됩니다. 컨테이너 정의의 `versionConsistency` 파라미터를 사용하여 태스크의 컨테이너마다 동작을 구성할 수 있습니다. 자세한 내용은 [versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency) 섹션을 참조하세요. **참고** 버전이 `1.31.0`보다 낮은 Amazon ECS 에이전트는 이미지 다이제스트 해상도를 지원하지 않습니다. `1.31.0`\$1`1.69.0` 버전의 에이전트는 Amazon ECR 리포지토리로 푸시된 이미지에 대해서만 이미지 다이제스트 해상도를 지원합니다. 버전이 `1.70.0` 이상인 에이전트는 모든 이미지에 대해 이미지 다이제스트 해상도를 지원합니다. 이미지 다이제스트 해상도의 최소 Fargate Linux 플랫폼 버전은 `1.3.0`입니다. 이미지 다이제스트 해상도의 최소 Fargate Windows 플랫폼 버전은 `1.0.0`입니다. Amazon ECS는 Amazon GuardDuty 보안 에이전트 또는 Service Connect 프록시와 같이 Amazon ECS에서 관리하는 사이드카 컨테이너의 다이제스트는 캡처하지 않습니다. 여러 작업이 포함된 서비스에서 컨테이너 이미지 확인과 관련된 잠재적 지연 시간을 줄이려면 EC2 컨테이너 인스턴스에서 Amazon ECS 에이전트 버전 `1.83.0` 이상을 실행하세요. 잠재적 지연 시간을 방지하려면 태스크 정의에 컨테이너 이미지 다이제스트를 지정합니다. 원하는 태스크 수가 0인 서비스를 생성하는 경우 원하는 태스크 수가 0보다 큰 서비스의 또 다른 배포를 트리거할 때까지 Amazon ECS에서 컨테이너 다이제스트를 설정할 수 없습니다. 업데이트된 이미지 다이제스트를 설정하려면 새 배포를 강제로 적용할 수 있습니다. 업데이트된 다이제스트는 새 태스크를 시작하는 데 사용되며 이미 실행 중인 태스크에는 영향을 주지 않습니다. 새 배포를 강제로 수행하는 방법에 대한 자세한 내용은 *Amazon ECS API 참조*의 [ForceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment)를 참조하세요. EC2 용량 공급자를 사용할 때 초기 배포 중에 태스크를 시작할 용량이 충분하지 않으면 소프트웨어 버전 일관성을 유지하지 못할 수 있습니다. 용량이 제한된 경우에도 버전 일관성을 유지 관리하려면 기본 동작에 의존하는 대신 태스크 정의 컨테이너 구성에서 명시적으로 `versionConsistency: "enabled"`를 설정합니다. 그러면 Amazon ECS는 배포를 진행하기 전에 용량을 사용할 수 있을 때까지 기다립니다. # Amazon ECS 서비스 파라미터의 모범 사례 애플리케이션 다운타임이 발생하지 않도록 배포 프로세스는 다음과 같습니다. 1. 기존 컨테이너를 계속 실행하면서 새 애플리케이션 컨테이너를 시작합니다. 1. 새 컨테이너가 정상 상태인지 확인합니다. 1. 이전 컨테이너를 중지합니다. 배포 구성과 클러스터의 예약되지 않은 여유 스페이스 크기에 따라 이전 작업을 모두 새 작업으로 교체하려면 이 작업을 여러 번 반복해야 할 수 있습니다. 숫자를 수정하는 데 사용할 수 있는 두 가지 서비스 구성 옵션이 있습니다. + `minimumHealthyPercent`: 100%(기본값) 배포 중 서비스가 `RUNNING` 상태를 유지해야 하는 작업 수의 하한. 가장 가까운 정수로 반올림된 `desiredCount`의 비율입니다. 이 파라미터를 통해 추가 클러스터 용량을 사용하지 않고 배포할 수 있습니다. + `maximumPercent`: 200%(기본값) 배포 중 `RUNNING` 또는 `PENDING` 상태를 유지해야 하는 서비스에 대한 작업 수의 상한. 가장 가까운 정수로 반내림된 `desiredCount`의 비율입니다. **예: 기본 구성 옵션** 총 8개의 작업 공간이 있는 클러스터에 6개의 작업이 배포된 다음과 같은 서비스를 고려합니다. 기본 서비스 구성 옵션으로는 배포에서 원하는 6개 작업의 100% 미만으로 내려갈 수 없습니다. 배포 프로세스는 다음과 같습니다. 1. 목표는 6개 작업을 대체하는 것입니다. 1. 기본 설정에서는 실행 중인 작업이 6개여야 하기 때문에 스케줄러가 2개의 새 작업을 시작합니다. 이제 기존 작업 6개와 새 작업 2개가 있습니다. 1. 스케줄러는 기존 작업 중 2개를 중지합니다. 이제 기존 작업 4개와 새 작업 2개가 있습니다. 1. 스케줄러는 추가로 2개의 새 작업을 시작합니다. 이제 기존 태스크 4개와 새 태스크 4개가 있습니다. 1. 스케줄러는 기존 작업 중 2개를 종료합니다. 이제 기존 작업 2개와 새 작업 4개가 있습니다. 1. 스케줄러는 추가로 2개의 새 작업을 시작합니다. 이제 기존 작업 2개와 새 작업 6개가 있습니다. 1. 스케줄러가 마지막 2개의 기존 작업을 종료합니다. 이제 6개의 새 작업이 있습니다. 위 예제에서 옵션의 기본값을 사용하는 경우 새 작업이 시작될 때마다 2.5분의 대기 시간이 있습니다. 또한 로드 밸런서는 이전 작업이 중지될 때까지 5분을 기다려야 할 수도 있습니다. **예: `minimumHealthyPercent` 수정** `minimumHealthyPercent` 값을 50% 로 설정하여 배포 속도를 높일 수 있습니다. 총 8개의 작업 공간이 있는 클러스터에 6개의 작업이 배포된 다음과 같은 서비스를 고려합니다. 배포 프로세스는 다음과 같습니다. 1. 목표는 6개 작업을 대체하는 것입니다. 1. 스케줄러는 기존 작업 중 3개를 중지합니다. `minimumHealthyPercent` 값을 충족하는 3개의 기존 작업이 아직 실행 중입니다. 1. 스케줄러는 5개의 새 작업을 시작합니다. 이제 기존 작업 3개와 새 작업 5개가 있습니다. 1. 스케줄러는 나머지 3개의 기존 작업을 중지합니다. 이제 5개의 새 작업이 있습니다. 1. 스케줄러는 마지막 새 작업을 시작합니다. 이제 6개의 새 작업이 있습니다. **예: 클러스터 여유 스페이스 수정** 추가 작업을 실행할 수 있도록 여유 스페이스를 더 추가할 수도 있습니다. 총 10개의 작업 공간이 있는 클러스터에 6개의 작업이 배포된 다음과 같은 서비스를 고려합니다. 배포 프로세스는 다음과 같습니다. 1. 목표는 기존 작업을 대체하는 것입니다. 1. 스케줄러는 기존 작업 중 3개를 중지합니다. 이제 3개의 기존 작업이 있습니다. 1. 스케줄러는 6개의 새 작업을 시작합니다. 이제 기존 작업 3개와 새 작업 6개가 있습니다. 1. 스케줄러는 기존 작업 3개를 중지합니다. 이제 6개의 새 작업이 있습니다. **권장 사항** 작업이 한동안 유휴 상태이고 사용률이 높지 않은 경우 서비스 구성 옵션에 다음 값을 사용합니다. + `minimumHealthyPercent`: 50% + `maximumPercent`: 200% # Amazon ECS 롤링 업데이트 배포 생성 클러스터에서 지정된 수의 태스크 정의 인스턴스를 동시에 실행하고 유지 관리하는 서비스를 생성합니다. 태스크가 실패하거나 중지되면 Amazon ECS 서비스 스케줄러가 태스크 정의의 다른 인스턴스를 시작하여 해당 태스크를 대체합니다. 이렇게 하면 서비스에서 원하는 수의 태스크를 유지 관리하는 데 도움이 됩니다. 서비스를 생성하기 전에 다음 구성 파라미터를 결정합니다. + 태스크를 분산하는 두 가지 컴퓨팅 옵션이 있습니다. + **용량 공급자 전략**은 Amazon ECS가 하나 또는 여러 개의 용량 공급자에 태스크를 분배하도록 합니다. Amazon ECS 관리형 인스턴스에서 워크로드를 실행하려면 용량 공급자 전략 옵션을 사용해야 합니다. + **시작 유형**에서는 Amazon ECS가 클러스터에 등록된 Fargate 또는 EC2 인스턴스에 대한 태스크가 Amazon ECS에서 곧바로 시작됩니다. Amazon ECS 관리형 인스턴스에서 워크로드를 실행하려면 용량 공급자 전략 옵션을 사용해야 합니다. + `awsvpc` 네트워크 모드 또는 로드 밸런서를 사용하도록 구성된 서비스를 사용하는 태스크 정의에 네트워킹 구성이 있어야 합니다. 기본적으로 콘솔은 기본 Amazon VPC와 모든 서브넷 및 기본 Amazon VPC 내의 기본 보안 그룹을 선택합니다. + 배치 전략인 기본 태스크 배치 전략에서는 가용 영역 전체에 균등하게 태스크가 분산됩니다. 서비스의 고가용성 확보에 도움이 되도록 가용 영역 리밸런싱을 사용하는 것이 좋습니다. 자세한 내용은 [가용 영역 전체의 Amazon ECS 서비스 밸런싱](service-rebalancing.md) 섹션을 참조하세요. + 서비스 배포에 **시작 유형**을 사용하면 기본적으로 서비스가 클러스터 VPC에서 서브넷에서 시작됩니다. + **용량 공급자 전략**의 경우, 콘솔이 기본적으로 컴퓨팅 옵션을 선택합니다. 다음은 콘솔에서 기본값을 선택하는 순서에 대한 설명입니다. + 클러스터에 기본 용량 공급자 전략이 정의된 경우 이 전략이 선택됩니다. + 클러스터에 기본 용량 공급자 전략이 정의되어 있지 않지만 Fargate 용량 공급자가 클러스터에 추가되어 있는 경우 `FARGATE` 용량 공급자를 사용하는 사용자 지정 용량 공급자 전략이 선택됩니다. + 클러스터에 기본 용량 공급자 전략이 정의되어 있지 않지만 하나 이상의 Auto Scaling 그룹 용량 공급자가 클러스터에 추가된 경우 **사용자 지정 사용(고급)** 옵션이 선택되고 전략을 수동으로 정의해야 합니다. + 클러스터에 기본 용량 공급자 전략이 정의되어 있지 않고 클러스터에 용량 공급자가 추가되지 않은 경우 Fargate 시작 유형이 선택됩니다. + 기본 배포 실패 감지 기본 옵션은 **Amazon ECS 배포 회로 차단기** 옵션과 **실패 시 롤백** 옵션을 함께 사용하는 것입니다. 자세한 내용은 [Amazon ECS 배포 회로 차단기가 장애를 감지하는 방법](deployment-circuit-breaker.md) 섹션을 참조하세요. + 서비스에서 원하는 태스크 수가 Amazon ECS에서 자동으로 증가하거나 감소하도록 할지를 결정합니다. 자세한 정보는 [Amazon ECS 서비스 자동 조정](service-auto-scaling.md) 섹션을 참조하세요. + 애플리케이션이 Amazon ECS에서 실행되는 다른 애플리케이션에 연결해야 하는 경우 아키텍처에 맞는 옵션을 결정합니다. 자세한 내용은 [Amazon ECS 서비스 상호 연결](interconnecting-services.md) 섹션을 참조하세요. + Amazon ECS 회로 차단기가 사용되는 서비스를 생성할 때 Amazon ECS에서는 서비스 배포 및 서비스 개정이 생성됩니다. 이러한 리소스를 통해 서비스 기록에 대한 자세한 내용을 볼 수 있습니다. 자세한 내용은 [Amazon ECS 서비스 배포를 사용하여 서비스 기록 보기](service-deployment.md) 섹션을 참조하세요. AWS CLI를 사용하여 서비스를 생성하는 방법에 대한 자세한 내용은 AWS Command Line Interface 참조의 [https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)를 참조하세요.** AWS CloudFormation을 사용하여 서비스를 생성하는 방법에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html)를 참조하세요. ## 기본 옵션으로 서비스 생성 콘솔을 사용하여 서비스를 빠르게 생성하고 배포할 수 있습니다. 서비스에는 다음 구성이 있습니다. + 클러스터와 연결된 VPC 및 서브넷에서 배포 + 하나의 태스크 배포 + 롤링 배포 사용 + 기본 용량 공급자로 기본 공급자 전략 사용 + 배포 회로 차단기를 사용하여 오류를 탐지하고 오류 발생 시 자동으로 롤백하는 옵션 설정 기본 파라미터를 사용하여 서비스를 배포하려면 다음의 단계를 따르세요. **서비스 생성 방법(Amazon ECS 콘솔)** 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. 탐색 페이지에서 **Clusters**(클러스터)를 선택합니다. 1. **클러스터** 페이지에서 서비스를 생성할 클러스터를 선택합니다. 1. **Services**(서비스) 탭에서 **Create**(생성)를 선택합니다. **서비스 생성** 페이지가 표시됩니다. 1. **서비스 세부 정보**에서 다음을 수행합니다. 1. **작업 정의**에 사용할 작업 정의 패밀리 및 개정을 입력합니다. 1. **서비스 이름(Service name)**에 서비스의 이름을 입력합니다. 1. ECS Exec을 사용하여 서비스를 디버깅하려면 **문제 해결 구성**에서 **ECS Exec 켜기**를 선택합니다. 1. **배포 구성**에서 다음을 수행합니다. 1. **원하는 작업(Desired tasks)**에 서비스에서 시작 및 유지 관리할 작업 수를 입력합니다. 1. (선택 사항) 서비스와 태스크를 식별하려면 **태그(Tags)** 섹션을 펼친 다음, 태그를 구성합니다. Amazon ECS가 새로 시작한 모든 작업에 클러스터 이름과 작업 정의 태그를 자동으로 지정하려면 **Amazon ECS 관리형 태그(Turn on Amazon ECS managed tags)** 사용을 선택한 다음 **작업 정의(Task definitions)**를 선택합니다. Amazon ECS가 새로 시작한 모든 작업에 클러스터 이름과 서비스 태그를 자동으로 지정하려면 **Amazon ECS 관리형 태그(Turn on Amazon ECS managed tags)** 사용을 선택한 다음 **서비스(Service)**를 선택합니다. 태그를 추가하거나 제거합니다. + [태그 추가] **새로운 태그(Add tag)**를 선택하고 다음을 수행합니다. + **키**에서 키 이름을 입력합니다. + **값**에 키 값을 입력합니다. + [태그 제거] 태그 옆에 있는 **태그 제거**를 선택합니다. ## 정의된 파라미터를 사용하여 서비스 생성 정의된 파라미터를 사용하여 서비스를 생성하려면 다음 단계를 수행합니다. **서비스 생성 방법(Amazon ECS 콘솔)** 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. 서비스를 시작할 리소스를 결정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/create-service-console-v2.html) **서비스 생성** 페이지가 표시됩니다. 1. 서비스 세부 정보에서 다음을 수행합니다. 1. **작업 정의**에 사용할 작업 정의를 입력합니다. 그런 다음 **개정**에서 사용할 개정을 선택합니다. 1. **서비스 이름(Service name)**에 서비스의 이름을 입력합니다. 1. **기존 클러스터**에 대해 클러스터를 선택합니다. **클러스터 생성**을 선택하여 새 클러스터에서 작업을 실행합니다. 1. 클러스터 인프라에 태스크를 배포하는 방식을 선택합니다. **컴퓨팅 구성**에서 옵션을 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. ECS Exec을 사용하여 서비스를 디버깅하려면 **문제 해결 구성**에서 **ECS Exec 켜기**를 선택합니다. 1. **배포 구성**에서 다음을 수행합니다. 1. **서비스 유형(Service type)**의 경우 서비스 예약 전략을 선택합니다. + 스케줄러가 모든 태스크 배치 제약을 준수하는 각 활성 컨테이너 인스턴스에서 정확히 하나의 태스크만 배포하게 하려면 **대몬(Daemon)**을 선택합니다. + 스케줄러가 클러스터에 원하는 수의 태스크를 배치하고 관리하도록 하려면 **복제본(Replica)**을 선택합니다. 1. **복제본(Replica)**을 선택하는 경우, **원하는 태스크(Desired tasks)**에 서비스에서 시작하고 유지할 태스크 개수를 입력합니다. 1. **복제본**을 선택한 경우 Amazon ECS에서 가용 영역 전체의 태스크 분산이 모니터링되고 불균형이 있으면 재분산되도록 하려면 **가용 영역 서비스 리밸런싱**에서 **가용 영역 서비스 리밸런싱**을 선택합니다. 1. **상태 확인 유예 기간**에 작업이 처음 시작된 후 서비스 스케줄러가 비정상 Elastic Load Balancing, VPC Lattice, 컨테이너 상태 확인을 무시하는 시간(초)을 입력합니다. 상태 확인 유예 기간 값을 지정하지 않으면 기본값인 0이 사용됩니다. 1. 서비스의 배포 유형을 결정합니다. **배포 옵션**을 확장한 후 다음 파라미터를 지정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. Amazon ECS에서 배포 오류를 탐지 및 처리하는 방법을 구성하려면 **배포 오류 탐지(Deployment failure detection)**를 펼친 다음, 옵션을 선택합니다. 1. 작업을 시작할 수 없을 때 배포를 중지하려면 **Use the Amazon ECS deployment circuit breaker**(Amazon ECS 배포 회로 차단기 사용)를 선택합니다. 배포 회로 차단기가 배포를 실패한 상태로 설정했을 때 소프트웨어가 마지막으로 완료한 배포로 자동 롤백하도록 하려면 **실패 시 롤백**을 선택합니다. 1. 애플리케이션 지표를 기반으로 배포를 중지하려면 **CloudWatch 경보 사용**을 선택합니다. 그런 다음, **CloudWatch 경보 이름**에서 경보를 선택합니다. 새 경보를 생성하려면 CloudWatch 콘솔을 이동합니다. CloudWatch 경보가 배포를 실패한 상태로 설정할 때 소프트웨어가 마지막으로 완료한 배포 상태로 자동 롤백하도록 하려면 **실패 시 롤백**을 선택합니다. 1. 태스크 정의에서 `awsvpc` 네트워크 모드를 사용하는 경우 사용자 지정 네트워크 구성 확장 **네트워킹**을 지정한 후에 다음을 수행할 수 있습니다. 1. **VPC**에서 사용할 VPC 선택합니다. 1. **서브넷(Subnets)**에서 태스크를 배치할 때 작업 스케줄러가 고려할 하나 이상의 서브넷을 VPC에서 선택합니다. 1. **보안 그룹(Security group)**의 경우 기존 보안 그룹을 선택하거나 새 보안 그룹을 생성할 수 있습니다. 기존 보안 그룹을 사용하려면 보안 그룹을 선택하고 다음 단계로 이동합니다. 새 보안 그룹을 만들려면 **새 보안 그룹 생성(Create a new security group)**을 선택합니다. 보안 그룹 이름 및 설명을 지정한 다음 보안 그룹에 대해 하나 이상의 인바운드 규칙을 추가해야 합니다. 1. **퍼블릭 IP(Public IP)**에서 작업의 탄력적 네트워크 인터페이스(ENI)에 퍼블릭 IP 주소를 자동 할당할지를 선택합니다. AWS Fargate 작업은 퍼블릭 서브넷에서 실행될 때 퍼블릭 IP 주소가 할당될 수 있으므로 인터넷에 연결되는 경로가 있습니다. 이 필드를 사용하여 EC2 작업에 퍼블릭 IP를 할당할 수 없습니다. 자세한 내용은 [Fargate에 대한 Amazon ECS 태스크 네트워킹 옵션](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) 및 [Amazon ECS 태스크에 대한 네트워크 인터페이스 할당](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html)을 참조하세요. 1. (선택 사항) Service Connect를 사용하여 서비스를 상호 연결하려면 **Service Connect**를 확장한 후 다음을 지정하세요. 1. **Service Connect 켜기**를 선택합니다. 1. **Service Connect configuration**(Service Connect 구성)에서 클라이언트 모드를 지정합니다. + 서비스에서 네임스페이스의 다른 서비스에만 연결하면 되는 네트워크 클라이언트 애플리케이션을 실행하는 경우 **클라이언트 측만**을 선택합니다. + 서비스가 네트워크 또는 웹 서비스 애플리케이션을 실행하고 이 서비스에 대한 엔드포인트를 제공해야 하며, 네임스페이스의 다른 서비스에 연결해야 하는 경우 **Client and server**(클라이언트 및 서버)를 선택합니다. 1. 기본 클러스터 네임스페이스가 아닌 네임스페이스를 사용하려면 **Namespace**(네임스페이스)에서 서비스 네임스페이스를 선택합니다. 이는 AWS 계정의 동일한 AWS 리전에서 별도로 생성된 네임스페이스 또는 AWS Resource Access Manager(AWS RAM)를 사용하여 계정과 공유되는 동일한 리전의 네임스페이스일 수 있습니다. 공유 AWS Cloud Map 네임스페이스에 대한 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)을 참조하세요. 1. (선택 사항) 로그 구성을 지정합니다. **로그 수집 사용**을 선택합니다. 기본 옵션은 CloudWatch Logs로 컨테이너 로그를 전송합니다. 다른 로그 드라이버 옵션은 AWS FireLens를 사용하여 구성됩니다. 자세한 정보는 [Amazon ECS 로그를 AWS 서비스 또는 AWS Partner로 전송](using_firelens.md)을 참조하세요. 다음은 각 컨테이너 로그 대상에 대한 자세한 설명입니다. + **Amazon CloudWatch** - CloudWatch Logs로 컨테이너 로그를 전송하도록 작업을 구성합니다. 사용자를 대신하여 CloudWatch 로그 그룹을 생성하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 로그 그룹 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon Data Firehose** - Firehose로 컨테이너 로그를 전송하도록 작업을 구성합니다. Firehose 전송 스트림으로 로그를 전송하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 전송 스트림 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon Kinesis Data Streams** - Kinesis Data Streams로 컨테이너 로그를 전송하도록 작업을 구성합니다. Kinesis Data Streams 스트림으로 로그를 전송하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 스트림 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon OpenSearch Service** - OpenSearch Service 도메인으로 컨테이너 로그를 전송하도록 작업을 구성합니다. 로그 드라이버 옵션이 제공되어야 합니다. + **Amazon S3** - Amazon S3 버킷으로 컨테이너 로그를 전송하도록 작업을 구성합니다. 기본 로그 드라이버 옵션이 제공되지만 유효한 Amazon S3 버킷 이름을 지정해야 합니다. 1. (선택 사항) 액세스 로그를 활성화하려면 다음 단계를 따릅니다. 1. **액세스 로그 구성**을 확장하세요. **형식**에서 **JSON** 또는 `TEXT`를 선택하세요. 1. 액세스 로그에 쿼리 파라미터를 포함하려면 **쿼리 파라미터 포함**을 선택하세요. 1. (선택 사항) 서비스 검색을 사용하여 서비스를 상호 연결하려면 **서비스 검색**을 확장한 후 다음을 수행하세요. 1. **서비스 검색 사용**을 선택합니다. 1. 새 네임스페이스를 사용하려면 **네임스페이스 구성**에서 **새 네임스페이스 생성**을 선택하고 네임스페이스 이름과 설명을 입력합니다. 기존 네임스페이스를 사용하려면 **기존 네임스페이스 선택**을 선택하고 사용할 네임스페이스를 선택합니다. 1. 서비스 이름 및 설명과 같은 서비스 검색 서비스 정보를 제공합니다. 1. Amazon ECS에서 정기적으로 컨테이너 수준 상태 확인을 수행하도록 하려면 **Amazon ECS 작업 상태 전파 활성화**를 선택합니다. 1. **DNS 레코드 유형(DNS record type)**에서 서비스에 대해 생성할 DNS 레코드 유형을 선택합니다. Amazon ECS 서비스 검색은 작업 정의에서 지정하는 네트워크 모드에 따라 **A** 및 **SRV** 레코드만 지원합니다. 이 레코드 유형의 값 형식에 대한 자세한 정보는 *Amazon Route 53 개발자 안내서*의 [지원되는 DNS 레코드 유형](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html)을 참조하세요. + 서비스 작업에서 지정한 작업 정의가 `bridge` 또는 `host` 네트워크 모드를 사용하는 경우에는 **SRV** 레코드 유형만 지원됩니다. 레코드와 연결된 컨테이너 이름 및 포트 조합을 선택합니다. + 서비스 작업에서 지정한 작업 정의가 `awsvpc` 네트워크 모드를 사용하는 경우에는 **A** 또는 **SRV** 레코드 유형을 선택합니다. **A**를 선택하면 다음 단계로 건너뜁니다. **SRV**를 선택한 경우에는 서비스를 찾을 수 있는 포트나 레코드와 연결할 컨테이너 이름 및 포트 조합을 지정합니다. **TTL**에 DNS 확인자 및 웹 브라우저에서 레코드 세트를 캐시하는 기간(초)을 입력합니다. 1. (선택 사항) VPC Lattice를 사용하여 서비스를 상호 연결하려면 **VPC Lattice**를 확장한 후 다음을 수행하세요. 1. **VPC Lattice 켜기**를 선택합니다. 1. **인프라 역할**에서 인프라 역할을 선택합니다. 역할을 생성하지 않은 경우 **인프라 역할 생성**을 선택합니다. 1. **대상 그룹**에서 대상 그룹 또는 그룹을 선택합니다. 대상 그룹을 하나 이상 선택해야 하며 최대 5개를 선택할 수 있습니다. 대상 그룹을 더 추가하려면 **대상 그룹 추가**를 선택합니다. 선택한 각 대상 그룹의 **포트 이름**, **프로토콜** 및 **포트**를 선택합니다. 대상 그룹을 삭제하려면 **제거**를 선택합니다. **참고** 기존 대상 그룹을 추가하려면 AWS CLI를 사용해야 합니다. AWS CLI를 사용하여 대상 그룹을 추가하는 방법에 대한 지침은 *AWS Command Line Interface 참조*의 [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html)를 참조하세요. VPC Lattice 서비스에는 여러 대상 그룹이 있을 수 있지만, 각 대상 그룹은 하나의 서비스에만 추가할 수 있습니다. 1. 리스너 기본 작업 또는 VPC Lattice 콘솔의 기존 VPC Lattice 서비스의 규칙에 새 대상 그룹을 포함시켜 VPC Lattice 구성을 완료합니다. 자세한 내용은 [VPC Lattice 서비스를 위한 리스너 규칙](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html)을 참조하세요. 1. (선택 사항) 서비스에 대한 로드 밸런서를 구성하려면 **로드 밸런싱(Load balancing)** 섹션을 확장합니다. 로드 밸런서를 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. (선택 사항) 서비스 오토 스케일링을 구성하려면 **서비스 오토 스케일링**을 확장한 후에 다음 파라미터를 지정합니다.트래픽 흐름에서 과거 로드 데이터를 살펴보는 예측 오토 스케일링을 사용하려면 서비스를 생성한 다음 예측 오토 스케일링을 구성합니다. 자세한 내용은 [과거 패턴을 사용하여 예측 규모 조정으로 Amazon ECS 서비스 규모 조정](predictive-auto-scaling.md) 섹션을 참조하세요. 1. 서비스 Auto Scaling을 사용하려면 **서비스 Auto Scaling(Service auto scaling)**을 선택합니다. 1. **작업의 최소 개수**에 서비스 Auto Scaling에서 사용할 작업 수의 하한을 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. **작업의 최대 개수**에 서비스 Auto Scaling에서 사용할 작업 수의 상한을 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. 정책 유형을 선택합니다. **규모 조정 정책 유형**에서 다음 옵션 중 하나를 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. (선택 사항) 기본 외에 다른 태스크 배치 전략을 사용하는 경우 **태스크 배치(Task Placement)**를 펼치고 다음의 옵션 중에서 선택하세요. 자세한 내용은 [Amazon ECS가 컨테이너 인스턴스에 작업을 배치하는 방법](task-placement.md) 섹션을 참조하세요. + **AZ Balanced Spread** - 작업을 가용 영역과 가용 영역의 컨테이너 인스턴스에 분산합니다. + **AZ Balanced BinPack** - 작업을 가용 영역과 가용 메모리가 최소인 컨테이너 인스턴스에 분산합니다. + **BinPack** - 사용 가능한 CPU 또는 메모리 최소량에 따라 태스크를 분산합니다. + **One Task Per Host** - 각 컨테이너 인스턴스에 서비스의 작업을 최대 1개 배치합니다. + **Custom** - 자체 작업 배치 전략을 정의합니다. **사용자 지정(Custom)**을 선택하는 경우, 태스크를 배치할 알고리즘과 태스크 배치 중에 고려할 규칙을 정의합니다. + **전략(Strategy)** 아래에 있는 **유형(Type)**과 **필드(Field)**의 경우, 알고리즘과 알고리즘에 사용할 엔터티를 선택합니다. 최대 5개의 전략을 입력할 수 있습니다. + **제약** 아래에 있는 **유형**과 **표현식**에서 해당 제약에 사용할 규칙과 속성을 선택합니다. 예를 들어 T2 인스턴스에 태스크를 배치하기 위한 제약을 설정할 경우, **식**에는 **attribute:ecs.instance-type =\$1 t2.\$1**를 입력합니다. 초대 10개의 제약을 입력할 수 있습니다. 1. 작업에서 배포 시 구성과 호환되는 데이터 볼륨을 사용하는 경우 **볼륨**을 확장하여 볼륨을 구성할 수 있습니다. 볼륨 이름과 볼륨 유형은 작업 정의 개정을 생성할 때 구성되며 서비스를 생성할 때는 변경할 수 없습니다. 볼륨 이름과 유형을 업데이트하려면 새 작업 정의 개정을 생성하고 새 개정을 사용해 서비스를 생성해야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/create-service-console-v2.html) 1. ECS Exec을 사용하여 서비스를 디버깅하려면 **문제 해결 구성**에서 **ECS Exec 켜기**를 선택합니다. 1. (선택 사항) 서비스와 태스크를 식별하려면 **태그(Tags)** 섹션을 펼친 다음, 태그를 구성합니다. Amazon ECS에서 새로 시작된 모든 작업에 클러스터 이름과 작업 정의 태그를 자동으로 지정하도록 하려면 **Amazon ECS 관리형 태그 켜기**를 선택한 다음 **작업 전파 시작**에서 **작업 정의**를 선택합니다. Amazon ECS에서 새로 시작된 모든 작업에 클러스터 이름과 서비스 태그를 자동으로 지정하도록 하려면 **Amazon ECS 관리형 태그 켜기**를 선택한 다음 **작업 전파 시작**에서 **서비스**를 선택합니다. 태그를 추가하거나 제거합니다. + [태그 추가] **새로운 태그(Add tag)**를 선택하고 다음을 수행합니다. + **키**에서 키 이름을 입력합니다. + **값**에 키 값을 입력합니다. + [태그 제거] 태그 옆에 있는 **태그 제거**를 선택합니다. 1. **생성(Create)**을 선택합니다. ## 다음 단계 다음은 서비스를 생성한 후의 추가 작업입니다. + 트래픽 흐름의 과거 로드 데이터를 살펴보는 예측 오토 스케일링을 구성합니다. 자세한 내용은 [과거 패턴을 사용하여 예측 규모 조정으로 Amazon ECS 서비스 규모 조정](predictive-auto-scaling.md) 섹션을 참조하세요. + 배포를 추적하고 Amazon ECS 회로 차단기에 사용되는 서비스에 대한 서비스 기록을 봅니다. 자세한 내용은 [Amazon ECS 서비스 배포를 사용하여 서비스 기록 보기](service-deployment.md) 섹션을 참조하세요. # Amazon ECS 블루/그린 배포 블루/그린 배포는 블루와 그린이라는 두 개의 동일한 프로덕션 환경을 실행하여 가동 중지 시간과 위험을 줄이는 릴리스 방법론입니다. Amazon ECS 블루/그린 배포를 사용하면 프로덕션 트래픽을 전달하기 전에 새 서비스 개정을 검증할 수 있습니다. 이 접근 방식은 필요한 경우 빠르게 롤백하는 기능을 통해 변경 내용을 배포하는 더 안전한 방법을 제공합니다. ## 이점 블루/그린 배포는 다음과 같은 이점을 제공합니다. + 프로덕션을 전환하기 전에 프로덕션 트래픽에서 테스트를 수행하여 위험을 줄입니다. 프로덕션 트래픽을 전달하기 전에 테스트 트래픽으로 새 배포를 검증할 수 있습니다. + 가동 중지 시간이 발생하지 않는 배포. 프로덕션 환경은 배포 프로세스 전반에 걸쳐 계속 사용할 수 있으며 이를 통해 지속적인 서비스 가용성을 보장합니다. + 문제가 감지되면 간편한 롤백. 그린 배포에 문제가 발생하면 서비스 중단을 연장하지 않고도 블루 배포로 빠르게 되돌릴 수 있습니다. + 제어된 테스트 환경. 그린 환경은 전체 배포 전에 실제 트래픽 패턴으로 새 기능을 테스트할 격리된 스페이스를 제공합니다. + 예측 가능한 배포 프로세스. 수명 주기 단계가 정의된 구조화된 접근 방식을 사용하면 배포의 일관성과 신뢰성이 향상됩니다. + 수명 주기 후크를 통한 자동화된 검증. 배포의 여러 단계에서 자동화된 테스트를 구현하여 기능을 확인할 수 있습니다. ## 용어 다음은 Amazon ECS 블루/그린 배포 용어입니다. + 베이크 소요 시간 - 프로덕션 트래픽이 이동한 후 블루 및 그린 서비스 개정이 모두 동시에 실행되는 기간. + 블루 배포 - 교체하려는 현재 프로덕션 서비스 개정. + 그린 배포 - 배포하려는 새 서비스 개정. + 수명 주기 단계 - '프로덕션 트래픽 전환 후'와 같은 배포 작업에 존재하는 일련의 이벤트. + 수명 주기 후크 - 특정 수명 주기 단계에서 배포를 확인하는 Lambda 함수. + 리스너 - 사용자가 구성한 프로토콜 및 포트를 사용하여 연결 요청을 확인하는 Elastic Load Balancing 리소스. 리스너에 대해 사용자가 정의한 규칙에 따라 Amazon ECS가 등록된 대상으로 요청을 라우팅하는 방법이 결정됩니다. + 규칙 - 리스너와 연결된 Elastic Load Balancing 리소스. 규칙은 요청이 라우팅되는 방식을 정의하며, 작업, 조건, 우선순위로 구성됩니다. + 대상 그룹 - 요청을 하나 이상의 등록된 대상(예: EC2 인스턴스)으로 라우팅하는 데 사용되는 Elastic Load Balancing 리소스. 리스너를 생성할 때 기본 작업에 대한 대상 그룹을 지정합니다. 트래픽은 리스너 규칙에 지정된 대상 그룹으로 전달됩니다. + 트래픽 전환 - Amazon ECS가 블루 배포에서 그린 배포로 트래픽을 전환하는 데 사용하는 프로세스. Amazon ECS 블루/그린 배포의 경우 모든 트래픽이 블루 서비스에서 그린 서비스로 한 번에 전환됩니다. ## 고려 사항 배포 유형을 선택할 때 다음을 고려하세요. + 리소스 사용량: 블루/그린 배포는 블루 및 그린 서비스 개정을 동시에 일시적으로 실행합니다. 이 경우 배포 중에 리소스 사용량이 두 배가 될 수 있습니다. + 배포 모니터링: 블루/그린 배포는 보다 자세한 배포 상태 정보를 제공하므로 이를 통해 배포 프로세스의 각 단계를 모니터링할 수 있습니다. + 롤백: 블루/그린 배포를 사용하면 베이크 소요 시간이 만료될 때까지 블루 개정이 계속 실행되므로 문제가 감지되면 이전 버전으로 쉽게 롤백할 수 있습니다. + Network Load Balancer 수명 주기 후크: 블루/그린 배포에 Network Load Balancer를 사용하는 경우, TEST\$1TRAFFIC\$1SHIFT 및 PRODUCTION\$1TRAFFIC\$1SHIFT 수명 주기 단계에 10분이 추가로 소요됩니다. Amazon ECS가 트래픽을 안전하게 이전할 수 있도록 보장하기 때문입니다. # Amazon ECS 블루/그린 서비스 배포 워크플로 Amazon ECS 블루/그린 배포 프로세스는 안전하고 신뢰할 수 있는 애플리케이션 업데이트를 보장하는 6단계로 구성된 구조화된 접근 방식을 따릅니다. 각 단계는 애플리케이션을 검증하고 현재 버전(파란색)에서 새 버전(녹색)으로 전환하는 구체적인 목적을 지원합니다. 1. **준비 단계**: 기존 블루 환경과 함께 그린 환경을 생성합니다. 여기에는 새 서비스 개정 프로비저닝 및 대상 그룹 준비가 포함됩니다. 1. **배포 단계**: 그린 환경에 새 서비스 개정을 배포합니다. 블루 환경이 프로덕션 트래픽을 계속 처리하는 동안 Amazon ECS는 업데이트된 서비스 개정을 사용하여 새 태스크를 시작합니다. 1. **테스트 단계**: 테스트 트래픽 라우팅을 사용하여 그린 환경을 검증합니다. Application Load Balancer는 프로덕션 트래픽이 블루 환경에서 유지되는 동안 테스트 요청을 그린 환경으로 보냅니다. 1. **트래픽 전환 단계**: 구성된 배포 전략에 따라 프로덕션 트래픽을 파란색에서 녹색으로 전환합니다. 이 단계에서는 모니터링 및 검증 체크포인트를 포함합니다. 1. **모니터링 단계**: 베이크 소요 시간 동안 애플리케이션 상태, 성능 지표 및 경보 상태를 모니터링합니다. 문제가 감지되면 롤백 작업이 시작됩니다. 1. **완료 단계**: 구성에 따라 블루 환경을 종료하거나 잠재적 롤백 시나리오에 맞게 유지 관리하여 배포를 완료합니다. ## 워크플로 다음 다이어그램은 Amazon ECS와 Application Load Balancer 간 상호 작용을 표시하는 포괄적인 블루/그린 배포 워크플로를 보여줍니다. ![\[자세한 구성 요소 상호 작용, 트래픽 전환 단계 및 모니터링 체크포인트를 포함하는 Amazon ECS의 블루/그린 배포 프로세스를 표시하는 포괄적인 다이어그램\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/blue-green.png) 향상된 배포 워크플로는 다음과 같은 세부 단계를 포함합니다. 1. **초기 상태**: 블루 서비스(현재 프로덕션)가 프로덕션 트래픽의 100%를 처리합니다. Application Load Balancer에는 정상 상태의 블루 태스크를 포함하는 블루 대상 그룹으로 모든 요청을 라우팅하는 규칙을 사용하는 단일 리스너가 있습니다. 1. **그린 환경 프로비저닝**: Amazon ECS는 업데이트된 태스크 정의를 사용하여 새 태스크를 생성합니다. 이러한 태스크는 새 그린 대상 그룹에 등록되지만 처음에는 트래픽을 수신하지 않습니다. 1. **상태 확인 검증**: Application Load Balancer는 그린 태스크에 대해 상태 확인을 수행합니다. 그린 태스크가 상태 확인을 통과한 경우에만 배포는 다음 단계로 진행됩니다. 1. **테스트 트래픽 라우팅**: 구성된 경우 Application Load Balancer의 리스너 규칙은 프로덕션 트래픽이 블루 환경에서 유지되는 동안 검증을 위해 특정 트래픽 패턴(예: 테스트 헤더가 있는 요청)을 그린 환경으로 라우팅합니다. 이는 요청 속성에 따라 서로 다른 규칙을 사용하여 프로덕션 트래픽을 처리하는 동일한 리스너에 의해 제어됩니다. 1. **프로덕션 트래픽 전환**: 배포 구성에 따라 트래픽이 블루에서 그린으로 전환됩니다. ECS 블루/그린 배포에서는 트래픽의 100%가 블루에서 그린 환경으로 이동합니다(즉시 한 번에 전환). Application Load Balancer는 가중치를 기반으로 블루 및 그린 대상 그룹 간 트래픽 분산을 제어하는 리스너 규칙을 사용하는 단일 리스너를 사용합니다. 1. **모니터링 및 검증**: Amazon ECS는 트래픽 전환 전반에 걸쳐 CloudWatch 지표, 경보 상태 및 배포 상태를 모니터링합니다. 문제가 감지되면 자동 롤백 트리거가 활성화됩니다. 1. **베이크 소요 시간(기간)**: 프로덕션 트래픽이 전환된 후 블루 및 그린 서비스 개정이 동시에 실행되는 기간. 1. **블루 환경 종료**: 트래픽 전환 및 검증에 성공하면 클러스터 리소스를 확보하기 위해 블루 환경이 종료되거나 빠른 롤백 기능을 위해 유지됩니다. 1. **최종 상태**: 그린 환경은 트래픽의 100%를 처리하며 새로운 프로덕션 환경이 됩니다. 배포가 성공으로 표시됩니다. ## 배포 수명 주기 단계 블루/그린 배포 프로세스는 각각 특정 책임과 검증 체크포인트가 있는 고유한 수명 주기 단계('프로덕션 트래픽 전환 이후'와 같은 배포 작업에서 일련의 이벤트)를 거칩니다. 이러한 단계를 이해하면 배포 진행 상황을 모니터링하고 문제를 효과적으로 해결할 수 있습니다. 각 수명 주기 단계는 최대 24시간 동안 지속될 수 있습니다. 값을 24시간 표시 미만으로 유지하는 것이 좋습니다. 비동기 프로세스가 후크를 트리거하는 데 시간이 필요하기 때문입니다. 시스템 제한 시간이 초과되어 배포에 실패하고 하나의 단계가 24시간에 도달한 후에 롤백을 시작합니다. CloudFormation 배포에는 추가 제한 시간이 있습니다. 24시간의 단계 제한은 여전히 유효하지만 CloudFormation은 전체 배포에 대해 36시간의 제한을 적용합니다. CloudFormation에서 배포에 실패하고 프로세스가 36시간 이내에 완료되지 않으면 롤백을 시작합니다. | 수명 주기 단계 | 설명 | 수명 주기 후크에서 이 단계 사용 여부 | | --- | --- | --- | | RECONCILE\$1SERVICE | 이 단계는 활성 상태인 서비스 개정이 2개 이상인 새 서비스 배포를 시작하는 경우에만 나타납니다. | 예 | | PRE\$1SCALE\$1UP | 그린 서비스 개정이 시작되지 않았습니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리하는 중입니다. 테스트 트래픽이 없습니다. | 예 | | SCALE\$1UP | 그린 서비스 개정이 100%까지 스케일 업되고 새 태스크를 시작하는 시간. 그린 서비스 개정이 현재 트래픽을 처리하지 않습니다. | 아니요 | | POST\$1SCALE\$1UP | 그린 서비스 개정이 시작되었습니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리하는 중입니다. 테스트 트래픽이 없습니다. | 예 | | TEST\$1TRAFFIC\$1SHIFT | 블루 및 그린 서비스 개정이 실행 중입니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리합니다. 그린 서비스 개정이 테스트 트래픽의 0%\$1100%를 마이그레이션하고 있습니다. | 예 | | POST\$1TEST\$1TRAFFIC\$1SHIFT | 테스트 트래픽 전환이 완료되었습니다. 그린 서비스 개정이 테스트 트래픽의 100%를 처리합니다. | 예 | | PRODUCTION\$1TRAFFIC\$1SHIFT | 프로덕션 트래픽이 그린 서비스 개정으로 전환되고 있습니다. 그린 서비스 개정이 프로덕션 트래픽의 0%\$1100%를 마이그레이션하고 있습니다. | 예 | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 프로덕션 트래픽 전환이 완료되었습니다. | 예 | | BAKE\$1TIME | 블루 및 그린 서비스 개정이 동시에 실행 중인 기간. | 아니요 | | CLEAN\$1UP | 블루 서비스 개정이 실행 중인 태스크가 0개인 상태로 완전히 스케일 다운되었습니다. 이제 그린 서비스 개정은 이 단계 이후에 프로덕션 서비스 개정이 됩니다. | 아니요 | 각 수명 주기 단계는 다음 단계로 진행하기 전에 통과해야 하는 기본 제공 검증 체크포인트를 포함합니다. 검증에 실패하면 배포를 자동으로 롤백하여 서비스 가용성과 신뢰성을 유지 관리할 수 있습니다. Lambda 함수를 사용하는 경우 함수는 작업을 완료하거나 15분 이내에 IN\$1PROGRESS를 반환해야 합니다. `callBackDelaySeconds`를 사용하여 Lambda에 대한 호출을 지연할 수 있습니다. 자세한 내용은 GitHub의 sample-amazon-ecs-blue-green-deployment-patterns에서 [app.py 함수](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25)를 참조하세요. # Amazon ECS 블루/그린 배포에 필요한 리소스 관리형 트래픽 전환을 통해 블루/그린 배포를 사용하려면 서비스에서 다음 기능 중 하나를 사용해야 합니다. + Elastic Load Balancing + Service Connect 서비스 검색, Service Connect, VPC Lattice 또는 Elastic Load Balancing을 사용하지 않는 서비스도 블루/그린 배포를 사용할 수 있지만 관리형 트래픽 전환의 이점은 얻을 수 없습니다. 다음 목록은 Amazon ECS 블루/그린 배포를 위해 구성해야 하는 사항에 대한 개략적인 개요를 제공합니다. + 서비스는 Application Load Balancer, Network Load Balancer 또는 Service Connect를 사용합니다. 적절한 리소스를 구성합니다. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. + Service Connect - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스](service-connect-blue-green.md) 섹션을 참조하세요. + 서비스 배포 컨트롤러를 `ECS`로 설정합니다. + 서비스 정의에서 `blue/green`으로 배포 전략을 구성합니다. + 선택적으로 다음과 같은 추가 파라미터를 구성합니다. + 새 배포를 위한 베이크 소요 시간 + 자동 롤백에 대한 CloudWatch 경보 + 테스트에 대한 배포 수명 주기 후크(지정된 배포 단계에서 실행되는 Lambda 함수임) ## 모범 사례 성공적인 Amazon ECS 블루/그린 배포를 위해 다음 모범 사례를 따릅니다. + 애플리케이션 상태를 정확하게 반영하는 적절한 상태 확인을 구성합니다. + 그린 배포를 충분히 테스트할 수 있는 베이크 소요 시간을 설정합니다. + CloudWatch 경보를 구현하여 문제를 자동으로 감지하고 롤백을 트리거합니다. + 수명 주기 후크를 사용하여 각 배포 단계에서 자동화된 테스트를 수행합니다. + 애플리케이션이 동시에 실행되는 블루 및 그린 서비스 개정을 모두 처리할 수 있는지 확인합니다. + 배포 중에 두 서비스 개정을 모두 처리할 수 있는 충분한 클러스터 용량을 계획합니다. + 프로덕션 환경에서 롤백 프로시저를 구현하기 전에 테스트합니다. # 블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스 Amazon ECS 블루/그린 배포에서 Application Load Balancer를 사용하려면 블루 및 그린 서비스 개정 간 트래픽 라우팅을 허용하는 특정 리소스를 구성해야 합니다. ## 대상 그룹 Elastic Load Balancing을 사용하는 블루/그린 배포의 경우 두 개의 대상 그룹을 생성해야 합니다. + 블루 서비스 개정의 기본 대상 그룹(현재 프로덕션 트래픽) + 그린 서비스 개정(새 버전)의 대체 대상 그룹 두 대상 그룹 모두 다음 설정으로 구성해야 합니다. + 대상 유형: `IP`(`awsvpc` 네트워크 모드를 사용하는 Fargate 또는 EC2의 경우) + 프로토콜: `HTTP`(또는 애플리케이션이 사용하는 프로토콜) + 포트: 애플리케이션이 수신 대기하는 포트(일반적으로 HTTP의 경우 `80`) + VPC: Amazon ECS 태스크와 동일한 VPC + 상태 확인 설정: 애플리케이션 상태를 올바르게 확인하도록 구성됨 블루/그린 배포 중에 Amazon ECS는 배포 단계에 따라 적절한 대상 그룹에 태스크를 자동으로 등록합니다. **Example Application Load Balancer 대상 그룹 생성** 다음 CLI 명령은 블루/그린 배포에서 Application Load Balancer와 함께 사용할 두 개의 대상 그룹을 생성합니다. ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 aws elbv2 create-target-group \ --name green-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 ``` ## Application Load Balancer 다음 구성을 사용하여 Application Load Balancer를 생성해야 합니다. + 스키마: 요구 사항에 따라 인터넷 연결 또는 내부 + IP 주소 유형: IPv4 + VPC: Amazon ECS 태스크와 동일한 VPC + 서브넷: 서로 다른 가용 영역에서 두 개 이상의 서브넷 + 보안 그룹: 리스너 포트에서 트래픽을 허용하는 보안 그룹 Application Load Balancer에 연결된 보안 그룹에는 Amazon ECS 태스크에 연결된 보안 그룹으로 트래픽을 허용하는 아웃바운드 규칙이 있어야 합니다. **Example Application Load Balancer 생성** 다음 CLI 명령은 블루/그린 배포에 사용할 Application Load Balancer를 생성합니다. ``` aws elbv2 create-load-balancer \ --name my-application-load-balancer \ --type application \ --security-groups sg-abcd1234 \ --subnets subnet-12345678 subnet-87654321 ``` ## 리스너 및 규칙 블루/그린 배포의 경우 Application Load Balancer에서 다음과 같이 리스너를 구성해야 합니다. + 프로덕션 리스너: 프로덕션 트래픽 처리(일반적으로 포트 80 또는 443) + 처음에 기본 대상 그룹으로 트래픽 전달(블루 서비스 개정) + 배포 후 대체 대상 그룹으로 트래픽 전달(그린 서비스 개정) + 테스트 리스너(선택 사항): 프로덕션 트래픽을 전환하기 전에 테스트 트래픽을 처리하여 그린 서비스 개정 검증 + 다른 포트(예: 8080 또는 8443)에서 구성 가능 + 테스트 중에 대체 대상 그룹(그린 서비스 개정)으로 트래픽 전달 블루/그린 배포 중에 Amazon ECS는 배포 단계에 따라 적절한 대상 그룹으로 트래픽을 라우팅하도록 리스너 규칙을 자동으로 업데이트합니다. **Example 프로덕션 리스너 생성** 다음 CLI 명령은 기본(블루) 대상 그룹으로 트래픽을 전달하는 프로덕션 리스너를 포트 80에서 생성합니다. ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 80 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456 ``` **Example 테스트 리스너 생성** 다음 CLI 명령은 대체(그린) 대상 그룹으로 트래픽을 전달하는 테스트 리스너를 포트 8080에서 생성합니다. ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 8080 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example 경로 기반 라우팅에 대한 리스너 규칙 생성** 다음 CLI 명령은 테스트를 위해 특정 경로에 대한 트래픽을 그린 대상 그룹으로 전달하는 규칙을 생성합니다. ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 10 \ --conditions Field=path-pattern,Values='/test/*' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example 헤더 기반 라우팅에 대한 리스너 규칙 생성** 다음 CLI 명령은 테스트를 위해 특정 헤더를 포함한 트래픽을 그린 대상 그룹으로 전달하는 규칙을 생성합니다. ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 20 \ --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` ## 서비스 구성 Amazon ECS에서 사용자를 대신해 클러스터의 로드 밸런서 리소스를 관리하도록 허용할 권한이 있어야 합니다. 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. Elastic Load Balancing을 사용하여 블루/그린 배포에 대한 Amazon ECS 서비스를 생성하거나 업데이트하는 경우 다음 구성을 지정해야 합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. 이 구성의 주요 구성 요소는 다음과 같습니다. + `targetGroupArn`: 기본 대상 그룹 ARN(블루 서비스 개정). + `alternateTargetGroupArn`: 대체 대상 그룹 ARN(그린 서비스 개정). + `productionListenerRule`: 프로덕션 트래픽에 대한 리스너 규칙 ARN. + `roleArn`: Amazon ECS에서 Elastic Load Balancing 리소스를 관리하도록 허용하는 역할의 ARN. + `strategy`: 블루/그린 배포를 활성화하려면 `BLUE_GREEN`으로 설정합니다. + `bakeTimeInMinutes`: 프로덕션 트래픽이 이동한 후 블루 및 그린 서비스 개정이 모두 동시에 실행되는 기간. + `TestListenerRule`: 테스트 트래픽에 대한 리스너 규칙 ARN. 이는 선택 가능한 파라미터입니다. ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012", "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678", "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## 배포 중 트래픽 흐름 Elastic Load Balancing을 사용하는 블루/그린 배포 중에 트래픽은 다음과 같이 시스템을 통해 흐릅니다. 1. *초기 상태*: 모든 프로덕션 트래픽이 기본 대상 그룹(블루 서비스 개정)으로 라우팅됩니다. 1. *그린 서비스 개정 배포*: Amazon ECS는 새 태스크를 배포하고 대체 대상 그룹에 등록합니다. 1. *트래픽 테스트*: 테스트 리스너가 구성된 경우 테스트 트래픽이 대체 대상 그룹으로 라우팅되어 그린 서비스 개정을 검증합니다. 1. *프로덕션 트래픽 전환*: Amazon ECS는 트래픽을 대체 대상 그룹(그린 서비스 개정)으로 라우팅하도록 프로덕션 리스너 규칙을 업데이트합니다. 1. *베이크 소요 시간*: 프로덕션 트래픽이 이동한 후 블루 및 그린 서비스 개정이 모두 동시에 실행되는 기간. 1. *완료*: 배포에 성공하면 블루 서비스 개정이 종료됩니다. 배포 중에 문제가 감지되면 Amazon ECS는 트래픽을 기본 대상 그룹(블루 서비스 개정)으로 다시 라우팅하여 자동으로 롤백할 수 있습니다. # Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer Amazon ECS 블루/그린 배포에서 Network Load Balancer를 사용하려면 블루 및 그린 서비스 개정 간 트래픽 라우팅을 허용하는 특정 리소스를 구성해야 합니다. 이 섹션에서는 필수 구성 요소 및 해당 구성에 대해 설명합니다. 구성에 Network Load Balancer가 포함된 경우 Amazon ECS는 다음 수명 주기 단계에 10분 지연을 추가합니다. + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT 이 지연은 구성된 트래픽 가중치와 데이터 플레인의 실제 트래픽 라우팅 간 불일치를 일으킬 수 있는 Network Load Balancer 타이밍 문제를 고려합니다. ## 대상 그룹 Network Load Balancer를 사용하는 블루/그린 배포의 경우 두 개의 대상 그룹을 생성해야 합니다. + 블루 서비스 개정의 기본 대상 그룹(현재 프로덕션 트래픽) + 그린 서비스 개정(새 서비스 개정)의 대체 대상 그룹 두 대상 그룹 모두 다음 설정으로 구성해야 합니다. + 대상 유형: `ip`(`awsvpc` 네트워크 모드를 사용하는 Fargate 또는 EC2의 경우) + 프로토콜: `TCP`(또는 애플리케이션이 사용하는 프로토콜) + 포트: 애플리케이션이 수신 대기하는 포트(일반적으로 HTTP의 경우 `80`) + VPC: Amazon ECS 태스크와 동일한 VPC + 상태 확인 설정: 애플리케이션 상태를 올바르게 확인하도록 구성됨 TCP 상태 확인을 위해 Network Load Balancer는 대상과 TCP 연결을 설정합니다. 연결에 성공하면 대상이 정상 상태로 간주됩니다. HTTP/HTTPS 상태 확인의 경우 Network Load Balancer는 대상에 HTTP/HTTPS 요청을 보내고 응답을 확인합니다. 블루/그린 배포 중에 Amazon ECS는 배포 단계에 따라 적절한 대상 그룹에 태스크를 자동으로 등록합니다. **Example Network Load Balancer에 대한 대상 그룹 생성** 다음 AWS CLI 명령은 블루/그린 배포에서 Network Load Balancer와 함께 사용할 두 개의 대상 그룹을 생성합니다. ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP aws elbv2 create-target-group \ --name green-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP ``` ## Network Load Balancer 다음 구성을 사용하여 Network Load Balancer를 생성해야 합니다. + 스키마: 요구 사항에 따라 인터넷 연결 또는 내부 + IP 주소 유형: IPv4 + VPC: Amazon ECS 태스크와 동일한 VPC + 서브넷: 서로 다른 가용 영역에서 두 개 이상의 서브넷 Application Load Balancer와 달리 Network Load Balancer는 전송 계층(계층 4)에서 작동하며 보안 그룹을 사용하지 않습니다. 대신 Amazon ECS 태스크와 연결된 보안 그룹이 리스너 포트에서 Network Load Balancer로부터 수신되는 트래픽을 허용하는지 확인해야 합니다. **Example Network Load Balancer 생성** 다음 AWS CLI 명령은 블루/그린 배포에 사용할 Network Load Balancer를 생성합니다. ``` aws elbv2 create-load-balancer \ --name my-network-load-balancer \ --type network \ --subnets subnet-12345678 subnet-87654321 ``` ## 블루/그린 배포 사용에 관한 고려 사항 블루/그린 배포에 대해 Network Load Balancer를 사용하는 경우 다음 사항을 고려하세요. + **계층 4 작업**: Network Load Balancer는 전송 계층(계층 4)에서 작동하며 애플리케이션 계층(계층 7) 콘텐츠를 검사하지 않습니다. 즉, 라우팅 결정에 대해 HTTP 헤더 또는 경로를 사용할 수 없습니다. + **상태 확인**: Network Load Balancer 상태 확인은 TCP, HTTP 또는 HTTPS 프로토콜로 제한됩니다. TCP 상태 확인의 경우 Network Load Balancer는 연결을 설정할 수 있는지만 확인합니다. + **연결 보존**: Network Load Balancer는 보안 및 로깅 목적으로 유용할 수 있는 클라이언트의 소스 IP 주소를 보존합니다. + **고정 IP 주소**: Network Load Balancer는 각 서브넷에 대한 고정 IP 주소를 제공합니다. 이는 화이트리스트에 추가할 때 또는 클라이언트가 고정 IP 주소에 연결해야 하는 경우에 유용할 수 있습니다. + **테스트 트래픽**: Network Load Balancer는 콘텐츠 기반 라우팅을 지원하지 않으므로 테스트 트래픽을 프로덕션 트래픽과 다른 포트로 전송해야 합니다. ## 리스너 및 규칙 Network Load Balancer를 사용하는 블루/그린 배포의 경우 다음과 같이 리스너를 구성해야 합니다. + 프로덕션 리스너: 프로덕션 트래픽 처리(일반적으로 포트 80 또는 443) + 처음에 기본 대상 그룹으로 트래픽 전달(블루 서비스 개정) + 배포 후 대체 대상 그룹으로 트래픽 전달(그린 서비스 개정) + 테스트 리스너(선택 사항): 프로덕션 트래픽을 전환하기 전에 테스트 트래픽을 처리하여 그린 서비스 개정 검증 + 다른 포트(예: 8080 또는 8443)에서 구성 가능 + 테스트 중에 대체 대상 그룹(그린 서비스 개정)으로 트래픽 전달 Application Load Balancer와 달리 Network Load Balancer는 콘텐츠 기반 라우팅 규칙을 지원하지 않습니다. 대신 트래픽은 리스너 포트 및 프로토콜에 기반하여 라우팅됩니다. 다음 AWS CLI 명령은 Network Load Balancer에 대한 프로덕션 및 테스트 리스너를 생성합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 80 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456 aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 8080 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456 ``` ## 서비스 구성 Amazon ECS에서 사용자를 대신해 클러스터의 로드 밸런서 리소스를 관리하도록 허용할 권한이 있어야 합니다. 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. Network Load Balancer를 사용하여 블루/그린 배포에 대한 Amazon ECS 서비스를 생성하거나 업데이트하는 경우 다음 구성을 지정해야 합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. 이 구성의 주요 구성 요소는 다음과 같습니다. + `targetGroupArn`: 기본 대상 그룹 ARN(블루 서비스 개정) + `alternateTargetGroupArn`: 대체 대상 그룹 ARN(그린 서비스 개정) + `productionListenerRule`: 프로덕션 트래픽에 대한 리스너 ARN + `testListenerRule`: (선택 사항) 테스트 트래픽에 대한 리스너 ARN + `roleArn`: Amazon ECS에서 Network Load Balancer 리소스를 관리하도록 허용하는 역할의 ARN. + `strategy`: 블루/그린 배포를 활성화하려면 `BLUE_GREEN`으로 설정 + `bakeTimeInMinutes`: 프로덕션 트래픽이 이동한 후 블루 및 그린 서비스 개정이 모두 동시에 실행되는 기간 ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456", "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456", "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567", "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## 배포 중 트래픽 흐름 Network Load Balancer를 사용하는 블루/그린 배포 중에 트래픽은 다음과 같이 시스템을 통해 흐릅니다. 1. *초기 상태*: 모든 프로덕션 트래픽이 기본 대상 그룹(블루 서비스 개정)으로 라우팅됩니다. 1. *그린 서비스 개정 배포*: Amazon ECS는 새 태스크를 배포하고 대체 대상 그룹에 등록합니다. 1. *트래픽 테스트*: 테스트 리스너가 구성된 경우 테스트 트래픽이 대체 대상 그룹으로 라우팅되어 그린 서비스 개정을 검증합니다. 1. *프로덕션 트래픽 전환*: Amazon ECS는 트래픽을 대체 대상 그룹(그린 서비스 개정)으로 라우팅하도록 프로덕션 리스너를 업데이트합니다. 1. *베이크 소요 시간*: 프로덕션 트래픽이 이동한 후 블루 및 그린 서비스 개정이 모두 동시에 실행되는 기간. 1. *완료*: 배포에 성공하면 블루 서비스 개정이 종료됩니다. 배포 중에 문제가 감지되면 Amazon ECS는 트래픽을 기본 대상 그룹(블루 서비스 개정)으로 다시 라우팅하여 자동으로 롤백할 수 있습니다. # Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스 블루/그린 배포와 함께 Service Connect를 사용하는 경우 블루 및 그린 서비스 개정 사이에서 트래픽을 적절히 라우팅할 수 있도록 특정 구성 요소를 구성해야 합니다. 이 섹션에서는 필수 구성 요소 및 해당 구성에 대해 설명합니다. ## 아키텍처 개요 Service Connect는 Amazon ECS 태스크에 자동으로 삽입되는 관리형 사이드카 프록시를 통해 서비스 검색 및 서비스 메시 기능을 모두 빌드합니다. 이러한 프록시는 라우팅 결정, 재시도 및 지표 수집을 처리하는 반면 AWS Cloud Map에서는 서비스 레지스트리 백엔드를 제공합니다. Service Connect가 활성화된 상태로 서비스를 배포하면 서비스가 자체적으로 AWS Cloud Map에 등록되고 클라이언트 서비스가 네임스페이스를 통해 이를 검색합니다. 표준 Service Connect 구현에서 클라이언트 서비스는 논리적 서비스 이름에 연결되고 사이드카 프록시는 실제 서비스 인스턴스로의 라우팅을 처리합니다. 블루/그린 배포의 경우 이 모델은 `testTrafficRules` 구성을 통한 테스트 트래픽 라우팅을 포함하도록 확장됩니다. 블루/그린 배포 중에 다음 주요 구성 요소가 함께 작동합니다. + **Service Connect 프록시**: 서비스 간 모든 트래픽은 구성을 기반으로 라우팅 결정을 내리는 Service Connect 프록시를 통과합니다. + **AWS Cloud Map 등록**: 블루 및 그린 배포 모두가 AWS Cloud Map에 등록되지만 그린 배포는 처음에 "테스트" 엔드포인트로 등록됩니다. + **테스트 트래픽 라우팅**: Service Connect 구성의 `testTrafficRules`는 테스트 트래픽을 식별하고 그린 배포로 라우팅하는 방법을 결정합니다. 이는 요청의 특정 HTTP 헤더가 트래픽을 테스트 개정으로 보내는 헤더 **기반 라우팅**을 통해 수행됩니다. 기본적으로 Service Connect는 사용자 지정 규칙이 지정되지 않은 경우 HTTP 기반 프로토콜의 `x-amzn-ecs-blue-green-test` 헤더를 인식합니다. + **클라이언트 구성**: 네임스페이스의 모든 클라이언트는 프로덕션 및 테스트 경로를 모두 자동으로 수신하지만 테스트 규칙과 일치하는 요청만 그린 배포로 이동합니다. 이 접근 방식이 강력한 이유는 전환 중 서비스 검색의 복잡성을 처리한다는 점 때문입니다. 트래픽이 블루에서 그린 배포로 전환되면 모든 연결 및 검색 메커니즘이 자동으로 업데이트됩니다. DNS 레코드를 업데이트하거나 로드 밸런서를 재구성하거나, 서비스 검색 변경 내용을 별도로 배포할 필요가 없습니다. 서비스 메시가 이 작업을 모두 처리하기 때문입니다. ## 트래픽 라우팅 및 테스트 Service Connect는 테스트 시나리오에 대한 헤더 기반 라우팅 및 클라이언트 별칭 구성을 포함하여 블루/그린 배포에 대한 고급 트래픽 라우팅 기능을 제공합니다. ### 테스트 트래픽 헤더 규칙 블루/그린 배포 중에 테스트 목적을 위해 특정 요청을 그린(신규) 서비스 개정으로 라우팅하도록 테스트 트래픽 헤더 규칙을 구성할 수 있습니다. 이렇게 하면 배포를 완료하기 전에 트래픽을 제어하며 새 버전을 검증할 수 있습니다. Service Connect는 **헤더 기반 라우팅**을 사용하여 테스트 트래픽을 식별합니다. 기본적으로 Service Connect는 사용자 지정 규칙이 지정되지 않은 경우 HTTP 기반 프로토콜의 `x-amzn-ecs-blue-green-test` 헤더를 인식합니다. 요청에 이 헤더가 있으면 Service Connect 프록시는 테스트를 위해 요청을 그린 배포로 자동으로 라우팅합니다. 테스트 트래픽 헤더 규칙을 사용하면 다음을 수행할 수 있습니다. + 특정 헤더가 있는 요청을 그린 서비스 개정으로 라우팅 + 트래픽 하위 집합을 사용하여 새 기능 테스트 + 전체 트래픽 전환 전에 서비스 동작 검증 + 카나리 테스트 전략 구현 + 프로덕션과 유사한 환경에서 통합 테스트 수행 헤더 기반 라우팅 메커니즘은 기존 애플리케이션 아키텍처에서 원활하게 작동합니다. 클라이언트 서비스는 블루/그린 배포 프로세스를 인식하지 않아도 됩니다. 테스트 요청을 보낼 때 적절한 헤더를 포함하면 Service Connect 프록시가 라우팅 로직을 자동으로 처리합니다. 테스트 트래픽 헤더 규칙을 구성하는 방법에 대한 자세한 내용은 *Amazon Elastic Container Service API 참조*의 [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html)를 참조하세요. ### 헤더 일치 규칙 헤더 일치 규칙은 블루/그린 배포 중에 테스트 트래픽을 라우팅하기 위한 기준을 정의합니다. 그린 서비스 개정으로 라우팅되는 요청을 정확하게 제어하기 위해 여러 일치 조건을 구성할 수 있습니다. 헤더 일치에서는 다음을 지원합니다. + 정확한 헤더 값 일치 + 헤더 존재 확인 + 패턴 기반 일치 + 여러 헤더 조합 사용 사례 예제에는 테스트를 위해 특정 사용자 에이전트 문자열, API 버전 또는 기능 플래그가 있는 요청을 그린 서비스로 라우팅하는 작업이 포함됩니다. 헤더 일치 구성에 대한 자세한 내용은 *Amazon Elastic Container Service API 참조*의 [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html)를 참조하세요. ### 블루/그린 배포에 대한 클라이언트 별칭 클라이언트 별칭은 블루/그린 배포 중 서비스에 안정적인 DNS 엔드포인트를 제공합니다. 이를 통해 클라이언트 애플리케이션이 연결 엔드포인트를 변경하지 않고도 블루 및 그린 서비스 개정 간에 원활한 트래픽 라우팅을 지원합니다. 블루/그린 배포 중에 클라이언트 별칭은 다음과 같은 기능을 수행합니다. + 클라이언트 연결을 위해 일관된 DNS 이름 유지 관리 + 서비스 개정 간 자동 트래픽 전환 활성화 + 점진적 트래픽 마이그레이션 전략 지원 + 트래픽을 블루 개정으로 리디렉션하여 롤백 기능 제공 여러 포트 또는 프로토콜에 대해 여러 클라이언트 별칭을 구성하여 배포 중에 복잡한 서비스 아키텍처에서 연결을 유지할 수 있습니다. 클라이언트 별칭 구성에 대한 자세한 내용은 *Amazon Elastic Container Service API 참조*의 [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html)를 참조하세요. ### 트래픽 라우팅 모범 사례 Service Connect를 사용하는 블루/그린 배포에 대한 트래픽 라우팅을 구현하는 경우 다음 모범 사례를 고려하세요. + **헤더 기반 테스트로 시작**: 테스트 트래픽 헤더 규칙을 사용하여 모든 트래픽을 전환하기 전에 트래픽을 제어하며 그린 서비스를 검증합니다. + **상태 확인 구성**: 블루 및 그린 서비스 모두에서 비정상 인스턴스로 트래픽을 라우팅하지 않도록 적절한 상태 확인이 구성되어 있는지 확인합니다. + **서비스 지표 모니터링**: 배포 중에 두 서비스 개정에 대한 주요 성능 지표를 추적하여 문제를 조기에 식별합니다. + **롤백 전략 계획**: 문제가 감지되면 블루 서비스로 빠르게 롤백할 수 있도록 클라이언트 별칭 및 라우팅 규칙을 구성합니다. + **헤더 일치 로직 테스트**: 프로덕션 배포에 적용하기 전에 비프로덕션 환경에서 헤더 일치 규칙을 검증합니다. ## Service Connect 블루/그린 배포 워크플로 Service Connect가 블루/그린 배포 프로세스를 관리하는 방법을 이해하면 배포를 효과적으로 구현하고 문제를 해결하는 데 도움이 됩니다. 다음 워크플로는 배포의 각 단계에서 서로 다른 구성 요소가 상호 작용하는 방식을 보여줍니다. ### 배포 단계 Service Connect 블루/그린 배포는 다음과 같은 여러 개별 단계를 통해 진행됩니다. 1. **초기 상태**: 블루 서비스가 프로덕션 트래픽의 100%를 처리합니다. 네임스페이스의 모든 클라이언트 서비스는 Service Connect에 구성된 논리적 서비스 이름을 통해 블루 서비스에 연결됩니다. 1. **그린 서비스 등록**: 그린 배포가 시작되면 AWS Cloud Map에 '테스트' 엔드포인트로 등록됩니다. 클라이언트 서비스의 Service Connect 프록시는 프로덕션 및 테스트 라우팅 구성을 모두 자동으로 수신합니다. 1. **테스트 트래픽 라우팅**: 테스트 트래픽 헤더(예: `x-amzn-ecs-blue-green-test`)가 포함된 요청이 Service Connect 프록시에 의해 자동으로 그린 서비스로 라우팅됩니다. 프로덕션 트래픽은 계속해서 블루 서비스로 흐릅니다. 1. **트래픽 전환 준비**: 테스트에 성공하면 배포 프로세스가 프로덕션 트래픽 전환을 준비합니다. 블루 및 그린 서비스는 모두 등록되고 정상 상태로 유지됩니다. 1. **프로덕션 트래픽 전환**: 프로덕션 트래픽을 그린 서비스로 라우팅하도록 Service Connect 구성이 업데이트됩니다. 이는 클라이언트 서비스 업데이트 또는 DNS 변경 없이 자동으로 수행됩니다. 1. **베이크 소요 시간(기간)**: 프로덕션 트래픽이 전환된 후 블루 및 그린 서비스 개정이 동시에 실행되는 기간. 1. **블루 서비스 등록 취소**: 트래픽 이동 및 검증에 성공하면 블루 서비스가 AWS Cloud Map에서 등록 취소되고 종료되며 배포가 완료됩니다. ### Service Connect 프록시 동작 Service Connect 프록시는 블루/그린 배포 중에 트래픽을 관리하는 데 중요한 역할을 합니다. 이 동작을 이해하면 효과적인 테스트 및 배포 전략을 설계하는 데 도움이 됩니다. 블루/그린 배포 중 주요 프록시 동작: + **자동 경로 검색**: 프록시는 애플리케이션을 다시 시작하거나 구성을 변경할 필요 없이 AWS Cloud Map에서 프로덕션 및 테스트 경로를 모두 자동으로 검색합니다. + **헤더 기반 라우팅**: 프록시는 수신 요청 헤더를 검사하고 구성된 테스트 트래픽 규칙에 따라 트래픽을 적절한 서비스 개정으로 라우팅합니다. + **상태 확인 통합**: 프록시는 정상 서비스 인스턴스로만 트래픽을 라우팅하며, 라우팅 풀에서 비정상 태스크를 자동으로 제외합니다. + **재시도 및 회로 차단**: 프록시는 기본 제공 재시도 로직 및 회로 차단 기능을 제공하며 이를 통해 배포 중 복원력을 개선합니다. + **지표 수집**: 프록시는 블루 및 그린 서비스 모두에 대한 자세한 지표를 수집하여 배포 중에 포괄적인 모니터링을 지원합니다. ### 서비스 검색 업데이트 블루/그린 배포에 Service Connect를 사용하는 경우 주요 이점 중 하나는 서비스 검색 업데이트의 자동 처리입니다. 기존 블루/그린 배포에는 복잡한 DNS 업데이트 또는 로드 밸런서 재구성이 필요한 경우가 많지만 Service Connect는 이러한 변경 내용을 투명하게 관리합니다. 배포 중에 Service Connect는 다음을 처리합니다. + **네임스페이스 업데이트**: Service Connect 네임스페이스는 적절한 라우팅 규칙과 함께 블루 및 그린 서비스 엔드포인트를 모두 자동으로 포함합니다. + **클라이언트 구성**: 네임스페이스의 모든 클라이언트 서비스는 다시 시작하거나 재배포할 필요 없이 업데이트된 라우팅 정보를 자동으로 수신합니다. + **점진적 전환**: 서비스 검색 업데이트가 점진적으로 안전하게 수행되므로 진행 중인 요청이 중단되지 않습니다. + **롤백 지원**: 롤백이 필요한 경우 Service Connect는 서비스 검색 구성을 빠르게 되돌려 트래픽을 블루 서비스로 다시 라우팅할 수 있습니다. # Amazon ECS 블루/그린 배포 생성 Amazon RDS 블루/그린 배포를 사용하면 프로덕션 환경에서 구현하기 전에 서비스를 변경하고 해당 변경 내용을 테스트할 수 있습니다. ## 사전 조건 블루/그린 배포를 시작하기 전에 다음 작업을 수행합니다. 1. 적절한 권한을 구성하세요. + Elastic Load Balancing 권한에 대한 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. + Lambda 권한에 대한 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. 1. Amazon ECS 블루/그린 배포에서는 서비스가 다음 기능 중 하나를 사용해야 합니다. 적절한 리소스를 구성하세요. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. + Service Connect - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스](service-connect-blue-green.md) 섹션을 참조하세요. 1. 수명 주기 단계에 대해 Lambda 함수를 실행할지를 결정하세요. + PRE\$1SCALE\$1UP + POST\$1SCALE\$1UP + TEST\$1TRAFFIC\$1SHIFT + POST\$1TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT 자세한 내용은 *AWS Lambda 개발자 안내서*의 [콘솔로 Lambda 함수 생성](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function)을 참조하세요. ## 절차 콘솔 또는 AWS CLI를 사용하여 Amazon ECS 블루/그린 서비스를 생성할 수 있습니다. ------ #### [ Console ] 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. 서비스를 시작할 리소스를 결정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-blue-green-service.html) **서비스 생성** 페이지가 표시됩니다. 1. **서비스 세부 정보**에서 다음을 수행합니다. 1. **태스크 정의**에서 사용할 태스크 정의 패밀리 및 개정을 선택하세요. 그런 다음 **태스크 정의 개정**에 사용할 개정을 입력하세요. 1. **서비스 이름(Service name)**에 서비스의 이름을 입력합니다. 1. 기존 클러스터에서 서비스를 실행하려면 **기존 클러스터**에서 클러스터를 선택하세요. 새 클러스터에서 서비스를 실행하려면 **클러스터 생성**을 선택하세요. 1. 클러스터 인프라에 태스크를 배포하는 방식을 선택합니다. **컴퓨팅 구성**에서 옵션을 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-blue-green-service.html) 1. **배포 구성**에서 다음을 수행합니다. 1. **서비스 유형**에서 **복제본**을 선택하세요. 1. **원하는 작업(Desired tasks)**에 서비스에서 시작 및 유지 관리할 작업 수를 입력합니다. 1. Amazon ECS에서 가용 영역 전체의 태스크 분산을 모니터링하고 불균형이 있을 때 재분산하려면 **가용 영역 서비스 리밸런싱**에서 **가용 영역 서비스 리밸런싱**을 선택하세요. 1. **상태 확인 유예 기간**에 태스크가 처음 시작된 후 서비스 스케줄러가 비정상 Elastic Load Balancing, VPC Lattice, 컨테이너 상태 확인을 무시하는 시간(초)을 입력하세요. 상태 확인 유예 기간 값을 지정하지 않으면 기본값인 0이 사용됩니다. 1. 1. **베이크 소요 시간**에 블루 개정이 종료되기 전에 블루 및 그린 서비스 개정이 동시에 실행되는 시간(분)을 입력하세요. 이를 통해 확인 및 테스트 시간을 확보할 수 있습니다. 1. (선택 사항) 배포의 특정 단계에서 실행할 Lambda 함수를 실행하세요. **배포 수명 주기 후크**에서 수명 주기 후크를 실행할 단계를 선택하세요. 수명 주기 후크를 추가하는 방법: 1. **추가**를 선택합니다. 1. **Lambda 함수**에서 함수 이름 또는 ARN을 입력하세요. 1. **역할**에서 Lambda 함수를 간접 호출할 권한이 있는 IAM 역할을 선택하세요. 1. **수명 주기 단계**에서 Lambda 함수를 실행해야 하는 단계를 선택하세요. 1. Amazon ECS에서 배포 오류를 탐지 및 처리하는 방법을 구성하려면 **배포 오류 탐지(Deployment failure detection)**를 펼친 다음, 옵션을 선택합니다. 1. 작업을 시작할 수 없을 때 배포를 중지하려면 **Use the Amazon ECS deployment circuit breaker**(Amazon ECS 배포 회로 차단기 사용)를 선택합니다. 배포 회로 차단기가 배포를 실패한 상태로 설정했을 때 소프트웨어가 마지막으로 완료한 배포로 자동 롤백하도록 하려면 **실패 시 롤백**을 선택합니다. 1. 애플리케이션 지표를 기반으로 배포를 중지하려면 **CloudWatch 경보 사용**을 선택합니다. 그런 다음, **CloudWatch 경보 이름**에서 경보를 선택합니다. 새 경보를 생성하려면 CloudWatch 콘솔을 이동합니다. CloudWatch 경보가 배포를 실패한 상태로 설정할 때 소프트웨어가 마지막으로 완료한 배포 상태로 자동 롤백하도록 하려면 **실패 시 롤백**을 선택합니다. 1. (선택 사항) Service Connect를 사용하여 서비스를 상호 연결하려면 **Service Connect**를 확장한 후 다음을 지정하세요. 1. **Service Connect 켜기**를 선택합니다. 1. **Service Connect configuration**(Service Connect 구성)에서 클라이언트 모드를 지정합니다. + 서비스에서 네임스페이스의 다른 서비스에만 연결하면 되는 네트워크 클라이언트 애플리케이션을 실행하는 경우 **클라이언트 측만**을 선택합니다. + 서비스가 네트워크 또는 웹 서비스 애플리케이션을 실행하고 이 서비스에 대한 엔드포인트를 제공해야 하며, 네임스페이스의 다른 서비스에 연결해야 하는 경우 **Client and server**(클라이언트 및 서버)를 선택합니다. 1. 기본 클러스터 네임스페이스가 아닌 네임스페이스를 사용하려면 **Namespace**(네임스페이스)에서 서비스 네임스페이스를 선택합니다. 이는 AWS 계정의 동일한 AWS 리전에서 별도로 생성된 네임스페이스 또는 AWS Resource Access Manager(AWS RAM)를 사용하여 계정과 공유되는 동일한 리전의 네임스페이스일 수 있습니다. 공유 AWS Cloud Map 네임스페이스에 대한 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)을 참조하세요. 1. (선택 사항) 블루/그린 배포에 대한 테스트 트래픽 헤더 규칙을 구성하세요. **테스트 트래픽 라우팅**에서 다음을 지정하세요. 1. 테스트 중에 특정 요청을 그린 서비스 개정으로 라우팅하려면 **테스트 트래픽 헤더 규칙 활성화**를 선택하세요. 1. **헤더 일치 규칙**에서 테스트 트래픽 라우팅 기준을 구성하세요. + **헤더 이름**: 일치시킬 HTTP 헤더의 이름을 입력합니다(예: `X-Test-Version` 또는 `User-Agent`). + **일치 유형**: 일치 기준을 선택합니다. + **정확한 일치**: 헤더 값이 지정된 값과 정확히 일치하는 요청을 라우팅합니다. + **헤더 있음**: 값에 관계없이 지정된 헤더를 포함하는 라우팅 요청 + **패턴 일치**: 헤더 값이 지정된 패턴과 일치하는 요청 라우팅 + **헤더 값**(정확한 일치 또는 패턴 일치를 사용하는 경우): 일치시킬 값 또는 패턴을 입력합니다. 여러 헤더 일치 규칙을 추가하여 복잡한 라우팅 로직을 생성할 수 있습니다. 구성된 규칙과 일치하는 요청은 테스트를 위해 그린 서비스 개정으로 라우팅됩니다. 1. **헤더 규칙 추가**를 선택하여 추가 헤더 일치 조건을 구성하세요. **참고** 테스트 트래픽 헤더 규칙을 사용하면 전체 배포를 완료하기 전에 트래픽을 제어하며 새 기능을 검증할 수 있습니다. 이를 통해 블루 서비스 개정으로 정상적인 트래픽 흐름을 유지하면서 특정 요청(예: 내부 테스트 도구 또는 베타 사용자의 요청)으로 그린 서비스 개정을 테스트할 수 있습니다. 1. (선택 사항) 로그 구성을 지정합니다. **로그 수집 사용**을 선택합니다. 기본 옵션은 CloudWatch Logs로 컨테이너 로그를 전송합니다. 다른 로그 드라이버 옵션은 AWS FireLens를 사용하여 구성됩니다. 자세한 정보는 [Amazon ECS 로그를 AWS 서비스 또는 AWS Partner로 전송](using_firelens.md)을 참조하세요. 다음은 각 컨테이너 로그 대상에 대한 자세한 설명입니다. + **Amazon CloudWatch** - CloudWatch Logs로 컨테이너 로그를 전송하도록 작업을 구성합니다. 사용자를 대신하여 CloudWatch 로그 그룹을 생성하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 로그 그룹 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon Data Firehose** - Firehose로 컨테이너 로그를 전송하도록 작업을 구성합니다. Firehose 전송 스트림으로 로그를 전송하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 전송 스트림 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon Kinesis Data Streams** - Kinesis Data Streams로 컨테이너 로그를 전송하도록 작업을 구성합니다. Kinesis Data Streams 스트림으로 로그를 전송하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 스트림 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon OpenSearch Service** - OpenSearch Service 도메인으로 컨테이너 로그를 전송하도록 작업을 구성합니다. 로그 드라이버 옵션이 제공되어야 합니다. + **Amazon S3** - Amazon S3 버킷으로 컨테이너 로그를 전송하도록 작업을 구성합니다. 기본 로그 드라이버 옵션이 제공되지만 유효한 Amazon S3 버킷 이름을 지정해야 합니다. 1. (선택 사항) 블루/그린 배포를 위한 **로드 밸런싱**을 구성하세요. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-blue-green-service.html) 1. (선택 사항) 서비스와 태스크를 식별하려면 **태그(Tags)** 섹션을 펼친 다음, 태그를 구성합니다. Amazon ECS에서 새로 시작된 모든 작업에 클러스터 이름과 작업 정의 태그를 자동으로 지정하도록 하려면 **Amazon ECS 관리형 태그 켜기**를 선택한 다음 **작업 전파 시작**에서 **작업 정의**를 선택합니다. Amazon ECS에서 새로 시작된 모든 작업에 클러스터 이름과 서비스 태그를 자동으로 지정하도록 하려면 **Amazon ECS 관리형 태그 켜기**를 선택한 다음 **작업 전파 시작**에서 **서비스**를 선택합니다. 태그를 추가하거나 제거합니다. + [태그 추가] **새로운 태그(Add tag)**를 선택하고 다음을 수행합니다. + **키**에서 키 이름을 입력합니다. + **값**에 키 값을 입력합니다. + [태그 제거] 태그 옆에 있는 **태그 제거**를 선택합니다. 1. **생성(Create)**을 선택합니다. ------ #### [ AWS CLI ] 1. 다음 콘텐츠가 포함된 `service-definition.json`이라는 파일을 생성합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. ``` { "serviceName": "myBlueGreenService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 2, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true }, "lifecycleHooks": [ { "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample", "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke", "lifecycleStages": [ "PRE_SCALE_UP" ] } ] }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. `create-service`를 실행합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. ``` aws ecs create-service --cli-input-json file://service-definition.json ``` 또는 로드 밸런서 구성으로 블루/그린 배포 서비스를 생성하는 다음 예제를 사용할 수 있습니다. ``` aws ecs create-service \ --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \ --service-name "blue-green-example-service" \ --task-definition "nginxServer:1" \ --launch-type "FARGATE" \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \ --desired-count 3 \ --deployment-controller "type=ECS" \ --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \ --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}" ``` ------ ## 다음 단계 + 배포를 시작하도록 서비스를 업데이트합니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. + 배포 프로세스를 모니터링하여 블루/그린 패턴을 따르는지 확인합니다. + 그린 서비스 개정이 생성되고 스케일 업됨 + 테스트 트래픽이 그린 개정으로 라우팅됨(구성된 경우) + 프로덕션 트래픽이 그린 개정으로 전환됨 + 베이크 소요 시간이 지나면 블루 개정이 종료됨 # Amazon ECS 블루/그린 배포 문제 해결 다음은 Amazon ECS에서 블루/그린 배포를 사용할 때 발생할 수 있는 일반적인 문제에 대한 솔루션을 제공합니다. 블루/그린 배포 오류는 다음과 같은 단계에서 발생할 수 있습니다. + *동기 경로*: `CreateService` 또는 `UpdateService` API 직접 호출에 대한 응답으로 즉시 나타나는 오류입니다. + *비동기 경로*: `DescribeServiceDeployments`의 `statusReason` 필드에 나타나며 배포 롤백을 유발하는 오류입니다. **작은 정보** [Amazon ECS MCP 서버](ecs-mcp-introduction.md)를 AI 어시스턴트와 함께 사용하여 배포를 모니터링하고 자연어를 사용하여 배포 문제를 해결할 수 있습니다. ## 로드 밸런서 구성 문제 로드 밸런서 구성은 Amazon ECS에서 블루/그린 배포의 중요한 구성 요소입니다. 성공적인 배포를 위해서는 리스너 규칙, 대상 그룹 및 로드 밸런서 유형을 올바르게 구성해야 합니다. 이 섹션에서는 블루/그린 배포 실패가 일어날 수 있는 일반적인 로드 밸런서 구성 문제를 다룹니다. 로드 밸런서 문제를 해결할 때는 리스너 규칙과 대상 그룹 간의 관계를 이해하는 것이 중요합니다. 블루/그린 배포에서: + 프로덕션 리스너 규칙은 트래픽을 현재 활성(블루) 서비스 개정으로 전달함 + 프로덕션 트래픽을 이동하기 전에 테스트 리스너 규칙을 사용하여 새 (그린) 서비스 개정 검증 가능 + 대상 그룹은 각 서비스 개정의 컨테이너 인스턴스를 등록하는 데 사용됨 + 배포 중에 리스너 규칙에서 대상 그룹의 가중치를 조정하여 트래픽이 블루 서비스 개정에서 그린 서비스 개정으로 점진적으로 이동함 ### 리스너 규칙 구성 오류 다음 문제는 블루/그린 배포에 대한 잘못된 리스너 규칙 구성과 관련된 사항입니다. 리스너 규칙 ARN 대신 Application Load Balancer 리스너 ARN 사용 *오류 메시지*: `productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456` *해결 방법*: Application Load Balancer를 사용하는 경우 리스너 ARN이 아닌 `productionListenerRule` 및 `testListenerRule`에 대한 리스너 규칙 ARN을 지정해야 합니다. Network Load Balancer의 경우 리스너 ARN을 사용해야 합니다. 리스너 ARN을 찾는 방법에 대한 자세한 정보는 *Application Load Balancers 사용 설명서*의 [Application Load Balancer에 대한 리스너 생성](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)을 참조하세요. 규칙의 ARN은 `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...` 형식입니다. 프로덕션 리스너와 테스트 리스너 모두에 동일한 규칙 사용 *오류 메시지*: `The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789` *해결 방법*: 프로덕션 및 테스트 트래픽에는 서로 다른 리스너 규칙을 사용해야 합니다. 테스트 대상 그룹으로 라우팅되는 테스트 트래픽에 대해 별도의 리스너 규칙을 생성합니다. 대상 그룹이 리스너 규칙과 연결되지 않음 *오류 메시지*: `Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.` *해결 방법*: 기본 대상 그룹과 대체 대상 그룹은 모두 프로덕션 리스너 규칙 또는 테스트 리스너 규칙과 연결되어야 합니다. 로드 밸런서 구성을 업데이트하여 두 대상 그룹이 리스너 규칙과 올바르게 연결되도록 합니다. Application Load Balancer에서 테스트 리스너 규칙 누락 *오류 메시지*: `For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup` *해결 방법*: Application Load Balancer를 사용할 때 두 대상 그룹이 모두 프로덕션 리스너 규칙과 연결되지 않은 경우 테스트 리스너 규칙을 지정해야 합니다. 구성에 `testListenerRule`을 추가하고 두 대상 그룹이 프로덕션 또는 테스트 리스너 규칙과 연결되어 있는지 확인합니다. 자세한 내용은 *Application Load Balancer 사용 설명서*의 [Application Load Balancers용 리스너](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)를 참조하세요. ### 대상 그룹 구성 문제 다음 문제는 블루/그린 배포에 대한 잘못된 대상 그룹 구성과 관련된 사항입니다. 리스너 규칙에 트래픽이 있는 여러 대상 그룹 *오류 메시지*: `Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic` *해결 방법*: 블루/그린 배포를 시작하기 전에 리스너 규칙에서 하나의 대상 그룹만 트래픽을 수신하고 있는지(가중치가 0이 아닌지) 확인합니다. 트래픽을 수신하지 않아야 하는 대상 그룹의 가중치를 0으로 설정하도록 리스너 규칙 구성을 업데이트합니다. 로드 밸런서 항목 간에 대상 그룹 복제 *오류 메시지*: `Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123` *해결 방법*: 각 대상 그룹 ARN은 서비스 정의의 모든 로드 밸런서 항목에서 고유해야 합니다. 구성을 검토하고 각 로드 밸런서 항목에 대해 서로 다른 대상 그룹을 사용하고 있는지 확인합니다. 프로덕션 리스너 규칙의 예상치 못한 대상 그룹 *오류 메시지*: `Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789` *해결 방법*: 프로덕션 리스너 규칙이 서비스 정의에 지정되지 않은 대상 그룹에 트래픽을 전달하고 있습니다. 리스너 규칙이 서비스 정의에 지정된 대상 그룹으로만 트래픽을 전달하도록 구성되어 있는지 확인합니다. 자세한 내용은 *Application Load Balancer 사용 설명서*의 [전달 작업](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions)을 참조하세요. ### 로드 밸런서 유형 구성 오류 다음 문제는 블루/그린 배포에 대한 잘못된 로드 밸런서 유형 구성과 관련된 사항입니다. Classic Load Balancer 및 Application Load Balancer 또는 Network Load Balancer 구성 혼합 *오류 메시지*: `All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)` Classic Load Balancer는 Elastic Load Balancing 이전 세대의 로드 밸런서입니다. 현재 세대의 로드 밸런서로 마이그레이션하는 것이 좋습니다. 자세한 내용은 [Classic Load Balancer 마이그레이션](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html)을 참조하세요. *해결 방법*: 모든 Classic Load Balancer 또는 모든 Application Load Balancer 및 Network Load Balancer를 사용합니다. Application Load Balancer 및 Network Load Balancer의 경우 `targetGroupArn` 필드만 지정합니다. Classic Load Balancer에서 고급 구성 사용 *오류 메시지*: `advancedConfiguration field is not allowed with ELBv1 loadBalancers` *해결 방법*: 블루/그린 배포를 위한 고급 구성은 Application Load Balancer 및 Network Load Balancer에서만 지원됩니다. Classic Load Balancer(`loadBalancerName`으로 지정됨)를 사용하는 경우 `advancedConfiguration` 필드를 사용할 수 없습니다. Application Load Balancer로 전환하거나 `advancedConfiguration` 필드를 제거합니다. 로드 밸런서 간 일관되지 않은 고급 구성 *오류 메시지*: `Either all or none of the provided loadBalancers must have advancedConfiguration defined` *해결 방법*: 로드 밸런서를 여러 개 사용하는 경우 모든 로드 밸런서에 대해 `advancedConfiguration`을 정의하거나 어느 로드 밸런서에도 정의하지 않아야 합니다. 모든 로드 밸런서 항목에서 일관성을 보장하도록 구성을 업데이트합니다. 블루/그린 배포에서 고급 구성 누락 *오류 메시지*: `advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy` *해결 방법*: Application Load Balancer에서 블루/그린 배포 전략을 사용하는 경우 모든 로드 밸런서 항목에 `advancedConfiguration` 필드를 지정해야 합니다. 로드 밸런서 구성에 필요한 `advancedConfiguration`을 추가합니다. ## 권한 문제 다음 문제는 블루/그린 배포에 대한 권한 부족과 관련된 사항입니다. 인프라 역할에 대한 신뢰 정책 누락 *오류 메시지*: `Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.` *해결 방법*: 로드 밸런서 리소스를 관리하기 위해 지정된 IAM 역할에 올바른 신뢰 정책이 없습니다. 서비스에서 역할을 위임할 수 있도록 역할의 신뢰 정책을 업데이트합니다. 신뢰 정책은 다음을 포함해야 합니다. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 로드 밸런서 역할에 대한 읽기 권한 누락 *오류 메시지*: `service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)` *해결 방법*: 로드 밸런서 리소스 관리에 사용되는 IAM 역할에 대상 상태 정보를 읽을 수 있는 권한이 없습니다. 역할 정책에 `elasticloadbalancing:DescribeTargetHealth` 권한을 추가합니다. Elastic Load Balancing 권한에 대한 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. 로드 밸런서 역할에 대한 쓰기 권한 누락 *오류 메시지*: `service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)` *해결 방법*: 로드 밸런서 리소스 관리에 사용되는 IAM 역할에 대상을 등록할 수 있는 권한이 없습니다. 역할 정책에 `elasticloadbalancing:RegisterTargets` 권한을 추가합니다. Elastic Load Balancing 권한에 대한 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. 리스너 규칙을 수정할 수 있는 권한 누락 *오류 메시지*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action` *해결 방법*: 로드 밸런서 리소스 관리에 사용되는 IAM 역할에 대상을 수정할 수 있는 권한이 없습니다. 역할 정책에 `elasticloadbalancing:ModifyListener` 권한을 추가합니다. Elastic Load Balancing 권한에 대한 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. 블루/그린 배포의 경우 로드 밸런서 리소스 관리에 필요한 모든 권한이 포함된 `AmazonECS-ServiceLinkedRolePolicy` 관리형 정책을 인프라 역할에 연결하는 것이 좋습니다. ## 수명 주기 후크 문제 다음 문제는 블루/그린 배포의 수명 주기 후크와 관련된 사항입니다. Lambda 후크 역할에 대한 잘못된 신뢰 정책 *오류 메시지*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin` *해결 방법*: Lambda 수명 주기 후크에 지정된 IAM 역할에 올바른 신뢰 정책이 없습니다. 서비스에서 역할을 위임할 수 있도록 역할의 신뢰 정책을 업데이트합니다. 신뢰 정책은 다음을 포함해야 합니다. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` Lambda 후크가 FAILED 상태를 반환함 *오류 메시지*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.` *해결 방법*: 수명 주기 후크로 지정된 Lambda 함수가 FAILED 상태를 반환했습니다. Amazon CloudWatch Logs에서 Lambda 함수 로그를 확인하여 실패 이유를 파악하고 배포 이벤트를 올바르게 처리하도록 함수를 업데이트합니다. Lambda 함수를 호출할 수 있는 권한 누락 *오류 메시지*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action` *해결 방법*: Lambda 수명 주기 후크에 사용되는 IAM 역할에 Lambda 함수를 호출할 수 있는 권한이 없습니다. 특정 Lambda 함수 ARN에 대한 역할 정책에 `lambda:InvokeFunction` 권한을 추가합니다. Lambda 권한에 대한 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. Lambda 함수 시간 초과 또는 잘못된 응답 *오류 메시지*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null` *해결 방법*: Lambda 함수가 시간 초과되었거나 잘못된 응답을 반환했습니다. Lambda 함수가 `hookStatus` 필드가 `SUCCEEDED` 또는 `FAILED`로 설정된 유효한 응답을 반환하는지 확인합니다. 또한 Lambda 함수 시간 초과가 검증 로직에 맞게 적절하게 설정되었는지 확인합니다. 자세한 내용은 [Amazon ECS 서비스 배포에 대한 수명 주기 후크](deployment-lifecycle-hooks.md) 섹션을 참조하세요. 유효한 Lambda 응답의 예: ``` { "hookStatus": "SUCCEEDED", "reason": "Validation passed" } ``` # Amazon ECS 선형 배포 선형 배포는 시간이 지남에 따라 트래픽을 이전 서비스 개정에서 새 서비스 개정으로 점진적으로 동일한 증분만큼씩 이전하므로 다음 단계로 진행하기 전에 각 단계를 모니터링할 수 있습니다. Amazon ECS 선형 배포를 사용하면 트래픽 이전 속도를 제어하고 프로덕션 트래픽의 양이 증가함에 따라 새 서비스 개정을 검증합니다. 이 접근 방식은 각 증분에서 성능을 모니터링하는 기능과 함께 변경 사항을 배포하는 제어된 방법을 제공합니다. ## 선형 배포와 관련된 리소스 다음은 Amazon ECS 선형 배포와 관련된 리소스입니다. + 트래픽 이전 - Amazon ECS가 프로덕션 트래픽을 이전하는 데 사용하는 프로세스. Amazon ECS 선형 배포의 경우 트래픽은 각 증분 간에 구성 가능한 대기 시간을 두고 동일한 비율 증분 단위로 이전됩니다. + 단계 백분율 - 선형 배포 중에 각 증분 단위로 이전할 트래픽의 백분율. 이 필드는 값으로 Double을 사용하며 유효한 값은 3.0\$1100.0입니다. + 단계 베이크 소요 시간 - 선형 배포 중 각 트래픽 이전 증분 사이의 대기 시간. 유효한 값은 0\$11,440분입니다. + 배포 베이크 소요 시간 - 모든 프로덕션 트래픽을 새 서비스 개정으로 이전한 후 Amazon ECS가 이전 서비스 개정을 종료하기 전에 대기하는 시간. 프로덕션 트래픽이 이전한 후 블루 및 그린 서비스 개정이 모두 동시에 실행되는 기간입니다. + 수명 주기 단계 - '프로덕션 트래픽 전환 후'와 같은 배포 작업에 존재하는 일련의 이벤트. + 수명 주기 후크 - 특정 수명 주기 단계에서 실행되는 Lambda 함수. 배포를 확인하는 함수를 생성할 수 있습니다. PRODUCTION\$1TRAFFIC\$1SHIFT에 대해 구성된 Lambda 함수 또는 수명 주기 후크는 모든 프로덕션 트래픽 이전 단계에서 간접 호출됩니다. + 대상 그룹 - 요청을 하나 이상의 등록된 대상(예: EC2 인스턴스)으로 라우팅하는 데 사용되는 Elastic Load Balancing 리소스. 리스너를 생성할 때 기본 작업에 대한 대상 그룹을 지정합니다. 트래픽은 리스너 규칙에 지정된 대상 그룹으로 전달됩니다. + 리스너 - 사용자가 구성한 프로토콜 및 포트를 사용하여 연결 요청을 확인하는 Elastic Load Balancing 리소스. 리스너에 대해 사용자가 정의한 규칙에 따라 Amazon ECS가 등록된 대상으로 요청을 라우팅하는 방법이 결정됩니다. + 규칙 - 리스너와 연결된 Elastic Load Balancing 리소스. 규칙은 요청이 라우팅되는 방식을 정의하며, 작업, 조건, 우선순위로 구성됩니다. ## 고려 사항 배포 유형을 선택할 때 다음을 고려하세요. + 리소스 사용량: 선형 배포는 블루 및 그린 서비스 개정을 동시에 일시적으로 실행합니다. 이 경우 배포 중에 리소스 사용량이 두 배가 될 수 있습니다. + 배포 모니터링: 선형 배포는 자세한 배포 상태 정보를 제공하므로 이를 통해 배포 프로세스의 각 단계와 각 트래픽 이전 증분을 모니터링할 수 있습니다. + 롤백: 선형 배포를 사용하면 베이크 소요 시간이 만료될 때까지 블루 개정이 계속 실행되므로 문제가 감지되면 이전 버전으로 쉽게 롤백할 수 있습니다. + 점진적 검증: 선형 배포를 사용하면 프로덕션 트래픽의 양이 증가함에 따라 새 개정을 검증하여 배포에 대한 신뢰도를 높일 수 있습니다. + 배포 기간: 증분 트래픽 이전 및 단계 사이의 대기 시간으로 인해 선형 배포가 한 번에 전체를 배포하는 방식보다 완료되는 데 시간이 더 오래 걸립니다. ## 선형 배포 작동 방식 Amazon ECS 선형 배포 프로세스는 안전하고 신뢰할 수 있는 애플리케이션 업데이트를 보장하는 6단계로 구성된 구조화된 접근 방식을 따릅니다. 각 단계는 애플리케이션을 검증하고 현재 버전(파란색)에서 새 버전(녹색)으로 전환하는 구체적인 목적을 지원합니다. 1. 준비 단계: 기존 블루 환경과 함께 그린 환경을 생성합니다. 1. 배포 단계: 그린 환경에 새 서비스 개정을 배포합니다. 블루 환경이 프로덕션 트래픽을 계속 처리하는 동안 Amazon ECS는 업데이트된 서비스 개정을 사용하여 새 태스크를 시작합니다. 1. 테스트 단계: 테스트 트래픽 라우팅을 사용하여 그린 환경을 검증합니다. Application Load Balancer는 프로덕션 트래픽이 블루 환경에서 유지되는 동안 테스트 요청을 그린 환경으로 보냅니다. 1. 선형 트래픽 이전 단계: 구성된 배포 전략에 따라 프로덕션 트래픽을 블루에서 그린으로 동일한 백분율 증분만큼 점진적으로 이전합니다. 1. 모니터링 단계: 베이크 소요 시간 동안 애플리케이션 상태, 성능 지표 및 경보 상태를 모니터링합니다. 문제가 감지되면 롤백 작업이 시작됩니다. 1. 완료 단계: 블루 환경을 종료하여 배포를 완료합니다. 선형 트래픽 이전 단계는 다음 단계를 따릅니다. + 초기 - 배포는 블루(현재) 서비스 개정으로 라우팅된 트래픽의 100%로 시작됩니다. 그린(신규) 서비스 개정은 테스트 트래픽을 수신하지만 처음에는 프로덕션 트래픽은 수신하지 않습니다. + 증분 트래픽 이전 - 트래픽은 블루에서 그린으로 동일한 백분율 증분만큼 이전됩니다. 예를 들어 10.0% 단계 구성을 사용하면 트래픽은 다음과 같이 이전됩니다. + 1단계: 녹색으로 10.0%, 파란색으로 90.0% + 2단계: 녹색으로 20.0%, 파란색으로 80.0% + 3단계: 녹색으로 30.0%, 파란색으로 70.0% + 100%가 그린에 도달할 때까지 + 단계 베이크 소요 시간 - 트래픽 로드가 증가함에 따라 새 개정의 성능을 모니터링하고 검증할 수 있도록 각 트래픽 이전 증분 사이에 배포는 구성 가능한 기간(단계 베이크 소요 시간)을 대기합니다. 참고로 트래픽이 100.0% 이전되면 마지막 단계 베이크 소요 시간은 건너뜁니다. + 수명 주기 후크 - 배포 중 다양한 수명 주기 단계에서 선택적 Lambda 함수를 실행하여 자동화된 검증, 모니터링 또는 사용자 지정 로직을 수행할 수 있습니다. PRODUCTION\$1TRAFFIC\$1SHIFT에 대해 구성된 Lambda 함수 또는 수명 주기 후크는 모든 프로덕션 트래픽 이전 단계에서 간접 호출됩니다. ## 배포 수명 주기 단계 선형 배포 프로세스는 각각 특정 책임과 검증 체크포인트가 있는 고유한 수명 주기 단계로 진행됩니다. 이러한 단계를 이해하면 배포 진행 상황을 모니터링하고 문제를 효과적으로 해결할 수 있습니다. 각 수명 주기 단계는 최대 24시간 동안 지속될 수 있으며 PRODUCTION\$1TRAFFIC\$1SHIFT의 각 트래픽 이전 단계도 최대 24시간 동안 지속될 수 있습니다. 값을 24시간 표시 미만으로 유지하는 것이 좋습니다. 비동기 프로세스가 후크를 트리거하는 데 시간이 필요하기 때문입니다. 시스템 제한 시간이 초과되어 배포에 실패하고 하나의 단계가 24시간에 도달한 후에 롤백을 시작합니다. CloudFormation 배포에는 추가 제한 시간의 제한 사항이 있습니다. 24시간의 단계 제한은 여전히 유효하지만 CloudFormation은 전체 배포에 대해 36시간의 제한을 적용합니다. CloudFormation에서 배포에 실패하고 프로세스가 36시간 이내에 완료되지 않으면 롤백을 시작합니다. | 수명 주기 단계 | 설명 | 수명 주기 후크 지원 | | --- | --- | --- | | RECONCILE\$1SERVICE | 이 단계는 활성 상태인 서비스 개정이 2개 이상인 새 서비스 배포를 시작하는 경우에만 나타납니다. | 예 | | PRE\$1SCALE\$1UP | 그린 서비스 개정이 시작되지 않았습니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리하는 중입니다. 테스트 트래픽이 없습니다. | 예 | | SCALE\$1UP | 그린 서비스 개정이 100%까지 스케일 업되고 새 태스크를 시작하는 시간. 그린 서비스 개정이 현재 트래픽을 처리하지 않습니다. | 아니요 | | POST\$1SCALE\$1UP | 그린 서비스 개정이 시작되었습니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리하는 중입니다. 테스트 트래픽이 없습니다. | 예 | | TEST\$1TRAFFIC\$1SHIFT | 블루 및 그린 서비스 개정이 실행 중입니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리합니다. 그린 서비스 개정이 테스트 트래픽의 0%\$1100%를 마이그레이션하고 있습니다. | 예 | | POST\$1TEST\$1TRAFFIC\$1SHIFT | 테스트 트래픽 전환이 완료되었습니다. 그린 서비스 개정이 테스트 트래픽의 100%를 처리합니다. | 예 | | PRODUCTION\$1TRAFFIC\$1SHIFT | 트래픽은 그린이 트래픽의 100%를 수신할 때까지 동일한 비율 증분으로 블루에서 그린으로 점진적으로 이전됩니다. 각 트래픽 이전은 24시간 제한 시간을 두고 수명 주기 후크를 간접 호출합니다. | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 프로덕션 트래픽 전환이 완료되었습니다. | 예 | | BAKE\$1TIME | 블루 및 그린 서비스 개정이 동시에 실행 중인 기간. | 아니요 | | CLEAN\$1UP | 블루 서비스 개정이 실행 중인 태스크가 0개인 상태로 완전히 스케일 다운되었습니다. 이제 그린 서비스 개정은 이 단계 이후에 프로덕션 서비스 개정이 됩니다. | 아니요 | # Amazon ECS 선형 배포에 필요한 리소스 관리형 트래픽 전환을 통해 선형 배포를 사용하려면 서비스에서 다음 기능 중 하나를 사용해야 합니다. + Elastic Load Balancing + Service Connect 다음 목록은 Amazon ECS 선형 배포를 위해 구성해야 하는 사항에 대한 개략적인 개요를 제공합니다. + 서비스는 Application Load Balancer, Network Load Balancer 또는 Service Connect를 사용합니다. 적절한 리소스를 구성합니다. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. + Service Connect - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스](service-connect-blue-green.md) 섹션을 참조하세요. + 서비스 배포 컨트롤러를 `ECS`로 설정합니다. + 서비스 정의에서 `linear`으로 배포 전략을 구성합니다. + 선택적으로 다음과 같은 추가 파라미터를 구성합니다. + 새 배포를 위한 베이크 소요 시간 + 첫 번째 증분에서 이전할 트래픽의 백분율. + 각 트래픽 이전 증분 사이의 대기 시간(분). + 자동 롤백에 대한 CloudWatch 경보 + 배포 수명 주기 후크(BEFORE\$1INSTALL, PRODUCTION\$1TRAFFIC\$1SHIFT 또는 POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT와 같이 지정된 배포 단계에서 실행되는 Lambda 함수) ## 모범 사례 성공적인 Amazon ECS 선형 배포를 위해 다음 모범 사례를 따릅니다. + **애플리케이션이 동시에 실행되는 서비스 개정을 모두 처리할 수 있는지 확인합니다.** + **배포 중에 두 서비스 개정을 모두 처리할 수 있는 충분한 클러스터 용량을 계획합니다.** + **프로덕션 환경에서 롤백 프로시저를 구현하기 전에 테스트합니다.** + 애플리케이션 상태를 정확하게 반영하는 적절한 상태 확인을 구성합니다. + 새 서비스 개정을 충분히 테스트할 수 있는 베이크 소요 시간을 설정합니다. + CloudWatch 경보를 구현하여 문제를 자동으로 감지하고 롤백을 트리거합니다. + 배포 속도와 검증 요구 사항의 균형을 맞추는 단계 백분율과 베이크 소요 시간을 선택합니다. + 위험 노출을 최소화하기 위해 중요한 애플리케이션에 더 작은 단계 백분율(5\$110%)을 사용합니다. + 워밍업하거나 안정화하는 데 시간이 필요한 애플리케이션의 경우 더 긴 단계 베이크 소요 시간을 설정합니다. + CloudWatch 경보를 구현하여 문제를 자동으로 감지하고 롤백을 트리거합니다. + 각 트래픽 이전 중에 애플리케이션 지표를 면밀히 모니터링하여 성능 저하를 조기에 감지합니다. + 애플리케이션이 동시에 실행되는 서비스 개정을 모두 처리할 수 있는지 확인합니다. + 프로덕션에서 구현하기 전에 여러 트래픽 백분율로 롤백 프로시저를 테스트합니다. # Amazon ECS 선형 배포 생성 Amazon ECS 선형 배포를 사용하면 지정된 시간 간격에 걸쳐 동일한 증분으로 트래픽을 점진적으로 이전할 수 있습니다. 그러면 배포 프로세스의 각 단계에서 제어된 검증을 제공합니다. ## 사전 조건 선형 배포를 시작하기 전에 다음 작업을 수행합니다. 1. 적절한 권한을 구성하세요. + Elastic Load Balancing 권한에 대한 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. + Lambda 권한에 대한 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. 1. Amazon ECS 선형 배포를 사용하려면 서비스에서 다음 기능 중 하나를 사용해야 합니다. 적절한 리소스를 구성하세요. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. + Service Connect - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스](service-connect-blue-green.md) 섹션을 참조하세요. ## 절차 콘솔 또는 AWS CLI를 사용하여 Amazon ECS 선형 배포 서비스를 생성할 수 있습니다. ------ #### [ Console ] 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. 서비스를 시작할 리소스를 결정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-linear-service.html) **서비스 생성** 페이지가 표시됩니다. 1. **서비스 세부 정보**에서 다음을 수행합니다. 1. **태스크 정의**에서 사용할 태스크 정의 패밀리 및 개정을 선택하세요. 그런 다음 **태스크 정의 개정**에 사용할 개정을 입력하세요. 1. **서비스 이름(Service name)**에 서비스의 이름을 입력합니다. 1. 기존 클러스터에서 서비스를 실행하려면 **기존 클러스터**에서 클러스터를 선택하세요. 새 클러스터에서 서비스를 실행하려면 **클러스터 생성**을 선택하세요. 1. 클러스터 인프라에 태스크를 배포하는 방식을 선택합니다. **컴퓨팅 구성**에서 옵션을 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-linear-service.html) 1. **배포 구성**에서 다음을 수행합니다. 1. **서비스 유형**에서 **복제본**을 선택하세요. 1. **원하는 작업(Desired tasks)**에 서비스에서 시작 및 유지 관리할 작업 수를 입력합니다. 1. Amazon ECS에서 가용 영역 전체의 태스크 분산을 모니터링하고 불균형이 있을 때 재분산하려면 **가용 영역 서비스 리밸런싱**에서 **가용 영역 서비스 리밸런싱**을 선택하세요. 1. **상태 확인 유예 기간**에 태스크가 처음 시작된 후 서비스 스케줄러가 비정상 Elastic Load Balancing, VPC Lattice, 컨테이너 상태 확인을 무시하는 시간(초)을 입력하세요. 상태 확인 유예 기간 값을 지정하지 않으면 기본값인 0이 사용됩니다. 1. **배포 구성**에서 선형 배포 설정을 구성하세요. 1. **배포 전략**에서 **선형**을 선택하세요. 1. **트래픽 증분 백분율**에 각 증분 단위로 이전할 트래픽의 백분율을 입력하세요(예: 10% 단위로 트래픽을 이전하려면 10%). 1. **증분 간격**에 각 트래픽 이전 증분 사이의 대기 시간(분)을 입력하세요. 1. **베이크 소요 시간**에 최종 트래픽 이전 후 블루 개정이 종료되기 전에 블루 및 그린 서비스 개정이 동시에 실행되는 시간(분)을 입력하세요. 1. (선택 사항) 배포의 특정 단계에서 실행할 Lambda 함수를 실행하세요. **배포 수명 주기 후크**에서 수명 주기 후크를 실행할 단계를 선택하세요. 수명 주기 후크를 추가하는 방법: 1. **추가**를 선택합니다. 1. **Lambda 함수**에서 함수 이름 또는 ARN을 입력하세요. 1. **역할**에서 Lambda 함수를 간접 호출할 권한이 있는 IAM 역할을 선택하세요. 1. **수명 주기 단계**에서 Lambda 함수를 실행해야 하는 단계를 선택하세요. 1. Amazon ECS에서 배포 오류를 탐지 및 처리하는 방법을 구성하려면 **배포 오류 탐지(Deployment failure detection)**를 펼친 다음, 옵션을 선택합니다. 1. 작업을 시작할 수 없을 때 배포를 중지하려면 **Use the Amazon ECS deployment circuit breaker**(Amazon ECS 배포 회로 차단기 사용)를 선택합니다. 배포 회로 차단기가 배포를 실패한 상태로 설정했을 때 소프트웨어가 마지막으로 완료한 배포로 자동 롤백하도록 하려면 **실패 시 롤백**을 선택합니다. 1. 애플리케이션 지표를 기반으로 배포를 중지하려면 **CloudWatch 경보 사용**을 선택합니다. 그런 다음, **CloudWatch 경보 이름**에서 경보를 선택합니다. 새 경보를 생성하려면 CloudWatch 콘솔을 이동합니다. CloudWatch 경보가 배포를 실패한 상태로 설정할 때 소프트웨어가 마지막으로 완료한 배포 상태로 자동 롤백하도록 하려면 **실패 시 롤백**을 선택합니다. 1. (선택 사항) Service Connect를 사용하여 서비스를 상호 연결하려면 **Service Connect**를 확장한 후 다음을 지정하세요. 1. **Service Connect 켜기**를 선택합니다. 1. **Service Connect configuration**(Service Connect 구성)에서 클라이언트 모드를 지정합니다. + 서비스에서 네임스페이스의 다른 서비스에만 연결하면 되는 네트워크 클라이언트 애플리케이션을 실행하는 경우 **클라이언트 측만**을 선택합니다. + 서비스가 네트워크 또는 웹 서비스 애플리케이션을 실행하고 이 서비스에 대한 엔드포인트를 제공해야 하며, 네임스페이스의 다른 서비스에 연결해야 하는 경우 **Client and server**(클라이언트 및 서버)를 선택합니다. 1. 기본 클러스터 네임스페이스가 아닌 네임스페이스를 사용하려면 **Namespace**(네임스페이스)에서 서비스 네임스페이스를 선택합니다. 이는 AWS 계정의 동일한 AWS 리전에서 별도로 생성된 네임스페이스 또는 AWS Resource Access Manager(AWS RAM)를 사용하여 계정과 공유되는 동일한 리전의 네임스페이스일 수 있습니다. 공유 AWS Cloud Map 네임스페이스에 대한 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)을 참조하세요. 1. (선택 사항) 선형 배포에 대한 테스트 트래픽 헤더 규칙을 구성하세요. **테스트 트래픽 라우팅**에서 다음을 지정하세요. 1. 테스트 중에 특정 요청을 그린 서비스 개정으로 라우팅하려면 **테스트 트래픽 헤더 규칙 활성화**를 선택하세요. 1. **헤더 일치 규칙**에서 테스트 트래픽 라우팅 기준을 구성하세요. + **헤더 이름**: 일치시킬 HTTP 헤더의 이름을 입력합니다(예: `X-Test-Version` 또는 `User-Agent`). + **일치 유형**: 일치 기준을 선택합니다. + **정확한 일치**: 헤더 값이 지정된 값과 정확히 일치하는 요청을 라우팅합니다. + **헤더 있음**: 값에 관계없이 지정된 헤더를 포함하는 라우팅 요청 + **패턴 일치**: 헤더 값이 지정된 패턴과 일치하는 요청 라우팅 + **헤더 값**(정확한 일치 또는 패턴 일치를 사용하는 경우): 일치시킬 값 또는 패턴을 입력합니다. 여러 헤더 일치 규칙을 추가하여 복잡한 라우팅 로직을 생성할 수 있습니다. 구성된 규칙과 일치하는 요청은 테스트를 위해 그린 서비스 개정으로 라우팅됩니다. 1. **헤더 규칙 추가**를 선택하여 추가 헤더 일치 조건을 구성하세요. **참고** 테스트 트래픽 헤더 규칙을 사용하면 전체 배포를 완료하기 전에 트래픽을 제어하며 새 기능을 검증할 수 있습니다. 이를 통해 블루 서비스 개정으로 정상적인 트래픽 흐름을 유지하면서 특정 요청(예: 내부 테스트 도구 또는 베타 사용자의 요청)으로 그린 서비스 개정을 테스트할 수 있습니다. 1. (선택 사항) 로그 구성을 지정합니다. **로그 수집 사용**을 선택합니다. 기본 옵션은 CloudWatch Logs로 컨테이너 로그를 전송합니다. 다른 로그 드라이버 옵션은 AWS FireLens를 사용하여 구성됩니다. 자세한 정보는 [Amazon ECS 로그를 AWS 서비스 또는 AWS Partner로 전송](using_firelens.md)을 참조하세요. 다음은 각 컨테이너 로그 대상에 대한 자세한 설명입니다. + **Amazon CloudWatch** - CloudWatch Logs로 컨테이너 로그를 전송하도록 작업을 구성합니다. 사용자를 대신하여 CloudWatch 로그 그룹을 생성하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 로그 그룹 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon Data Firehose** - Firehose로 컨테이너 로그를 전송하도록 작업을 구성합니다. Firehose 전송 스트림으로 로그를 전송하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 전송 스트림 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon Kinesis Data Streams** - Kinesis Data Streams로 컨테이너 로그를 전송하도록 작업을 구성합니다. Kinesis Data Streams 스트림으로 로그를 전송하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 스트림 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon OpenSearch Service** - OpenSearch Service 도메인으로 컨테이너 로그를 전송하도록 작업을 구성합니다. 로그 드라이버 옵션이 제공되어야 합니다. + **Amazon S3** - Amazon S3 버킷으로 컨테이너 로그를 전송하도록 작업을 구성합니다. 기본 로그 드라이버 옵션이 제공되지만 유효한 Amazon S3 버킷 이름을 지정해야 합니다. 1. (선택 사항) 선형 배포를 위한 **로드 밸런싱**을 구성하세요. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-linear-service.html) 1. (선택 사항) 서비스와 태스크를 식별하려면 **태그(Tags)** 섹션을 펼친 다음, 태그를 구성합니다. Amazon ECS에서 새로 시작된 모든 작업에 클러스터 이름과 작업 정의 태그를 자동으로 지정하도록 하려면 **Amazon ECS 관리형 태그 켜기**를 선택한 다음 **작업 전파 시작**에서 **작업 정의**를 선택합니다. Amazon ECS에서 새로 시작된 모든 작업에 클러스터 이름과 서비스 태그를 자동으로 지정하도록 하려면 **Amazon ECS 관리형 태그 켜기**를 선택한 다음 **작업 전파 시작**에서 **서비스**를 선택합니다. 태그를 추가하거나 제거합니다. + [태그 추가] **새로운 태그(Add tag)**를 선택하고 다음을 수행합니다. + **키**에서 키 이름을 입력합니다. + **값**에 키 값을 입력합니다. + [태그 제거] 태그 옆에 있는 **태그 제거**를 선택합니다. 1. **생성(Create)**을 선택합니다. ------ #### [ AWS CLI ] 1. 다음 콘텐츠가 포함된 `linear-service-definition.json`이라는 파일을 생성합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. ``` { "serviceName": "myLinearService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "LINEAR", "maximumPercent": 200, "minimumHealthyPercent": 100, "linearConfiguration": { "stepPercentage": 10.0, "stepBakeTimeInMinutes":6 }, "bakeTimeInMinutes": 10, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true } }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. `create-service`를 실행합니다. ``` aws ecs create-service --cli-input-json file://linear-service-definition.json ``` ------ ## 다음 단계 + 배포를 시작하도록 서비스를 업데이트합니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. + 배포 프로세스를 모니터링하여 선형 패턴을 따르는지 확인합니다. + 그린 서비스 개정이 생성되고 스케일 업됨 + 트래픽은 지정된 간격으로 점진적으로 이전됩니다. + 각 증분은 다음 이전 전에 지정된 간격을 기다립니다. + 모든 트래픽이 이전되면 베이크 소요 시간이 시작됩니다. + 베이크 소요 시간이 지나면 블루 개정이 종료됨 # Amazon ECS 카나리 배포 카나리 배포는 먼저 초기 테스트를 위해 소량의 트래픽을 새 개정으로 라우팅한 다음 카나리 단계가 성공적으로 완료된 후 나머지 모든 트래픽을 한 번에 이전합니다. Amazon ECS 카나리 배포를 사용하면 위험 노출을 최소화하면서 실제 사용자 트래픽으로 새 서비스 개정을 검증할 수 있습니다. 이 접근 방식은 성능을 모니터링하고 문제가 감지되면 신속하게 롤백할 수 있는 기능과 함께 변경 사항을 배포하는 제어된 방법을 제공합니다. ## 카나리 배포와 관련된 리소스 다음은 Amazon ECS 카나리 배포와 관련된 리소스입니다. + 트래픽 이전 - Amazon ECS가 프로덕션 트래픽을 이전하는 데 사용하는 프로세스. Amazon ECS 카나리 배포의 경우 트래픽은 두 단계로 이전됩니다. 먼저 카나리 백분율로 이전한 다음 배포를 완료합니다. + 카나리 백분율 - 평가 기간에 새 버전으로 라우팅되는 트래픽의 백분율. + 카나리 베이크 소요 시간 - 전체 배포를 진행하기 전에 카나리 버전을 모니터링하는 기간. + 배포 베이크 소요 시간 - 모든 프로덕션 트래픽을 새 서비스 개정으로 이전한 후 Amazon ECS가 이전 서비스 개정을 종료하기 전에 대기하는 시간. 프로덕션 트래픽이 이전한 후 블루 및 그린 서비스 개정이 모두 동시에 실행되는 기간입니다. + 수명 주기 단계 - '프로덕션 트래픽 전환 후'와 같은 배포 작업에 존재하는 일련의 이벤트. + 수명 주기 후크 - 특정 수명 주기 단계에서 실행되는 Lambda 함수. 배포를 확인하는 함수를 생성할 수 있습니다. + 대상 그룹 - 요청을 하나 이상의 등록된 대상(예: EC2 인스턴스)으로 라우팅하는 데 사용되는 Elastic Load Balancing 리소스. 리스너를 생성할 때 기본 작업에 대한 대상 그룹을 지정합니다. 트래픽은 리스너 규칙에 지정된 대상 그룹으로 전달됩니다. + 리스너 - 사용자가 구성한 프로토콜 및 포트를 사용하여 연결 요청을 확인하는 Elastic Load Balancing 리소스. 리스너에 대해 사용자가 정의한 규칙에 따라 Amazon ECS가 등록된 대상으로 요청을 라우팅하는 방법이 결정됩니다. + 규칙 - 리스너와 연결된 Elastic Load Balancing 리소스. 규칙은 요청이 라우팅되는 방식을 정의하며, 작업, 조건, 우선순위로 구성됩니다. ## 고려 사항 배포 유형을 선택할 때 다음을 고려하세요. + 리소스 사용량: 카나리 배포는 평가 기간에 원본 태스크 세트와 카나리 태스크 세트를 동시에 실행하여 리소스 사용량을 늘립니다. + 트래픽 볼륨: 카나리 백분율이 새 버전의 의미 있는 검증을 위해 충분한 트래픽을 생성하는지 확인합니다. + 복잡성 모니터링: 카나리 배포에서는 두 버전 간의 지표를 동시에 모니터링하고 비교해야 합니다. + 롤백 속도: 카나리 배포에서는 트래픽을 원래 태스크 세트로 다시 이전하여 빠른 롤백이 가능합니다. + 위험 완화: 카나리 배포는 적은 비율의 사용자로 노출을 제한하여 뛰어난 위험 완화 기능을 제공합니다. + 배포 기간: 카나리 배포에는 전체 배포 시간을 연장하지만 검증 기회를 제공하는 평가 기간이 포함됩니다. ## 카나리 배포 작동 방식 Amazon ECS 카나리 배포 프로세스는 안전하고 신뢰할 수 있는 애플리케이션 업데이트를 보장하는 6단계로 구성된 구조화된 접근 방식을 따릅니다. 각 단계는 애플리케이션을 검증하고 현재 버전(파란색)에서 새 버전(녹색)으로 전환하는 구체적인 목적을 지원합니다. 1. 준비 단계: 기존 블루 환경과 함께 그린 환경을 생성합니다. 1. 배포 단계: 그린 환경에 새 서비스 개정을 배포합니다. 블루 환경이 프로덕션 트래픽을 계속 처리하는 동안 Amazon ECS는 업데이트된 서비스 개정을 사용하여 새 태스크를 시작합니다. 1. 테스트 단계: 테스트 트래픽 라우팅을 사용하여 그린 환경을 검증합니다. Application Load Balancer는 프로덕션 트래픽이 블루 환경에서 유지되는 동안 테스트 요청을 그린 환경으로 보냅니다. 1. 카나리 트래픽 이전 단계: 카나리 단계에서 구성된 트래픽 비율을 새 그린 서비스 개정으로 이전한 다음 트래픽의 100.0%를 그린 서비스 개정으로 이동 1. 모니터링 단계: 베이크 소요 시간 동안 애플리케이션 상태, 성능 지표 및 경보 상태를 모니터링합니다. 문제가 감지되면 롤백 작업이 시작됩니다. 1. 완료 단계: 블루 환경을 종료하여 배포를 완료합니다. 카나리 트래픽 이전 단계는 다음 단계를 따릅니다. + 초기 - 배포는 블루(현재) 서비스 개정으로 라우팅된 트래픽의 100%로 시작됩니다. 그린(신규) 서비스 개정은 테스트 트래픽을 수신하지만 처음에는 프로덕션 트래픽은 수신하지 않습니다. + 카나리 트래픽 이전 - 2단계 트래픽 이전 전략입니다. + 1단계: 녹색으로 10.0%, 파란색으로 90.0% + 2단계: 녹색으로 100.0%, 파란색으로 0.0% + 카나리 베이크 소요 시간 - 트래픽 로드가 증가함에 따라 새 개정의 성능을 모니터링하고 검증할 수 있도록 카나리 트래픽 이전 후 구성 가능한 기간(카나리 베이크 소요 시간)을 대기합니다. + 수명 주기 후크 - 배포 중 다양한 수명 주기 단계에서 선택적 Lambda 함수를 실행하여 자동화된 검증, 모니터링 또는 사용자 지정 로직을 수행할 수 있습니다. PRODUCTION\$1TRAFFIC\$1SHIFT에 대해 구성된 Lambda 함수 또는 수명 주기 후크는 모든 프로덕션 트래픽 이전 단계에서 간접 호출됩니다. ### 배포 수명 주기 단계 카나리 배포 프로세스는 각각 특정 책임과 검증 체크포인트가 있는 고유한 수명 주기 단계로 진행됩니다. 이러한 단계를 이해하면 배포 진행 상황을 모니터링하고 문제를 효과적으로 해결할 수 있습니다. 각 수명 주기 단계는 최대 24시간 동안 지속될 수 있으며 PRODUCTION\$1TRAFFIC\$1SHIFT의 각 트래픽 이전 단계도 최대 24시간 동안 지속될 수 있습니다. 값을 24시간 표시 미만으로 유지하는 것이 좋습니다. 비동기 프로세스가 후크를 트리거하는 데 시간이 필요하기 때문입니다. 시스템 제한 시간이 초과되어 배포에 실패하고 하나의 단계가 24시간에 도달한 후에 롤백을 시작합니다. CloudFormation 배포에는 추가 제한 시간의 제한 사항이 있습니다. 24시간의 단계 제한은 여전히 유효하지만 CloudFormation은 전체 배포에 대해 36시간의 제한을 적용합니다. CloudFormation에서 배포에 실패하고 프로세스가 36시간 이내에 완료되지 않으면 롤백을 시작합니다. **수명 주기 단계** | 수명 주기 단계 | 설명 | 수명 주기 후크 지원 | | --- | --- | --- | | RECONCILE\$1SERVICE | 이 단계는 활성 상태인 서비스 개정이 2개 이상인 새 서비스 배포를 시작하는 경우에만 나타납니다. | 예 | | PRE\$1SCALE\$1UP | 그린 서비스 개정이 시작되지 않았습니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리하는 중입니다. 테스트 트래픽이 없습니다. | 예 | | SCALE\$1UP | 그린 서비스 개정이 100%까지 스케일 업되고 새 태스크를 시작하는 시간. 그린 서비스 개정이 현재 트래픽을 처리하지 않습니다. | 아니요 | | POST\$1SCALE\$1UP | 그린 서비스 개정이 시작되었습니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리하는 중입니다. 테스트 트래픽이 없습니다. | 예 | | TEST\$1TRAFFIC\$1SHIFT | 블루 및 그린 서비스 개정이 실행 중입니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리합니다. 그린 서비스 개정이 테스트 트래픽의 0%\$1100%를 마이그레이션하고 있습니다. | 예 | | POST\$1TEST\$1TRAFFIC\$1SHIFT | 테스트 트래픽 전환이 완료되었습니다. 그린 서비스 개정이 테스트 트래픽의 100%를 처리합니다. | 예 | | PRODUCTION\$1TRAFFIC\$1SHIFT | 카나리 프로덕션 트래픽은 그린 개정으로 라우팅되고 수명 주기 후크는 24시간 제한 시간으로 간접 호출됩니다. 두 번째 단계에서는 나머지 프로덕션 트래픽을 그린 개정으로 이전합니다. | 예 | | POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | 프로덕션 트래픽 전환이 완료되었습니다. | 예 | | BAKE\$1TIME | 블루 및 그린 서비스 개정이 동시에 실행 중인 기간. | 아니요 | | CLEAN\$1UP | 블루 서비스 개정이 실행 중인 태스크가 0개인 상태로 완전히 스케일 다운되었습니다. 이제 그린 서비스 개정은 이 단계 이후에 프로덕션 서비스 개정이 됩니다. | 아니요 | ### 구성 파라미터 카나리 배포에는 다음 구성 파라미터가 필요합니다. + 카나리 백분율 - 카나리 단계에서 새 서비스 개정으로 라우팅할 트래픽의 백분율. 이를 통해 프로덕션 트래픽의 제어된 하위 세트로 테스트할 수 있습니다. + 카나리 베이크 소요 시간 - 남은 트래픽을 새 서비스 개정으로 이전하기 전에 카나리 단계에서 대기하는 기간. 이 시간에 새 버전을 모니터링하고 검증할 수 있습니다. ### 트래픽 관리 카나리 배포는 로드 밸런서 대상 그룹을 사용하여 트래픽 분산을 관리합니다. + 원래 대상 그룹 - 현재 안정적인 버전의 태스크를 포함하며 대부분의 트래픽을 수신합니다. + 카나리 대상 그룹 - 새 버전의 태스크를 포함하며 테스트를 위해 소량의 트래픽을 수신합니다. + 가중치 기반 라우팅 - 로드 밸런서는 가중치 기반 라우팅 규칙을 사용하여 구성된 카나리 백분율을 기반으로 대상 그룹 간에 트래픽을 분산합니다. ### 모니터링 및 검증 효과적인 카나리 배포는 포괄적인 모니터링에 의존합니다. + 상태 확인 - 두 태스크 세트 모두 트래픽을 수신하기 전에 상태 확인을 통과해야 합니다. + 지표 비교 - 응답 시간, 오류율 및 처리량과 같은 원래 버전과 카나리 버전 간의 주요 성능 지표를 비교합니다. + 자동 롤백 - 카나리 버전에서 성능이 저하된 경우 롤백을 자동으로 트리거하도록 CloudWatch 경보를 구성합니다. + 수동 검증 - 평가 기간을 사용하여 계속하기 전에 로그, 지표 및 사용자 피드백을 수동으로 검토합니다. ### 카나리 배포 모범 사례 서비스를 사용하여 카나리를 성공적으로 배포하려면 다음 모범 사례를 따릅니다. #### 적절한 트래픽 백분율 선택 카나리 트래픽 백분율을 선택할 경우 다음 요소를 고려합니다. + 작게 시작 - 트래픽의 5\$110%로 시작하여 문제가 발생할 경우 영향을 최소화합니다. + 애플리케이션 중요도 고려 - 미션 크리티컬 애플리케이션에는 더 작은 비율을 사용하고 덜 중요한 서비스에는 더 큰 비율을 사용합니다. + 트래픽 볼륨 고려 - 카나리 백분율이 의미 있는 검증을 위해 충분한 트래픽을 생성하는지 확인합니다. #### 적절한 평가 기간 설정 다음 고려 사항에 따라 평가 기간을 구성합니다. + 충분한 시간 허용 - 의미 있는 성능 데이터를 캡처할 수 있을 만큼 충분히 긴 평가 기간을 설정합니다. 일반적으로 10\$130분입니다. + 트래픽 패턴 고려 - 애플리케이션의 트래픽 패턴과 최대 사용 시간을 고려합니다. + 속도 및 안전의 균형 - 평가 기간이 길수록 더 많은 데이터를 제공하지만 배포 속도는 느립니다. #### 포괄적인 모니터링 구현 카나리 배포 성능을 추적하도록 모니터링을 설정합니다. + 주요 지표 - 두 작업 세트의 응답 시간, 오류율, 처리량 및 리소스 사용률을 모니터링합니다. + 경보 기반 롤백 - 지표가 임계치를 초과할 때 롤백을 자동으로 트리거하도록 CloudWatch 경보를 구성합니다. + 비교 분석 - 원래 버전과 카나리 버전 간의 지표를 나란히 비교하도록 대시보드를 설정합니다. + 비즈니스 지표 - 기술 지표와 함께 전환율 또는 사용자 참여와 같은 비즈니스별 지표를 포함합니다. #### 롤백 전략 계획 다음 전략으로 잠재적 롤백 시나리오를 준비합니다. + 자동화된 롤백 - 상태 확인 및 성능 지표를 기반으로 자동 롤백 트리거를 구성합니다. + 수동 롤백 절차 - 자동화된 트리거가 모든 문제를 캡처하지 않는 경우 수동 롤백에 대한 명확한 절차를 문서화합니다. + 롤백 테스트 - 롤백 절차를 정기적으로 테스트하여 필요할 때 올바르게 작동하는지 확인합니다. #### 배포 전에 철저히 검증 카나리 배포를 진행하기 전에 철저하게 검증합니다. + 사전 배포 테스트 - 카나리 배포 전에 스테이징 환경의 변경 사항을 철저히 테스트합니다. + 상태 확인 구성 - 상태 확인이 애플리케이션 준비 상태 및 기능을 정확하게 반영하는지 확인합니다. + 종속성 검증 - 새 버전이 다운스트림 및 업스트림 서비스와 호환되는지 확인합니다. + 데이터 일관성 - 데이터베이스 스키마 변경 및 데이터 마이그레이션이 이전 버전과 호환되는지 확인합니다. #### 팀 참여 조정 카나리 배포 중에 효과적인 팀 조정을 보장합니다. + 배포 기간 - 팀이 모니터링하고 대응할 수 있는 업무 시간 중에 카나리 배포를 예약합니다. + 통신 채널 - 배포 상태 및 문제 에스컬레이션을 위한 명확한 통신 채널을 설정합니다. + 역할 할당 - 모니터링, 의사 결정 및 롤백 실행에 대한 역할과 책임을 정의합니다. # Amazon ECS 카나리 배포에 필요한 리소스 관리형 트래픽 전환을 통해 카나리 배포를 사용하려면 서비스에서 다음 기능 중 하나를 사용해야 합니다. + Elastic Load Balancing + Service Connect 다음 목록은 Amazon ECS 카나리 배포를 위해 구성해야 하는 사항에 대한 개략적인 개요를 제공합니다. + 서비스는 Application Load Balancer, Network Load Balancer 또는 Service Connect를 사용합니다. 적절한 리소스를 구성합니다. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. + Service Connect - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스](service-connect-blue-green.md) 섹션을 참조하세요. + 서비스 배포 컨트롤러를 `ECS`로 설정합니다. + 서비스 정의에서 `canary`으로 배포 전략을 구성합니다. + 선택적으로 다음과 같은 추가 파라미터를 구성합니다. + 새 배포를 위한 베이크 소요 시간 + 카나리 단계에서 새 서비스 개정으로 라우팅할 트래픽의 백분율. + 남은 트래픽을 새 서비스 개정으로 이전하기 전에 카나리 단계에서 대기하는 기간. + 자동 롤백에 대한 CloudWatch 경보 + 배포 수명 주기 후크(지정된 배포 단계에서 실행되는 Lambda 함수) ## 모범 사례 성공적인 Amazon ECS 카나리 배포를 위해 다음 모범 사례를 따릅니다. + **애플리케이션이 동시에 실행되는 서비스 개정을 모두 처리할 수 있는지 확인합니다.** + **배포 중에 두 서비스 개정을 모두 처리할 수 있는 충분한 클러스터 용량을 계획합니다.** + **프로덕션 환경에서 롤백 프로시저를 구현하기 전에 테스트합니다.** + 애플리케이션 상태를 정확하게 반영하는 적절한 상태 확인을 구성합니다. + 그린 배포를 충분히 테스트할 수 있는 베이크 소요 시간을 설정합니다. + CloudWatch 경보를 구현하여 문제를 자동으로 감지하고 롤백을 트리거합니다. + 수명 주기 후크를 사용하여 각 배포 단계에서 자동화된 테스트를 수행합니다. + 문제가 발생할 경우 영향을 최소화하려면 작은 카나리 백분율(5\$110%)로 시작합니다. + 의미 있는 성능 데이터 수집을 위해 충분한 시간을 허용하는 적절한 평가 기간을 설정합니다. + 자동화된 롤백 트리거에 대한 CloudWatch 경보를 사용하여 포괄적인 모니터링을 구현합니다. + 애플리케이션의 준비 상태 및 기능을 정확하게 반영하는 상태 확인을 구성합니다. + 평가 중에 기술 지표(응답 시간, 오류율)와 비즈니스 지표를 모두 모니터링합니다. + 애플리케이션이 세션 또는 상태 문제 없이 트래픽 분할을 처리할 수 있는지 확인합니다. + 롤백 절차를 계획하고 정기적으로 테스트하여 필요할 때 작동하는지 확인합니다. + 팀이 모니터링하고 대응할 수 있는 업무 시간 중에 카나리 배포를 예약합니다. + 카나리 배포 전에 스테이징 환경에서 변경 사항을 철저히 검증합니다. + 수동 개입 및 롤백 결정을 위한 명확한 절차를 문서화합니다. # Amazon ECS 카나리 배포 생성 Amazon ECS 카나리 배포를 사용하면 소량의 트래픽을 새 서비스 개정('카나리')으로 이전할 수 있습니다. 배포를 검증한 다음 지정된 간격 후 나머지 트래픽을 한 번에 모두 이전합니다. 이 접근 방식을 사용하면 전체 배포 전에 위험을 최소화하면서 새 기능을 테스트할 수 있습니다. ## 사전 조건 카나리 배포를 시작하기 전에 다음 작업을 수행합니다. 1. 적절한 권한을 구성하세요. + Elastic Load Balancing 권한에 대한 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. + Lambda 권한에 대한 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. 1. Amazon ECS 카나리 배포에서는 서비스가 다음 기능 중 하나를 사용해야 합니다. 적절한 리소스를 구성하세요. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. + Service Connect - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스](service-connect-blue-green.md) 섹션을 참조하세요. ## 절차 콘솔 또는 AWS CLI를 사용하여 Amazon ECS 카나리 배포 서비스를 생성할 수 있습니다. ------ #### [ Console ] 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. 서비스를 시작할 리소스를 결정합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-canary-service.html) **서비스 생성** 페이지가 표시됩니다. 1. **서비스 세부 정보**에서 다음을 수행합니다. 1. **태스크 정의**에서 사용할 태스크 정의 패밀리 및 개정을 선택하세요. 그런 다음 **태스크 정의 개정**에 사용할 개정을 입력하세요. 1. **서비스 이름(Service name)**에 서비스의 이름을 입력합니다. 1. 기존 클러스터에서 서비스를 실행하려면 **기존 클러스터**에서 클러스터를 선택하세요. 새 클러스터에서 서비스를 실행하려면 **클러스터 생성**을 선택하세요. 1. 클러스터 인프라에 태스크를 배포하는 방식을 선택합니다. **컴퓨팅 구성**에서 옵션을 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-canary-service.html) 1. **배포 구성**에서 다음을 수행합니다. 1. **서비스 유형**에서 **복제본**을 선택하세요. 1. **원하는 작업(Desired tasks)**에 서비스에서 시작 및 유지 관리할 작업 수를 입력합니다. 1. Amazon ECS에서 가용 영역 전체의 태스크 분산을 모니터링하고 불균형이 있을 때 재분산하려면 **가용 영역 서비스 리밸런싱**에서 **가용 영역 서비스 리밸런싱**을 선택하세요. 1. **상태 확인 유예 기간**에 태스크가 처음 시작된 후 서비스 스케줄러가 비정상 Elastic Load Balancing, VPC Lattice, 컨테이너 상태 확인을 무시하는 시간(초)을 입력하세요. 상태 확인 유예 기간 값을 지정하지 않으면 기본값인 0이 사용됩니다. 1. **배포 구성**에서 카나리 배포 설정을 구성하세요. 1. **배포 전략**에서 **카나리**를 선택하세요. 1. **카나리 백분율**에 첫 번째 단계에서 그린 서비스 개정으로 이전할 트래픽 백분율을 입력하세요(예: 초기 카나리 트래픽의 경우 10%). 1. **카나리 베이크 소요 시간**에 남은 트래픽을 그린 서비스 개정으로 이전하기 전에 대기할 시간(분)을 입력하세요. 1. **베이크 소요 시간**에 최종 트래픽 이전 후 블루 개정이 종료되기 전에 블루 및 그린 서비스 개정이 동시에 실행되는 시간(분)을 입력하세요. 1. (선택 사항) 배포의 특정 단계에서 실행할 Lambda 함수를 실행하세요. **배포 수명 주기 후크**에서 수명 주기 후크를 실행할 단계를 선택하세요. 수명 주기 후크를 추가하는 방법: 1. **추가**를 선택합니다. 1. **Lambda 함수**에서 함수 이름 또는 ARN을 입력하세요. 1. **역할**에서 Lambda 함수를 간접 호출할 권한이 있는 IAM 역할을 선택하세요. 1. **수명 주기 단계**에서 Lambda 함수를 실행해야 하는 단계를 선택하세요. 1. Amazon ECS에서 배포 오류를 탐지 및 처리하는 방법을 구성하려면 **배포 오류 탐지(Deployment failure detection)**를 펼친 다음, 옵션을 선택합니다. 1. 작업을 시작할 수 없을 때 배포를 중지하려면 **Use the Amazon ECS deployment circuit breaker**(Amazon ECS 배포 회로 차단기 사용)를 선택합니다. 배포 회로 차단기가 배포를 실패한 상태로 설정했을 때 소프트웨어가 마지막으로 완료한 배포로 자동 롤백하도록 하려면 **실패 시 롤백**을 선택합니다. 1. 애플리케이션 지표를 기반으로 배포를 중지하려면 **CloudWatch 경보 사용**을 선택합니다. 그런 다음, **CloudWatch 경보 이름**에서 경보를 선택합니다. 새 경보를 생성하려면 CloudWatch 콘솔을 이동합니다. CloudWatch 경보가 배포를 실패한 상태로 설정할 때 소프트웨어가 마지막으로 완료한 배포 상태로 자동 롤백하도록 하려면 **실패 시 롤백**을 선택합니다. 1. (선택 사항) Service Connect를 사용하여 서비스를 상호 연결하려면 **Service Connect**를 확장한 후 다음을 지정하세요. 1. **Service Connect 켜기**를 선택합니다. 1. **Service Connect configuration**(Service Connect 구성)에서 클라이언트 모드를 지정합니다. + 서비스에서 네임스페이스의 다른 서비스에만 연결하면 되는 네트워크 클라이언트 애플리케이션을 실행하는 경우 **클라이언트 측만**을 선택합니다. + 서비스가 네트워크 또는 웹 서비스 애플리케이션을 실행하고 이 서비스에 대한 엔드포인트를 제공해야 하며, 네임스페이스의 다른 서비스에 연결해야 하는 경우 **Client and server**(클라이언트 및 서버)를 선택합니다. 1. 기본 클러스터 네임스페이스가 아닌 네임스페이스를 사용하려면 **Namespace**(네임스페이스)에서 서비스 네임스페이스를 선택합니다. 이는 AWS 계정의 동일한 AWS 리전에서 별도로 생성된 네임스페이스 또는 AWS Resource Access Manager(AWS RAM)를 사용하여 계정과 공유되는 동일한 리전의 네임스페이스일 수 있습니다. 공유 AWS Cloud Map 네임스페이스에 대한 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)을 참조하세요. 1. (선택 사항) 카나리 배포에 대한 테스트 트래픽 헤더 규칙을 구성하세요. **테스트 트래픽 라우팅**에서 다음을 지정하세요. 1. 테스트 중에 특정 요청을 그린 서비스 개정으로 라우팅하려면 **테스트 트래픽 헤더 규칙 활성화**를 선택하세요. 1. **헤더 일치 규칙**에서 테스트 트래픽 라우팅 기준을 구성하세요. + **헤더 이름**: 일치시킬 HTTP 헤더의 이름을 입력합니다(예: `X-Test-Version` 또는 `User-Agent`). + **일치 유형**: 일치 기준을 선택합니다. + **정확한 일치**: 헤더 값이 지정된 값과 정확히 일치하는 요청을 라우팅합니다. + **헤더 있음**: 값에 관계없이 지정된 헤더를 포함하는 라우팅 요청 + **패턴 일치**: 헤더 값이 지정된 패턴과 일치하는 요청 라우팅 + **헤더 값**(정확한 일치 또는 패턴 일치를 사용하는 경우): 일치시킬 값 또는 패턴을 입력합니다. 여러 헤더 일치 규칙을 추가하여 복잡한 라우팅 로직을 생성할 수 있습니다. 구성된 규칙과 일치하는 요청은 테스트를 위해 그린 서비스 개정으로 라우팅됩니다. 1. **헤더 규칙 추가**를 선택하여 추가 헤더 일치 조건을 구성하세요. **참고** 테스트 트래픽 헤더 규칙을 사용하면 전체 배포를 완료하기 전에 트래픽을 제어하며 새 기능을 검증할 수 있습니다. 이를 통해 블루 서비스 개정으로 정상적인 트래픽 흐름을 유지하면서 특정 요청(예: 내부 테스트 도구 또는 베타 사용자의 요청)으로 그린 서비스 개정을 테스트할 수 있습니다. 1. (선택 사항) 로그 구성을 지정합니다. **로그 수집 사용**을 선택합니다. 기본 옵션은 CloudWatch Logs로 컨테이너 로그를 전송합니다. 다른 로그 드라이버 옵션은 AWS FireLens를 사용하여 구성됩니다. 자세한 정보는 [Amazon ECS 로그를 AWS 서비스 또는 AWS Partner로 전송](using_firelens.md)을 참조하세요. 다음은 각 컨테이너 로그 대상에 대한 자세한 설명입니다. + **Amazon CloudWatch** - CloudWatch Logs로 컨테이너 로그를 전송하도록 작업을 구성합니다. 사용자를 대신하여 CloudWatch 로그 그룹을 생성하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 로그 그룹 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon Data Firehose** - Firehose로 컨테이너 로그를 전송하도록 작업을 구성합니다. Firehose 전송 스트림으로 로그를 전송하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 전송 스트림 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon Kinesis Data Streams** - Kinesis Data Streams로 컨테이너 로그를 전송하도록 작업을 구성합니다. Kinesis Data Streams 스트림으로 로그를 전송하는 기본 로그 드라이버 옵션이 제공됩니다. 다른 스트림 이름을 지정하려면 드라이버 옵션 값을 변경합니다. + **Amazon OpenSearch Service** - OpenSearch Service 도메인으로 컨테이너 로그를 전송하도록 작업을 구성합니다. 로그 드라이버 옵션이 제공되어야 합니다. + **Amazon S3** - Amazon S3 버킷으로 컨테이너 로그를 전송하도록 작업을 구성합니다. 기본 로그 드라이버 옵션이 제공되지만 유효한 Amazon S3 버킷 이름을 지정해야 합니다. 1. (선택 사항) 카나리 배포를 위한 **로드 밸런싱**을 구성하세요. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/deploy-canary-service.html) 1. (선택 사항) 서비스와 태스크를 식별하려면 **태그(Tags)** 섹션을 펼친 다음, 태그를 구성합니다. Amazon ECS에서 새로 시작된 모든 작업에 클러스터 이름과 작업 정의 태그를 자동으로 지정하도록 하려면 **Amazon ECS 관리형 태그 켜기**를 선택한 다음 **작업 전파 시작**에서 **작업 정의**를 선택합니다. Amazon ECS에서 새로 시작된 모든 작업에 클러스터 이름과 서비스 태그를 자동으로 지정하도록 하려면 **Amazon ECS 관리형 태그 켜기**를 선택한 다음 **작업 전파 시작**에서 **서비스**를 선택합니다. 태그를 추가하거나 제거합니다. + [태그 추가] **새로운 태그(Add tag)**를 선택하고 다음을 수행합니다. + **키**에서 키 이름을 입력합니다. + **값**에 키 값을 입력합니다. + [태그 제거] 태그 옆에 있는 **태그 제거**를 선택합니다. 1. **생성(Create)**을 선택합니다. ------ #### [ AWS CLI ] 1. 다음 콘텐츠가 포함된 `canary-service-definition.json`이라는 파일을 생성합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. ``` { "serviceName": "myCanaryService", "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster", "taskDefinition": "sample-fargate:1", "desiredCount": 5, "launchType": "FARGATE", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "subnet-09ce6e74c116a2299", "subnet-00bb3bd7a73526788", "subnet-0048a611aaec65477" ], "securityGroups": [ "sg-09d45005497daa123" ], "assignPublicIp": "ENABLED" } }, "deploymentController": { "type": "ECS" }, "deploymentConfiguration": { "strategy": "CANARY", "maximumPercent": 200, "minimumHealthyPercent": 100, "canaryConfiguration" : { "canaryPercent" : 5.0, "canaryBakeTime" : 10 }, "bakeTimeInMinutes": 10, "alarms": { "alarmNames": [ "myAlarm" ], "rollback": true, "enable": true } }, "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197", "containerName": "fargate-app", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199", "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911", "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS" } } ] } ``` 1. `create-service`를 실행합니다. ``` aws ecs create-service --cli-input-json file://canary-service-definition.json ``` ------ ## 다음 단계 카나리 배포를 구성한 후 다음 단계를 완료합니다. + 배포를 시작하도록 서비스를 업데이트합니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. + 배포 프로세스를 모니터링하여 카나리 패턴을 따르는지 확인합니다. + 그린 서비스 개정이 생성되고 스케일 업됨 + 소량의 트래픽(카나리)이 그린 개정으로 이전됩니다. + 시스템이 지정된 카나리 간격을 기다립니다. + 나머지 트래픽은 모두 한 번에 그린 개정으로 이전합니다. + 베이크 소요 시간이 지나면 블루 개정이 종료됨 ## 배포 용어 다음 용어는 Amazon ECS 배포 설명서 전체에서 사용됩니다. 블루/그린 배포 기존 환경(블루)과 함께 새 환경(그린)을 생성한 다음 검증 후 트래픽을 블루에서 그린으로 이전하는 배포 전략. 카나리 배포 검증을 위해 안정적인 버전에서 대부분을 유지하면서 소량의 트래픽을 새 버전으로 라우팅하는 배포 전략. 선형 배포 시간이 지남에 따라 트래픽을 동일한 증분으로 이전 버전에서 새 버전으로 점진적으로 이전하는 배포 전략. 롤링 배포 이전 버전의 인스턴스를 한 번에 하나씩 새 버전의 인스턴스로 교체하는 배포 전략. 작업 세트 배포 중에 서비스 내에서 동일한 태스크 정의를 실행하는 태스크 모음. 대상 그룹 배포 중에 로드 밸런서로부터 트래픽을 수신하는 대상의 논리적 그룹. 배포 컨트롤러 Amazon ECS, CodeDeploy 또는 외부 컨트롤러와 같은 서비스의 새 버전을 배포하는 데 사용되는 방법. 롤백 배포 중에 문제가 감지되면 이전 버전의 애플리케이션으로 되돌리는 프로세스. # 타사 컨트롤러를 사용한 Amazon ECS 서비스 배포 *외부* 배포 유형을 사용하면 타사 배포 컨트롤러를 사용하여 Amazon ECS 서비스의 배포 프로세스를 완벽하게 제어할 수 있습니다. 서비스에 대한 세부 정보는 서비스 관리 API 작업(`CreateService`, `UpdateService` 및 `DeleteService`) 또는 작업 세트 관리 API 작업(`CreateTaskSet`, `UpdateTaskSet`, `UpdateServicePrimaryTaskSet` 및 `DeleteTaskSet`)에 의해 관리됩니다. 각 API 작업은 서비스 정의 파라미터의 하위 집합을 관리합니다. `UpdateService` API 동작은 서비스의 원하는 개수 및 상태 확인 유예 기간 파라미터를 업데이트합니다. 컴퓨팅 옵션, 플랫폼 버전, 로드 밸런서 세부 정보, 네트워크 구성 또는 태스크 정의를 업데이트해야 하는 경우 새 태스크 세트를 생성해야 합니다. `UpdateTaskSet` API 태스크는 작업 세트의 배율 파라미터만 업데이트합니다. `UpdateServicePrimaryTaskSet` API 태스크는 서비스의 어떤 작업 세트가 기본 작업 세트인지 수정합니다. `DescribeServices` API 태스크를 호출하면 기본 작업 세트에 대해 지정된 모든 필드를 반환합니다. 서비스에 대한 기본 작업 세트가 업데이트되면 새 기본 작업 세트가 정의될 때 서비스에 설정된 이전 기본 작업 세트와 다른 새 기본 작업 세트에 있는 작업 세트 파라미터 값이 새 값으로 업데이트됩니다. 서비스에 대한 기본 작업 세트가 정의되지 않은 경우, 서비스를 설명할 때 작업 세트 필드가 null입니다. ## 외부 배포 고려 사항 외부 배포 유형을 사용할 때는 다음 사항을 고려합니다. + 지원되는 로드 밸런서 유형은 Application Load Balancer 또는 Network Load Balancer입니다. + Fargate나 `EXTERNAL` 배포 컨트롤러 유형을 사용하는 태스크는 `DAEMON` 일정 전략을 지원하지 않습니다. + Amazon ECS와의 Application AutoScaling 통합은 Amazon ECS 서비스만 대상으로 지원합니다. Amazon ECS에 대해 지원되는 확장 가능 차원은 `ecs:service:DesiredCount`(Amazon ECS 서비스의 태스크 수)입니다. Application AutoScaling과 Amazon ECS 태스크 세트 사이에서 직접적인 통합이 없습니다. Amazon ECS 태스크 세트는 Amazon ECS 서비스 `DesiredCount`에 기반하여 `ComputedDesiredCount`를 계산합니다. ## 외부 배포 워크플로 다음은 Amazon ECS에서 외부 배포를 관리하기 위한 기본 워크플로입니다. **외부 배포 컨트롤러를 사용하여 Amazon ECS 서비스를 관리하려면** 1. Amazon ECS 서비스를 생성합니다. 이때는 서비스 이름 파라미터만 있으면 됩니다. 외부 배포 컨트롤러를 사용하여 서비스를 생성할 때 다음 파라미터를 지정할 수 있습니다. 다른 모든 서비스 파라미터는 서비스 내에 작업 세트를 생성할 때 지정됩니다. `serviceName` 유형: 문자열 필수 항목 여부: 예 서비스의 이름입니다. 최대 255개의 문자(대문자 및 소문자), 숫자, 하이픈 및 밑줄이 허용됩니다. 서비스 이름은 클러스터 내에서 고유해야 하지만, 한 리전 또는 여러 리전에 걸쳐 존재하는 여러 클러스터에서 비슷한 서비스 이름을 사용할 수 있습니다. `desiredCount` 서비스 내에 배포되어 실행되도록 지정된 작업 세트 태스크 정의의 인스턴스 수입니다. `deploymentConfiguration` 배포 시 실행할 작업 수 및 작업 중지/시작 순서를 제어하는 선택적 배포 파라미터입니다. `tags` 타입: 객체 배열 필수 여부: 아니요 서비스를 분류하고 구성하는 데 도움이 되도록 서비스에 적용하는 메타데이터입니다. 각 태그는 사용자가 정의하는 키와 선택적 값으로 구성됩니다. 서비스가 삭제되면 태그도 함께 삭제됩니다. 서비스에 최대 50개의 태그를 적용할 수 있습니다. 자세한 내용은 [Amazon ECS 리소스 태그 지정](ecs-using-tags.md) 섹션을 참조하세요. 서비스를 업데이트할 때 이 파라미터는 새 서비스 배포를 트리거하지 않습니다. `key` 유형: 문자열 길이 제약: 최소 길이는 1. 최대 길이는 128입니다. 필수 여부: 아니요 하나의 태그를 구성하는 키-값 쌍의 일부분입니다. 키는 더 구체적인 태그 값에 대해 범주와 같은 역할을 하는 일반적인 레이블입니다. `value` 유형: 문자열 길이 제약: 최소 길이는 0. 최대 길이 256. 필수 여부: 아니요 하나의 태그를 구성하는 키-값 쌍의 선택적 부분입니다. 하나의 값은 태그 범주(키) 내에서 서술자 역할을 수행합니다. `enableECSManagedTags` 서비스 내의 태스크에 대해 Amazon ECS 관리형 태그를 사용할지를 지정합니다. 자세한 정보는 [결제에 태그 사용](ecs-using-tags.md#tag-resources-for-billing)을 참조하세요. `propagateTags` 유형: 문자열 유효한 값: `TASK_DEFINITION` \$1 `SERVICE` 필수 여부: 아니요 태그를 태스크 정의 또는 서비스에서 서비스의 작업으로 복사할지를 지정합니다. 값을 지정하지 않을 경우 태그는 복사되지 않습니다. 태그는 서비스 생성 중에 서비스 내의 작업에만 복사할 수 있습니다. 서비스 생성 후 작업 생성에 태그를 추가하려면 `TagResource` API 태스크를 사용합니다. 서비스를 업데이트할 때 이 파라미터는 새 서비스 배포를 트리거하지 않습니다. `schedulingStrategy` 사용할 일정 전략입니다. 외부 배포 컨트롤러를 사용하는 서비스는 `REPLICA` 일정 전략만 지원합니다. `placementConstraints` 서비스 내 작업에 사용할 배치 제약 객체의 배열입니다. 작업당 최대 10개의 제약을 지정할 수 있습니다(이 제한에는 태스크 정의 내 제약과 런타임 시 지정되는 제약이 포함됨). Fargate를 사용하는 경우 태스크 배치 제약은 지원되지 않습니다. `placementStrategy` 서비스 내 작업에 사용할 배치 전략 객체입니다. 서비스당 최대 4개까지 전략 규칙을 지정할 수 있습니다. 다음은 외부 배포 컨트롤러를 사용하는 서비스를 생성하기 위한 예제 서비스 정의입니다. ``` { "cluster": "", "serviceName": "", "desiredCount": 0, "role": "", "deploymentConfiguration": { "maximumPercent": 0, "minimumHealthyPercent": 0 }, "placementConstraints": [ { "type": "distinctInstance", "expression": "" } ], "placementStrategy": [ { "type": "binpack", "field": "" } ], "schedulingStrategy": "REPLICA", "deploymentController": { "type": "EXTERNAL" }, "tags": [ { "key": "", "value": "" } ], "enableECSManagedTags": true, "propagateTags": "TASK_DEFINITION" } ``` 1. 초기 작업 세트를 생성합니다. 작업 세트에는 서비스에 대한 다음 세부 정보가 들어 있습니다. `taskDefinition` 사용할 작업 세트의 작업에 대한 태스크 정의입니다. `launchType` 유형: 문자열 유효한 값: `EC2` \$1 `FARGATE` \$1 `EXTERNAL` 필수 여부: 아니요 서비스를 실행할 시작 유형. 시작 유형을 지정하지 않으면 기본적으로 `capacityProviderStrategy`가 사용됩니다. 서비스를 업데이트할 때 이 파라미터는 새 서비스 배포를 트리거합니다. `launchType`이 지정된 경우 `capacityProviderStrategy` 파라미터를 생략해야 합니다. `platformVersion` 유형: 문자열 필수 여부: 아니요 서비스의 작업이 실행 중인 플랫폼 버전입니다. 플랫폼 버전은 Fargate 시작 유형을 사용하는 작업에만 지정됩니다. 지정하지 않으면 기본적으로 최신 버전(`LATEST`)이 사용됩니다. 서비스를 업데이트할 때 이 파라미터는 새 서비스 배포를 트리거합니다. AWS Fargate 플랫폼 버전은 Fargate 태스크 인프라를 위한 특정 실행 시간 환경을 참조하는 데 사용합니다. 태스크를 실행하거나 서비스를 생성할 때 `LATEST` 플랫폼 버전을 지정하면 해당 작업에 사용 가능한 최신 플랫폼 버전을 얻을 수 있습니다. 서비스를 확장하면 해당 태스크는 서비스의 현재 배포에 지정된 플랫폼 버전을 받습니다. 자세한 내용은 [Amazon ECS에 대한 Fargate 플랫폼 버전](platform-fargate.md) 섹션을 참조하세요. 플랫폼 버전은 EC2 시작 유형을 사용하는 작업에는 지정되지 않습니다. `loadBalancers` 서비스와 함께 사용할 로드 밸런서를 나타내는 로드 밸런서 객체입니다. 외부 배포 컨트롤러를 사용하는 경우 Application Load Balancer 및 Network Load Balancer만 지원됩니다. Application Load Balancer를 사용하는 경우 작업 세트당 하나의 Application Load Balancer 대상 그룹만 허용됩니다. 다음 조각은 사용할 `loadBalancer` 객체의 예제를 보여줍니다. ``` "loadBalancers": [ { "targetGroupArn": "", "containerName": "", "containerPort": 0 } ] ``` `loadBalancer` 객체를 지정할 때는 `targetGroupArn`을 지정하고 `loadBalancerName` 파라미터를 생략해야 합니다. `networkConfiguration` 서비스에 대한 네트워크 구성. 이 파라미터는 `awsvpc` 네트워크 모드를 사용하는 태스크 정의가 고유한 탄력적 네트워크 인터페이스를 받는 데 필요하며 다른 네트워크 모드에 대해서는 지원되지 않습니다. Fargate의 네트워킹에 대한 자세한 내용은 [Fargate에 대한 Amazon ECS 태스크 네트워킹 옵션](fargate-task-networking.md) 섹션을 참조하세요. `serviceRegistries` 이 서비스에 할당할 서비스 검색 레지스트리의 세부 정보입니다. 자세한 정보는 [서비스 검색을 사용하여 Amazon ECS 서비스를 DNS 이름으로 연결](service-discovery.md) 섹션을 참조하세요. `scale` 작업 세트에 배치하고 실행하려는 작업 수의 부동 소수점 백분율입니다. 이 값은 서비스의 `desiredCount`에 대한 총 백분율로 지정됩니다. 허용되는 값은 0과 100 사이의 숫자입니다. 다음은 외부 배포 컨트롤러에 대한 작업 세트를 생성하기 위한 JSON 예제입니다. ``` { "service": "", "cluster": "", "externalId": "", "taskDefinition": "", "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "" ], "securityGroups": [ "" ], "assignPublicIp": "DISABLED" } }, "loadBalancers": [ { "targetGroupArn": "", "containerName": "", "containerPort": 0 } ], "serviceRegistries": [ { "registryArn": "", "port": 0, "containerName": "", "containerPort": 0 } ], "launchType": "EC2", "capacityProviderStrategy": [ { "capacityProvider": "", "weight": 0, "base": 0 } ], "platformVersion": "", "scale": { "value": null, "unit": "PERCENT" }, "clientToken": "" } ``` 1. 서비스 변경이 필요한 경우 업데이트 중인 파라미터에 따라 `UpdateService`, `UpdateTaskSet` 또는 `CreateTaskSet` API 태스크를 사용합니다. 작업 세트를 만든 경우 서비스의 각 작업 세트에 대해 `scale` 파라미터를 사용하여 서비스에서 실행 중인 작업 수를 결정합니다. 예를 들어, `tasksetA`가 포함된 서비스가 있고 `tasksetB`를 생성한 경우 프로덕션 트래픽을 전환하기 전에 `tasksetB`의 유효성을 테스트할 수 있습니다. 두 작업 세트의 `scale`을 `100`으로 설정할 수 있으며 모든 프로덕션 트래픽을 `tasksetB`로 전환할 준비가 되면 `tasksetA`의 `scale`을 `0`으로 업데이트하여 축소할 수 있습니다. # Amazon ECS에 대한 CodeDeploy 블루/그린 배포 Amazon ECS 블루/그린 배포를 사용하는 것이 좋습니다. 자세한 내용은 [Amazon ECS 블루/그린 배포 생성](deploy-blue-green-service.md) 섹션을 참조하세요. *블루/그린* 배포 유형은 CodeDeploy로 제어되는 블루/그린 배포 모델을 사용합니다. 이 배포 유형을 사용하면 프로덕션 트래픽을 전송하기 전에 서비스의 새로운 배포를 확인합니다. 자세한 내용은 *AWS CodeDeploy 사용 설명서*의 [CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)를 참조하세요.배포 전에 Amazon ECS 서비스의 상태 확인 블루/그린 배포 중 트래픽을 이동할 수 있는 세 가지 방법이 있습니다. + **Canary**: 트래픽이 두 증분으로 나뉘어 이동합니다. 나머지 트래픽이 두 번째 증분으로 이동하기 전에 첫 번째 증분에서 업데이트된 작업 세트로 이동할 트래픽 비율(%)과 간격(분)을 지정하는 사전 정의된 Canary 옵션 중에서 선택할 수 있습니다. + **Linear**: 트래픽이 동일한 증분 이동하며 각 증분 간에 시간 간격(분)이 동일합니다. 각 증분에서 이동되는 트래픽 비율(%)과 각 증분 간의 시간(분)을 지정하는 사전 정의된 Linear 옵션에서 선택할 수 있습니다. + **All-at-once**: 모든 트래픽이 원래 작업 세트에서 업데이트된 작업 세트로 모두 한 번에 이동합니다. 서비스가 블루/그린 배포 유형을 사용할 때 Amazon ECS가 사용하는 CodeDeploy의 구성 요소들은 다음과 같습니다. **CodeDeploy 애플리케이션** CodeDeploy 리소스 컬렉션. 이것은 하나 이상의 배포 그룹으로 구성됩니다. **CodeDeploy 배포 그룹** 배포 설정. 이것은 다음과 같은 요소로 구성됩니다. + Amazon ECS 클러스터와 서비스 + 로드 밸런서 대상 그룹 및 리스너 정보 + 배포 롤백 전략 + 트래픽 다시 라우팅 설정 + 원래 개정 종료 설정 + 배포 구성 + 배포를 중지하도록 설정할 수 있는 CloudWatch 경보 구성 + SNS 또는 CloudWatch Events 알림 설정 자세한 정보는 *AWS CodeDeploy 사용 설명서*의 [배포 그룹으로 작업](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)을 참조하세요. **CodeDeploy 배포 구성** CodeDeploy가 배포 중 프로덕션 트래픽을 교체 작업 세트로 라우팅하는 방법을 지정합니다. 다음과 같은 사전 정의된 Linear 및 Canary 배포 구성을 사용할 수 있습니다. 사용자 정의 Linear 및 Canary 배포도 생성할 수 있습니다. 자세한 정보는 *AWS CodeDeploy 사용 설명서*의 [배포 구성으로 작업](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)을 참조하세요. + **CodeDeployDefault.ECSAllAtOnce**: 모든 트래픽을 업데이트된 Amazon ECS 컨테이너로 한 번에 이동합니다. + **CodeDeployDefault.ECSLinear10PercentEvery1Minutes**: 모든 트래픽이 이동할 때까지 매분 트래픽의 10%를 이동합니다. + **CodeDeployDefault.ECSLinear10PercentEvery3Minutes**: 모든 트래픽이 이동할 때까지 3분마다 트래픽의 10%를 이동합니다. + **CodeDeployDefault.ECSCanary10Percent5Minutes**: 첫 번째 증분에서 트래픽의 10%를 이동합니다. 나머지 90%는 5분 이후 배포됩니다. + **CodeDeployDefault.ECSCanary10Percent15Minutes**: 첫 번째 증분에서 트래픽의 10%를 이동합니다. 나머지 90%는 15분 이후 배포됩니다. **개정** 개정은 CodeDeploy 애플리케이션 사양 파일(AppSpec 파일)입니다. AppSpec 파일에서 태스크 정의의 전체 ARN을 지정하고, 새 배치가 생성될 때 트래픽이 라우팅되는 대상에 해당하는 교체 작업 세트의 컨테이너 및 포트도 지정합니다. 컨테이너 이름은 태스크 정의에서 참조되는 컨테이너 이름 중 하나여야 합니다. 서비스 정의에서 네트워크 구성 또는 플랫폼 버전이 업데이트된 경우, AppSpec 파일에서도 해당 세부 정보를 지정해야 합니다. 배포 수명 주기 이벤트 중에 실행할 Lambda 함수를 지정할 수도 있습니다. Lambda 함수를 사용하면 배포 중에 테스트를 실행하고 지표를 반환할 수 있습니다. 자세한 정보는 *AWS CodeDeploy 사용 설명서*의 [AppSpec 파일 참조](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html)를 참조하세요. ## 고려 사항 블루/그린 배포 유형 사용 시 고려할 몇 가지 사항들은 다음과 같습니다. + 블루/그린 배포 유형을 사용하는 Amazon ECS 서비스가 맨 처음 생성되면 Amazon ECS 작업 세트가 생성됩니다. + Application Load Balancer 또는 Network Load Balancer를 사용하도록 서비스를 구성해야 합니다. 로드 밸런서의 요구 사항들은 다음과 같습니다. + 프로덕션 트래픽을 라우팅하는 데 사용되는 로드 밸런서에 프로덕션 리스너를 추가해야 합니다. + 테스트 트래픽을 라우팅하는 데 사용되는 로드 밸런서에는 테스트 리스너(선택 사항)를 추가해야 합니다. 테스트 리스너를 지정하면 CodeDeploy는 배포 중에 테스트 트래픽을 교체 작업 세트로 라우팅합니다. + 프로덕션 및 테스트 리스너는 모두 동일한 로드 밸런서에 속해야 합니다. + 로드 밸런서에 대한 대상 그룹을 정의해야 합니다. 대상 그룹은 트래픽을 프로덕션 리스너를 통해 서비스의 원래 작업 세트로 라우팅합니다. + Network Load Balancer를 사용하는 경우 `CodeDeployDefault.ECSAllAtOnce` 배포 구성만이 지원됩니다. + 서비스 Auto Scaling 및 블루/그린 배포 유형을 사용하도록 구성된 서비스의 경우 배포 중에 Auto Scaling이 차단되지 않지만 일부 상황에서는 배포가 실패할 수 있습니다. 이 동작에 대한 자세한 설명은 아래와 같습니다. + 서비스가 조정되고 배포가 시작되면 그린 작업 세트가 생성되고, CodeDeploy는 그린 작업 세트가 정상 상태에 도달하도록 최대 1시간 동안 대기하며 트래픽이 이동하지 않습니다. + 서비스가 블루/그린 배포 중이고 조정 이벤트가 발생하면 트래픽은 5분 동안 계속 이동합니다. 서비스가 5분 이내에 정상 상태에 도달하지 않으면 CodeDeploy는 배포를 중지하고 실패로 표시합니다. + Fargate이나 `CODE_DEPLOY` 배포 컨트롤러 유형을 사용하는 태스크는 `DAEMON` 일정 전략을 지원하지 않습니다. + CodeDeploy 애플리케이션 및 배포 그룹을 처음 생성할 때 다음을 지정해야 합니다. + 로드 밸런서에 대해 두 개의 대상 그룹을 정의해야 합니다. 하나의 대상 그룹은 Amazon ECS 서비스가 생성될 때 로드 밸런서에 대해 정의된 초기 대상 그룹이어야 합니다. 두 번째 대상 그룹의 유일한 요구 사항은 서비스가 사용하는 것과 다른 로드 밸런서에 연결할 수 없다는 것입니다. + Amazon ECS 서비스에 대해 CodeDeploy 배포가 생성되면 CodeDeploy는 배포에서 *교체 작업 세트*(또는 *그린 작업 세트*)를 생성합니다. 테스트 리스너를 로드 밸런서에 추가한 경우 CodeDeploy는 테스트 트래픽을 교체 작업 세트로 라우팅합니다. 이때 모든 확인 테스트를 실행할 수 있습니다. 그런 다음, CodeDeploy는 프로덕션 트래픽을 원래 작업 세트에서 배포 그룹에 대한 트래픽 다시 라우팅 설정에 따라 교체 작업 세트로 다시 라우팅합니다. ## 필수 IAM 권한 블루/그린 배포는 Amazon ECS와 CodeDeploy API의 조합으로 가능합니다. 사용자는 AWS Management Console에서 또는 AWS CLI 또는 SDK를 사용하여 Amazon ECS 블루/그린 배포를 사용하기 전에 이들 서비스에 적합한 권한이 있어야 합니다. Amazon ECS는 서비스 생성 및 업데이트를 위한 표준 IAM 권한 외에 다음과 같은 권한을 필요로 합니다. 이러한 권한은 `AmazonECS_FullAccess` IAM 정책에 추가되었습니다. 자세한 내용은 [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) 섹션을 참조하세요. + `codedeploy:CreateApplication` + `codedeploy:CreateDeployment` + `codedeploy:CreateDeploymentGroup` + `codedeploy:GetApplication` + `codedeploy:GetDeployment` + `codedeploy:GetDeploymentGroup` + `codedeploy:ListApplications` + `codedeploy:ListDeploymentGroups` + `codedeploy:ListDeployments` + `codedeploy:StopDeployment` + `codedeploy:GetDeploymentTarget` + `codedeploy:ListDeploymentTargets` + `codedeploy:GetDeploymentConfig` + `codedeploy:GetApplicationRevision` + `codedeploy:RegisterApplicationRevision` + `codedeploy:BatchGetApplicationRevisions` + `codedeploy:BatchGetDeploymentGroups` + `codedeploy:BatchGetDeployments` + `codedeploy:BatchGetApplications` + `codedeploy:ListApplicationRevisions` + `codedeploy:ListDeploymentConfigs` + `codedeploy:ContinueDeployment` + `sns:ListTopics` + `cloudwatch:DescribeAlarms` + `lambda:ListFunctions` **참고** 작업과 서비스를 실행하는 데 필요한 표준 Amazon ECS 권한 이외에, 사용자는 작업에 대한 IAM 역할을 사용하기 위한 `iam:PassRole` 권한도 필요합니다. CodeDeploy는 Amazon ECS API를 호출하고 Elastic Load Balancing을 수정하며 Lambda 함수를 호출하고 CloudWatch 경보를 설명할 수 있는 권한은 물론, 사용자를 대신하여 원하는 서비스 개수를 수정할 수 있는 권한도 필요합니다. 블루/그린 배포 유형을 사용하는 Amazon ECS 서비스를 생성하기 전에 IAM 역할(`ecsCodeDeployRole`)을 생성해야 합니다. 자세한 내용은 [Amazon ECS CodeDeploy IAM 역할](codedeploy_IAM_role.md) 섹션을 참조하세요. # CodeDeploy 블루/그린 배포를 Amazon ECS 블루/그린 배포로 마이그레이션 CodeDeploy 블루/그린 및 Amazon ECS 블루/그린 배포는 유사한 기능을 제공하지만 구성 및 관리 방법은 서로 다릅니다. ## CodeDeploy 블루/그린 배포 개요 CodeDeploy를 사용하여 Amazon ECS 서비스를 생성하는 경우 다음을 수행합니다. 1. 프로덕션 리스너 및 (선택 사항) 테스트 리스너를 사용하여 로드 밸런서를 생성합니다. 각 리스너는 모든 트래픽을 단일 대상 그룹(기본 대상 그룹)으로 라우팅하는 단일(기본) 규칙으로 구성됩니다. 1. `deploymentController` 유형이 `CODE_DEPLOY`로 설정된 리스너 및 대상 그룹을 사용하도록 구성된 Amazon ECS 서비스를 생성합니다. 서비스를 생성하면 지정된 대상 그룹에 등록된 (블루) 태스크 세트가 생성됩니다. 1. CodeDeploy 배포 그룹(CodeDeploy 애플리케이션의 일부)을 생성하고 Amazon ECS 클러스터, 서비스 이름, 로드 밸런서 리스너, 두 개의 대상 그룹(프로덕션 리스너 규칙에 사용되는 기본 대상 그룹, 대체 태스크에 사용할 보조 대상 그룹), 서비스 역할(Amazon ECS 및 Elastic Load Balancing 리소스를 조작할 수 있는 권한을 CodeDeploy에 부여), 배포 동작을 제어하는 다양한 파라미터의 세부 정보로 구성합니다. CodeDeploy를 사용하면 `CreateDeployment()`를 사용하여 새 버전의 서비스가 배포되고 이때 CodeDeploy 애플리케이션 이름, 배포 그룹 이름 및 새 개정과 선택적 수명 주기 후크에 대한 세부 정보를 제공하는 AppSpec 파일을 지정합니다. CodeDeploy 배포는 대체(그린) 태스크 세트를 생성하고 해당 태스크를 보조 대상 그룹에 등록합니다. 정상 상태가 되면 테스트(선택 사항) 및 프로덕션에서 사용할 수 있습니다. 두 경우 모두 그린 태스크 세트와 연결된 보조 대상 그룹을 가리키도록 각 리스너 규칙을 변경하여 다시 라우팅할 수 있습니다. 롤백은 프로덕션 리스너 규칙을 기본 대상 그룹으로 다시 변경하여 수행됩니다. ## Amazon ECS 블루/그린 배포 개요 Amazon ECS 블루/그린 배포의 경우 배포 구성은 Amazon ECS 서비스 자체의 일부입니다. 1. 가중치가 1과 0인 두 개의 대상 그룹을 포함하는 규칙을 사용하여 로드 밸런서 프로덕션 리스너를 사전 구성해야 합니다. 1. 다음 리소스를 지정하거나 서비스 리소스를 업데이트해야 합니다. + 이 리스너 규칙의 ARN + 두 개의 대상 그룹 + Amazon ECS에 Elastic Load Balancing API를 직접 호출할 권한을 부여하는 IAM 역할 + Lambda 함수를 실행하기 위한 선택적 IAM 역할 + `deploymentController` 유형을 `ECS`로 설정하고 `deploymentConfiguration.strategy`를 `BLUE_GREEN`으로 설정합니다. 그러면 태스크가 기본 대상 그룹에 등록된 (블루) 서비스 배포가 생성됩니다. Amazon ECS 블루/그린을 사용하면 Amazon ECS `UpdateService()`를 직접 호출하고 새 개정의 세부 정보를 전달하여 새 서비스 개정이 생성됩니다. 서비스 배포는 새 (그린) 서비스 개정 태스크를 생성하고 보조 대상 그룹에 등록합니다. Amazon ECS는 리스너 규칙의 가중치를 전환하여 재라우팅 및 롤백 작업을 처리합니다. ## 주요 구현 차이 두 접근 방식 모두 초기 태스크 세트를 생성하지만 기본 구현은 서로 다릅니다. + CodeDeploy는 태스크 세트를 사용하지만 Amazon ECS는 서비스 개정을 사용합니다. Amazon ECS 태스크 세트는 Amazon ECS 서비스 개정 및 배포로 대체된 이전 구문입니다. 후자는 배포 프로세스와 서비스 배포 및 서비스 개정 기록에 대한 더 높은 가시성을 제공합니다. + CodeDeploy를 사용하면 수명 주기 후크가 `CreateDeployment()`에 제공되는 AppSpec 파일의 일부로 지정됩니다. 즉, 후크를 한 배포에서 다음 배포로 변경할 수 있습니다. Amazon ECS 블루/그린에서는 후크가 서비스 구성의 일부로 지정되며 모든 업데이트에 `UpdateService()` 직접 호출이 필요합니다. + CodeDeploy와 Amazon ECS 블루/그린 모두 후크 구현에 Lambda를 사용하지만 예상되는 입력과 출력은 서로 다릅니다. CodeDeploy에서는 함수가 `PutLifecycleEventHookExecutionStatus()`를 직접 호출하여 후크 상태를 반환해야 합니다. 후크 상태는 `SUCCEEDED` 또는 `FAILED`일 수 있습니다. Amazon ECS에서는 Lambda 응답을 사용하여 후크 상태를 나타냅니다. + CodeDeploy는 각 후크를 일회성 직접 호출로 간접 호출하며 1시간 이내에 최종 실행 상태가 반환될 것으로 예상합니다. Amazon ECS 후크는 `IN_PROGRESS` 표시기를 리턴할 수 있다는 점에서 보다 유연합니다. 이 표시기는 `SUCCEEDED` 또는 `FAILED`가 될 때까지 후크를 반복적으로 다시 간접 호출해야 함을 알립니다. 자세한 내용은 [Amazon ECS 서비스 배포에 대한 수명 주기 후크](deployment-lifecycle-hooks.md) 섹션을 참조하세요. ## 마이그레이션 접근 방식 CodeDeploy 블루/그린에서 Amazon ECS 블루/그린 배포로 마이그레이션하는 세 가지 기본 접근 방식이 있습니다. 각 접근 방식은 복잡성, 위험, 롤백 기능 및 잠재적 가동 중지 시간 측면에서 서로 다른 특성을 보입니다. ### CodeDeploy에 사용된 것과 동일한 Elastic Load Balancing 리소스 재사용 CodeDeploy 배포 컨트롤러 대신 블루/그린 배포 전략으로 Amazon ECS 배포 컨트롤러를 사용하도록 기존 Amazon ECS 서비스를 업데이트합니다. 이 접근 방식을 사용하는 경우 다음 사항을 고려하세요. + 기존 Amazon ECS 서비스 배포 컨트롤러 및 배포 전략을 업데이트하므로 마이그레이션 절차가 더 간단합니다. + 올바르게 구성하고 마이그레이션하면 가동 중지 시간이 발생하지 않습니다. + 롤백하려면 서비스 개정을 되돌려야 합니다. + 병렬 블루/그린 구성이 없으므로 위험이 높습니다. CodeDeploy에 사용되는 것과 동일한 로드 밸런서 리스너 및 대상 그룹을 사용합니다. CloudFormation을 사용 중인 경우 [CloudFormation CodeDeploy 블루/그린 배포 템플릿을 Amazon ECS 블루/그린 CloudFormation 템플릿으로 마이그레이션](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md) 섹션을 참조하세요. 1. 대체 대상 그룹을 포함하도록 프로덕션/테스트 리스너의 기본 규칙을 수정하고 기본 대상 그룹의 가중치를 1로, 대체 대상 그룹을 0으로 설정하세요. CodeDeploy의 경우 서비스에 연결된 로드 밸런서의 리스너는 모든 트래픽을 단일 대상 그룹으로 라우팅하는 단일(기본값) 규칙으로 구성됩니다. Amazon ECS 블루/그린의 경우 로드 밸런서 리스너는 가중치가 있는 두 개의 대상 그룹을 포함하는 규칙으로 사전 구성되어야 합니다. 기본 대상 그룹은 가중치를 1로 지정하고 대체 대상 그룹은 가중치를 0으로 지정해야 합니다. 1. `UpdateService` API를 직접 호출하고 파라미터 `deploymentController`를 `ECS`로, 파라미터 `deploymentStrategy`를 `BLUE_GREEN`으로 설정하여 기존 Amazon ECS 서비스를 업데이트하세요. 대상 그룹, 대체 대상 그룹, 프로덕션 리스너 및 선택적 테스트 리스너의 ARN을 지정하세요. 1. 서비스가 예상대로 작동하는지 확인하세요. 1. 이제 Amazon ECS 블루/그린을 사용하고 있으므로 이 Amazon ECS 서비스에 대한 CodeDeploy 설정을 삭제하세요. ### 기존 로드 밸런서를 사용하는 새 서비스 이 접근 방식은 마이그레이션에 블루/그린 전략을 사용합니다. 이 접근 방식을 사용하는 경우 다음 사항을 고려하세요. + 중단이 최소화됩니다. Elastic Load Balancing 포트 스왑 중에만 발생합니다. + 롤백하려면 Elastic Load Balancing 포트 스왑을 되돌려야 합니다. + 병렬 구성이기 때문에 위험이 낮습니다. 따라서 트래픽 전환 전에 테스트할 수 있습니다. 1. 필요한 경우 이 설정으로 쉽게 롤백할 수 있도록 CodeDeploy 설정에 대한 리스너, 대상 그룹 및 Amazon ECS 서비스를 그대로 두세요. 1. 기존 로드 밸런서에서 새 대상 그룹과 새 리스너(원래 리스너와 다른 포트를 사용함)를 생성하세요. 그런 다음 배포 컨트롤러로 `ECS`, 배포 전략으로 `BLUE_GREEN`을 사용하는 경우를 제외하고 기존 Amazon ECS 서비스와 일치하는 새 Amazon ECS 서비스를 생성하고 새 대상 그룹 및 새 리스너 규칙에 대한 ARN을 전달하세요. 1. 서비스에 HTTP 트래픽을 수동으로 전송하여 새 설정을 확인하세요. 모두 잘 진행되면 원래 리스너와 새 리스너의 포트를 바꿔 트래픽을 새 설정으로 라우팅하세요. 1. 새 설정을 확인하고 모든 것이 예상대로 계속 작동하면 CodeDeploy 설정을 삭제하세요. ### 새 로드 밸런서를 사용하는 새 서비스 이전 접근 방식과 마찬가지로 이 접근 방식은 마이그레이션에 블루/그린 전략을 사용합니다. 주요 차이점은 CodeDeploy 설정에서 Amazon ECS 블루/그린 설정으로 전환이 로드 밸런서 위의 역방향 프록시 계층에서 발생한다는 점입니다. 역방향 프록시 계층의 구현 샘플은 Route 53 및 CloudFront입니다. 이 접근 방식은 이미 이 역방향 프록시 계층이 있고 서비스와의 모든 통신이 이를 통해 수행되는 고객(예: 로드 밸런서 수준에서 직접 통신하지 않음) 적합합니다. 이 접근 방식을 사용하는 경우 다음 사항을 고려하세요. + 이를 위해서는 역방향 프록시 계층이 필요합니다. + 기존 Amazon ECS 서비스 배포 컨트롤러 및 배포 전략을 업데이트해야 하므로 마이그레이션 절차가 더 복잡합니다. + 중단이 최소화됩니다. Elastic Load Balancing 포트 스왑 중에만 발생합니다. + 롤백하려면 프록시 구성 변경 내용을 되돌려야 합니다. + 병렬 구성이기 때문에 위험이 낮습니다. 따라서 트래픽 전환 전에 테스트할 수 있습니다. 1. 기존 CodeDeploy 설정을 수정하지 마세요(로드 밸런서, 리스너, 대상 그룹, Amazon ECS 서비스 및 CodeDeploy 배포 그룹). 1. Amazon ECS 블루/그린 배포에 대해 구성된 새 로드 밸런서, 대상 그룹 및 리스너를 생성하세요. 적절한 리소스를 구성합니다. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. 1. `ECS`를 배포 컨트롤러로 사용하고 `BLUE_GREEN`을 배포 전략으로 사용하여 새 로드 밸런서 리소스를 가리키는 새 서비스를 생성하세요. 1. 새 로드 밸런서를 통해 테스트하여 새 설정을 확인하세요. 1. 트래픽을 새 로드 밸런서로 라우팅하도록 역방향 프록시 구성을 업데이트하세요. 1. 새 서비스 개정을 관찰하고 모든 것이 예상대로 계속 작동하면 CodeDeploy 설정을 삭제하세요. ## 다음 단계 Amazon ECS 블루/그린 배포로 마이그레이션한 후: + CodeDeploy `UpdateService` API 대신 Amazon ECS `CreateDeployment` API를 사용하도록 배포 스크립트 및 CI/CD 파이프라인을 업데이트합니다. + CodeDeploy 배포 대신 Amazon ECS 서비스 배포를 추적하도록 모니터링 및 알림을 업데이트합니다. + 새 배포 프로세스의 자동화된 테스트를 구현하여 예상대로 작동하는지 확인합니다. # CodeDeploy 블루/그린에서 Amazon ECS 블루/그린 서비스 배포로 마이그레이션 Amazon RDS 블루/그린 배포를 사용하면 프로덕션 환경에서 구현하기 전에 서비스를 변경하고 해당 변경 내용을 테스트할 수 있습니다. Amazon ECS 블루/그린 배포에 대한 새 수명 주기 후크를 생성해야 합니다. ## 사전 조건 블루/그린 배포를 시작하기 전에 다음 작업을 수행합니다. 1. Amazon ECS CodeDeploy IAM 역할을 다음 권한으로 바꾸세요. + Elastic Load Balancing 권한에 대한 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. + Lambda 권한에 대한 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. 1. CodeDeploy 자동화를 끄세요. 자세한 내용은 *CodeDeploy 사용 설명서*의 [Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)를 참조하세요. 1. CodeDeploy 블루/그린 배포에서 다음 정보가 있는지 확인하세요. Amazon ECS 블루/그린 배포에서 이 정보를 재사용할 수 있습니다. + 프로덕션 대상 그룹 + 프로덕션 리스너 + 프로덕션 규칙 + 테스트 대상 그룹 그린 서비스 개정의 대상 그룹입니다. 1. Application Load Balancer 대상 그룹이 리스너 규칙과 올바르게 연결되어 있는지 확인하세요. + 테스트 리스너를 사용하지 않는 경우 두 개의 대상 그룹(프로덕션 및 테스트)이 프로덕션 리스너 규칙과 연결되어 있어야 합니다. + 테스트 리스너를 사용하는 경우 하나의 대상 그룹을 프로덕션 리스너 규칙에 연결하고 다른 대상 그룹을 테스트 리스너 규칙에 연결해야 합니다. 이 요구 사항이 충족되지 않으면 서비스 배포에 실패하고 다음 오류가 발생합니다. `Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.` 1. 서비스에 대해 진행 중인 서비스 배포가 없는지 확인하세요. 자세한 내용은 [Amazon ECS 서비스 배포를 사용하여 서비스 기록 보기](service-deployment.md) 섹션을 참조하세요. 1. Amazon ECS 블루/그린 배포에서는 서비스가 다음 기능 중 하나를 사용해야 합니다. 적절한 리소스를 구성하세요. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. + Service Connect - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스](service-connect-blue-green.md) 섹션을 참조하세요. 1. Amazon ECS 블루/그린 배포의 단계에 대한 수명 주기 단계에서 Lambda 함수를 실행할지를 결정하세요. + 사전 스케일 업 + 스케일 업 이후 + 트래픽 전환 테스트 + 트래픽 전환 테스트 이후 + 프로덕션 트래픽 전환 + 프로덕션 트래픽 전환 이후 각 수명 주기 단계에 대해 Lambda 함수를 생성하세요. 자세한 내용은 *AWS Lambda 개발자 안내서*의 [콘솔로 Lambda 함수 생성](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function)을 참조하세요. 서비스의 배포 컨트롤러 업데이트에 대한 자세한 내용은 [Amazon ECS 서비스 파라미터 업데이트](update-service-parameters.md) 섹션을 참조하세요. ## 절차 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 클러스터 세부 정보 페이지가 표시됩니다. 1. **서비스** 탭에서 서비스를 선택하세요. 서비스 세부 정보 페이지가 표시됩니다. 1. 배너에서 **배포 컨트롤러 유형 업데이트**를 선택하세요. **배포 컨트롤러 유형 마이그레이션** 페이지가 표시됩니다. 1. **새로 만들기**를 확장한 후 다음 파라미터를 지정하세요. 1. **배포 컨트롤러 유형**에서 **ECS**를 선택하세요. 1. **배포 전략**에서 **블루/그린**을 선택하세요. 1. **베이크 소요 시간**에 블루 및 그린 서비스 개정이 모두 실행되는 시간을 입력하세요. 1. 수명 주기 단계에서 Lambda 함수를 실행하려면 **배포 수명 주기 후크** 아래 각 고유한 Lambda 함수에 대해 다음을 수행하세요. 1. **추가**를 선택합니다. 실행하려는 모든 고유 함수에 대해 반복하세요. 1. **Lambda 함수**에서 함수 이름을 입력하세요. 1. **역할**에서 블루/그린 권한이 있는 사전 요구 사항에서 생성한 역할을 선택하세요. 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. 1. **수명 주기 단계**에서 Lambda 함수가 실행되는 단계를 선택하세요. 1. (선택 사항) **후크 세부 정보**에 후크에 대한 정보를 제공하는 키-값 페어를 입력하세요. 1. **로드 밸런싱**을 확장한 후 다음을 구성하세요. 1. **역할**에서 블루/그린 권한이 있는 사전 요구 사항에서 생성한 역할을 선택하세요. 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. 1. **리스너**에서 CodeDeploy 블루/그린 배포의 프로덕션 리스너를 선택하세요. 1. **프로덕션 규칙**에서 CodeDeploy 블루/그린 배포의 프로덕션 규칙을 선택하세요. 1. **테스트 규칙**에서 CodeDeploy 블루/그린 배포의 테스트 규칙을 선택하세요. 1. **대상 그룹**에서 CodeDeploy 블루/그린 배포의 프로덕션 대상 그룹을 선택하세요. 1. **대체 대상 그룹**에서 CodeDeploy 블루/그린 배포의 테스트 대상 그룹을 선택하세요. 1. **업데이트**를 선택합니다. ## 다음 단계 + 배포를 시작하도록 서비스를 업데이트합니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. + 배포 프로세스를 모니터링하여 블루/그린 패턴을 따르는지 확인합니다. + 그린 서비스 개정이 생성되고 스케일 업됨 + 테스트 트래픽이 그린 개정으로 라우팅됨(구성된 경우) + 프로덕션 트래픽이 그린 개정으로 전환됨 + 베이크 소요 시간이 지나면 블루 개정이 종료됨 # CloudFormation CodeDeploy 블루/그린 배포 템플릿을 Amazon ECS 블루/그린 CloudFormation 템플릿으로 마이그레이션 Amazon ECS 서비스에 대한 CodeDeploy 블루/그린 배포를 사용하는 CloudFormation 템플릿을 네이티브 Amazon ECS 블루/그린 배포 전략을 사용하는 템플릿으로 마이그레이션합니다. 마이그레이션은 'CodeDeploy에 사용된 것과 동일한 Elastic Load Balancing 리소스 재사용' 접근 방식을 따릅니다. 자세한 내용은 [CodeDeploy 블루/그린 배포를 Amazon ECS 블루/그린 배포로 마이그레이션](migrate-codedeploy-to-ecs-bluegreen.md) 섹션을 참조하세요. ## 소스 템플릿 이 템플릿은 `AWS::CodeDeployBlueGreen` 변환 및 `AWS::CodeDeploy::BlueGreen` 후크를 사용하여 Amazon ECS 서비스에 대한 블루/그린 배포를 구현합니다. ### 소스 CodeDeploy 블루/그린 배포를 사용하는 전체 CloudFormation 템플릿입니다. 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [Blue/green deployment template example](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json)을 참조하세요. ``` { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { "Vpc": { "Type": "AWS::EC2::VPC::Id" }, "Subnet1": { "Type": "AWS::EC2::Subnet::Id" }, "Subnet2": { "Type": "AWS::EC2::Subnet::Id" } }, "Transform": [ "AWS::CodeDeployBlueGreen" ], "Hooks": { "CodeDeployBlueGreenHook": { "Type": "AWS::CodeDeploy::BlueGreen", "Properties": { "TrafficRoutingConfig": { "Type": "TimeBasedCanary", "TimeBasedCanary": { "StepPercentage": 15, "BakeTimeMins": 5 } }, "Applications": [ { "Target": { "Type": "AWS::ECS::Service", "LogicalID": "ECSDemoService" }, "ECSAttributes": { "TaskDefinitions": [ "BlueTaskDefinition", "GreenTaskDefinition" ], "TaskSets": [ "BlueTaskSet", "GreenTaskSet" ], "TrafficRouting": { "ProdTrafficRoute": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "LogicalID": "ALBListenerProdTraffic" }, "TargetGroups": [ "ALBTargetGroupBlue", "ALBTargetGroupGreen" ] } } } ] } } }, "Resources": { "ExampleSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Security group for ec2 access", "VpcId": {"Ref": "Vpc"}, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "CidrIp": "0.0.0.0/0" } ] } }, "ALBTargetGroupBlue": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ALBTargetGroupGreen": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ExampleALB": { "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", "Properties": { "Scheme": "internet-facing", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ], "Tags": [ { "Key": "Group", "Value": "Example" } ], "Type": "application", "IpAddressType": "ipv4" } }, "ALBListenerProdTraffic": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "Properties": { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 } ] } } ], "LoadBalancerArn": {"Ref": "ExampleALB"}, "Port": 80, "Protocol": "HTTP" } }, "ALBListenerProdRule": { "Type": "AWS::ElasticLoadBalancingV2::ListenerRule", "Properties": { "Actions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 } ] } } ], "Conditions": [ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "Mozilla" ] } } ], "ListenerArn": {"Ref": "ALBListenerProdTraffic"}, "Priority": 1 } }, "ECSTaskExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" ] } }, "BlueTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]}, "ContainerDefinitions": [ { "Name": "DemoApp", "Image": "nginxdemos/hello:latest", "Essential": true, "PortMappings": [ { "HostPort": 80, "Protocol": "tcp", "ContainerPort": 80 } ] } ], "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "Memory": "512", "Family": "ecs-demo" } }, "ECSDemoCluster": { "Type": "AWS::ECS::Cluster", "Properties": {} }, "ECSDemoService": { "Type": "AWS::ECS::Service", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "DesiredCount": 1, "DeploymentController": { "Type": "EXTERNAL" } } }, "BlueTaskSet": { "Type": "AWS::ECS::TaskSet", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "LaunchType": "FARGATE", "NetworkConfiguration": { "AwsVpcConfiguration": { "AssignPublicIp": "ENABLED", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ] } }, "PlatformVersion": "1.4.0", "Scale": { "Unit": "PERCENT", "Value": 100 }, "Service": {"Ref": "ECSDemoService"}, "TaskDefinition": {"Ref": "BlueTaskDefinition"}, "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"} } ] } }, "PrimaryTaskSet": { "Type": "AWS::ECS::PrimaryTaskSet", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "Service": {"Ref": "ECSDemoService"}, "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]} } } } } ``` ## 마이그레이션 단계 ### CodeDeploy 관련 리소스 제거 다음 속성은 더 이상 필요하지 않습니다. + `AWS::CodeDeployBlueGreen` 변환 + `CodeDeployBlueGreenHook` 후크 + `GreenTaskDefinition` 및 `GreenTaskSet` 리소스(Amazon ECS에서 관리됨) + `PrimaryTaskSet` 리소스(Amazon ECS는 태스크 세트를 내부적으로 관리함) ### 로드 밸런서 리스너 재구성 두 개의 대상 그룹에 전달 작업을 사용하도록 `ALBListenerProdTraffic` 리소스를 수정합니다. ``` { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ] } ``` ### 배포 속성 업데이트 다음을 업데이트하고 추가합니다. + `DeploymentController` 속성을 `EXTERNAL`에서 `ECS`로 업데이트합니다. + `Strategy` 속성을 추가하고 BLUE\$1GREEN으로 설정합니다. + `BakeTimeInMinutes` 속성을 추가합니다. ``` { "DeploymentConfiguration": { "MaximumPercent": 200, "MinimumHealthyPercent": 100, "DeploymentCircuitBreaker": { "Enable": true, "Rollback": true }, "BakeTimeInMinutes": 5, "Strategy": "BLUE_GREEN" } } ``` + 로드 밸런서 구성을 서비스에 추가합니다. ``` { "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "AdvancedConfiguration": { "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "ProductionListenerRule": {"Ref": "ALBListenerProdRule"}, "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]} } } ] } ``` + 서비스에 태스크 정의 참조를 추가합니다. ``` { "TaskDefinition": {"Ref": "BlueTaskDefinition"} } ``` ### AmazonECSInfrastructureRolePolicyForLoadBalancers 역할 생성 Amazon ECS가 로드 밸런서 리소스를 관리하도록 허용하는 새 IAM 역할을 추가합니다. 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. ## 테스트 권장 사항 1. 마이그레이션된 템플릿을 비프로덕션 환경에 배포하세요. 1. 서비스가 초기 구성으로 올바르게 배포되는지 확인하세요. 1. 태스크 정의를 업데이트하고 블루/그린 배포 프로세스를 관찰하여 배포를 테스트하세요. 1. 트래픽이 블루 배포와 그린 배포 사이에서 올바르게 전환되는지 확인하세요. 1. 배포 실패를 강제로 적용하여 롤백 기능을 테스트하세요. ## 마이그레이션 후 템플릿 ### 최종 템플릿 Amazon ECS 블루/그린 배포를 사용하는 전체 CloudFormation 템플릿입니다. ``` { "AWSTemplateFormatVersion": "2010-09-09", "Parameters": { "Vpc": { "Type": "AWS::EC2::VPC::Id" }, "Subnet1": { "Type": "AWS::EC2::Subnet::Id" }, "Subnet2": { "Type": "AWS::EC2::Subnet::Id" } }, "Resources": { "ExampleSecurityGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription": "Security group for ec2 access", "VpcId": {"Ref": "Vpc"}, "SecurityGroupIngress": [ { "IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "CidrIp": "0.0.0.0/0" }, { "IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "CidrIp": "0.0.0.0/0" } ] } }, "ALBTargetGroupBlue": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ALBTargetGroupGreen": { "Type": "AWS::ElasticLoadBalancingV2::TargetGroup", "Properties": { "HealthCheckIntervalSeconds": 5, "HealthCheckPath": "/", "HealthCheckPort": "80", "HealthCheckProtocol": "HTTP", "HealthCheckTimeoutSeconds": 2, "HealthyThresholdCount": 2, "Matcher": { "HttpCode": "200" }, "Port": 80, "Protocol": "HTTP", "Tags": [ { "Key": "Group", "Value": "Example" } ], "TargetType": "ip", "UnhealthyThresholdCount": 4, "VpcId": {"Ref": "Vpc"} } }, "ExampleALB": { "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer", "Properties": { "Scheme": "internet-facing", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ], "Tags": [ { "Key": "Group", "Value": "Example" } ], "Type": "application", "IpAddressType": "ipv4" } }, "ALBListenerProdTraffic": { "Type": "AWS::ElasticLoadBalancingV2::Listener", "Properties": { "DefaultActions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ], "LoadBalancerArn": {"Ref": "ExampleALB"}, "Port": 80, "Protocol": "HTTP" } }, "ALBListenerProdRule": { "Type": "AWS::ElasticLoadBalancingV2::ListenerRule", "Properties": { "Actions": [ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "Weight": 1 }, { "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "Weight": 0 } ] } } ], "Conditions": [ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": [ "Mozilla" ] } } ], "ListenerArn": {"Ref": "ALBListenerProdTraffic"}, "Priority": 1 } }, "ECSTaskExecutionRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ecs-tasks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" ] } }, "ECSInfrastructureRoleForLoadBalancers": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToECSForInfrastructureManagement", "Effect": "Allow", "Principal": { "Service": "ecs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }, "ManagedPolicyArns": [ "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers" ] } }, "BlueTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]}, "ContainerDefinitions": [ { "Name": "DemoApp", "Image": "nginxdemos/hello:latest", "Essential": true, "PortMappings": [ { "HostPort": 80, "Protocol": "tcp", "ContainerPort": 80 } ] } ], "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "Memory": "512", "Family": "ecs-demo" } }, "ECSDemoCluster": { "Type": "AWS::ECS::Cluster", "Properties": {} }, "ECSDemoService": { "Type": "AWS::ECS::Service", "Properties": { "Cluster": {"Ref": "ECSDemoCluster"}, "DesiredCount": 1, "DeploymentController": { "Type": "ECS" }, "DeploymentConfiguration": { "MaximumPercent": 200, "MinimumHealthyPercent": 100, "DeploymentCircuitBreaker": { "Enable": true, "Rollback": true }, "BakeTimeInMinutes": 5, "Strategy": "BLUE_GREEN" }, "NetworkConfiguration": { "AwsvpcConfiguration": { "AssignPublicIp": "ENABLED", "SecurityGroups": [ {"Ref": "ExampleSecurityGroup"} ], "Subnets": [ {"Ref": "Subnet1"}, {"Ref": "Subnet2"} ] } }, "LaunchType": "FARGATE", "PlatformVersion": "1.4.0", "TaskDefinition": {"Ref": "BlueTaskDefinition"}, "LoadBalancers": [ { "ContainerName": "DemoApp", "ContainerPort": 80, "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}, "AdvancedConfiguration": { "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"}, "ProductionListenerRule": {"Ref": "ALBListenerProdRule"}, "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]} } } ] } } } } ``` # CodeDeploy 블루/그린에서 Amazon ECS 롤링 업데이트 서비스 배포로 마이그레이션 CodeDeploy 블루/그린 배포에서 Amazon ECS 롤링 업데이트 배포로 서비스 배포를 마이그레이션할 수 있습니다. 이렇게 하면 CodeDeploy 종속성을 벗어나 통합 배포를 사용할 수 있습니다. Amazon ECS 서비스 스케줄러는 현재 실행 중인 태스크를 새 태스크로 대체합니다. 롤링 업데이트 중에 Amazon ECS가 서비스에 추가하거나 서비스에서 제거하는 작업의 수는 서비스 배포 구성으로 제어합니다. ## 사전 조건 블루/그린 배포를 시작하기 전에 다음 작업을 수행합니다. 1. 더 이상 Amazon ECS CodeDeploy IAM 역할이 필요하지 않습니다. 1. CodeDeploy 자동화를 끄세요. 자세한 내용은 *CodeDeploy 사용 설명서*의 [Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html)를 참조하세요. 1. 서비스에 대해 진행 중인 서비스 배포가 없는지 확인하세요. 자세한 내용은 [Amazon ECS 서비스 배포를 사용하여 서비스 기록 보기](service-deployment.md) 섹션을 참조하세요. 서비스의 배포 컨트롤러 업데이트에 대한 자세한 내용은 [Amazon ECS 서비스 파라미터 업데이트](update-service-parameters.md) 섹션을 참조하세요. ## 절차 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 클러스터 세부 정보 페이지가 표시됩니다. 1. **서비스** 탭에서 서비스를 선택하세요. 서비스 세부 정보 페이지가 표시됩니다. 1. 배너에서 **마이그레이션**을 선택하세요. **배포 구성 업데이트** 페이지가 표시됩니다. 1. **배포 옵션**을 확장한 후 다음 파라미터를 지정합니다. 1. **배포 컨트롤러 유형**에서 **ECS**를 선택하세요. 1. **배포 전략**에서 **롤링 업데이트**를 선택하세요. 1. **최소 실행 작업(Min running tasks)**의 경우, 배포 시 `RUNNING` 상태를 유지해야 하는 서비스 내 작업 수에 대한 하한을 원하는 작업 수의 백분율(가장 가까운 정수로 올림)로 입력합니다. 자세한 내용은 [배포 구성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration)을 참조하세요. 1. **최대 실행 작업(Max running tasks)**의 경우, 배포 시 `RUNNING` 또는 `PENDING` 상태가 허용되는 서비스 내 작업 수에 대한 상한을 원하는 작업 수의 백분율(가장 가까운 정수로 내림)로 입력합니다. 1. **로드 밸런싱**을 확장한 후 다음을 구성하세요. 1. **역할**에서 블루/그린 권한이 있는 사전 요구 사항에서 생성한 역할을 선택하세요. 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. 1. **리스너**에서 CodeDeploy 블루/그린 배포의 프로덕션 리스너를 선택하세요. 1. **대상 그룹**에서 CodeDeploy 블루/그린 배포의 프로덕션 대상 그룹을 선택하세요. 1. **업데이트**를 선택합니다. ## 다음 단계 변경 내용을 적용하려면 서비스를 업데이트해야 합니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. # Amazon ECS 배포 전략 업데이트 Amazon ECS는 서비스 업데이트에 대한 여러 배포 전략을 지원합니다. 애플리케이션 요구 사항에 따라 이러한 전략 사이에서 마이그레이션할 수 있습니다. 이 주제에서는 롤링 배포와 블루/그린 배포 사이에서 마이그레이션하는 방법에 대해 설명합니다. ## Amazon ECS 배포 전략 이해 배포 전략 사이에서 마이그레이션하기 전에 각 전략의 작동 방식과 주요 차이점을 이해하는 것이 중요합니다. **롤링 배포** 롤링 배포에서 Amazon ECS는 현재 실행 중인 애플리케이션 버전을 새 버전으로 바꿉니다. 서비스 스케줄러는 최소 및 최대 정상 상태 백분율 파라미터를 사용하여 배포 전략을 결정합니다. 롤링 배포는 설정이 더 간단하지만 배포 프로세스 및 트래픽 라우팅에 대한 제어는 덜합니다. **블루/그린 배포** 블루/그린 배포에서 Amazon ECS는 기존 버전(블루)과 함께 새 서비스 버전(그린)을 생성합니다. 이렇게 하면 프로덕션 트래픽을 라우팅하기 전에 새 버전을 확인할 수 있습니다. 블루/그린 배포는 트래픽 전환, 테스트 및 롤백 기능을 포함하여 배포 프로세스에 대한 더 많은 제어를 제공합니다. ## 모범 사례 배포 전략 사이에서 마이그레이션하는 경우 다음 모범 사례를 따릅니다. + **비프로덕션 환경에서 테스트**: 프로덕션 서비스에 변경 내용을 적용하기 전에 항상 비프로덕션 환경에서 업데이트를 테스트합니다. + **롤백 계획**: 업데이트가 예상대로 작동하지 않는 경우에 대비하여 롤백 계획을 수립합니다. + **전환 중 모니터링**: 마이그레이션 도중 및 마이그레이션 후 서비스를 면밀히 모니터링하여 서비스가 계속 올바르게 작동하는지 확인합니다. + **설명서 업데이트**: 새 배포 전략을 반영하도록 배포 설명서를 업데이트합니다. + **트래픽 영향 고려**: 업데이트가 서비스 트래픽에 미치는 영향을 이해하고 적절히 계획합니다. # 롤링 업데이트에서 Amazon ECS 블루/그린으로 배포 전략 업데이트 프로덕션 환경에서 구현하기 전에 서비스를 변경하고 해당 변경 내용을 테스트하려는 경우 롤링 업데이트 배포에서 Amazon ECS 블루/그린 배포로 마이그레이션할 수 있습니다. ## 사전 조건 서비스를 롤링에서 블루/그린 배포로 마이그레이션하기 전에 다음 사항을 갖추어야 합니다. + 현재 배포가 완료될 때까지 기다립니다. + 롤링 배포 전략을 사용하는 기존 Amazon ECS 서비스. + 트래픽을 지원하는 서비스 개정이 여러 개 있는 경우 Amazon ECS는 마이그레이션 중에 트래픽을 단일 개정으로 통합하려고 시도합니다. 실패하면 마이그레이션하기 전에 단일 개정을 사용하도록 서비스를 수동으로 업데이트해야 할 수 있습니다. + 적절한 권한을 구성하세요. + Elastic Load Balancing 권한에 대한 자세한 내용은 [로드 밸런서에 대한 Amazon ECS 인프라 IAM 역할](AmazonECSInfrastructureRolePolicyForLoadBalancers.md) 섹션을 참조하세요. + Lambda 권한에 대한 자세한 내용은 [Amazon ECS 블루/그린 배포에서 Lambda 함수에 필요한 권한](blue-green-permissions.md) 섹션을 참조하세요. + 구성에 따라 다음 중 하나를 수행해야 합니다. + 서비스가 Elastic Load Balancing을 사용하는 경우 새 'advancedConfiguration'으로 서비스를 업데이트하고 롤링 배포를 시작합니다. + 서비스가 Service Connect를 사용하는 경우 서비스를 업데이트하고 롤링 배포를 시작합니다. + 서비스가 Elastic Load Balancing 및 Service Connect를 모두 사용하는 경우 위의 두 단계를 모두 수행합니다(단일 UpdateService 요청 사용 가능). + 서비스가 위의 항목을 사용하지 않는 경우 추가 작업이 필요하지 않습니다. + Amazon ECS 블루/그린 배포에서는 서비스가 다음 기능 중 하나를 사용해야 합니다. 적절한 리소스를 구성합니다. + Application Load Balancer - 자세한 내용은 [블루/그린, 선형, 카나리 배포에 대한 Application Load Balancer 리소스](alb-resources-for-blue-green.md) 섹션을 참조하세요. + Network Load Balancer - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포를 위한 Network Load Balancer](nlb-resources-for-blue-green.md) 섹션을 참조하세요. + Service Connect - 자세한 내용은 [Amazon ECS 블루/그린, 선형 및 카나리 배포에 대한 Service Connect 리소스](service-connect-blue-green.md) 섹션을 참조하세요. ## 절차 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 Amazon ECS 콘솔을 여세요. 1. 탐색 창에서 **클러스터**를 선택합니다. 1. **클러스터** 페이지에서 마이그레이션하려는 서비스가 포함된 클러스터를 선택하세요. 클러스터 세부 정보 페이지가 표시됩니다. 1. **클러스터 세부 정보** 페이지에서 **서비스** 탭을 선택하세요. 1. 서비스를 선택하고 **업데이트**를 선택하세요. 서비스 업데이트 페이지가 표시됨 1. **배포 옵션**을 확장한 후 다음을 수행하세요. 1. **배포 전략**에서 **블루/그린**을 선택하세요. 1. 다음과 같이 블루/그린 배포 설정을 구성하세요. 1. **베이크 소요 시간**에 블루 개정이 종료되기 전에 블루 및 그린 서비스 개정이 동시에 실행되는 시간(분)을 입력하세요. 이를 통해 확인 및 테스트 시간을 확보할 수 있습니다. 1. (선택 사항) 배포의 특정 단계에서 실행할 Lambda 함수를 구성하세요. **배포 수명 주기 후크**에서 다음 단계에 맞게 Lambda 함수를 구성하세요. + **사전 스케일 업**: 그린 서비스 개정을 스케일 업하기 전에 실행 + **사후 스케일 업**: 그린 서비스 개정을 스케일 업한 후 실행 + **테스트 트래픽 전환**: 그린 서비스 개정으로 트래픽 라우팅을 테스트하는 동안 실행 + **사후 테스트 트래픽 전환**: 테스트 트래픽이 그린 서비스 개정으로 라우팅된 후 실행 + **프로덕션 트래픽 전환**: 그린 서비스 개정으로 프로덕션 트래픽을 라우팅하는 동안 실행 + **사후 프로덕션 트래픽 전환**: 프로덕션 트래픽이 그린 서비스 개정으로 라우팅된 후 실행 수명 주기 후크를 추가하는 방법: 1. **추가**를 선택합니다. 1. **Lambda 함수**에서 함수 이름 또는 ARN을 입력하세요. 1. **역할**에서 Lambda 함수를 간접 호출할 권한이 있는 IAM 역할을 선택하세요. 1. **수명 주기 단계**에서 Lambda 함수를 실행해야 하는 단계를 선택하세요. 1. 선택 사항: **후크 세부 정보**에 후크에 대한 추가 정보를 제공하도록 키-값 페어를 입력하세요. 1. 다음과 같이 로드 밸런서를 구성하세요. 1. **로드 밸런싱**에서 서비스가 로드 밸런서를 사용하도록 구성되어 있는지 확인하세요. 1. **대상 그룹**에서 프로덕션(블루) 환경의 기본 대상 그룹을 선택하세요. 1. **대체 대상 그룹**에서 테스트(그린) 환경의 대상 그룹을 선택하세요. 1. **프로덕션 리스너 규칙**에서 프로덕션 트래픽을 라우팅하기 위한 리스너 규칙을 선택하세요. 1. 선택 사항: **테스트 리스너 규칙**에서 테스트 트래픽을 그린 환경으로 라우팅하기 위한 리스너 규칙을 선택하세요. 1. **역할**에서 Amazon ECS가 로드 밸런서를 관리하도록 허용하는 IAM 역할을 선택하세요. 1. 변경 내용을 검토한 다음 **업데이트**를 선택하세요. ## 다음 단계 + 배포를 시작하도록 서비스를 업데이트합니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. + 배포 프로세스를 모니터링하여 블루/그린 패턴을 따르는지 확인합니다. + 그린 서비스 개정이 생성되고 스케일 업됨 + 테스트 트래픽이 그린 개정으로 라우팅됨(구성된 경우) + 프로덕션 트래픽이 그린 개정으로 전환됨 + 베이크 소요 시간이 지나면 블루 개정이 종료됨 # Amazon ECS 블루/그린에서 롤링 업데이트로 배포 전략 업데이트 블루/그린 배포를 롤링 업데이트 배포로 마이그레이션할 수 있습니다. 롤링 배포로 마이그레이션하는 경우 다음 사항을 고려하세요. + **트래픽 처리**: 롤링 배포를 사용하면 상태 확인을 통과하는 즉시 새 태스크가 트래픽을 수신하기 시작합니다. 블루/그린 배포와 마찬가지로 별도의 테스트 단계는 없습니다. + **리소스 효율성**: 롤링 배포는 완전한 중복 환경을 생성하는 대신 태스크를 점진적으로 대체하기 때문에 일반적으로 블루/그린 배포보다 적은 리소스를 사용합니다. + **롤백 복잡성**: 롤백 배포에서는 블루/그린 배포에 비해 롤백 작업이 더 복잡합니다. 롤백해야 하는 경우 이전 태스크 정의를 사용하여 새 배포를 시작해야 합니다. + **배포 속도**: 롤링 배포는 특히 태스크가 많은 서비스의 경우 블루/그린 배포보다 완료하는 데 더 오래 걸릴 수 있습니다. + **로드 밸런서 구성**: 기존 로드 밸런서 구성은 롤링 배포에서 계속 작동하지만 트래픽 전환 동작은 서로 다릅니다. ## 사전 조건 블루/그린에서 롤링 배포로 서비스를 마이그레이션하기 전에 다음 사항을 갖추어야 합니다. + 블루/그린 배포 전략을 사용하는 기존 Amazon ECS 서비스 + 서비스에 대한 진행 중인 배포 없음(현재 배포가 완료될 때까지 대기) + 롤링 배포에서 서비스가 동작하는 방식에 대한 명확한 이해 **참고** 배포가 진행 중인 경우 서비스를 롤링 배포로 마이그레이션할 수 없습니다. 계속하기 전에 현재 배포가 완료될 때까지 기다립니다. ## 마이그레이션 절차 다음 단계에 따라 Amazon ECS 서비스를 블루/그린에서 롤링 배포로 마이그레이션합니다. 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 Amazon ECS 콘솔을 여세요. 1. 탐색 창에서 **클러스터**를 선택합니다. 1. **클러스터** 페이지에서 마이그레이션하려는 서비스가 포함된 클러스터를 선택하세요. 1. **클러스터 세부 정보** 페이지에서 **서비스** 탭을 선택하세요. 1. 마이그레이션할 서비스를 선택하고 **업데이트**를 선택하세요. 1. **서비스 업데이트** 페이지에서 **배포 옵션** 섹션으로 이동하여 필요한 경우 확장하세요. 1. **배포 전략**에서 **롤링 업데이트**를 선택하세요. 1. 롤링 배포 설정을 구성하세요. 1. **최소 정상 상태 백분율**에서 배포 도중 `RUNNING` 상태를 유지해야 하는 태스크의 최소 백분율을 입력하세요. 이 값은 서비스에 대해 원하는 태스크 수의 백분율로 지정됩니다. 1. **최대 백분율**에서 배포 도중 `RUNNING` 또는 `PENDING` 상태로 허용되는 태스크의 최대 백분율을 입력하세요. 이 값은 서비스에 대해 원하는 태스크 수의 백분율로 지정됩니다. 1. 선택 사항: **배포 실패 감지**에서 Amazon ECS가 배포 실패를 감지하고 처리하는 방법을 구성하세요. 1. 배포 회로 차단기를 사용하려면 **Amazon ECS 배포 회로 차단기 사용**을 선택하세요. 1. 실패한 배포를 자동으로 롤백하려면 **실패 시 롤백**을 선택하세요. 1. 구성 변경 내용을 검토한 다음 **업데이트**를 선택하여 변경 내용을 저장하고 서비스를 롤링 배포로 마이그레이션하세요. Amazon ECS는 롤링 배포 전략을 사용하도록 서비스 구성을 업데이트합니다. 다음에 서비스를 업데이트할 때 롤링 배포 프로세스를 사용합니다. **참고** 블루/그린에서 롤링 배포로 마이그레이션하는 경우 Amazon ECS는 다음을 통해 전환을 처리합니다. 트래픽을 처리하는 현재 활성 서비스 개정 식별. 기존 로드 밸런서 구성을 유지하면서 새 배포 처리 방법 변경. 향후 롤링 배포를 위해 서비스 준비. ## 다음 단계 + 배포를 시작하도록 서비스를 업데이트합니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. # Amazon ECS 배포 전략 업데이트 문제 해결 이 섹션에서는 배포 전략을 마이그레이션하는 경우 발생할 수 있는 일반적인 문제에 대한 솔루션을 제공합니다. ## 여러 서비스 개정 또는 태스크 세트 다음 문제는 배포에 대한 여러 서비스 개정이 있는 상황과 관련이 있습니다. ECS 배포 컨트롤러 업데이트하는 경우 여러 태스크 세트 *오류 메시지*: `Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.` *솔루션*: 이 오류는 활성 태스크 세트가 여러 개인 서비스의 배포 컨트롤러 유형을 변경하려는 경우 발생합니다. `CODE_DEPLOY` 또는 `EXTERNAL` 배포 컨트롤러에서 이 문제를 해결하는 방법: 1. 현재 태스크 세트를 확인하세요. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets" ``` 1. 진행 중인 배포가 완료될 때까지 기다리세요. 1. 새 배포를 강제로 실행하여 태스크 세트를 정리하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment ``` 1. 필요한 경우 추가 태스크 세트를 수동으로 삭제하세요. ``` aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id ``` 1. 태스크 세트가 하나만 남게 되면 배포 컨트롤러 업데이트를 다시 시도하세요. 자세한 내용은 [Amazon ECS 서비스 배포 컨트롤러 및 전략](ecs_service-options.md) 섹션을 참조하세요. `ECS` 배포 컨트롤러 업데이트 시 기본 태스크 세트 누락 *오류 메시지*: `Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.` *솔루션*: 이 오류는 기본 태스크 세트가 없는 서비스의 배포 컨트롤러 유형을 변경하려는 경우 발생합니다. 이 문제를 해결하려면: 1. 서비스 상태 및 태스크 세트를 확인하세요. 서비스에 태스크 세트가 있으면 `ACTIVE`로 표시됩니다. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id] ``` `ACTIVE` 상태의 태스크 세트가 없으면 배포를 마이그레이션하세요. 자세한 내용은 [마이그레이션 접근 방식](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths)을 참조하세요. 1. 서비스에 실행 중인 태스크가 없으면 서비스를 업데이트하여 하나 이상의 태스크를 배포하세요. ``` aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id ``` 그러면 서비스에서 이전에 `ACTIVE` 상태였던 태스크 세트를 `PRIMARY` 상태로 표시합니다. 1. 태스크가 안정적인 실행 상태에 도달할 때까지 기다리세요. 다음을 통해 상태를 확인할 수 있습니다. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments" ``` 1. 서비스에 실행 중인 태스크가 포함된 기본 태스크 세트가 있으면 배포 컨트롤러 업데이트를 다시 시도하세요. 자세한 내용은 [Amazon ECS 서비스 배포 컨트롤러 및 전략](ecs_service-options.md) 섹션을 참조하세요. ## 배포 실패 감지 유형과 배포 컨트롤러 간 불일치 다음 문제는 배포 실패 감지 유형과 배포 컨트롤러 간 불일치와 관련이 있습니다. 비ECS 컨트롤러와 배포 회로 차단기 *오류 메시지*: `Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.` *솔루션*: 이 오류는 `ECS` 배포 컨트롤러를 사용하지 않는 서비스에서 배포 회로 차단기 기능을 활성화하려는 경우 발생합니다. 배포 회로 차단기는 `ECS` 배포 컨트롤러와만 호환됩니다. 1. 서비스의 현재 배포 컨트롤러를 확인하세요. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. `ECS` 배포 컨트롤러를 사용하도록 서비스를 업데이트하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. 서비스가 `ECS` 배포 컨트롤러를 사용하면 배포 회로 차단기를 활성화하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" ``` 자세한 내용은 [Amazon ECS 배포 회로 차단기가 장애를 감지하는 방법](deployment-circuit-breaker.md) 섹션을 참조하세요. 비ECS 컨트롤러와 경보 기반 롤백 *오류 메시지*: `Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.` *솔루션*: 이 오류는 `ECS` 배포 컨트롤러를 사용하지 않는 서비스에서 경보 기반 롤백을 구성하려는 경우 발생합니다. 경보 기반 롤백 기능은 `ECS` 배포 컨트롤러와만 호환됩니다. 1. 서비스의 현재 배포 컨트롤러를 확인하세요. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. `ECS` 배포 컨트롤러를 사용하도록 서비스를 업데이트하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. 서비스가 `ECS` 배포 컨트롤러를 사용하면 경보 기반 롤백을 구성하세요. ``` aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}" ``` 자세한 내용은 [CloudWatch 경보가 Amazon ECS 배포 장애를 감지하는 방법](deployment-alarm-failure.md) 섹션을 참조하세요. ## Service Connect와 배포 컨트롤러 간 불일치 다음 문제는 Service Connect와 배포 컨트롤러 간 불일치와 관련이 있습니다. Service Connect에서 `EXTERNAL` 컨트롤러 *오류 메시지*: `The EXTERNAL deployment controller type is not supported for services using Service Connect.` *솔루션*: 이 오류는 Service Connect가 활성화된 서비스에서 `EXTERNAL` 배포 컨트롤러를 사용하려는 경우 발생합니다. `EXTERNAL` 컨트롤러는 Service Connect와 호환되지 않습니다. 1. 서비스에 Service Connect가 활성화되어 있는지 확인하세요. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration" ``` 1. `EXTERNAL` 배포 컨트롤러를 사용해야 하는 경우 서비스를 업데이트하여 Service Connect를 비활성화하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}" ``` 1. 또는 Service Connect를 사용해야 하는 경우 `ECS` 배포 컨트롤러를 대신 사용하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 자세한 내용은 [Amazon ECS 서비스 배포 컨트롤러 및 전략](ecs_service-options.md) 섹션을 참조하세요. 비ECS 컨트롤러와 Service Connect *오류 메시지*: `Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.` *솔루션*: 이 오류는 `ECS` 배포 컨트롤러를 사용하지 않는 경우에 Service Connect를 활성화하려는 경우 발생합니다. Service Connect 기능은 `ECS` 배포 컨트롤러와만 호환됩니다. 1. 서비스의 현재 배포 컨트롤러를 확인하세요. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController" ``` 1. ECS 배포 컨트롤러를 사용하도록 서비스를 업데이트하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 1. 서비스가 ECS 배포 컨트롤러를 사용하면 Service Connect를 활성화하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace" ``` 자세한 내용은 [Amazon ECS 서비스 배포 컨트롤러 및 전략](ecs_service-options.md) 섹션을 참조하세요. ## 컨트롤러 유형과 예약 전략 간 불일치 다음 문제는 컨트롤러 유형과 예약 전략 간 불일치와 관련이 있습니다. `DAEMON` 예약 전략과 `CODE_DEPLOY` 컨트롤러 *오류 메시지*: `The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.` *솔루션*: 이 오류는 `DAEMON` 예약 전략을 사용하는 서비스에서 CODE\$1DEPLOY 배포 컨트롤러를 사용하려는 경우 발생합니다. `CODE_DEPLOY` 컨트롤러는 `REPLICA` 예약 전략과만 호환됩니다. 1. 서비스의 현재 예약 전략을 확인하세요. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy" ``` 1. 블루/그린 배포가 필요한 경우 `REPLICA` 예약 전략을 사용하도록 서비스를 변경하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA ``` 1. 또는 `DAEMON` 예약 전략을 사용해야 하는 경우 `ECS` 배포 컨트롤러를 대신 사용하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 자세한 내용은 [Amazon ECS 서비스 배포 컨트롤러 및 전략](ecs_service-options.md) 섹션을 참조하세요. DAEMON 예약 전략과 EXTERNAL 컨트롤러 *오류 메시지*: `The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.` *솔루션*: 이 오류는 DAEMON 예약 전략을 사용하는 ECS 서비스에서 EXTERNAL 배포 컨트롤러를 사용하려는 경우 발생합니다. EXTERNAL 컨트롤러는 REPLICA 예약 전략과만 호환됩니다. 1. 서비스의 현재 예약 전략을 확인하세요. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy" ``` 1. `EXTERNAL` 배포 컨트롤러를 사용해야 하는 경우 `REPLICA` 예약 전략을 사용하도록 서비스를 변경하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA ``` 1. 또는 `DAEMON` 예약 전략을 사용해야 하는 경우 `ECS` 배포 컨트롤러를 대신 사용하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS ``` 자세한 내용은 [Amazon ECS 서비스 배포 컨트롤러 및 전략](ecs_service-options.md) 섹션을 참조하세요. 외부 시작 유형과 서비스 레지스트리 *오류 메시지*: `Service registries are not supported for external launch type.` *솔루션*: 이 오류는 `EXTERNAL` 시작 유형을 사용하는 서비스에서 서비스 검색(서비스 레지스트리)을 구성하려는 경우 발생합니다. 서비스 검색은 `EXTERNAL` 시작 유형과 호환되지 않습니다. 1. 서비스의 현재 시작 유형을 확인하세요. ``` aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType" ``` 1. 서비스 검색이 필요한 경우 `EC2` 또는 `FARGATE` 시작 유형을 사용하도록 서비스를 변경하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE ``` 1. 또는 `EXTERNAL` 시작 유형을 사용해야 하는 경우 서비스 레지스트리 구성을 제거하세요. ``` aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]" ``` 자세한 내용은 [Amazon ECS 서비스 배포 컨트롤러 및 전략](ecs_service-options.md) 섹션을 참조하세요. ## 배포 컨트롤러 업데이트 되돌리기 이전 배포 컨트롤러로 돌아가려는 경우 다음 중 하나를 수행할 수 있습니다. + CloudFormation를 사용하는 경우 이전 템플릿을 사용하여 새 스택을 생성할 수 있습니다. 자세한 내용은 *CloudFormation 사용 설명서*에서 [스택 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)을 참조하세요. + Amazon ECS 콘솔 또는 AWS CLI를 사용한 경우 서비스를 업데이트할 수 있습니다. 자세한 내용은 [Amazon ECS 서비스 업데이트](update-service-console-v2.md) 섹션을 참조하세요. update-service 명령을 사용하는 경우 `--deployment-controller` 옵션을 사용하고 이전 배포 컨트롤러로 설정합니다. # Amazon ECS 서비스 배포를 사용하여 서비스 기록 보기 서비스 배포에서는 배포에 대한 포괄적인 보기가 제공됩니다. 서비스 배포에서는 서비스에 대한 다음과 같은 정보가 제공됩니다. + 현재 배포된 워크로드 구성(소스 서비스 개정) + 배포 중인 워크로드 구성(대상 서비스 개정) + 배포 상태 + 회로 차단이 감지된 실패한 태스크 수 + 경보에 있는 CloudWatch 경보 + 서비스 배포 시작 및 완료 시점 + 롤백 발생 시 세부 정보 서비스 배포 속성에 대한 내용은 [Amazon ECS 서비스 배포에 포함된 속성](service-deployment-property.md) 섹션을 참조하세요. 서비스 배포는 읽기 전용이며 각각 고유한 ID가 있습니다. 세 가지 서비스 배포 스테이지가 있습니다. | 단계 | 정의 | 연결된 상태 | | --- | --- | --- | | 보류중 | 서비스 배포가 생성되었으나 시작되지 않았음 | PENDING | | 지속적 | 서비스 배포 진행 중 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-deployment.html) | | 완료됨 | 서비스 배포 마침(성공 또는 실패) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-deployment.html) | 서비스 배포를 사용하여 서비스의 수명 주기를 이해하고 취해야 할 조치가 있는지 결정합니다. 예를 들면, 롤백이 발생한 경우 서비스 배포를 조사하고 서비스 이벤트를 살펴보는 것이 좋습니다. 콘솔, API 및 AWS CLI를 사용하여 2024년 10월 25일 이후에 생성된 배포에 대한 최근 90일 기록을 볼 수 있습니다. 완료되지 않은 배포를 중지할 수 있습니다. 자세한 내용은 [Amazon ECS 서비스 배포 중지](stop-service-deployment.md) 섹션을 참조하세요. ## 서비스 배포 수명 주기 Amazon ECS에서는 다음과 같은 조치 중 하나라도 발생하면 자동으로 새 서비스 배포가 생성됩니다. + 사용자가 서비스를 생성합니다. + 사용자가 서비스를 업데이트하고 새 배포 강제 적용 옵션을 사용합니다. + 배포가 필요한 하나 이상의 서비스 속성을 사용자가 업데이트합니다. 배포가 진행되는 동안 Amazon ECS에서는 서비스 배포의 진행률이 반영되도록 다음과 같은 서비스 배포 속성이 업데이트됩니다. + 상태 + 실행 중인 태스크 수 서비스 개정에 표시된 실행 중인 태스크 수는 실행 중인 태스크의 실제 수와 같지 않을 수 있습니다. 이 숫자는 배포 완료 시 실행 중인 태스크 수를 나타냅니다. 예를 들면, 서비스 배포와 독립적으로 태스크를 시작한 경우 해당 태스크는 서비스 개정의 실행 중인 태스크 수에 포함되지 않습니다. + 회로 차단기 실패 탐지: + 시작에 실패한 태스크 수 + CloudWatch 경보 실패 탐지 + 활성 상태인 경보 + 롤백 정보: + 시작 시각 + 롤백 사유 + 롤백에 사용된 서비스 개정의 ARN + 상태 사유 서비스를 삭제할 때 Amazon ECS에서 서비스 배포가 삭제됩니다. ## 서비스 배포 상태 서비스 배포는 `PENDING` 상태로 시작됩니다. 다음 그림에서는 `PENDING` 상태 이후에 발생할 수 있는 서비스 배포 상태인 `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_IN_PROGRESSS`, `ROLLBACK_FAILED`, `ROLLBACK_SUCCESSFUL`, `STOPPED`를 보여줍니다. ![\[IN_PROGRESS 상태 이후에 발생할 수 있는 서비스 배포 STOP_REQUESTED, SUCCESSFUL 및 ROLLBACK_IN_PROGRESS 상태입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/service-deployment-states.png) 다음과 같은 정보에서는 서비스 배포 상태에 대한 세부 정보가 제공됩니다. + `PENDING` - 서비스 배포가 생성되었으나 시작되지 않았습니다. 상태가 `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `STOP_REQUESTED` 또는 `STOPPED`로 바뀔 수 있습니다. + `IN_PROGRESS` - 서비스 배포가 진행 중입니다. 상태가 `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_REQUESTED`, `ROLLBACK_IN_PROGRESS` 및 `STOPPED`로 바뀔 수 있습니다. + `STOP_REQUESTED` - 다음 중 하나가 발생하면 서비스 배포 상태가 `STOP_REQUESTED`로 바뀝니다. + 사용자가 새 서비스 배포를 시작합니다. + 롤백 옵션은 실패 탐지 메커니즘(회로 차단기 또는 경보 기반)에 사용되지 않으며 서비스가 `SUCCESSFUL` 상태에 도달하지 않습니다. 상태가 `STOPPED`로 바뀝니다. + `ROLLBACK_REQUESTED` - 사용자가 콘솔, API 또는 CLI를 통해 롤백을 요청하면 서비스 배포 상태가 `ROLLBACK_REQUESTED`로 바뀝니다. 상태가 `SUCCESSFUL`, `ROLLBACK_IN_PROGRESS` 및 `STOPPED`로 바뀔 수 있습니다. + `SUCCESSFUL` - 서비스 배포가 완료되면 서비스 배포 상태가 `SUCCESSFUL`로 바뀝니다. + `ROLLBACK_IN_PROGRESS` - 롤백 옵션이 실패 탐지 메커니즘(회로 차단기 또는 경보 기반)에 사용 중이면 서비스 배포 상태가 `ROLLBACK_IN_PROGRESS`로 바뀌며 서비스에 실패합니다. 상태가 `ROLLBACK_SUCCESSFUL` 또는 `ROLLBACK_FAILED`로 바뀝니다. # Amazon ECS 서비스 배포에 포함된 속성 다음과 같은 속성이 서비스 배포에 포함되어 있습니다. | 속성 | 설명 | | --- | --- | | 서비스 배포 ARN | 서비스 배포의 ARN입니다. | | 서비스 ARN | 이 서비스 배포에 대한 서비스의 ARN입니다. | | 클러스터 ARN | 서비스가 호스팅되는 클러스터의 ARN입니다. | | 서비스 배포 생성 시각 | 서비스 배포가 생성된 시각입니다. | | 서비스 배포 시작 시각 | 서비스 배포가 시작된 시각입니다. | | 서비스 배포 완료 시각 | 서비스 배포가 완료된 시각입니다. | | 서비스 배포 중지 시각 | 서비스 배포가 중지된 시각입니다. | | 서비스 배포 업데이트 시각 | 서비스 배포가 마지막으로 업데이트된 시각입니다. | | 소스 서비스 개정 | 현재 실행 중인 서비스 개정입니다. 포함된 속성에 대한 내용은 [Amazon ECS 서비스 개정에 포함된 속성](service-revision-property.md) 섹션을 참조하세요. | | 배포 구성 | 회로 차단기 구성, 결정 경보가 포함된 배포 파라미터입니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-deployment-property.html) | | 대상 서비스 개정 | 배포되는 서비스 개정입니다.배포가 완료되면 실행 중인 서비스 개정이 대상 서비스 개정입니다. | | 서비스 배포 상태 | 서비스 배포 상태입니다.유효한 값은 PENDING, SUCCESSFUL, STOPPED, STOP\$1REQUESTED, STOP\$1IN\$1PROGRESS, IN\$1PROGRESS, ROLLBACK\$1IN\$1PROGRESS, ROLLBACK\$1SUCCESSFUL 및 ROLLBACK\$1FAILED입니다. | | 서비스 배포 상태 정보 | 서비스 배포가 현재 상태인 이유에 대한 정보입니다. 예: 실패가 회로 차단기에서 탐지되었습니다. | | 롤백 정보 | 배포 실패 시 서비스 배포에 사용되는 롤백 옵션입니다. | | 서비스 배포 회로 차단기 옵션 | 서비스 배포 실패가 결정되는 회로 차단기입니다. | | 서비스 배포에 대한 CloudWatch 경보 | 서비스 배포 실패 시점이 결정되는 CloudWatch 경보입니다. | # Amazon ECS 서비스 배포를 보는 데 필요한 권한 최소 권한 부여의 모범 사례를 따는 경우 콘솔에서 서비스 배포를 보려면 추가 권한을 추가해야 합니다. 다음과 같은 조치에 대한 액세스 권한이 필요합니다. + ListServiceDeployments + DescribeServiceDeployments + DescribeServiceRevisions 다음과 같은 리소스에 대한 액세스 권한이 필요합니다. + 서비스 + 서비스 배포 + 서비스 개정 다음 예제 정책에는 필요한 권한이 있으며, 지정된 서비스로 조치가 제한됩니다. `account`, `cluster-name` 및 `service-name`을 원하는 값으로 바꿉니다. ------ #### [ JSON ] **** ``` { "Statement": [ { "Effect": "Allow", "Action": [ "ecs:ListServiceDeployments", "ecs:DescribeServiceDeployments", "ecs:DescribeServiceRevisions" ], "Resource": [ "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name", "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*", "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*" ] } ] } ``` ------ # Amazon ECS 서비스 배포 보기 2024년 10월 25일 이후에 생성된 배포에 대한 최근 90일 기록을 참조할 수 있습니다. 서비스 배포 상태는 다음 중 하나일 수 있습니다. + 진행 중 + 보류중 + 완료됨 이 정보를 사용하여 서비스가 배포되는 방식 또는 서비스 개정을 업데이트해야 하는지 결정할 수 있습니다. 포함된 속성에 대한 내용은 [Amazon ECS 서비스 배포에 포함된 속성](service-deployment-property.md) 단원을 참조하세요. 시작하기 전에 서비스 배포를 보는 데 필요한 권한을 구성합니다. 자세한 내용은 [Amazon ECS 서비스 배포를 보는 데 필요한 권한](service-deployment-permissions.md) 섹션을 참조하세요. ------ #### [ Amazon ECS Console ] 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 섹션에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 표시됩니다. 1. 배포 세부 정보 페이지에서 **배포**를 선택합니다. 1. 보려는 서비스 배포를 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/view-service-deployment.html) 서비스 배포 세부 정보 페이지가 나타납니다. 1. (선택 사항) 서비스 개정을 비교하여 차이점을 봅니다. **서비스 개정**에서 **개정 비교**를 선택한 다음에 비교할 개정 2개를 선택합니다. 서비스 개정은 차이점이 강조 표시되어 나란히 표시됩니다. ------ #### [ AWS CLI ] 1. `list-service-deployments`를 실행하여 서비스 배포 ARN을 검색합니다. 변수를 원하는 값으로 바꿉니다. ``` aws ecs list-service-deployments --cluster cluster-name --service service-name ``` 보려는 배포에 대한 serviceDeploymentArn을 기록해 둡니다. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095", "status": "SUCCESSFUL" } ] } ``` 1. `describe-service-deployments`를 실행합니다. `list-service-deployments`에서 반환된 `serviceDeploymentArn`을 사용합니다. 변수를 원하는 값으로 바꿉니다. ``` aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 ``` ------ ## 다음 단계 배포에서 서비스 개정에 대한 세부 정보를 볼 수 있습니다. 자세한 내용은 [Amazon ECS 서비스 개정 세부 정보 보기](view-service-revision.md) 섹션을 참조하세요. # Amazon ECS 서비스 개정 서비스 개정에는 Amazon ECS에서 시도되고 있는 워크로드 구성의 레코드가 있습니다. 서비스를 생성하거나 배포할 때마다 Amazon ECS에서는 서비스 개정에서 배포하려는 구성이 자동으로 생성되고 캡처됩니다. 서비스 개정은 읽기 전용이며 고유한 식별자가 있습니다. 포함된 속성에 대한 내용은 [Amazon ECS 서비스 개정에 포함된 속성](service-revision-property.md) 단원을 참조하세요. 서비스 개정에서는 다음과 같은 이점이 제공됩니다. + 서비스 배포 중 현재 배포된 서비스 개정(소스)을 배포 중인 개정(대상)과 비교할 수 있습니다. + 서비스 배포에 롤백 옵션을 사용하면 Amazon ECS에서는 서비스 배포가 성공적으로 배포된 마지막 서비스 개정으로 자동으로 롤백됩니다. + 서비스 개정에는 리소스 하나에 워크로드 구성 레코드가 있습니다. ## 서비스 개정 수명 주기 서비스를 생성하거나 배포가 시작되는 서비스 속성을 업데이트할 때 새 서비스 개정이 Amazon ECS에서 자동으로 생성됩니다. Amazon ECS에서는 롤백 작업에 대한 새 서비스 개정이 생성되지 않습니다. Amazon ECS에서는 롤백에 마지막으로 성공한 서비스 개정을 사용합니다. 서비스 개정은 변경할 수 없습니다. 서비스를 삭제할 때 Amazon ECS에서 서비스 개정이 삭제됩니다. 콘솔, API 및 CLI를 사용하여 2024년 10월 25일 이후에 생성된 서비스 개정을 볼 수 있습니다. # Amazon ECS 서비스 개정에 포함된 속성 다음과 같은 속성이 서비스 개정에 포함되어 있습니다. | 리소스 | 설명 | | --- | --- | | 서비스 ARN | 서비스를 식별하는 ARN입니다. | | 클러스터 ARN | 서비스가 호스팅되는 클러스터의 ARN입니다. | | 작업 정의 ARN | 서비스 태스크에 사용되는 태스크 정의의 ARN입니다. | | 서비스 레지스트리 | 서비스 검색에 사용되는 서비스 레지스트리의 세부 정보입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-revision-property.html) | | 용량 공급자 | 용량 공급자 전략 세부 정보입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-revision-property.html) | | 컨테이너 이미지 | 컨테이너 이미지에 대한 세부 정보입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-revision-property.html) | | 네트워킹 | 서비스에 대한 네트워크 구성. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-revision-property.html) | | 시작 유형 | 서비스에 사용되는 컴퓨팅 옵션. | | Fargate별 속성 | Fargate를 사용하는 경우 이는 Fargate 버전에 대한 정보입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-revision-property.html) | | 배포 시 구성되는 Amazon EBS 볼륨입니다. | 시작 시 구성되는 볼륨으로 태스크 정의에서 지정되는 볼륨에 대한 구성입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-revision-property.html) | | Service Connect | Service Connect 구성입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-revision-property.html) | | 서비스 로드 밸런서 | 서비스 트래픽이 라우팅되는 로드 밸런서입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-revision-property.html) | | 런타임 모니터링 | Runtime Monitoring이 켜져 있는지를 나타냅니다. | | Creation(생성) 날짜 | 서비스 개정이 생성된 날짜입니다. | | VPC Lattice | 서비스 개정에 대한 VPC Lattice 구성입니다. | # Amazon ECS 서비스 개정 세부 정보 보기 2024년 10월 25일 이후에 생성된 다음과 같은 서비스 개정 유형에 대한 내용을 볼 수 있습니다. + 소스 - 현재 배포된 워크로드 구성 + 대상 - 배포 중인 워크로드 구성 ------ #### [ Amazon ECS Console ] 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 섹션에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 표시됩니다. 1. 배포 세부 정보 페이지에서 **배포**를 선택합니다. 1. 보려는 서비스 개정을 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/view-service-revision.html) ------ #### [ AWS CLI ] 1. `describe-service-deployments`를 실행하여 서비스 개정 ARN을 검색합니다. 변수를 원하는 값으로 바꿉니다. ``` aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 ``` `sourceServiceRevisions` 또는 `targetServiceRevisions`의 `arn`을 기록해 둡니다. ``` { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5", "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example", "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example", "updatedAt": "2024-09-10T16:49:35.572000+00:00", "sourceServiceRevision": { "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "targetServiceRevision": { "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "status": "IN_PROGRESS", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": false, "rollback": false }, "maximumPercent": 200, "minimumHealthyPercent": 100 } } ], "failures": [] } ``` 1. `describe-service-revisions`를 실행합니다. `describe-service-deployments`에서 반환된 `arn`을 사용합니다. 변수를 원하는 값으로 바꿉니다. ``` aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095 ``` ------ # 가용 영역 전체의 Amazon ECS 서비스 밸런싱 2025년 9월 5일부터 Amazon ECS는 해당 기능을 사용할 수 있는 모든 서비스에 대해 가용 영역 리밸런싱을 활성화합니다. 가용 영역 분산이 첫 번째 태스크 배치 전략이거나 배치 전략이 없는 경우 서비스를 사용할 수 있습니다. 애플리케이션의 고가용성 달성에 도움이 되려면 여러 가용 영역에서 실행되도록 다중 태스크 서비스를 구성하는 것이 좋습니다. 첫 번째 배치 전략을 가용 영역 분산으로 지정하는 서비스의 경우 AWS에서는 사용 가능한 가용 영역에 서비스 태스크가 균등하게 분산되도록 최선을 다합니다. 그러나 한 가용 영역과 다른 가용 영역에서 실행되는 태스크 수가 동일하지 않은 경우가 있을 수 있습니다(예: 가용 영역 중단 후). 이 태스크 불균형이 해결되도록 가용 영역 리밸런싱 특성을 활성화할 수 있습니다. 가용 영역 리밸런싱을 통해 Amazon ECS에서는 각 서비스의 가용 영역 전체의 태스크 분산을 지속적으로 모니터링합니다. Amazon ECS에서는 균등하지 않은 태스크 분산이 감지되면 자동으로 가용 영역 사이에 워크로드가 리밸런싱되도록 조처합니다. 여기에는 태스크가 가장 적은 가용 영역에서 새 태스크를 시작하고 과부하가 걸린 가용 영역에서 태스크를 종료하는 것이 포함됩니다. 이 재분산은 장애 지점이 되는 가용 영역이 없어지므로 컨테이너화된 애플리케이션의 전체 가용성을 유지하는 데 도움이 됩니다. 자동 리밸런싱 프로세스를 통해 수동 개입 필요성이 제거되므로 이벤트 후 복구 시간이 단축됩니다. 다음은 가용 영역 리밸런싱 프로세스의 개요입니다. 1. Amazon ECS에서는 서비스의 상태가 안정되면 모니터링을 시작하고 각 가용 영역에서 실행되는 태스크 수를 조사합니다. 1. Amazon ECS에서는 각 가용 영역에서 실행되는 태스크 수에서 불균형이 탐지되면 다음과 같은 작업을 수행합니다. + 가용 영역 리밸런싱이 시작되고 있음을 나타내는 서비스 이벤트를 보냅니다. + 실행 중인 태스크 수가 가장 적은 가용 영역의 태스크를 시작합니다. + 실행 중인 태스크 수가 가장 많은 가용 영역의 태스크를 중지합니다. + 스케줄러에서는 과도하게 규모가 조정된 가용 영역의 태스크를 중지하기 전에 새로 시작된 태스크가 `HEALTHY` 및 `RUNNING`이 될 때까지 기다립니다. + 가용 영역 리밸런싱 결과가 있는 서비스 이벤트를 보냅니다. ## Amazon ECS에서 불균형 태스크 분배를 탐지하는 방법 Amazon ECS는 서비스의 원하는 태스크 수를 구성된 가용 영역 수로 나누어 각 가용 영역에서 실행되는 태스크 수의 불균형을 확인합니다. 원하는 태스크 수가 균등하게 분산되지 않는 경우 Amazon ECS는 나머지 태스크를 구성된 여러 가용 영역에서 균등하게 분산합니다. 각 가용 영역에는 태스크가 1개 이상 있어야 합니다. 2개의 가용 영역에 대해 원하는 태스크 수가 2개로 구성된 Amazon ECS 서비스를 예로 들어 보겠습니다. 이 시나리오에서는 원하는 태스크 수가 균등하게 배포됩니다. 균형 잡힌 분배는 가용 영역당 태스크 1개입니다. 가용 영역 1에 태스크가 2개 있고 가용 영역 2에 태스크가 없는 경우 Amazon ECS는 가용 영역 1에서 태스크를 중지하기 전에 가용 영역 2에서 태스크를 시작하여 재분배를 시작합니다. 이제 2개의 가용 영역에 대해 원하는 태스크 수가 3개로 구성된 Amazon ECS 서비스를 예로 들어 보겠습니다. 이 시나리오에서는 원하는 태스크 수가 균등하게 배포되지 않습니다. 각 가용 영역에는 태스크가 1개 이상 있고 나머지 태스크는 가용 영역 2에 배치되므로 균형 잡힌 분배는 가용 영역 1에 태스크 1개와 가용 영역 2에 태스크 2개입니다. 3개의 가용 영역에 대해 원하는 태스크 수가 5개로 구성된 Amazon ECS 서비스를 예로 들어 보겠습니다. 이 시나리오에서는 원하는 태스크 수가 균등하게 배포되지 않습니다. 균형 잡힌 분배는 가용 영역 1에 태스크 1개와 가용 영역 2와 3 각각에 태스크 2개입니다. 모든 가용 영역에 태스크가 1개씩 있음을 고려하여 나머지 2개의 태스크는 가용 영역에 균등하게 분배됩니다. ## 가용 영역 재분배 구성 시 고려 사항 가용 영역 재분배를 구성하려는 경우 다음 사항을 고려하세요. + 가용 영역 리밸런싱은 Fargate 및 EC2 용량 공급자를 지원하며 Amazon ECS 관리형 인스턴스에서 지원됩니다. Fargate의 경우 Amazon ECS에서는 사용 가능한 가용 영역 전체에 태스크를 자동으로 재분산하여 균형을 유지 관리합니다. EC2 용량 공급자의 경우 Amazon ECS에서는 사용자가 정의한 배치 전략 및 제약 조건에 따라 기존 컨테이너 인스턴스 전체에 태스크를 리밸런싱합니다. 그러나 Amazon ECS에서는 리밸런싱 프로세스의 일부로 사용률이 낮은 가용 영역에서 새 인스턴스를 시작할 수 없으므로 기존 컨테이너 인스턴스로 리밸런싱이 제한됩니다. + 가용 영역 리밸런싱은 다음과 같은 구성에서 작동합니다. + `Replica` 전략을 사용하는 서비스 + 가용 영역 분산을 첫 번째 태스크 배치 전략으로 지정하지 않거나 배치 전략을 지정하지 않는 서비스입니다. + 다음과 같은 기준 중 하나라도 서비스에서 충족되면 가용 영역 리밸런싱을 사용할 수 없습니다. + `Daemon` 전략 사용 + `EXTERNAL` 시작 유형 사용(ECS Anywhere) + `maximumPercent` 값으로 100% 사용 + Classic Load Balancer 사용 + 태스크 배치 제약 조건으로 `attribute:ecs.availability-zone` 사용 ## 가용 영역 리밸런싱 포함 배치 전략 및 배치 제약 조건 배치 전략에 따라 Amazon ECS에서 태스크 배치를 종료할 컨테이너 인스턴스와 가용 영역을 선택하는 방식이 결정됩니다. 태스크 배치 제약 조건은 태스크가 특정 컨테이너 인스턴스에서 실행될 수 있는지 여부가 결정되는 규칙입니다. EC2의 경우 가용 영역 리밸런싱과 함께 배치 전략 및 배치 제약 조건을 사용할 수 있습니다. 그러나 가용 영역 리밸런싱이 작동하려면 지정된 첫 번째 전략이 가용 영역 분산 배치 전략이어야 합니다. 가용 영역 리밸런싱은 다양한 배치 전략 조합과 호환됩니다. 예를 들면, 가용 영역 전체에 균등하게 태스크를 분산한 다음에 각 가용 영역 내에서 메모리를 기준으로 태스크를 빈팩(bin pack)하는 전략을 생성할 수 있습니다. 이 경우 가용 영역 분산 전략이 먼저 지정되므로 가용 영역 리밸런싱이 작동합니다. 배치 전략 배열의 첫 번째 전략이 가용 영역 분산 구성 요소가 아닌 경우 가용 영역 리밸런싱이 작동하지 않는다는 점을 유의해야 합니다. 이 요구 사항에 따라 태스크 분산의 일차적인 초점이 고가용성에 매우 중요한 가용 영역 전체의 균형 유지 관리에 맞춰집니다. 태스크 배치 전략 및 제약 조건에 대한 자세한 내용은 [Amazon ECS가 컨테이너 인스턴스에 작업을 배치하는 방법](task-placement.md) 섹션을 참조하세요. Fargate를 사용하는 태스크에 대해서는 태스크 배치 전략 및 제약 조건이 지원되지 않습니다. Fargate는 액세스 가능한 가용 영역 전체에 작업을 분산시키기 위해 최선을 다합니다. 용량 공급자에 Fargate와 Fargate 스팟이 모두 포함되는 경우 분산 동작은 용량 공급자마다 독립적입니다. 다음 예제 전략에서는 가용 영역 전체에 균등하게 태스크를 분산한 다음에 각 가용 영역 내에서 메모리를 기준으로 태스크를 빈팩(bin pack)합니다. 가용 영역 리밸런싱은 `spread` 전략이 첫 번째이므로 서비스와 호환됩니다. ``` "placementStrategy": [ { "field": "attribute:ecs.availability-zone", "type": "spread" }, { "field": "memory", "type": "binpack" } ] ``` ## 가용 영역 리밸런싱 켜기 신규 및 기존 서비스에 대해 가용 영역 리밸런싱을 활성화해야 합니다. 콘솔, API, AWS CLI 및 CloudFormation을 사용하여 가용 영역 리밸런싱을 활성화 및 비활성화할 수 있습니다. `AvailabilityZoneRebalancing`의 기본 동작은 생성 요청과 업데이트 요청 간에 다릅니다. + 서비스 요청 생성의 경우 값을 지정하지 않으면 `AvailabilityZoneRebalancing`Amazon ECS는 값을 로 기본 설정합니다`ENABLED`. + 업데이트 서비스 요청의 경우에 `AvailabilityZoneRebalancing`에 대한 값을 지정하지 않으면 Amazon ECS는 기본적으로 기존 서비스의 `AvailabilityZoneRebalancing` 값으로 설정됩니다. 서비스에 `AvailabilityZoneRebalancing` 값이 설정된 적이 없는 경우 Amazon ECS는 이를 `DISABLED`로 취급합니다. | 서비스 유형 | API | 콘솔 | CLI | | --- | --- | --- | --- | | 기존 | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) | [Amazon ECS 서비스 업데이트](update-service-console-v2.md) | [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | | New | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) | [Amazon ECS 롤링 업데이트 배포 생성](create-service-console-v2.md) | [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | 다음 예제에서는 새 서비스를 생성할 때 서비스 리밸런싱을 활성화하는 방법을 보여줍니다. ``` aws ecs create-service \ --cluster my-cluster \ --service-name my-service \ --task-definition my-task-definition:1 \ --desired-count 6 \ --availability-zone-rebalancing ENABLED ``` # Amazon ECS 가용 영역 리밸런싱 추적 `describe-services`를 직접적으로 호출하거나 콘솔에서 서비스에 대해 가용 영역 리밸런싱이 활성화되어 있는지 확인할 수 있습니다. 다음 예제는 CLI를 통해 상태를 참조하는 데 사용할 수 있습니다. 응답은 `ENABLED` 또는 `DISABLED`입니다. ``` aws ecs describe-services \ --services service-name \ --cluster cluster-name \ --query services[0].availabilityZoneRebalancing ``` ## 서비스 이벤트 Amazon ECS에서는 가용 영역 리밸런싱 수명 주기를 이해하는 데 도움이 되는 서비스 작업 이벤트를 보냅니다. | Event | 시나리오 | Type | 자세히 알아보기 | | --- | --- | --- | --- | | SERVICE\$1REBALANCING\$1STARTED | Amazon ECS에서 가용 영역 리밸런싱 작업 시작 | INFO | [서비스(*service-name*)는 *가용 영역 1*의 *number-tasks* 태스크, *가용 영역 2*의 *number-tasks* 및 *가용 영역 3*의 *number-tasks*로 밸런싱된 AZ가 아닙니다. AZ 리밸런싱이 진행 중입니다.](service-rebalancing-event-messages-list.md#service-rebalancing-started) | | SERVICE\$1REBALANCING\$1COMPLETED | 가용 영역 리밸런싱 작업 완료 | INFO | [서비스(*service-name*)는 *가용 영역 1*의 *number-tasks* 태스크, *가용 영역 2*의 *number-tasks* 태스크 및 *가용 영역 3*의 *number-tasks* 태스크로 밸런싱된 AZ입니다.](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | | TASKS\$1STARTED | Amazon ECS에서 가용 영역 리밸런싱 작업의 일부로 태스크 시작 | INFO | [*service-name*이 AZ 리밸런싱에 대한 *가용 영역*의 *number-tasks* 태스크를 시작했습니다(*task-ids*).](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | | TASKS\$1STOPPED | Amazon ECS에서 가용 영역 리밸런싱 작업의 일부로 태스크 중지 | INFO | [*service-name*이 AZ 리밸런싱으로 인해 *가용 영역*에서 실행 중인 태스크 *number-tasks*를 중지했습니다(*task-id*).](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | | SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | Amazon ECS에서 가용 영역 리밸런싱 작업의 일부로 태스크 시작 실패 | 오류 | EC2의 경우 [모든 요구 사항을 충족하는 컨테이너 인스턴스가 없기 때문에 서비스(*service-name*)가 태스크를 *가용 영역*에 배치할 수 없습니다.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance) 섹션을 참조하세요.Fargate의 경우 [서비스(*service-name*)가 태스크를 *가용 영역*에 배치할 수 없습니다.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure) 섹션을 참조하세요. | | TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | 태스크 보호가 사용되고 있어 가용 영역 리밸런싱 작업이 차단되었습니다. | INFO | [*reason* 사유로 인해 *task-set-name* 태스크가 스케일 인될 수 없어서 서비스(*service-name*)가 AZ 리밸런싱할 수 없었습니다.](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | | SERVICE\$1REBALANCING\$1STOPPED | 가용 영역 리밸런싱 작업이 중지되었습니다. Amazon ECS에서는 자세한 내용이 제공되는 추가 이벤트를 보냅니다. | INFO | [서비스(*service-name*)가 AZ 리밸런싱을 중지했습니다.](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | ## 태스크 상태 변경 이벤트 Amazon ECS에서 리밸런싱 프로세스의 일부로 시작되는 태스크마다 태스크 상태 변경 이벤트(`START`)를 보냅니다. Amazon ECS에서는 리밸런싱 프로세스의 일부로 중지되는 태스크마다 태스크 상태 변경 이벤트(`STOPPED`)를 보냅니다. 사유는 `Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)`로 설정됩니다. 이벤트에 대한 자세한 내용은 [Amazon ECS 작업 상태 변경 이벤트](ecs_task_events.md) 섹션을 참조하세요. ## 서비스 리밸런싱 문제 해결 서비스 리밸런싱 관련 문제가 발생하면 다음 문제 해결 단계를 고려하세요. 리밸런싱이 시작되지 않음 다음을 확인합니다. + 서비스에 대해 서비스 리밸런싱이 활성화됨 + 서비스에서 지원되는 구성을 사용함([가용 영역 재분배 구성 시 고려 사항](#service-rebalancing-configurations) 참조) + 서비스가 안정된 상태에 도달함 리밸런싱 중 태스크 배치 실패 `SERVICE_TASK_PLACEMENT_FAILURE` 이벤트가 표시되는 경우: + EC2의 경우: 대상 가용 영역에 사용 가능한 컨테이너 인스턴스가 있는지 확인 + Fargate의 경우: 리소스 제약 조건 또는 서비스 할당량 제한 태스크 배치가 있는지 확인 + 태스크 배치 제약 조건을 검토하여 적절한 태스크 분산을 방해하지 않는지 확인. 리밸런싱이 예기치 않게 중지됨 `SERVICE_REBALANCING_STOPPED` 이벤트가 표시되는 경우: + 작업을 차단할 수도 있는 태스크 보호 확인 + 리밸런싱을 중단할 수도 있는 동시 서비스 배포 찾기 + 리밸런싱이 중지된 이유에 대한 추가 정보 확인을 위해 서비스 이벤트 검토 ## 서비스 리밸런싱 모범 사례 서비스 리밸런싱을 최대한 활용하려면 다음 모범 사례를 따릅니다. + **리밸런싱 작업 모니터링** - CloudWatch 경보를 설정하여 리밸런싱과 관련된 서비스 이벤트를 모니터링해 문제를 신속하게 식별합니다. + **성능 영향 고려** - 이전 태스크가 중지되기 전에 새 태스크가 시작되면 리밸런싱 작업으로 인해 리소스 사용량이 일시적으로 증가할 수 있습니다. + **전략적으로 태스크 보호 사용** - 리밸런싱 중에 종료해서는 안 되는 중요한 태스크가 있는 경우 태스크 보호 사용을 고려하세요. + **EC2 용량 계획** - EC2의 경우 모든 가용 영역에 걸쳐 효과적인 리밸런싱을 지원하기에 충분한 컨테이너 인스턴스가 있는지 확인합니다. + **리밸런싱 동작 테스트** - 프로덕션 환경에서 리밸런싱에 의존하기 전에 비프로덕션 환경에서 리밸런싱 작업 중에 서비스가 어떻게 작동하는지 테스트합니다. # 로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산 필요하다면 Elastic Load Balancing을 사용하여 서비스의 작업에 트래픽을 균등하게 분산하도록 서비스를 구성할 수 있습니다. **참고** 태스크 세트를 사용할 때 모두 Elastic Load Balancing을 사용하거나 Elastic Load Balancing을 사용하지 않도록 세트의 모든 태스크를 구성해야 합니다. AWS Fargate에서 호스팅되는 Amazon ECS 서비스는 Application Load Balancer, Network Load Balancer, Gateway Load Balancer를 지원합니다. 다음 테이블을 참조하여 사용할 로드 밸런서 유형에 대해 알아보세요. | 로드 밸런서 유형 | 다음과 같은 경우에 사용 | | --- | --- | | Application Load Balancer | HTTP/HTTPS(또는 계층 7) 트래픽을 라우팅합니다.Application Load Balancer는 Amazon ECS 서비스에 사용할 수 있는 유용한 몇 가지 기능을 제공합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/service-load-balancing.html) | | Network Load Balancer | TCP 또는 UDP(또는 계층 4) 트래픽을 라우팅합니다. | | Gateway Load Balancer | TCP 또는 UDP(또는 계층 4) 트래픽을 라우팅합니다. 방화벽, 침입 감지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 사용하세요. | 서비스에 Network Load Balancer 또는 Gateway Load Balancer에만 제공되는 기능이 필요한 경우가 아니라면 이러한 최신 기능을 활용할 수 있도록 Amazon ECS 서비스에 Application Load Balancer를 사용하는 것을 권장합니다. Elastic Load Balancing에 대한 정보와 로드 밸런서 유형의 차이점에 대한 자세한 정보는 [Elastic Load Balancing 사용 설명서](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/)를 참조하세요. 로드 밸런서에서는 사용한 만큼만 지불하면 됩니다. 자세한 정보는 [Elastic Load Balancing 요금](https://aws.amazon.com/elasticloadbalancing/pricing/)을 참조하세요. # Amazon ECS에 대한 로드 밸런서 상태 확인 파라미터 최적화 로드 밸런서는 로드 밸런서의 가용 영역에서 정상 상태의 대상에만 요청을 전송합니다. 각 대상은 대상 그룹에 등록됩니다. 로드 밸런서는 대상 그룹 상태 확인 설정을 사용하여 각 대상의 상태를 확인합니다. 대상을 등록한 후 대상은 상태 확인을 통과해야만 정상 상태로 간주됩니다. Amazon ECS는 로드 밸런서를 모니터링합니다. 로드 밸런서는 주기적으로 Amazon ECS 컨테이너에 상태 확인을 전송합니다. Amazon ECS 에이전트는 로드 밸런서를 모니터링하고 로드 밸런서가 컨테이너 상태를 보고할 때까지 기다립니다. 컨테이너가 정상 상태라고 판단하기 전에 이 작업을 수행합니다. 2개의 Elastic Load Balancing 상태 확인 파라미터가 배포 속도에 영향을 줍니다. + 상태 확인 간격: 개별 컨테이너의 대략적인 상태 확인 사이의 대략적인 시간(초)을 결정합니다. 기본적으로 로드 밸런서는 30초마다 확인합니다. 이 파라미터 이름은 다음과 같습니다. + Elastic Load Balancing API에서 `HealthCheckIntervalSeconds` + Amazon EC2 콘솔에서의 **간격** + 정상 임계값 수: 비정상 상태의 용기가 정상으로 간주되기 전에 필요한 연속된 상태 확인 성공 횟수를 결정합니다. 기본적으로 로드 밸런서는 대상 컨테이너가 정상임을 보고하기 전에 상태 확인을 5회 통과해야 합니다. 이 파라미터 이름은 다음과 같습니다. + Elastic Load Balancing API에서 `HealthyThresholdCount` + Amazon EC2 콘솔의 **정상 임계값** **중요:** 새로 등록된 대상의 경우 정상 임계값 수 설정에 관계없이 대상을 정상으로 간주하려면 한 번의 성공한 상태 확인만 필요합니다. 정상 임계값 수는 대상이 비정상 상태에서 정상 상태로 다시 전환될 때만 적용됩니다. 기본 설정에서 대상이 비정상 상태가 되었다가 복구되는 경우 컨테이너 상태를 확인하는 데 걸리는 총 시간은 2분 30초(`30 seconds * 5 = 150 seconds`)입니다. 10초 이내에 서비스가 시작되고 안정화되면 상태 확인 프로세스의 속도를 높일 수 있습니다. 프로세스 속도를 높이려면 상태 확인 간격과 정상 임계값 수를 줄입니다. + `HealthCheckIntervalSeconds`(Elastic Load Balancing API 이름) 또는 **간격**(Amazon EC2 콘솔 이름): 5 + `HealthyThresholdCount`(Elastic Load Balancing API 이름) 또는 **정상 임계값**(Amazon EC2 콘솔 이름): 2 기본 설정에서 상태 확인 프로세스는 2분 30초가 걸리는 데 비해 이 설정을 사용하면 10초가 걸립니다. Elastic Load Balancing 상태 확인에 대한 자세한 내용은 *Elastic Load Balancing 사용 설명서*의 [Health checks for your target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)를 참조하세요. # Amazon ECS에 대한 로드 밸런서 Connection Draining 파라미터 최적화 최적화를 위해 클라이언트는 컨테이너 서비스에 대한 연결 유지 연결을 유지 관리합니다. 이렇게 하면 해당 클라이언트의 후속 요청에서 기존 연결을 재사용할 수 있습니다. 컨테이너로 향하는 트래픽을 중지하려면 로드 밸런서에 알립니다. 로드 밸런서는 클라이언트가 연결 유지 연결을 종료했는지 주기적으로 확인합니다. Amazon ECS는 로드 밸런서를 모니터링하고 로드 밸런서에서 연결 유지 연결을 닫았음을 보고할 때까지 기다립니다(대상은 `UNUSED` 상태임). 대상을 `UNUSED` 상태로 전환하기 위해 로드 밸런서가 대기하는 시간을 등록 취소 지연이라고 합니다. 다음 로드 밸런서 파라미터를 구성하여 배포 속도를 높일 수 있습니다. + `deregistration_delay.timeout_seconds`: 300(기본값) 서비스의 응답 시간이 1초 미만인 경우 파라미터를 다음 값으로 설정하여 로드 밸런서가 클라이언트 및 백엔드 서비스 간 연결이 끊어질 때까지 5초만 대기하도록 합니다. + `deregistration_delay.timeout_seconds`: 5 **참고** 파일 업로드 또는 스트리밍 연결 속도가 느린 경우와 같이 요청 수명이 긴 서비스의 경우 값을 5초로 설정하지 않습니다. ## SIGTERM 응답성 Amazon ECS는 먼저 태스크에 신호를 보내 애플리케이션을 완료 및 종료해야 함을 알립니다. 이 신호는 STOPSIGNAL 명령을 사용하여 컨테이너 이미지에 정의될 수 있으며 기본적으로 SIGTERM으로 설정됩니다. 그러면 Amazon ECS에서 SIGKILL 메시지를 보냅니다. 애플리케이션이 SIGTERM을 무시하는 경우 Amazon ECS 서비스는 프로세스를 종료하기 위한 SIGTERM 신호 전송을 기다려야 합니다. Amazon ECS가 SIGKILL 메시지를 보내기 위해 대기하는 시간은 다음 Amazon ECS 에이전트 옵션으로 결정됩니다. + `ECS_CONTAINER_STOP_TIMEOUT`: 30(기본값) 컨테이너 에이전트 파라미터에 대한 자세한 내용은 GitHub의 [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md)를 참조하세요. 대기 시간을 단축하려면 Amazon ECS 에이전트 파라미터를 다음 값으로 설정합니다. + `ECS_CONTAINER_STOP_TIMEOUT`: 2 애플리케이션이 1초 넘게 걸리는 경우 값에 2를 곱하고 이 숫자를 값으로 사용합니다. 이 경우 Amazon ECS는 컨테이너가 종료될 때까지 2초 정도 기다린 다음, 애플리케이션이 중지되지 않으면 Amazon ECS에서 SIGKILL 메시지를 보냅니다. 또한 SIGTERM 신호를 트랩하고 이에 반응하도록 애플리케이션 코드를 수정할 수 있습니다. 다음은 JavaScript로 작성된 예제입니다. ``` process.on('SIGTERM', function() { server.close(); }) ``` 이 코드를 사용하면 HTTP 서버가 새 요청에 대한 수신을 중지하고 전송 중인 요청에 대한 응답을 완료한 다음 해당 이벤트 루프에 수행할 작업이 더 이상 없기 때문에 Node.js 프로세스가 종료됩니다. 이 경우 프로세스가 전송 중인 요청을 완료하는 데 500밀리초 정도밖에 걸리지 않으면 중지 제한 시간을 기다리고 SIGKILL을 받지 않고도 조기에 종료합니다. # Amazon ECS에 대한 Application Load Balancer 사용 Application Load Balancer는 애플리케이션 계층(HTTP/HTTPS)에서 라우팅 결정을 내리고, 경로 기반 라우팅을 지원하며, 클러스터의 각 컨테이너 인스턴스 상의 하나 이상의 포트로 요청을 라우팅할 수 있습니다. Application Load Balancer는 동적 호스트 포트 매핑을 지원합니다. 예를 들어, 작업의 컨테이너 정의가 NGINX 컨테이너 포트로 포트 80을 지정하고, 호스트 포트로 포트 0을 지정하면 컨테이너 인스턴스의 임시 포트 범위(예: 최신 Amazon ECS 최적화 AMI에서 32768 \$1 61000)에서 호스트 포트가 동적으로 선택됩니다. 태스크가 시작되면 NGINX 컨테이너가 인스턴스 ID와 포트의 조합으로 Application Load Balancer에 등록되고 트래픽은 해당 컨테이너에 해당하는 인스턴스 ID와 포트에 분산됩니다. 이 동적 매핑을 통해 동일한 컨테이너 인스턴스에서 단일 서비스의 다중 작업이 가능합니다. 자세한 정보는 [Application Load Balancer 사용 설명서](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)를 참조하세요. 배포 속도를 높이기 위한 파라미터 설정 모범 사례에 대한 자세한 내용은 다음을 참조하세요. + [Amazon ECS에 대한 로드 밸런서 상태 확인 파라미터 최적화](load-balancer-healthcheck.md) + [Amazon ECS에 대한 로드 밸런서 Connection Draining 파라미터 최적화](load-balancer-connection-draining.md) Amazon ECS와 함께 Application Load Balancer를 사용할 때는 다음 사항을 고려하세요. + Amazon ECS에는 작업이 생성되고 중지될 때 로드 밸런서에 대상을 등록 및 등록 취소하는 데 필요한 권한을 제공하는 서비스 연결 IAM 역할이 필요합니다. 자세한 내용은 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요. + IPv6 전용 구성의 서비스인 경우 Application Load Balancer의 대상 그룹 IP 주소 유형을 `dualstack` 또는 `dualstack-without-public-ipv4`로 설정해야 합니다. + `awsvpc` 네트워크 모드를 사용하는 작업이 있는 서비스의 경우 서비스의 대상 그룹을 만들 때 `instance`가 아닌 `ip`를 대상 유형으로 선택해야 합니다. 이는 `awsvpc` 네트워크 모드를 사용하는 태스크가 Amazon EC2 인스턴스가 아닌 탄력적 네트워크 인터페이스와 연결되기 때문입니다. + 서비스에서 HTTP/HTTPS 서비스를 위한 포트 80 및 포트 443과 같은 여러 로드 밸런싱 포트에 대한 액세스가 필요한 경우 2개의 리스너를 구성할 수 있습니다. 한 리스너는 요청을 서비스로 전달하는 HTTPS를 담당하고 다른 리스너는 HTTP 요청을 적절한 HTTPS 포트로 경로를 재지정하는 책임을 집니다. 자세한 정보는 *Application Load Balancers 사용 설명서*의 [Application Load Balancer에 리스너 생성](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html)을 참조하세요. + 로드 밸런서 서브넷 구성에는 컨테이너 인스턴스가 상주하는 모든 가용 영역이 포함되어야 합니다. + 서비스를 생성한 후에는 로드 밸런서 구성을 AWS Management Console에서 변경할 수 없습니다. AWS Copilot, AWS CloudFormation, AWS CLI 또는 SDK를 사용하여 로드 밸런서 구성을 AWS CodeDeploy 블루/그린 또는 외부가 아닌 `ECS` 롤링 배포 컨트롤러에 대해서만 변경할 수 있습니다. 로드 밸런서 구성을 추가, 업데이트 또는 제거하면 Amazon ECS가 업데이트된 Elastic Load Balancing 구성을 사용하여 새 배포를 시작합니다. 이로 인해 작업이 로드 밸런서에 등록되거나 로드 밸런서에서 등록 취소됩니다. Elastic Load Balancing 구성을 업데이트하기 전에 테스트 환경에서 이를 확인하는 것이 좋습니다. 구성을 변경하는 방법에 대한 자세한 정보는 *Amazon Elastic Container Service API Reference*(Amazon Elastic Container Service API 레퍼런스)의 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)를 참조하세요. + 서비스 작업이 로드 밸런서 상태 확인 기준에 실패하면 작업이 중단되고 다시 시작됩니다. 이 프로세스는 서비스가 원하는 실행 작업 수에 도달할 때까지 계속됩니다. + 로드 밸런서-활성화 서비스에 문제가 있는 경우, [Amazon ECS의 서비스 로드 밸런서 문제 해결](troubleshoot-service-load-balancers.md) 섹션을 참조하세요 + `instance` 대상 유형을 사용하는 경우 태스크 및 로드 밸런서는 동일한 VPC에 있어야 합니다. `ip` 대상 유형을 사용하는 경우 교차 VPC 연결이 지원됩니다. + 각 서비스에 대해 고유한 대상 그룹을 사용합니다. 여러 서비스에 대해 동일한 대상 그룹을 사용하면 서비스 배포 중에 문제가 발생할 수 있습니다. + Application Load Balancer와 연결된 대상 그룹을 지정해야 합니다. Application Load Balancer를 생성하는 방법에 대한 자세한 내용은 *Application Load Balancer*의 [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)를 참조하세요. # Amazon ECS에 대해 Network Load Balancer 사용 Network Load Balancer는 전송 계층(TCP/SSL)에서 라우팅을 결정합니다. 초당 수백만 개의 요청을 처리할 수 있습니다. 로드 밸런서가 연결을 수신하면 해시 라우팅 알고리즘 흐름에 따라 기본 규칙의 대상 그룹에서 대상을 선택합니다. 리스너 구성에 지정된 포트에서 선택한 대상에 대한 TCP 연결을 열려고 시도합니다. 헤더를 수정하지 않고 요청을 전달합니다. Network Load Balancer는 동적 호스트 포트 매핑을 지원합니다. 예를 들어, 작업의 컨테이너 정의가 NGINX 컨테이너 포트로 포트 80을 지정하고, 호스트 포트로 포트 0을 지정하면 컨테이너 인스턴스의 임시 포트 범위(예: 최신 Amazon ECS 최적화 AMI에서 32768 \$1 61000)에서 호스트 포트가 동적으로 선택됩니다. 작업이 시작되면 NGINX 컨테이너가 인스턴스 ID-포트 조합으로 Network Load Balancer에 등록되고, 트래픽은 해당 컨테이너에 해당하는 인스턴스 ID와 포트에 분산됩니다. 이 동적 매핑을 통해 동일한 컨테이너 인스턴스에서 단일 서비스의 다중 작업이 가능합니다. Network Load Balancer에 대한 자세한 정보는 [Network Load Balancer 사용 설명서](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/)를 참조하세요. 배포 속도를 높이기 위한 파라미터 설정 모범 사례에 대한 자세한 내용은 다음을 참조하세요. + [Amazon ECS에 대한 로드 밸런서 상태 확인 파라미터 최적화](load-balancer-healthcheck.md) + [Amazon ECS에 대한 로드 밸런서 Connection Draining 파라미터 최적화](load-balancer-connection-draining.md) Amazon ECS와 함께 Network Load Balancer를 사용할 때는 다음을 고려하세요. + Amazon ECS에는 작업이 생성되고 중지될 때 로드 밸런서에 대상을 등록 및 등록 취소하는 데 필요한 권한을 제공하는 서비스 연결 IAM 역할이 필요합니다. 자세한 내용은 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요. + 서비스에 5개 이상의 대상 그룹을 연결할 수 없습니다. + IPv6 전용 구성의 서비스의 경우 Network Load Balancer의 대상 그룹 IP 주소 유형을 `dualstack`으로 설정해야 합니다. + `awsvpc` 네트워크 모드를 사용하는 작업이 있는 서비스의 경우 서비스의 대상 그룹을 만들 때 `instance`가 아닌 `ip`를 대상 유형으로 선택해야 합니다. 이는 `awsvpc` 네트워크 모드를 사용하는 작업이 Amazon EC2 인스턴스가 아닌 탄력적 네트워크 인터페이스와 연결되기 때문입니다. + 로드 밸런서 서브넷 구성에는 컨테이너 인스턴스가 상주하는 모든 가용 영역이 포함되어야 합니다. + 서비스를 생성한 후에는 로드 밸런서 구성을 AWS Management Console에서 변경할 수 없습니다. AWS Copilot, AWS CloudFormation, AWS CLI 또는 SDK를 사용하여 로드 밸런서 구성을 AWS CodeDeploy 블루/그린 또는 외부가 아닌 `ECS` 롤링 배포 컨트롤러에 대해서만 변경할 수 있습니다. 로드 밸런서 구성을 추가, 업데이트 또는 제거하면 Amazon ECS가 업데이트된 Elastic Load Balancing 구성을 사용하여 새 배포를 시작합니다. 이로 인해 작업이 로드 밸런서에 등록되거나 로드 밸런서에서 등록 취소됩니다. Elastic Load Balancing 구성을 업데이트하기 전에 테스트 환경에서 이를 확인하는 것이 좋습니다. 구성을 변경하는 방법에 대한 자세한 정보는 *Amazon Elastic Container Service API Reference*(Amazon Elastic Container Service API 레퍼런스)의 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)를 참조하세요. + 서비스 작업이 로드 밸런서 상태 확인 기준에 실패하면 작업이 중단되고 다시 시작됩니다. 이 프로세스는 서비스가 원하는 실행 작업 수에 도달할 때까지 계속됩니다. + IP 주소를 대상으로 구성하고 클라이언트 IP 보존을 해제한 Gateway Load Balancer를 사용하면 요청이 Gateway Load Balancer의 프라이빗 IP 주소에서 오는 것으로 간주됩니다. 즉, Gateway Load Balancer를 사용하는 서비스는 대상 보안 그룹에서 들어오는 요청과 상태 확인을 허용하는 즉시 전 세계에 효과적으로 개방됩니다. + Fargate 태스크의 경우 플랫폼 버전 `1.4.0`(Linux) 또는 `1.0.0`(Windows)을 사용해야 합니다. + 로드 밸런서-활성화 서비스에 문제가 있는 경우, [Amazon ECS의 서비스 로드 밸런서 문제 해결](troubleshoot-service-load-balancers.md) 섹션을 참조하세요 + `instance` 대상 유형을 사용하는 경우 태스크 및 로드 밸런서는 동일한 VPC에 있어야 합니다. `ip` 대상 유형을 사용하는 경우 교차 VPC 연결이 지원됩니다. + Network Load Balancer 클라이언트 IP 주소 보존은 Fargate 대상과 호환됩니다. + 각 서비스에 대해 고유한 대상 그룹을 사용합니다. 여러 서비스에 대해 동일한 대상 그룹을 사용하면 서비스 배포 중에 문제가 발생할 수 있습니다. + Network Load Balancer와 연결된 대상 그룹을 지정해야 합니다. Network Load Balancer를 생성하는 방법에 대한 자세한 내용은 *Network Load Balancer*의 [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)를 참조하세요. **중요** 서비스의 태스크 정의가 `awsvpc` 네트워크 모드(Fargate의 경우에는 필수)를 사용하는 경우 대상 유형을 `instance`가 아닌 `ip`로 선택해야 합니다. 이는 `awsvpc` 네트워크 모드를 사용하는 작업이 Amazon EC2 인스턴스가 아닌 탄력적 네트워크 인터페이스와 연결되기 때문입니다. C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, T1 인스턴스 유형인 경우 인스턴스 ID로 인스턴스를 등록할 수 없습니다. 이러한 인스턴스 유형은 IP 주소로 등록할 수 있습니다. # Amazon ECS에 Gateway Load Balancer 사용 Gateway Load Balancer는 오픈 시스템 상호 연결(OSI) 모델의 세 번째 계층인 네트워크 계층에서 작동합니다. 모든 포트에서 모든 IP 패킷을 수신하고 리스너 규칙에 지정된 대상 그룹으로 트래픽을 전달합니다. 5튜플(TCP/UDP 흐름의 경우) 또는 3튜플(비 TCP/UDP 흐름의 경우)을 사용하여 특정 대상 어플라이언스에 대한 흐름의 연결을 유지합니다. 예를 들어, 작업의 컨테이너 정의가 NGINX 컨테이너 포트로 포트 80을 지정하고, 호스트 포트로 포트 0을 지정하면 컨테이너 인스턴스의 임시 포트 범위(예: 최신 Amazon ECS 최적화 AMI에서 32768 \$1 61000)에서 호스트 포트가 동적으로 선택됩니다. 태스크가 시작되면 NGINX 컨테이너가 인스턴스 ID와 포트의 조합으로 Gateway Load Balancer에 등록되고 트래픽은 해당 컨테이너에 해당하는 인스턴스 ID와 포트에 분산됩니다. 이 동적 매핑을 통해 동일한 컨테이너 인스턴스에서 단일 서비스의 다중 작업이 가능합니다. 자세한 내용은 *Gateway Load Balancer*에서 [Gateway Load Balancer란 무엇입니까?](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html)를 참조하세요. 배포 속도를 높이기 위한 파라미터 설정 모범 사례에 대한 자세한 내용은 다음을 참조하세요. + [Amazon ECS에 대한 로드 밸런서 상태 확인 파라미터 최적화](load-balancer-healthcheck.md) + [Amazon ECS에 대한 로드 밸런서 Connection Draining 파라미터 최적화](load-balancer-connection-draining.md) Amazon ECS와 함께 Gateway Load Balancer를 사용할 때는 다음을 고려하세요. + Amazon ECS에는 작업이 생성되고 중지될 때 로드 밸런서에 대상을 등록 및 등록 취소하는 데 필요한 권한을 제공하는 서비스 연결 IAM 역할이 필요합니다. 자세한 내용은 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요. + IPv6 전용 구성의 서비스의 경우 Gateway Load Balancer의 대상 그룹 IP 주소 유형을 `dualstack`으로 설정해야 합니다. + `awsvpc` 이외의 네트워크 모드를 사용하는 작업이 있는 서비스의 경우 게이트웨이 로드 밸런서가 지원되지 않습니다. + 로드 밸런서 서브넷 구성에는 컨테이너 인스턴스가 상주하는 모든 가용 영역이 포함되어야 합니다. + 서비스를 생성한 후에는 로드 밸런서 구성을 AWS Management Console에서 변경할 수 없습니다. AWS Copilot, AWS CloudFormation, AWS CLI 또는 SDK를 사용하여 로드 밸런서 구성을 AWS CodeDeploy 블루/그린 또는 외부가 아닌 `ECS` 롤링 배포 컨트롤러에 대해서만 변경할 수 있습니다. 로드 밸런서 구성을 추가, 업데이트 또는 제거하면 Amazon ECS가 업데이트된 Elastic Load Balancing 구성을 사용하여 새 배포를 시작합니다. 이로 인해 작업이 로드 밸런서에 등록되거나 로드 밸런서에서 등록 취소됩니다. Elastic Load Balancing 구성을 업데이트하기 전에 테스트 환경에서 이를 확인하는 것이 좋습니다. 구성을 변경하는 방법에 대한 자세한 정보는 *Amazon Elastic Container Service API Reference*(Amazon Elastic Container Service API 레퍼런스)의 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)를 참조하세요. + 서비스 작업이 로드 밸런서 상태 확인 기준에 실패하면 작업이 중단되고 다시 시작됩니다. 이 프로세스는 서비스가 원하는 실행 작업 수에 도달할 때까지 계속됩니다. + IP 주소를 대상으로 구성한 Gateway Load Balancer를 사용하면 요청이 Gateway Load Balancer의 프라이빗 IP 주소에서 오는 것으로 간주됩니다. 즉, Gateway Load Balancer를 사용하는 서비스는 대상 보안 그룹에서 들어오는 요청과 상태 확인을 허용하는 즉시 전 세계에 효과적으로 개방됩니다. + Fargate 태스크의 경우 플랫폼 버전 `1.4.0`(Linux) 또는 `1.0.0`(Windows)을 사용해야 합니다. + 로드 밸런서-활성화 서비스에 문제가 있는 경우, [Amazon ECS의 서비스 로드 밸런서 문제 해결](troubleshoot-service-load-balancers.md) 섹션을 참조하세요 + `instance` 대상 유형을 사용하는 경우 태스크 및 로드 밸런서는 동일한 VPC에 있어야 합니다. `ip` 대상 유형을 사용하는 경우 교차 VPC 연결이 지원됩니다. + 각 서비스에 대해 고유한 대상 그룹을 사용합니다. 여러 서비스에 대해 동일한 대상 그룹을 사용하면 서비스 배포 중에 문제가 발생할 수 있습니다. + Gateway Load Balancer와 연결된 대상 그룹을 지정해야 합니다. Gateway Load Balancer를 생성하는 방법에 대한 자세한 내용은 *Gateway Load Balancer*의 [Gateway Load Balancer 시작하기](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html)를 참조하세요. **중요** 서비스의 태스크 정의가 `awsvpc` 네트워크 모드(Fargate의 경우에는 필수)를 사용하는 경우 대상 유형을 `instance`가 아닌 `ip`로 선택해야 합니다. 이는 `awsvpc` 네트워크 모드를 사용하는 작업이 Amazon EC2 인스턴스가 아닌 탄력적 네트워크 인터페이스와 연결되기 때문입니다. C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, T1 인스턴스 유형인 경우 인스턴스 ID로 인스턴스를 등록할 수 없습니다. 이러한 인스턴스 유형은 IP 주소로 등록할 수 있습니다. # Amazon ECS 서비스에 여러 대상 그룹 등록 Amazon ECS 서비스는 서비스 정의에 여러 대상 그룹을 지정할 경우 여러 로드 밸런서의 트래픽을 처리하며 여러 로드 밸런스 포트를 노출합니다. 여러 대상 그룹을 지정하는 서비스를 생성하려는 경우 Amazon ECS API, SDK, AWS CLI 또는 CloudFormation 템플릿을 사용하여 서비스를 생성해야 합니다. 서비스가 생성되면 AWS Management Console에서 서비스 및 서비스에 등록된 대상 그룹을 볼 수 있습니다. 기존 서비스의 로드 밸런서 구성을 수정하려면 `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)`를 사용해야 합니다. 여러 대상 그룹은 다음 유형을 사용해 서비스 정의에서 정의될 수 있습니다. 서비스 정의의 전체 구문은 [서비스 정의 템플릿](sd-template.md) 섹션을 참조하세요. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"container_name", "containerPort":container_port }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"container_name", "containerPort":container_port } ] ``` ## 고려 사항 서비스 정의에 여러 대상 그룹을 지정할 때는 다음을 고려해야 합니다. + Application Load Balancer 또는 Network Load Balancer를 사용하는 서비스의 경우 6개 이상의 대상 그룹을 서비스에 연결할 수 없습니다. + 서비스 정의에 여러 대상 그룹을 지정하는 것은 다음 조건에서만 지원됩니다. + 서비스는 Application Load Balancer 또는 Network Load Balancer를 사용해야 합니다. + 서비스는 (`ECS`) 배포 컨트롤러 유형을 사용해야 합니다. 이는 Amazon ECS 네이티브/블루 그린 배포 또는 롤링 업데이트 배포일 수 있습니다. + 여러 대상 그룹 지정은 Fargate 및 EC2 시작 유형을 모두 사용하는 태스크를 포함하는 서비스에 대해 지원됩니다. + 여러 대상 그룹을 지정하는 서비스를 생성하는 경우 Amazon ECS 서비스 연결 역할을 생성해야 합니다. 역할은 API 요청에서 `role` 파라미터를 생략하거나 CloudFormation에서 `Role` 속성을 생략하여 생성됩니다. 자세한 정보는 [Amazon ECS에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 섹션을 참조하세요. ## 서비스 정의 예 다음은 서비스 정의에 여러 대상 그룹을 정의하는 사용 사례입니다. 서비스 정의의 전체 구문은 [서비스 정의 템플릿](sd-template.md) 섹션을 참조하세요. ### 내부 및 외부 트래픽에 대해 개별 로드 밸런서 사용 다음 사용 사례에서 서비스는 동일한 컨테이너 및 포트에 내부 트래픽 및 인터넷 경계 트래픽용으로 두 개의 로드 밸런서를 사용합니다. ``` "loadBalancers":[ //Internal ELB { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"nginx", "containerPort":8080 }, //Internet-facing ELB { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"nginx", "containerPort":8080 } ] ``` ### 동일한 컨테이너에 여러 포트 노출 다음 사용 사례에서 서비스는 하나의 로드 밸런서를 사용하지만 동일한 컨테이너에 여러 포트를 노출합니다. 예를 들어 Jenkins 컨테이너는 Jenkins 웹 인터페이스용으로 8080 포트를 노출하고 API용으로 50000 포트를 노출할 수 있습니다. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"jenkins", "containerPort":8080 }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"jenkins", "containerPort":50000 } ] ``` ### 여러 컨테이너의 포트 노출 다음 사용 사례에서 서비스는 하나의 로드 밸런서와 두 개의 대상 그룹을 사용해 각 컨테이너별로 개별 포트를 노출합니다. ``` "loadBalancers":[ { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456", "containerName":"webserver", "containerPort":80 }, { "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321", "containerName":"database", "containerPort":3306 } ] ``` # Amazon ECS 서비스 자동 조정 *자동 크기 조정*은 Amazon ECS 서비스에서 원하는 작업 수를 자동으로 늘리거나 줄이는 기능입니다. Amazon ECS는 Application Auto Scaling 서비스를 활용하여 이 기능을 제공합니다. 자세한 정보는 [Application Auto Scaling 사용 설명서](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html)를 참조하세요. Amazon ECS는 서비스의 평균 CPU 및 메모리 사용량과 함께 CloudWatch 지표를 게시합니다. 자세한 정보는 [Amazon ECS 서비스 사용률 지표](service_utilization.md) 섹션을 참조하세요. 이와 함께 다른 CloudWatch 지표를 사용하여 피크 시간에는 서비스를 확장(더 많은 태스크를 추가)하여 높은 수요를 처리하고 사용률이 낮은 기간에는 서비스를 축소(더 적은 태스크를 실행)하여 비용을 절감할 수 있습니다. Amazon ECS 서비스 Auto Scaling은 다음과 같은 유형의 Auto Scaling을 지원합니다. + [대상 지표를 사용하여 Amazon ECS 서비스 규모 조정](service-autoscaling-targettracking.md)— 특정 지표에 대한 대상 값을 기준으로 서비스가 실행하는 작업의 수를 늘리거나 줄입니다. 이 과정은 온도 조절기를 사용하여 집안 온도를 유지하는 방법과 비슷합니다. 사용자가 온도를 선택하면 나머지는 모두 온도 조절기에서 자동으로 수행됩니다. + [CloudWatch 경보를 기반으로 미리 정의된 증분을 사용하여 Amazon ECS 서비스 규모 조정](service-autoscaling-stepscaling.md)— 일련의 조정 조절(경보 위반의 크기에 따라 달라지는 단계 조절)을 기준으로 서비스가 실행하는 작업의 수를 늘리거나 줄입니다. + [예약된 조치를 사용하여 Amazon ECS 서비스 규모 조정](service-autoscaling-schedulescaling.md) - 날짜 및 시간을 기준으로 서비스가 실행하는 작업 수를 늘리거나 줄입니다. + [과거 패턴을 사용하여 예측 규모 조정으로 Amazon ECS 서비스 규모 조정](predictive-auto-scaling.md) - 과거 로드 데이터 분석을 기반으로 서비스가 실행되는 태스크 수를 늘리거나 줄여 트래픽 흐름의 일간 또는 주간 패턴을 탐지합니다. ## 고려 사항 조정 정책을 사용하는 경우 다음 고려 사항을 참조하세요. + Amazon ECS는 1분 간격으로 지표를 CloudWatch로 보냅니다. 클러스터 및 서비스가 CloudWatch로 지표를 전송할 때까지는 지표를 사용할 수 없으며, 아직 존재하지 않는 지표에 대해 CloudWatch 경보를 생성할 수 없습니다. + 조정 정책은 휴지 기간을 지원합니다. 이것은 이전의 조정 활동이 적용될 때까지 대기할 시간(초)입니다. + 확장 이벤트의 목적은 지속적이지만 과도하지는 않게 확장하는 것입니다. 서비스 Auto Scaling에서 조정 정책을 사용하여 성공적으로 확장하면 휴지 기간이 계산되기 시작합니다. 조정 정책은 더 큰 조정이 시작되거나 휴지 기간이 종료되지 않는 한 원하는 용량을 다시 늘리지 않습니다. 확장 휴지 기간이 진행되는 동안 확장 활동을 시작하여 추가된 용량은 다음 확장 활동에 대해 원하는 용량의 일부로 계산됩니다. + 축소 이벤트의 목적은 애플리케이션의 가용성을 보호하기 위해 보수적으로 축소하여 휴지 기간이 만료될 때까지 축소 활동을 차단하는 것입니다. 그러나 축소 휴지 기간 중에 다른 경보가 확장 활동을 시작하면 서비스 Auto Scaling은 대상을 즉시 확장합니다. 이 경우 축소 휴지 기간이 중지되고 완료되지 않습니다. + 서비스 스케줄러는 원하는 수를 항상 신뢰하지만 서비스에 활성화된 조정 정책과 경보가 있는 한 서비스 Auto Scaling은 사용자가 수동으로 설정한 원하는 수를 변경할 수 있습니다. + 원하는 서비스 수가 최소 용량 값 이하로 설정되어 있고 경보가 확장 활동을 시작하는 경우 서비스 Auto Scaling은 원하는 수를 최소 용량 값까지 확장한 다음 경보에 연결된 조정 정책에 따라 필요한 만큼 계속 스케일 아웃합니다. 하지만 원하는 수가 이미 최소 용량 값 미만이기 때문에 축소 활동은 원하는 수를 조정하지 않습니다. + 원하는 서비스 수가 최대 용량 값 이상으로 설정되어 있고 경보가 스케일 인 활동을 시작하는 경우 서비스 Auto Scaling은 원하는 수를 최대 용량 값까지 스케일 아웃한 다음, 경보에 연결된 조정 정책에 따라 필요한 만큼 계속 스케일 인합니다. 하지만 원하는 수가 이미 최대 용량 값을 초과하므로 확장 활동은 원하는 수를 조절하지 않습니다. + 조정 활동 중에 서비스 Auto Scaling이 시작점으로 사용하는 값은 원하는 수가 아니라 서비스에서 실제 실행 중인 태스크 수입니다. 이것이 처리 용량입니다. 이로써, 가령 추가 태스크를 배치하기에 충분한 컨테이너 인스턴스 리소스가 없는 경우 등 충족될 수 없는 과도한(불필요한) 조정을 방지합니다. 나중에 컨테이너 인스턴스 용량을 사용할 수 있는 경우 대기 중인 조정 활동이 승계되며 휴지 기간 후에 추가 조정 활동이 계속될 수 있습니다. + 수행할 작업이 없을 때 태스크 수를 0으로 조정하려면 최소 용량을 0으로 설정합니다. 대상 추적 조정 정책을 사용하는 경우 실제 용량이 0이고 지표에 워크로드 요구량이 있다고 나타나면 서비스 Auto Scaling이 확장하기 전에 하나의 데이터 포인트가 전송될 때까지 기다립니다. 이 경우 시작 지점으로 가능한 최소량만큼 확장한 다음 실제 실행 중인 작업 수를 기준으로 조정을 재개합니다. + Application Auto Scaling은 Amazon ECS 배포가 진행 중인 동안 축소 프로세스를 비활성화합니다. 그러나 배포 중에 일시 중단되지 않는 한 확장 프로세스는 계속 발생합니다. 이 동작은 외부 배포 컨트롤러를 사용하는 Amazon ECS 서비스에 적용되지 않습니다. 자세한 내용은 [서비스 Auto Scaling 및 배포](#service-auto-scaling-deployments) 섹션을 참조하세요. + Amazon ECS 작업을 위한 여러 Application Auto Scaling 옵션이 있습니다. 대상 추적이 가장 사용하기 쉬운 모드입니다. 이 옵션을 사용하는 경우 CPU 평균 사용률과 같은 지표의 목표 값을 설정하기만 하면 됩니다. 그러면 자동 스케일러가 해당 값을 달성하는 데 필요한 작업 수를 자동으로 관리합니다. 단계 조정을 사용하면 조정 지표의 특정 임계값과 임계값을 초과했을 때 추가 또는 제거할 작업 수를 정의하므로 수요 변화에 더 빠르게 대응할 수 있습니다. 더욱이 임계값 경보를 위반하는 시간을 최소화하여 수요 변화에 매우 빠르게 대응할 수 있습니다. 서비스 오토 스케일링 모범 사례에 대한 자세한 내용은 [Amazon ECS 서비스 오토 스케일링 최적화](capacity-autoscaling-best-practice.md) 섹션을 참조하세요. ## 서비스 Auto Scaling 및 배포 Application Auto Scaling은 Amazon ECS 배포가 진행 중인 동안 축소 프로세스를 비활성화합니다. 그러나 배포 중에 일시 중단되지 않는 한 확장 프로세스는 계속 발생합니다. 이 동작은 외부 배포 컨트롤러를 사용하는 Amazon ECS 서비스에 적용되지 않습니다. 배포가 진행되는 동안 확장 프로세스를 일시 중단하려면 다음 단계를 수행합니다. 1. [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html) 명령을 호출하여 Application Auto Scaling에서 확장 가능한 대상과 연결된 서비스의 리소스 ID를 지정합니다(예:`service/default/sample-webapp`). 출력 결과를 기록합니다. 다음 명령을 호출할 때 필요합니다. 1. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 명령을 호출하여 리소스 ID, 네임스페이스 및 확장 가능한 차원을 지정합니다. `DynamicScalingInSuspended` 및 `DynamicScalingOutSuspended` 모두에 대해 `true`를 지정합니다. 1. 배포가 완료되면 [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 명령을 호출하여 조정을 재개할 수 있습니다. 자세한 정보는 [Application Auto Scaling의 조정 일시 중지 및 재개](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html)를 참조하세요. # 대상 지표를 사용하여 Amazon ECS 서비스 규모 조정 대상 추적 조정 정책을 사용하는 경우 지표를 선택하고 목표 값을 설정합니다. Amazon ECS 서비스 Auto Scaling은 조정 정책을 제어하는 CloudWatch 경보를 생성 및 관리하고 지표와 대상 값을 기준으로 조정 조절을 계산합니다. 조정 정책은 필요에 따라 서비스 태스크를 추가하거나 제거하여 측정치를 지정된 대상 값과 같거나 비슷하게 유지합니다. 측정치를 대상 값과 비슷하게 유지하는 것 외에도, 대상 추적 조정 정책은 변동하는 로드 패턴으로 인한 측정치 변동에 맞게 조정하고 서비스에서 실행 중인 작업 수의 급격한 변동을 최소화합니다. 대상 추적 정책을 사용하면 CloudWatch 경보 및 조정 작업을 수동으로 정의할 필요가 없습니다. Amazon ECS에서는 사용자가 설정하는 대상에 따라 자동으로 처리됩니다. 대상 추적 정책을 사용할 때 다음을 고려하세요. + 대상 추적 조정 정책은 지정한 지표가 목표 값을 초과할 때 한해서 확장을 수행해야 합니다. 대상 추적 조정 정책에서는 지정한 지표가 목표 값보다 작을 때 확장할 수 없습니다. + 대상 추적 조정 정책에서는 지정한 지표에 데이터가 부족할 때 조정을 수행하지 않습니다. 데이터가 부족하다고 해서 사용량이 낮은 것으로 해석하지 않기 때문에 축소를 수행하지 않습니다. + 목표 값과 실제 지표 데이터 포인트 사이에는 차이가 발생할 수 있습니다. 서비스 Auto Scaling이 추가하거나 제거할 용량을 결정할 때마다 항상 반올림 또는 내림을 통해 어림짐작으로 동작하기 때문입니다. 이는 용량을 부족하게 추가하거나 너무 많이 제거하는 일을 방지하기 위해서입니다. + 애플리케이션 가용성을 보장하기 위해 서비스는 지표에 비례하여 가능한 한 빠르게 확장하지만, 비교적 점진적으로 축소합니다. + Application Auto Scaling은 Amazon ECS 배포가 진행 중인 동안 축소 프로세스를 비활성화합니다. 그러나 배포 중에 일시 중단되지 않는 한 확장 프로세스는 계속 발생합니다. 이 동작은 외부 배포 컨트롤러를 사용하는 Amazon ECS 서비스에 적용되지 않습니다. 자세한 내용은 [서비스 Auto Scaling 및 배포](service-auto-scaling.md#service-auto-scaling-deployments) 섹션을 참조하세요. + 각 정책이 다른 측정치를 사용한다면 한 Amazon ECS 서비스에 대해 여러 대상 추적 조정 정책을 생성할 수 있습니다. 서비스 Auto Scaling은 항상 가용성을 우선시하므로, 대상 추적 정책이 확장 또는 축소를 허용하는지에 따라 그 동작이 달라집니다. 대상 추적 정책 중 하나라도 스케일 아웃할 준비가 된 경우 서비스를 스케일 아웃하지만 모든 대상 추적 정책(스케일 인 부분이 켜진 상태)이 스케일 인할 준비가 된 경우에만 스케일 인합니다. + 서비스 Auto Scaling의 대상 추적 조정 정책에서 관리되는 CloudWatch 경보는 편집하거나 삭제하지 마세요. 조정 정책을 삭제하면 서비스 Auto Scaling에서 경보가 자동으로 삭제됩니다. + 대상 추적 조정 정책에 대한 `ALBRequestCountPerTarget` 지표는 블루/그린 배포 유형을 지원하지 않습니다. 대상 추적 조정 정책에 대한 자세한 내용을 알아보려면 *Application Auto Scaling 사용 설명서*의 [대상 추적 조정 정책](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)을 참조하세요. # Amazon ECS 서비스 오토 스케일링에 대한 대상 추적 규모 조정 정책 생성 서비스에서 원하는 태스크 수가 Amazon ECS에서 자동으로 증가하거나 감소하는 대상 추적 규모 조정 정책을 생성합니다. 대상 추적은 대상 지표 값을 기반으로 작동합니다. ## 콘솔 1. 서비스를 생성 및 업데이트하는 표준 IAM 권한 외에도 추가 권한이 필요합니다. 자세한 내용은 [Amazon ECS 서비스 Auto Scaling에 필요한 IAM 권한](auto-scaling-IAM.md) 섹션을 참조하세요. 1. 정책에 사용되는 지표를 결정합니다. 다음과 같은 지표를 사용할 수 있습니다. + **ECSServiceAverageCPUUtilization** - 서비스에서 사용되는 평균 CPU 사용률입니다. + **ECSServiceAverageMemoryUtilization** - 서비스에서 사용되는 평균 메모리 사용률입니다. + **ALBRequestCountPerTarget** - 작업에 이상적으로 수신되는 분당 평균 요청 수입니다. 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 섹션에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 나타납니다. 1. **태스크 수 설정**을 선택합니다. 1. **Amazon ECS 서비스 태스크 수**에서 **오토 스케일링 사용**을 선택합니다. **태스크 수 섹션**이 나타납니다. 1. **작업의 최소 개수**에 서비스 Auto Scaling에서 사용할 작업 수의 하한을 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. 사용할 서비스 오토 스케일링에 대한 태스크 수의 상한을 **최대**에 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. **저장**을 선택합니다. 정책 페이지가 나타납니다. 1. **규모 조정 정책 생성**을 선택합니다. **정책 생성** 페이지가 나타납니다. 1. **조정 정책 유형(Scaling policy type)**에서 **대상 추적(Target tracking)**을 선택합니다. 1. **정책 이름(Policy name)**에 정책 이름을 입력합니다. 1. **지표 유형**에는 옵션 목록 중에서 지표를 선택합니다. 1. **목표 사용률**에는 Amazon ECS에서 유지 관리되어야 하는 태스크의 백분율에 대한 대상 값을 입력합니다. 서비스 오토 스케일링에서는 평균 사용률이 목표 사용률에 도달하거나 사용자가 지정한 최대 태스크 수에 도달할 때까지 용량이 스케일 아웃됩니다. 1. **추가 설정**에서 다음을 수행합니다 1. **스케일 인 휴지 기간**에는 스케일 인 활동 완료 후 다른 스케일 인 활동이 시작될 수 있는 시간(초)을 입력합니다. 1. **스케일 아웃 휴지 기간**에는 이전 스케일 아웃 활동이 적용될 때까지 대기하는 시간(초)을 입력합니다. 1. 스케일 아웃 정책만 생성하려면 **스케일 인 비활성화**를 선택합니다. 1. **규모 조정 정책 생성**을 선택합니다. ## AWS CLI 1. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 명령을 사용하여 Amazon ECS 서비스를 조정 가능 대상으로 등록합니다. 1. [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 명령을 사용하여 조정 정책을 생성합니다. # CloudWatch 경보를 기반으로 미리 정의된 증분을 사용하여 Amazon ECS 서비스 규모 조정 단계 조정 정책을 사용하여 조정 프로세스를 호출하는 CloudWatch 경보를 생성하고 관리합니다. 경보 위반이 발생하면 해당 경보와 관련된 규모 조정 정책이 Amazon ECS에서 시작됩니다. 단계 규모 조정 정책에서는 단계 조정이라는 조정 세트를 통해 태스크 규모가 조정됩니다. 조정 크기는 경보 위반 규모에 따라 다릅니다. + 첫 번째 임계값을 초과한 위반의 경우 Amazon ECS에서는 첫 번째 단계 조정이 적용됩니다. + 두 번째 임계값을 초과한 위반의 경우 Amazon ECS에서는 두 번째 단계 조정이 적용되는 식으로 진행됩니다. 목표 추적 조정 정책을 사용하여 목표당 평균 요청 수 또는 평균 CPU 사용률과 같은 지표에 따라 조정하는 것이 좋습니다 용량이 증가할 때 감소하고 용량이 감소할 때 증가하는 지표를 사용하여 비례적으로 스케일 아웃하거나 대상 추적을 사용하여 작업 수를 늘릴 수 있습니다. 이는 애플리케이션에 대한 수요 곡선을 Amazon ECS에서 긴밀하게 따르는 데 도움이 됩니다. # Amazon ECS 서비스 오토 스케일링에 대한 단계 규모 조정 정책 생성 서비스에서 원하는 태스크 수가 Amazon ECS에서 자동으로 증가하거나 감소하는 단계 규모 조정 정책을 생성합니다. 단계 규모 조정은 경보 위반의 크기에 따라 달라지는 단계 조정이라는 규모 조정 세트를 기반으로 실행됩니다. ## 콘솔 1. 서비스를 생성 및 업데이트하는 표준 IAM 권한 외에도 추가 권한이 필요합니다. 자세한 내용은 [Amazon ECS 서비스 Auto Scaling에 필요한 IAM 권한](auto-scaling-IAM.md) 섹션을 참조하세요. 1. 정책에 사용되는 지표를 결정합니다. 다음과 같은 지표를 사용할 수 있습니다. + **ECSServiceAverageCPUUtilization** - 서비스에서 사용되는 평균 CPU 사용률입니다. + **ECSServiceAverageMemoryUtilization** - 서비스에서 사용되는 평균 메모리 사용률입니다. + **ALBRequestCountPerTarget** - 작업에 이상적으로 수신되는 분당 평균 요청 수입니다. 1. 지표에 대한 CloudWatch 경보를 생성합니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [정적 임계값을 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)을 참조하세요. 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 섹션에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 나타납니다. 1. **태스크 수 설정**을 선택합니다. 1. **Amazon ECS 서비스 태스크 수**에서 **오토 스케일링 사용**을 선택합니다. **태스크 수 섹션**이 나타납니다. 1. **작업의 최소 개수**에 서비스 Auto Scaling에서 사용할 작업 수의 하한을 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. 사용할 서비스 오토 스케일링에 대한 태스크 수의 상한을 **최대**에 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. **저장**을 선택합니다. 정책 페이지가 나타납니다. 1. **규모 조정 정책 생성**을 선택합니다. **정책 생성** 페이지가 나타납니다. 1. **규모 조정 정책 유형**에서 **단계 규모 조정**을 선택합니다. 1. 스케일 아웃 속성을 구성합니다. **태스크에 추가되는 단계**에서 다음을 수행합니다. 1. **정책 이름(Policy name)**에 정책 이름을 입력합니다. 1. **CloudWatch 경보 이름**에서 CloudWatch 경보를 선택합니다. 1. **지표 집계 유형**에는 선택한 지표가 정의된 임계값과 비교되는 방식을 선택합니다. 1. **조정 유형**에는 조정이 태스크 수 변경 또는 작업 백분율 변경에 따라 달라지는지 여부를 선택합니다. 1. **취할 조치**에는 취할 조치의 값을 입력합니다. **단계 추가**를 선택하여 추가 조치를 추가합니다. 1. 스케일 인 속성을 구성합니다. **태스크 제거 단계**에서 다음을 수행합니다. 1. **정책 이름(Policy name)**에 정책 이름을 입력합니다. 1. **CloudWatch 경보 이름**에서 CloudWatch 경보를 선택합니다. 1. **지표 집계 유형**에는 선택한 지표가 정의된 임계값과 비교되는 방식을 선택합니다. 1. **조정 유형**에는 조정이 태스크 수 변경 또는 작업 백분율 변경에 따라 달라지는지 여부를 선택합니다. 1. **취할 조치**에는 취할 조치의 값을 입력합니다. **단계 추가**를 선택하여 추가 조치를 추가합니다. 1. **휴지 기간**에 이전 조정 활동이 적용될 때까지 대기하는 시간(초)을 입력합니다. 추가 정책의 경우 이 시간은 스케일 아웃 활동 이후 조정 정책이 스케일 인 활동을 차단하고 한 번에 스케일 아웃할 수 있는 작업 수를 제한하는 시간입니다. 제거 정책의 경우 스케일 인 활동 이후 다른 스케일 인 활동을 시작하기 전까지 경과해야 하는 시간입니다. 1. **규모 조정 정책 생성**을 선택합니다. ## AWS CLI 1. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) 명령을 사용하여 Amazon ECS 서비스를 조정 가능 대상으로 등록합니다. 1. [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 명령을 사용하여 조정 정책을 생성합니다. # 예약된 조치를 사용하여 Amazon ECS 서비스 규모 조정 예약된 조정을 사용하면 특정 시간에 태스크 수가 증가하거나 감소하는 예약된 조치를 생성하여 예측 가능한 로드 변경을 기반으로 애플리케이션의 자동 규모 조정을 설정할 수 있습니다. 이를 통해 예측 가능한 부하 변화에 맞춰 애플리케이션 규모를 사전에 조정할 수 있습니다. 이러한 예약된 규모 조정 작업을 통해 비용과 성능을 최적화할 수 있습니다. 주중 트래픽 피크를 처리할 충분한 태스크 수가 애플리케이션에 있지만, 다른 시간에는 태스크가 과도하게 프로비저닝되지 않습니다. 예약된 조정 및 조정 정책을 함께 사용하면 규모 조정에 대한 예방적 및 대응적 접근 방식의 이점을 모두 얻을 수 있습니다. 예약된 규모 조정 조치 실행 후 규모 조정 정책에서는 태스크 수의 추가 규모 조정 여부에 대한 결정이 계속될 수 있습니다. 이는 애플리케이션의 로드를 처리할 충분한 태스크 수를 확보하는 데 도움이 됩니다. 수요에 일치하도록 애플리케이션 규모가 조정되는 동안 현재 용량은 예약한 조치 따라 설정된 설정한 최소 및 최대 태스크 수 범위여야 합니다. AWS CLI를 사용하여 일정 조정을 구성할 수 있습니다. 예약된 조정을 사용하는 방법에 대한 자세한 내용은 *Application Auto Scaling 사용 설명서*의 [Scheduled Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)을 참조하세요. # Amazon ECS 서비스 규모 조정에 대한 예약된 조치 생성 날짜 및 시간을 기준으로 서비스가 실행되는 태스크 수가 Amazon ECS에서 증가하거나 감소하는 예정된 조치를 생성합니다. ## 콘솔 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 단원에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 나타납니다. 1. **서비스 오토 스케일링**을 선택합니다. 서비스 오토 스케일링 페이지가 나타납니다. 1. 서비스 오토 스케일링을 구성하지 않은 경우 **작업 수 설정**을 선택합니다. **Amazon ECS 서비스 작업 수** 섹션이 나타납니다. **Amazon ECS 서비스 작업 수**에서 **서비스 오토 스케일링 사용을 선택하여 서비스의 원하는 작업 수를 조정**합니다. **태스크 수 섹션**이 나타납니다. 1. **작업의 최소 개수**에 서비스 Auto Scaling에서 사용할 작업 수의 하한을 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. 사용할 서비스 오토 스케일링에 대한 태스크 수의 상한을 **최대**에 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. **저장 선택**을 선택합니다. 정책 페이지가 나타납니다. 1. **예약된 작업**과 **생성**을 차례로 선택합니다. **예약된 작업 생성** 페이지가 나타납니다. 1. **액션 이름**에 고유한 이름을 입력합니다. 1. **시간대**에서 시간대를 선택합니다. 나열된 모든 표준 시간대는 IANA 표준 시간대 데이터베이스에서 가져온 것입니다. 자세한 내용은 [tz 데이터베이스 시간대 목록](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)을 참조하세요. 1. **시작 시간**에는 작업이 시작되는 **날짜**와 **시간을** 입력합니다. 반복되는 일정을 선택한 경우, 시작 시간은 일련의 반복에서 첫 번째 예약된 작업이 실행되는 시점을 정의합니다. 1. **Recurrence(반복)**에서 사용 가능한 옵션 중 하나를 선택합니다. + 반복되는 일정에 따라 규모를 조정하려면 예약된 작업이 Amazon ECS에서 실행되는 빈도를 선택합니다. + **Rate**로 시작하는 옵션을 선택하면 cron 표현식이 자동으로 생성됩니다. + **Cron**을 선택하는 경우, 작업을 수행하는 시기를 지정하는 Cron 식을 입력합니다. + 한 번만 규모를 조정하려면 **한 번**을 선택합니다. 1. **태스크 조정**에서 다음을 수행합니다. + **최소**에는 서비스가 실행되어야 하는 최소 태스크 수를 입력합니다. + **최대**에는 서비스가 실행되어야 하는 최대 작업 수를 입력합니다. 1. **예약된 작업 생성**을 선택합니다. ## CLI 다음과 같이 AWS CLI를 사용하여 서비스의 예약된 규모 조정 정책을 구성합니다. *user input placeholder*를 사용자의 정보로 바꿉니다. **예: 일회성 조정** `--start-time "YYYY-MM-DDThh:mm:ssZ"`와 `--MinCapacity` 및 `--MaxCapacity` 옵션 중 하나 또는 둘 다와 함께 다음 [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) 명령을 사용합니다. ``` aws application-autoscaling put-scheduled-action --service-namespace ecs \ --resource-id service/my-cluster/my-service \ --scheduled-action-name my-one-time-schedule \ --start-time 2021-01-30T12:00:00 \ --scalable-target-action MinCapacity=3,MaxCapacity=10 ``` **예: 반복되는 일정으로 조정 예약** 다음 [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) 명령을 사용합니다. 모든 *사용자 입력*을 사용자의 값으로 바꿉니다. ``` aws application-autoscaling put-scheduled-action --service-namespace ecs \ --resource-id service/my-cluster/my-service \ --scheduled-action-name my-recurring-action \ --schedule "rate(5 hours)" \ --start-time 2021-01-30T12:00:00 \ --end-time 2021-01-31T22:00:00 \ --scalable-target-action MinCapacity=3,MaxCapacity=10 ``` 지정된 반복 일정은 UTC 시간대를 기반으로 실행됩니다. 다른 시간대를 지정하려면 `--time-zone` 옵션을 포함하고 IANA 시간대의 이름을 다음 예와 같이 지정합니다. ``` --time-zone "America/New_York" ``` 자세한 내용은 [tz 데이터베이스 시간대 목록](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)을 참조하세요. # 과거 패턴을 사용하여 예측 규모 조정으로 Amazon ECS 서비스 규모 조정 예측 규모 조정에서는 트래픽 흐름의 과거 로드 데이터 조사를 통해 일간 또는 주간 패턴이 분석됩니다. 그런 다음에 이 분석이 향후 필요성을 예측하고 필요에 따라 서비스의 태스크 미리 늘리는 데 사용됩니다. 예측 오토 스케일링은 다음과 같은 상황에서 가장 유용합니다. + 주기적 트래픽 - 정규 업무 시간에는 리소스 사용이 증가하고 저녁과 주말에는 리소스 사용이 감소했습니다. + 반복적인 온/오프 워크로드 패턴 - 배치 처리, 테스트 또는 주기적 데이터 분석이 예에 포함됩니다. + 초기화 시간이 오래 걸리는 애플리케이션 - 현저한 대기 시간의 원인이 되는 스케일 아웃 이벤트 동안 애플리케이션 성능에 영향을 줄 수 있습니다. 규칙적인 패턴으로 애플리케이션 초기화에 시간이 오래 걸리고 트래픽이 증가하는 경우 예측 규모 조정 사용을 고려해야 합니다. 대상 추적 또는 단계 규모 조정과 같은 동적 조정 정책을 단독으로 사용하는 대신에 예상되는 로드에 대한 태스크 수를 사전에 늘려 더 빠르게 규모를 조정할 수 있습니다. 태스크 수를 과도하게 프로비저닝할 가능성을 방지하는 데 도움이 되므로 예측 규모 조정을 통해 잠재적으로 비용도 절감할 수도 있습니다. 예컨대, 업무 시간 중에는 사용량이 많고 밤새 사용량이 줄어드는 애플리케이션을 생각해 보겠습니다. 각 영업일이 시작될 때 예측 규모 조정은 트래픽이 처음 유입되기 전에 태스크를 스케일 아웃할 수 있습니다. 이를 통해 사용률이 낮은 기간에서 높은 기간으로 전환될 때 애플리케이션이 고가용성과 성능을 유지할 수 있습니다. 동적 조정이 변화하는 트래픽에 대응할 때까지 기다릴 필요가 없습니다. 또한 애플리케이션의 로드 패턴을 검토하고 예약된 조정을 사용하여 적절한 태스크를 예약하는 데 시간을 할애할 필요가 없습니다. 예측 크기 조정은 기본 컴퓨팅 용량(예: EC2 또는 Fargate)의 규모 조정과 독립적으로 서비스의 태스크 규모를 조정하는 서비스 수준 기능입니다. Fargate의 경우, AWS는 태스크 요구 사항에 따라 기본 용량을 관리하고 자동으로 규모를 조정합니다. EC2 용량의 경우, Auto Scaling 그룹 용량 공급자를 사용하여 태스크의 규모 조정 요구 사항에 따라 기본 EC2 인스턴스 규모를 자동으로 조정할 수 있습니다. **Topics** + [예측 규모 조정 개요](#predictive-auto-scaling-overview) + [예측 조정 정책 생성](predictive-scaling-create-policy.md) + [예측적 조정 정책 평가](predictive-scaling-graphs.md) + [예측 재정의](predictive-scaling-overriding-forecast-capacity.md) + [사용자 정의 지표 사용](predictive-scaling-custom-metrics.md) ## Amazon ECS에서 예측 크기 조정이 작동하는 방식 여기에서 예측 규모 조정 사용에 대한 고려 사항, 작동 방식 및 제한 사항에 대해 알아볼 수 있습니다. ### 예측 규모 조정 사용 시 고려 사항 + 예측 규모 조정이 워크로드에 적합한지 확인하는 것이 좋습니다. **예측 전용** 모드에서 규모 조정 정책을 구성하여 이를 확인하고 콘솔의 권장 사항을 참조할 수 있습니다. 예측 규모 조정을 사용하기 전에 예측 및 권장 사항을 평가해야 합니다. + 예측 규모 조정에서 예측이 시작될 수 있으려면 최소 24시간 동안의 기록 데이터가 필요합니다. 사용 가능한 기록 데이터가 많을수록 예측이 더 효과적이며 2주 분량이 이상적입니다. 또한 Amazon ECS 서비스를 삭제하고 새 서비스를 생성할 때 예측 규모 조정에서 새 예측이 생성될 수 있도록 24시간을 기다려야 합니다. 속도를 높이는 한 가지 방법은 사용자 지정 지표를 사용하여 이전 및 새 Amazon ECS 서비스 전체의 지표를 집계하는 것입니다. + 애플리케이션의 전체 로드를 정확하게 나타내고 확장해야 하는 애플리케이션의 측면인 부하 지표를 선택합니다. + 예측 규모 조정을 통한 동적 규모 조정은 애플리케이션에 대한 수요를 면밀히 따라가는 데 도움이 되므로 소강 상태인 동안 스케일 인하고 예기치 않게 트래픽이 증가하는 동안 스케일 아웃할 수 있습니다. 여러 규모 조정 정책이 활성화된 경우, 각 정책에서는 원하는 태스크 수가 독립적으로 결정되고 원하는 태스크 수가 최댓값으로 설정됩니다. + 실시간 패턴과 과거 패턴을 모두 기반으로 하여 애플리케이션 규모가 조정되도록 대상 추적 또는 단계 규모 조정과 같은 동적 규모 조정 정책과 함께 예측 규모 조정을 사용할 수 있습니다. 예측 규모 조정 자체로는 태스크가 스케일 인되지 않습니다. + `register-scalable-target` API를 직접적으로 호출할 때 사용자 지정 역할을 사용하는 경우 활성화된 SLR만 예측 규모 조정 정책과 연동한다는 오류가 발생할 수 있습니다. 이 경우에는 role-arn이 없는 `register-scalable-target`을 다시 직접적으로 호출해야 합니다. 확장 가능한 대상을 등록할 때 SLR을 사용하고 `put-scaling-policy` API를 직접적으로 호출합니다. ### 예측 조정의 작동 방식 모니터링하고 분석할 CloudWatch 지표가 지정되는 예측 규모 조정 정책을 생성하여 예측 규모 조정을 사용합니다. 예측 규모 조정에서 미래 값 예측이 시작되려면 예측 규모 조정에 24시간 이상의 데이터가 있어야 합니다. 정책을 생성한 후 예측 조정은 패턴을 식별하기 위해 지난 14일까지의 지표 데이터를 분석하기 시작합니다. 이 분석은 향후 48시간의 요구 사항 시간별 예측 생성에 사용됩니다. 최신 CloudWatch 데이터를 사용하여 6시간마다 예측이 업데이트됩니다. 새로운 데이터가 들어오면 예측 규모 조정을 통해 향후 예측의 정확도가 지속적으로 개선됩니다. 예측 조정을 처음 활성화하면 *예측 전용* 모드에서 실행됩니다. 이 모드로 예측이 생성되지만, 해당 예측을 기반으로 Amazon ECS 서비스의 규모가 조정되지는 않습니다. 따라서 예측의 정확성과 적합성을 평가할 수 있습니다. `GetPredictiveScalingForecast` API 작업 또는 AWS Management Console을 사용하여 예측 데이터를 봅니다. 예측 규모 조정 사용을 시작하기로 결정하면 규모 조정 정책을 *예측 및 규모 조정* 모드로 전환합니다. 이 모드에서는 다음과 같이 진행됩니다. 기본적으로 해당 시간의 예측을 기반으로 매시간 시작 시 Amazon ECS 서비스의 규모가 조정됩니다. `PutScalingPolicy` API 작업의 `SchedulingBufferTime` 속성을 사용하여 더 일찍 시작하도록 선택할 수 있습니다. 그러면 예측된 수요에 앞서 새 태스크가 시작되고 부팅되어 트래픽을 처리할 준비가 될 시간이 주어집니다. ### 최대 태스크 한도 규모 조정을 위해 Amazon ECS 서비스를 등록할 때 서비스당 시작할 수 있는 최대 태스크 수를 정의합니다. 기본적으로 규모 조정 정책이 설정되면 태스크 수를 최대한도보다 높게 늘릴 수 없습니다. 그 대신에 예측이 Amazon ECS 서비스의 최대 태스크 수에 근접하거나 이를 초과하는 경우 서비스의 최대 태스크 수가 자동으로 증가하도록 허용할 수 있습니다. **주의** 최대 태스크 수가 자동으로 증가하도록 허용할 때는 주의해야 합니다. 증가한 최대 태스크 수를 모니터링하고 관리하지 않으면 의도한 것보다 더 많은 태스크가 시작될 수 있습니다. 그러면 증가한 최대 태스크 수는 수동으로 업데이트할 때까지 Amazon ECS 서비스의 새로운 정상 최대 태스크 수가 됩니다. 최대 태스크 수는 원래 최대 태스크 수로 자동으로 다시 감소하지 않습니다. ### 지원되는 리전 + 미국 동부(버지니아 북부) + 미국 동부(오하이오) + 미국 서부(캘리포니아 북부) + 미국 서부(오리건) + 아프리카(케이프타운) + 아시아 태평양(홍콩) + 아시아 태평양(자카르타) + 아시아 태평양(뭄바이) + 아시아 태평양(오사카) + 아시아 태평양(서울) + 아시아 태평양(싱가포르) + 아시아 태평양(시드니) + 아시아 태평양(도쿄) + 캐나다(중부) + 중국(베이징) + 중국(닝샤) + 유럽(프랑크푸르트) + 유럽(아일랜드) + 유럽(런던) + 유럽(밀라노) + 유럽(파리) + 유럽(스톡홀름) + 중동(바레인) + 남아메리카(상파울루) + AWS GovCloud(미국 동부) + AWS GovCloud(미국 서부) # Amazon ECS 서비스 오토 스케일링에 대한 예측 규모 조정 정책 생성 기록 데이터를 기반으로 서비스가 실행되는 태스크 수가 Amazon ECS에서 증가하거나 감소하는 예측 규모 조정 정책을 생성합니다. **참고** 예측이 생성될 수 있으려면 새 서비스에서 최소 24시간의 데이터가 제공되어야 합니다. ## 콘솔 1. 서비스를 생성 및 업데이트하는 표준 IAM 권한 외에도 추가 권한이 필요합니다. 자세한 내용은 [Amazon ECS 서비스 Auto Scaling에 필요한 IAM 권한](auto-scaling-IAM.md) 섹션을 참조하세요. 1. 정책에 사용되는 지표를 결정합니다. 다음과 같은 지표를 사용할 수 있습니다. + **ECSServiceAverageCPUUtilization** - 서비스에서 사용되는 평균 CPU 사용률입니다. + **ECSServiceAverageMemoryUtilization** - 서비스에서 사용되는 평균 메모리 사용률입니다. + **ALBRequestCountPerTarget** - 작업에 이상적으로 수신되는 분당 평균 요청 수입니다. 그 대신에 사용자 지정 지표를 사용할 수 있습니다. 다음과 같은 값을 정의해야 합니다. + 로드 - 애플리케이션의 전체 로드를 정확하게 나타내는 지표이며, 규모 조정 시 가장 중요한 애플리케이션 측면입니다. + 규모 조정 지표 - 애플리케이션에 이상적인 사용률에 대한 최상의 예측기입니다. 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 단원에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 나타납니다. 1. **서비스 오토 스케일링**을 선택한 다음 **작업 수 설정**을 선택합니다. 1. **Amazon ECS 서비스 태스크 수**에서 **오토 스케일링 사용**을 선택합니다. **태스크 수 섹션**이 나타납니다. 1. **작업의 최소 개수**에 서비스 Auto Scaling에서 사용할 작업 수의 하한을 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. 사용할 서비스 오토 스케일링에 대한 태스크 수의 상한을 **최대**에 입력합니다. 바람직한 수는 이 숫자 이내여야 합니다. 1. **저장**을 선택합니다. 정책 페이지가 나타납니다. 1. **규모 조정 정책 생성**을 선택합니다. **정책 생성** 페이지가 나타납니다. 1. **규모 조정 정책 유형**에는 **예측 규모 조정**을 선택합니다. 1. **정책 이름(Policy name)**에 정책 이름을 입력합니다. 1. **지표 쌍**에는 옵션 목록 중에서 지표를 선택합니다. **Application Load Balancer request count per target(대상당 Application Load Balancer 요청 수)**을 선택한 경우, **Target group(대상 그룹)**에서 대상 그룹을 선택합니다. **대상별 Application Load Balancer 요청 수**는 서비스에 Application Load Balancer 대상 그룹을 연결한 경우에만 지원됩니다. **사용자 지정 지표 쌍**을 선택하는 경우 **로드 지표** 및 **규모 조정 지표**의 목록에서 개별 지표를 선택합니다. 1. **목표 사용률**에는 Amazon ECS에서 유지 관리되어야 하는 태스크의 백분율에 대한 대상 값을 입력합니다. 서비스 오토 스케일링에서는 평균 사용률이 목표 사용률에 도달하거나 사용자가 지정한 최대 태스크 수에 도달할 때까지 용량이 스케일 아웃됩니다. 1. **규모 조정 정책 생성**을 선택합니다. ## AWS CLI 다음과 같이 AWS CLI를 사용하여 Amazon ECS 서비스에 대한 예측 규모 조정 정책을 구성합니다. *user input placeholder*를 사용자의 정보로 바꿉니다. 지정 가능한 CloudWatch 지표에 대한 자세한 내용은 *Amazon EC2 Auto Scaling API 참조*의 [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)을 참조하세요. ### 예제 1: 사전 정의된 메모리가 있는 예측 규모 조정 정책입니다. 다음은 사전 정의된 메모리 구성이 있는 예제 정책입니다. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 40, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceMemoryUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` 다음 예제에서는 지정된 구성 파일로 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 명령을 실행하여 정책을 생성하는 것을 보여줍니다. ``` aws application-autoscaling put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` 이 명령이 제대로 실행되면 정책의 ARN이 반환됩니다. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` ### 예제 2: 사전 정의된 CPU가 있는 예측 규모 조정 정책입니다. 다음은 사전 정의된 CPU 구성이 있는 예제 정책입니다. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 0.00000004, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceCPUUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` 다음 예제에서는 지정된 구성 파일로 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 명령을 실행하여 정책을 생성하는 것을 보여줍니다. ``` aws aas put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` 이 명령이 제대로 실행되면 정책의 ARN이 반환됩니다. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` # Amazon ECS에 대한 예측 규모 조정 정책 평가 예측 규모 조정 정책을 사용하여 서비스 규모를 조정하기 전에 Amazon ECS 콘솔에서 정책에 대한 권장 사항과 기타 데이터를 검토합니다. 이는 예측의 정확성이 확인될 때까지 예측적 조정 정책이 실제 용량을 조정하는 것을 원하지 않기 때문에 중요합니다. 서비스가 새로운 경우 첫 번째 예측을 생성하는 데 24시간이 걸립니다. AWS에서는 예측을 생성할 때 기록 데이터를 사용합니다. 서비스에 아직 최근 기록 데이터가 많지 않은 경우, 예측 규모 조정에서는 현재 사용 가능한 기록 집계에서 생성된 집계로 예측을 일시적으로 채울 수 있습니다. 정책 생성 날짜 전 최대 2주 동안 예측이 채워집니다. ## 예측적 조정 권장 사항 보기 효과적인 분석을 위해 비교할 예측 규모 조정 정책이 2개 이상 서비스 오토 스케일링에 있어야 합니다. (그러나 여전히 단일 정책에 대한 결과를 검토할 수 있습니다.) 여러 정책을 생성할 때 한 지표를 사용하는 정책을 다른 지표를 사용하는 정책과 비교하여 평가할 수 있습니다. 또한 다양한 대상 값과 지표 조합의 영향을 평가할 수 있습니다. 예측 규모 조정 정책이 생성된 후 Amazon ECS에서는 즉시 어느 정책이 그룹 규모 조정 작업을 더 잘 수행할지 평가하기 시작합니다. **Amazon ECS 콘솔에서 권장 사항을 보는 방법** 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 단원에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 나타납니다. 1. **서비스 오토 스케일링**을 선택합니다. 1. 예측 규모 조정 정책을 선택한 다음에 **작업**, **예측 규모 조정**, **권장 사항 보기**를 선택합니다. 권장 사항과 함께 정책에 대한 세부 정보를 볼 수 있습니다. 권장 사항은 예측적 조정 정책이 사용하지 않는 것보다 더 나은 작업을 수행하는지 여부를 알려줍니다. 예측적 조정 정책이 그룹에 적합한지 확실하지 않은 경우, **가용성에 미치는 영향** 열과 **비용에 미치는 영향** 열을 검토하여 적합한 정책을 선택합니다. 각 열에 대한 정보는 정책의 영향을 알려줍니다. + **가용성에 미치는 영향**: 정책을 사용하지 않을 때와 비교하여 정책을 통해 워크로드를 처리하기에 충분한 태스크를 프로비저닝함으로써 가용성에 미치는 부정적인 영향을 방지할 수 있는지 여부를 설명합니다. + **비용에 미치는 영향**: 정책을 사용하지 않을 때와 비교하여 정책을 통해 태스크를 과다 프로비저닝하지 않음으로써 비용에 미치는 부정적인 영향을 방지할 수 있는지 여부를 설명합니다. 과다 프로비저닝하면 서비스가 충분히 사용되지 않거나 유휴 상태가 되어 비용에 미치는 영향만 가중됩니다. 정책이 여러 개인 경우, 더 낮은 비용으로 가장 많은 가용성 이점을 제공하는 정책 이름 옆에 **최상의 예측** 태그가 표시됩니다. 가용성 영향에 더 많은 가중치가 부여됩니다. 1. (선택 사항) 권장 사항 결과에 대해 원하는 기간을 선택하려면 **평가 기간** 드롭다운에서 원하는 값(**2일**, **1주** 또는 **2주**)을 선택합니다. 기본적으로 평가 기간은 지난 2주입니다. 평가 기간이 길수록 권장 사항 결과에 더 많은 데이터 포인트가 제공됩니다. 그러나 로드 패턴이 변경된 경우(예: 예외적인 수요 기간 이후) 데이터 포인트를 더 추가해도 결과가 개선되지 않을 수 있습니다. 이 경우, 보다 최근 데이터를 살펴봄으로써 보다 집중적인 권장 사항을 얻을 수 있습니다. **참고** **예상 전용** 모드에 있는 정책에 대한 권장 사항만 생성됩니다. 권장 사항 기능은 평가 기간 내내 정책이 **예상 전용** 모드일 때 더 잘 작동합니다. **예상 및 조정** 모드에서 정책을 시작하고 나중에 **예상 전용** 모드로 전환하면 해당 정책에 대한 결과가 편향될 가능성이 높습니다. 이는 정책이 이미 실제 용량에 기여했기 때문입니다. ## 예측적 조정 모니터링 그래프 검토 콘솔에서 이전 날, 주 또는 달의 예측을 검토하여 시간이 지남에 따라 정책이 얼마나 잘 수행되는지 시각화할 수 있습니다. 정책을 통해 실제 태스크 수 규모를 조정할지 여부를 결정할 때 이 정보를 사용하여 예측의 정확성을 평가할 수도 있습니다. **Amazon ECS 콘솔에서 예측 규모 조정 모니터링 그래프를 보는 방법** 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 단원에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 나타납니다. 1. **서비스 오토 스케일링**을 선택합니다. 1. 예측 규모 조정 정책을 선택한 다음에 **작업**, **예측 규모 조정**, **그래프 보기**를 선택합니다. 1. **모니터링** 섹션에서 로드 및 용량 정책에 대한 과거 및 미래 예측을 실제 값과 비교하여 볼 수 있습니다. **로드** 그래프는 선택한 로드 지표에 대한 로드 예측 및 실제 값을 보여줍니다. **용량** 그래프에는 정책에서 예측한 태스크 수가 표시됩니다. 시작된 실제 태스크 수도 포함되어 있습니다. 수직선은 과거 값과 미래 예측을 구분합니다. 정책이 생성되면 바로 이 그래프를 사용할 수 있습니다. 1. (옵션) 차트에 표시된 기록 데이터 양을 변경하려면 페이지 상단의 **평가 기간** 드롭다운에서 원하는 값을 선택합니다. 평가 기간은 어떤 식으로든 이 페이지의 데이터를 변환하지 않으며, 표시되는 기록 데이터의 양만 변경합니다. ****로드** 그래프의 데이터 비교** 각 수평선은 1시간 간격으로 보고되는 서로 다른 데이터 포인트 세트를 나타냅니다. 1. **실제 관찰된 로드**는 선택한 로드 지표에 대한 SUM 통계를 사용하여 과거의 총 시간별 로드를 보여줍니다. 1. **정책에 의해 예측되는 로드**는 시간별 로드 예측을 보여줍니다. 이 예측은 지난 2주간의 실제 로드 관찰에 근거하여 합니다. ****용량** 그래프의 데이터 비교** 각 수평선은 1시간 간격으로 보고되는 서로 다른 데이터 포인트 세트를 나타냅니다. 1. **실제 관찰된 태스크 수**는 선택한 기간 동안 적용된 기타 규모 조정 정책과 최소 그룹 크기에 따라 달라지는 과거의 Amazon ECS 서비스 실제 용량을 보여줍니다. 1. **정책에서 예측한 용량**은 정책이 **예상 및 조정** 모드일 때 매 시간 시작 시 예상할 수 있는 기본 용량을 보여줍니다. 1. **추론된 필수 태스크 수**는 선택한 대상 값으로 규모 조정 지표를 유지 관리하는 데 이상적인 서비스의 태스크 수를 보여줍니다. 1. **최소 태스트 수**는 서비스의 최소 태스크 수를 보여줍니다. 1. **최대 용량**은 서비스의 최대 태스크 수를 보여줍니다. 추론된 필수 용량을 계산하기 위해 먼저 각 태스크가 지정된 대상 값에서 균등하게 사용된다고 가정합니다. 실제로 태스크 수는 균등하게 활용되지 않습니다. 그러나 사용률이 태스크 간에 균일하게 분산되어 있다고 가정하면 필요한 용량의 양을 예측할 수 있습니다. 그런 다음에 태스크 수 요구 사항은 예측 규모 조정 정책에 사용한 규모 조정 지표에 반비례하도록 계산됩니다. 즉, 태스크 수가 증가하면 동일한 비율로 규모 조정 지표가 감소합니다. 예를 들어, 태스크 수가 두 배로 증가하면 규모 조정 지표는 절반으로 감소해야 합니다. 추론된 필수 용량에 대한 공식: `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)` 예컨대, 지정된 시간에 대한 `actualServiceUnits`(`10`) 및 `scalingMetricValue`(`30`)를 가져옵니다. 그런 다음 예측적 조정 정책(`60`)에 지정한 `targetUtilization`을 가져오고 같은 시간에 대해 추론된 필수 용량을 계산합니다. 이 예는 값 `5`를 반환합니다. 즉, 조정 지표의 대상 값에 반비례하여 용량을 유지하는 데 필요한 추론 용량은 5입니다. **참고** 애플리케이션의 비용 절감 및 가용성을 조정하고 개선하기 위해 다양한 레버를 사용할 수 있습니다. 기준 용량과 동적 조정에 예측적 조정을 사용하여 추가 용량을 처리합니다. 동적 조정은 예측적 조정과 독립적으로 작동하며 현재 사용률에 따라 스케일 아웃되고 축소됩니다. 먼저 Amazon ECS에서는 예약되지 않은 규모 조정 정책마다 권장 태스크 수를 계산합니다. 그런 다음에 최대 태스크 수가 제공되는 정책에 따라 규모가 조정됩니다. 로드가 감소할 때 스케일 인이 발생하도록 하려면 스케일 인 부분이 활성화된 동적 조정 규모 정책이 항상 하나 이상 서비스에 있어야 합니다. 최소 및 최대 용량이 너무 제한적이지 않은지 확인하여 조정 성능을 개선할 수 있습니다. 권장 태스크 수가 최소 및 최대 용량 범위에 속하지 않는 정책은 스케일 인 및 스케일 아웃되지 않습니다. # CloudWatch로 Amazon ECS에 대한 예측 규모 조정 지표 모니터링 Amazon CloudWatch를 사용하여 예측 규모 조정을 위한 데이터를 모니터링할 수 있습니다. 예측 규모 조정 정책에서는 향후 로드를 예측하는 데 사용되는 데이터를 수집합니다. 수집된 데이터는 정기적으로 CloudWatch에 자동으로 저장되며, 시간별로 정책이 얼마나 잘 작동하는지 시각화하는 데 사용할 수 있습니다. 정의한 한도 이상으로 성과 지표가 변화할 때 알려주는 CloudWatch 경보도 생성할 수 있습니다. ## 기록 예측 데이터 시각화 예측 규모 조정 정책의 로드 예측 데이터는 CloudWatch에서 볼 수 있으며, 단일 그래프에서 다른 CloudWatch 지표와 비교되는 예측을 시각화할 때 유용할 수 있습니다. 더 넓은 시간 범위를 보면서 시간별 추세를 참조할 수도 있습니다. 최대 15개월의 기록 지표에 액세스하여, 정책의 성능을 전반적으로 더 잘 파악할 수 있습니다. **CloudWatch 콘솔을 사용하여 기록 예측 데이터를 보려면** 1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다. 1. 탐색 창에서 **지표(Metrics)**를 선택한 다음 **모든 지표(All metrics)**를 선택합니다. 1. **Application Auto Scaling** 지표 네임스페이스를 선택합니다. 1. **예측 규모 조정 로드 예측**을 선택합니다. 1. 검색 필드에 예측 규모 조정 정책의 이름 또는 Amazon ECS 서비스 그룹의 이름을 입력한 다음에 Enter 키를 눌러 결과를 필터링합니다. 1. 측정치를 그래프로 표시하려면 측정치 옆에 있는 확인란을 선택합니다. 그래프 이름을 변경하려면 연필 아이콘을 선택합니다. 시간 범위를 변경하려면 제공되는 값 중 하나를 선택하거나 **사용자 지정**을 선택합니다. 자세한 설명은 *Amazon CloudWatch 사용 설명서*에서 [지표 그래프](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html)를 참조하세요. 1. 기간을 변경하려면 **그래프로 표시된 지표** 탭을 선택합니다. 열 머리글이나 개별 값을 선택한 후 다른 통계를 선택합니다. 각 지표의 어떤 통계든 선택할 수 있지만, 모든 통계가 **PredictiveScalingLoadForecast** 지표에 유용한 것은 아닙니다. 예컨대 **평균**, **최소** 및 **최대** 통계는 유용하지만 **합계** 통계는 유용하지 않습니다. 1. 그래프에 다른 지표를 추가하려면 **찾아보기(Browse)**에서 **모두(All)**를 선택하고 특정 지표를 찾은 다음 해당 지표 옆에 있는 확인란을 선택합니다. 최대 10개의 지표를 추가할 수 있습니다. 1. (옵션) 이 그래프를 CloudWatch 대시보드에 추가하려면 **작업(Actions)**, **대시보드에 추가(Add to dashboard)**를 선택합니다. ## 지표 수식을 사용하여 정확도 지표 생성 지표 수식을 사용하면 여러 CloudWatch 지표를 쿼리하고 수학 표현식을 활용함으로써 이러한 지표에 근거하여 새로운 시계열을 만들 수 있습니다. CloudWatch 콘솔에서 결과 시계열을 시각화하고 대시보드에 추가할 수 있습니다. 지표 수학에 대한 자세한 설명은 *Amazon CloudWatch 사용 설명서*에서 [지표 수학 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 참조하세요. 지표 수식을 사용하면 예측 스케일 인을 위해 서비스 오토 스케일링에서 생성되는 데이터를 다양한 방식으로 그래프로 표시할 수 있습니다. 이는 시간 경과에 따른 정책 성능을 모니터링하고 지표 조합을 개선할 수 있는지 여부를 파악하는 데 도움이 됩니다. 예컨대, 지표 수학 표현식을 사용하여 [평균 절대 백분율 오차](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error)(MAPE)를 모니터링할 수 있습니다. MAPE 지표는 예측된 값과 지정된 예측 기간 동안 관찰된 실제 값의 차이를 모니터링하는 데 유용합니다. MAPE 값의 변화는 시간 경과에 따라 애플리케이션의 특성이 변경되면서 정책의 성능이 저하되는지 여부를 나타낼 수 있습니다. MAPE가 증가하면 예측된 값과 실제 값의 차이가 더 커진다는 것을 나타냅니다. **예: 지표 수학 표현식** 이 유형의 그래프로 시작하려면, 다음 예에 표시된 것과 같은 지표 수학 표현식을 생성하면 됩니다. 단일 지표 대신, `MetricDataQueries`의 지표 데이터 쿼리 구조의 배열을 사용할 수 있습니다. `MetricDataQueries`의 각 항목은 지표를 가져오거나 수학 표현식을 수행합니다. 첫 번째 항목 `e1`은 수학 표현식입니다. 이 지정된 표현식은 `ReturnData` 파라미터를 `true`로 설정합니다. 이는 궁극적으로 단일 시계열을 생성합니다. 다른 모든 지표의 경우, `ReturnData` 값은 `false`입니다. 이 예에서 지정된 표현식은 실제 값과 예측된 값을 입력으로 사용하여 새 지표(MAPE)를 반환합니다. `m1`은 실제 로드 값을 포함하는 CloudWatch 지표입니다(CPU 사용률이 `my-predictive-scaling-policy`라는 정책에 대해 원래 지정된 로드 지표라고 가정). `m2`는 예측된 로드 값을 포함하는 CloudWatch 지표입니다. MAPE 지표의 수식 구문은 다음과 같습니다. *(abs ((실제 - 예측)/(실제)))의 평균* ### 정확도 지표 시각화 및 경보 설정 정확도 지표 데이터를 시각화하려면 CloudWatch 콘솔에서 **지표(Metrics)** 탭을 선택합니다. 여기에서 데이터를 그래프로 표시할 수 있습니다. 자세한 설명은 *Amazon CloudWatch 사용 설명서*에서 [CloudWatch 그래프에 수학 표현식 추가](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console)를 참조하세요. **지표(Metrics)** 섹션에서 모니터링하는 지표에 대해 경보를 설정할 수도 있습니다. **그래프로 표시된 지표(Graphed metrics)** 탭에서 **작업(Actions)** 열 아래에 있는 **경보 생성(Create alarm)** 아이콘을 선택합니다. 이 **경보 생성(Create alarm)** 아이콘은 작은 종 모양으로 표시됩니다. 자세한 내용과 알림 옵션은 *Amazon CloudWatch 사용 설명서*의 [지표 수학 표현식에 근거하여 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) 및 [경보 변경 시 사용자에게 알림](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html)을 참조하세요. 또는 [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) 및 [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)을 사용하여 지표 수식으로 계산을 수행하고 그 출력에 따라 경보를 생성할 수 있습니다. # 예약된 작업을 사용하여 Amazon ECS의 예측 값 재정의 경우에 따라 예상 계산에서 고려할 수 없는 향후 애플리케이션 필요량에 대한 추가 정보가 있을 수 있습니다. 예컨대, 예상 계산은 향후 마케팅 이벤트에 필요한 작업을 과소 평가할 수 있습니다. 예약된 작업을 사용하여 미래 기간에 대한 예상을 임시로 재정의할 수 있습니다. 예약된 작업은 반복적으로 실행되거나 일회성 수요 변동이 있는 특정 날짜 및 시간에 실행될 수 있습니다. 예컨대, 예상한 것보다 높은 작업 수로 예약된 작업을 생성할 수 있습니다. 런타임 시 Amazon ECS에서는 서비스의 최소 태스크 수를 업데이트합니다. 예측 조정은 작업 수에 맞게 최적화하므로 최소 작업 수가 예상 값보다 높은 예약된 작업이 적용됩니다. 이렇게 하면 작업 수가 예상보다 적지 않습니다. 예상 재정의를 중지하려면 두 번째 예약된 작업을 사용하여 최소 작업 수를 원래 설정으로 되돌립니다. 다음 절차에서는 미래 기간의 예상을 재정의하는 단계를 간략하게 설명합니다. **Topics** + [1단계: (옵션) 시계열 데이터 분석](#analyzing-time-series-data) + [2단계: 2개의 예약된 작업 생성](#scheduling-capacity) **중요** 이 주제에서는 예측보다 더 큰 용량으로 확장하기 위해 예측을 재정의한다고 가정합니다. 예측 조정 정책의 간섭 없이 일시적으로 작업 수를 줄여야 하는 경우 *예측 전용* 모드를 대신 사용합니다. 예측 전용 모드에서 예측 조정은 계속 예측을 생성하지만 작업 수가 자동으로 증가하지는 않습니다. 그러면 리소스 사용률을 모니터링하고 필요에 따라 태스크 수를 수동으로 줄일 수 있습니다. ## 1단계: (옵션) 시계열 데이터 분석 예상 시계열 데이터 분석으로 시작합니다. 이 단계는 선택 사항이지만 예상의 세부 정보를 파악하려는 경우, 유용합니다. 1. **예상 검색** 예상이 생성되면 예상에서 특정 기간을 쿼리할 수 있습니다. 쿼리의 목표는 특정 기간에 대한 시계열 데이터의 전체 보기를 얻는 것입니다. 쿼리에는 최대 2일간의 미래 예상 데이터가 포함될 수 있습니다. 예측 조정을 잠시 사용한 경우에도 과거 예상 데이터에 액세스할 수 있습니다. 그러나 시작 시간과 해지 시간 사이의 최대 기간은 30일입니다. [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI 명령을 사용하여 예상을 얻으려면 명령에 다음 파라미터를 제공합니다. + `resource-id` 파라미터에 클러스터의 이름을 입력합니다. + `--policy-name` 파라미터에 정책 이름을 입력합니다. + 지정한 시간 또는 그 이후의 예상 데이터만 반환하려면 `--start-time` 파라미터에 시작 시간을 입력합니다. + 지정한 시간 이전의 예상 데이터만 반환하려면 `--end-time` 파라미터에 해지 시간을 입력합니다. ``` aws application-autoscaling get-predictive-scaling-forecast \ --service-namespace ecs \ --resource-id service/MyCluster/test \ --policy-name cpu40-predictive-scaling-policy \ --scalable-dimension ecs:service:DesiredCount \ --start-time "2021-05-19T17:00:00Z" \ --end-time "2021-05-19T23:00:00Z" ``` 이 작업이 성공하면 명령에서 다음 예와 비슷한 데이터가 반환됩니다. ``` { "LoadForecast": [ { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 153.0655799339254, 128.8288551285919, 107.1179447150675, 197.3601844551528, 626.4039934516954, 596.9441277518481, 677.9675713779869 ], "MetricSpecification": { "TargetValue": 40.0, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ASGCPUUtilization" } } } ], "CapacityForecast": { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 2.0, 2.0, 2.0, 2.0, 4.0, 4.0, 4.0 ] }, "UpdateTime": "2021-05-19T01:52:50.118000+00:00" } ``` 응답에는 `LoadForecast` 및 `CapacityForecast`라는 두 가지 예측 값이 포함됩니다. `LoadForecast`는 시간별 로드 예측을 보여 주고 `CapacityForecast`는 40.0(평균 CPU 사용률 40%)의 `TargetValue`를 유지하는 동안 예측 로드를 처리하는 데 시간당 필요한 용량에 대한 예측 값을 보여 줍니다. 1. **대상 기간 식별** 일회성 수요 변동이 발생해야 하는 시간을 식별합니다. 예상에 표시된 날짜와 시간은 UTC입니다. ## 2단계: 2개의 예약된 작업 생성 다음으로, 애플리케이션의 예상 로드보다 높은 특정 기간에 대해 2개의 예약된 작업을 생성합니다. 예컨대, 제한된 기간에 사이트에 대한 트래픽을 높이는 마케팅 이벤트가 있는 경우, 이벤트 시작 시 최소 용량을 업데이트하는 일회성 작업을 예약할 수 있습니다. 그런 다음 이벤트가 해지 시 최소 용량을 원래 설정으로 되돌리도록 다른 작업을 예약합니다. 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터(Clusters)** 페이지에서 클러스터를 선택합니다. 1. 클러스터 세부 정보 페이지의 **서비스** 섹션에서 서비스를 선택합니다. 서비스 세부 정보 페이지가 나타납니다. 1. **서비스 오토 스케일링**을 선택합니다. 정책 페이지가 나타납니다. 1. **예약된 작업**과 **생성**을 차례로 선택합니다. **예약 생성 작업** 페이지가 나타납니다. 1. **액션 이름**에 고유한 이름을 입력합니다. 1. **시간대**에서 시간대를 선택합니다. 나열된 모든 표준 시간대는 IANA 표준 시간대 데이터베이스에서 가져온 것입니다. 자세한 내용은 [tz 데이터베이스 시간대 목록](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)을 참조하세요. 1. **시작 시간**에는 작업이 시작되는 **날짜**와 **시간을** 입력합니다. 1. **반복**에서 **1회(Once)**를 선택합니다. 1. **작업 조정**의 최솟값에 최대 작업 수보다 적거나 같은 값을 입력합니다. 1. **예약된 작업 생성**을 선택합니다. 정책 페이지가 나타납니다. 1. 이벤트 종료 시 최소 작업 수가 원래 설정으로 되돌아 가도록 두 번째 예약된 작업을 구성합니다. 예측 조정은 **최소**에 대해 사용자가 설정한 값이 예상 값보다 적은 경우에만 작업 수를 조정할 수 있습니다. **일회성 이벤트에 대해 2개의 예약된 작업을 생성하려면(AWS CLI)** AWS CLI를 사용하여 예약된 작업을 생성하려면 [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) 명령을 사용합니다. 예컨대, 5월 19일 오후 5시에 8시간 동안 최소 용량으로 인스턴스 3개를 유지하는 일정을 정의해 보겠습니다. 다음 명령은 이 시나리오를 구현하는 방법을 보여 줍니다. 첫 번째 [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) 명령은 2021년 5월 19일 오후 5시(UTC)에 지정된 Auto Scaling 그룹의 최소 용량을 업데이트하도록 Amazon EC2 Auto Scaling에 지시합니다. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \ --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3 ``` 두 번째 명령은 그룹의 최소 용량을 2021년 5월 20일 오전 1시(UTC)의 용량으로 설정하도록 Amazon EC2 Auto Scaling에 지시합니다. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \ --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1 ``` 이러한 예약된 작업을 Auto Scaling 그룹에 추가하면 Amazon EC2 Auto Scaling은 다음을 수행합니다. + 2021년 5월 19일 오후 5시(UTC)에 첫 번째 예약된 작업이 실행됩니다. 현재 해당 그룹에 인스턴스가 3개 미만 있는 경우, 그룹은 인스턴스 3개로 스케일 아웃됩니다. 이 시간과 향후 8시간 동안 예측 용량이 실제 용량보다 높거나 동적 조정 정책이 적용되는 경우, Amazon EC2 Auto Scaling이 계속 스케일 아웃을 수행할 수 있습니다. + 2021년 5월 20일 오전 1시(UTC)에 두 번째 예약된 작업이 실행됩니다. 이렇게 하면 이벤트 해지 시 최소 용량이 원래 설정으로 돌아갑니다. ### 반복 일정에 따라 크기 조정 매주 동일한 기간에 대한 예상을 재정의하려면 두 개의 예약된 작업을 생성하고 cron 표현식을 사용하여 시간 및 날짜 로직을 제공합니다. cron 표현식 형식은 다음과 같이 공백으로 구분된 다섯 개의 필드로 구성됩니다. [Minute] [Hour] [Day\$1of\$1Month] [Month\$1of\$1Year] [Day\$1of\$1Week]. 필드에는 특수 문자를 포함하여 허용되는 모든 값을 포함할 수 있습니다. 예컨대, 다음 cron 표현식은 매주 화요일 오전 6시 30분에 작업을 실행합니다. 별표는 필드의 모든 값을 일치시키기 위한 와일드카드로 사용됩니다. ``` 30 6 * * 2 ``` ### 다음 사항도 참조하세요. 예약된 작업을 관리하는 방법에 대한 자세한 내용은 [예약된 조치를 사용하여 Amazon ECS 서비스 규모 조정](service-autoscaling-schedulescaling.md) 섹션을 참조하세요. # Amazon ECS의 사용자 정의 지표를 사용하는 고급 예측 규모 조정 정책 미리 정의된 지표 또는 사용자 정의 지표를 예측 규모 조정 정책에서 사용할 수 있습니다. 사용자 지정 지표는 CPU, 메모리 등과 같이 미리 정의된 지표가 애플리케이션 로드를 충분히 설명하기에 충분하지 않을 때 유용합니다. 사용자 지정 지표를 사용하여 예측 규모 조정 정책을 생성할 때 AWS에서 제공하는 다른 CloudWatch 지표를 지정할 수 있습니다. 그 대신에 직접 정의하고 게시하는 지표를 지정할 수도 있습니다. 또한 지표 수학을 사용하여 기존 지표를 집계하고 AWS가 자동으로 추적하지 않는 새 시계열로 변환할 수 있습니다. 예를 들면, *집계*라는 새 합계 또는 평균 계산을 통해 데이터의 값을 결합할 수 있습니다. 결과 데이터를 *집계*라고 합니다. 다음 섹션에는 정책의 JSON 구조를 구성하는 방법에 대한 모범 사례와 예가 나와 있습니다. ## 사전 조건 정책에서 사용자 지정 지표를 지정하려면 `cloudwatch:GetMetricData` 권한이 있어야 합니다. AWS에서 제공하는 지표 대신 자체 지표를 지정하려면 먼저 지표를 CloudWatch에 게시해야 합니다. 자세한 설명은 *Amazon CloudWatch 사용 설명서*의 [사용자 정의 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)를 참조하세요. 자체 지표를 게시하는 경우, 최소 5분 간격으로 데이터 요소를 게시해야 합니다. 데이터 포인트는 필요한 기간을 기준으로 CloudWatch에서 검색됩니다. 예컨대, 로드 지표 사양은 시간별 지표를 사용하여 애플리케이션의 로드를 측정합니다. CloudWatch는 게시된 지표 데이터로 각 1시간 기간에 속하는 타임스탬프가 있는 모든 데이터 요소를 집계하여 1시간 기간 동안 단일 데이터 값을 제공합니다. ## 모범 사례 다음 모범 사례는 사용자 정의 지표를 보다 효과적으로 사용하는 데 도움이 될 수 있습니다. + 로드 지표 사양에 가장 유용한 지표는 Auto Scaling 그룹 전체의 로드를 나타내는 지표입니다. + 규모 조정 지표 사양의 규모 조정에 가장 유용한 지표는 태스크 지표당 평균 처리량 또는 사용률입니다. + 목표 사용률은 조정 지표 유형과 일치해야 합니다. 예를 들면, CPU 사용률을 사용하는 정책 구성의 경우에는 목표 백분율입니다. + 이러한 권장 사항을 따르지 않으면 시계열의 예측된 미래 값이 정확하지 않을 수 있습니다. 데이터가 올바른지 검증하기 위해 콘솔에서 예측된 값을 볼 수 있습니다. 또는 예측 규모 조정 정책을 생성한 후 [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html) API 직접적으로 호출에서 반환된 `LoadForecast` 객체를 검사합니다. + 예측 규모 조정에서 능동적으로 규모 조정이 시작되기 전에 예상을 평가할 수 있게 예상 전용 모드에서 예측적 조정을 구성하는 것이 좋습니다. ## 제한 사항 + 하나의 지표 사양에서 최대 10개 지표의 데이터 요소를 쿼리할 수 있습니다. + 이 제한을 위해 하나의 표현식이 하나의 지표로 계산됩니다. ## 사용자 지정 지표로 예측 규모 조정 정책 문제 해결 사용자 정의 지표를 사용하는 동안 문제가 발생하면 다음을 수행하는 것이 좋습니다. + 검색 표현식을 사용하는 동안 블루/그린 배포에서 문제가 발생하는 경우 정확히 일치가 아니라 부분 일치를 찾는 검색 표현식을 생성해야 합니다. 또한 쿼리가 특정 애플리케이션에서 실행 중인 Auto Scaling 그룹만 찾는지 확인해야 합니다. 검색 표현식 구문에 대한 자세한 설명은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch 검색 표현식 구문](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)을 참조하세요. + 조정 규모 정책을 생성할 때 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) 명령이 표현식을 검증합니다. 그러나 이 명령이 탐지된 오류의 정확한 원인을 식별하지 못할 수도 있습니다. 문제를 해결하려면 [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) 명령에 대한 요청의 응답에서 수신하는 오류를 해결합니다. CloudWatch 콘솔에서 표현식의 문제를 해결할 수도 있습니다. + `MetricDataQueries`가 SUM()과 같은 수학 함수 없이 자체적으로 SEARCH() 함수를 지정하는 경우, `ReturnData`에 대해 `false`를 지정해야 합니다. 이는 검색 표현식이 여러 시계열을 반환할 수 있고 표현식에 근거하여 하는 지표 사양이 하나의 시계열만 반환할 수 있기 때문입니다. + 검색 표현식과 관련된 모든 지표는 해상도가 동일해야 합니다. # Amazon ECS로 예측 규모 조정 사용자 지정 지표를 위한 JSON 구성 다음 섹션에는 CloudWatch에서 데이터를 쿼리하도록 예측 조정을 구성하는 방법에 대한 예가 나와 있습니다. 이 옵션을 구성하는 방법에는 두 가지가 있으며 선택하는 방법에 따라 예측 조정 정책에 사용할 JSON을 구성하는 데 사용하는 형식이 달라집니다. 지표 수학을 사용하는 경우, JSON의 형식은 수행되는 지표 수학에 따라 더 달라집니다. 1. AWS에서 제공하는 다른 CloudWatch 지표 또는 CloudWatch에 게시하는 지표에서 직접 데이터를 가져오는 정책을 생성하려면 [AWS CLI를 사용하는 사용자 지정 로드 및 규모 조정 지표가 있는 예측 규모 조정 정책 예제](#predictive-scaling-custom-metrics-example1)을 참조하세요. ## AWS CLI를 사용하는 사용자 지정 로드 및 규모 조정 지표가 있는 예측 규모 조정 정책 예제 AWS CLI를 사용하여 사용자 지정 로드 및 조정 지표로 예측 조정 정책을 생성하려면 `config.json`이라는 JSON 파일에 `--predictive-scaling-configuration`에 대한 인수를 저장합니다. 다음 예에서 교체 가능한 값을 지표 및 목표 사용률의 값으로 교체하여 사용자 지정 지표를 추가하기 시작합니다. ``` { "MetricSpecifications": [ { "TargetValue": 50, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Id": "scaling_metric", "MetricStat": { "Metric": { "MetricName": "MyUtilizationMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Average" } } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "MyLoadMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Sum" } } ] } } ] } ``` 자세한 설명은 *Amazon EC2 Auto Scaling API 참조*의 [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)를 참조하세요. **참고** 다음은 CloudWatch 지표에 대한 지표 이름, 네임스페이스, 차원 및 통계를 찾는 데 도움이 되는 몇 가지 추가 리소스입니다. AWS 서비스에 사용 가능한 지표에 대한 자세한 설명은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch 지표를 게시하는 AWS 서비스](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)를 참조하세요. AWS CLI를 사용하여 CloudWatch 지표에 대한 정확한 지표 이름, 네임스페이스 및 차원(해당되는 경우)을 얻으려면 [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html)를 참조하세요. 이 정책을 생성하려면 다음 예에 나와 있는 것처럼 JSON 파일을 입력으로 사용하여 [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) 명령을 실행합니다. ``` aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json ``` 이 명령이 제대로 실행되면 정책의 Amazon 리소스 이름(ARN)을 반환합니다. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy", "Alarms": [] } ``` # 지표 수학 표현식 사용 다음 섹션에서는 정책에서 예측 규모 조정 정책과 지표 수학을 함께 사용하는 방법에 대한 정보가 제공됩니다. ## 지표 수학 이해 기존 지표 데이터를 집계하기만 하면 CloudWatch 지표 수학을 통해 CloudWatch에 다른 지표를 게시하는 데 드는 노력과 비용을 절약할 수 있습니다. AWS에서 제공하는 모든 지표를 사용할 수 있으며 애플리케이션의 일부로 정의하는 지표를 사용할 수도 있습니다. 자세한 설명은 *Amazon CloudWatch 사용 설명서*의 [지표 수학 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 참조하세요. 예측적 조정 정책에서 지표 수학 표현식을 사용하기로 선택한 경우, 다음 사항을 고려하세요. + 지표 수학 연산은 고유한 조합의 지표 이름, 네임스페이스 및 지표의 차원 키/값 페어의 데이터 요소를 사용합니다. + 산술 연산자(\$1 - \$1 / ^), 통계 함수(예: AVG 또는 SUM) 또는 CloudWatch에서 지원하는 기타 함수를 사용할 수 있습니다. + 수학 표현식의 공식에서 지표 및 다른 수학 표현식의 결과를 모두 사용할 수 있습니다. + 지표 수학 표현식은 다양한 집계로 구성될 수 있습니다. 그러나 최종 집계 결과에서 조정 지표에는 `Average`를 사용하고 로드 지표에는 `Sum`을 사용하는 것이 가장 좋습니다. + 지표 사양에 사용된 표현식은 결국 단일 시계열을 반환해야 합니다. 지표 수학을 사용하려면 다음을 수행합니다. + 하나 이상의 CloudWatch 지표를 선택합니다. 그런 다음 표현식을 생성합니다. 자세한 설명은 *Amazon CloudWatch 사용자 가이드*의 [지표 수학 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 참조하세요. + CloudWatch 콘솔 또는 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API를 사용하여 지표 수학 표현식이 유효한지 확인합니다. ## 지표 수학을 사용하여 지표를 결합하는 예측 조정 정책의 예(AWS CLI) 지표를 직접 지정하는 대신 어떤 방식으로든 해당 데이터를 먼저 처리해야 하는 경우가 있습니다. 예컨대, Amazon SQS 대기열에서 작업을 가져오는 애플리케이션이 있고 대기열의 항목 수를 예측적 조정의 기준으로 사용할 수 있습니다. 대기열의 메시지 수가 필요한 인스턴스 수를 단독으로 정의하지 않습니다. 따라서 인스턴스당 백로그를 계산하는 데 사용할 수 있는 지표를 생성하려면 더 많은 작업이 필요합니다. 다음은 이 시나리오에 대한 예측적 조정 정책의 예입니다. 대기열에서 검색할 수 있는 메시지 수인 Amazon SQS `ApproximateNumberOfMessagesVisible` 지표를 기준으로 하는 조정 및 로드 지표를 지정합니다. 또한 Amazon EC2 Auto Scaling `GroupInServiceInstances` 지표와 수학 표현식을 사용하여 조정 지표에 대한 인스턴스당 백로그를 계산합니다. ``` aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \ --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json --service-namespace ecs \ --resource-id service/MyCluster/test \ "MetricSpecifications": [ { "TargetValue": 100, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Label": "Get the queue size (the number of messages waiting to be processed)", "Id": "queue_size", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Get the group size (the number of running instances)", "Id": "running_capacity", "MetricStat": { "Metric": { "MetricName": "GroupInServiceInstances", "Namespace": "AWS/AutoScaling", "Dimensions": [ { "Name": "AutoScalingGroupName", "Value": "my-asg" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Calculate the backlog per instance", "Id": "scaling_metric", "Expression": "queue_size / running_capacity", "ReturnData": true } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ], }, "Stat": "Sum" }, "ReturnData": true } ] } } ] } ``` 이 예에서는 정책의 ARN을 반환합니다. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy", "Alarms": [] } ``` # Amazon ECS 서비스 상호 연결 Amazon ECS 작업에서 실행되는 애플리케이션은 종종 인터넷으로부터 연결을 받거나 Amazon ECS 서비스에서 실행되는 다른 애플리케이션에 연결해야 합니다. 인터넷을 통한 외부 연결이 필요한 경우 Elastic Load Balancing을 사용하는 것이 좋습니다. 통합 로드 밸런싱에 대한 자세한 내용은 [로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산](service-load-balancing.md) 섹션을 참조하세요. 애플리케이션이 Amazon ECS 서비스에서 실행되는 다른 애플리케이션에 연결해야 하는 경우 Amazon ECS에서는 다음과 같은 방법으로 로드 밸런서 없이 할 수 있습니다. + *Amazon ECS Service Connect* 서비스 검색, 연결 및 트래픽 모니터링을 위한 Amazon ECS 구성을 제공하는 Service Connect를 사용하는 것이 좋습니다. Service Connect를 사용하면 애플리케이션dms 짧은 이름과 표준 포트를 사용하여 동일한 AWS 리전에 있는 여러 VCP에 있는 항목을 포함하여 동일한 클러스터, 다른 클러스터의 Amazon ECS 서비스에 연결할 수 있습니다. Service Connect를 사용하면 Amazon ECS가 서비스 검색의 모든 부분을 관리합니다. 즉, 검색할 수 있는 이름을 생성하고, 작업이 시작 및 중지될 때 각 작업에 대한 항목을 동적으로 관리하며, 이름을 검색하도록 구성된 각 작업에서 에이전트를 실행할 수 있습니다. 애플리케이션은 DNS 이름에 대한 표준 기능을 사용하고 연결을 설정하여 이름을 조회할 수 있습니다. 애플리케이션이 이미 이 작업을 수행하는 경우 Service Connect를 사용하기 위해 애플리케이션을 수정할 필요가 없습니다. 각 서비스 및 작업 정의 내에 전체 구성을 제공합니다. Amazon ECS는 각 서비스 배포에서 이 구성의 변경 내용을 관리하여 배포의 모든 작업이 동일한 방식으로 작동하도록 합니다. 예를 들어, 서비스 검색으로 DNS에서 흔히 발생하는 문제는 마이그레이션 제어와 관련됩니다. 새 교체 IP 주소를 가리키도록 DNS 이름을 변경하는 경우 모든 클라이언트가 새 서비스를 사용하기 시작하는 데 최대 TTL 시간이 걸릴 수 있습니다. Service Connect를 사용하면 클라이언트 배포에서 클라이언트 작업을 교체하여 구성을 업데이트합니다. 다른 배포와 동일한 방식으로 Service Connect 변경 내용에 영향을 주도록 배포 회로 차단기 및 기타 배포 구성을 구성할 수 있습니다. 자세한 내용은 [Service Connect를 사용하여 짧은 이름으로 Amazon ECS 서비스 연결](service-connect.md) 섹션을 참조하세요. + *Amazon ECS 서비스 검색* 서비스 간 통신의 또 다른 접근 방식으로, 서비스 검색을 사용하는 직접 통신이 있습니다. 이 접근 방식에서는 Amazon ECS와의 AWS Cloud Map 서비스 검색 통합을 사용할 수 있습니다. Amazon ECS는 서비스 검색을 사용하여 시작된 작업 목록을 AWS Cloud Map과 동기화합니다. 이 제품에서는 해당 특정 서비스에서 하나 이상 작업에 대한 내부 IP 주소로 확인되는 DNS 호스트 이름을 유지 관리합니다. Amazon VPC의 다른 서비스는 이 DNS 호스트 이름을 사용하여 내부 IP 주소를 통해 다른 컨테이너로 직접 트래픽을 보낼 수 있습니다. 서비스 간 통신에 대한 이러한 접근 방식은 지연 시간을 줄여줍니다. 컨테이너 사이에 추가 구성 요소가 없습니다. 트래픽은 한 컨테이너에서 다른 컨테이너로 직접 이동합니다. 이 접근 방식은 각 작업의 IP 주소가 고유한 `awsvpc` 네트워크 모드를 사용할 때 적합합니다. 대부분의 소프트웨어는 IP 주소로 직접 확인되는 DNS `A` 레코드 사용만 지원합니다. `awsvpc` 네트워크 모드를 사용하는 경우 각 작업의 IP 주소는 `A` 레코드입니다. 하지만 `bridge` 네트워크 모드를 사용하는 경우 여러 컨테이너가 동일한 IP 주소를 공유할 수 있습니다. 또한 동적 포트 매핑으로 해당 단일 IP 주소에서 컨테이너에 포트 번호가 무작위로 할당됩니다. 이 경우 `A` 레코드는 더 이상 서비스 검색에 충분하지 않습니다. 또한 `SRV` 레코드를 사용해야 합니다. 이 유형의 레코드는 IP 주소와 포트 번호를 모두 추적할 수 있지만 애플리케이션을 적절하게 구성해야 합니다. 사용하는 일부 사전 구축된 애플리케이션은 `SRV` 레코드를 지원하지 않을 수 있습니다. `awsvpc` 네트워크 모드의 또 다른 이점은 각 서비스에 대해 고유한 보안 그룹이 보유한다는 점입니다. 해당 서비스와 통신해야 하는 특정 업스트림 서비스의 수신 연결만 허용하도록 이 보안 그룹을 구성할 수 있습니다. 서비스 검색을 사용하는 서비스 간 직접 통신의 주된 단점은 재시도 및 연결 실패 처리를 위해 추가 로직을 구현해야 한다는 점입니다. DNS 레코드에는 캐싱되는 시간을 제어하는 TTL(Time To Live) 기간이 있습니다. 애플리케이션이 최신 버전의 DNS 레코드를 선택할 수 있도록 DNS 레코드를 업데이트하고 캐시가 만료되기까지 어느 정도 시간이 걸립니다. 따라서 애플리케이션이 DNS 레코드를 확인할 때 더 이상 존재하지 않는 다른 컨테이너를 가리킬 수 있습니다. 애플리케이션은 재시도를 처리하고 잘못된 백엔드를 무시할 수 있는 로직을 포함해야 합니다. 자세한 내용은 [서비스 검색을 사용하여 Amazon ECS 서비스를 DNS 이름으로 연결](service-discovery.md) 섹션을 참조하세요. + *Amazon VPC Lattice * Amazon VPC Lattice는 Amazon ECS 고객이 코드를 수정하지 않고 AWS 컴퓨팅 서비스, VPC 및 계정에 구축된 애플리케이션을 관찰, 보안 유지 및 모니터링하는 데 사용하는 관리형 애플리케이션 네트워킹 서비스입니다. VPC Lattice에서는 컴퓨팅 리소스 모음인 대상 그룹을 사용합니다. 이러한 대상은 애플리케이션 또는 서비스를 실행하며, Amazon EC2 인스턴스, IP 주소, Lambda 함수 및 Application Load Balancer일 수 있습니다. 이제는 고객이 Amazon ECS 서비스를 VPC Lattice 대상 그룹과 연결하여 Amazon ECS 작업을 VPC Lattice의 IP 대상으로 활성화할 수 있습니다. Amazon ECS에서는 등록된 서비스에 대한 태스크가 시작될 때 VPC Lattice 대상 그룹에 태스크를 자동으로 등록합니다. 자세한 내용은 [Amazon VPC Lattice를 사용하여 Amazon ECS 서비스 연결, 관찰 및 보안 유지](ecs-vpc-lattice.md) 섹션을 참조하세요. ## 네트워크 모드 호환성 표 다음 표에서는 이러한 옵션과 작업 네트워크 모드 간의 호환성에 대해 설명합니다. 표에서 '클라이언트'는 Amazon ECS 작업 내에서 연결하는 애플리케이션을 가리킵니다. **** | 상호 연결 옵션 | 브리징 | `awsvpc` | Host | | --- | --- | --- | --- | | 서비스 검색 | 예, 하지만 클라이언트는 hostPort 없이 DNS에서 SRV 레코드를 인식해야 합니다. | yes | 예, 하지만 클라이언트는 hostPort 없이 DNS에서 SRV 레코드를 인식해야 합니다. | | Service Connect | 예 | 예 | 아니요 | | VPC Lattice | 예 | 예 | 예 | # Service Connect를 사용하여 짧은 이름으로 Amazon ECS 서비스 연결 Amazon ECS Service Connect는 서비스 간 통신 관리를 Amazon ECS 구성으로 제공합니다. Amazon ECS에서 서비스 검색과 서비스 메시를 모두 구축합니다. 이를 통해 서비스 배포에서 관리하는 각 서비스 내부의 전체 구성, VPC DNS 구성에 의존하지 않는 네임스페이스 내 서비스를 참조하는 통합된 방법, 모든 애플리케이션을 모니터링하는 표준화된 지표와 로그를 제공합니다. Service Connect는 서비스만 상호 연결합니다. 다음 다이어그램에서는 VPC의 서브넷 2개와 서비스 2개가 있는 서비스 연결 네트워크 예제를 보여줍니다. 클라이언트 서비스는 각 서브넷에서 1개 작업으로 WordPress를 실행합니다. 서버 서비스는 각 서브넷에서 1개 작업으로 MySQL을 실행합니다. 각 서비스가 2개의 서브넷에 분산된 여러 작업을 실행하므로 두 서비스 모두 가용성이 높고 작업 및 가용 영역 문제에 대한 복원력이 뛰어납니다. 실선 화살표는 WordPress에서 MySQL로의 연결을 나타냅니다. 예를 들어, `mysql --host=mysql` CLI 명령은 작업의 WordPress 컨테이너 내에서 IP 주소 `172.31.16.1`로 실행됩니다. 이 명령은 MySQL의 기본 포트에서 약식 이름 `mysql`을 사용합니다. 이 이름과 포트는 동일한 작업의 서비스 연결 프록시에 연결합니다. WordPress 작업의 프록시는 라운드 로빈 로드 밸런싱과 이상값 탐지의 이전 실패 정보를 사용하여 연결할 MySQL 작업을 선택합니다. 다이어그램에서 실선 화살표로 표시된 것처럼 프록시는 IP 주소 `172.31.16.2`를 사용하여 MySQL 작업의 두 번째 프록시에 연결합니다. 두 번째 프록시는 동일한 작업의 로컬 MySQL 서버에 연결합니다. 두 프록시 모두 Amazon ECS 및 Amazon CloudWatch 콘솔에서 그래프로 확인할 수 있는 연결 성능을 보고하므로 동일한 방법으로 모든 종류의 애플리케이션에서 성능 지표를 얻을 수 있습니다. ![\[최소 HA 서비스를 표시하는 서비스 연결 네트워크 예제\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/images/serviceconnect.png) 다음 용어는 Service Connect에서 사용됩니다. **포트 이름** 특정 포트 매핑에 이름을 할당하는 Amazon ECS 작업 정의 구성입니다. 이 구성은 Amazon ECS Service Connect에서만 사용됩니다. **클라이언트 별칭** 엔드포인트에서 사용되는 포트 번호를 할당하는 Amazon ECS 서비스 구성입니다. 추가로 클라이언트 별칭은 엔드포인트의 DNS 이름을 할당하여 검색 이름을 재정의할 수 있습니다. 검색 이름이 Amazon ECS 서비스에 제공되지 않은 경우 클라이언트 별칭 이름이 엔드포인트 이름인 포트 이름보다 우선합니다. 엔드포인트 예제는 *엔드포인트* 정의를 참조하세요. 여러 클라이언트 별칭을 Amazon ECS 서비스에 할당할 수 있습니다. 이 구성은 Amazon ECS Service Connect에서만 사용됩니다. **검색 이름** 작업 정의에서 지정된 포트에 대해 생성할 수 있는 선택적 중간 이름입니다. 이 이름은 AWS Cloud Map 서비스를 생성하는 데 사용됩니다. 이 이름이 제공되지 않으면 작업 정의의 포트 이름이 사용됩니다. 특정 포트 및 Amazon ECS 서비스에 여러 검색 이름을 할당할 수 있습니다. 이 구성은 Amazon ECS Service Connect에서만 사용됩니다. AWS Cloud Map 서비스 이름은 네임스페이스 내에서 고유해야 합니다. 이러한 제한 때문에 각 네임스페이스의 특정 작업 정의에 대한 검색 이름이 없는 Service Connect 구성은 하나만 있을 수 있습니다. **엔드포인트** API 또는 웹 사이트에 연결하기 위한 URL입니다. URL에는 프로토콜, DNS 이름 및 포트가 포함됩니다. 일반적인 엔드포인트에 대한 자세한 내용은 Amazon Web Services 일반 참조의 *AWS 용어집*에 있는 [엔드포인트](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint)를 참조하세요. Service Connect는 Amazon ECS 서비스에 연결하는 엔드포인트를 생성하고 Amazon ECS 서비스에서 엔드포인트에 연결할 작업을 구성합니다. URL에는 프로토콜, DNS 이름 및 포트가 포함됩니다. 포트는 컨테이너 이미지 내에 있는 애플리케이션과 일치해야 하므로 작업 정의에서 프로토콜 및 포트 이름을 선택합니다. 서비스에서 이름에 따라 각 포트를 선택하고 DNS 이름을 할당할 수 있습니다. Amazon ECS 서비스 구성에서 DNS 이름을 지정하지 않으면 기본적으로 작업 정의의 포트 이름이 사용됩니다. 예를 들어, Service Connect 엔드포인트는 `http://blog:80`, `grpc://checkout:8080` 또는 `http://_db.production.internal:99`일 수 있습니다. **Service Connect 서비스** Amazon ECS 서비스의 단일 엔드포인트 구성입니다. 이는 Service Connect 구성의 일부로 콘솔의 **Service Connect and discovery name configuration**(Service Connect 및 검색 이름 구성)의 단일 행 또는 Amazon ECS 서비스의 JSON 구성에 있는 `services` 목록의 한 객체로 구성됩니다. 이 구성은 Amazon ECS Service Connect에서만 사용됩니다. 자세한 내용은 Amazon Elastic Container Service API 참조의 [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)를 참조하세요. **네임스페이스** Service Connect와 함께 사용할 AWS Cloud Map 네임스페이스의 약식 이름 또는 전체 Amazon 리소스 이름(ARN)입니다. 네임스페이스는 Amazon ECS 서비스 및 클러스터와 같은 AWS 리전에 있어야 합니다. AWS Cloud Map의 네임스페이스 유형은 Service Connect에 영향을 주지 않습니다. 네임스페이스는 AWS RAM 가 사용 가능한 AWS 리전에서 AWS Resource Access Manager(AWS RAM)를 사용하여 AWS 계정과 공유되는 네임스페이스일 수 있습니다. 공유 네임스페이스에 대한 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)을 참조하세요. Service Connect는 AWS Cloud Map 네임스페이스를 서로 통신하는 Amazon ECS 작업의 논리적 그룹으로 사용합니다. 각 Amazon ECS 서비스는 하나의 네임스페이스에만 속할 수 있습니다. 네임스페이스 내 서비스는 동일한 AWS 리전에 있는 여러 Amazon ECS 클러스터에 분산될 수 있습니다. 네임스페이스가 공유 네임스페이스인 경우 서비스는 네임스페이스 소유자 및 네임스페이스 소비자 AWS 계정에서 분산될 수 있습니다. 어떤 기준으로든 서비스를 자유롭게 구성할 수 있습니다. **클라이언트 서비스** 네트워크 클라이언트 애플리케이션을 실행하는 서비스입니다. 이 서비스에는 네임스페이스가 구성되어 있어야 합니다. 서비스의 각 작업은 Service Connect 프록시 컨테이너를 통해 네임스페이스의 모든 엔드포인트를 검색하고 연결할 수 있습니다. 작업의 컨테이너에서 네임스페이스의 서비스에서 엔드포인트에 연결해야 하는 경우 클라이언트 서비스를 선택합니다. 프런트엔드, 리버스 프록시 또는 로드 밸런서 애플리케이션이 Elastic Load Balancing 등의 다른 방법을 통해 외부 트래픽을 수신하는 경우 이 유형의 Service Connect 구성 유형을 사용할 수 있습니다. **클라이언트-서버 서비스** 네트워크 또는 웹 서비스 애플리케이션을 실행하는 Amazon ECS 서비스입니다. 이 서비스에는 네임스페이스와 하나 이상의 엔드포인트가 구성되어 있어야 합니다. 서비스의 각 작업은 엔드포인트를 사용하여 연결할 수 있습니다. Service Connect 프록시 컨테이너는 엔드포인트 이름과 포트에서 수신 대기하여 트래픽을 작업의 앱 컨테이너로 보냅니다. 네트워크 트래픽을 위해 포트를 노출하고 해당 포트에서 수신 대기하는 컨테이너가 있는 경우 클라이언트-서버 서비스를 선택합니다. 이러한 애플리케이션은 동일한 네임스페이스의 다른 클라이언트-서버 서비스에 연결할 필요는 없지만 클라이언트 구성이 필요합니다. 백엔드, 미들웨어, 비즈니스 티어 또는 대부분의 마이크로서비스는 이 유형의 Service Connect 구성을 사용할 수 있습니다. 프런트엔드, 리버스 프록시 또는 로드 밸런서 애플리케이션이 동일한 네임스페이스의 Service Connect로 구성된 다른 서비스로부터 트래픽을 수신하도록 하려면 이러한 서비스가 이 유형의 Service Connect 구성을 사용해야 합니다. Service Connect 기능은 관련 서비스의 가상 네트워크를 생성합니다. 동일한 서비스 구성을 여러 네임스페이스에서 사용하여 독립적이면서도 동일한 애플리케이션 세트를 실행할 수 있습니다. Service Connect는 Amazon ECS 서비스의 프록시 컨테이너를 정의합니다. 이렇게 하면 동일한 작업 정의를 사용하여 Service Connect 구성이 다른 여러 네임스페이스에서 동일한 애플리케이션을 실행할 수 있습니다. 서비스가 만드는 각 태스크는 태스크의 프록시 컨테이너를 실행합니다. Service Connect는 동일한 네임스페이스 내의 Amazon ECS 서비스 간 연결에 적합합니다. 다음 애플리케이션의 경우 추가 상호 연결 방법을 사용하여 Service Connect로 구성된 Amazon ECS 서비스에 연결해야 합니다. + 다른 네임스페이스에서 구성된 태스크 + Service Connect에 대해 구성되지 않은 태스크 + Amazon ECS 외부의 기타 애플리케이션 이러한 애플리케이션은 Service Connect 프록시를 통해 연결할 수 있지만 Service Connect 엔드포인트 이름을 확인할 수는 없습니다. 이러한 애플리케이션이 Amazon ECS 작업의 IP 주소를 확인하려면 다른 상호 연결 방법을 사용해야 합니다. **Topics** + [가격 책정](#service-connect-pricing) + [Amazon ECS Service Connect 구성 요소](service-connect-concepts-deploy.md) + [Amazon ECS Service Connect 구성 개요](service-connect-concepts.md) + [공유 AWS Cloud Map 네임스페이스를 사용하는 Amazon ECS Service Connect](service-connect-shared-namespaces.md) + [Amazon ECS Service Connect 액세스 로그](service-connect-envoy-access-logs.md) + [Amazon ECS Service Connect 트래픽 암호화](service-connect-tls.md) + [AWS CLI를 사용한 Amazon ECS Service Connect 구성](create-service-connect.md) ## 가격 책정 + Amazon ECS Service Connect 요금은 AWS Fargate 또는 컨테이너식 워크로드를 호스팅하는 Amazon EC2 인프라의 사용 여부에 따라 달라집니다. AWS Outposts에서 Amazon ECS를 사용하는 경우 요금은 Amazon EC2를 직접 사용할 때와 동일한 모델을 따릅니다. 자세한 내용은 [Amazon ECS 요금](https://aws.amazon.com/ecs/pricing)을 참조하세요. + Amazon ECS Service Connect 사용에 따른 추가 요금은 없습니다. + Service Connect에서 사용하는 경우 AWS Cloud Map 사용에 따른 추가 요금은 없습니다. + 고객은 vCPU 및 메모리를 비롯하여 Amazon ECS Service Connect에서 사용하는 컴퓨팅 리소스에 대한 비용을 지불합니다. Amazon ECS Service Connect 에이전트는 고객 태스크 내에서 실행되므로 실행에 따른 추가 요금은 없습니다. 태스크 리소스는 고객 워크로드와 Amazon ECS Service Connect 에이전트 간에 공유됩니다. + AWS Private CA에서 Amazon ECS Service Connect 트래픽 암호화 기능을 사용하는 경우, 고객은 생성한 프라이빗 인증 기관과 발급된 각 TLS 인증서에 대한 비용을 지불합니다. 자세한 내용은 [AWS Private Certificate Authority 요금](https://aws.amazon.com/private-ca/pricing/)을 참조하세요. TLS 인증서의 월별 비용을 추정하려면 고객은 TLS가 활성화된 Amazon ECS 서비스의 수를 파악하여 인증서 비용을 곱한 다음 6을 곱해야 합니다. Amazon ECS Service Connect는 5일마다 TLS 인증서를 자동으로 교체하므로, Amazon ECS 서비스당 월 평균 6개의 인증서가 발급됩니다. # Amazon ECS Service Connect 구성 요소 Amazon ECS Service Connect를 사용하는 경우에는 네트워크 요청을 받는 서버 애플리케이션(클라이언트-서버 서비스)을 실행하거나 요청을 생성하는 클라이언트 애플리케이션(클라이언트 서비스)을 실행하도록 각 Amazon ECS 서비스를 구성합니다. Service Connect 사용을 시작할 준비가 되면 클라이언트-서버 서비스로 시작합니다. 새 서비스 또는 기존 서비스에 Service Connect 구성을 추가할 수 있습니다. Amazon ECS는 네임스페이스에 Service Connect 엔드포인트를 생성합니다. 추가로 Amazon ECS는 서비스에 새 배포를 생성하여 현재 실행 중인 작업을 대체합니다. 기존 작업 및 기타 애플리케이션은 기존 엔드포인트 및 외부 애플리케이션에 계속 연결할 수 있습니다. 클라이언트-서버 서비스가 스케일 아웃을 통해 태스크를 추가하면 클라이언트의 새 연결이 모든 태스크 간에 즉시 밸런싱됩니다. 클라이언트-서버 서비스가 업데이트된 경우 클라이언트의 새 연결은 새 버전의 태스크 사이에서 밸런싱됩니다. 기존 작업은 확인할 수 없으며 새 엔드포인트에 연결할 수 없습니다. 동일한 네임스페이스에 Service Connect 구성이 있고 이 배포 이후에 실행을 시작하는 새 태스크만 이 엔드포인트를 확인하고 여기에 연결할 수 있습니다. 즉, 서버 애플리케이션 운영자가 언제든지 구성을 변경할 수 있더라도 클라이언트 애플리케이션 운영자가 앱 구성이 변경되는 시기를 결정합니다. 네임스페이스의 엔드포인트 목록은 네임스페이스의 서비스가 배포될 때마다 변경될 수 있습니다. 기존 태스크와 대체 태스크는 최근 배포 후에도 동일하게 작동합니다. 다음 예제를 살펴보세요. 먼저 퍼블릭 인터넷에서 사용할 수 있는 애플리케이션을 단일 AWS CloudFormation 템플릿 및 단일 CloudFormation 스택으로 생성하고 있다고 가정해 보겠습니다. 공개 검색 및 연결 가능성은 프런트엔드 클라이언트 서비스를 포함하여 CloudFormation에서 마지막으로 생성해야 합니다. 프런트엔드 클라이언트 서비스가 실행되고 퍼블릭에서 사용 가능하지만 백엔드는 사용할 수 없는 기간을 방지하려면 이 순서로 서비스를 생성해야 합니다. 이렇게 하면 해당 기간 동안 오류 메시지가 퍼블릭으로 전송되는 것을 방지할 수 있습니다. AWS CloudFormation에서는 `dependsOn`을 사용하여 CloudFormation에 여러 Amazon ECS 서비스를 병렬로 또는 동시에 만들 수 없음을 나타내야 합니다. 클라이언트 작업이 연결되는 각 백엔드 클라이언트-서버 서비스의 프런트엔드 클라이언트 서비스에 `dependsOn`을 추가해야 합니다. 두 번째로 프런트엔드 서비스가 Service Connect 구성 없이 존재한다고 가정합니다. 작업은 기존 백엔드 서비스에 연결되고 있습니다. 먼저 **DNS** 또는 프런트엔드가 사용하는 `clientAlias`에서의 동일한 이름을 사용하여 백엔드 서비스에 클라이언트-서버 Service Connect 구성을 추가합니다. 이렇게 하면 새 배포가 생성되므로 모든 배포 롤백 탐지 또는 AWS Management Console, AWS CLI, AWS SDK 및 기타 메서드가 백엔드 서비스를 롤백하고 이전 배포 및 구성으로 되돌릴 수 있습니다. 백엔드 서비스의 성능과 동작이 만족스러우면 프런트엔드 서비스에 클라이언트 또는 클라이언트-서버 Service Connect 구성을 추가합니다. 새 배포의 작업만 새 작업에 추가된 Service Connect 프록시를 사용합니다. 이 구성에 문제가 있는 경우 배포 롤백 탐지 또는 AWS Management Console, AWS CLI, AWS SDK 및 기타 메서드를 사용하여 백엔드 서비스를 롤백하고 이전 배포 및 구성으로 되돌려 이전 구성으로 롤백하고 되돌릴 수 있습니다. Service Connect 대신 DNS를 기반으로 하는 다른 서비스 검색 시스템을 사용하는 경우 로컬 DNS 캐시가 만료된 후 프런트엔드 또는 클라이언트 애플리케이션이 새 엔드포인트를 사용하고 엔드포인트 구성을 변경하기 시작하며, 일반적으로 몇 시간이 걸립니다. ## 네트워킹 기본적으로 Service Connect 프록시는 태스크 정의 포트 매핑의 `containerPort`에서 수신 대기합니다. 보안 그룹 규칙은 클라이언트가 실행될 서브넷에서 이 포트로 들어오는(수신) 트래픽을 허용해야 합니다. Service Connect 서비스 구성에서 포트 번호를 설정하더라도 Service Connect 프록시가 수신 대기하는 클라이언트-서버 서비스용 포트는 변경되지 않습니다. 이 포트 번호를 설정하면 Amazon ECS는 해당 작업 내의 Amazon ECS 프록시에서 클라이언트 서비스가 연결하는 엔드포인트의 포트를 변경합니다. 클라이언트 서비스의 프록시는 `containerPort`를 사용하여 클라이언트-서버 서비스의 프록시에 연결합니다. Service Connect 프록시가 수신 대기하는 포트를 변경하려면 클라이언트-서버 서비스의 Service Connect 구성에서 `ingressPortOverride`를 변경합니다. 이 포트 번호를 변경하는 경우 이 서비스에 대한 트래픽에 사용되는 이 포트의 인바운드 트래픽을 허용해야 합니다. 애플리케이션이 Service Connect용으로 구성된 Amazon ECS 서비스로 전송하는 트래픽의 경우 Amazon VPC 및 서브넷에 사용 중인 `containerPort` 및 `ingressPortOverride` 포트 번호를 허용하는 라우팅 테이블 규칙 및 네트워크 ACL 규칙이 있어야 합니다. Service Connect를 사용하여 VPC 간에 트래픽을 보낼 수 있습니다. 라우팅 테이블 규칙, 네트워크 ACL, 보안 그룹에 대한 동일한 요구 사항이 두 VPC에 모두 적용됩니다. 예를 들어, 두 개의 클러스터는 서로 다른 VPC에서 작업을 생성합니다. 각 클러스터의 서비스는 동일한 네임스페이스를 사용하도록 구성됩니다. 이 두 서비스의 애플리케이션은 VPC DNS 구성 없이 네임스페이스의 모든 엔드포인트를 확인할 수 있습니다. 하지만 VPC 피어링, VPC 또는 서브넷 라우팅 테이블, VPC 네트워크 ACL이 `containerPort` 및 `ingressPortOverride` 포트 번호의 트래픽을 허용하는 경우를 제외하면 프록시를 연결할 수 없습니다. `bridge` 네트워킹 모드를 사용하는 작업의 경우 상위 동적 포트 범위에서 트래픽을 허용하는 인바운드 규칙이 포함된 보안 그룹을 생성해야 합니다. 그런 다음, Service Connect 클러스터의 모든 EC2 인스턴스에 보안 그룹을 할당합니다. ## Service Connect 프록시 Service Connect 구성을 사용하여 서비스를 생성하거나 업데이트하는 경우 Amazon ECS는 새 태스크가 시작될 때마다 새 컨테이너를 추가합니다. 별도의 컨테이너를 사용하는 이러한 패턴을 `sidecar`라고 합니다. 이 컨테이너는 작업 정의에 없으며 구성할 수 없습니다. Amazon ECS는 서비스에서 컨테이너 구성을 관리합니다. 이렇게 하면 Service Connect 없이도 여러 서비스, 네임스페이스, 태스크 간에 동일한 태스크 정의를 재사용할 수 있습니다. **프록시 리소스** + 태스크 정의의 경우 CPU 및 메모리 파라미터를 설정해야 합니다. Service Connect 프록시 컨테이너용 작업 CPU 및 메모리에 256개의 추가 CPU 유닛과 최소 64MiB의 메모리를 추가하는 것이 좋습니다. AWS Fargate에서 설정할 수 있는 최소 메모리양은 512MiB입니다. Amazon EC2에는 태스크 정의 메모리가 필요합니다. + 서비스의 경우 Service Connect 구성에서 로그 구성을 설정합니다. + 이 서비스의 작업이 피크 부하 시 초당 500개 이상의 요청을 받을 것으로 예상되는 경우 이 작업 정의에서 Service Connect 프록시 컨테이너에 대한 작업 CPU에 512개의 CPU 유닛을 추가하는 것이 좋습니다. + 네임스페이스에서 100개 이상의 Service Connect 서비스를 생성하거나 네임스페이스 내의 모든 Amazon ECS 서비스에서 총 2000개 이상의 작업을 생성할 것으로 예상되는 경우 Service Connect 프록시 컨테이너의 작업 메모리에 128MiB의 메모리를 추가하는 것이 좋습니다. 네임스페이스의 모든 Amazon ECS 서비스에서 사용하는 모든 작업 정의에서 이 작업을 수행해야 합니다. **프록시 구성** 애플리케이션은 수행 중인 동일한 작업에서 사이드카 컨테이너의 프록시에 연결합니다. Amazon ECS는 애플리케이션이 동일한 네임스페이스의 엔드포인트 이름에 연결되는 경우에만 애플리케이션이 프록시에 연결되도록 태스크와 컨테이너를 구성합니다. 다른 모든 트래픽은 프록시를 사용하지 않습니다. 다른 트래픽에는 동일한 VPC의 IP 주소, AWS 서비스 엔드포인트 및 외부 트래픽이 포함됩니다. **로드 밸런싱** 서비스 연결은 서비스 연결 엔드포인트의 작업 간의 로드 밸런싱에 라운드 로빈 전략을 사용하도록 프록시를 구성합니다. 연결이 시작되는 작업에 있는 로컬 프록시는 엔드포인트를 제공하는 클라이언트-서버 서비스의 작업 중 하나를 선택합니다. 예를 들어 **로컬이라는 네임스페이스에 **클라이언트 서비스로 구성된 서비스에서 WordPress를 실행하는 태스크가 있다고 가정합니다. MySQL 데이터베이스를 실행하는 2개의 작업이 있는 다른 서비스도 있습니다. 이 서비스는 동일한 네임스페이스에서 서비스 연결을 통해 `mysql`이라는 엔드포인트를 제공하도록 구성되어 있습니다. WordPress작업에서 WordPress 애플리케이션은 엔드포인트 이름을 사용하여 데이터베이스에 연결합니다. 이 이름에 대한 연결은 동일한 태스크의 사이드카 컨테이너에서 실행되는 프록시로 이동합니다. 그러면 프록시는 라운드 로빈 전략을 사용하여 MySQL 작업 중 하나에 연결할 수 있습니다. 로드 밸런싱 전략: 라운드 로빈 **이상치 탐지** 이 기능은 프록시에 있는 이전에 실패한 연결에 대한 데이터를 사용하여 연결이 실패한 호스트에 새 연결이 전송되지 않도록 합니다. 서비스 연결은 프록시의 이상치 탐지 기능을 구성하여 수동 상태 확인을 제공합니다. 이전 예제를 사용하여 프록시는 MySQL 태스크 중 하나에 연결할 수 있습니다. 프록시가 특정 MySQL 작업에 여러 번 연결했는데 지난 30초간 5개 이상의 연결이 실패한 경우 프록시는 30\$1300초간 해당 MySQL 작업을 방지합니다. **재시도** 서비스 연결은 프록시를 통과하여 실패한 연결을 다시 시도하도록 프록시를 구성하고, 두 번째 시도에서는 이전 연결의 호스트를 사용하지 않습니다. 이렇게 하면 서비스 연결을 통한 각 연결이 일회성 이유로 실패하지 않게 됩니다. 재시도 횟수: 2 **제한 시간** 서비스 연결은 클라이언트-서버 애플리케이션이 응답할 때까지 최대 시간을 대기하도록 프록시를 구성합니다. 기본 제한 시간 값은 15초이지만 업데이트할 수 있습니다. 선택적 파라미터: **idleTimeout** - 유휴 상태에서 연결이 활성 상태로 유지되는 시간(초)입니다. 값이 `0`이면 `idleTimeout`이 비활성화됩니다. `HTTP`/`HTTP2`/`GRPC`의 `idleTimeout` 기본값은 5분입니다. `TCP`의 `idleTimeout` 기본값은 1시간입니다. **perRequestTimeout** - 업스트림이 요청당 완전한 응답으로 응답할 때까지 기다리는 시간입니다. 값이 `0`이면 `perRequestTimeout`이 꺼집니다. 애플리케이션 컨테이너에 대한 `appProtocol`이 `HTTP`/`HTTP2`/`GRPC`인 경우에만 설정할 수 있습니다. 기본값은 15초입니다. `idleTimeout`이 `perRequestTimeout`보다 짧은 시간으로 설정되는 경우 `perRequestTimeout`가 아닌 `idleTimeout`에 도달하면 연결이 닫힙니다. ## 고려 사항 Service Connect를 사용할 때는 다음을 고려하세요. + Service Connect를 사용하려면 Fargate에서 실행되는 태스크가 Fargate Linux 플랫폼 버전 `1.4.0` 이상을 사용해야 합니다. + 컨테이너 인스턴스의 Amazon ECS 에이전트 버전은 `1.67.2` 이상이어야 합니다. + 서비스 연결을 사용하려면 컨테이너 인스턴스가 Amazon ECS 최적화 Amazon Linux 2023 AMI 버전 `20230428` 이상 또는 Amazon ECS 최적화 Amazon Linux 2 AMI 버전 `2.0.20221115`를 실행해야 합니다. 이러한 버전에는 Amazon ECS 컨테이너 에이전트 외에 서비스 연결 에이전트가 있습니다. 서비스 연결 에이전트에 대한 자세한 내용은 GitHub의 [Amazon ECS Service Connect Agent](https://github.com/aws/amazon-ecs-service-connect-agent)를 참조하세요. + 컨테이너 인스턴스에 리소스 `arn:aws:ecs:region:0123456789012:task-set/cluster/*`에 대한 `ecs:Poll` 권한이 있어야 합니다. `ecsInstanceRole`을 사용하는 경우에는 권한을 더 추가할 필요가 없습니다. `AmazonEC2ContainerServiceforEC2Role` 관리형 정책에 필요한 권한이 있습니다. 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 IAM 역할](instance_IAM_role.md) 섹션을 참조하세요. + `bridge` 네트워크 모드를 사용하고 Service Connect를 사용하는 작업은 `hostname` 컨테이너 정의 파라미터를 지원하지 않습니다. + 작업 정의는 Service Connect를 사용하는 작업 메모리 제한을 설정해야 합니다. 자세한 내용은 [Service Connect 프록시](#service-connect-concepts-proxy) 섹션을 참조하세요. + 컨테이너 메모리 제한을 설정하는 태스크 정의는 지원되지 않습니다. 컨테이너에 컨테이너 메모리 제한을 설정할 수 있지만 작업 메모리 제한을 컨테이너 메모리 제한의 합보다 큰 값으로 설정해야 합니다. 컨테이너 제한에 할당되지 않은 작업 제한의 추가 CPU 및 메모리는 Service Connect 프록시 컨테이너 및 컨테이너 제한을 설정하지 않은 다른 컨테이너에서 사용됩니다. 자세한 내용은 [Service Connect 프록시](#service-connect-concepts-proxy) 섹션을 참조하세요. + 동일한 AWS 계정에 있거나 AWS Resource Access Manager를 사용하여 AWS 계정에서 공유되는 동일한 리전 내 모든 AWS Cloud Map 네임스페이스를 사용하도록 Service Connect를 구성할 수 있습니다. 공유 네임스페이스 사용에 대한 자세한 내용은 [공유 AWS Cloud Map 네임스페이스를 사용하는 Amazon ECS Service Connect](service-connect-shared-namespaces.md) 섹션을 참조하세요. + 각 서비스는 하나의 네임스페이스에만 속할 수 있습니다. + 서비스에서 생성하는 태스크만 지원됩니다. + 모든 엔드포인트는 네임스페이스 내에서 고유해야 합니다. + 모든 검색 이름은 네임스페이스 내에서 고유해야 합니다. + 애플리케이션이 새 엔드포인트를 확인하기 전에 기존 서비스를 다시 배포해야 합니다. 최신 배포 후 네임스페이스에 추가된 새 엔드포인트는 작업 구성에 추가되지 않습니다. 자세한 내용은 [Amazon ECS Service Connect 구성 요소](#service-connect-concepts-deploy) 섹션을 참조하세요. + Service Connect는 클러스터가 삭제될 때 네임스페이스를 삭제하지 않습니다. AWS Cloud Map에서 네임스페이스를 삭제해야 합니다. + Application Load Balancer 트래픽은 기본적으로 `awsvpc` 네트워크 모드에서 Service Connect 에이전트를 통해 라우팅됩니다. 서비스 이외의 트래픽이 Service Connect 에이전트를 우회하도록 하려면 Service Connect 서비스 구성에서 `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` 파라미터를 사용합니다. + TLS를 사용하는 Service Connect는 `bridge` 네트워킹 모드를 지원하지 않습니다. `awsvpc` 네트워킹 모드만 지원됩니다. + `awsvpc` 모드에서 Service Connect 프록시는 IPv4 전용 및 듀얼 스택 구성의 서비스에 대해 IPv4 localhost `127.0.0.1`로 트래픽을 전달합니다. IPv6 전용 구성의 서비스인 경우 프록시는 IPv6 로컬 호스트 `::1`에 트래픽을 전달합니다. 서비스가 IPv4 전용 또는 듀얼 스택 구성에서 IPv6 전용으로 업데이트될 때 원활한 경험을 위해 두 localhost를 모두 수신하도록 애플리케이션을 구성하는 것이 좋습니다. 자세한 내용은 [EC2에 대한 Amazon ECS 태스크 네트워킹 옵션](task-networking.md) 및 [Fargate에 대한 Amazon ECS 태스크 네트워킹 옵션](fargate-task-networking.md)(을)를 참조하세요. **Service Connect는 다음을 지원하지 않습니다.** + Windows 컨테이너 + HTTP 1.0 + 독립 실행형 작업 + CodeDeploy 및 외부 배포 유형에서 지원하는 블루/그린을 사용하는 서비스 + Amazon ECS Anywhere용 `External` 컨테이너 인스턴스는 Service Connect에서 지원되지 않습니다. + PPv2 + FIPS 모드 # Amazon ECS Service Connect 구성 개요 Service Connect를 사용하는 경우 리소스에서 구성해야 하는 파라미터가 있습니다. 다음 표에는 Amazon ECS 리소스의 구성 파라미터가 설명되어 있습니다. | 파라미터 위치 | 앱 유형 | 설명 | 필수 | | --- | --- | --- | --- | | 태스크 정의 | 클라이언트 | 클라이언트 작업 정의에서 Service Connect에 사용할 수 있는 변경 사항이 없습니다. | 해당 사항 없음 | | 태스크 정의 | 클라이언트-서버 | 서버는 컨테이너의 portMappings에 있는 포트에 name 필드를 추가해야 합니다. 자세한 내용은 [portMappings](task_definition_parameters.md#ContainerDefinition-portMappings) 섹션을 참조하세요. | 예 | | 태스크 정의 | 클라이언트-서버 | 서버는 선택적으로 애플리케이션 프로토콜(예: HTTP)을 제공하여 서버 애플리케이션에 대한 프로토콜별 지표를 수신할 수 있습니다(예: HTTP 5xx). | 아니요 | | 서비스 정의 | 클라이언트 | 조인할 네임스페이스를 구성하려면 클라이언트 서비스에서 serviceConnectConfiguration을 추가해야 합니다. 이 네임스페이스에는 이 서비스가 검색해야 하는 모든 서버 서비스가 포함되어야 합니다. 자세한 내용은 [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration) 섹션을 참조하세요. | 예 | | 서비스 정의 | 클라이언트-서버 | 서버 서비스에서 serviceConnectConfiguration을 추가하여 서비스에서 사용할 수 있는 DNS 이름, 포트 번호 및 네임스페이스를 구성해야 합니다. 자세한 내용은 [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration) 섹션을 참조하세요. | 예 | | 클러스터 | 클라이언트 | 클러스터는 기본 Service Connect 네임스페이스를 추가할 수 있습니다. 클러스터의 새 서비스는 Service Connect가 서비스에서 구성된 경우 네임스페이스를 상속합니다. | 아니요 | | 클러스터 | 클라이언트-서버 | 서버 서비스에 적용되는 클러스터의 Service Connect에 사용할 수 있는 변경 사항이 없습니다. 서버 작업 정의 및 서비스는 해당 구성을 설정해야 합니다. | 해당 사항 없음 | **Service Connect 구성 단계 개요** 다음 단계는 Service Connect 구성 방법의 개요를 제공합니다. **중요** Service Connect에서 사용자 계정에 AWS Cloud Map 서비스를 생성합니다. 인스턴스를 수동으로 등록/등록 취소하거나, 인스턴스 속성을 변경하거나, 서비스를 삭제하여 이러한 AWS Cloud Map 리소스를 수정하면 애플리케이션 트래픽 또는 후속 배포에서 예상치 못한 동작이 발생할 수 있습니다. Service Connect는 태스크 정의에서 링크를 지원하지 않습니다. 1. 작업 정의의 포트 매핑에 포트 이름을 추가합니다. 또한 애플리케이션의 계층 7 프로토콜을 식별하여 추가 지표를 얻을 수 있습니다. 1. AWS Cloud Map 네임스페이스를 사용하거나 ECS 클러스터를 생성하거나 네임스페이스를 별도로 생성합니다. 간단한 구성을 위해 네임스페이스에 원하는 이름을 사용하여 클러스터를 생성하고 네임스페이스에 동일한 이름을 지정합니다. 이 경우 Amazon ECS는 필요한 구성으로 새 HTTP 네임스페이스를 생성합니다. Service Connect는 Amazon Route 53에서 DNS 호스팅 영역을 사용하거나 생성하지 않습니다. 1. 네임스페이스 내에 Service Connect 엔드포인트를 생성하도록 서비스를 구성합니다. 1. 서비스를 배포하여 엔드포인트를 생성합니다. Amazon ECS는 각 작업에 Service Connect 프록시 컨테이너를 추가하고 AWS Cloud Map에 Service Connect 엔드포인트를 생성합니다. 이 컨테이너는 작업 정의에 구성되어 있지 않고, 작업 정의를 수정하지 않고 재사용하여 동일한 네임스페이스 또는 여러 네임스페이스에 여러 서비스를 생성할 수 있습니다. 1. 엔드포인트에 연결할 클라이언트 앱을 서비스로 배포합니다. Amazon ECS는 각 작업에서 Service Connect 프록시를 통해 이를 Service Connect 엔드포인트에 연결합니다. 애플리케이션은 프록시를 서비스 연결 엔드포인트에 연결하는 데에만 사용합니다. 프록시를 사용하기 위한 추가 구성은 없습니다. 프록시는 라운드 로빈 로드 밸런싱, 이상값 탐지 및 재시도를 수행합니다. 프록시에 대한 자세한 내용은 [Service Connect 프록시](service-connect-concepts-deploy.md#service-connect-concepts-proxy)를 참조하세요. 1. Amazon CloudWatch의 Service Connect 프록시를 통해 트래픽을 모니터링합니다. ## 클러스터 구성 클러스터를 생성하거나 업데이트할 때 Service Connect의 기본 네임스페이스를 설정할 수 있습니다. 기본값으로 지정하는 네임스페이스 이름은 동일한 AWS 리전 및 계정에 있거나 동일한 AWS 리전에 있고 AWS Resource Access Manager를 사용하여 다른 AWS 계정에서 공유될 수 있습니다. 클러스터를 생성하고 기본 Service Connect 네임스페이스를 지정하면 클러스터는 Amazon ECS가 네임스페이스를 생성하는 동안 `PROVISIONING` 상태로 대기합니다. 네임스페이스의 상태를 나타내는 클러스터 상태에서 `attachment`를 볼 수 있습니다. 연결은 기본적으로 AWS CLI에 표시되지 않으므로 연결을 보려면 `--include ATTACHMENTS`를 추가해야 합니다. AWS RAM를 사용하여 AWS 계정과 공유되는 네임스페이스를 사용하려면 클러스터 구성에서 네임스페이스의 Amazon 리소스 이름(ARN)을 지정합니다. 공유 AWS Cloud Map 스페이스에 대한 자세한 내용은 [공유 AWS Cloud Map 네임스페이스를 사용하는 Amazon ECS Service Connect](service-connect-shared-namespaces.md) 섹션을 참조하세요. ## 서비스 구성 Service Connect는 최소 구성을 요구하도록 설계됩니다. 작업 정의의 Service Connect에서 사용할 각 포트 매핑의 이름을 설정해야 합니다. 서비스에서 클라이언트 서비스를 만들려면 Service Connect를 켜고 AWS 계정의 네임스페이스 또는 공유 네임스페이스를 선택해야 합니다. 클라이언트-서버 서비스를 만들려면 포트 매핑 중 하나의 이름과 일치하는 단일 Service Connect 서비스 구성을 추가해야 합니다. Amazon ECS는 작업 정의의 포트 번호와 포트 이름을 재사용하여 Service Connect 서비스와 엔드포인트를 정의합니다. 이러한 값을 재정의하려면 콘솔에서 다른 파라미터인 **Discovery**, **DNS** 및 **Port**를 사용하거나 Amazon ECS API에서 `discoveryName` 및 `clientAliases`를 각각 사용할 수 있습니다. ## 초기 상태 확인 구성 Service Connect는 트래픽을 라우팅하기 전에 작업이 정상인지 확인합니다. 태스크가 시작되면(배포, 조정 중 또는 교체) Service Connect는 태스크 상태를 모니터링하여 트래픽을 수락할 준비가 되었는지 확인합니다. 이 동작을 활성화하려면 태스크 정의에서 필수 컨테이너에 대한 상태 확인을 정의해야 합니다. 초기 상태 확인의 동작은 태스크가 트래픽을 수락할 준비가 되었을 때 상태에 도달하는 데 발생할 수 있는 지연을 설명합니다. + 태스크가 `HEALTHY`인 경우 트래픽에 대해 즉시 사용할 수 있습니다. + 태스크 상태가 `UNKNOWN`인 경우 Service Connect는 태스크의 필수 컨테이너의 컨테이너 상태 확인 구성([상태 확인](task_definition_parameters.md#container_definition_healthcheck) 참조)을 따라 `8 minutes` 상태로 남아 있더라도 트래픽에 대해 사용 가능해지기 전에 최대 `UNKNOWN`의 제한 시간을 계산합니다. + 태스크가 `UNHEALTHY`인 경우, Amazon ECS는 대체 태스크를 시작할 수 있습니다. 사용 가능한 정상 태스크가 없는 경우 서비스의 구성에 따라 배포가 롤백될 수 있습니다. Service Connect는 진행 중인 모든 트래픽에 대해 이상치 감지를 기반으로 하는 수동 상태 확인을 사용하여 트래픽을 효율적으로 라우팅합니다. # 공유 AWS Cloud Map 네임스페이스를 사용하는 Amazon ECS Service Connect Amazon ECS Service Connect는 동일한 AWS 리전 내 여러 AWS 계정에서 공유 AWS Cloud Map 네임스페이스 사용을 지원합니다. 이 기능을 사용하면 다른 AWS 계정에서 실행되는 서비스가 Service Connect를 통해 서로 검색하고 통신할 수 있는 분산 애플리케이션을 생성할 수 있습니다. 공유 네임스페이스는 안전한 교차 계정 리소스 공유를 허용하는 AWS Resource Access Manager(AWS RAM)를 사용하여 관리됩니다. 공유 네임스페이스에 대한 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)을 참조하세요. **중요** `AWSRAMPermissionCloudMapECSFullPermission` 관리형 권한을 사용하여 Service Connect가 네임스페이스와 제대로 작동하도록 네임스페이스를 공유해야 합니다. Service Connect에서 공유 AWS Cloud Map 네임스페이스를 사용하면 여러 AWS 계정의 서비스가 동일한 서비스 네임스페이스에 참여할 수 있습니다. 이는 보안 및 격리를 유지하면서 계정 경계를 넘어 서비스 간 통신을 유지 관리해야 하는 여러 AWS 계정이 있는 조직에 특히 유용합니다. **참고** 여러 VPC에 있는 서비스와 통신하려면 VPC 간 연결성을 구성해야 합니다. VPC 피어링 연결을 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 *Amazon Virtual Private Cloud VPC 피어링 가이드*의 [VPC 피어링 연결 생성](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html)을 참조하세요. # Amazon ECS Service Connect에서 공유 AWS Cloud Map 네임스페이스 사용 Service Connect에 대한 공유 AWS Cloud Map 네임스페이스 설정에는 네임스페이스 소유자가 네임스페이스 생성, AWS Resource Access Manager(AWS RAM)를 통한 소유자 공유, 소비자의 리소스 공유 수락, 공유 네임스페이스를 사용하도록 소비자의 Service Connect 구성과 같은 단계가 포함됩니다. ## 1단계: AWS Cloud Map 네임스페이스 생성 네임스페이스 소유자는 다른 계정과 공유할 AWS Cloud Map 네임스페이스를 생성합니다. **AWS Management Console을 사용하여 공유를 위한 네임스페이스를 생성하는 방법** 1. [https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/)에서 AWS Cloud Map 콘솔을 엽니다. 1. **Create namespace(네임스페이스 생성)**를 선택합니다. 1. **네임스페이스 이름**을 입력하세요. 이 이름은 모든 참여 계정의 서비스에서 사용됩니다. 1. **네임스페이스 유형**에서 사용 사례에 적합한 유형을 선택하세요. + **API 직접 호출** - DNS 기능이 없는 서비스 검색을 위한 HTTP 네임스페이스. + **VPC에서 API 직접 호출 및 DNS 쿼리** - VPC의 프라이빗 DNS 쿼리로의 서비스 검색을 위한 프라이빗 DNS 네임스페이스. + **API 직접 호출 및 퍼블릭 DNS 쿼리** - 퍼블릭 DNS 쿼리로의 서비스 검색을 위한 퍼블릭 DNS 네임스페이스. 1. **Create namespace(네임스페이스 생성)**를 선택합니다. ## 2단계: AWS RAM를 사용하여 네임스페이스 공유 네임스페이스 소유자는 AWS RAM를 사용하여 네임스페이스를 다른 AWS 계정과 공유합니다. **AWS RAM 콘솔을 사용하여 네임스페이스를 공유하는 방법** 1. AWS RAM 콘솔([https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/))을 엽니다. 1. **리소스 공유 생성**을 선택합니다. 1. **이름**에 리소스 공유를 설명하는 이름을 입력합니다. 1. **리소스** 섹션에서 다음을 수행합니다. 1. **리소스 유형**에서 **클라우드 맵 네임스페이스**를 선택하세요. 1. 이전 단계에서 생성한 클러스터를 선택하세요. 1. **관리형 권한** 섹션에서 **AWSRAMPermissionCloudMapECSFullPermission**을 지정하세요. **중요** `AWSRAMPermissionCloudMapECSFullPermission` 관리형 권한을 사용하여 Service Connect가 네임스페이스와 제대로 작동하도록 네임스페이스를 공유해야 합니다. 1. **위탁자** 섹션에서 네임스페이스를 공유할 AWS 계정과 지정하세요. 계정 ID 또는 조직 단위 ID를 입력할 수 있습니다. 1. **리소스 공유 생성**을 선택합니다. ## 3단계: 리소스 공유 수락 네임스페이스 소비자 계정은 공유 네임스페이스를 사용하려면 리소스 공유 초대를 수락해야 합니다. **AWS RAM 콘솔을 사용하여 리소스 공유 초대를 수락하는 방법** 1. 소비자 계정에서 AWS RAM 콘솔([https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/))을 여세요. 1. 탐색 창에서 **나와 공유됨**, **리소스 공유**를 선택하세요. 1. 리소스 공유 초대를 선택하고 **리소스 공유 수락**을 선택하세요. 1. 수락한 후 리소스 세부 정보에서 공유 네임스페이스 ARN을 기록하세요. Service Connect 서비스를 구성할 때 이 ARN을 사용합니다. ## 4단계: 공유 네임스페이스를 사용하여 Amazon ECS 서비스 구성 공유 네임스페이스를 수락한 후 네임스페이스 소비자는 공유 네임스페이스를 사용하도록 Amazon ECS 서비스를 구성할 수 있습니다. 구성은 일반 네임스페이스를 사용하는 방식과 비슷하지만 이름 대신 네임스페이스 ARN을 지정해야 합니다. 자세한 서비스 생성 절차는 [Amazon ECS 롤링 업데이트 배포 생성](create-service-console-v2.md) 섹션을 참조하세요. **AWS Management Console을 사용하여 공유 네임스페이스가 있는 서비스를 생성하는 방법** 1. [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)에서 콘솔을 엽니다. 1. **클러스터** 페이지에서 서비스를 생성하려는 클러스터를 선택하세요. 1. **서비스**에서 **생성**을 선택하세요. 1. 워크로드에 따라 다른 세부 정보를 입력한 후 **Service Connect** 섹션에서 **Service Connect 사용**을 선택하세요. 1. **네임스페이스**에 공유 네임스페이스의 전체 ARN을 입력하세요. ARN 형식은 `arn:aws:servicediscovery:region:account-id:namespace/namespace-id`입니다. 1. 서비스 유형(클라이언트 또는 클라이언트-서버)에 따라 나머지 Service Connect 설정을 구성하세요. 1. 서비스 생성 프로세스를 완료하세요. `serviceConnectConfiguration`의 `namespace` 파라미터에 공유 네임스페이스 ARN을 지정하여 AWS CLI 또는 AWS SDK를 사용하여 서비스를 구성할 수도 있습니다. ``` aws ecs create-service \ --cluster my-cluster \ --service-name my-service \ --task-definition my-task-def \ --service-connect-configuration '{ "enabled": true, "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890", "services": [{ "portName": "web", "discoveryName": "my-service", "clientAliases": [{ "port": 80, "dnsName": "my-service" }] }] }' ``` ## 고려 사항 Service Connect에서 AWS Cloud Map 네임스페이스를 사용하는 경우 다음을 고려합니다. + AWS RAM는 공유 네임스페이스를 사용하려는 AWS 리전에서 사용할 수 있어야 합니다. + 네임스페이스는 Amazon ECS 서비스 및 클러스터와 같은 AWS 리전에 있어야 합니다. + 공유 네임스페이스로 Service Connect를 구성할 경우 ID가 아닌 네임스페이스 ARN을 사용해야 합니다. + HTTP, 프라이빗 DNS, 퍼블릭 DNS 네임스페이스와 같은 모든 네임스페이스 유형이 지원됩니다. + 공유 네임스페이스에 대한 액세스가 취소되면 네임스페이스(예: `CreateService`, `UpdateService`, `ListServicesByNamespace`)와의 상호 작용이 필요한 Amazon ECS 작업이 실패합니다. 공유 네임스페이스의 권한 문제 해결에 대한 자세한 내용은 [공유 AWS Cloud Map 네임스페이스를 사용한 Amazon ECS Service Connect 문제 해결](service-connect-shared-namespaces-troubleshooting.md) 섹션을 참조하세요. + 공유 프라이빗 DNS 네임스페이스에서 DNS 쿼리를 사용하는 서비스 검색의 경우: + 네임스페이스 소유자는 네임스페이스와 연결된 프라이빗 호스팅 영역의 ID와 소비자의 VPC를 사용하여 `create-vpc-association-authorization`을 직접 호출해야 합니다. ``` aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678 ``` + 네임스페이스 소비자는 프라이빗 호스팅 영역의 ID를 사용하여 `associate-vpc-with-hosted-zone`을 직접 호출해야 합니다. ``` aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678 ``` + 네임스페이스 소유자만 리소스 공유를 관리할 수 있습니다. + 네임스페이스 소비자는 공유 네임스페이스 내에서 서비스를 생성하고 관리할 수 있지만 네임스페이스 자체는 수정할 수 없습니다. + 검색 이름은 서비스를 생성하는 계정에 관계없이 공유 네임스페이스 내에서 고유해야 합니다. + 공유 네임스페이스의 서비스는 네임스페이스에 액세스하는 다른 AWS 계정에서 서비스를 검색하고 연결할 수 있습니다. + Service Connect에 대한 TLS를 활성화하고 공유 네임스페이스를 사용하는 경우 AWS Private CA 인증 기관(CA)의 범위가 네임스페이스로 지정됩니다. 공유 네임스페이스에 대한 액세스가 취소되면 CA에 대한 액세스가 중지됩니다. + 공유 네임스페이스로 작업할 때 네임스페이스 소유자와 소비자는 기본적으로 교차 계정 Amazon CloudWatch 지표에 액세스할 수 없습니다. 대상 지표는 클라이언트 서비스를 소유한 계정에만 게시됩니다. 클라이언트 서비스를 소유한 계정은 클라이언트-서버 서비스를 소유한 계정에서 수신한 지표에 액세스할 수 없으며 반대도 마찬가지입니다. 지표에 대한 교차 계정 액세스를 허용하려면 CloudWatch 교차 계정 관찰성을 설정합니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch 크로스 계정 관찰성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)을 참조하세요. Service Connect용 CloudWatch 지표에 대한 자세한 내용은 [Amazon ECS CloudWatch 지표](available-metrics.md) 섹션을 참조하세요. # 공유 AWS Cloud Map 네임스페이스를 사용한 Amazon ECS Service Connect 문제 해결 다음 정보를 활용하여 공유 AWS Cloud Map 네임스페이스 및 Service Connect 관련 문제를 해결합니다. 오류 메시지 찾기에 대한 자세한 내용은 [Amazon ECS 문제 해결](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html)을 참조하세요. 권한 누락으로 인해 또는 네임스페이스에 대한 액세스가 취소된 경우 권한 문제와 관련된 오류 메시지가 나타납니다. **중요** `AWSRAMPermissionCloudMapECSFullPermission` 관리형 권한을 사용하여 Service Connect가 네임스페이스와 제대로 작동하도록 네임스페이스를 공유해야 합니다. 오류 메시지는 다음 형식 중 하나로 표시됩니다. An error occurred (ClientException) when calling the
If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
For online documentation and support please refer to
nginx.org.
Commercial support is available at
nginx.com.
Thank you for using nginx.
``` **Service Connect 지표 보기** Service Connect 프록시는 CloudWatch 지표에 애플리케이션(HTTP, HTTP2, gRPC 또는 TCP 연결) 지표를 생성합니다. CloudWatch 콘솔을 사용하는 경우 Amazon ECS 네임스페이스에서 **DiscoveryName**, (**DiscoveryName, ServiceName, ClusterName**), **TargetDiscoveryName**, (**TargetDiscoveryName, ServiceName, ClusterName**)의 추가 지표 차원을 확인합니다. 이러한 지표 및 차원에 대한 자세한 내용은 Amazon CloudWatch Logs 사용 설명서의 [View Available Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)를 참조하세요. # 서비스 검색을 사용하여 Amazon ECS 서비스를 DNS 이름으로 연결 Amazon ECS 서비스는 Amazon ECS 서비스 검색을 사용하도록 구성할 수도 있습니다. 서비스 검색은 AWS Cloud Map API 태스크를 사용하여 Amazon ECS 서비스에 대한 HTTP 및 DNS 네임스페이스를 관리합니다. 자세한 내용은 *AWS Cloud Map 개발자 안내서*의 [AWS Cloud Map란 무엇입니까?](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html)를 참조하세요. 서비스 검색은 다음 AWS 리전에서 사용할 수 있습니다. | 리전 이름 | 리전 | | --- | --- | | 미국 동부(버지니아 북부) | us-east-1 | | 미국 동부(오하이오) | us-east-2 | | 미국 서부(캘리포니아 북부) | us-west-1 | | 미국 서부(오리건) | us-west-2 | | 아프리카(케이프타운) | af-south-1 | | 아시아 태평양(홍콩) | ap-east-1 | | 아시아 태평양(타이베이) | ap-east-2 | | 아시아 태평양(뭄바이) | ap-south-1 | | 아시아 태평양(하이데라바드) | ap-south-2 | | 아시아 태평양(도쿄) | ap-northeast-1 | | 아시아 태평양(서울) | ap-northeast-2 | | 아시아 태평양(오사카) | ap-northeast-3 | | 아시아 태평양(싱가포르) | ap-southeast-1 | | 아시아 태평양(시드니) | ap-southeast-2 | | 아시아 태평양(자카르타) | ap-southeast-3 | | 아시아 태평양(멜버른) | ap-southeast-4 | | 아시아 태평양(말레이시아) | ap-southeast-5 | | 아시아 태평양(뉴질랜드) | ap-southeast-6 | | 아시아 태평양(태국) | ap-southeast-7 | | 캐나다(중부) | ca-central-1 | | 캐나다 서부(캘거리) | ca-west-1 | | 중국(베이징) | cn-north-1 | | 중국(닝샤) | cn-northwest-1 | | 유럽(프랑크푸르트) | eu-central-1 | | 유럽(취리히) | eu-central-2 | | 유럽(아일랜드) | eu-west-1 | | 유럽(런던) | eu-west-2 | | 유럽(파리) | eu-west-3 | | 유럽(밀라노) | eu-south-1 | | 유럽(스톡홀름) | eu-north-1 | | 이스라엘(텔아비브) | il-central-1 | | 유럽(스페인) | eu-south-2 | | 중동(UAE) | me-central-1 | | 멕시코(중부) | mx-central-1 | | 중동(바레인) | me-south-1 | | 남아메리카(상파울루) | sa-east-1 | | AWS GovCloud(미국 동부) | us-gov-east-1 | | AWS GovCloud(미국 서부) | us-gov-west-1 | ## 서비스 검색 개념 서비스 검색은 다음과 같은 구성 요소로 이루어집니다. + **서비스 검색 네임스페이스**: 트래픽을 라우팅할 동일한 도메인 이름(예: `example.com`)을 공유하는 서비스 검색 서비스의 논리적 그룹입니다. `aws servicediscovery create-private-dns-namespace` 명령을 직접 호출하거나 Amazon ECS 콘솔을 사용하여 네임스페이스를 생성할 수 있습니다. `aws servicediscovery list-namespaces` 명령을 사용하여 현재 계정에서 생성한 네임스페이스에 대한 요약 정보를 볼 수 있습니다. 서비스 검색 명령에 대한 자세한 정보는 *AWS Cloud Map(서비스 검색) AWS CLI 참조 가이드*의 `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)` 및 `[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)`를 참조하세요. + **서비스 검색 서비스**: 서비스 검색 네임스페이스 내에 존재하며 네임스페이스에 대한 서비스 이름과 DNS 구성으로 구성되어 있습니다. 핵심 구성 요소는 다음과 같습니다. + **서비스 레지스트리**: DNS 또는 AWS Cloud Map API 태스크를 통해 서비스를 검색하고 서비스 연결에 사용할 수 있는 하나 이상의 가용 엔드포인트를 가져올 수 있도록 허용합니다. + **서비스 검색 인스턴스**: 서비스 검색 서비스 내에 존재하며 서비스 디렉터리의 각 Amazon ECS 서비스와 연결된 속성들로 구성됩니다. + **인스턴스 속성**: 다음 메타데이터는 서비스 검색을 사용하도록 구성된 각 Amazon ECS 서비스에 대한 사용자 지정 속성으로 추가됩니다. + **`AWS_INSTANCE_IPV4`** – `A` 레코드의 경우, DNS 쿼리 및 AWS Cloud Map에 응답하여 Route 53이 반환하는 IPv4 주소는 인스턴스 세부 정보(예: `192.0.2.44`)를 검색할 때 반환됩니다. + **`AWS_INSTANCE_IPV6`** – `AAAA` 레코드의 경우 DNS 쿼리 및 AWS Cloud Map에 응답하여 Route 53이 반환하는 IPv6 주소는 인스턴스 세부 정보(예: ` 2001:0db8:85a3:0000:0000:abcd:0001:2345`)를 검색할 때 반환됩니다. Amazon ECS 듀얼 스택 서비스에 대해 `AWS_INSTANCE_IPv4` 및 `AWS_INSTANCE_IPv6`가 모두 추가됩니다. Amazon ECS IPv6 전용 서비스에 대해서는 `AWS_INSTANCE_IPv6`만 추가됩니다. + **`AWS_INSTANCE_PORT`** – 서비스 검색 서비스와 연계된 포트 값입니다. + **`AVAILABILITY_ZONE`** – 작업이 시작된 가용 영역입니다. EC2를 사용하는 태스크의 경우 이는 컨테이너 인스턴스가 존재하는 가용 영역입니다. Fargate를 사용하는 태스크의 경우 이는 탄력적 네트워크 인터페이스가 존재하는 가용 영역입니다. + **`REGION`** – 작업이 존재하는 리전입니다. + **`ECS_SERVICE_NAME`** – 작업이 속한 Amazon ECS 서비스의 이름입니다. + **`ECS_CLUSTER_NAME`** – 작업이 속한 Amazon ECS 클러스터의 이름입니다. + **`EC2_INSTANCE_ID`** – 작업이 배치된 컨테이너 인스턴스의 ID입니다. 태스크에서 Fargate를 사용하는 경우 이 사용자 지정 속성은 추가되지 않습니다. + **`ECS_TASK_DEFINITION_FAMILY`** – 작업에서 사용하는 태스크 정의 패밀리입니다. + **`ECS_TASK_SET_EXTERNAL_ID`** – 작업 세트가 외부 배포를 위해 생성되고 서비스 검색 레지스트리와 연관되는 경우 `ECS_TASK_SET_EXTERNAL_ID` 속성에는 작업 세트의 외부 ID가 포함됩니다. + **Amazon ECS 상태 확인**: Amazon ECS는 컨테이너 수준의 상태 확인을 정기적으로 수행합니다. 상태 확인을 전달하지 않는 엔드포인트는 DNS 라우팅에서 제거되고 비정상으로 상태가 표시됩니다. ## 서비스 검색 고려 사항 서비스 검색을 사용할 때는 다음 사항을 고려해야 합니다. + 플랫폼 버전 v1.1.0 이상을 사용 중인 Fargate의 작업에 대해 서비스 검색이 지원됩니다. 자세한 내용은 [Amazon ECS에 대한 Fargate 플랫폼 버전](platform-fargate.md) 섹션을 참조하세요. + 서비스 검색을 사용하도록 구성된 서비스는 서비스당 작업 수가 1,000개로 제한됩니다. 이는 Route 53 서비스 할당량 때문입니다. + Amazon ECS 콘솔의 서비스 생성 워크플로는 서비스를 프라이빗 DNS 네임스페이스에 등록하는 것만 지원합니다. AWS Cloud Map 프라이빗 DNS 네임스페이스가 생성되면 Route 53 프라이빗 호스팅 영역이 자동으로 생성됩니다. + DNS 확인에 성공하려면 VPC DNS 속성을 구성해야 합니다. 속성을 구성하는 방법에 대한 자세한 정보는 *Amazon VPC 사용 설명서*의 [VPC에서 DNS 지원](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support)을 참조하세요. + Amazon ECS는 공유 AWS Cloud Map 네임스페이스에 서비스 등록을 지원하지 않습니다. + 서비스 검색 서비스용으로 생성된 DNS 레코드는 퍼블릭 네임스페이스가 사용될 때도 퍼블릭 IP 주소 대신 항상 작업의 프라이빗 IP 주소로 등록합니다. + 서비스 검색을 위해서는 작업에서 `awsvpc`, `bridge` 또는 `host` 네트워크 모드(`none`는 지원되지 않음)를 지정해야 합니다. + 서비스 태스크 정의가 `awsvpc` 네트워크 모드를 사용하는 경우 각 서비스 태스크에 대해 `SRV` 또는 `A` 레코드를 임의로 조합해 생성할 수 있습니다. `SRV` 레코드를 사용하는 경우 포트가 필요합니다. 서비스가 듀얼 스택 서브넷을 사용하는 경우 `AAAA` 레코드를 추가로 생성할 수 있습니다. 서비스가 IPv6 전용 서브넷을 사용하는 경우 `A` 레코드를 생성할 수 없습니다. + 서비스 태스크 정의에서 `bridge` 또는 `host` 네트워크 모드를 사용하는 경우 SRV 레코드는 유일하게 지원되는 DNS 레코드 유형입니다. 각 서비스 태스크에 대한 SRV 레코드를 생성합니다. SRV 레코드는 태스크 정의로부터 컨테이너 이름과 컨테이너 포트 조합을 지정해야 합니다. + 서비스 검색 서비스를 위한 DNS 레코드는 VPC 내에서 쿼리가 가능합니다. 이들은 `Your application is now running on a container in Amazon ECS.