CodeDeploy 블루/그린 배포를 Amazon ECS 블루/그린 배포로 마이그레이션 - Amazon Elastic Container Service
CodeDeploy 블루/그린 배포 개요Amazon ECS 블루/그린 배포 개요주요 구현 차이마이그레이션 접근 방식다음 단계

CodeDeploy 블루/그린 배포를 Amazon ECS 블루/그린 배포로 마이그레이션

CodeDeploy 블루/그린 및 Amazon ECS 블루/그린 배포는 유사한 기능을 제공하지만 구성 및 관리 방법은 서로 다릅니다.

CodeDeploy 블루/그린 배포 개요

CodeDeploy를 사용하여 Amazon ECS 서비스를 생성하는 경우 다음을 수행합니다.

  1. 프로덕션 리스너 및 (선택 사항) 테스트 리스너를 사용하여 로드 밸런서를 생성합니다. 각 리스너는 모든 트래픽을 단일 대상 그룹(기본 대상 그룹)으로 라우팅하는 단일(기본) 규칙으로 구성됩니다.

  2. deploymentController 유형이 CODE_DEPLOY로 설정된 리스너 및 대상 그룹을 사용하도록 구성된 Amazon ECS 서비스를 생성합니다. 서비스를 생성하면 지정된 대상 그룹에 등록된 (블루) 태스크 세트가 생성됩니다.

  3. CodeDeploy 배포 그룹(CodeDeploy 애플리케이션의 일부)을 생성하고 Amazon ECS 클러스터, 서비스 이름, 로드 밸런서 리스너, 두 개의 대상 그룹(프로덕션 리스너 규칙에 사용되는 기본 대상 그룹, 대체 태스크에 사용할 보조 대상 그룹), 서비스 역할(Amazon ECS 및 Elastic Load Balancing 리소스를 조작할 수 있는 권한을 CodeDeploy에 부여), 배포 동작을 제어하는 다양한 파라미터의 세부 정보로 구성합니다.

CodeDeploy를 사용하면 CreateDeployment()를 사용하여 새 버전의 서비스가 배포되고 이때 CodeDeploy 애플리케이션 이름, 배포 그룹 이름 및 새 개정과 선택적 수명 주기 후크에 대한 세부 정보를 제공하는 AppSpec 파일을 지정합니다. CodeDeploy 배포는 대체(그린) 태스크 세트를 생성하고 해당 태스크를 보조 대상 그룹에 등록합니다. 정상 상태가 되면 테스트(선택 사항) 및 프로덕션에서 사용할 수 있습니다. 두 경우 모두 그린 태스크 세트와 연결된 보조 대상 그룹을 가리키도록 각 리스너 규칙을 변경하여 다시 라우팅할 수 있습니다. 롤백은 프로덕션 리스너 규칙을 기본 대상 그룹으로 다시 변경하여 수행됩니다.

Amazon ECS 블루/그린 배포 개요

Amazon ECS 블루/그린 배포의 경우 배포 구성은 Amazon ECS 서비스 자체의 일부입니다.

  1. 가중치가 1과 0인 두 개의 대상 그룹을 포함하는 규칙을 사용하여 로드 밸런서 프로덕션 리스너를 사전 구성해야 합니다.

  2. 다음 리소스를 지정하거나 서비스 리소스를 업데이트해야 합니다.

    • 이 리스너 규칙의 ARN

    • 두 개의 대상 그룹

    • Amazon ECS에 Elastic Load Balancing API를 직접 호출할 권한을 부여하는 IAM 역할

    • Lambda 함수를 실행하기 위한 선택적 IAM 역할

    • deploymentController 유형을 ECS로 설정하고 deploymentConfiguration.strategy를 BLUE_GREEN으로 설정합니다. 그러면 태스크가 기본 대상 그룹에 등록된 (블루) 서비스 배포가 생성됩니다.

Amazon ECS 블루/그린을 사용하면 Amazon ECS UpdateService()를 직접 호출하고 새 개정의 세부 정보를 전달하여 새 서비스 개정이 생성됩니다. 서비스 배포는 새 (그린) 서비스 개정 태스크를 생성하고 보조 대상 그룹에 등록합니다. Amazon ECS는 리스너 규칙의 가중치를 전환하여 재라우팅 및 롤백 작업을 처리합니다.

주요 구현 차이

두 접근 방식 모두 초기 태스크 세트를 생성하지만 기본 구현은 서로 다릅니다.

  • CodeDeploy는 태스크 세트를 사용하지만 Amazon ECS는 서비스 개정을 사용합니다. Amazon ECS 태스크 세트는 Amazon ECS 서비스 개정 및 배포로 대체된 이전 구문입니다. 후자는 배포 프로세스와 서비스 배포 및 서비스 개정 기록에 대한 더 높은 가시성을 제공합니다.

  • CodeDeploy를 사용하면 수명 주기 후크가 CreateDeployment()에 제공되는 AppSpec 파일의 일부로 지정됩니다. 즉, 후크를 한 배포에서 다음 배포로 변경할 수 있습니다. Amazon ECS 블루/그린에서는 후크가 서비스 구성의 일부로 지정되며 모든 업데이트에 UpdateService() 직접 호출이 필요합니다.

  • CodeDeploy와 Amazon ECS 블루/그린 모두 후크 구현에 Lambda를 사용하지만 예상되는 입력과 출력은 서로 다릅니다.

    CodeDeploy에서는 함수가 PutLifecycleEventHookExecutionStatus()를 직접 호출하여 후크 상태를 반환해야 합니다. 후크 상태는 SUCCEEDED 또는 FAILED일 수 있습니다. Amazon ECS에서는 Lambda 응답을 사용하여 후크 상태를 나타냅니다.

  • CodeDeploy는 각 후크를 일회성 직접 호출로 간접 호출하며 1시간 이내에 최종 실행 상태가 반환될 것으로 예상합니다. Amazon ECS 후크는 IN_PROGRESS 표시기를 리턴할 수 있다는 점에서 보다 유연합니다. 이 표시기는 SUCCEEDED 또는 FAILED가 될 때까지 후크를 반복적으로 다시 간접 호출해야 함을 알립니다. 자세한 내용은 Amazon ECS 서비스 배포에 대한 수명 주기 후크 섹션을 참조하세요.

마이그레이션 접근 방식

CodeDeploy 블루/그린에서 Amazon ECS 블루/그린 배포로 마이그레이션하는 세 가지 기본 접근 방식이 있습니다. 각 접근 방식은 복잡성, 위험, 롤백 기능 및 잠재적 가동 중지 시간 측면에서 서로 다른 특성을 보입니다.

CodeDeploy에 사용된 것과 동일한 Elastic Load Balancing 리소스 재사용

CodeDeploy 배포 컨트롤러 대신 블루/그린 배포 전략으로 Amazon ECS 배포 컨트롤러를 사용하도록 기존 Amazon ECS 서비스를 업데이트합니다. 이 접근 방식을 사용하는 경우 다음 사항을 고려하세요.

  • 기존 Amazon ECS 서비스 배포 컨트롤러 및 배포 전략을 업데이트하므로 마이그레이션 절차가 더 간단합니다.

  • 올바르게 구성하고 마이그레이션하면 가동 중지 시간이 발생하지 않습니다.

  • 롤백하려면 서비스 개정을 되돌려야 합니다.

  • 병렬 블루/그린 구성이 없으므로 위험이 높습니다.

CodeDeploy에 사용되는 것과 동일한 로드 밸런서 리스너 및 대상 그룹을 사용합니다. CloudFormation을 사용 중인 경우 CloudFormation CodeDeploy 블루/그린 배포 템플릿을 Amazon ECS 블루/그린 CloudFormation 템플릿으로 마이그레이션 섹션을 참조하세요.

  1. 대체 대상 그룹을 포함하도록 프로덕션/테스트 리스너의 기본 규칙을 수정하고 기본 대상 그룹의 가중치를 1로, 대체 대상 그룹을 0으로 설정하세요.

    CodeDeploy의 경우 서비스에 연결된 로드 밸런서의 리스너는 모든 트래픽을 단일 대상 그룹으로 라우팅하는 단일(기본값) 규칙으로 구성됩니다. Amazon ECS 블루/그린의 경우 로드 밸런서 리스너는 가중치가 있는 두 개의 대상 그룹을 포함하는 규칙으로 사전 구성되어야 합니다. 기본 대상 그룹은 가중치를 1로 지정하고 대체 대상 그룹은 가중치를 0으로 지정해야 합니다.

  2. UpdateService API를 직접 호출하고 파라미터 deploymentController를 ECS로, 파라미터 deploymentStrategy를 BLUE_GREEN으로 설정하여 기존 Amazon ECS 서비스를 업데이트하세요. 대상 그룹, 대체 대상 그룹, 프로덕션 리스너 및 선택적 테스트 리스너의 ARN을 지정하세요.

  3. 서비스가 예상대로 작동하는지 확인하세요.

  4. 이제 Amazon ECS 블루/그린을 사용하고 있으므로 이 Amazon ECS 서비스에 대한 CodeDeploy 설정을 삭제하세요.

기존 로드 밸런서를 사용하는 새 서비스

이 접근 방식은 마이그레이션에 블루/그린 전략을 사용합니다.

이 접근 방식을 사용하는 경우 다음 사항을 고려하세요.

  • 중단이 최소화됩니다. Elastic Load Balancing 포트 스왑 중에만 발생합니다.

  • 롤백하려면 Elastic Load Balancing 포트 스왑을 되돌려야 합니다.

  • 병렬 구성이기 때문에 위험이 낮습니다. 따라서 트래픽 전환 전에 테스트할 수 있습니다.

  1. 필요한 경우 이 설정으로 쉽게 롤백할 수 있도록 CodeDeploy 설정에 대한 리스너, 대상 그룹 및 Amazon ECS 서비스를 그대로 두세요.

  2. 기존 로드 밸런서에서 새 대상 그룹과 새 리스너(원래 리스너와 다른 포트를 사용함)를 생성하세요. 그런 다음 배포 컨트롤러로 ECS, 배포 전략으로 BLUE_GREEN을 사용하는 경우를 제외하고 기존 Amazon ECS 서비스와 일치하는 새 Amazon ECS 서비스를 생성하고 새 대상 그룹 및 새 리스너 규칙에 대한 ARN을 전달하세요.

  3. 서비스에 HTTP 트래픽을 수동으로 전송하여 새 설정을 확인하세요. 모두 잘 진행되면 원래 리스너와 새 리스너의 포트를 바꿔 트래픽을 새 설정으로 라우팅하세요.

  4. 새 설정을 확인하고 모든 것이 예상대로 계속 작동하면 CodeDeploy 설정을 삭제하세요.

새 로드 밸런서를 사용하는 새 서비스

이전 접근 방식과 마찬가지로 이 접근 방식은 마이그레이션에 블루/그린 전략을 사용합니다. 주요 차이점은 CodeDeploy 설정에서 Amazon ECS 블루/그린 설정으로 전환이 로드 밸런서 위의 역방향 프록시 계층에서 발생한다는 점입니다. 역방향 프록시 계층의 구현 샘플은 Route 53 및 CloudFront입니다.

이 접근 방식은 이미 이 역방향 프록시 계층이 있고 서비스와의 모든 통신이 이를 통해 수행되는 고객(예: 로드 밸런서 수준에서 직접 통신하지 않음) 적합합니다.

이 접근 방식을 사용하는 경우 다음 사항을 고려하세요.

  • 이를 위해서는 역방향 프록시 계층이 필요합니다.

  • 기존 Amazon ECS 서비스 배포 컨트롤러 및 배포 전략을 업데이트해야 하므로 마이그레이션 절차가 더 복잡합니다.

  • 중단이 최소화됩니다. Elastic Load Balancing 포트 스왑 중에만 발생합니다.

  • 롤백하려면 프록시 구성 변경 내용을 되돌려야 합니다.

  • 병렬 구성이기 때문에 위험이 낮습니다. 따라서 트래픽 전환 전에 테스트할 수 있습니다.

  1. 기존 CodeDeploy 설정을 수정하지 마세요(로드 밸런서, 리스너, 대상 그룹, Amazon ECS 서비스 및 CodeDeploy 배포 그룹).

  2. Amazon ECS 블루/그린 배포에 대해 구성된 새 로드 밸런서, 대상 그룹 및 리스너를 생성하세요.

    적절한 리소스를 구성합니다.

  3. ECS를 배포 컨트롤러로 사용하고 BLUE_GREEN을 배포 전략으로 사용하여 새 로드 밸런서 리소스를 가리키는 새 서비스를 생성하세요.

  4. 새 로드 밸런서를 통해 테스트하여 새 설정을 확인하세요.

  5. 트래픽을 새 로드 밸런서로 라우팅하도록 역방향 프록시 구성을 업데이트하세요.

  6. 새 서비스 개정을 관찰하고 모든 것이 예상대로 계속 작동하면 CodeDeploy 설정을 삭제하세요.

다음 단계

Amazon ECS 블루/그린 배포로 마이그레이션한 후:

  • CodeDeploy UpdateService API 대신 Amazon ECS CreateDeployment API를 사용하도록 배포 스크립트 및 CI/CD 파이프라인을 업데이트합니다.

  • CodeDeploy 배포 대신 Amazon ECS 서비스 배포를 추적하도록 모니터링 및 알림을 업데이트합니다.

  • 새 배포 프로세스의 자동화된 테스트를 구현하여 예상대로 작동하는지 확인합니다.