ElasticBeanstalk + GithubAction Deployment failed: Error 해결

GithunAction + ElasticBeanstalk 조합으로 서버 코드 배포 자동화를 해놨는데, 이게 간헐적으로(매우 높은 확률로) 아래와 같이 흘러가다가 GithubAction 상에서 에러로 남아 있는게 아닌가..!

Warning: Environment update finished, but health is Red and health status is Degraded. Giving it 30 seconds to recover...
01:27:22 INFO: New application version was deployed to running EC2 instances.
01:27:22 INFO: Environment update completed successfully.
Warning: Environment still has health: Red and health status Degraded. Waiting 19 more seconds before failing...
Warning: Environment still has health: Red and health status Degraded. Waiting 8 more seconds before failing...
Error: Deployment failed: Error: Environment still has health Red 30 seconds after update finished!

 

GithubAction 상에는 에러로 남아있지만 실제로 ElasticBeanstalk을 들어가보면 아래와 같이 정상적으로 배포가 되었음을 볼 수 있었다.

 

이게 가만히 생각해보니, 서버의 개발된 내용이 많아지면 많아질수록 더욱 실패하는 상황인것으로 보였고, 더군다나 SpringBoot의 경우 특히 배포 초기에 데이터베이스 연결, JPA 엔티티 스캔, 의존성 주입등 많은 초기화 작업을 수행하기 때문에 시작 시간이 점점 길어지면서 이런 현상또한 더욱 높은 빈도로 발생하는게 아닐까? 라는 생각이 들었다. 

 

더군다나 로그를 보면 헬스체크가 정상적으로 되길 기다리는 시간이 30초 밖에 주어지지 않는데 너무짠게 아닌가? 라는 생각이 들었다.

Warning: Environment update finished, but health is Red and health status is Degraded. Giving it 30 seconds to recover...

스프링을 무시하냐!

 

현재 github action 내용중 ElasticBeanstalk 관련된 부분은 아래와 같았는데, 

- name: Deploy to AWS ElasticBeanstalk # Beanstalk 플러그인을 사용하는 코드입니다. 깃헙에 생성해둔 IAM 키를 사용합니다.
  uses: einaregilsson/beanstalk-deploy@v21
  with:
    aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    application_name: rich-api-service
    environment_name: rich-api-service
    version_label: github-action-${{steps.current-time.outputs.formattedTime}}
    region: ap-northeast-2
    deployment_package: deploy/deploy.zip

 

여기서 헬스체크를 기다리는 시간인 recover 타임을 조금더 늘릴 방법이 없을까 하고 찾아보니 방법이 있었다.

https://github.com/einaregilsson/beanstalk-deploy

GitHub - einaregilsson/beanstalk-deploy: GitHub action (and command line script) to deploy apps to Elastic Beanstalk

wait_for_environment_recovery 설정 값을 추가하면 된다고 적혀 있고, 기본 값은 30sec으로 잡혀있는 것을 확인.

넉넉히 180초로 증가 시켜서 다시 배포해보았다.

 

그 결과는??

recovery 시간을 증가시켰더니 그 이후로는 실패가 되지 않는 것을 확인했다. 

근본적으로는 서버 최적화를 통해 30초안에 모든게 해결되면 더욱 좋겠지만, 우선 당장눈에 가시(?)를 없애고 차근차근 해결 하는 방법으로 위 방법을 써봐도 좋을것 같다.