저번 글 에서 Blue/Green 배포가 무엇인지를 배웠습니다. 이번 글에서는 CodeDeploy 배포 방식 중에 하나인 현재 위치 배포 방식으로 실습을 진행해보겠습니다.
현재 위치 배포가 무엇인지 잘 모르겠다면 여기 를 읽고 오시면 됩니다.
이번 글은 저번 글 에서 다루고 있는 내용과 비슷한 부분이 있기 때문에 저번 글을 먼저 읽고 오시는 걸 추천드립니다.
Spring BootTravis CICodeDeployS3Auto-ScalingLoad-BalancerGithub
이번 글에서 해보려는 아키텍쳐는 위와 같습니다. 즉, Auto-Scaling-Group을 2개를 만들고 각각의 그룹 안에 EC2 인스턴스 2개를 생성할 것입니다. 그리고 각각의 Auto-Scaling-Group을 로드 밸런서의 Target-Group 이랑 연결할 것입니다.
이제 바로 실습을 진행해보겠습니다.
EC2 초기 세팅을 한 후에 AMI를 만들겠습니다.(기본적으로 CodeAgent, Java 11은 설치되었다고 가정하겠습니다.)
Spring Boot 프로젝트에서 위와 같이 간단한 Controller를 세팅한 후에 jar 파일을 만들겠습니다.
./gradlew clean build
그러면 위와 같이 jar 파일이 만들어집니다. 이것을 AMI를 만들 때 쓰일 EC2 인스턴스로 옮기겠습니다. (저는 Filezila를 사용해서 옮기겠습니다.)
EC2에 위와 같이 jar 파일을 옮겼습니다. 그리고 app 디렉토리가 보입니다. 이것은 S3에 존재하는 파일들을 CodeAgent가 EC2로 가져올 때 목적지를 정하기 위해서 임시로 만든 디렉토리입니다.
위와 같이 /home/ec2-user/app/step3의 경로로 디렉토리를 만들겠습니다.
EC2 인스턴스가 재부팅 될 때마다 jar를 실행하는 명령어를 수행하도록 설정을 하겠습니다.
sudo vi /etc/rc.d/rc.local
들어가면 위와 같이 뜰 것입니다. 여기는 EC2 인스턴스가 부팅될 때 실행되는 명령어들을 설정할 수 있습니다. 위의 영어를 읽어보면 알 수 있지만 다 적은 후에 마지막에 chmod +x /etc/rc.d/rc.local을 꼭 해주어야 한다고 나와있습니다.
일단 여기서 jar를 실행시키는 명령어를 적겠습니다.
cd /home/ec2-user/
nohup java -jar *.jar &
그리고 rc.local 파일에 권한 부여를 하겠습니다. (필수 !!)
chmod +x /etc/rc.d/rc.local
위와 같이 초록색으로 바뀌었으면 권한 부여가 잘 된 것입니다.
기본적으로 CodeAgent, Java, Linux 명령어 세팅, jar 파일 존재와 같은 설정들이 되어 있는 상태로 AMI를 만들어야 합니다.
이미지로 만들고자 하는 인스턴스를 선택하고 오른쪽 마우스 클릭 후에 위와 같이 이미지 생성을 하겠습니다.
시간이 조금 걸리기는 하지만 위와 같이 AMI 이미지가 잘 만들어진 것을 볼 수 있습니다.
EC2 탭에 들어가면 왼쪽에 시작 템플릿이 존재합니다. Auto-Scaling 그룹이 인스턴스를 만들 때 시작 템플릿 기반으로 설정된 것을 기반으로 EC2 인스턴스를 만들게 됩니다.
위에서 만든 이미지 선택, 프리티어 용도인 t2.miro, 본인이 원하는 키 페어를 선택하겠습니다.
해당 보안 그룹은 꼭! 최소 8080은 열려있는 보안 그룹이어야 합니다.
그리고 위의 인스턴스 프로파일 설정은 중요합니다. 위와 같이 설정을 해주어야 Auto-Scaling을 통해 만들어진 인스턴스도 해당 역할을 가지고 만들어집니다. (자세한 내용은 참고하기 에서 확인하시면 됩니다.)
Application Load Balancer를 선택하겠습니다.
현재 테스트에서는 HTTPS는 사용하지 않고 HTTP로만 할 것이기 때문에 위와 같이 체크하겠습니다.
위와 같이 가용 영역은 모두 체크를 하고 다음으로 넘어가겠습니다. 그리고 보안그룹은 80, 8080이 열려 있도록 만들겠습니다. (원하는 형태의 보안그룹을 만들어서 사용하면 됩니다.)
대상그룹의 포트는 대상 그룹 내 인스턴스로 로드밸런싱을 할 때 해당 포트로 트래픽을 보낸다는 뜻입니다.상태 검사는 주기적으로 로드밸런스가 대상그룹 내 인스턴스들에게 요청을 보내 확인하는 경로입니다.
정상 임계값: 연속으로 몇 번 정상 응답을 해야만 정상 상태로 볼 것인지 지정하는 항목비정상 임계값: 연속으로 몇 번 비정상 응답을 해야만 정상 상태로 볼 것인지 지정하는 항목제한 시간: 타임아웃 시간으로 응답이 몇 초 이내로 오지 않을 경우 비정상 응답으로 판단할지 지정하는 항목간격: 몇 초 간격으로 인스턴스의 상태를 물어볼지 지정하는 항목
위와 같이 값을 작게 설정 해주어야 CodeDeploy 배포 과정인 AllowTraffic 구간에서 빠르게 진행될 수 있습니다. 그리고 다음 대상 등록에서는 인스턴스를 지금 등록하지 않고 Auto-Scaling 그룹을 만들면서 자동으로 등록되게 할 것이니 일단 넘어가겠습니다.
위에서 새 대상 그룹을 지정해서 만들기 때문에 로드밸런서를 만들 때 대상 그룹이 하나 같이 만들어집니다.(Target-Group의 Healthy Check는 8080 포트에 root 경로로 지정하겠습니다.)
두 번째 대상 그룹도 8080 포트 인스턴스들에게 보내기 위해서 위와 같이 설정하겠습니다.
그리고 두 번째 대상 그룹은 root 경로가 아닌 /test로 Health Check 경로를 설정하겠습니다. 그리고 다음에 인스턴스는 등록하지 않고 대상 그룹 생성을 하겠습니다.
그러면 위와 같이 Target-Group-B는 로드 밸런서와 연결이 되어 있지 않습니다. 로드 밸런서와 연결하는 작업을 하겠습니다.
로드 밸런서 탭에 들어온 후에 위의 순서대로 클릭을 하겠습니다.
위와 같이 트래픽은 50% : 50%로 분배될 수 있도록 설정하고 업데이트를 클릭하겠습니다.
Auto-Scaling Group 2개를 만들겠습니다.
그 다음 뷰에서는 시작 템플릿 준수, 모든 서브넷 체크 후에 다음으로 넘어가겠습니다.
위에서 만든 로드밸런싱 타겟 그룹을 지정하고 다음으로 넘어가겠습니다. 첫번 째 Auto-Scaling Group은 Target-Group에다 연결하겠습니다.
저는 인스턴스 2개로 유지할 것이기 때문에 용량을 모두 2로 설정하고 게속 다음을 누른 후에 Auto-Scaling-Group을 만들겠습니다.
그러면 위에서 적정 용량, 최소 용량, 최대 용량을 모두 2로 지정했기 때문에 인스턴스가 2개가 시작 템플릿 설정에 맞춰서 자동으로 생성되고 있는 것을 볼 수 있습니다. 그리고 로드밸런서 타겟그룹에 가서 연결이 잘 되었는지 확인 해보겠습니다.
위와 같이 8080 포트가 Healthy 상태인 것도 확인할 수 있습니다. 이제 자동화 배포를 하기 위해서 CodeDeploy를 설정해보겠습니다.
위와 같이 두 번째 Auto-Scaling Group에는 두 번째 대상 그룹을 지정하고 나머지는 첫 번째 그룹과 다 똑같이 만들겠습니다.
위와 같이 4개의 인스턴스가 모두 Healthy 상태인 것을 확인할 수 있습니다.
여기서 서비스 역할을 정하는데 이것은 참고하기 을 참고하시길 바랍니다.(역할 매우 중요합니다!! 설정을 제대로 하지 않으면 작동하지 않습니다 ㅠㅠ)
일단은 체크하지 않고 만들어보겠습니다. (체크 하고 안하고의 차이가 좀 애매한데 좀 더 공부해봐야 겠습니다.)
자동화 배포는 위에서 말했던 것처럼 Spring Boot, Travis CI, S3, CodeDeploy, Load-Balancer, Auto-Scaling-Group을 사용할 것입니다. 또한 자동화 배포를 하려면 appspec.yml, deploy.sh, travis.yml 파일들을 작성해야 하는데 그러한 내용은 Blue/Greeen 자동화 배포 에서 다뤘기 때문에 해당 링크에서 참고하시면 됩니다. (똑같이 진행하겠습니다.)
위와 같이 간단하게 수정을 한 후에 Github Push를 해보겠습니다. 그러면 Blue/Green 배포 방식과는 다르게 인스턴스를 줄이거나 생성하는 과정이 없기 때문에 상당히 빠른 시간에 배포가 진행되는 것을 볼 수 있습니다.
Travis CI, CodeDeploy 모두 성공한 것을 볼 수 있습니다. 이제 로드밸런서 DNS 주소로 접속해보겠습니다.
그러면 위와 같이 배포에 성공한 것을 볼 수 있습니다.