AWS 인프라 구축 실습 9회 - AutoScaling
AWS 오토스케일링 아키텍처 구성도
사전준비사항
1. 대상그룹 : "new-tg-asg" <- 시연에서는 ALB 생성 과정에서 등록합니다
2. 보안그룹 :
- "new-sg-web" [ssh(anywhere), http(anywhere)]
- "new-SG-ALB" [https(anywhere)]
3. Internet Gateway
4. VPC : "new-vpc"
5. Subnet : 퍼블릭서브넷2a, 퍼블릭서브넷2c
6. EC2
- web01 서버 : (amazon linux 2, t2.micro, new-vpc, 퍼블릭서브넷2a, 퍼블릭ip자동할당 활성화, httpd설치, 보안그룹)
- 예약스크립트 (EC2 인스턴스 생성할 때 스크립트가 실행됩니다. 아래는 httpd 아파치 서버를 설치&실행하는 스크립트입니다)
# EC2 인스턴스 생성 시, 아파치 설치&실행 스크립트
#!/bin/bash
yum install -y httpd
systemctl enable --now httpd
echo "webserver" > /var/www/html/index.html* 사전준비사항과 탄력적IP(EIP)설정은 이전강의에서도 나와 있으므로의 시연과정에서는 생략합니다.
설정 절차
1. ALB : "new-Asg-ALB" 생성
2. AMI 생성(EC2 이미지) : "new-ami"
3. AutoScaling 시작구성 생성 : "new-LC"
4. AutoScaling 그룹 생성 "new-ASG"
5. Route53 등록
6. ACM 등록
7. AutoScaling 조정정책 설정
8. 부하테스트
실습내용
- HTTPS 인증서 발급
- 오토스케일링 시연
- Autoscale Out : CPU 사용률이 70% 을 상회하면 서버 수를 늘립니다.
- Autoscale In : CPU 사용률이 30%을 하회하면 서버 수를 줄입니다.
* CPU 사용률은 인스턴스 전체 평균입니다.
아마존에서 이야기하는 AutoScaling 이점
Amazon EC2 Auto Scaling을 애플리케이션 아키텍처에 추가하는 것은 AWS 클라우드의 이점을 극대화할 수 있는 한 가지 방법입니다. Amazon EC2 Auto Scaling을 사용하면 애플리케이션에서는 다음과 같은 이점을 누릴 수 있습니다.
- 향상된 내결함성. Amazon EC2 Auto Scaling에서는 인스턴스가 비정상 상태일 때 이를 감지하여 종료한 다음 이를 대체할 인스턴스를 시작할 수 있습니다. 여러 개의 가용 영역을 사용하도록 Amazon EC2 Auto Scaling을 구성할 수도 있습니다. 하나의 가용 영역이 사용 불가 상태가 되면 Amazon EC2 Auto Scaling에서는 다른 가용 영역에서 새 인스턴스를 시작하여 이에 대처할 수 있습니다.
- 가용성 향상. Amazon EC2 Auto Scaling은 애플리케이션이 항상 현재 트래픽 요구를 처리할 수 있는 올바른 용량을 갖추도록 도와줍니다.
- 비용 관리 향상. Amazon EC2 Auto Scaling은 필요에 따라 용량을 동적으로 늘리거나 줄일 수 있습니다. 사용한 EC2 인스턴스에 대해서만 비용을 지불하므로, 인스턴스가 필요할 때 이를 시작하고 필요 없어지면 종료함으로써 비용을 절감합니다.
오토스케일링의 경우 가용 자원을 최소/최대로 설정하여 실시간 지표에 따라 유연하게 운영을 할 수 있도록 하여 확정성과 비용절감이라는 장점을 갖고 있습니다. 또, CloudWatch와 연계하여 사용량을 모니터링할 수 있고 문제가 발생하였을 때 알람기능을 메일 또는 SNS로 보낼 수 있습니다.
오토스케일링은 현재 SPICE 시스템의 배포/운영에 적용해 볼 수 있습니다.
하지만 무중단 배포 정책에 대하여 한계가 있기 때문에, 이를 활용하려면 AWS ECS나 EKS를 활용하여 배포/운영할 수 있겠습니다.
* 무중단 배포 정책에는 크게 롤링배포, 블루/그린배포, 카나리배포 로 나누어 집니다. 자세한 설명은 다음 링크 무중단 배포 아키텍처를 참고하세요.
오토스케일링의 개념 이해와 경험은 리소스 확장성과 비용절감이라는 클라우드 아키텍처의 기본적인 지식을 습득하는 것이라 볼 수 있겠습니다.
AutoScaling 구축 시연
1. Load Balancer 에서 ALB 생성
1.1. EC2 > 로드 밸런서 > Application Load Balancer 생성
AWS Builders 100 Hand on Lab
오토스케일링 Amazon EC2 Auto Scaling 개념 Amazon EC2 Auto Scaling를 통해 애플리케이션의 로드를 처리할 수 있는 정확한 수의 Amazon EC2 인스턴스를 보유하도록 보장할 수 있습니다. Auto Scaling 그룹이라는 EC
aws-builders-kr.workshop.aws
기본설정에서 로드밸런서명을 "new-ASG-ALB"로 하고 체계는 "인터넷 페이싱"으로 합니다.
앞서 생성한 VPC(new-vpc)와 Subnet(퍼블릭서브넷2a, 퍼블릭서브넷2c)을 선택합니다.
VPC, 퍼블릭서브넷의 경우 라우팅설정에서 Internet Gateway와 연동되어 있습니다.
보안그룹은 앞서 생성한 "new-SG-ALB"를 선택합니다. 이 보안그룹은 HTTPS 를 오픈합니다.
아키텍쳐 생성과정 중에 HTTPS를 설정하여 반영하게 합니다.
리스너는 HTTPS로 선택합니다.
1.2. 대상그룹 만들기
대상그룹이 없기 때문에 대상그룹을 생성합니다.
'Create target group'을 클릭합니다.
대상유형은 'instances', 대상그룹명은 'new-tg-asg', vpc는 'new-vpc', 프로토콜은 'http'로 설정하고 저장합니다.
대상등록(인스턴스)에서 "include as pending below"를 클릭하지 않고 대상그룹을 생성합니다.
생성된 대상그룹입니다.
ALB 생성 중 대상그룹란을 리프레시하여 앞서 생성한 대상그룹 'new-TG-ASG'를 선택합니다.
이제 로드밸런서를 생성합니다.
생성된 ALB는 프로비저닝 중입니다. 잠시 기다리시면 프로비저닝이 완료되고 "활성" 상태로 변경됩니다.
생성된 로드밸런서를 선택하고 리스너 탭을 선택합니다.
리스너 편집 버튼을 클릭하여 기본작업의 전달사항으로 대상그룹 "new-tg-asg" 을 선택하고 ACM 인증서는 등록한 인증서를 선택하여 리스너를 추가합니다.
2. EC2 > 이미지(AMI)생성
EC2 > 인스턴스 > web01 에서 팝업메뉴를 오픈하고 이미지 생성 메뉴를 클릭합니다.
이미지의 이름은 'new-ami', 재부팅안함 체크하고 이미지 생성을 클릭합니다.
(참고로 AMI 이미지가 생성되지만 스냅샷이 ami 원본입니다)
AMI 이미지 생성결과입니다.
참고로 스냅샷이 ami 이미지의 원본입니다.
참고로 AMI란 EC2 인스턴스 생성시에 첫단계에 선택하는 텝플릿 이미지입니다.
3. AutoScaling 시작구성 생성
이제 Auto Scaling 시작 구성 메뉴를 선택합니다.
시작구성생성을 클릭합니다.
시작구성명은 'new-LC', ami 는 'web01'의 이미지를 'new-ami'선택합니다. 인스턴스 유형은 't2.micro'를 선택합니다.
보안그룹은 'new-sg-web'을 선택합니다.
키페어를 선택하고 생성을 클릭합니다.
4. AutoScaling 그룹 생성
이제 Auto Scaling 그룹을 생성합니다.
Auto Scaling Group 메뉴 > 오토스케일링 그룹 생성을 클릭합니다.
1단계 시작템플릿 또는 구성 선택
이름 'new-ASG', 시작 템플릿(launch template) 에서 우측의 '시작구성으로 전환'을 클릭합니다.
시작구성은 'new-LC'를 선택합니다. 다음을 클릭합니다.
2단계 설정구성
VPC 'new-vpc', subnet '퍼블릭서브넷2a', '퍼블릭서브넷2c'를 선택하고 다음을 클릭합니다.
3단계 고급옵션 구성
로드밸런서는 기존로드밸런서를 선택하고 기존 로드밸런서 연결에서는 로드밸런서 대상그룹을 선택합니다.
그리고, 앞서 생성한 로드밸런서 'new-tg-asg'를 선택합니다. 다음을 클릭합니다.
4단계 그룹 크기 및 조정 정책 구성
기본 2개의 인스턴스로 구성하고 최소 2개, 최대 4개로 설정하여 시뮬레이션 해보도록 하겠습니다.
조정정책은 CPU, 네트워크 입출력 등을 설정할 수 있습니다만 실습에서는 없음으로 선택하겠습니다.
차후에 Scaling in, Scaling out 에 대한 조건 설정을 하려고 합니다.
5단계 알림추가
실습에서는 알림 추가를 선택하여 이메일로 전송하도록 하겠습니다.
주제생성을 클릭하고 주제명은 'scale-out-noti', 이메일을 등록하고 다음을 클릭합니다.
6단계 태그추가
생략하도록 하겠습니다. 태그를 추가하면 확장생성되는 경우에 EC2 인스턴스에 이름을 부여할 수 있습니다.
7단계 검토
문제가 없다면 오토스케일링 그룹 생성을 클릭합니다. 곧 상태가 활성화 됩니다.
이제 오토스케일링 실습을 위해서 트래픽 폭주를 가정하고 오토스케일링 로드밸런스로 부하테스트를 시작하면 됩니다.
시연에서는 HTTPS와 도메인도 등록해 보겠습니다.
5. Route53 도메인 등록
이 실습을 위해서 도메인을 먼저 구매해야 합니다.
HTTPS 보안 연결에는 인증서 도메인이 필요합니다.
도메인등록 사이트에 가서 도메인을 등록합니다.
도메인 관련 설정은 시간이 좀 필요한 작업입니다. 등록한 도메인이 사용가능하기 까지 몇분에서 몇 십분이 필요할 수 있기 때문에
도메인 설정에 관한 작업은 우선적으로 처리하는게 좋습니다.
저는 도메인을 'edbae.shop'으로 준비하였습니다. 앞으로 이 도메인을 사용해서 테스트 하도록 하겠습니다.
5.1. 도메인 등록
Route53 대시보드로 이동합니다.
호스트 영역 생성
도메인이름 : 'edbae.shop' 을 입력하고 생성합니다.
생성된 결과는 유형이 'ns', 'soa' 가 생성됩니다.
여기에 나온 Name Server (이름서버)값을 도메인 등록사이트의 Name Server에 등록합니다.
참고 : 호스팅 영역당 등록 12시간 후부터는 과금시작이 됩니다. 0.5$/월 입니다. 실습 중에는 참고 하세요.
도메인 설정이 되었으니 다음 과정으로 이동합니다.
5.2. 로드밸런서 도메인 설정
Route53에서 도메인을 등록하였고 로드밸런서용 도메인을 등록하겠습니다.
https://alb.edbae.shop
edbae.shop 호스팅영역에서 레코드생성을 클릭합니다.
레코드 이름을 "alb"로 입력하고 값Info의 별칭을 클릭합니다. "값Info"가 "트래픽 라우팅 대상 Info"로 변경되었습니다.
| -> |
트래픽 라우팅 대상을 "Application/Classic Load Balancer > 서울리전 > dualstack.new-SG-ALB-..." 선택하고 레코드 생성을 클릭합니다.
오토스케일링을 위한 도메인 url이 준비되었습니다. 도메인 등록은 바로 적용되지 않을 수 있으므로 웹사이트가 바로 보이지 않을 수 있습니다.
참고로 오토스케일그룹의 EC2 인스턴스의 웹사이트입니다.
6. ACM 인증서 등록
AWS Certificate Manage(ACM)를 통해 프로비저닝되는 퍼블릭 SSL/TLS인증서는 무료입니다. AWS 리소스에 대해서만 비용을 지불합니다.
ACM(인증서) 메뉴로 가서 TLS 인증서를 발급하도록 하겠습니다.
ACM 메뉴로 이동합니다.
인증서 프로비저닝을 시작합니다.
'공인 인증서 요청'을 선택하고 '인증서 요청'을 클릭합니다.
이제 인증서 요청의 5단계를 시작합니다.
1단계: 도메인 이름 추가
도메인관리사이트에서 등록한 도메인이름("*.edbae.shop")을 기입하고 다음을 클릭합니다.
2단계: 검증 방법 선택
DNS 검증을 선택하고 다음을 클릭합니다.
3단계: 태그 추가
태그는 생략합니다.
요청한 인증서입니다.
인증서ID를 클릭해서 상세페이지로 이동합니다.
인증서 상태는 "검증 대기 중"입니다.
'Route53 레코드 생성'을 클릭합니다.
Route53에서 레코드생성 버튼이 표시됩니다. 하지만 아직, CNAME이 할당되지 않았습니다. 잠시 기다리면 CNAME이 표시됩니다.
CNAME이 생성되었습니다. 레코드 생성을 클릭합니다.
"DNS 레코드를 성공적으로 생성했습니다"라는 메시지가 추가로 표시됩니다.
Route53의 edbae.shop 호스팅 영역에서 발급된 CNAME을 확인할 수 있습니다.
하지만 아직 "검증 대기중"입니다.
검증상태가 "발급됨"가 되면 인증서 발급 절차가 성공적으로 완료됩니다.
HTTPS 인증서를 이용한 사이트 접속이 되는 것을 확인할 수 있습니다.
URL : https://alb.edbae.shop
7. AutoScaling 조정정책 설정
오토스케일링그룹설정 메뉴 > 'new-asg' 선택 후 자동조정 탭을 클릭합니다.
'Dynamic scaling policies'에서 정책생성을 클릭합니다.
스케일링 정책에서
정책유형은 '단순조정'
조정정책이름은 'scale-out-policy'
cloudwatch 경보에서는 '경보생성'을 클릭합니다.
지표 및 조건 지정에서 지표선택을 클릭합니다.
지표선택 목록에서 EC2를 선택하고 AutoScaling Group별 선택 후 'new-ASG'의 CPU Utilization 선택하고 지표를 선택합니다.
선택 후 화면입니다.
(참고로 cloud watch 1분이하 단위부터는 과금대상입니다)
조건에서 임계값유형(정적), CPU조건(보다 크거나 같음), 보다 (70)을 입력하고 다음을 클릭합니다.
단계2 작업구성
알림은 경보상태
SNS주제 선택은 앞서 입력한 'scale-in-out'를 선택합니다. 입력한 이메일은 자동선택됩니다.
단계3 이름 및 설명 추가
경보이름은 'SCALE-OUT-ALERT'로 입력하고 다음을 클릭합니다.
단계4 미리보기 및 생성에서 경보를 생성합니다.
이제 오토스케일링 그룹 설정의 스케일링정책에서
cloudwatch 경보를 갱신해서 생성한 'SCALE-OUT-ALERT'을 선택하고 경보 연속 개수는 기간당 임계치에서 발생으로 설정합니다.
실습에서는 작업추가 1건 용량 단위, 300초대기로 하여 생성합니다.
Scale-In 경보를 추가적으로 등록하겠습니다.
자동조정 탭에서 스케일링 정책생성을 클릭합니다.
정책유형은 '단순조정'
조정정책이름은 'scale-in-policy'
cloud watch 경보는 생성을 클릭하여 설정합니다.
지표 및 조건 지정에서 지표 선택을 클릭하고 EC2를 선택하고 AutoScaling Group별을 선택하고 new-ASG의 CPU Utilization을 선택후 지표선택을 클릭합니다.
조건은 '임계값유형(정적), CPU 조건은 '보다작거나 같음', 값은 '30'을 입력하고 다음을 클릭합니다.
시연용으로 Scale In/Out을 신속히 확인하기 위하여 범위를 넓게 설정합니다.
단계2 작업구성에서
경보상태 트리거는 경보상태, SNS주제선택은 기존SNS주제선택, 알림전송은 'scale-in-out
단계2이름 및 설명추가
단계4 미리보기 및 생성에서
생성을 클릭하여 생성합니다.
cloudwatch 경보를 갱신해서 생성한 'SCALE-IN-ALERT'선택하고 경보연속 개수는 기간당 임계치에서 발생설정을 하고 작업 '제거', 1건, 용량단위는 300초 대기로 하여 저장합니다.
Auto Scaling Group의 조정정책이 등록되었습니다.
EC2 메뉴로 이동하면 현재 설정한 Auto Scaling 이 작동중인 것을 확인할 수 있습니다.
오토스케일링으로 운영중인 인스턴스의 태그명은 "web-asg"입니다.
로드밸런싱에서 설정한 대상그룹에는 등록된 대상으로 web-asg 가 표시되고 있습니다.
그럼 오토스케일링이 스케일 인/아웃이 되는지 확인해 보도록 하겠습니다.
8. 부하테스트
CPU 부하테스트 대상은 인스턴스의 수를 2개에서 4개까지 scale out, scale in 수행을 합니다.
그럼 각 인스턴스에 대하여 CPU 과부하 스트레스 테스트로 측정해 보겠습니다.
앞서 설정한 내용에 따라 경보가 발생해서 scale-in, scale-out이 발생하는데 5분이상 유지해야 됩니다.
8.1. 스케일 아웃(Scale-out)
CPU 과부하 테스트로 인스턴스의 수가 2개에서 3개 또는 4개까지 확장될 수 있습니다.
SSH 클라이언트 연결 명령어로 2개의 인스턴스에 대하여 CPU 과부하 생성
# CPU 과부하 99% 생성
$ yes > /dev/null &
# top 명령어로 모니터링
$ top
top 명령어로 모니터링하면서 scale out, scale in 되는지를 확인합니다.
Auto Scaling 그룹의 모니터링 탭에서 "CloudWatch 모니터링 세부정보"로도 확인이 가능합니다.
인스턴스의 수가 변경되었습니다.
작업기록을 확인하니 "SCALE-OUT-ALERT" 경보가 발생했습니다.
EC2 인스턴스메뉴에서 인스턴스 수를 확인해보겠습니다.
| 3번째 인스턴스가 생성되었습니다. |
잠시 후 4번째 인스턴스도 생성되었습니다.
작업기록에 "SCALE-OUT-ALERT" 경보가 발생하였습니다.
인스턴스는 대상그룹의 가용영역 범위내에서 생성이 됩니다.
8.2. 스케일 인(Scale-In)
CPU 과부하 테스트를 종료하겠습니다. CPU인스턴스의 수가 3~4개에서 2개까지 감소하는 현상을 확인하겠습니다.
첫번째, 두번쨰 인스턴스에서 CPU 과부하 프로세스를 제거합니다. top 명령어로 CPU 유휴 상태를 확인합니다.
잠시 대기 중입니다.
작업기록에 "SCALE-IN-ALERT" 경보가 발생했습니다.
아직 진행중이며 인스턴스에도 변화가 생겼습니다.
오토스케일링 조정정책에 따라 작업에서, 인스턴스의 확장은 신속한 반면, 축소는 상대적으로 느린 편입니다.
또, 축소 대상 인스턴스에 작업이 처리 중이라면 작업이 완료될 때까지 대기를 합니다.
1개의 인스턴스가 종료되었습니다.
종료된 인스턴스
CPU 유휴 상태로 인하여 "SCALE-IN-ALERT" 경보가 발생하였습니다.
첫번째, 두번쨰 인스턴스에서 CPU 과부하 프로세스를 제거합니다. top 명령어로 CPU 과부하 상태를 확인합니다.
인스턴스 상황에도 변화가 생겼습니다.
CPU 유휴 상태로 인하여 최소 인스턴스 2개만을 실행하도록 하는 상태가 되었습니다.
이상, AWS 인프라 구축 실습 9회 - AutoScaling 이였습니다.
다음과정에서는 AWS 인프라 구축 실습 10회 S3에 대하여 실습해보겠습니다.
'[AWS 기타]' 카테고리의 다른 글
| AWS-Vault (0) | 2024.07.28 |
|---|---|
| VPN이란 무엇인가? (0) | 2023.02.08 |
| [AWS] Nitro system 이란?(AWS 5세대 인스턴스) (0) | 2023.01.22 |
| Squid로 NAT 인스턴스에 DNS 필터링을 추가하는 방법 (0) | 2023.01.19 |
| AWS - Route53 (0) | 2023.01.19 |
