Auto Scaling (오토 스케일링)
💡 Auto Scaling이란?
Auto Scaling은 시스템 부하 상황에 따라 리소스를 자동으로 유연하게 조정하는 기능이다.
쿠버네티스도 클라우드 네이티브 도구로서 오토 스케일링 기능을 제공한다.
1. Cluster Autoscaler를 이용한 데이터 플레인(워커 노드) 오토 스케일링
주요 기능
클러스터 오토스케일러는 데이터 플레인(Data Plane, 워커 노드) 인스턴스에 대한 오토 스케일링을 지원한다.
발견적 오토 스케일링(Heuristic Autoscaling) 방식을 사용하며, 파드의 리소스 요청 값을 기준으로 동작한다.
작동 원리
- 새로운 파드를 배포하려고 할 때 요청한 CPU 리소스와 메모리 리소스가 부족하면, 그 파드는 Pending 상태가 된다.
- Pending 상태의 파드가 발생하면 노드가 자동으로 추가된다.
설정 방법
1) IAM 권한 설정: 데이터 노드 권한 수정
데이터 노드의 IAM 역할에 IAM 정책을 추가해야 한다.
데이터 노드로 사용되는 EC2 인스턴스를 찾아서 AutoScalingFullAccess 권한을 부여한다.
EC2 > 데이터 노드 인스턴스 선택 > 상세보기
인스턴스의 IAM 역할 클릭 > AutoScalingFullAccess 권한 추가
- IAM 사용자 권한에 정책 연결: AutoScalingFullAccess
- 오토스케일링 그룹 이름 확인
2) YAML 파일 설정 및 실행
YAML 파일을 만들어서 auto scaling을 활성화 해줘야 한다.
아래에 있는 cluster_autoscaler.yaml 파일을 다운로드 받아서 command 부분의 오토 스케일링 그룹 이름 부분만 수정한다.
# 오토스케일링 그룹 이름 설정 부분을 자신의 설정에 맞게 수정한다.
- 노드 개수
- 노드그룹 이름
command:
- ./cluster-autoscaler
- --v=4
- --stderrthreshold=info
- --cloud-provider=aws
- --skip-nodes-with-local-storage=false
# 오토스케일링 그룹 이름 설정
- --nodes=<노드개수>:5:<오토스케일링 그룹 이름>
YAML 파일 실행
kubectl apply -f cluster-autoscaler.yaml
3) 동작 확인
Cluster Autoscaler 로그를 확인한다.
kubectl logs -f deployment/cluster-autoscaler -n kube-system
replica의 개수 증가시키기
kubectl scale --replicas=20 deployment/backend-app
파드 확인
Pending 상태인 것이 있는지 확인한다.
kubectl get pods
주의사항
- Cluster Autoscaler는 requests 값으로 스케일링을 판단한다.
- 파드를 배치할 때만 스케일링할지 판단할 수 있다.
- 파드가 배치가 되면 노드의 스케줄링은 실행되지 않는다.
- 실제 부하가 작지만 파드의 requests 값이 큰 경우 파드가 스케줄링 되지 못하고 스케일링된다.
- requests 값은 낮지만 limits 설정이 없거나 limits가 아주 높은 값으로 설정된 경우, request 자체에는 아직 리소스에 여유가 있어도 이때 파드를 배포하면 노드에 과부하가 걸리는 상태가 될 수 있다.
2. AWS 오토 스케일링 기능을 이용한 예방적 오토 스케일링
AWS EC2 Auto Scaling 개념 가이드 문서
Amazon EC2 Auto Scaling이란 무엇입니까? - Amazon EC2 Auto Scaling
이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.
docs.aws.amazon.com
주요 개념
- AWS EC2 Auto Scaling은 리소스 부족 상황을 사전에 방지하기 위한 스케일링 방식이다.
- 리소스가 부족해지기 전에 CPU 사용률 등 특정 임계값을 기준으로 스케일링하도록 설정한다.
리소스가 부족해서 파드를 배치할 수 없는 상황이 발생하면 스케일 아웃을 하는 것은 잘못된 방식일 수 있다.
실제 상황에서는 리소스가 부족한 상황이 발생했을 때 스케일 아웃을 하는 것보다, 특정 임계값을 넘었을 때 노드를 추가하는 것이 더 올바른 방식이다. 컨테이너는 빠르게 배포해야 하는데 노드 추가를 기다려야 한다면 컨테이너의 장점을 활용하지 못하는 것이고, 미리 많은 서버를 동작시켜 두는 것도 비용이 많이 발생하기 때문에 비효율적이다. 부하가 얼마나 발생할지, 또는 대기 시간을 얼마나 갖는지 등을 분석하여 적절한 임계값을 사용하는 것이 좋다. 생성되는 파드를 pending 상태로 만들지 않으려면, 노드의 부하가 높아지는 것을 판단할 필요가 있는데 이때 많이 사용되는 매트릭이 CPU 사용률이다.
설정 Tip
- AWS에서는 CloudWatch의 Container Insights를 활성화하면 자동으로 등록된다 : 클러스터 부하를 모니터링 가능
- eksctl 명령어로 클러스터 배포 시 기본 설정을 포함한다.
AWS에서는 다음과 같이 도큐먼트를 제공한다.
https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/scale-your-group.html
스케일링을 통해 애플리케이션의 컴퓨팅 용량을 늘리거나 줄입니다. - Amazon EC2 Auto Scaling
이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.
docs.aws.amazon.com
3. Horizontal Pod Autoscaler(HPA)를 이용한 파드 오토 스케일링
- 노드 오토 스케일링: 파드를 원하는 수만큼 동작시키기 위해 용량을 확보하는 것
- 파드 오토 스케일링: 애플리케이션의 오토 스케일링
Horizontal Pod Autoscaler(HPA)라는 기능을 이용해서 파드의 스케일 아웃 / 스케일 인 기능을 수행할 수 있다.
HPA는 AWS 오토스케일링과 마찬가지로 서비스의 문제 발생을 예방하는 차원에서 설정한다.
파드의 리소스 사용 현황을 모니터링하고 임계값을 넘을 경우 스케일 아웃을 한다.
이로써 애플리케이션의 성능 문제를 예방할 수 있다.
설정 방법
1) Metric Server (메트릭 서버) 배포
메트릭 서버는 파드 리소스 사용 현황을 파악하는 서버이다.
HPA는 메트릭 서버를 통해 리소스 사용량 데이터를 수집한다.
Kubernetes 지표 서버 설치로 검색하면 설치할 수 있다. 자세한 건 다음 페이지에서 확인할 수 있다.
https://github.com/kubernetes-sigs/metrics-server
GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in aut
Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines. - kubernetes-sigs/metrics-server
github.com
설치 명령어
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
설치 확인
kubectl get deployment metrics-server -n kube-system
kubectl get apiservice v1beta1.metrics.k8s.io -o yaml
2) 자원(리소스) 사용량 확인
노드의 자원 소모량 확인
kubectl top node
파드의 자원 소모량 확인
kubectl top pods
3) HPA 리소스 생성을 위한 YAML 파일 작성
HPA 리소스를 생성하기 위한 YAML 파일을 작성한다.
horizontal-pod-autoscaler.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: backend-app
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: deployment
name: backend-app
minReplicas: 2
maxReplicas: 5
targetCPUUtilizationPercentage: 50
- backend-app 이라는 Deployment의 레플리카를 2에서 5까지 증감할 수 있다.
- minReplicas: 최소 파드 개수
- maxReplicas: 최대 파드 개수
- targetCPUUtilizationPercentage: 스케일 아웃 기준 CPU 사용률
- 여기서는 증가하는 기준은 cpu 사용률이 50%를 넘었을 때이다.
- 테스트할 때는 이 값을 낮춰서(예: 5) 확인해본다.
주의사항
1. Cluster Autoscaler의 판단 기준
- requests 값만을 기준으로 스케일링을 판단한다.
- limits 값이 과도하게 설정된 경우, 노드 과부하가 발생할 수 있다.
2. 스케일링 지연 문제
: 리소스 부족으로 Pending 상태가 발생하지 않도록 임계값을 조정할 필요가 있다.
3. HPA 설정 시 CPU/메모리 사용량 고려
: 테스트 환경에서는 임계값을 낮춰 확인한다.