개요

안면 창백, 큰 트러블을 일으켰습니다.
비슷한 것을 다른 사람에게도 일어나지 않도록 메모로 남겨 둡니다.

무엇이 있었는지

경고가 너무 많아 사이트에 503 오류로 사이트를 열 수 없습니다!

무엇이 일어나고 있는지 AWS 콘솔에서 EC2 인스턴스 확인

공포! ! ! ! 인스턴스가 시작하고 즉시 종료하고 시작하고 즉시 종료하고 무한 루프. . . . 심호흡. 침착하자 (캡처에서 볼 수 있듯이 스크롤 막대가 표시되고 숨겨질 정도로 terminated 인스턴스가 있습니다)

우선, 급속 접속이 가능한 상태로 하는 최단의 대책을 생각한다

EC2 Auto Scaling이 왜 시작되고 실패하는지 확인합니다

대응

4. 급거 접속이 가능한 상태로 하는 최단의 대책을 생각한다

그리고 갑자기 AMI에서 인스턴스를 단독으로 시작하고 최신 소스 코드를 반영하여 ALB에 연결했습니다.

이것으로 일단 연결할 수없는 문제는 면제되었습니다.

여기서 더 진정하고 대응을 하기 위해 커피를 마셨습니다 (아무래도 좋다)

5. EC2 Auto Scaling이 왜 시작되고 실패하는지 확인하십시오.

우선 여러가지 간략화한 그림이지만 이하와 같은 서버 구성도로 되어 있다(EC2는 최소 2대의 구성)



우선, 처음에 STATUS 체크 faild 가 되고 있는 인스턴스가 2대 존재하고 있었다.
그로부터 EC2 Auto Scaling이 인스턴스를 최소 2대 구성으로 되돌리려고 노력했다.

그냥 시작하고 시작할 수없는 즉시 종료하고 반복합니다.
이 원인을 보기 위해 Auto Scaling 그룹의 활동을 검토한 결과 다음과 같은 로그를 대량으로 확인했습니다.

Cancelled
Launching a new EC2 instance: i-xxxxx. Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token 8xxxxxx was abandoned: Lifecycle Action Completed with ABANDON Result

Lifecycle Action이 실패한 것 같습니다.

Lifecycle Action에서 움직이는 것은 최신 소스 코드를 반영하기 위해 CodeDeploy이다.
로그를 보자.



뭐야? 대량의 실패 폭풍이.

이제 개별 로그의 내용을 조금 자세히 살펴보면.



CodeDeploy의 DownloadBundle 이벤트에서 UnKnownError



또한
The specified key does not exist.
그리고 표시됩니다.

CodeDeploy는 이전에 배포 한 최신 소스 코드를 S3에서 가져 왔지만 존재하지 않는다는 것 같습니다.

분명히 URL이 열리면 소스 코드 파일이 S3에 없습니다. . .



조금 기다려.
나, CodePipeline 의 소스 코드의 S3 의 버킷, GitHub 로 관리하고 있기 때문에, 30 일전의 소스 코드는 필요하지 않으면,
라이프 사이클 규칙으로 삭제하도록 설정했습니다. .
이 사이트에서 배포한 2개월 이상 전이고, 그것이다! ! !

그래서 라이프 사이클 규칙을 지우고 자동 스케일링 그룹을 다시 만들어 해결.

덧붙여서, 같은 파일명으로 최신의 소스 코드를 S3에 배치하면 움직이지 않겠지? 시도해 보았습니다.



etag가 일치하지 않으면 오류가 발생했습니다. 맞습니다. 제대로 밸리데이션 해 주셔서 대단합니다.

결론

트러블이 일어났을 때는 커피를 마시는 것이 아니라 일단 침착해 생각한다.
Amazon EC2 Auto Scaling에서 Lifecycle Action에 CodeDeploy를 정의한 경우 S3에 저장된 소스 코드는 라이프사이클 규칙에서 제거해야 합니다.