Auto Scaling
컴퓨팅 리소스의 규모나 사이즈(scale)를 조절하는 것을 스케일링이라고 한다. 사이즈를 키우거나(scale up), 줄이거나(scale down), 규모를 확장하거나(scale out), 축소하며(scale in) 컴퓨팅 리소스를 조절해 가용성과 안정성을 확보하고 비용을 효율적으로 관리할 수 있다.
이러한 스케일링 작업 중 용량 확장과 축소를 클라우드 상에서 자동으로 수행하는 것을 오토스케일링이라고 하고, AWS에선 Auto Scaling Group(ASG)를 통해 EC2 인스턴스들을 하나의 논리적인 단위로 묶어 scale in/out을 자동으로 수행할 수 있다.
ASG는 Multi-AZ이다. 여러 가용영역을 걸쳐 설정할 수 있지만 한 리전 내에서만 할 수 있다.
인스턴스 개수 한도
ASG의 EC2인스턴스 수의 최소치와 최대치, 그리고 목표치를 정할 수 있다.
목표 용량에 최대한 맞춰지겠지만, 목표 용량은 절대적인 것이 아니다. 용량의 우선순위는 최소, 최대 >> 목표이다. 만약 최소치에 도달하면 목표 용량이 그보다 낮아도 더 줄어들지 않고, 최대치에 도달하면 목표 용량이 그보다 높아도 더 확장되지 않는다.
ASG 내의 EC2 인스턴스 생명주기
ASG에 등록된 EC2 인스턴스의 스케일링 상 라이프사이클은 아래와 같다.
Scale out이 필요한 상황에서 그룹 내의 EC2 인스턴스 용량을 맞추기 위해 인스터스가 실행되고 정상적으로 ASG에 등록이 되면 `InService` 상태가 된다. Scale in이 필요한 상황에서 EC2 인스턴스는 `Terminating` 상태로 돌입하며 이 때 인스턴스는 그룹에서 해지된다.
Standby
위의 라이프사이클을 보면 알겠지만, 자동으로 수행되는 과정 이외에도 사용자가 직접 인스턴스를 분리(detach)시킬 수도 있고, 필요하다면 `Standby`로 전환 시킬 수 있다. `Stanby` 상태의 인스턴스는 그룹 용량에 포함되어 자동 관리되지만, 서비스 대상은 아니다. 사용자가 특정 인스턴스의 문제를 해결하기 위해 `Standby`로 전환시키고 문제가 해결되면 다시 서비스 상태로 되돌려 해당 인스턴스를 가용할 수 있다.
EC2 인스턴스의 비용은 그룹과는 별개이다. 인스턴스가 시작된 순간부터 비용이 과금되며, `Standby` 상태로 돌입하더라도 비용이 부과된다.
Lifecycle Hook
그룹 내의 인스턴스가 새로 시작되거나 종료될 때 사용자가 특정한 작업을 Lifycycle Hook를 사용해 추가할 수 있다. Lifecycle Hook가 있다면 인스턴스가 등록되거나 종료될 때 Lifecycle Hook의 작업이 완료되어야만 `InService`나 `Terminated` 상태로 돌입한다.
Lifecycle Hook를 통해 인스턴스 시작 시 bootstrap 스크립트를 실행시키거나 ELB에 등록되어 트래픽을 받을 준비를 하고, 인스턴스 종료 시에는 로그나 데이터를 옮길 수 있다.
Lifecycle Hook는 기본 1시간으로 설정된 제한 시간을 가지고, 제한 시간 내에 작업이 완료되면 다음 상태로 넘어갈 수 있다. 작업이 성공하지 못했다면 제한 시간까지 기다렸다가 제한 시간 후 다음 상태로 전환된다.
EC2 인스턴스의 상태 확인
ASG는 그룹 내의 EC2 인스턴스의 health check를 통해 인스턴스의 가용성을 확인하고 용량을 조절한다. Health check는 EC2 인스턴스에서 직접 확인할 수도 있고, ELB, VPC Lattice, EBS 등의 다른 AWS 서비스를 통해 수행될 수 있다.
EC2 인스턴스
EC2 인스턴스를 통한 health check는 간단하다. 인스턴스의 상태가 `running`인지 확인되면 된다. 별개로 인스턴스의 특정 메타 데이터를 health check로 사용하도록 사용자가 정의할 수도 있다.
ELB
일반적으로 ASG는 ELB와 연결되어 사용된다. 하지만 기본적으론 ASG는 ELB의 Health Check를 사용하지 않는다. ASG에 등록된 EC2 인스턴스는 연결된 ELB에도 등록되며, ASG가 Health Check를 수행하기 위해선 EC2 인스턴스로부터 직접 상태를 확인한다.
이 때는 ASG가 인스턴스의 Health Check 후, 인스턴스가 `running`이 아니라면 ASG는 해당 인스턴스의 종료를 시작한다. 그 때 인스턴스는 ASG에 연결된 ELB의 라우팅 대상에서 drain된다.
인스턴스가 새롭게 등록될 때 또한 마찬가지로 먼저 ASG에 등록된 후, ELB에 라우팅 대상으로 포함된다.
ELB의 Health Check를 ASG가 직접 사용할 수 있도록 설정할 수 있다.
ELB는 등록된 인스턴스를 해제하더라도 인스턴스의 상태에 관여하지 않는다. ELB의 Health Check를 직접적으로 ASG가 사용한다면 ELB가 정상적이지 않은 인스턴스를 종료시키며 상태관리에 관여할 수 있게된다. VPC Lattice도 마찬가지다.
ELB에 연결한다면 ELB Health Check는 권장사항이다.
EBS
특이한 점이 있다면, ASG의 Health Check 방식으로 EBS 상태 확인을 활성화할 수 있다. Nitro 시스템에 구축된 인스턴스를 대상으로 EBS 볼륨을 확인할 수 없거나 I/O 상태 확인에 실패한다면 ASG는 인스턴스를 비정상 인스턴스로 간주해 종료시킨다.
스케일링 기준 - Scaling Policy
ASG의 인스턴스 용량을 자동으로 스케일링하기 위해선 특정한 기준이 필요하다. 최소, 최대, 목표 용량 설정을 변경해 스케일링 이벤트를 트리거할 수도 있지만, 특정한 기준을 Target Metric으로 삼아 동적, 혹은 예상 조정이 가능하다.
이러한 기준들이 있더라도 허용 가능한 범위는 여전하다. 아무리 기준 지표가 낮더라도 ASG의 최소 용량보다 낮아질 수 없으며, 특정 설정이 없으면 최대치를 초과할 수 없다.
Dynamic Scaling Policy
동적 조정 정책으로는 특정한 정보를 타겟으로 삼는 target tracking scaling, CloudWatch의 특정 알람 정도에 따라 특정 수를 스케일링하는 step scaling이 있다. simple scaling도 있지만 여기에 단계별로 점진적인 조정을 추가한 것이 step scaling이기 때문에 target tracking과 step scaling만 짚고 넘어가면 될 것 같다.
Target tracking scaling은 ASG 생성 시에도 설정할 수 있다.
Target metric으로는 위와 같이 CPU사용량, 네트워크 처리량, ALB 요청 수(ALBRequestCountPerTarget) 등 용량을 결정할 때 일반적으로 유용한 지표가 기본적으로 존재한다. 트래픽이 증가할 때 변화가 심한 지표들이다. 이 때 변화들은 기본적으로 5분마다 모니터링된다. 세부 모니터링을 1분마다 진행할 수 있지만, 추가 과금이다. 다 돈이다.
이와 별개로 사용자 정의의 CloudWatch metric을 선택할 수도 있다. SQS의 인스턴스 당 대기열의 메세지(ApproximateNumberOfMessages)도 유용하게 사용될 수 있는 지표지만, AWS에서는 지표 수학을 이용하는 것을 권장한다.
Step scaling과 simple scaling은 ASG를 생성 후에 만들 수 있다.
특정 지표에 대한 단계를 추가하며 생성할 수 있고, 지표의 50%를 기준으로 했을 때의 작동 방식에 대한 예시는 아래와 같다.
지표가 50%를 기준으로 초과했을 때의 단계가 왼쪽 표만큼이고, 50%미만일 때의 단계가 오른쪽 표만큼이다.
Predictive Scaling
트래픽이 늘어나 스케일 아웃이 자동으로 수행된다고 해도 인스턴스가 시작되면서 걸리는 시간으로 인해 다운타임이 생길 수도 있다. 트래픽이 정기적으로 몰린다면, 몰리기 전에 미리 인스턴스가 올라가 있다면 바람직할 것이다. ASG의 과거 2주까지의 데이터를 기반으로 ML기반의 분석을 통해 예측 조정이 그러한 역할을 할 수 있다.
특정 지표를 기반으로 과거 이벤트들을 분석해 예측을 통해 인스턴스들을 미리 켜놓거나 미리 줄임으로써 리소스 가용을 최적화 할 수 있다.
예측된 용량이 ASG의 최대치보다 더 클 수도 있다. 마지막 옵션을 활성화하면 그러한 상황에서 최대치를 조정할 수 있다.
Scheduled Scaling
크론잡으로 특정 시간에 목표, 최소, 최대 용량을 변경할 수도 있다.
트래픽이 없는 새벽에 목표치를 줄이거나 트래픽이 예상되는 시간에 목표나 최대치를 예약 기반 조정으로 올릴 수 있다.
Launch Template
ASG가 목표 용량에 맞춰 인스턴스를 생성할 때 Launch Template을 사용해 사전에 설정된 템플릿을 따라 일정하게 인스턴스를 생성한다. 예전엔 Launch Configuration이 존재했지만 현재는 아예 Launch Template으로 바뀌었다.
Launch Template을 통해 ASG가 새로 생성할 인스턴스의 AMI, 인스턴스 타입, 키페어, 네트워크 및 보안그룹 설정, 그리고 EC2 고급설정 등을 정해놓을 수 있다.
Launch Template은 static한 설정이다. 만약 변경되어야 한다면 기존 template을 변경하는 것이 아닌 기존 template의 설정에서 일부 변경된 template을 새로 만들어야 한다. 그렇게 새로 만든 template을 버전 관리를 할 수도 있다.
ASG는 사실 시험에서 많이 나온 부분은 없는 것 같다. ASG에 대한 지식을 기반으로 한 다른 서비스 문제는 나온 적이 있지만, ASG에 대한 특정적이거나 세세한 문제는 나오지 않았던 것 같다. 그래도 알면 분명 도움이 될 것이라고 생각한다. 다루진 못했지만 instance refresh, instance maintenance policy, warm pool, capacity provider 등 ASG와 관련된 내용도 많은 것 같다.
'DevOps > AWS' 카테고리의 다른 글
| AWS SAA - Elastic Load Balancer & Elastic Beanstalk (0) | 2024.11.03 |
|---|---|
| AWS SAA - EC2 & AMI (3) | 2024.11.01 |
| AWS Certified Solution Architect - Associate (AWS SAA) 시작 (2) | 2024.10.31 |
