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

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

Amazon ECS 블루/그린 배포 프로세스는 안전하고 안정적인 애플리케이션 업데이트를 보장하는 6개의 뚜렷한 단계를 따르는 체계적인 접근 방식을 사용해요. 각 단계는 애플리케이션을 현재 버전(blue)에서 새 버전(green)으로 검증·전환하는 데 특정한 목적을 제공합니다.

출처: 문서

본문

Amazon ECS 블루/그린 배포 프로세스는 안전하고 안정적인 애플리케이션 업데이트를 보장하는 6개의 뚜렷한 단계를 따르는 체계적인 접근 방식을 사용합니다. 각 단계는 현재 버전(blue)에서 새 버전(green)으로 애플리케이션을 검증하고 전환하는 데 특정한 목적을 제공해요.

  • 준비 단계(Preparation Phase) — 기존 blue 환경 옆에 green 환경을 만듭니다. 여기에는 새 서비스 리비전 프로비저닝과 대상 그룹 준비가 포함됩니다.
  • 배포 단계(Deployment Phase) — 새 서비스 리비전을 green 환경에 배포합니다. Amazon ECS가 업데이트된 서비스 리비전으로 새 태스크를 시작하는 동안 blue 환경은 계속 프로덕션 트래픽을 처리합니다.
  • 테스트 단계(Testing Phase) — 테스트 트래픽 라우팅으로 green 환경을 검증합니다. Application Load Balancer는 프로덕션 트래픽이 blue에 남아 있는 동안 테스트 요청을 green 환경으로 보냅니다.
  • 트래픽 전환 단계(Traffic Shifting Phase) — 구성한 배포 전략에 따라 프로덕션 트래픽을 blue에서 green으로 전환합니다. 이 단계에는 모니터링과 검증 체크포인트가 포함됩니다.
  • 모니터링 단계(Monitoring Phase) — 베이크 타임(bake time) 기간 동안 애플리케이션 상태, 성능 메트릭, 알람 상태를 모니터링합니다. 문제가 감지되면 롤백 작업이 시작됩니다.
  • 완료 단계(Completion Phase) — 구성에 따라 blue 환경을 종료하거나 잠재적 롤백 시나리오를 위해 유지하여 배포를 마무리합니다.

워크플로

다음 다이어그램은 Amazon ECS와 Application Load Balancer 사이의 상호작용을 보여주는 종합적인 블루/그린 배포 워크플로를 나타냅니다.

향상된 배포 워크플로에는 다음의 상세 단계가 포함됩니다.

  1. 초기 상태(Initial State) — blue 서비스(현재 프로덕션)가 프로덕션 트래픽의 100%를 처리합니다. Application Load Balancer에는 모든 요청을 healthy한 blue 태스크가 포함된 blue 대상 그룹으로 라우팅하는 규칙이 있는 단일 리스너가 있습니다.
  2. Green 환경 프로비저닝(Green Environment Provisioning) — Amazon ECS가 업데이트된 태스크 정의로 새 태스크를 만듭니다. 이 태스크들은 새 green 대상 그룹에 등록되지만 처음에는 트래픽을 받지 않습니다.
  3. 헬스 체크 검증(Health Check Validation) — Application Load Balancer가 green 태스크에 대해 헬스 체크를 수행합니다. green 태스크가 헬스 체크를 통과해야만 배포가 다음 단계로 진행됩니다.
  4. 테스트 트래픽 라우팅(Test Traffic Routing) — 구성된 경우, Application Load Balancer의 리스너 규칙이 특정 트래픽 패턴(테스트 헤더가 있는 요청 등)을 프로덕션 트래픽이 blue에 남아 있는 동안 검증용으로 green 환경으로 보냅니다. 이는 프로덕션 트래픽을 처리하는 같은 리스너가 요청 속성에 따라 서로 다른 규칙을 사용해 제어합니다.
  5. 프로덕션 트래픽 전환(Production Traffic Shift) — 배포 구성에 따라 트래픽이 blue에서 green으로 전환됩니다. ECS 블루/그린 배포에서 이는 트래픽의 100%가 blue에서 green 환경으로 이동하는 즉시(한 번에, all-at-once) 전환입니다. Application Load Balancer는 가중치에 따라 blue와 green 대상 그룹 간의 트래픽 분산을 제어하는 리스너 규칙이 있는 단일 리스너를 사용합니다.
  6. 모니터링과 검증(Monitoring and Validation) — 트래픽 전환 내내 Amazon ECS가 CloudWatch 메트릭, 알람 상태, 배포 상태를 모니터링합니다. 문제가 감지되면 자동 롤백 트리거가 활성화됩니다.
  7. 베이크 타임 기간(Bake Time Period) — 프로덕션 트래픽이 전환된 후 blue와 green 서비스 리비전이 동시에 실행되는 기간입니다.
  8. Blue 환경 종료(Blue Environment Termination) — 성공적인 트래픽 전환과 검증 후, 클러스터 리소스를 확보하기 위해 blue 환경이 종료되거나, 빠른 롤백 기능을 위해 유지됩니다.
  9. 최종 상태(Final State) — green 환경이 새 프로덕션 환경이 되어 트래픽의 100%를 처리합니다. 배포는 성공으로 표시됩니다.

배포 수명주기 단계

블루/그린 배포 프로세스는 각각 특정 책임과 검증 체크포인트가 있는 뚜렷한 수명주기 단계(배포 작업의 일련의 이벤트, 예: "after production traffic shift")를 거쳐 진행됩니다. 이 단계를 이해하면 배포 진행 상황을 모니터링하고 문제를 효과적으로 트러블슈팅하는 데 도움이 됩니다.

각 수명주기 단계는 최대 24시간까지 지속될 수 있습니다. 값이 24시간 미만으로 유지되도록 권장합니다. 비동기 프로세스가 훅을 트리거하는 데 시간이 필요하기 때문입니다. 단계가 24시간에 도달하면 시스템이 타임아웃되어 배포를 실패시키고 롤백을 시작합니다.

CloudFormation 배포에는 추가 타임아웃 제한이 있습니다. 24시간 단계 제한이 유지되는 동안 CloudFormation은 전체 배포에 36시간 제한을 적용합니다. CloudFormation은 36시간 내에 프로세스가 완료되지 않으면 배포를 실패시키고 롤백을 시작합니다.

일시 중지 훅의 경우 타임아웃을 최대 20,160분(14일)까지 구성할 수 있습니다. 전체 배포 타임아웃은 30일입니다.

수명주기 단계 설명 수명주기 훅에 이 단계를 사용하나요?
RECONCILE_SERVICE 이 단계는 ACTIVE 상태의 서비스 리비전이 2개 이상인 상태로 새 서비스 배포를 시작할 때만 발생합니다. 예
PRE_SCALE_UP green 서비스 리비전이 시작되지 않았습니다. blue 서비스 리비전이 프로덕션 트래픽의 100%를 처리합니다. 테스트 트래픽이 없습니다. 예
SCALE_UP green 서비스 리비전이 100%로 확장되고 새 태스크를 시작하는 시점입니다. 이 시점에 green 서비스 리비전은 트래픽을 처리하지 않습니다. 아니요
POST_SCALE_UP green 서비스 리비전이 시작되었습니다. blue 서비스 리비전이 프로덕션 트래픽의 100%를 처리합니다. 테스트 트래픽이 없습니다. 예
TEST_TRAFFIC_SHIFT blue와 green 서비스 리비전이 모두 실행 중입니다. blue 서비스 리비전이 프로덕션 트래픽의 100%를 처리합니다. green 서비스 리비전이 테스트 트래픽의 0%에서 100%로 마이그레이션 중입니다. 예 (Lambda만)
POST_TEST_TRAFFIC_SHIFT 테스트 트래픽 전환이 완료되었습니다. green 서비스 리비전이 테스트 트래픽의 100%를 처리합니다. 예
PRE_PRODUCTION_TRAFFIC_SHIFT 프로덕션 트래픽 전환 전에 발생합니다. 블루/그린 배포의 경우 이 단계는 한 번 호출됩니다. 예
PRODUCTION_TRAFFIC_SHIFT 프로덕션 트래픽이 green 서비스 리비전으로 전환되고 있습니다. green 서비스 리비전이 프로덕션 트래픽의 0%에서 100%로 마이그레이션 중입니다. 예 (Lambda만)
POST_PRODUCTION_TRAFFIC_SHIFT 프로덕션 트래픽 전환이 완료되었습니다. 예
BAKE_TIME blue와 green 서비스 리비전이 동시에 실행되는 기간입니다. 아니요
CLEAN_UP blue 서비스 리비전이 완전히 0 실행 태스크로 축소되었습니다. 이 단계 이후 green 서비스 리비전이 프로덕션 서비스 리비전이 됩니다. 아니요

각 수명주기 단계에는 다음 단계로 진행하기 전에 통과해야 하는 내장 검증 체크포인트가 있습니다. 검증이 실패하면 서비스 가용성과 신뢰성을 유지하기 위해 배포가 자동으로 롤백될 수 있습니다.

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

더 알아보기 (Learn more)

  • Amazon ECS 블루/그린 배포에 대한 자세한 내용은 AWS 공식 문서를 참고해 주세요.