Amazon ECS 카나리아 배포

Amazon ECS 카나리아 배포

카나리아 배포는 먼저 트래픽의 작은 백분율을 새 개정판으로 라우팅해 초기 테스트를 한 다음, 카나리아 단계가 성공적으로 완료되면 나머지 모든 트래픽을 한 번에 전환해요.

출처: 문서

본문

카나리아 배포는 먼저 트래픽의 작은 백분율을 새 개정판으로 라우팅해 초기 테스트를 한 다음, 카나리아 단계가 성공적으로 완료되면 나머지 모든 트래픽을 한 번에 전환합니다. Amazon ECS 카나리아 배포를 사용하면 위험 노출을 최소화하면서 실제 사용자 트래픽으로 새 서비스 개정판을 검증할 수 있습니다. 이 접근 방식은 성능을 모니터링하고 문제가 감지되면 빠르게 롤백할 수 있는 능력으로 변경 사항을 제어된 방식으로 배포하는 방법을 제공합니다.

카나리아 배포에 관련된 리소스

다음은 Amazon ECS 카나리아 배포에 관련된 리소스입니다.

• 트래픽 전환(Traffic shift) – Amazon ECS가 프로덕션 트래픽을 전환하는 과정. Amazon ECS 카나리아 배포의 경우 트래픽이 두 단계로 전환됩니다: 먼저 카나리아 백분율로, 그 다음 배포를 완료하기 위해.
• 카나리아 백분율(Canary percentage) – 평가 기간 동안 새 버전으로 라우팅되는 트래픽의 백분율.
• 카나리아 베이크 시간(Canary bake time) – 전체 배포를 진행하기 전에 카나리아 버전을 모니터링하는 기간.
• 배포 베이크 시간(Deployment bake time) – Amazon ECS가 모든 프로덕션 트래픽을 새 서비스 개정판으로 전환한 후 이전 서비스 개정판을 종료하기 전에 기다리는 시간(분). 이는 프로덕션 트래픽이 전환된 후 blue와 green 서비스 개정판이 동시에 실행되는 기간입니다.
• 수명 주기 단계(Lifecycle stages) – "after production traffic shift" 같은 배포 작업의 일련의 이벤트.
• 수명 주기 후크(Lifecycle hook) – 특정 수명 주기 단계에서의 Lambda 함수 또는 일시 중지 지점. Lambda 후크는 사용자가 정의한 Lambda 함수를 호출해 사용자 지정 코드를 실행합니다. 일시 중지 후크는 배포를 일시 중지하고 ContinueServiceDeployment를 호출할 때까지 기다립니다.
• 대상 그룹(Target group) – 하나 이상의 등록된 대상(예: EC2 인스턴스)으로 요청을 라우팅하는 데 사용되는 Elastic Load Balancing 리소스. 리스너를 만들 때 기본 액션에 대한 대상 그룹을 지정합니다. 트래픽은 리스너 규칙에 지정된 대상 그룹으로 전달됩니다.
• 리스너(Listener) – 구성한 프로토콜과 포트를 사용해 연결 요청을 확인하는 Elastic Load Balancing 리소스. 리스너에 대해 정의한 규칙은 Amazon ECS가 등록된 대상으로 요청을 어떻게 라우팅하는지 결정합니다.
• 규칙(Rule) – 리스너와 연결된 Elastic Load Balancing 리소스. 규칙은 요청이 어떻게 라우팅되는지 정의하며 액션, 조건, 우선순위로 구성됩니다.

고려 사항

배포 유형을 선택할 때 다음을 고려하세요.

• 리소스 사용: 카나리아 배포는 평가 기간 동안 원본과 카나리아 작업 세트를 동시에 실행하므로 리소스 사용이 증가합니다.
• 트래픽 양: 카나리아 백분율이 새 버전의 의미 있는 검증에 충분한 트래픽을 생성하는지 확인하세요.
• 모니터링 복잡성: 카나리아 배포는 두 개의 서로 다른 버전 사이의 메트릭을 동시에 모니터링하고 비교해야 합니다.
• 롤백 속도: 카나리아 배포는 트래픽을 원래 작업 세트로 되돌려 빠른 롤백을 가능하게 합니다.
• 위험 완화: 카나리아 배포는 소수의 사용자 집단에만 노출을 제한하여 우수한 위험 완화를 제공합니다.
• 배포 기간: 카나리아 배포는 전체 배포 시간을 연장하지만 검증 기회를 제공하는 평가 기간을 포함합니다.

카나리아 배포 동작 방식

Amazon ECS 카나리아 배포 프로세스는 안전하고 안정적인 애플리케이션 업데이트를 보장하는 6개의 뚜렷한 단계로 구성된 구조적 접근 방식을 따릅니다. 각 단계는 애플리케이션을 현재 버전(blue)에서 새 버전(green)으로 검증하고 전환하는 데 특정 목적을 제공합니다.

1. 준비 단계(Preparation Phase): 기존 blue 환경 옆에 green 환경을 만듭니다.
2. 배포 단계(Deployment Phase): 새 서비스 개정판을 green 환경에 배포합니다. blue 환경이 계속 프로덕션 트래픽을 제공하는 동안 Amazon ECS가 업데이트된 서비스 개정판을 사용해 새 작업을 시작합니다.
3. 테스트 단계(Testing Phase): 테스트 트래픽 라우팅으로 green 환경을 검증합니다. Application Load Balancer가 프로덕션 트래픽은 blue에 유지하면서 테스트 요청을 green 환경으로 보냅니다.
4. 카나리아 트래픽 전환 단계(Canary Traffic Shifting Phase): 카나리아 단계에서 구성된 백분율의 트래픽을 새 green 서비스 개정판으로 전환한 다음, 트래픽의 100.0%를 green 서비스 개정판으로 전환합니다.
5. 모니터링 단계(Monitoring Phase): 베이크 타임 기간 동안 애플리케이션 상태, 성능 메트릭, 알람 상태를 모니터링합니다. 문제가 감지되면 롤백 작업이 시작됩니다.
6. 완료 단계(Completion Phase): blue 환경을 종료하여 배포를 마무리합니다.

카나리아 트래픽 전환 단계는 다음 단계를 따릅니다.

• 초기(Initial): 배포는 트래픽의 100%를 blue(현재) 서비스 개정판으로 라우팅하며 시작합니다. green(새) 서비스 개정판은 처음에 테스트 트래픽만 받고 프로덕션 트래픽은 받지 않습니다.
• 카나리아 트래픽 전환(Canary traffic shifting): 2단계 트래픽 전환 전략입니다.
  • 1단계: green에 10.0%, blue에 90.0%
  • 2단계: green에 100.0%, blue에 0.0%
• 카나리아 베이크 시간(Canary bake time): 카나리아 트래픽 전환 후 구성 가능한 기간(카나리아 베이크 시간)을 기다려 증가된 트래픽 부하로 새 개정판의 성능을 모니터링하고 검증합니다.
• 수명 주기 후크(Lifecycle hooks): 배포 중 다양한 수명 주기 단계에서 자동 검증, 모니터링 또는 사용자 지정 논리를 수행하도록 선택적 Lambda 함수나 일시 중지 후크를 구성할 수 있습니다. PRODUCTION_TRAFFIC_SHIFT 또는 PRE_PRODUCTION_TRAFFIC_SHIFT에 구성된 후크는 모든 프로덕션 트래픽 전환 단계에서 호출됩니다.

배포 수명 주기 단계

카나리아 배포 프로세스는 뚜렷한 수명 주기 단계를 거치며, 각 단계에는 특정 책임과 검증 체크포인트가 있습니다. 이러한 단계를 이해하면 배포 진행 상황을 모니터링하고 문제를 효과적으로 해결하는 데 도움이 됩니다.

각 수명 주기 단계는 최대 24시간까지 지속될 수 있으며, 추가로 PRODUCTION_TRAFFIC_SHIFT의 각 트래픽 전환 단계도 최대 24시간까지 지속될 수 있습니다. 값이 24시간 표시 아래로 유지되기를 권장합니다. 이는 비동기 프로세스가 후크를 트리거하는 데 시간이 필요하기 때문입니다. 단계가 24시간에 도달하면 시스템이 시간 초과되어 배포를 실패시키고 롤백을 시작합니다.

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

일시 중지 후크의 경우 최대 20,160분(14일)까지 시간 초과를 구성할 수 있습니다. 전체 배포 시간 초과는 30일입니다.

구성 매개변수(Configuration parameters)

카나리아 배포에는 다음 구성 매개변수가 필요합니다.

• 카나리아 백분율 – 카나리아 단계에서 새 서비스 개정판으로 라우팅할 트래픽의 백분율. 이는 제어된 프로덕션 트래픽 하위 집합으로 테스트할 수 있게 해줍니다.
• 카나리아 베이크 시간 – 나머지 트래픽을 새 서비스 개정판으로 전환하기 전에 카나리아 단계에서 기다리는 기간. 이는 새 버전을 모니터링하고 검증할 시간을 제공합니다.

트래픽 관리(Traffic management)

카나리아 배포는 로드 밸런서 대상 그룹을 사용해 트래픽 분포를 관리합니다.

• 원본 대상 그룹 – 현재 안정적인 버전의 작업을 포함하며 대부분의 트래픽을 받습니다.
• 카나리아 대상 그룹 – 새 버전의 작업을 포함하며 테스트를 위해 작은 백분율의 트래픽을 받습니다.
• 가중 라우팅 – 로드 밸런서는 구성된 카나리아 백분율에 따라 가중 라우팅 규칙을 사용해 대상 그룹 사이에 트래픽을 분배합니다.

모니터링과 검증(Monitoring and validation)

효과적인 카나리아 배포는 포괄적인 모니터링에 의존합니다.

• 상태 확인 – 두 작업 세트 모두 트래픽을 받기 전에 상태 확인을 통과해야 합니다.
• 메트릭 비교 – 응답 시간, 오류율, 처리량 같은 핵심 성능 지표를 원본 버전과 카나리아 버전 사이에서 비교합니다.
• 자동 롤백 – 카나리아 버전이 성능 저하를 보이면 자동으로 롤백을 트리거하도록 CloudWatch 알람을 구성합니다.
• 수동 검증 – 진행하기 전에 로그, 메트릭, 사용자 피드백을 수동으로 검토할 평가 기간을 사용합니다.

카나리아 배포 모범 사례

서비스와 함께 성공적인 카나리아 배포를 보장하려면 다음 모범 사례를 따르세요.

적절한 트래픽 백분율 선택

카나리아 트래픽 백분율을 선택할 때 다음 요인을 고려하세요.

• 작게 시작 – 문제가 발생할 경우 영향을 최소화하려면 트래픽의 5-10%로 시작하세요.
• 애플리케이션 중요도 고려 – 미션 크리티컬 애플리케이션에는 더 작은 백분율을, 덜 중요한 서비스에는 더 큰 백분율을 사용하세요.
• 트래픽 양 고려 – 카나리아 백분율이 의미 있는 검증에 충분한 트래픽을 생성하는지 확인하세요.

적절한 평가 기간 설정

다음 고려 사항에 따라 평가 기간을 구성하세요.

• 충분한 시간 허용 – 의미 있는 성능 데이터를 캡처할 만큼 긴 평가 기간(일반적으로 10-30분)을 설정하세요.
• 트래픽 패턴 고려 – 애플리케이션의 트래픽 패턴과 최고 사용 시간을 고려하세요.
• 속도와 안전성 균형 – 더 긴 평가 기간은 더 많은 데이터를 제공하지만 배포 속도를 늦춥니다.

포괄적인 모니터링 구현

카나리아 배포 성능을 추적하도록 모니터링을 설정하세요.

• 핵심 메트릭 – 두 작업 세트 모두에 대한 응답 시간, 오류율, 처리량, 리소스 사용률을 모니터링하세요.
• 알람 기반 롤백 – 메트릭이 임계값을 초과하면 자동으로 롤백을 트리거하도록 CloudWatch 알람을 구성하세요.
• 비교 분석 – 원본과 카나리아 버전의 메트릭을 나란히 비교하는 대시보드를 설정하세요.
• 비즈니스 메트릭 – 기술 메트릭과 함께 전환율이나 사용자 참여 같은 비즈니스 특정 메트릭을 포함하세요.

롤백 전략 계획

다음 전략으로 잠재적인 롤백 시나리오를 준비하세요.

• 자동 롤백 – 상태 확인과 성능 메트릭을 기반으로 자동 롤백 트리거를 구성하세요.
• 수동 롤백 절차 – 자동 트리거가 모든 문제를 포착하지 못할 때 수동 롤백에 대한 명확한 절차를 문서화하세요.
• 롤백 테스트 – 필요할 때 올바르게 작동하는지 확인하도록 롤백 절차를 정기적으로 테스트하세요.

배포 전 철저한 검증

카나리아 배포를 진행하기 전에 철저한 검증을 보장하세요.

• 배포 전 테스트 – 카나리아 배포 전에 스테이징 환경에서 변경 사항을 철저히 테스트하세요.
• 상태 확인 구성 – 상태 확인이 애플리케이션 준비 상태와 기능을 정확히 반영하는지 확인하세요.
• 의존성 검증 – 새 버전이 다운스트림 및 업스트림 서비스와 호환되는지 확인하세요.
• 데이터 일관성 – 데이터베이스 스키마 변경과 데이터 마이그레이션이 이전 버전과 호환되는지 확인하세요.

팀 참여 조정

카나리아 배포 중에 효과적인 팀 조정을 보장하세요.

• 배포 창 – 팀이 모니터링하고 대응할 수 있는 업무 시간에 카나리아 배포를 예약하세요.
• 통신 채널 – 배포 상태와 문제 에스컬레이션을 위한 명확한 통신 채널을 구축하세요.
• 역할 할당 – 모니터링, 의사 결정, 롤백 실행을 위한 역할과 책임을 정의하세요.

더 알아보기 (Learn more)

• Blue/green deployments with Amazon ECS
• Linear deployments with Amazon ECS