Amazon ECS 서비스 배포 컨트롤러와 전략

서비스를 배포하기 전에 배포 옵션과 서비스가 사용하는 기능을 결정해야 해요. 스케줄링 전략과 배포 컨트롤러의 종류를 이해하는 것이 중요해요.

출처: 문서

본문

서비스를 배포하기 전에 배포 옵션과 서비스가 사용하는 기능을 결정하세요.

스케줄링 전략(Scheduling strategy)

사용할 수 있는 두 가지 서비스 스케줄러 전략이 있습니다.

REPLICA – 복제본 스케줄링 전략은 클러스터 전체에 원하는 수의 작업을 배치하고 유지합니다. 기본적으로 서비스 스케줄러는 작업을 가용 영역 전체에 분산합니다. 작업 배치 전략과 제약 조건을 사용해 작업 배치 결정을 사용자 지정할 수 있습니다. 자세한 내용은 Replica scheduling strategy를 참고하세요.
DAEMON – 데몬 스케줄링 전략은 클러스터에서 지정한 모든 작업 배치 제약 조건을 충족하는 각 활성 컨테이너 인스턴스에 정확히 하나의 작업을 배포합니다. 이 전략을 사용할 때는 원하는 작업 수, 작업 배치 전략을 지정하거나 Service Auto Scaling 정책을 사용할 필요가 없습니다. 자세한 내용은 Daemon scheduling strategy를 참고하세요.
- 참고: Fargate 작업은 DAEMON 스케줄링 전략을 지원하지 않습니다.

복제본 스케줄링 전략(Replica scheduling strategy)

복제본 스케줄링 전략은 클러스터에서 원하는 수의 작업을 배치하고 유지합니다.

Fargate에서 작업을 실행하는 서비스의 경우 서비스 스케줄러가 새 작업을 시작하거나 실행 중인 작업을 중지할 때 가용 영역 전체에 균형을 유지하기 위해 최선을 다합니다. 작업 배치 전략이나 제약 조건을 지정할 필요가 없습니다.

EC2 인스턴스에서 작업을 실행하는 서비스를 만들 때 선택적으로 작업 배치 전략과 제약 조건을 지정해 작업 배치 결정을 사용자 지정할 수 있습니다. 작업 배치 전략이나 제약 조건이 지정되지 않으면 기본적으로 서비스 스케줄러가 가용 영역 전체에 작업을 분산합니다. 서비스 스케줄러는 다음 논리를 사용합니다.

클러스터의 어떤 컨테이너 인스턴스가 서비스의 작업 정의를 지원할 수 있는지 결정합니다(예: 필요한 CPU, 메모리, 포트, 컨테이너 인스턴스 속성).
어떤 컨테이너 인스턴스가 서비스에 대해 정의된 배치 제약 조건을 충족하는지 결정합니다.
- 데몬 서비스에 의존하는 복제본 서비스가 있을 때(예: 작업이 로깅을 사용하기 전에 실행되어야 하는 데몬 로그 라우터 작업), 데몬 서비스 작업이 복제본 서비스 작업보다 EC2 인스턴스에 먼저 배치되도록 보장하는 작업 배치 제약 조건을 만드세요. 자세한 내용은 Example Amazon ECS task placement constraints를 참고하세요.
정의된 배치 전략이 있으면 그 전략을 사용해 남은 후보에서 인스턴스를 선택합니다.
정의된 배치 전략이 없으면 다음 논리를 사용해 클러스터의 가용 영역 전체에서 작업 균형을 유지합니다.
- 유효한 컨테이너 인스턴스를 정렬합니다. 각각의 가용 영역에서 이 서비스에 대해 실행 중인 작업 수가 가장 적은 인스턴스에 우선순위를 둡니다. 예를 들어 영역 A에 실행 중인 서비스 작업이 하나 있고 영역 B와 C에는 각각 0개라면 영역 B 또는 C의 유효한 컨테이너 인스턴스가 배치에 최적으로 간주됩니다.
- 이전 단계를 기반으로 최적의 가용 영역의 유효한 컨테이너 인스턴스에 새 서비스 작업을 배치합니다. 이 서비스에 대해 실행 중인 작업 수가 가장 적은 컨테이너 인스턴스를 선호합니다.

REPLICA 전략을 사용할 때는 서비스 리밸런싱 기능을 사용할 것을 권장합니다. 서비스의 고가용성을 보장하는 데 도움이 되기 때문입니다.

데몬 스케줄링 전략(Daemon scheduling strategy)

데몬 스케줄링 전략은 클러스터에서 지정한 모든 작업 배치 제약 조건을 충족하는 각 활성 컨테이너 인스턴스에 정확히 하나의 작업을 배포합니다. 서비스 스케줄러는 실행 중인 작업에 대해 작업 배치 제약 조건을 평가하고, 배치 제약 조건을 충족하지 않는 작업을 중지합니다. 이 전략을 사용할 때는 원하는 작업 수, 작업 배치 전략을 지정하거나 Service Auto Scaling 정책을 사용할 필요가 없습니다.

Amazon ECS는 데몬 작업을 위해 CPU, 메모리, 네트워크 인터페이스를 포함한 컨테이너 인스턴스 컴퓨팅 리소스를 예약합니다. 다른 복제본 서비스가 있는 클러스터에서 데몬 서비스를 실행할 때 Amazon ECS는 데몬 작업에 우선순위를 둡니다. 즉 데몬 작업은 인스턴스에서 가장 먼저 시작되는 작업이고, 모든 복제본 작업이 중지된 후 가장 마지막에 중지되는 작업입니다. 이 전략은 리소스가 보류 중인 복제본 작업에 사용되지 않고 데몬 작업에 사용 가능하도록 보장합니다.

데몬 서비스 스케줄러는 DRAINING 상태의 인스턴스에는 작업을 배치하지 않습니다. 컨테이너 인스턴스가 DRAINING 상태로 전환되면 그 인스턴스의 데몬 작업은 중지됩니다. 서비스 스케줄러는 또한 새 컨테이너 인스턴스가 클러스터에 추가되는 시점을 모니터링하고 그 인스턴스에 데몬 작업을 추가합니다.

배포 구성을 지정할 때 maximumPercent 매개변수 값은 100(백분율로 지정)이어야 하며, 설정하지 않으면 사용되는 기본값입니다. minimumHealthyPercent 매개변수의 기본값은 0(백분율로 지정)입니다.

데몬 서비스의 배치 제약 조건을 변경할 때는 서비스를 다시 시작해야 합니다. Amazon ECS는 적격 인스턴스에서 데몬 작업용으로 예약된 리소스를 동적으로 업데이트합니다. 기존 인스턴스의 경우 스케줄러가 인스턴스에 작업을 배치하려고 시도합니다.

작업 정의에서 작업 크기나 컨테이너 리소스 예약에 변경이 있으면 새 배포가 시작됩니다. 서비스를 업데이트하거나 작업 정의의 다른 개정판을 설정할 때도 새 배포가 시작됩니다. Amazon ECS는 데몬에 대한 업데이트된 CPU 및 메모리 예약을 가져온 다음 데몬 작업을 위해 해당 용량을 차단합니다.

위의 두 경우 모두에 대해 리소스가 부족하면 다음이 발생합니다.

작업 배치가 실패합니다.
CloudWatch 이벤트가 생성됩니다.
Amazon ECS는 리소스를 사용할 수 있을 때까지 기다리며 인스턴스에 작업을 스케줄링하려고 계속 시도합니다.
Amazon ECS는 더 이상 배치 제약 조건 기준을 충족하지 않는 예약 인스턴스를 해제하고 해당 데몬 작업을 중지합니다.

데몬 스케줄링 전략은 다음 경우에 사용할 수 있습니다.

애플리케이션 컨테이너 실행
로깅, 모니터링, 추적 작업용 지원 컨테이너 실행

Fargate 또는 CODE_DEPLOY 또는 EXTERNAL 배포 컨트롤러 유형을 사용하는 작업은 데몬 스케줄링 전략을 지원하지 않습니다.

서비스 스케줄러가 실행 중인 작업을 중지할 때 클러스터의 가용 영역 전체에서 균형을 유지하려고 시도합니다. 스케줄러는 다음 논리를 사용합니다.

배치 전략이 정의되어 있으면 그 전략을 사용해 종료할 작업을 선택합니다. 예를 들어 서비스에 가용 영역 분산 전략이 정의되어 있으면 나머지 작업이 가장 잘 분산되도록 하는 작업이 선택됩니다.
배치 전략이 정의되어 있지 않으면 다음 논리를 사용해 클러스터의 가용 영역 전체에서 균형을 유지합니다.
- 유효한 컨테이너 인스턴스를 정렬합니다. 각각의 가용 영역에서 이 서비스에 대해 실행 중인 작업 수가 가장 많은 인스턴스에 우선순위를 둡니다. 예를 들어 영역 A에 실행 중인 서비스 작업이 하나 있고 영역 B와 C에 각각 두 개씩 있다면 영역 B 또는 C의 컨테이너 인스턴스가 종료에 최적으로 간주됩니다.
- 이전 단계를 기반으로 최적의 가용 영역의 컨테이너 인스턴스에서 작업을 중지합니다. 이 서비스에 대해 실행 중인 작업 수가 가장 많은 컨테이너 인스턴스를 선호합니다.

배포 컨트롤러(Deployment controllers)

배포 컨트롤러는 서비스에 대해 작업이 어떻게 배포되는지 결정하는 메커니즘입니다. 유효한 옵션은 다음과 같습니다.

ECS

ECS 배포 컨트롤러를 사용하는 서비스를 만들 때 다음 배포 전략 중에서 선택할 수 있습니다.

ROLLING – 롤링 업데이트(ROLLING) 배포 전략을 사용하는 서비스를 만들면 Amazon ECS 서비스 스케줄러가 현재 실행 중인 작업을 새 작업으로 교체합니다. 롤링 업데이트 중에 Amazon ECS가 서비스에서 추가하거나 제거하는 작업 수는 서비스 배포 구성으로 제어됩니다.
- 롤링 업데이트 배포는 다음 시나리오에 가장 적합합니다.
  - 점진적 서비스 업데이트: 전체 서비스를 한 번에 오프라인으로 전환하지 않고 서비스를 증분적으로 업데이트해야 할 때
  - 제한된 리소스 요구 사항: 블루/그린 배포에 필요한 두 개의 전체 환경을 동시에 실행하는 추가 리소스 비용을 피하고 싶을 때
  - 허용 가능한 배포 시간: 롤링 업데이트가 작업을 하나씩 교체하므로 애플리케이션이 더 긴 배포 프로세스를 용인할 수 있을 때
  - 즉시 롤백 불필요: 서비스가 초 단위가 아닌 분 단위로 걸리는 롤백 프로세스를 용인할 수 있을 때
  - 간단한 배포 프로세스: 여러 환경, 대상 그룹, 리스너를 관리하는 복잡성 없이 간단한 배포 방식을 선호할 때
  - 로드 밸런서 불필요: 서비스가 로드 밸런서, Application Load Balancer, Network Load Balancer, Service Connect(블루/그린 배포에 필요)를 사용하거나 요구하지 않을 때
  - 상태 유지 애플리케이션: 애플리케이션이 두 개의 병렬 환경을 실행하기 어렵게 만드는 상태를 유지할 때
  - 비용 민감도: 배포 중 중복 환경을 실행하지 않아 배포 비용을 최소화하려 할 때
- 롤링 업데이트는 서비스의 기본 배포 전략이며 많은 일반적인 애플리케이션 시나리오에서 배포 안전성과 리소스 효율성 사이의 균형을 제공합니다.
BLUE_GREEN – 블루/그린(BLUE_GREEN) 배포 전략은 blue와 green이라는 두 개의 동일한 프로덕션 환경을 실행하여 다운타임과 위험을 줄이는 릴리스 방법론입니다. Amazon ECS 블루/그린 배포를 사용하면 프로덕션 트래픽을 보내기 전에 새 서비스 개정판을 검증할 수 있습니다. 이 접근 방식은 필요할 때 빠르게 롤백할 수 있는 능력으로 변경 사항을 더 안전하게 배포하는 방법을 제공합니다.
- Amazon ECS 블루/그린 배포는 다음 시나리오에 가장 적합합니다.
  - 서비스 검증: 프로덕션 트래픽을 보내기 전에 새 서비스 개정판을 검증해야 할 때
  - 제로 다운타임: 서비스가 제로 다운타임 배포를 요구할 때
  - 즉시 롤백: 문제가 감지되면 빠르게 롤백할 수 있는 능력이 필요할 때
  - 로드 밸런서 요구 사항: 서비스가 Application Load Balancer, Network Load Balancer 또는 Service Connect를 사용할 때
LINEAR – 선형(LINEAR) 배포 전략은 지정된 시간 동안 동일한 백분율 증가분으로 현재 프로덕션 환경에서 새 환경으로 트래픽을 점진적으로 전환합니다. Amazon ECS 선형 배포를 사용하면 트래픽 전환 속도를 제어하고 증가하는 프로덕션 트래픽 양으로 새 서비스 개정판을 검증할 수 있습니다.
- Amazon ECS 선형 배포는 다음 시나리오에 가장 적합합니다.
  - 점진적 검증: 증가하는 트래픽으로 새 서비스 버전을 점진적으로 검증하려 할 때
  - 성능 모니터링: 배포 중 메트릭과 성능을 모니터링할 시간이 필요할 때
  - 위험 최소화: 새 버전을 프로덕션 트래픽에 점진적으로 노출하여 위험을 최소화하려 할 때
  - 로드 밸런서 요구 사항: 서비스가 Application Load Balancer, Network Load Balancer 또는 Service Connect를 사용할 때
CANARY – 카나리아(CANARY) 배포 전략은 먼저 작은 백분율의 트래픽을 새 서비스 개정판으로 전환한 다음, 지정된 시간 후 나머지 트래픽을 한 번에 전환합니다. 이를 통해 전체 배포 전에 사용자 하위 집합으로 새 버전을 테스트할 수 있습니다.
- Amazon ECS 카나리아 배포는 다음 시나리오에 가장 적합합니다.
  - 기능 테스트: 전체 롤아웃 전에 작은 사용자 하위 집합으로 새 기능을 테스트하려 할 때
  - 프로덕션 검증: 실제 프로덕션 트래픽으로 성능과 기능을 검증해야 할 때
  - 블래스트 반경 제어: 새 버전에서 문제가 발견되면 블래스트 반경을 최소화하려 할 때
  - 로드 밸런서 요구 사항: 서비스가 Application Load Balancer, Network Load Balancer 또는 Service Connect를 사용할 때

External

타사 배포 컨트롤러를 사용합니다.

블루/그린 배포(AWS CodeDeploy 기반)

CodeDeploy는 애플리케이션의 업데이트된 버전을 새 교체 작업 세트로 설치하고, 원래 애플리케이션 작업 세트에서 교체 작업 세트로 프로덕션 트래픽을 다시 라우팅합니다. 성공적인 배포 후 원래 작업 세트가 종료됩니다. 이 배포 컨트롤러를 사용해 프로덕션 트래픽을 보내기 전에 서비스의 새 배포를 검증하세요.

배포 용어(Deployment terminology)

다음 용어는 Amazon ECS 배포 문서 전반에 걸쳐 사용됩니다.

블루-그린 배포(Blue-green deployment) – 기존 환경(blue) 옆에 새 환경(green)을 만들고 검증 후 blue에서 green으로 트래픽을 전환하는 배포 전략.
카나리아 배포(Canary deployment) – 검증을 위해 대부분의 트래픽을 안정적인 버전에 유지하면서 새 버전으로 작은 백분율의 트래픽을 라우팅하는 배포 전략.
선형 배포(Linear deployment) – 시간에 따라 같은 증분으로 트래픽을 이전 버전에서 새 버전으로 점진적으로 전환하는 배포 전략.
롤링 배포(Rolling deployment) – 이전 버전의 인스턴스를 새 버전의 인스턴스로 한 번에 하나씩 교체하는 배포 전략.
작업 세트(Task set) – 배포 중 서비스 내에서 같은 작업 정의를 실행하는 작업 모음.
대상 그룹(Target group) – 배포 중 로드 밸런서에서 트래픽을 받는 대상의 논리적 그룹.
배포 컨트롤러(Deployment controller) – 서비스의 새 버전을 배포하는 데 사용되는 방식(예: Amazon ECS, CodeDeploy, 외부 컨트롤러).
롤백(Rollback) – 배포 중 문제가 감지될 때 애플리케이션의 이전 버전으로 되돌리는 과정.

Amazon ECS 서비스 배포 컨트롤러와 전략