Part 13. Auto Scaling

728x90

SMALL

 

Auto Scaling

Auto Scaling은 자동으로 EC2 인스턴스의 개수가 줄거나 늘거나 하는 기능을 말한다. Auto Scaling은 두 가지 경우로 나눌 수 있다.

• Scaling Up/Down: 인스턴스 타입의 크기를 크거나 작게 만드는 경우
• Scaling Out/In: 인스턴스의 개수를 늘리거나 줄이는 경우

Auto Scaling Group

이 Auto Scaling 기능을 이용하기 위해 Auto Scaling Group이 만들어져야 하는데 여기서 최소, 희망, 최대 인스턴스 개수를 설정할 수 있다.

 

그리고 사용자가 설정한 Auto Scaling 조정 정책, 즉 EC2가 감내할 수 있는 부하의 기준을 정하면 인스턴스 개수가 최대 최소의 인스턴스 내에서 자동으로 조절이 된다. 이런 설정을 하는 것이 Auto Scaling Group이라고 보면 된다.

 

 

Launch Template, Golden AMI

Launch Template은 인스턴스를 생성할 때 결정하는 네트워크 정보, 타입, 키페어, AMI(Amazon Machine Image)와 같은 설정값들에 대한 템플릿을 의미한다.

AMI는 인스턴스 생성할 때 지금까지 사용했던 Amazon Linux Image와 같은 그 이미지를 말한다.

 

Auto Scaling Group을 사용할 때 이 Launch Template을 사용해서 추가적으로 생성될 인스턴스를 만들 수 있게 구성할 수 있다. 이 때, Launch Template을 통해서 사용되는 이미지를 Golden AMI라고 한다. 이 Golden AMI는 OS를 포함해서 필요한 필수 패키지들이 설치되어 있는 표준 이미지를 말한다. Golden 이라는 단어의 의미는 딱히 중요하지 않다. 그냥 완성적이고 필수 패키지들이 잘 적용이 된 상태라서 Golden 이라는 이름이 붙어졌다. 이후에 직접 만들어보면서 더 이해를 하겠지만 직접 나만의 이미지를 만들어서 기존에 사용했던 동일한 인스턴스 상태와 환경을 구성할 수 있게 해준다. 그리고 이런 방식이 앞서 얘기한 Immutable Infra를 만들게 해준다.

 

 

Autoscaling Policy

위에서 Auto Scaling 조정 정책이라는 말을 했는데 그것을 알아보자. 이 조정 정책이란 사용자가 "이런 조건에 도달하면 Auto Scaling 기능을 활성화해줘!"라고 정의해놓은 정책을 말한다. 그리고 크게 3가지가 있다.

 

• 단순 조정 정책 (Simple Scaling)
  • Cloudwatch 경보 위반을 기준으로 사용
  • Cloudwatch 경보 발생 시 특정 인스턴스 개수만큼 스케일 인/아웃 설정이 가능
  • 또는 Cloudwatch 경보 발생 시 Auto Scaling Group의 퍼센티지(%)만큼 스케일 인/아웃
  • 단점은 확장에 대한 세분화된 제어를 제공하지 않음
• 대상 추적 조정 정책 (Target Tracking Scaling)
  • Auto Scaling Group이 항상 유지해야 하는 조정 지표 및 지표값을 지정한다. 예를 들어, CPU 80%로 설정하면 항상 그만큼을 유지하도록 자동 스케일 인/아웃 실행
  • 4가지 지표 선택이 가능
    1. ASG Average CPUUtilization: Auto Scaling Group의 평균 CPU 사용률
    2. ASG Average NetworkIn: Auto Scaling Group이 모든 네트워크 인터페이스에서 수신한 평균 바이트 수
    3. ASG Average NetworkOut: Auto Scaling Group이 모든 네트워크 인터페이스에서 보낸 평균 바이트 수
    4. ALB Request CountPerTarget: Auto Scaling Group이 ALB 대상 그룹과 연결된 경우 대상 그룹의 대상 당 완료된 요청 수
• 단계 조정 정책 (Step Scaling)
  • 위 단순 조정 정책의 단점인 세분화된 제어를 보완하기 위한 정책
  • Cloudwatch 경보 위반의 정도에 따라 인스턴스 개수를 단계적으로 조정하는 작업을 설정 가능
  • 단계적 조정을 통해 정책은 경보 위반 이벤트 도중에도 추가 경보에 계속 응답할 수 있게 된다.

단계 조정 정책의 예시

 

 

 

Auto Scaling Group의 Lifecycle

Auto Scaling Group으로 인스턴스를 만들고 지울 때 인스턴스의 생명주기가 있다. 그림을 보자.

 

우선 Auto Scaling Group으로부터 인스턴스가 새로 생성되는 Scale Out일 때 인스턴스 상태는 'Pending'이다. Pending에서 인스턴스가 완전히 띄워졌을 때 'InService'상태가 된다. InService상태에서 Health Check가 실패하거나 Scale In이 될 때 'Terminating'상태가 된다. 이 Terminating에서 완전히 인스턴스가 제거된 상태는 'Terminated'이다.

 

그 외 InService상태에서 인스턴스를 떼어내면 'Detaching'상태가 되고 InService상태에서 인스턴스를 Standby로 설정하면 'EnteringStandby'상태가 된다. 

 

 

Auto Scaling 직접 사용해보기

이제 Auto Scaling 기능을 실제로 사용해보자. 우선 어떤 형태의 모습이 그려질지는 다음과 같다.

 

기존에 가지고 있는 EC2 인스턴스가 있고 그 인스턴스를 가지고 Auto Scaling Group을 만들어서 Launch Template을 만든다. 그리고 정책을 설정해서 정책 조건에 도달하면 자동으로 인스턴스가 늘어나는 모습을 확인할 예정. 앞단에는 LB를 붙여서 인스턴스가 3개가 만들어지면 부하 분산 처리가 잘 되는지도 확인해보자.

 

 

필요한 보안 그룹 생성

위 그림에서 LB가 있다. LB에 관련된 보안 그룹을 먼저 생성하자.

EC2 > Security Groups에서 보안 그룹 생성.

이름과 VPC를 설정하고, 인바운드 규칙에는 80에 모두(0.0.0.0/0)가 들어올 수 있게 설정한다. 이 상태로 생성.

 

이번엔 새로 만들 EC2에 대한 보안 그룹을 생성한다. 위 그림에서 총 3개의 EC2가 있는데 이들의 표본이 될 EC2 하나는 만들어야한다. 그래서 보안 그룹 하나를 더 생성.

 

하단에 보면 3개의 인바운드 규칙이 있다.

22는 우리가 항상 사용하던 OpenVPN으로 SSH 접속할 수 있게 설정

80도 역시 OpenVPN을 통해 접속할 수 있게 설정

80중 또다른 하나는 방금 막 만든 LB 보안 그룹으로 설정

 

 

표본 EC2 생성

위에서 말한 표본 EC2를 생성한다. Name 설정은 자유롭게하고 AMI는 Amazon Linux로 선택, 타입은 디폴트인 t2.micro, 키페어는 계속 사용해왔던 키페어로 선택, 네트워크 설정에서는 계속 사용했던 VPC, Private Subnet App A로 하고 보안 그룹은 방금 만든 보안 그룹을 선택하고 생성한다. (이제 EC2 만드는 건 이렇게 말로만 하겠다.)

 

이제 OpenVPN에 접속해서 이 방금 만든 EC2를 SSH로 접속하자. 접속했으면 여기에 필요한 패키지들을 설치해야 한다. 그것들을 정리한 README.md 파일 경로는 다음과 같다.

GitHub - chyoni/aws-ec2meta-webpage: Auto Scaling 공부용 EC2 웹 페이지

 

README.md에 적힌 필요 패키지들이다.

sudo -s
sudo yum -y install httpd php git
dnf -y localinstall https://dev.mysql.com/get/mysql80-community-release-el9-4.noarch.rpm
dnf -y install mysql mysql-community-client
sudo systemctl start httpd
sudo systemctl enable httpd
sudo cd /var/www/html/ && sudo git clone https://github.com/chyoni/aws-ec2meta-webpage.git

 

제일 마지막 소스를 내려받았으면 httpd를 restart해주자.

systemctl restart httpd

 

이제 EC2의 프라이빗 IP를 통해 Clone받은 웹 페이지가 잘 출력되는지 확인해보자.

http://ec2-private-ip/aws-ec2meta-webpage/index.php

 

다음과 같은 화면이 나오면 된다.

 

표본 EC2로 AMI 만들기

이제 우리가 만든 EC2로 필요 패키지들과 설정까지 다 끝냈으니 이 EC2로 AMI를 만들어보자.

표본 EC2를 선택한 후 Actions > Image and templates > Create image 선택

 

거의 다 기본값 설정으로 만드는데 이미지 이름과 설명은 작성해주고, No reboot에 Enable 체크를 해줘야한다. 이건 이 이미지를 만들 때 체크를 안하면 해당 EC2가 재부팅이 된다. 그것을 안하고자 체크하고 이미지 생성

 

이제 잘 만들어졌는지 확인해보자. EC2 > Images > AMIs 가보면 방금 만든 이미지가 생성중인 모습을 확인할 수 있다. 

 

 

만든 AMI로 Launch Template 생성

AMI를 가지고 Launch Template을 만들어보자.

EC2 > Instances > Launch Templates에서 'Create launch template' 클릭

 

Name, Description을 입력한다.

 

여기 부분이 중요한데, AMI를 선택할 때 My AMIs 탭을 선택하고 Owned by me를 클릭한다. 그리고 방금 만든 AMI를 선택

 

그 다음, 인스턴스 유형과 키페어는 다음과 같이 설정한다. 키페어는 기존에 사용했던 키페어를 계속 사용한다.

 

그 다음, 네트워크 설정이다. Subnet은 프라이빗 서브넷 App A에 그러니까 표본 EC2가 있는 같은 서브넷으로 선택하고 보안 그룹은 저 EC2와 같은 보안 그룹을 선택한다.

 

나머지는 기본값으로 설정한 후 만들어보자. 만들고 나면 리스트에 만든 Launch Template이 보여진다.

 

 

ALB 생성

이제 앞단에 쓰일 로드밸런서를 만든다. EC2 > Load Balancers에서 로드밸런서 하나를 만들자.

 

유형은 다음처럼 ALB를 선택한다.

 

Basic configuration은 다음과 같다.

 

네트워크 설정은 다음과 같다. AZ-a, AZ-c 두개를 사용한다.

 

보안 그룹은 앞에서 만든 ALB용 보안 그룹을 선택한다.

 

그리고 이 ALB를 만들기 전 대상 그룹을 먼저 만들어야 했는데 만들지 않았다. 그래서 Listerners and routing 섹션에 다음처럼 Create target group 링크를 클릭해서 만들자.

 

 

대상 그룹을 만들 때 유형은 인스턴스, 프로토콜과 포트는 HTTP:80용으로 한다.

 

그리고 VPC는 계속 사용했던 것을 선택하면 되고 Health check는 다음 경로로 설정한다.

 

다음으로 넘어가면 대상을 등록하면 된다. 위에 만든 Auto Scaling을 위한 EC2를 선택하고 'Includ as pending below' 클릭

 

그리고 만들면 이제 다시 로드밸런서 만들었던 화면으로 돌아가서 방금 만든 대상 그룹을 선택한다.

 

이렇게 설정하고 로드밸런서를 생성한다. 생성하면 리스트에 다음과 같이 노출된다.

 

이 만든 로드밸런서를 Route 53에 연결하자. Route 53 > Hosted zones로 가서 우리의 도메인을 선택하고 레코드 하나를 추가하자.

 

레코드를 다음과 같이 생성한다. subdomain은 autoscaling으로 설정했고 방금 만든 ALB에 붙인다.

 

 

 

이제 방금 만든 도메인으로 접속해보자. 그런데, HTTPS로 접속 가능하게 해보자. 우선 로드밸런서로 가서 규칙 하나를 추가해주자.

이렇게 설정하고 규칙하나를 추가해주자. 그리고 우리가 ALB에 적용한 보안 그룹 역시 443은 열려있지 않기 때문에 인바운드 규칙 하나를 추가해줘야 한다. 이 ALB에 적용한 보안 그룹으로 가서 인바운드 규칙 추가를 누르고 다음 443에 대해 설정해주자.

 

다 설정이 끝났으면 접속해보자. 잘 보여야 한다.

 

 

 

Auto Scaling Group 생성하기

이제 Auto Scaling Group을 만들어보자. EC2 > Auto Scaling > Auto Scaling Groups 로 들어가자.

 

생성하기를 누르고 이름을 지정해준다. 그리고 Launch template을 우리가 위에서 만든 것으로 지정한다. 버전은 그냥 Default로 하면 된다. 그리고 Next

 

VPC는 계속 사용하던 VPC로 설정하고 가용 영역과 서브넷은 A존 C존에 App용 서브넷을 선택한다. 그리고 Next

 

다음은 로드밸런서를 선택한다. 만든 로드밸런서를 선택하고 그에 맞게 설정한 대상 그룹을 지정한다.

 

Health Check 주기는 10초로 변경하자. 300초는 너무 길다. 그리고 Next

 

계속 Next로 넘어가고 태그를 만드는 화면에서 태그 하나를 생성하자. 태그의 키는 Name, Value는 적절한 값을 넣어서 태그 하나를 생성하고 Next

 

그러면 요약 부분이 나오고 확인 후 생성하면 된다. 생성하면 다음처럼 리스트에 잘 나온다.

 

들어가서 확인해보면 현재 Desired, Minimum, Maximum capacity가 전부 '1'로 되어 있다. 변경해보자. 우측 Edit 버튼 클릭

 

최대 용량을 3으로 변경해보자.

 

 

이제 Automatic scaling에서 정책을 생성해야 한다. Automatic scaling 탭에서 Dynamic scaling policies 섹션에 생성 버튼을 누른다.

 

정책 타입은 Target tracking scaling으로 하고 Metric type은 Average CPU utilization으로 선택하자. Target value는 70으로 설정하고 Instance warmup은 10초로 설정하고 만들어보자.

 

생성하면 다음과 같이 정책 하나가 추가됨을 확인할 수 있다.

 

정책은 정책이고 이렇게 Auto Scaling Group을 정상적으로 만들면 이 그룹에 의해 자동으로 인스턴스가 만들어진다. 확인해보자.

Auto Scaling Group의 Instance management 탭으로 가면 다음과 같이 인스턴스 하나가 'InService'상태인 것을 확인할 수 있다. 이는 Auto Scaling Group으로부터 자동으로 만들어진 인스턴스다.

 

실제로 인스턴스에 가서 리스트를 확인해보면 다음처럼 우리가 만든 표본 EC2가 있고 Auto Scaling Group이 만든 EC2가 둘 다 구동중이다.

 

Auto Scaling Group으로 만들어진 인스턴스들만 로드밸런서가 취급을 할 수 있도록 로드밸런서 쪽 대상 그룹에서 우리가 만든 표본 EC2는 날려주자. EC2 > Load Balancing > Target Groups에서 위에서 만든 로드밸런서에 적용할 대상 그룹에 들어가보면 다음과 같이 타겟이 두개다. 하나는 앞서 만든 표본 EC2, 하나는 Auto Scaling Group으로부터 만들어진 EC2. 표본 EC2를 대상 그룹에서 Deregister하자.

 

Deregister를 하면 다음처럼 상태가 Draining으로 변하고 이 대상 그룹에 타겟에서 빠진다.

 

 

Auto Scaling 확인하기

이제 우리가 만든 Auto Scaling Group의 정책에 따라 CPU 사용률이 70이 넘어가면 Scale Out이 발생하는지 확인해보자. 그러기 위해 Auto Scaling Group이 만들어준 EC2로 들어가서 스트레스를 부여하자.

 

우선 해당 EC2로 들어가야 한다. 해당 EC2의 프라이빗 IP를 확인해서 접속해보자. 내부로 들어오면 루트 유저로 변경하자.

sudo -s

 

이제 stress 패키지를 설치하자.

yum install stress

 

설치가 끝났으면 stress를 실행해보자.

stress -c 1& # 백그라운드로 stress 실행

 

잘 실행중인지 확인

ps -ef | grep stress

 

다음과 비슷하게 결과가 나올것.

root        4798    4279  0 01:08 pts/0    00:00:00 stress -c 1
root        4799    4798 98 01:08 pts/0    00:00:07 stress -c 1
root        4805    4279  0 01:08 pts/0    00:00:00 grep --color=auto stress

 

그리고 CPU 사용률을 확인해보자.

top

 

이러면 Auto Scaling Group에서 만든 정책 조건에 부합한다. 다음을 보자. 이 부분이 Auto Scaling Group에서 설정한 Dynamic scaling policies중 하나다. 저기 보면 'As required to maintain Average CPU utilization at 70' 이런 문장이 있는데 이게 CPU 평균 사용률을 70으로 유지하는데 필요한 경우이다. 우리가 99%까지 CPU 사용률을 높였기 때문에 이 조건에 따라 EC2가 늘어날 것이다.

CPU Policy
Target tracking scaling
Enabled
As required to maintain Average CPU utilization at 70
Add or remove capacity units as required
10 seconds to warm up before including in metric
Enabled

 

Activity 탭에서 이 부분을 유심히 봐보자.

 

당장 만들어지지 않을 수 있다. CPU 지표가 Cloudwatch로 전달이 되고 Cloudwatch에 있는 수치를 Auto Scaling Group에서 확인하는데까지 시간이 걸릴 수 있기 때문에 실시간 반영은 되지 않을 수 있다. 

 

조금 기다리면 다음과 같이 새로운 인스턴스가 Launching 된다는 활동 내역이 나온다. 

 

우리가 설정한 최대 3개까지 모두 만들어진 모습이다.

 

 

이렇게 3개까지 만들어지면 이제 로드밸런서는 이 세개의 인스턴스를 부하분산 처리해주면서 라운드로빈 방식으로 한번씩 돌아가면서 요청을 전달한다. 이렇게 Scale Out 현상을 잘 확인해보았다. 그럼 반대로 CPU 사용률에 대한 스트레스 프로세스를 죽였을 때 인스턴스가 하나씩 사라져야한다. Scale In. 그것을 확인해보자.

 

우선 stress 프로세스를 죽이자. 프로세스 ID를 확인해서 kill.

kill -9 stress-pID

 

스트레스 프로세스가 띄워져 있는지 확인

ps -ef | grep stress

 

 

자 이제 Auto Scaling Group으로 가서 인스턴스가 하나씩 종료되는지 확인하자. 다음처럼 하나씩 인스턴스가 종료된다고 나온다. 

 

 

이 인스턴스가 종료되는 방식은 Auto Scaling Group의 Details 탭에 가보면 Advanced configurations 섹션이 있다.

거기에 Termination policies가 Default인데, 이 Default는 가장 먼저 생성된 인스턴스를 가장 먼저 지우는 방식이다.

Edit 버튼을 눌러서 Terminate policies를 쭉 보면 다음과 같이 여러 방식이 있다.

이런 원리로 인스턴스가 종료된다는 것을 알아두면 된다.