Amazon ECS 블루/그린 서비스 배포 워크플로 - Amazon Elastic Container Service
워크플로배포 수명 주기 단계

Amazon ECS 블루/그린 서비스 배포 워크플로

Amazon ECS 블루/그린 배포 프로세스는 안전하고 신뢰할 수 있는 애플리케이션 업데이트를 보장하는 6단계로 구성된 구조화된 접근 방식을 따릅니다. 각 단계는 애플리케이션을 검증하고 현재 버전(파란색)에서 새 버전(녹색)으로 전환하는 구체적인 목적을 지원합니다.

  1. 준비 단계: 기존 블루 환경과 함께 그린 환경을 생성합니다. 여기에는 새 서비스 개정 프로비저닝 및 대상 그룹 준비가 포함됩니다.

  2. 배포 단계: 그린 환경에 새 서비스 개정을 배포합니다. 블루 환경이 프로덕션 트래픽을 계속 처리하는 동안 Amazon ECS는 업데이트된 서비스 개정을 사용하여 새 태스크를 시작합니다.

  3. 테스트 단계: 테스트 트래픽 라우팅을 사용하여 그린 환경을 검증합니다. Application Load Balancer는 프로덕션 트래픽이 블루 환경에서 유지되는 동안 테스트 요청을 그린 환경으로 보냅니다.

  4. 트래픽 전환 단계: 구성된 배포 전략에 따라 프로덕션 트래픽을 파란색에서 녹색으로 전환합니다. 이 단계에서는 모니터링 및 검증 체크포인트를 포함합니다.

  5. 모니터링 단계: 베이크 소요 시간 동안 애플리케이션 상태, 성능 지표 및 경보 상태를 모니터링합니다. 문제가 감지되면 롤백 작업이 시작됩니다.

  6. 완료 단계: 구성에 따라 블루 환경을 종료하거나 잠재적 롤백 시나리오에 맞게 유지 관리하여 배포를 완료합니다.

워크플로

다음 다이어그램은 Amazon ECS와 Application Load Balancer 간 상호 작용을 표시하는 포괄적인 블루/그린 배포 워크플로를 보여줍니다.

자세한 구성 요소 상호 작용, 트래픽 전환 단계 및 모니터링 체크포인트를 포함하는 Amazon ECS의 블루/그린 배포 프로세스를 표시하는 포괄적인 다이어그램

향상된 배포 워크플로는 다음과 같은 세부 단계를 포함합니다.

  1. 초기 상태: 블루 서비스(현재 프로덕션)가 프로덕션 트래픽의 100%를 처리합니다. Application Load Balancer에는 정상 상태의 블루 태스크를 포함하는 블루 대상 그룹으로 모든 요청을 라우팅하는 규칙을 사용하는 단일 리스너가 있습니다.

  2. 그린 환경 프로비저닝: Amazon ECS는 업데이트된 태스크 정의를 사용하여 새 태스크를 생성합니다. 이러한 태스크는 새 그린 대상 그룹에 등록되지만 처음에는 트래픽을 수신하지 않습니다.

  3. 상태 확인 검증: Application Load Balancer는 그린 태스크에 대해 상태 확인을 수행합니다. 그린 태스크가 상태 확인을 통과한 경우에만 배포는 다음 단계로 진행됩니다.

  4. 테스트 트래픽 라우팅: 구성된 경우 Application Load Balancer의 리스너 규칙은 프로덕션 트래픽이 블루 환경에서 유지되는 동안 검증을 위해 특정 트래픽 패턴(예: 테스트 헤더가 있는 요청)을 그린 환경으로 라우팅합니다. 이는 요청 속성에 따라 서로 다른 규칙을 사용하여 프로덕션 트래픽을 처리하는 동일한 리스너에 의해 제어됩니다.

  5. 프로덕션 트래픽 전환: 배포 구성에 따라 트래픽이 블루에서 그린으로 전환됩니다. ECS 블루/그린 배포에서는 트래픽의 100%가 블루에서 그린 환경으로 이동합니다(즉시 한 번에 전환). Application Load Balancer는 가중치를 기반으로 블루 및 그린 대상 그룹 간 트래픽 분산을 제어하는 리스너 규칙을 사용하는 단일 리스너를 사용합니다.

  6. 모니터링 및 검증: Amazon ECS는 트래픽 전환 전반에 걸쳐 CloudWatch 지표, 경보 상태 및 배포 상태를 모니터링합니다. 문제가 감지되면 자동 롤백 트리거가 활성화됩니다.

  7. 베이크 소요 시간(기간): 프로덕션 트래픽이 전환된 후 블루 및 그린 서비스 개정이 동시에 실행되는 기간.

  8. 블루 환경 종료: 트래픽 전환 및 검증에 성공하면 클러스터 리소스를 확보하기 위해 블루 환경이 종료되거나 빠른 롤백 기능을 위해 유지됩니다.

  9. 최종 상태: 그린 환경은 트래픽의 100%를 처리하며 새로운 프로덕션 환경이 됩니다. 배포가 성공으로 표시됩니다.

배포 수명 주기 단계

블루/그린 배포 프로세스는 각각 특정 책임과 검증 체크포인트가 있는 고유한 수명 주기 단계('프로덕션 트래픽 전환 이후'와 같은 배포 작업에서 일련의 이벤트)를 거칩니다. 이러한 단계를 이해하면 배포 진행 상황을 모니터링하고 문제를 효과적으로 해결할 수 있습니다.

각 수명 주기 단계는 최대 24시간 동안 지속될 수 있습니다. 값을 24시간 표시 미만으로 유지하는 것이 좋습니다. 비동기 프로세스가 후크를 트리거하는 데 시간이 필요하기 때문입니다. 시스템 제한 시간이 초과되어 배포에 실패하고 하나의 단계가 24시간에 도달한 후에 롤백을 시작합니다. AWS CloudFormation 배포에는 추가 제한 시간이 있습니다. 24시간의 단계 제한은 여전히 유효하지만 AWS CloudFormation은 전체 배포에 대해 36시간의 제한을 적용합니다. AWS CloudFormation에서 배포에 실패하고 프로세스가 36시간 이내에 완료되지 않으면 롤백을 시작합니다.

수명 주기 단계 설명 수명 주기 후크에서 이 단계 사용 여부
RECONCILE_SERVICE 이 단계는 활성 상태인 서비스 개정이 2개 이상인 새 서비스 배포를 시작하는 경우에만 나타납니다. 예
PRE_SCALE_UP 그린 서비스 개정이 시작되지 않았습니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리하는 중입니다. 테스트 트래픽이 없습니다. 예
SCALE_UP 그린 서비스 개정이 100%까지 스케일 업되고 새 태스크를 시작하는 시간. 그린 서비스 개정이 현재 트래픽을 처리하지 않습니다. 아니요
POST_SCALE_UP 그린 서비스 개정이 시작되었습니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리하는 중입니다. 테스트 트래픽이 없습니다. 예
TEST_TRAFFIC_SHIFT 블루 및 그린 서비스 개정이 실행 중입니다. 블루 서비스 개정이 프로덕션 트래픽의 100%를 처리합니다. 그린 서비스 개정이 테스트 트래픽의 0%~100%를 마이그레이션하고 있습니다. 예
POST_TEST_TRAFFIC_SHIFT 테스트 트래픽 전환이 완료되었습니다. 그린 서비스 개정이 테스트 트래픽의 100%를 처리합니다. 예
PRODUCTION_TRAFFIC_SHIFT 프로덕션 트래픽이 그린 서비스 개정으로 전환되고 있습니다. 그린 서비스 개정이 프로덕션 트래픽의 0%~100%를 마이그레이션하고 있습니다. 예
POST_PRODUCTION_TRAFFIC_SHIFT 프로덕션 트래픽 전환이 완료되었습니다. 예
BAKE_TIME 블루 및 그린 서비스 개정이 동시에 실행 중인 기간. 아니요
CLEAN_UP 블루 서비스 개정이 실행 중인 태스크가 0개인 상태로 완전히 스케일 다운되었습니다. 이제 그린 서비스 개정은 이 단계 이후에 프로덕션 서비스 개정이 됩니다. 아니요

각 수명 주기 단계는 다음 단계로 진행하기 전에 통과해야 하는 기본 제공 검증 체크포인트를 포함합니다. 검증에 실패하면 배포를 자동으로 롤백하여 서비스 가용성과 신뢰성을 유지 관리할 수 있습니다.

Lambda 함수를 사용하는 경우 함수는 작업을 완료하거나 15분 이내에 IN_PROGRESS를 반환해야 합니다. callBackDelaySeconds를 사용하여 Lambda에 대한 호출을 지연할 수 있습니다. 자세한 내용은 GitHub의 sample-amazon-ecs-blue-green-deployment-patterns에서 app.py 함수를 참조하세요.