본문 바로가기

CICD/AutoScaling

AWS EC2 AutoScaling 사용하기 - 1. Intro

카테고리가 CICD인데, AutoScaling과 무슨 관계인가? 라는 생각이 드실 수 있습니다.

하지만 AWS에서 AutoScaling과 CICD는 뗄 수 없는 관계입니다.

 

그 과정을 먼저 EC2 부터 살펴보도록 하겠습니다.

먼저 EC2에서 AutoScaling을 구성하는 방법에 대해 알아봅시다.

 

1. 먼저 AMI를 생성해야 합니다.

만약 Spring Boot Jar파일을 실행할 서버라면 이 서비스를 수행하기 위해

JDK 1.8을 꼭 설치해야할 것이며 이 외에도 서비스 운영에 관해 필요한 각 라이브러리나 솔루션들을 서버에 설치해야합니다.

이렇게 서버에 Jar파일만 올려서 돌리면 서비스가 될 수 있도록 세팅이 끝난 서버의 현 시간을 이미지화 해서

해당 상태의 서버를 계속해서 찍어낼 수 있는 것이 AMI 입니다.

 

2. Launch Configuration을 구성합니다 (시작구성)

실제 EC2 서버가 만들어 질 때, 어떠한 AMI, Type, 볼륨의 사이즈, Security Group, Key를 가지고 서버를 만들 것인지

즉, 실제 서버가 실행되는 부분에 대한 세팅을 정의한다고 생각하시면 됩니다.

 

3. 마지막으로 AutoScaling Group을 생성합니다.

위에서 다 세팅된 서버 세팅을 가지고 어떠한 조건에서 오토스케일링을 하여 서버를 만들거나 줄일 것인지 구성하게 됩니다.

일반적으로 오토스케일링 그룹에 있는 CPU Utilization의 평균값을 가지고 부하를 산정하여 서버를 스케일 인 아웃하게 되나,

Cloudwatch에서 지표를 통해 구성한 알람들을 가지고 오토스케일링을 설정 할 수도 있습니다. (메모리 디스크 등)

 

따라서 배포할 때 마다 위의 세팅을 모두 바꿔줄 것이 아니라면,

오토스케일링을 적용한 서버의 경우에는 서버가 새롭게 스케일 아웃 되었을 경우 예전 소스를 가진 서버가 생성되게 됩니다.

따라서 CodeDeploy를 사용하여서 오토스케일링 그룹을 바라보고 있다가 새롭게 서버가 스케일 아웃 되었을 때

가장 최근에 성공한 배포기록을 가지고 자동으로 배포 될 수 있게 서비스를 자동화 시켜놓아야 하는 것입니다.

 

물론 배포할 때 마다 저 세팅을 바꿔 줄 수도 있겠지만, 상당히 많은 시간이 소요될 뿐더러,

서비스 중단이나 세션이 깔끔하게 옮겨질 수 없기 때문에 서비스 사용자가 불편함을 겪을 수 밖에 없습니다.

 

혹은 코드디플로이를 사용하지 않고 유저데이터를 사용하여 쉘 스크립트로 대신 할 수도 있으나,

이 부분 역시 배포에 대한 성공 여부나 에러여부에 대해서 체크할 수 없기 때문에 새로 구축된 서버가 이전 서비스를 수행하면서

장애를 발생시킬 수 있는 부분을 가지고 있기 때문에 사용하지 않는 것이 좋습니다.

 

ECS의 경우에도 Service가 Task Definition에 정의된 컨테이너 버전을 가지고 배포하고,

이 역시 블루그린 배포일 경우 코드디플로이를 통해 배포되기 때문에 자동화 구성이 되어있어야 합니다.

 

EKS는 HPA를 통해 오토스케일링되고 이는 yaml파일을 통해 정의된 대로 구성되기 때문에

수동 배포를 하더라도 서비스 소스관리와 쿠버네티스 인프라 적용에 관한 yaml 소스 관리를 꼼꼼히 해야합니다.

이에 대한 부분을 서비스에 대한 개발 소스 및 인프라에 관한 소스까지 모두 Git에서 운영하는

GitOps 형태의 구성을 가지고 자동화를 하는 방식을 많이 사용합니다.

MSA 형태의 개발 구조에서 수 많은 어플리케이션 소스와 인프라에 적용되어 배포되는 Yaml파일을 관리할 수 있습니다.

Yaml파일에 대한 배포는 각 운영 환경을 나누어 할 경우에는 Spinnaker와 같은 솔루션을 사용할 수 도 있겠지만,

가볍게 혹은 하나의 파드 단위 배포는 ArgoCD를 통해 Sync하는 형태로 구성하면서 진행하는 방식을 많이 사용합니다.

(물론 yaml을 크게 정의한다면, 파드 단위보다 더 크게 운영할 수도 있습니다.)

 

결국 어떠한 오토스케일링이던 각 정의된 세팅을 가지고 진행하기 때문에

해당 세팅을 계속해서 바꿔 주는 작업을 하기 보다는 전체를 자동화 해놓고 알아서 적용되게 끔 구성하는 것이

운영면에서 안정성이나 편리성 모두 가져갈 수 있는 부분입니다.

 

CICD와 AutoScaling의 연관성을 어느정도 이해하셨으리라 생각하며

다음 포스트에서는 EC2 AutoScaling에 대한 부분들을 다뤄보도록 하겠습니다.

'CICD > AutoScaling' 카테고리의 다른 글

AWS EC2 AutoScaling 사용하기 - 2. Hands On  (0) 2020.01.22