Luvpli 배포 자동화 과정

배포 자동화 과정

배포 자동화에는 AWS에서 제공하는 CodePipeline을 사용했다.

배포 자동화 Pipeline의 3가지 단계

1. Source 단계
   원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행
2. Build 단계
   Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공
   Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행
3. Deploy 단계
   Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행

배포 실패했을 때 로그 보는 방법

EC2 애플리케이션에서 배포를 여러 번 해봤기 때문에 build까지는 아무런 문제가 없었다. 그런데 Deploy 과정에서 뜬금없이 실패...

CodeDeploy에서 보기를 클릭하면 Pipeline의 진행상황, 로그를 확인할 수 있다.(Source, Build도 포함)

View events를 통해 실패메시지를 확인할 수 있었다. "codedeploy agent was not able to receive the lifecycle event. check the codedeploy agent logs on your host and make sure the agent is running and can connect to the codedeploy server."
CodeDeploy 에이전트가 실행중인지 확인하라는 메시지였는데 EC2에서 CodeDeploy는 실행 중인 것을 확인했고 역할부여에도 문제는 없었다. CodeDeploy 에이전트가 실행 된 지 1주일도 넘은 상태여서 다음 명령어로 재시작했더니 이 문제는 해결됐다.

sudo service codedeploy-agent restart

배포 시간 단축

이 후 과정은 아무런 문제 없이 배포에 성공했다. 다만 커밋을 할 때마다 적용이 되기까지 10분 정도의 시간이 걸리는 것이 마음에 걸렸다.

로그를 확인해보니 Deploy과정에서 BlockTraffic, AllowTraffic에서 가장 많은 시간이 소요되고 있었다.

1. AllowTraffic
   2분 30초의 시간이 걸렸는데 원인은 Target Group에서 Health Check가 오래 걸리기 때문이다. 로드밸런서의 Target Group에 들어가보면 다음과 같은 설정이 되어있었다.
   
   Healthy threshold의 수치 5번 체크를 하고 그 간격(Interval)은 30초라서 2분 30초의 시간이 걸린 것이다. 이 것을 단축하기 위해 각각 2 / 15 로 수치를 번경했다.
   

2. BlockTraffic
   마찬 가지로 Target Group의 Attributes에서 조정할 수 있다. Deregistration delay를 300초에서 60초로 변경했다.
   
   

위와 같이 커밋을 배포에 적용하는 시간이 대폭 줄어들었다. 하지만 검사 횟수와 간격을 단축했기 때문에 안정성에는 문제가 생길 수도 있다. 커밋을 자주하는 개발단계에서는 이처럼 하고 서비스를 제공할 때는 Defalut 값을 사용하는 것이 좋겠다.