Amazon EC2 Auto Scaling 문제 해결

1. 다음 중 하나를 수행합니다.

   • delete-deployment-group 명령을 호출하여 하트비트 제한 시간을 발생시키는 Auto Scaling 그룹과 연결된 배포 그룹을 삭제합니다.

   • Auto Scaling 그룹 이름의 빈 목록이 null이 아닌 update-deployment-group 명령을 호출하여 CodeDeploy관리형 Auto Scaling 수명 주기 후크를 모두 분리합니다.

     예를 들어 다음 AWS CLI 명령을 입력합니다.

     aws deploy update-deployment-group --application-name my-example-app --current-deployment-group-name my-deployment-group --auto-scaling-groups

     또 다른 예로 Java와 함께 를 CodeDeploy API 사용하는 경우 를 호출UpdateDeploymentGroup하고 autoScalingGroups로 설정합니다new ArrayList<String>(). 이것은 autoScalingGroups를 빈 목록으로 설정하고 기존 목록을 제거합니다. 기본값으로 null을 사용하지 마세요. 이렇게 하면 autoScalingGroups가 원하는 대로 유지되지 않기 때문입니다.

   호출의 출력을 검사합니다. 출력에 Amazon EC2 Auto Scaling 수명 주기 후크 목록이 있는 hooksNotCleanedUp 구조가 포함된 경우 남은 수명 주기 후크가 있습니다.

2. describe-lifecycle-hooks 명령을 호출하여 시작에 실패한 EC2 인스턴스와 연결된 Amazon EC2 Auto Scaling 그룹의 이름을 지정합니다. 출력에서 다음 중 하나를 찾습니다.

   • 1단계에서 식별한 hooksNotCleanedUp 구조에 해당하는 Amazon EC2 Auto Scaling 수명 주기 후크 이름입니다.

   • 실패하는 EC2 Auto Scaling 그룹과 연결된 배포 그룹의 이름이 포함된 Amazon Auto Scaling 수명 주기 후크 이름입니다.

   • CodeDeploy 배포에 하트비트 제한 시간이 발생했을 수 있는 Amazon EC2 Auto Scaling 수명 주기 후크 이름입니다.

3. 후크가 2단계에 나열된 범주 중 하나에 속하는 경우 delete-lifecycle-hook 명령을 호출하여 삭제합니다. 통화에서 Amazon EC2 Auto Scaling 그룹 및 수명 주기 후크를 지정합니다.

   중요

   2단계에서 설명한 대로 문제를 일으키는 후크만 삭제합니다. 실행 가능한 후크를 삭제하면 배포가 실패하거나 애플리케이션 개정을 배포하여 EC2 인스턴스를 확장하지 못할 CodeDeploy 수 있습니다.

4. 원하는 Auto Scaling 그룹 이름으로 update-deployment-group 또는 create-deployment-group 명령을 호출합니다. CodeDeploy 는 새 로 Auto Scaling 후크를 다시 설치합니다UUIDs.

1. describe-lifecycle-hooks 명령을 호출하여 에서 배포 그룹과 연결된 Amazon EC2 Auto Scaling 그룹의 이름을 지정합니다 CodeDeploy. 출력의 LifecycleHooks 목록에서 각 LifecycleHookName 값을 기록합니다.

2. get-deployment-group 명령을 호출하여 Amazon EC2 Auto Scaling 그룹과 연결된 배포 그룹의 이름을 지정합니다. 출력의 autoScalingGroups 목록에서 이름 값이 Amazon EC2 Auto Scaling 그룹 이름과 일치하는 각 항목을 찾은 다음 해당 hook 값을 기록해 둡니다.

1. get-deployment-group 명령 출력에 없는 수명 주기 후크 이름이 describe-lifecycle-hooks 명령 출력에 있으면 다음과 같이 합니다.

   1. describe-lifecycle-hooks 명령 출력의 각 수명 주기 후크 이름에 대해 delete-lifecycle-hook 명령을 호출합니다.

   2. 명령을 호출하여 원래 Amazon EC2 Auto Scaling 그룹의 이름을 update-deployment-group 지정합니다. 는 Amazon EC2 Auto Scaling 그룹에서 새 대체 수명 주기 후크를 CodeDeploy 생성하고 수명 주기 후크를 배포 그룹과 연결합니다. 이제 Amazon EC2 Auto Scaling 그룹에 새 인스턴스가 추가되면 자동 배포가 재개됩니다.

2. describe-lifecycle-hooks 명령 출력에 없는 수명 주기 후크 이름이 get-deployment-group 명령 출력에 있으면 다음과 같이 합니다.

   1. update-deployment-group 명령을 호출하지만 원래 Amazon EC2 Auto Scaling 그룹의 이름은 지정하지 않습니다.

   2. update-deployment-group 명령을 다시 호출하지만 이번에는 원래 Amazon EC2 Auto Scaling 그룹의 이름을 지정합니다. 는 Amazon EC2 Auto Scaling 그룹에서 누락된 수명 주기 후크를 CodeDeploy 다시 생성합니다. 이제 Amazon EC2 Auto Scaling 그룹에 새 인스턴스가 추가되면 자동 배포가 재개됩니다.

InService 상태에 인스턴스가 없는 경우 오류를 해결하려면

1. Amazon EC2 콘솔에서 원하는 용량 설정을 확인합니다. 값이 0이면 양수로 설정합니다. 인스턴스가 InService 상태가 되어 배포가 성공할 때까지 기다립니다. 문제를 해결했으면 이 문제 해결 절차의 나머지 단계를 건너뛸 수 있습니다. 원하는 용량 설정에 대한 자세한 내용은 Amazon Auto Scaling 사용 설명서의 Auto Scaling 그룹에서 용량 제한 설정을 참조하세요. EC2 Auto Scaling

2. Auto Scaling이 원하는 용량을 충족하기 위해 새 EC2 인스턴스를 계속 시작하려고 하지만 스케일 아웃을 수행할 수 없는 경우 일반적으로 Auto Scaling 수명 주기 후크가 실패하기 때문입니다. 이 문제는 다음과 같이 해결합니다.

   1. 어떤 Auto Scaling 수명 주기 후크 이벤트가 실패하는지 확인하려면 Amazon Auto Auto Scaling 사용 설명서의 Auto Scaling 그룹에 대한 조정 활동 확인을 참조하세요. EC2 Auto Scaling

   2. 실패한 후크의 이름이 인 경우 로 CodeDeploy-managed-automatic-launch-deployment-hook-DEPLOYMENT_GROUP_NAME이동하여 배포 그룹을 CodeDeploy찾은 다음 Auto Scaling 으로 시작된 실패한 배포를 찾습니다. 그런 다음 배포에 실패한 이유를 조사합니다.

   3. 배포가 실패한 이유(예: CloudWatch 경보 발생)를 이해하고 개정을 변경하지 않고도 문제를 해결할 수 있는 경우 지금 수행합니다.

   4. 조사 후 CodeDeploy의 마지막으로 성공한 개정이 더 이상 정상이 아닌 것으로 확인되고 Auto Scaling 그룹에 정상 인스턴스가 없는 경우 배포 교착 상태 시나리오에 있는 것입니다. 이 문제를 해결하려면 Auto Scaling 그룹에서 CodeDeploy의 수명 주기 후크를 일시적으로 제거한 다음 후크를 다시 설치하고 새 (좋은) 개정 CodeDeploy 을 다시 배포하여 잘못된 개정을 수정해야 합니다. 지침은 다음 섹션을 참조하세요.

      • To fix the deployment deadlock issue (CLI)

      • To fix the deployment deadlock issue (console)

배포 교착 상태 문제를 해결하려면(CLI)

1. (선택 사항) 이 문제를 해결하는 동안 예기치 않은 배포가 발생하지 않도록 CodeDeploy 오류를 유발하는 CI/CD 파이프라인을 차단합니다.

2. 현재 Auto Scaling DesiredCapacity 설정을 기록해 둡니다.

   aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name ASG_NAME

   이 절차의 끝부분에서 이 숫자로 다시 크기를 조정해야 할 수도 있습니다.

3. Auto Scaling DesiredCapacity 설정을 로 설정합니다1. 원하는 용량이 1보다 큰 경우 시작할 수 있는 선택 사항입니다 이 설정을 1로 줄이면 인스턴스가 나중에 프로비저닝하고 배포하는 데 걸리는 시간이 단축되어 문제 해결 속도가 빨라집니다. Auto Scaling에서 원하는 용량이 원래대로 0으로 설정된 경우, 1로 늘려야 합니다. 이 변경은 필수입니다.

   aws 오토스케일링 set-desired-capacity --auto-scaling-group-name ASG_NAME --원하는 용량 1

   참고

   이 절차의 나머지 단계에서는 를 DesiredCapacity로 설정했다고 가정합니다1.

   이때 Auto Scaling은 하나의 인스턴스로 크기를 조정하려고 시도합니다. 그런 다음, CodeDeploy 추가한 후크가 여전히 존재하기 때문에 배포를 CodeDeploy 시도하고, 배포가 실패하고, Auto Scaling이 인스턴스를 취소하고, Auto Scaling이 인스턴스를 다시 시작하여 원하는 용량인 1에 도달하려고 하면 다시 실패합니다. 즉, 취소와 재실행이 반복되는 상태인 것입니다.

4. 배포 그룹에서 Auto Scaling 그룹의 등록을 취소합니다.

   주의

   다음 명령은 소프트웨어가 없는 새 EC2 인스턴스를 시작합니다. 명령을 실행하기 전에 소프트웨어를 실행하지 않는 Auto Scaling InService 인스턴스가 허용되는지 확인합니다. 예를 들어, 인스턴스에 연결된 로드 밸런서가 소프트웨어 없이 이 호스트로 트래픽을 전송하지 않는지 확인합니다.

   중요

   아래 표시된 CodeDeploy 명령을 사용하여 후크를 제거합니다. Auto Scaling 서비스를 통해 후크를 제거하지 마세요. 에서 제거를 인식하지 못하기 때문입니다 CodeDeploy.

   aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups

   이 명령을 실행하면 다음과 같은 문제가 발생합니다.

   1. CodeDeploy 배포 그룹에서 Auto Scaling 그룹의 등록을 취소합니다.

   2. CodeDeploy 는 Auto Scaling 그룹에서 Auto Scaling 수명 주기 후크를 제거합니다.

   3. 배포 실패를 야기한 후크가 더 이상 존재하지 않으므로 Auto Scaling은 기존 EC2 인스턴스를 취소하고 즉시 새 인스턴스를 시작하여 원하는 용량으로 확장합니다. 새 인스턴스 곧 InService 상태로 변경됩니다. 새 인스턴스에는 소프트웨어가 포함되어 있지 않습니다.

5. EC2 인스턴스가 InService 상태가 될 때까지 기다립니다. 이를 확인하려면 다음 명령을 사용합니다.

   aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names ASG_NAME --query AutoScalingGroups[0].Instances[*].LifecycleState

6. EC2 인스턴스에 후크를 다시 추가합니다.

   중요

   아래 표시된 CodeDeploy 명령을 사용하여 후크를 추가합니다. 에서 추가를 인식하지 못하므로 Auto Scaling 서비스를 사용하여 후크를 추가하지 마세요 CodeDeploy.

   aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups ASG_NAME

   이 명령을 실행하면 다음과 같은 문제가 발생합니다.

   1. CodeDeploy Auto Scaling 수명 주기 후크를 EC2 인스턴스에 다시 설치합니다.

   2. CodeDeploy 는 Auto Scaling 그룹을 배포 그룹에 다시 등록합니다.

7. Amazon S3 또는 GitHub 수정 버전으로 플릿 전체 배포를 생성합니다. 이 배포는 정상 상태이며 사용하려는 것으로 알고 있습니다.

   예를 들어 개정이 httpd_app.zip 객체 키를 사용하여 my-revision-bucket을 호출하는 Amazon S3 버킷의 .zip 파일인 경우 다음 명령을 입력합니다.

   aws deploy create-deployment --application-name APPLICATION_NAME --deployment-group-name DEPLOYMENT_GROUP_NAME --revision "revisionType=S3,s3Location={bucket=my-revision-bucket,bundleType=zip,key=httpd_app.zip}"

   이제 InService 인스턴스 1개가 Auto Scaling 그룹에 있으므로 배포는 정상 작동하며 더 이상 배포 그룹에 대한 인스턴스를 찾을 수 없어서 배포에 실패했습니다 오류가 표시되지 않습니다.

8. 다음은 이전에 Auto Scaling 그룹을 크기 조정한 경우, 배포가 성공한 후 원래 용량으로 다시 조정하는 방법입니다.

   aws autoscaling set-desired-capacity --auto-scaling-group-name ASG_NAME --desired-capacity ORIGINAL_CAPACITY

배포 교착 상태 문제를 해결하려면 (콘솔)

1. (선택 사항) 이 문제를 해결하는 동안 예기치 않은 배포가 발생하지 않도록 CodeDeploy 오류를 유발하는 CI/CD 파이프라인을 차단합니다.

2. Amazon EC2 콘솔로 이동하여 Auto Scaling Desired 용량 설정을 기록해 둡니다. 이 절차의 끝부분에서 이 숫자로 다시 크기를 조정해야 할 수도 있습니다. 이 설정을 찾는 방법에 대한 자세한 내용은 Auto Scaling 그룹의 용량 제한 설정을 참조하세요.

3. 원하는 EC2 인스턴스 수를 로 설정합니다1.

   원하는 용량이 1보다 큰 경우 시작할 수 있는 선택 사항입니다 이 설정을 1로 줄이면 인스턴스가 나중에 프로비저닝하고 배포하는 데 걸리는 시간이 단축되어 문제 해결 속도가 빨라집니다. Auto Scaling에 대해 원하는 용량(Desired capacity)이 원래 0으로 설정되어 있었다면 1로 늘려야 합니다. 이 변경은 필수입니다.

   참고

   이 절차의 나머지 단계에서는 원하는 용량(Desired capacity)을 1로 설정했다고 가정합니다.

   1. 에서 Amazon EC2 콘솔을 열고 탐색 창에서 Auto Scaling Groups를 https://console.aws.amazon.com/ec2/선택합니다.

   2. 해당 리전을 선택합니다.

   3. 문제가 있는 Auto Scaling 그룹으로 이동합니다.

   4. 일반 세부 정보(General details)에서 편집(Edit)을 선택합니다.

   5. 원하는 용량(Desired capacity)을 1로 설정합니다.

   6. 업데이트를 선택합니다.

4. 배포 그룹에서 Auto Scaling 그룹의 등록을 취소합니다.

   주의

   다음 하위 단계는 소프트웨어가 없는 새 EC2 인스턴스를 시작합니다. 명령을 실행하기 전에 소프트웨어를 실행하지 않는 Auto Scaling InService 인스턴스가 허용되는지 확인합니다. 예를 들어, 인스턴스에 연결된 로드 밸런서가 소프트웨어 없이 이 호스트로 트래픽을 전송하지 않는지 확인합니다.

   1. 에서 CodeDeploy 콘솔을 엽니다https://console.aws.amazon.com/codedeploy/.

   2. 해당 리전을 선택합니다.

   3. 탐색 창에서 애플리케이션을 선택합니다.

   4. CodeDeploy 애플리케이션의 이름을 선택합니다.

   5. CodeDeploy 배포 그룹의 이름을 선택합니다.

   6. 편집을 선택합니다.

   7. 환경 구성 에서 Amazon EC2 Auto Scaling 그룹 을 선택 취소합니다.

      참고

      환경 구성이 정의되어 있지 않으면 콘솔에서 구성을 저장할 수 없습니다. 확인을 우회하려면 호스트로 확인되지 않는 EC2 또는 On-premises 태그를 임시로 추가하세요. 태그를 추가하려면 Amazon EC2 인스턴스 또는 온프레미스 인스턴스 를 선택하고 EC2 또는 의 태그 Key를 추가합니다On-premises. 태그 값(Value)은 비워 둘 수 있습니다.

   8. Save changes(변경 사항 저장)를 선택합니다.

      이러한 하위 단계를 완료한 후 다음과 같은 상황이 발생합니다.

      1. CodeDeploy 배포 그룹에서 Auto Scaling 그룹의 등록을 취소합니다.

      2. CodeDeploy 는 Auto Scaling 그룹에서 Auto Scaling 수명 주기 후크를 제거합니다.

      3. 배포 실패를 야기한 후크가 더 이상 존재하지 않으므로 Auto Scaling은 기존 EC2 인스턴스를 취소하고 즉시 새 인스턴스를 시작하여 원하는 용량으로 확장합니다. 새 인스턴스 곧 InService 상태로 변경됩니다. 새 인스턴스에는 소프트웨어가 포함되어 있지 않습니다.

5. EC2 인스턴스가 InService 상태가 될 때까지 기다립니다. 상태를 확인하는 방법은 다음과 같습니다.

   1. 에서 Amazon EC2 콘솔을 엽니다https://console.aws.amazon.com/ec2/.

   2. 탐색 창에서 Auto Scaling 그룹을 선택합니다.

   3. 사용자의 Auto Scaling 그룹을 선택합니다.

   4. 콘텐츠 창에서 인스턴스 관리(Instance Management) 탭을 선택합니다.

   5. 인스턴스 에서 수명 주기 열이 인스턴스 InService 옆에 표시되는지 확인합니다.

6. Auto Scaling 그룹을 제거하는 데 사용한 것과 동일한 방법을 사용하여 CodeDeploy 배포 그룹에 다시 등록합니다.

   1. 에서 CodeDeploy 콘솔을 엽니다https://console.aws.amazon.com/codedeploy/.

   2. 해당 리전을 선택합니다.

   3. 탐색 창에서 애플리케이션을 선택합니다.

   4. CodeDeploy 애플리케이션의 이름을 선택합니다.

   5. CodeDeploy 배포 그룹의 이름을 선택합니다.

   6. 편집을 선택합니다.

   7. 환경 구성 에서 Amazon EC2 Auto Scaling 그룹을 선택하고 목록에서 Auto Scaling 그룹을 선택합니다.

   8. Amazon EC2 인스턴스 또는 온프레미스 인스턴스에서 추가한 태그를 찾아 제거합니다.

   9. Amazon EC2 인스턴스 또는 온프레미스 인스턴스 옆의 확인란을 선택 취소합니다.

   10. Save changes(변경 사항 저장)를 선택합니다.

   이 구성으로 Auto Scaling 그룹에 수명 주기 후크를 다시 설치합니다.

7. Amazon S3 또는 GitHub 수정 버전으로 플릿 전체 배포를 생성합니다. 이 배포는 정상 상태이며 사용하려는 것으로 알고 있습니다.

   예를 들어 개정이 httpd_app.zip 객체 키를 사용하여 my-revision-bucket을 호출하는 Amazon S3 버킷의 .zip 파일인 경우 다음을 수행합니다.

   1. CodeDeploy 콘솔의 배포 그룹 페이지에서 배포 생성 을 선택합니다.

   2. Revision type(수정 유형)에서 My application is stored in Amazon S3(내 애플리케이션은 Amazon S3에 저장됨)를 선택합니다.

   3. 개정 위치(Revision location)는 s3://my-revision-bucket/httpd_app.zip을 선택합니다.

   4. 개정 파일 형식(Revision file type)은 .zip을 선택합니다.

   5. 배포 만들기를 선택합니다.

   이제 InService 인스턴스 1개가 Auto Scaling 그룹에 있으므로 배포가 정상 작동하며 더 이상 “배포 그룹에 대한 인스턴스를 찾을 수 없어서 배포에 실패했습니다.” 오류가 표시되지 않습니다.

8. 다음은 이전에 Auto Scaling 그룹을 크기 조정한 경우, 배포가 성공한 후 원래 용량으로 다시 조정하는 방법입니다.

   1. 에서 Amazon EC2 콘솔을 열고 탐색 창에서 Auto Scaling Groups를 https://console.aws.amazon.com/ec2/선택합니다.

   2. 해당 리전을 선택합니다.

   3. Auto Scaling 그룹으로 이동합니다.

   4. 일반 세부 정보(General details)에서 편집(Edit)을 선택합니다.

   5. 원하는 용량(Desired capacity)을 원래 값으로 다시 설정합니다.

   6. 업데이트를 선택합니다.