본문 바로가기
AWS

[AWS] Auto Scaling 차근 차근 따라하기

by chan10 2023. 3. 8.

AWS에서 없어서는 안되는 Auto-Scaling은 필요에 따라 서비스 확장을 유연하게 도와주는 서비스입니다.

상태에 따라 EC2를 자동으로 조절하여 서비스 처리를 원활하게 할 수 있도록 도와주는 기능입니다.

Auto-Scaling을 설정 함에 앞서 Scaling에 대해 잠깐 짚고 넘어가겠습니다.

 

스케일링 이란?

스케일링이란 필요 시 EC2 인스턴스의 파워를 늘리는 것으로 2가지 종류가 있습니다.

스케일 업(Scale-Up) 스케일 아웃(Scale-Out)
- 용량 확장 필요 시 인스턴스 성능을 증가
(인스턴스 갯수 동일)
- 성능과 비용이 비례하지 않는다는 단점
- 스케일 다운(Scale-Down) : 인스턴스 성능 감소
용량 확장 필요 시 인스턴스 갯수를 증가, 규모를 늘리는 것
(인스턴스 성능은 동일)
- 스케일 인(Scale-In) : 인스턴스 갯수 감소

Auto-Scaling 생성 순서

1) AMI 생성

2) 시작 템플릿 생성

3) 로드밸런서, 타켓 그룹 생성 (옵션)

3) Auto Scaling 그룹 생성

AMI 생성

Auto-Scaling을 적용할 인스턴스의 AMI를 생성하기 위해 이미지 생성을 눌러줍니다.

저는 EC2 인스턴스에 Nginx, Stress를 구동시켜 테스트를 진행할 수 있도록 준비했습니다.

 

이미지 이름, 볼륨 크기 지정 후 이미지를 생성해줍니다.

해당 이미지를 기반으로 Auto-Scaling 시 인스턴스가 생성되기에 변경사항이 있을 경우 이미지를 새로 생성 해야합니다.

AMI 생성 시 서비스가 서비스가 잠시 중단되기에 실제 업무망에서는 주의가 필요합니다!!!!!

시작 템플릿 생성

AMI가 인스턴스의 이미지를 생성했다면 시작템플릿은 이미지의 컴퓨팅 유형, 네트워크

하나의 서버를 구성하기 위한 템플릿이라고 생각하면 됩니다.

 

템플릿 이름과 설명을 작성 후 Auto Scaling 지침을 체크하면 Auto Scaling시 필요한 필수 항목들을 알 수 있도록 메뉴 설정에 표시됩니다.

 

생성한 AMI를 선택하고 인스턴스 유형, 키 페어를 선택합니다.

인스턴스 유형은 필요한 성능에 맞게 선택하며 Auto Scaling 시 해당 성능으로 인스턴스가 생성됩니다.

 

네트워크 설정의 서브넷은 Auto Scaling 생성 시 네트워크를 지정하기에 시작템플릿에는 포함하지 않습니다.

‘종료 시 삭제’는 예로 하여 인스턴스 종료 시 인터페이스도 같이 삭제되도록 합니다.

 

퍼블릭 IP는 인스턴스를 외부에서 접근이 필요할 경우 할당으로 선택합니다.

저는 Session Manager로 접근이 가능하기에 포함하지 않았습니다.

(Session Manager 설정이 궁금하시면 링크 참고 부탁드립니다 😀 https://chan-it-note.tistory.com/116)

 

사용자 데이터EC2 인스턴스가 최초 실행될 때 한번만 구동되는 스크립트를 작성하는 필드입니다.

저는 인스턴스 실행 시 nginx가 자동으로 실행되도록 스크립트를 작성했습니다.

모든 설정을 완료했다면 시작 템플릿을 생성합니다.

Auto Scaling 그룹 생성

좌측 Auto Scaling 메뉴로 들어가 Auto Scaling 그룹 생성 버튼을 눌러 생성합니다.

이전에 만들었던 시작 템플릿에서 작업 -> ‘Auto Scaling 그룹 생성’을 통해서 만들 수도 있습니다.

 

Auto Scaling 이름과 이전 과정에서 만들었던 시작 템플릿을 선택합니다.

시작 템플릿 버전은 시작 템플릿을 수정할 때마다 버전이 새로 생성되기에 원하는 버전에 맞게 선택하면 됩니다.

특별히 사용할 버전이 있지 않은 경우 Default 또는 Latest 버전을 선택하시면 됩니다.

 

다음은 Auto Scaling을 연결할 로드 밸런서를 선택하는 과정입니다.

로드 밸런서를 선택은 필수 사항은 아니며 로드 밸런서가 없어도 Auto Scaling은 가능합니다.

다만, 로드 밸런서를 선택하면 Auto Scaling 후 생성된 인스턴스를 로드밸런서에 등록까지 자동으로 이루어지게 됩니다.

 

상태 확인은 Auto Scaling 그룹에서 EC2 인스턴스의 상태를 확인하여 실패 시 인스턴스를 교체하기 위한 설정입니다.

             EC2 : EC2 인스턴스의 상태가 실패할 때 인스턴스 교체

             ELB : ELB Health Check에 실패할 때 인스턴스 교체

 

만약 ELB에 Auto Scaling을 연결했는데 ELB체크를 하지 않을 경우 Health Check는 실패했지만 EC2 인스턴스 상태 체크가 실패하지 않으면 EC2 인스턴스 교체가 이루어지지 않습니다. 서비스 장애가 일어날 수 있겠죠.

 

ELB를 연결하여 Auto Scaling을 업무에 적용하는 경우 업무 환경에 따라 ELB 체크를 해주시면 됩니다.

다만 Health Check가 성공하지 않으면 EC2 인스턴스가 무한정 교체되기에 테스트 용도인 저는 선택하지 않았습니다.

 

최소/최대 용량의 범위를 지정하여 Auto Scaling 그룹의 크기를 지정합니다.

  원하는 용량 : 평상시에 유지하고 싶은 인스턴스 수

                     원하는 용량에 따라 실행되는 인스턴스의 수가 변동되며 범위는 최소/최대 용량 사이로 설정할 수 있습니다.

  최소 용량 : 최소로 유지하는 인스턴스 수

                   인스턴스를 유지할 최소한의 크기로 Auto Scaling은 인스턴스를 해당 갯수 이하로 내려가지 않도록 합니다.

  최대 용량 : 최대로 유지하는 인스턴스 수

                  인스턴스를 유지하는 최대 크기로 Scale-Out을 진행하면 최대 크기를 넘지 않도록 합니다.

 

Auto Scaling을 조정하는 조건을 선택하는 옵션입니다.

상태 확인은 인스턴스에 문제가 감지될 시 인스턴스를 교체하는 옵션이면 크기 조정 정책은 Auto Scaling의 확장 조건을 선택하는 것으로 사용할 수 있는 조건은 다음과 같습니다.

1) 평균 CPU 사용률

2) 평균 네트워크 입력/출력(바이트)

3) 대상당 Application Load Balancer 요청 수

 

인스턴스 요구 사항의 ‘지표에 포함하기 전 워밍업 시간’설정된 시간까지는 조정 정책에 포함 시키지 않는다는 뜻입니다.

만약 인스턴스가 초기 생성 시 CPU사용률이 높더라도 300초 동안은 조정 정책 지표에 산정되지 않아 Scale Out 동작을 하지 않게 됩니다.

 

알림, 태그 메뉴는 옵션으로 필요에 따라 설정하면 됩니다. Name 태그 작성 시 EC2 인스턴스 생성 시 작성한 이름으로 생성되어 관리가 편해지기에 Name 태그는 작성합니다.

설정 검토를 완료하고 Auto Scaling 그룹 생성 버튼을 누르면 새로운 Auto Scaling 그룹이 생성됩니다.

 

생성된 Auto Scaling 그룹을 누르면 세부 정보를 볼 수 있습니다.

여기서 활동 탭을 누르게 되면 Auto Scaling의 로그를 볼 수 있는데 Auto Scaling동작에 따라 인스턴스가 생성/증가/감소되는 활동의 로그를 확인 할 수 있습니다.

 

생성된 인스턴스는 인스턴스 관리 탭에서 목록/상태를 확인할 수 있습니다.

EC2 메뉴에서도 Auto Scaling 그룹에 의해 생성된 인스턴스를 볼 수 있고 Name 태그를 기반으로 인스턴스 이름도 자동으로 붙여진 모습을 볼 수 있습니다.

 

Auto Sacling그룹 생성 시 로드밸런서 타겟 그룹에도 등록을 했기에 타켓 그룹에도 들어가서 보면

생선된 인스턴스 2대가 타켓 그룹으로 등록된 것을 볼 수 있습니다.

 

로드밸런서를 통해서 서비스 접근까지 확인하면 Auto Scaling 그룹에 의해 생성된 인스턴스가 정상적으로 동작하는 것을 알 수 있습니다. (시작 템플릿에 작성한 사용자 데이터에 의해 nginx도 자동으로 활성화 되었네요)

Auto Scaling 테스트 (정적)

Auto Scaling 그룹을 이용해 용량을 줄여 수동으로 인스턴스 수를 줄여보겠습니다. 만들었던 Auto Scaling 그룹의 이름을 눌러서 세부 정보로 들어갑니다.

 

세부 정보에서 원하는 사이즈를 조절할 수 있는데 원하는 용량을 1로 하여 인스턴스 수를 하나로 조절하겠습니다.

그런데 원하는 용량은 최소/최대 사이의 값 이어야 하기에 최소 용량도 2->1로 변경해줍니다.

(원하는 용량이 최소/최대 사이 값이 아니면 설정이 적용되지 않아요..!)

 

Auto Scaling 그룹의 용량을 변경하고 잠시 뒤 확인해보면 인스턴스 수가 2대 -> 1대로 줄어들었고

로드밸런서의 타켓 그룹에서도 1대는 제외되어 1대만 적용된 것을 볼 수 있습니다.

Auto Scaling 테스트 (동적)

하나로 줄어들은 인스터스 수를 수동으로 늘리는 것이 아닌 자동으로 늘어나도록 해보겠습니다.

이전에 Auto Scaling 그룹 생성 시 설정했던 ‘크기 조정 정책’조건에 따라 ‘평균 CPU 사용률 ’이 80% 이상으로 증가하면 인스턴스 수가 자동으로 증가하게 됩니다.

 

테스트를 위해 EC2 인스턴스에 접속합니다. 이때 인스턴스는 아무 인스턴스가 아닌 Auto Scaling에 체크되는 인스턴스를 접속합니다.

저는 이전 테스트에서 Auto Scaling에 의해 수동으로 줄어들어 하나 남은 인스턴스를 세션 메니저를 이용해 접속했습니다.

stress 패키지를 이용해 인스턴스에 강제로 CPU에 부하를 줘보겠습니다.

 

그러면 잠시 후 Auto Scaling 그룹이 해당 인스턴스의 상태를 감지하여 인스턴스를 증가하는 작업을 수행합니다.

인스턴스 증가가 완료되면 자동으로 1대 -> 2대로 증가된 것을 확인 할 수 있습니다.

 

로드밸런서 타켓 그룹도 생성된 인스턴스가 추가로 등록되었습니다.

로드밸런싱 대상에 자동으로 포함되었으니 분산 처리도 이루어질 수 있게 됩니다.

 

[참고 사이트]

1) https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-EC2-%EC%98%A4%ED%86%A0-%EC%8A%A4%EC%BC%80%EC%9D%BC%EB%A7%81-ELB-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%84%9C-%EA%B0%9C%EB%85%90-%EA%B5%AC%EC%B6%95-%EC%84%B8%ED%8C%85-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

 

2) https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/asg-capacity-limits.html