# Amazon ECS가 컨테이너 인스턴스에 작업을 배치하는 방법
<a name="task-placement"></a>

작업 배치를 사용하여 특정 기준(예: 가용 영역 또는 인스턴스 유형)을 충족하는 컨테이너 인스턴스에 작업을 배치하도록 Amazon ECS를 구성할 수 있습니다.

다음은 작업 배치 구성 요소입니다.
+ 작업 배치 전략 - 작업을 배치할 컨테이너 인스턴스 또는 종료할 작업을 선택하는 알고리즘입니다. 예를 들어 Amazon ECS는 무작위로 컨테이너 인스턴스를 선택하거나 인스턴스 그룹에 작업이 균등하게 배분되도록 컨테이너 인스턴스를 선택할 수 있습니다.
+ 작업 그룹 - 관련 작업 그룹(예: 데이터베이스 작업)입니다.
+ 작업 배치 제약 조건 - 컨테이너 인스턴스에 작업을 배치하기 위해 충족해야 하는 규칙입니다. 제약 조건이 충족되지 않으면 작업이 배치되지 않고 `PENDING` 상태로 유지됩니다. 예를 들어 제약 조건을 사용하여 특정 인스턴스 유형에만 작업을 배치할 수 있습니다.

Amazon ECS에는 여러 용량 옵션에 대해 서로 다른 알고리즘이 있습니다.

## Amazon ECS 관리형 인스턴스
<a name="managed-instances-launch-type"></a>

Amazon ECS 관리형 인스턴스에서 실행되는 태스크의 경우 Amazon ECS는 태스크를 배치할 위치와 태스크 수를 스케일 다운할 때 종료할 태스크를 결정해야 합니다. Amazon ECS는 용량 공급자 시작 템플릿에 지정된 인스턴스 요구 사항, CPU 및 메모리와 같은 태스크 정의에 지정된 요구 사항, 태스크 배치 제약 조건을 기반으로 이 결정을 내립니다.

**참고**  
Amazon ECS 관리형 인스턴스는 태스크 배치 전략을 지원하지 않습니다. Amazon ECS는 액세스 가능한 가용 영역 전체에 태스크를 분산시키기 위해 최선을 다합니다.

Amazon ECS는 태스크를 배치할 때 다음 프로세스를 사용하여 컨테이너 인스턴스를 선택합니다.

1. 작업 정의의 CPU, GPU, 메모리, 포트 요구 사항을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 작업 배치 제약 조건을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 용량 공급자 시작 템플릿에 지정된 인스턴스 요구 사항을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 작업 배치를 위해 컨테이너 인스턴스를 선택합니다.

## EC2
<a name="ec2-launch-type"></a>

EC2 시작 유형을 사용하는 작업의 경우 Amazon ECS는 CPU와 메모리 등 작업 정의에 지정된 요구 사항에 따라 작업 배치 위치를 결정해야 합니다. 마찬가지로 작업 수를 축소하는 경우, Amazon ECS는 어떤 태스크를 종료할지 결정해야 합니다. 작업 배치 전략과 제약을 적용하여 Amazon ECS가 태스크를 배치하고 종료하는 방법을 사용자 지정할 수 있습니다.

기본 작업 배치 전략은 작업을 수동으로 실행하는지 아니면 서비스 내에서 실행하는지에 따라 달라집니다. Amazon ECS 서비스의 일부로 실행되는 작업의 경우 기본 작업 배치 전략은 `attribute:ecs.availability-zone`을 사용하는 `spread`입니다. 서비스 중이 아닌 태스크에는 기본 태스크 배치 제약이 없습니다. 자세한 내용은 [Amazon ECS에서 컨테이너 예약](scheduling_tasks.md) 섹션을 참조하세요.

**참고**  
작업 배치 전략은 최선의 노력입니다. Amazon ECS는 가장 최적의 배치 옵션을 사용할 수 없을 경우에도 작업 배치를 계속 시도합니다. 하지만 작업 배치 제약이 적용되므로 작업 배치를 막을 수 있습니다.

작업 배치 전략과 제약을 함께 사용할 수 있습니다. 예를 들어 작업 배치 전략과 작업 배치 제약을 사용하여 가용 영역과 각 가용 영역 내의 메모리를 기반으로 하는 휴지통 팩 작업에 태스크를 분산할 수 있으나, 이는 G2 인스턴스에만 해당됩니다.

Amazon ECS는 태스크를 배치할 때 다음 프로세스를 사용하여 컨테이너 인스턴스를 선택합니다.

1. 작업 정의의 CPU, GPU, 메모리, 포트 요구 사항을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 작업 배치 제약 조건을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 작업 배치 전략을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 작업 배치를 위해 컨테이너 인스턴스를 선택합니다.

## Fargate
<a name="fargate-launch-type"></a>

Fargate를 사용하는 태스크에 대해서는 태스크 배치 전략 및 제약이 지원되지 않습니다. Fargate는 액세스 가능한 가용 영역 전체에 작업을 분산시키기 위해 최선을 다합니다. 용량 공급자에 Fargate와 Fargate 스팟이 모두 포함되는 경우 분산 동작은 용량 공급자마다 독립적입니다.

# Amazon ECS 관리형 인스턴스 오토 스케일링 및 태스크 배치
<a name="managed-instance-auto-scaling"></a>

Amazon ECS 관리형 인스턴스는 지능형 알고리즘을 사용하여 클러스터 용량을 자동으로 조정하고 인프라 전체에서 태스크를 효율적으로 배치합니다. 이러한 알고리즘의 작동 방식을 이해하면 서비스 구성을 최적화하고 배치 동작 문제를 해결하는 데 도움이 됩니다.

## 태스크 배치 알고리즘
<a name="managed-instance-task-placement-algorithm"></a>

Amazon ECS 관리형 인스턴스는 태스크 예약 시 가용성, 리소스 사용률 및 네트워크 요구 사항의 균형을 맞추는 정교한 배치 알고리즘을 사용합니다.

### 가용 영역 분산
<a name="managed-instance-az-spread-behavior"></a>

기본적으로 Amazon ECS 관리형 인스턴스는 여러 가용 영역에 작업을 분산하여 가용성을 우선합니다.
+ 여러 태스크가 있는 서비스의 경우 Amazon ECS 관리형 인스턴스는 가능한 경우 서로 다른 가용 영역에 있는 최소 3개의 인스턴스에 분산되도록 합니다.
+ 이 동작은 내결함성을 제공하지만 인스턴스당 리소스 사용률이 낮아질 수 있습니다.
+ 가용 영역 분산이 빈 패킹 최적화보다 우선합니다.

### 빈 패킹 동작
<a name="managed-instance-bin-packing"></a>

Amazon ECS 관리형 인스턴스는 빈 패킹을 수행하여 리소스 사용률을 극대화할 수 있지만 이 동작은 네트워크 구성의 영향을 받습니다.
+ 빈 패킹을 수행하려면 단일 서브넷을 사용하도록 서비스를 구성합니다.
+ 다중 서브넷 구성은 리소스 밀도보다 가용 영역 분산을 우선합니다.
+ 빈 패킹은 조정 이벤트보다 초기 서비스 시작 중에 발생할 가능성이 더 큽니다.

### ENI 밀도 고려 사항
<a name="managed-instance-eni-density"></a>

`awsvpc` 네트워크 모드를 사용하는 서비스의 경우 Amazon ECS 관리형 인스턴스는 배치 결정을 내릴 때 탄력적 네트워크 인터페이스(ENI) 밀도를 고려합니다.
+ `awsvpc` 모드의 각 태스크에는 전용 ENI가 필요합니다.
+ 인스턴스 유형에는 태스크 밀도에 영향을 미치는 다양한 ENI 제한이 있습니다.
+ Amazon ECS 관리형 인스턴스는 대상 인스턴스를 선택할 때 ENI 가용성을 고려합니다.

**참고**  
배치 결정을 최적화하기 위해 ENI 밀도 계산은 지속적으로 개선됩니다.

## 용량 공급자 결정 로직
<a name="managed-instance-capacity-provider-decisions"></a>

Amazon ECS 관리형 인스턴스 용량 공급자는 여러 요인에 따라 조정 및 배치 결정을 내립니다.

리소스 요구 사항  
보류 중인 태스크의 CPU, 메모리 및 네트워크 요구 사항

인스턴스 가용성  
기존 인스턴스에서 현재 용량 및 사용률

네트워킹 제약 조건  
서브넷 구성 및 ENI 가용성

가용 영역 배포  
여러 가용 영역에서 내결함성 유지 관리

## 구성 옵션
<a name="managed-instance-configuration-options"></a>

### 서브넷 선택 전략
<a name="managed-instance-subnet-strategy"></a>

서브넷 구성은 태스크 배치 동작에 상당한 영향을 미칩니다.

다중 서브넷(기본값)  
고가용성을 위해 가용 영역 분산 우선순위 지정  
인스턴스당 리소스 사용률이 낮아질 수 있음  
내결함성이 필요한 프로덕션 워크로드에 권장됨

단일 서브넷  
리소스 사용률을 높이기 위해 빈 패킹 활성화  
하나의 가용 영역에 태스크를 집중시켜 내결함성 감소  
개발 또는 비용 최적화 워크로드에 적합

### 네트워크 모드 고려 사항
<a name="managed-instance-network-mode-considerations"></a>

선택한 네트워크 모드는 배치 결정에 영향을 미칩니다.
+ `awsvpc` 모드 - 각 태스크에는 인스턴스당 태스크 밀도를 제한하는 전용 ENI가 필요합니다.
+ `host` 모드 - 태스크에서는 호스트의 네트워크를 직접 사용하며, 배치는 주로 리소스 가용성에 따라 결정됩니다.

### CPU 아키텍처 고려 사항
<a name="managed-instance-cpu-architecture-considerations"></a>

태스크 정의에서 지정하는 `cpuArchitecture`는 특정 아키텍처에 작업을 배치하는 데 사용됩니다. `cpuArchitecture`를 지정하지 않으면 Amazon ECS는 용량 공급자 구성을 기반으로 사용 가능한 CPU 아키텍처에 태스크를 배치하려고 시도합니다. `X86_64` 또는 `ARM64`를 지정할 수 있습니다.

## 태스크 배치 문제 해결
<a name="managed-instance-troubleshooting-placement"></a>

### 일반적인 배치 패턴
<a name="managed-instance-common-placement-patterns"></a>

예상 배치 패턴을 이해하면 정상적인 동작을 잠재적 문제와 구별하는 데 도움이 됩니다.

분산 배포  
부분 사용률로 여러 인스턴스에 분산된 태스크  
다중 서브넷 사용 시 정상 동작  
리소스 효율성보다 가용성을 우선함을 표시함

집중 배치  
사용률이 더 높고 더 적은 인스턴스에 배치된 여러 태스크  
단일 서브넷 구성을 사용할 때 예상됨  
초기 서비스 시작 중에 발생할 수 있음

고르지 않은 분포  
일부 인스턴스는 활용도가 높고 다른 인스턴스는 활용도가 낮음  
ENI 제한 또는 리소스 제약 조건을 나타낼 수 있음  
인스턴스 유형 및 네트워크 구성 검토 고려

### 배치 동작 최적화
<a name="managed-instance-placement-optimization"></a>

특정 요구 사항에 맞게 태스크 배치를 최적화하는 방법:

1. 가용성 요구 사항과 비용 최적화 요구 사항 평가

1. 우선순위에 따라 적절한 서브넷 구성 선택

1. 네트워크 모드에 적합한 ENI 용량의 인스턴스 유형 선택

1. 배치 패턴 모니터링 및 필요에 따라 구성 조정

## 모범 사례
<a name="managed-instance-best-practices"></a>
+ **프로덕션 워크로드의 경우** - 여러 가용 영역에 걸쳐 여러 서브넷을 사용하여 고가용성을 보장하고 리소스 사용률의 절충 허용
+ **개발 또는 테스트의 경우** - 리소스 사용률을 극대화하고 비용을 절감하려면 단일 서브넷 구 고려
+ **`awsvpc` 모드의 경우** - 배치 제약 조건을 피하기 위해 충분한 ENI 용량이 있는 인스턴스 유형 선택
+ **비용 최적화** - 사용률 패턴을 모니터링하고 서비스 구성을 조정하여 가용성과 효율성의 균형 조정
+ **문제 해결** - 예상치 못한 배치 패턴을 조사할 때 서브넷 구성 및 네트워크 모드 검토

# 전략을 사용하여 Amazon ECS 작업 배치 정의
<a name="task-placement-strategies"></a>

EC2 시작 유형을 사용하는 작업의 경우 Amazon ECS는 CPU와 메모리 등 작업 정의에 지정된 요구 사항에 따라 작업 배치 위치를 결정해야 합니다. 마찬가지로 작업 수를 축소하는 경우, Amazon ECS는 어떤 태스크를 종료할지 결정해야 합니다. 작업 배치 전략과 제약을 적용하여 Amazon ECS가 태스크를 배치하고 종료하는 방법을 사용자 지정할 수 있습니다.

기본 작업 배치 전략은 작업을 수동으로 실행하는지 아니면 서비스 내에서 실행하는지에 따라 달라집니다. Amazon ECS 서비스의 일부로 실행되는 작업의 경우 기본 작업 배치 전략은 `attribute:ecs.availability-zone`을 사용하는 `spread`입니다. 서비스 중이 아닌 태스크에는 기본 태스크 배치 제약이 없습니다. 자세한 내용은 [Amazon ECS에서 컨테이너 예약](scheduling_tasks.md) 섹션을 참조하세요.

**참고**  
작업 배치 전략은 최선의 노력입니다. Amazon ECS는 가장 최적의 배치 옵션을 사용할 수 없을 경우에도 작업 배치를 계속 시도합니다. 하지만 작업 배치 제약이 적용되므로 작업 배치를 막을 수 있습니다.

작업 배치 전략과 제약을 함께 사용할 수 있습니다. 예를 들어 작업 배치 전략과 작업 배치 제약을 사용하여 가용 영역과 각 가용 영역 내의 메모리를 기반으로 하는 휴지통 팩 작업에 태스크를 분산할 수 있으나, 이는 G2 인스턴스에만 해당됩니다.

Amazon ECS는 태스크를 배치할 때 다음 프로세스를 사용하여 컨테이너 인스턴스를 선택합니다.

1. 작업 정의의 CPU, GPU, 메모리, 포트 요구 사항을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 작업 배치 제약 조건을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 작업 배치 전략을 충족하는 컨테이너 인스턴스를 식별합니다.

1. 작업 배치를 위해 컨테이너 인스턴스를 선택합니다.

서비스 정의에서 작업 배치 전략을 지정하거나 `placementStrategy` 파라미터를 사용하여 작업 정의에서 지정합니다.

```
"placementStrategy": [
    {
        "field": "The field to apply the placement strategy against",
        "type": "The placement strategy to use"
    }
]
```

작업을 실행할 때([RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)), 새 서비스를 생성할 때([CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)), 또는 기존 서비스를 업데이트할 때([UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)) 전략을 지정할 수 있습니다.

다음 테이블에서는 사용 가능한 유형 및 필드를 설명합니다.


| type | 유효한 필드 값 | 
| --- | --- | 
| binpack 태스크는 사용되지 않는 CPU 또는 메모리를 최소한으로 남겨둘 수 있도록 컨테이너 인스턴스에 배치됩니다. 이 전략은 사용 중인 컨테이너 인스턴스의 수를 최소화합니다. 이 전략을 사용하고 축소 작업을 수행하면 Amazon ECS가 태스크를 종료합니다. 이는 태스크가 종료된 후 컨테이너 인스턴스에 남아 있는 리소스의 양을 기준으로 합니다. 태스크 종료 후 사용 가능한 리소스가 가장 많이 남은 컨테이너 인스턴스가 해당 태스크를 종료합니다. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 
| random 태스크가 무작위로 배치됩니다. | 사용되지 않습니다 | 
| spread태스크가 지정된 값에 따라 균등하게 배치됩니다. 서비스 태스크는 해당 서비스의 태스크를 기준으로 분산됩니다. 독립 실행형 태스크는 동일한 작업 그룹의 태스크를 기준으로 분산됩니다. 작업 그룹에 대한 자세한 정보는 [그룹 관련 Amazon ECS 작업](task-groups.md) 섹션을 참조하세요.`spread` 전략이 사용되고 축소 작업이 수행되면 Amazon ECS가 가용 영역 간에 균형을 유지하도록 종료할 태스크를 선택합니다. 가용 영역 내에서 태스크가 무작위로 선택됩니다. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 

기존 서비스에 대해서도 작업 배치 전략을 업데이트할 수 있습니다. 자세한 내용은 [Amazon ECS가 컨테이너 인스턴스에 작업을 배치하는 방법](task-placement.md) 섹션을 참조하세요.

전략을 수행할 순서대로 전략 배열을 생성하여 여러 전략을 사용하는 작업 배치 전략을 생성할 수 있습니다. 예를 들어 가용 영역에 작업을 분산한 다음 각 가용 영역 내의 메모리를 기반으로 하는 작업을 빈팩하려면 가용 영역 전략과 메모리 전략을 차례로 지정합니다. 예제 전략은 [Amazon ECS 작업 배치 전략 예제](strategy-examples.md)를 참조하세요.

# Amazon ECS 작업 배치 전략 예제
<a name="strategy-examples"></a>

[CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) 및 [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html) 태스크를 사용하면 작업 배치 전략을 지정할 수 있습니다.

**Topics**
+ [가용 영역에 균등하게 작업 분산](#even-az)
+ [모든 인스턴스에 균등하게 작업 분산](#even-instance)
+ [메모리를 기반으로 작업 빈팩](#binpack)
+ [무작위로 작업 배치](#random)
+ [가용 영역에 균등하게 작업을 분산한 다음 각 가용 영역 내에서 인스턴스에 균등하게 작업 분산](#az-instance)
+ [가용 영역에 균등하게 작업을 분산한 다음 각 가용 영역 내의 메모리를 기준으로 작업 빈팩](#az-memory)
+ [인스턴스에 균등하게 작업을 분산한 다음 메모리를 기반으로 작업 빈팩](#instance-memory)

## 가용 영역에 균등하게 작업 분산
<a name="even-az"></a>

다음 전략은 가용 영역에 균등하게 태스크를 분산합니다.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    }
]
```

## 모든 인스턴스에 균등하게 작업 분산
<a name="even-instance"></a>

다음 전략은 모든 인스턴스에 균등하게 태스크를 분산합니다.

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## 메모리를 기반으로 작업 빈팩
<a name="binpack"></a>

다음 전략은 메모리를 기준으로 태스크를 bin-pack합니다.

```
"placementStrategy": [
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## 무작위로 작업 배치
<a name="random"></a>

다음 전략은 태스크를 무작위로 배치합니다.

```
"placementStrategy": [
    {
        "type": "random"
    }
]
```

## 가용 영역에 균등하게 작업을 분산한 다음 각 가용 영역 내에서 인스턴스에 균등하게 작업 분산
<a name="az-instance"></a>

다음 전략은 가용 영역에 균등하게 태스크를 분산한 다음 각 가용 영역 내에서 인스턴스에 균등하게 태스크를 분산합니다.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## 가용 영역에 균등하게 작업을 분산한 다음 각 가용 영역 내의 메모리를 기준으로 작업 빈팩
<a name="az-memory"></a>

다음 전략은 가용 영역에 균등하게 태스크를 분산한 다음 각 가용 영역 내에서 메모리를 기준으로 태스크를 bin-pack합니다.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## 인스턴스에 균등하게 작업을 분산한 다음 메모리를 기반으로 작업 빈팩
<a name="instance-memory"></a>

다음 전략에서는 모든 인스턴스에 균등하게 작업을 분산한 다음 각 인스턴스 내의 메모리를 기반으로 작업을 빈팩합니다.

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

# 그룹 관련 Amazon ECS 작업
<a name="task-groups"></a>

관련된 작업 세트를 식별하고 작업 그룹에 배치할 수 있습니다. 태스크 그룹 이름이 같은 모든 태스크는 `spread` 작업 배치 전략을 사용할 때 하나의 집합으로 간주됩니다. 예를 들어 데이터베이스와 웹 서버 등 하나의 클러스터에서 상이한 애플리케이션을 실행한다고 가정해 봅시다. 가용 영역에서 데이터베이스들이 균형을 이루도록 하려면 `databases`라는 이름의 태스크 그룹에 추가한 다음 `spread` 작업 배치 전략을 사용합니다. 자세한 정보는 [전략을 사용하여 Amazon ECS 작업 배치 정의](task-placement-strategies.md)을 참조하세요.

태스크 그룹을 작업 배치 제약 조건으로 사용할 수도 있습니다. `memberOf` 제약 조건에 작업 그룹을 지정하면 작업은 지정된 작업 그룹에 실행되는 컨테이너 인스턴스로만 전송됩니다. 예시는 [Amazon ECS 작업 배치 제약 조건 예제](constraint-examples.md) 섹션을 참조하세요.

기본적으로 독립 실행형 태스크에서는 사용자 정의 태스크 그룹 이름이 지정되지 않은 경우 태스크 정의 패밀리 이름을 태스크 그룹 이름으로 사용합니다(예: `family:my-task-definition`). 서비스의 일부로 시작된 태스크는 서비스 이름을 작업 그룹 이름으로 사용하며 변경할 수 없습니다.

작업 그룹에 대해 다음 요구 사항이 적용됩니다.
+ 태스크 그룹 이름은 255자 이하여야 합니다.
+ 각 태스크는 정확히 하나의 그룹에 속할 수 있습니다.
+ 태스크를 시작한 후에는 해당 태스크 그룹을 수정할 수 없습니다.

# Amazon ECS가 작업에 사용하는 컨테이너 인스턴스 정의
<a name="task-placement-constraints"></a>

작업 배치 제약 조건은 Amazon ECS가 해당 인스턴스에서 작업을 실행할 수 있는지 여부를 결정하는 데 사용하는 컨테이너 인스턴스에 대한 규칙입니다. 하나 이상의 컨테이너 인스턴스가 제약과 일치해야 합니다. 제약과 일치하는 인스턴스가 없는 경우 작업은 `PENDING` 상태로 유지됩니다. 새 서비스를 생성하거나 기존 서비스를 업데이트할 때 서비스 작업에 대한 작업 배치 제약을 지정할 수 있습니다.

`placementConstraint` 파라미터를 사용하여 서비스 정의, 작업 정의 또는 작업에서 작업 배치 제약 조건을 지정할 수 있습니다.

```
"placementConstraints": [
    {
        "expression": "The expression that defines the task placement constraints",
        "type": "The placement constraint type to use"
    }
]
```

다음 테이블에서는 파라미터를 사용하는 방법을 설명합니다.


| 제약 유형 | 지정 가능한 경우 | 
| --- | --- | 
| distinctInstance각 활성 태스크를 서로 다른 컨테이너 인스턴스에 배치합니다.Amazon ECS는 작업 배치를 위해 원하는 작업 상태를 확인합니다. 예를 들어 기존 작업의 원하는 상태가 `STOPPED`인 경우(하지만 마지막 상태는 그렇지 않음), `distinctInstance` 배치 제약에도 불구하고 새로 들어오는 작업을 동일한 인스턴스에 배치할 수 있습니다. 따라서 동일한 인스턴스에 마지막 `RUNNING` 상태인 작업 2개가 표시될 수 있습니다. 엄격한 작업 격리를 원하는 고객은 Fargate를 사용하는 것이 좋습니다. Fargate는 하드웨어 가상화 환경에서 각 작업을 실행합니다. 이러한 컨테이너화된 워크로드는 네트워크 인터페이스, Fargate 임시 스토리지, CPU 또는 메모리를 다른 작업과 공유하지 않습니다. 자세한 내용은 [Security Overview of AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf)를 참조하세요. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/task-placement-constraints.html)  | 
| memberOf표현식을 충족하는 컨테이너 인스턴스에 태스크를 배치. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/task-placement-constraints.html) | 

`memberOf` 제약 조건 유형을 사용하는 경우 Amazon ECS가 작업을 배치할 수 있는 컨테이너 인스턴스를 정의하는 클러스터 쿼리 언어를 사용하여 표현식을 생성할 수 있습니다. 표현식은 속성별로 컨테이너 인스턴스를 그룹화하는 방법입니다. 표현식은 `placementConstraint`의 `expression ` 파라미터에 포함됩니다.

## Amazon ECS 컨테이너 인스턴스 속성
<a name="attributes"></a>

*속성*이라고 하는 사용자 지정 메타데이터를 컨테이너 인스턴스에 추가할 수 있습니다. 각 속성에는 이름과 선택 사항인 문자열 값이 있습니다. Amazon ECS가 제공하는 기본 속성을 사용하거나 사용자 지정 속성을 정의할 수 있습니다.

다음 섹션에는 샘플 기본 제공, 선택적 및 사용자 정의 속성이 있습니다.

### 기본 속성
<a name="ecs-automatic-attributes"></a>

Amazon ECS는 자동으로 다음 속성을 컨테이너 인스턴스에 적용합니다.

`ecs.ami-id`  
인스턴스를 시작하는 데 사용된 AMI의 ID. 이 속성의 예시 값은 `ami-1234abcd`입니다.

`ecs.availability-zone`  
인스턴스의 가용 영역. 이 속성의 예시 값은 `us-east-1a`입니다.

`ecs.instance-type`  
인스턴스의 인스턴스 유형. 이 속성의 예시 값은 `g2.2xlarge`입니다.

`ecs.os-type`  
인스턴스의 운영 체제. 이 속성에 사용 가능한 값은 `linux` 및 `windows`입니다.

`ecs.os-family`  
인스턴스의 운영 체제 버전입니다.  
Linux 인스턴스의 경우 유효한 값은 `LINUX`입니다. Windows 인스턴스의 경우 ECS는 값을 `WINDOWS_SERVER_<OS_Release>_<FULL or CORE>` 형식으로 설정합니다. 유효한 값은 `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_20H2_CORE`, `WINDOWS_SERVER_2019_FULL`, `WINDOWS_SERVER_2019_CORE` 및 `WINDOWS_SERVER_2016_FULL`입니다.  
이는 Windows 컨테이너 및 Windows containers on AWS Fargate에서 중요한데, 모든 Windows 컨테이너의 OS 버전이 호스트의 OS 버전과 일치해야 하기 때문입니다. 컨테이너 이미지의 Windows 버전이 호스트와 다르면 컨테이너가 시작되지 않습니다. 자세한 내용은 Microsoft 설명서 웹 사이트의 [Windows 컨테이너 버전 호환성](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11)을 참조하세요.  
클러스터에서 여러 Windows 버전을 실행하는 경우 배치 제약 조건 `memberOf(attribute:ecs.os-family == WINDOWS_SERVER_<OS_Release>_<FULL or CORE>)`를 사용하여 동일한 버전에서 실행되는 EC2 인스턴스에 작업이 배치되도록 할 수 있습니다. 자세한 내용은 [Amazon ECS 최적화 Windows AMI 메타데이터 검색](retrieve-ecs-optimized_windows_AMI.md) 섹션을 참조하세요.

`ecs.cpu-architecture`  
인스턴스의 CPU 아키텍처입니다. 이 속성의 예시 값은 `x86_64`와 `arm64`입니다.

`ecs.vpc-id`  
인스턴스가 시작된 VPC입니다. 이 속성의 예시 값은 `vpc-1234abcd`입니다.

`ecs.subnet-id`  
인스턴스가 사용 중인 서브넷입니다. 이 속성의 예시 값은 `subnet-1234abcd`입니다.

**참고**  
Amazon ECS 관리형 인스턴스는 다음과 같은 속성 하위 세트를 지원합니다.  
`ecs.subnet-id`
`ecs.availability-zone`
`ecs.instance-type`
`ecs.cpu-architecture`

### 선택적 속성
<a name="ecs-optional-attributes"></a>

Amazon ECS는 컨테이너 인스턴스에 다음 속성을 추가할 수 있습니다.

`ecs.awsvpc-trunk-id`  
이 속성이 있으면 인스턴스에 트렁크 네트워크 인터페이스가 있습니다. 자세한 내용은 [Amazon ECS Linux 컨테이너 인스턴스 네트워크 인터페이스 증가](container-instance-eni.md) 섹션을 참조하세요.

`ecs.outpost-arn`  
이 속성이 있으면 Outpost의 Amazon 리소스 이름(ARN)이 포함됩니다. 자세한 내용은 [AWS Outposts의 Amazon Elastic Container Service](using-outposts.md) 섹션을 참조하세요.

`ecs.capability.external`  
이 속성이 있으면 인스턴스가 외부 인스턴스로 식별됩니다. 자세한 내용은 [외부 인스턴스에 대한 Amazon ECS 클러스터](ecs-anywhere.md) 섹션을 참조하세요.

### 사용자 지정 속성
<a name="ecs-custom-attributes"></a>

컨테이너 인스턴스에 사용자 지정 속성을 적용할 수 있습니다. 예를 들어 이름이 "stack"이고 값이 "prod"인 속성을 정의할 수 있습니다.

사용자 정의 속성을 지정할 때 다음 사항을 고려해야 합니다.
+ `name`은 1\$1128자의 문자를 포함해야 하며 이름에는 문자(대문자 및 소문자), 숫자, 하이픈, 밑줄, 슬래시, 백슬래시 또는 마침표가 포함될 수 있습니다.
+ `value`은 1\$1128자의 문자를 포함해야 하며 이름에는 문자(대문자 및 소문자), 숫자, 하이픈, 밑줄, 마침표, @ 기호, 슬래시, 백슬래시, 콜론 또는 공백이 포함될 수 있습니다. 값은 선행 또는 후행 공백을 포함할 수 없습니다.

# Amazon ECS 작업에 대한 컨테이너 인스턴스를 정의하도록 표현식 생성
<a name="cluster-query-language"></a>

클러스터 쿼리는 객체를 그룹화할 수 있게 해 주는 표현식입니다. 예를 들어 가용 영역, 인스턴스 유형 또는 사용자 지정 메타데이터 같은 속성을 기준으로 컨테이너 인스턴스를 그룹화할 수 있습니다. 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 속성](task-placement-constraints.md#attributes) 섹션을 참조하세요.

컨테이너 인스턴스 그룹을 정의한 후 그룹을 기준으로 태스크를 컨테이너 인스턴스에 배치하도록 Amazon ECS를 사용자 지정할 수 있습니다. 자세한 정보는 [애플리케이션을 Amazon ECS 태스크로 실행](standalone-task-create.md) 및 [Amazon ECS 롤링 업데이트 배포 생성](create-service-console-v2.md) 섹션을 참조하세요. 컨테이너 인스턴스를 나열할 때 그룹 필터를 적용할 수도 있습니다.

## 표현식 구문
<a name="expression-syntax"></a>

표현식에는 다음과 같은 구문이 있습니다.

```
subject operator [argument]
```

**제목**  
평가할 속성 또는 필드.

`agentConnected`  
Amazon ECS 컨테이너 에이전트 연결 상태를 기준으로 컨테이너 인스턴스를 선택합니다. 이 필터를 사용하여 분리된 컨테이너 에이전트가 있는 인스턴스를 검색할 수 있습니다.  
유효 연산자: equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`agentVersion`  
Amazon ECS 컨테이너 에이전트 버전을 기준으로 컨테이너 인스턴스를 선택합니다. 이 필터를 사용하여 오래된 Amazon ECS 컨테이너 에이전트 버전을 실행하는 인스턴트를 검색할 수 있습니다.  
유효 연산자: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`attribute:attribute-name`  
속성을 기준으로 컨테이너 인스턴스를 선택합니다. 자세한 내용은 [Amazon ECS 컨테이너 인스턴스 속성](task-placement-constraints.md#attributes) 섹션을 참조하세요.

`ec2InstanceId`  
Amazon EC2 인스턴스 ID로 컨테이너 인스턴스를 선택합니다.  
유효 연산자: equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`registeredAt`  
컨테이너 인스턴스 등록일을 기준으로 컨테이너 인스턴스를 선택합니다. 이 필터를 사용하여 새로 등록된 인스턴스 또는 매우 오래된 인스턴스를 검색할 수 있습니다.  
유효 연산자: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)  
유효한 날짜 형식: 2018-06-18T22:28:28\$100:00, 2018-06-18T22:28:28Z, 2018-06-18T22:28:28, 2018-06-18

`runningTasksCount`  
실행 중인 작업 수를 기준으로 컨테이너 인스턴스를 선택합니다. 이 필터를 사용하여 비었거나 거의 비어 있는(실행 중인 작업이 거의 없는) 인스턴스를 검색할 수 있습니다.  
유효 연산자: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`task:group`  
작업 그룹을 기준으로 컨테이너 인스턴스를 선택합니다. 자세한 정보는 [그룹 관련 Amazon ECS 작업](task-groups.md)을 참조하세요.

**연산자**  
비교 연산자. 다음의 연산자가 지원됩니다.


|  연산자  |  설명  | 
| --- | --- | 
|  ==, equals  |  문자열 같음  | 
|  \$1=, not\$1equals  |  문자열 다름  | 
|  >, greater\$1than  |  초과  | 
|  >=, greater\$1than\$1equal  |  크거나 같음  | 
|  <, less\$1than  |  미만  | 
|  <=, less\$1than\$1equal  |  작거나 같음  | 
|  exists  |  주체 있음  | 
|  \$1exists, not\$1exists  |  주체 없음  | 
|  in  |  인수 목록에 있는 값  | 
|  \$1in, not\$1in  |  인수 목록에 없는 값  | 
|  =\$1, matches  |  패턴 일치  | 
|  \$1\$1, not\$1matches  |  패턴 불일치  | 

**참고**  
단일 표현식은 괄호를 포함할 수 없습니다. 하지만 복합 표현식에서는 우선순위를 지정하기 위해 괄호를 사용할 수 있습니다.

**인수**  
많은 연산자에서 인수는 리터럴 값입니다.

`in` 및 `not_in` 연산자에는 인수로 인수 목록이 필요합니다. 다음과 같이 인수를 지정합니다.

```
[argument1, argument2, ..., argumentN]
```

matches 및 not\$1matches 연산자에는 Java 정규식 구문을 준수하는 인수가 필요합니다. 자세한 내용은 [java.util.regex.Pattern](http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html)을 참조하세요.

**복합 표현식**

다음 부울 연산자를 사용하여 표현식을 결합할 수 있습니다.
+ &&, 및
+ \$1\$1, 또는
+ \$1, not

괄호를 사용하여 우선순위를 지정할 수 있습니다.

```
(expression1 or expression2) and expression3
```

## 예제 표현식
<a name="expression-examples"></a>

다음은 예제 표현식입니다.

**예제: 문자열 같음**  
다음 표현식은 지정된 인스턴스 유형을 가진 인스턴스를 선택합니다.

```
attribute:ecs.instance-type == t2.small
```

**예제: 인수 목록**  
다음 표현식은 us-east-1a 또는 us-east-1b 가용 영역 내 인스턴스를 선택합니다.

```
attribute:ecs.availability-zone in [us-east-1a, us-east-1b]
```

**예제: 복합 표현식**  
다음 표현식은 us-east-1d 가용 영역에 없는 G2 인스턴스를 선택합니다.

```
attribute:ecs.instance-type =~ g2.* and attribute:ecs.availability-zone != us-east-1d
```

**예제: 태스크 선호도**  
다음 표현식은 `service:production` 그룹에서 태스크를 호스팅하고 있는 인스턴스를 선택합니다.

```
task:group == service:production
```

**예제: 태스크 비선호도**  
다음 표현식은 database 그룹에서 태스크를 호스팅하고 있지 않은 인스턴스를 선택합니다.

```
not(task:group == database)
```

**예: 실행 중인 태스크 개수**  
다음 표현식은 작업 한 개만 실행 중인 인스턴스를 선택합니다.

```
runningTasksCount == 1
```

**예제: Amazon ECS 컨테이너 에이전트 버전**  
다음 표현식은 실행 중인 컨테이너 에이전트 버전이 1.14.5인 인스턴스를 선택합니다.

```
agentVersion < 1.14.5
```

**예: 인스턴스 등록 시간**  
다음 표현식은 2018년 2월 13일 이전에 등록된 인스턴스를 선택합니다.

```
registeredAt < 2018-02-13
```

**예제: Amazon EC2 인스턴스 ID**  
다음 표현식은 다음 Amazon EC2 인스턴스 ID를 갖는 인스턴스를 선택합니다.

```
ec2InstanceId in ['i-abcd1234', 'i-wxyx7890']
```

# Amazon ECS 작업 배치 제약 조건 예제
<a name="constraint-examples"></a>

다음은 작업 배치 제약 예제입니다.

이 예제에서는 `memberOf` 제약 조건을 사용하여 t2 인스턴스에 작업을 배치합니다. 다음 작업 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html) 및 [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)로 지정할 수 있습니다.

```
"placementConstraints": [
    {
        "expression": "attribute:ecs.instance-type =~ t2.*",
        "type": "memberOf"
    }
]
```

이 예제에서는 `memberOf` 제약을 사용하여 대몬(daemon) 서비스 `daemon-service` 작업 그룹의 다른 작업과 함께 인스턴스에 복제본 작업을 배치하고, 함께 지정된 모든 작업 배치 전략도 적용합니다. 이 제약으로 인해 대몬(daemon) 서비스 작업이 복제 서비스 작업보다 먼저 EC2 인스턴스에 배치됩니다.

`daemon-service`를 대몬(daemon) 서비스 이름으로 바꿉니다.

```
"placementConstraints": [
    {
        "expression": "task:group == service:daemon-service",
        "type": "memberOf"
    }
]
```

이 예제에서는 `memberOf` 제약을 사용하여 지정된 모든 작업 배치 전략을 적용한 `databases` 작업 그룹의 다른 태스크와 함께 인스턴스에 태스크를 배치합니다. 작업 그룹에 대한 자세한 내용은 [그룹 관련 Amazon ECS 작업](task-groups.md) 섹션을 참조하세요. 다음 작업 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html) 및 [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)로 지정할 수 있습니다.

```
"placementConstraints": [
    {
        "expression": "task:group == databases",
        "type": "memberOf"
    }
]
```

`distinctInstance` 제약은 그룹의 각 태스크를 서로 다른 인스턴스에 배치합니다. 다음 작업 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) 및 [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)로 지정할 수 있습니다.

Amazon ECS는 작업 배치를 위해 원하는 작업 상태를 확인합니다. 예를 들어 기존 작업의 원하는 상태가 `STOPPED`인 경우(하지만 마지막 상태는 그렇지 않음), `distinctInstance` 배치 제약에도 불구하고 새로 들어오는 작업을 동일한 인스턴스에 배치할 수 있습니다. 따라서 동일한 인스턴스에 마지막 `RUNNING` 상태인 작업 2개가 표시될 수 있습니다.

```
"placementConstraints": [
    {
        "type": "distinctInstance"
    }
]
```