[AWS] 📚 Auto Scaling 개념 원리 & 사용 세팅 💯 정리

...

오토 스케일링 (Auto Scaling)

클라우드 컴퓨팅의 대표적인 장점으로는 필요에 따라 서비스를 빠르게 확장하거나 축소할 수 있는 유연성을 들 수 있다.

그중, 오토스케일링(Auto Scaling)은 클라우드의 유연성을 돋보이게 하는 핵심기술로 CPU, 메모리, 디스크, 네트워크 트래픽과 같은 시스템 자원들의 메트릭(Metric) 값을 모니터링하여 서버 사이즈를 자동으로 조절 하는 서비스를 말한다.

이를 통해 사용자는 예상치 못한 서비스 부하에 효과적으로 대응하고, 최대한 저렴한 비용으로 안정적이고 예측 가능한 성능을 유지 할수 있다.

스케일링 이란?

오토스케일링(Auto Scaling)에 대해 배우기 앞서 스케일링(Scaling)이 정확히 무엇을 의미하는지 간단하게 짚고 넘어가도록 하자.

스케일링 이란 인스턴스 혹은 컴퓨팅 파워를 늘리는 것을 말한다.

스케일링의 방법에는 대표적으로 2가지가 있다.

스케일 업(Scale Up)

cpu가 하나이고 memory 1기가인 인스턴스가 있다고 가정하자.

만일 인스턴스의 성능을 16배로 늘려야할 상황이 온다면, 말 그대로 16배 큰 인스턴스를 사용함으로서 성능을 올리는 것을 스케일 업이라고 한다. 하지만 이는 성능과 비용이 비례하지 않는다는 단점이 있다.

주변에서 간단히 예를 들면 그래픽카드를 볼 수 있다. (그래픽카드 지식이 있으신 게이머 분들만 보세요!)

GTX 1080과 RTX 2080의 성능 차이는 30%밖에 안되지만 가격 차이는 두배가 넘는다.

물론 RTX 3080같은 명작도 가끔 나오지만 역시 엄청 비싸다.

거기다 만일 1,000,000배 높은 성능을 사용하고 싶다면 비용은 어마어마 할것이고, 물리적으로 가능한지도 고민 해봐야 한다.

스케일 아웃(Scale Out)

위의 물리적인 문제를 해결하는것이 바로 스케일 아웃 이다.

스케일 아웃은 규모를 늘리는 것이다.

즉, 10만배 성능이 좋은 그래픽카드는 현실에서도 존재하지도 않으니 여러개 장착 해서 성능을 올려보자는 개념이다.

하지만 이는 물리적으로 불가능하다. 메인보드에는 그래픽카드를 최대 2개밖에 장착하지 못하며, 만일 수십개를 장착할 수 있다고 해도 공간을 고려해야 되지 때문이다.

그러나 클라우드는 상황이 다르다. (왜 클라우드가 인기있는 이유이기도 하다)

성능을 16배 올리고 싶으면 그냥 인스턴스를 16개 가져다가 쓰면 된다.

공간의 제약이나 하드웨어적인 제약이 없다.

그리고 성능과 비용이 비례하다는 특징도 가지고 있다. (그래픽카드 크로스파이어(글카 2개 장착) 같은경우 30%밖에 성능 향상폭이 미미하다)

따라서, 클라우드 환경에서는 Scale Out을 항상 염두하며 설계를 해야 한다.

수요에 따라 인스턴스를 덜 쓸 수도, 더 쓸 수도 있음으로서 유연성을 가질 수 있기 때문이다.

스케일 인(Scale In)

scale out으로 늘린 인스턴스를 다시 줄이는 행위로 이해하면 된다.

이처럼, 오토 스케일링(Auto Scaling)은 바로 Scale Out을 자동화(Auto) 하기 위해 나온 서비스라고 보면 된다.

애플리케이션을 모니터링 하고 용량을 자동으로 조정하는 역할을 하며, 최대한 저렴한 비용으로 안정적이고 예측 가능한 성능을 유지 한다.

그래서 몇 분만에 손쉽게 여러 서비스 전체에서 여러 리소스에 대해 애플리케이션 규모 조정을 설정 할 수 있다.

오토 스케일링의 목표

정확한 수의 EC2 인스턴스를 보유하도록 보장
- 그룹의 최소 인스턴스 숫자와 최대 인스턴스 숫자를 관리
- 만약 애플리케이션을 실행하기 위해 인스턴스가 3개가 필요하다면, 3대 이상의 인스턴스가 항상 떠있을 수 있게 보장한다.
- 최소 숫자 이하로 내려가지 않도록 인스턴스 숫자를 유지 (인스턴스 추가)
- 최대 숫자 이상 늘어자니 않도록 인스턴스 숫자 유지 (인스턴스 삭제)
다양한 스케일링 정책 적용 가능
- CPU의 부하에 따라 인스턴스 크기 늘리기/줄이기 (오후 2시가 되면 게임 접속 트래픽이 많으니 인스턴스 확 올리고, 새벽 2시가 되면 접속 트래픽이 낮으니 인스턴스를 내린다.)
가용영역에 인스턴스가 골고루 분산될 수 있도록 인스턴스를 분배
- 서비스 장애가 발생하더라도 문제없이 서비스 이용

또한, AWS 오토스케일링 서비스는 EC2뿐만아니라 여러 AWS 서비스와 유기적으로 연동하여 사용 할수도 있다.

오토 스케일링 구성 요소

오토 스케일링 그룹(Groups)

EC2 인스턴스를 조정 및 관리 목적의 논리 단위로 취급될 수 있도록 그룹으로 구성
그룹을 생성할 때 EC2 인스턴스의 최소(minimum size) 및 최대(maximum size) 인스턴스 수와 원하는(desired capacity) 인스턴스 수를 지정하고 이 범위안에서 Scale in/out 이 일어난다.
인스턴스 증감은 이 그룹안에서 이루어 지게 되며, 사용자가 지정한 조건을 통해 실행된다.
- 증설 시 어떤 인스턴스 템플릿을 이용할 것인지
- 얼마나 많은 서버를 필요로 하는지
- 어떤 값을 기반으로 모니터링해서, 인스턴스를 증설 또는 감축 할 것인지
추가적으로 증설된 인스턴스가 로드밸런서의 멤버로 연결되어야 한다면, 로드밸런서를 지정할 수도 있다.

시작(구성) 템플릿

Auto Scaling 그룹에서 인스턴스를 시작하는데 사용하는 템플릿으로, AMI(이미지)라고 생각해도 된다.
템플릿이라 함은 똑같은 OS환경의 인스턴스를 간편하게 복제하기 위해서 구성하는 것이다.
따라서 템플릿을 오토스켕일링 그룹에 지정시킴으로서, 오토스케일링을 통해 인스턴스 늘리면 그 인스턴스의 환경 구성이 템플릿에 설정된 환경에 따라 복제됨으로서 서비스를 늘린다는 개념 원리인 것이다.
인스턴스의 AMI ID, 인스턴스 유형, 키 페어, 보안 그룹, 블록 디바이스 매핑 등의 정보를 세팅해서 템플릿을 구성하게 된다.
템플릿을 구성하면 수정이 불가능하다. 템플릿은 버젼으로 구분되는데, 만일 옵션을 바꿀 필요가 있으면 새로 생성을 하고 버젼을 새로생성한 버젼으로 바꾸는 식으로 해야한다. (뒤의 실습을 보면 이해할수 있을 것이다.)

오토 스케일링 조정 옵션

Auto Scaling 그룹을 조정하는 다양한 조건 방법을 설정하는 옵션이다.
예를들어, CPU 점유율이 일정 %를 넘었을 때 추가로 늘리거나 아니면 2개 이상이 필요한 스택에서 EC2 하나가 죽었을 때 실행하거나 등
현재 인스턴스 수준 유지 관리, 수동 조정, 일정을 기반으로 조정, 온디맨드 기반 조정 등등 이 있다.
CloudWatch이나 ELB(부하 분산)와 연계가 가능하다.
아래 사진과같이 어느 when일떄 take the action할지 옵션 조정 메뉴가 있다.

오토스케일링 동작 원리

복잡하지만 최대한 간단하게 요약하자면 다음과 같이 된다.

EC2 인스턴스 클러스터 가 있고 8개의 인스턴스가 필요하다고 가정해보자
하드웨어가 터졌다던지 소프트웨어 문제가 터져서 EC2 한개가 죽어버렸다.
그럼 이것을 오토스케일링이 감지를 한다
그리고 시작구성에 맞는 인스턴스를 생성을 해서 오토 스케일링 클러스터에 넣어준다.

만일 보다 자세한 동작원리에 대해 알고 싶다면 다음 포스팅을 추천하는 바다.

탄력적인 클라우드 자원 활용 기술: 오토스케일링(Auto Scaling)

[BY 삼성SDS] 손병창 | 에스코어㈜ 소프트웨어사업부 클라우드 컴퓨팅의 대표적인 장점으로 필요에 따라 ...

m.post.naver.com

오토 스케일링 실전 구축 세팅

1. 시작 템플릿 생성

오토스케일링 그룹을 생성하기에 앞서, 어떤 인스턴스를 어떻게 올릴지 정의하는 템플릿을 생성한다.

과거에는 시작 구성(Launch Configuration)을 사용했지만 현재는 AWS에서는 시작 템플릿(Template) 방법 사용을 권장하고 있으며, 시작 템플릿이 시작 구성에 비해 버전 등 관리가 더 편하다고 한다.

두 가지 모두 Auto Scaling을 위해 생성해야 하는 서비스지만,

시작 구성(Launch Configuration)의 경우 배포할 소스의 버전이 올라가면 시작 구성을 매번 새로 만들어줘야하는 것에 반해,

시작 Template은 배포할 소스의 버전이 올라가도 해당 템플릿 업데이트를 통해 버전 관리가 가능하다.

Auto Scaling으로 인스턴스를 증설하기 위해서는 EC2 AMI 이미지가 필요하다.

리눅스 서버 인스턴스를 증설해야되는데 뜬금없이 윈도우 서버 인스턴스를 생성하면 안되기 때문이다.

미리 만들어놓은 AMI를 고를수도 있고 새 AMI를 고를수도 있다.

최근 사용 : 최근에 사용한 AMI 목록
내 AMI : 미리 만들어놓은 내 AMI를 선택
Quick Start : EC2 인스턴스 생성할떄 AMI를 골랐을때 처럼 고를수 있다.

인스턴스 유형 및 전반적인 인스턴스 초기 세팅을 설정한다.

복잡하게 생각할 필요 없이 그냥 EC2 인스턴스 생성했을때 처럼 항목을 선택해주면 된다.

이것들은 오토스케일링으로 인스턴스를 여러개 만들때 어떤 인스턴스 유형으로, 어떤 스토리지로, 어떤 AMI로 만들지 미리 세팅하는 템플릿 개념으로 이해하면 된다.

2. Auto Scaling 그룹 생성

시작 템플릿을 생성했으면 따로 EC2 인스턴스를 생성할수도 있고 이를 기반으로 오토 스케일링 그룹을 생성할 수도 있다.

템플릿을 선택하고 작업 메뉴에서 오토스케일링 그룹 생성을 누른다.

이제 EC2 인스턴스를 분배할 VPC와 가용영역(AZ)을 선택한다.

서울 리전을 기준으로 ap-northeast-2a와 ap-northeast-2c를 선택했다.

이렇게 가용영역을 두개를 지정하면 Auto Scaling을 통해 인스턴스를 만들 때 가용영역을 번갈아 50% 비중으로 인스턴스를 만들기 때문에 하나의 가용영역에 문제가 생겨도 상대적으로 영향을 덜 받을 수 있게 된다.

고급 옵션 구성에서는 로드 밸런서를 Auto Scaling 그룹에 연결하거나 Auto Scaling 그룹에서 인스턴스가 정상인지 비정상인지 판단하는 방법에 대한 특정 요구사항을 정의한다.

최종 구상도를 위해서는 필요한 설정이겠지만, 우선은 CPU 사용량에 따른 scale out만을 확인하고자 하니 넘어가도록 하겠다

로드밸런싱에 관해서는 다음 ELB 강의에서 진행하도록 하겠다.

그룹 크기 및 조정 정책에서는 원하는 용량 , 최소 용량, 최대 용량을 설정해 줄 수 있다.

이 부분이 바로 오토 스케일링을 통해 증설하거나 유지할 인스턴스 개수를 설정하는 부분이다.

원하는 용량(그룹 사이즈)
- 그룹 내 목표로 하는 인스턴스 수, 평상시에 유지하고 있을 인스턴스 수
  사용자의 필요에 따라 선택할 수 있으며, 최소 및 최대 크기 범위 이내에 있어야 한다.
  이 항목을 입력하지 않으면 Auto Scailing은 최소 크기에 맞춰 인스턴스를 런칭하고, 입력하면 해당 값에 맞춰 인스턴스를 추가 또는 종료시키게 된다.

최소 용량
- 그룹 내 최소 유지할 인스턴스 수
  예를들어 최소가 2이면 자동조정 정책이나 사람에 의해 인스턴스 수를 2개 미만으로 줄일 수 없다.
  Auto Scailing은 인스턴스 수가 최소 크기 이하로 내려가지 않도록 한다.
  이 값을 0으로 설정하면 새 인스턴스를 추가하지 않고 그룹 내에서 실행되는 모든 인스턴스를 종료시키게 된다. (최소를 가장 적게 주고 싶어서 생각없이 0을 줘버리면 싹 EC2가 종료되어리니 조심해야 된다.)

최대 용량
- 그룹 내 최대 유지할 인스턴스 수
  Auto Scailing은 인스턴스 크기가 최대 크기 이상이 되지 않도록 하며, 예산 제한선을 고려해 예기치 못한 수요에 의해 지나치게 많은 인스턴스가 추가되지 않도록 하는 안전장치 역할을 한다.

오토스케일링 그룹을 사용하지 않을 때는 원하는 용량, 최소 용량, 최대 용량을 0, 0, 0으로 설정해주면 된다.

조정 정책은 앞서 말했듯이, Auto Scaling 그룹을 조정하는 다양한 조건 방법을 설정하는 옵션이다.

[ 대상 추적 조정 정책 ] 을 선택하고 [ 지표 유형 ] 의 평균 CPU 사용률 대상 값을 80으로 설정해 준다.

이는, 만약 2개의 인스턴스가 가동되는 있는 상황에서 1개의 인스턴스 평균 CPU 사용률이 80%가 넘어가면 새로운 인스턴스를 생성한다는 오토스케일링 동작 조건을 걸어놓은 것이다.

사용할 수 있는 지표 유형은 다음과 같다.

평균 CPU 사용률
평균 네트워크 입력 / 출력 (byte)
대상당 Application Load Balancer 요청 수

지표에 포함하기 전 워밍업 시간(초)는 새로 시작된 인스턴스가 설정해둔 시간까지 조정 정책 지표에 포함시키지 않는다는 뜻이다.

예를 들어, 워밍업 시간을 300초로 해두었다면 새로 생긴 인스턴스가 CPU 사용률이 아주 높을지라도 조정 정책 지표 산정에 300초 동안은 포함되지 않아 스케일 아웃이 동작하지 않는 것이다.

알림 추가는 Auto Scaling 그룹에 인스턴스가 시작/종료 될때마다 SNS 주제로 알림을 전송할 수 있다고 한다.

이번 강의에선 pass를 한다.

태그 부분은 통과해도 무난하지만, 키는 Name, 값은 auto-group 으로 주시면 생성된 ec2 인스턴스를 관리할때 편리하다.

마지막 검토를 하고 오토 스케일링 그룹을 생성 버튼을 누르면 그룹 생성이 완료된다.

3. Auto Scaling 그룹 동작 확인하기

오토스켕일링 그룹을 클릭하면 지금까지 설정한 세부 정보를 볼수 있는데, 앞서 원하는용량, 최소용량, 최대용량을 2개로 맞춰놓았었다.

오토스케일링 그룹을 생성하면 바로 앞서 정의한 인스턴스 용량에 따라 자동으로 인스턴스가 바로 업데이트되게 된다.

활동을 보면 EC2 인스턴스 런치가 성공적으로 됬다는 로그를 볼수 있고, 인스턴스 관리탭에 들어가면 두개가 생성됨을 볼 수있다.

정말로 생성되었는지 확인을 위해 EC2 인스턴스 메뉴에 들어가면 앞서 태그에서 설정한 auto-group 별명의 인스턴스가 두개 생성됨을 확인 할 수 있다.

이번에는 오토 스케일링 그룹이 원하는 인스턴스 갯수를 맞춰주는지 확인하기 위해, auto-group 인스턴스 하나를 일부러 종료시켜 보자.

예상대로라면 오토 스케일링 그룹의 설정에 원하는 인스턴스 갯수가 2개로 설정하였으니, 다시 2개를 맞춰주기 위해 인스턴스를 한개 추가로 생성해 유지시켜줄 것이다.

4. Auto Scaling 그룹 EC2 인스턴스 삭제

만일 오토 스케일링으로 작동되고 있는 EC2 인스턴스를 삭제하고 싶다면 어떻게 할까?

이때까지 해왔듯이 EC2 인스턴스 메뉴에서 인스터스 종료를 하면 될까? 그렇게 하면 위에서 했듯이 오토스케일링으로 인해 인스턴스가 복구가 되어 버릴 것이다.

따라서 오토스케일링 인스턴스를 완전히 삭제하기 위해서는, 그룹메뉴에서 원하는 용량, 최소 용량, 최대 용량을 0으로 설정해주면 된다.

5. 시작 템플릿 버젼 업데이트하기

시작 템플릿을 만들면 이미 세팅한 템플릿 설정들을 수정할수는 없다.

대신에 템플릿을 새로 만들어서 버젼을 업데이트 하는 형식으로 시작 템플릿 설정들을 간접적으로 바꿔줄수 있다.

우선 시작 템플릿 매니저 메뉴에 들어와서 작업 → 템플릿 수정(새 버젼 생성)을 누른다.

인스턴스, 스토리지, 네트워크 설정 등을 원하는 대로 재세팅 해준다.

그리고 맨 밑으로 내려가서 고급 세부 정보를 클릭해준다.

그리고 다음과 같이 입력해준다.

bash 스크립트를 작성해주는데, 그냥 인스턴스 웹페이지로 들어가면 인스턴스 고유ID가 화면에 출력되게 하는 간단한 스크립트 이다.

#!/bin/bash

INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id) # 자신의 인스턴스 ID 문자값을 변수에 저장
yum  install httpd -y # 아파치 서버 설치
echo ""$INSTANCE_ID"" >> /var/www/html/index.html # #INSTANCE_ID 변수값을 html에 이어쓰기
service httpd start # 아파치 시작