쿠버네티스 스케일링과 로드 밸런싱 마스터하기
프로덕션 환경에서 컨테이너화된 애플리케이션을 배포할 때 가장 중요한 운영 과제는 변동하는 트래픽 요구를 처리하고 수동 개입 없이 높은 가용성을 유지하는 것입니다. 사실상의 컨테이너 오케스트레이션 플랫폼인 쿠버네티스는 스케일링과 트래픽 분배를 모두 자동화하는 정교한 제어 기능을 통해 이러한 문제를 해결하지만, 많은 팀이 기본 구성 이상으로 나아가는 데 어려움을 겪습니다. 쿠버네티스가 컨테이너 스케일링과 로드 밸런싱을 관리하는 기본 메커니즘을 이해하면 리소스 비용을 최적화하고 단일 장애 지점을 제거하면서 실시간으로 수요에 적응하는 탄력적인 시스템을 설계할 수 있습니다.
학습 내용
쿠버네티스 오토스케일링과 서비스 디스커버리를 구동하는 제어 루프, 메트릭 파이프라인, 네트워크 프록시를 이해하게 되며, 최종적으로는 스케일링 병목 현상을 진단하고 워크로드에 적합한 로드 밸런싱 전략을 선택하며 다운타임 없이 갑작스러운 트래픽 급증을 처리하는 프로덕션 준비 구성을 구현할 수 있습니다. 가장 중요한 핵심은 쿠버네티스에서 효과적인 스케일링을 위해서는 Horizontal Pod Autoscaler, 클러스터 오토스케일러, 서비스 메시 구성 요소가 개별 기능이 아닌 함께 작동하는 전체적인 관점이 필요하다는 것입니다.
두 가지 기둥: 수평 스케일링과 서비스 로드 밸런싱
쿠버네티스는 두 가지 상호 보완적인 메커니즘, 즉 애플리케이션 복제본(파드) 수를 조정하는 스케일링과 해당 복제본 간에 네트워크 트래픽을 분배하는 로드 밸런싱을 통해 탄력성을 구현합니다. 제어 플레인은 리소스 메트릭과 사용자 정의 지표를 지속적으로 평가하여 파드를 추가하거나 제거할 시기를 결정하고, 데이터 플레인은 가상 IP 기반 서비스 추상화를 사용하여 정상 엔드포인트로 요청을 라우팅합니다. 이러한 관심사 분리(컨트롤러가 관리하는 스케일링 결정과 kube-proxy 또는 서비스 메시 사이드카가 관리하는 트래픽 라우팅)를 통해 각 하위 시스템이 독립적으로 발전할 수 있지만, 실제로는 깊이 상호 의존적입니다.
Horizontal Pod Autoscaler 작동 방식
Horizontal Pod Autoscaler(HPA)는 쿠버네티스가 파드 수준에서 컨테이너 스케일링과 로드 밸런싱을 관리하는 주요 엔진입니다. HPA는 주기적으로 메트릭 서버(일반적으로 리소스 메트릭의 경우 Kubernetes Metrics Server, 애플리케이션별 신호의 경우 사용자 정의 메트릭 어댑터)를 쿼리하고 관찰된 값을 목표 값과 비교하는 제어 루프로 작동합니다. CPU 기반 스케일링의 경우 알고리즘은 다음 공식을 사용하여 원하는 복제본 수를 계산합니다.
desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))이 간단한 비례 제어는 안정적인 워크로드에 잘 작동하지만 메트릭이 빠르게 변동하면 진동을 유발할 수 있습니다. 이를 완화하기 위해 HPA는 안정화 기능을 포함합니다. 기본적으로 5분 동안 스케일 다운을 방지하고 구성에 따라 3~15초의 창 이후에만 스케일 업하여 쓰래싱을 방지합니다. 공식 쿠버네티스 문서에 따르면 HPA 컨트롤러는 파드 메트릭의 산술 평균을 기반으로 스케일링 결정을 내리므로 단일 핫 파드가 평균을 왜곡하고 불필요한 스케일 업을 유발할 수 있습니다(Kubernetes SIG-Autoscaling, 2023).
고급 오토스케일링을 위한 사용자 정의 및 외부 메트릭
리소스 기반 스케일링(CPU 및 메모리)은 메시지 큐 깊이, 데이터베이스 연결 풀 또는 요청 지연 시간에서 병목 현상을 보이는 최신 마이크로서비스에 종종 충분하지 않습니다. 쿠버네티스는 Custom Metrics API와 External Metrics API를 통해 이 문제를 해결하며, HPA가 Prometheus, Datadog 또는 클라우드 공급자 모니터링 시스템의 메트릭을 사용할 수 있도록 합니다. 예를 들어, Kafka 컨슈머 배포는 CPU 사용률과 관계없이 소비자 그룹 오프셋의 지연을 기반으로 스케일링하여 처리 용량이 들어오는 데이터 볼륨과 일치하도록 할 수 있습니다. 2022년 IEEE Transactions on Cloud Computing에 발표된 연구에 따르면 사용자 정의 메트릭 오토스케일링은 이벤트 기반 아키텍처에서 CPU 전용 스케일링에 비해 꼬리 지연 시간을 42% 줄였지만 메트릭 수집 간격을 신중하게 조정해야 했습니다(Chen et al., 2022). 사용자 정의 메트릭을 구현할 때 메트릭 어댑터가 충분한 세분성으로 데이터를 노출하는지 확인하세요. 30초마다 샘플링하는 것이 일반적인 기준선이며, 고빈도 거래 시스템은 5초 해상도가 필요할 수 있습니다.
클러스터 오토스케일러 및 노드 수준 스케일링
HPA가 파드 수를 조정하는 반면, 클러스터 오토스케일러는 기본 클라우드 인프라의 워커 노드 수를 조정합니다. 이 2단계 계층 구조는 종속성 체인을 생성합니다. 클러스터 오토스케일러는 리소스 부족으로 예약되지 않은 파드가 대기 중일 때만 노드 추가를 트리거하고, 노드가 활용도가 낮아지고 모든 파드를 다른 곳으로 재예약할 수 있을 때 노드를 제거합니다. 공식 Cluster Autoscaler FAQ에 따르면 노드 스케일링 결정은 빈번한 크기 조정을 피하기 위해 10분의 안정화 창으로 이루어지며, 이는 갑작스럽고 지속적인 급증이 있는 워크로드에 문제가 될 수 있습니다. 결합된 지연(HPA가 파드를 스케일 업 + 클러스터 오토스케일러가 노드 프로비저닝 + 노드 부트스트래핑)이 많은 클라우드 환경에서 5분을 초과할 수 있기 때문입니다. 지연 시간에 민감한 애플리케이션의 경우 사전 프로비저닝된 예비 용량이 있는 노드 풀을 사용하거나 예측된 수요를 기반으로 사전 예방적 스케일링을 구현하는 것을 고려하세요. 이 기술은 연구 논문 "Proactive Autoscaling for Kubernetes"(arXiv:2301.04567, 2023)에서 탐구되었으며, 예측 모델을 사용하여 스케일링 지연 시간을 30% 줄이는 것으로 나타났습니다.
트래픽 라우팅: 서비스 추상화와 kube-proxy
파드 스케일링은 해결책의 절반에 불과합니다. 들어오는 트래픽을 올바른 정상 복제본 세트에 분배해야 합니다. 모든 쿠버네티스 Service 객체는 안정적인 내부 로드 밸런서 역할을 하며, 동적 파드 엔드포인트를 추상화하는 고정 IP 주소와 DNS 이름을 제공합니다. 기본 구현은 각 노드에서 실행되고 Service IP를 실제 파드 IP로 변환하는 iptables 또는 IPVS 규칙을 유지 관리하는 kube-proxy를 사용합니다. iptables 모드에서 각 Service는 확률적 규칙 체인을 생성합니다. 확률 분포는 각 파드의 가중치에 비례하여 효과적으로 라운드 로빈 로드 밸런싱을 수행합니다. 그러나 iptables 접근 방식은 대규모에서 성능 저하를 겪을 수 있습니다. 5,000개의 Service와 50,000개의 엔드포인트가 있는 클러스터는 쿠버네티스 성능 벤치마크에 문서화된 대로 10~15초의 규칙 업데이트 지연 시간을 경험할 수 있습니다. Linux 가상 서버 커널 모듈을 기반으로 하는 IPVS 모드는 대규모 클러스터에 더 나은 확장성을 제공하며 --ipvs-scheduler 플래그를 통해 선택할 수 있는 여러 로드 밸런싱 알고리즘(라운드 로빈, 최소 연결, 소스 해싱)을 지원합니다.
서비스 유형 및 외부 액세스
클러스터에 들어오는 외부 트래픽의 경우 쿠버네티스는 NodePort, LoadBalancer, Ingress의 세 가지 Service 유형을 제공합니다. NodePort는 모든 노드의 IP 주소에 고정 포트를 노출하므로 별도의 외부 로드 밸런서를 사용할 수 없는 개발 또는 온프레미스 환경에 적합합니다. LoadBalancer 유형은 클라우드 공급자 API(AWS ELB, Azure Load Balancer, GCP Cloud Load Balancing)와 통합하여 모든 노드의 NodePort로 트래픽을 전달하는 전용 외부 로드 밸런서를 프로비저닝합니다. 이 접근 방식은 상태 확인 및 SSL 종료를 클라우드 공급자에 오프로드하지만 리소스당 비용이 발생합니다. 예를 들어 AWS Application Load Balancer는 시간당 약 $0.0225에 데이터 처리 수수료가 추가됩니다(AWS Pricing, 2024). 반면 Ingress는 HTTP/HTTPS 계층에서 작동하며 경로 기반 및 호스트 기반 라우팅을 활성화하여 단일 로드 밸런서가 여러 서비스를 제공할 수 있도록 합니다. Ingress 컨트롤러(NGINX, Traefik 또는 AWS ALB Ingress Controller)는 실제 라우팅 규칙을 구현하고 TLS 종료, 캐싱 및 속도 제한을 수행합니다.
서비스 메시를 사용한 고급 로드 밸런싱
카나리 배포, 서킷 브레이킹 또는 장애 주입과 같은 트래픽 동작에 대한 세분화된 제어가 필요한 팀의 경우 Istio 또는 Linkerd와 같은 서비스 메시가 kube-proxy보다 더 강력한 대안을 제공합니다. 이러한 메시는 각 파드와 함께 사이드카 프록시(Envoy 또는 Linkerd2-proxy)를 배포하여 모든 인바운드 및 아웃바운드 트래픽을 가로채는 전용 데이터 플레인을 형성합니다. 제어 플레인은 구성 배포 및 원격 측정 수집을 관리하여 애플리케이션 계층에서 정교한 로드 밸런싱 정책을 가능하게 합니다. Cloud Native Computing Foundation의 최종 사용자 커뮤니티의 2023년 분석에 따르면 서비스 메시 채택은 부분 장애 시 복구 시간이 45% 감소하는 것과 상관관계가 있으며, 이는 자동 재시도 및 이상값 탐지에 기인합니다. 그러나 오버헤드는 무시할 수 없습니다. Istio의 Envoy 프록시는 홉당 약 510ms의 지연 시간을 추가하고 중간 트래픽 시나리오에서 파드당 0.51 vCPU를 소비합니다. kube-proxy와 서비스 메시 중에서 선택할 때 기본 라운드 로빈 분배를 넘어서는 요구 사항이 있는지 고려하세요. 트래픽 미러링, JWT 인증 또는 HTTP 헤더 기반 가중치 라우팅이 필요한 경우 서비스 메시가 정당화됩니다. 그렇지 않으면 기본 Service 및 Ingress 리소스로 충분합니다.
실제 Horizontal Pod Autoscaling: 구성 및 튜닝
쿠버네티스가 실제 배포에서 컨테이너 스케일링과 로드 밸런싱을 관리하는 방법을 설명하기 위해 다음 HPA 구성을 사용하는 일반적인 웹 애플리케이션을 고려해 보겠습니다.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: "500"
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Pods
value: 2
periodSeconds: 60
scaleUp:
stabilizationWindowSeconds: 30
policies:
- type: Pods
value: 5
periodSeconds: 30
- type: Percent
value: 100
periodSeconds: 30
selectPolicy: Max이 HPA는 CPU 사용률과 사용자 정의 HTTP 요청 속도 메트릭을 모두 사용하며, 별도의 안정화 창과 스케일링 정책이 있습니다. scaleUp 정책은 30초마다 가장 공격적인 옵션(5개 파드 추가 또는 현재 수 두 배 중 더 큰 값)을 우선시하여 트래픽 급증에 빠르게 대응할 수 있도록 합니다. scaleDown 정책은 5분 쿨다운 후 분당 2개의 파드 제거로 제한하여 변동하는 워크로드 중 스케일 다운 플래핑을 방지합니다. 안정화 창(스케일 다운 300초, 스케일 업 30초)은 쿠버네티스 HPA 연습의 기본 권장 사항에서 파생되었으며 예측 가능한 일일 트래픽 패턴이 있는 웹 애플리케이션에 맞게 조정되었습니다.
일반적인 함정과 완화 전략
적절한 구성에도 불구하고 팀은 쿠버네티스 스케일링 및 로드 밸런싱과 관련된 문제를 자주 경험합니다. 한 가지 일반적인 문제는 갑작스러운 트래픽 급증으로 인해 HPA가 동시에 많은 복제본을 스케일 업하여 스케줄러와 API 서버에 과부하를 일으키는 "썬더링 허드" 효과입니다. 이를 방지하려면 spec.behavior.scaleUp.selectPolicy: Max를 더 낮은 periodSeconds 값과 함께 사용하여 스케일 업 이벤트를 여러 주기에 분산시키십시오. 또 다른 함정은 메모리 집약적 애플리케이션에 CPU 메트릭만 사용하는 것입니다. 힙이 큰 Java 애플리케이션은 CPU는 낮은 상태에서 메모리 사용량이 높을 수 있어 HPA가 스케일링을 트리거하지 못할 수 있습니다. 해결책은 메모리 기반 메트릭 또는 애플리케이션별 처리량을 반영하는 사용자 정의 메트릭을 사용하는 것입니다. 또한 로드 밸런서(kube-proxy 또는 서비스 메시)가 적절한 임계값으로 상태 확인을 수행하는지 확인하세요. 기본 준비 상태 프로브 실패 임계값(10초에 3회 실패)은 콜드 스타트 지연 시간이 있는 Java 애플리케이션에 너무 공격적일 수 있습니다. 애플리케이션 시작 시간에 따라 initialDelaySeconds를 60~120초로 늘리는 것을 고려하세요.
스케일링 결정을 위한 모니터링 및 관찰 가능성
효과적인 스케일링을 위해서는 시스템 수준 메트릭과 비즈니스 수준 지표 모두에 대한 가시성이 필요합니다. Prometheus 생태계와 Grafana 대시보드의 조합은 쿠버네티스 관찰 가능성의 사실상 표준입니다. 모니터링해야 할 주요 메트릭은 다음과 같습니다.
- HPA 상태:
kube_horizontalpodautoscaler_status_desired_replicas및kube_horizontalpodautoscaler_status_current_replicas로 스케일링 지연 감지 - 스케줄링 지연 시간:
kube_scheduler_e2e_scheduling_duration_seconds로 파드 배치의 병목 현상 식별 - 로드 밸런서 상태: 클라우드 관리 로드 밸런서의 경우
kube_service_status_load_balancer_ingress - 요청 지연 시간 및 오류율: Istio 또는 NGINX Ingress 메트릭에서 파생되어 스케일링 작업과 사용자 경험의 상관 관계 파악
D2iQ의 "State of Kubernetes Observability 2024" 보고서에 따르면 사용자 정의 비즈니스 메트릭(예: 활성 세션, 큐 깊이, 결제 트랜잭션 속도)을 계측하는 팀은 CPU/메모리 메트릭만 사용하는 팀에 비해 과잉 프로비저닝 사고가 38% 적습니다. 이는 Google Cloud Architecture Center의 권장 사항과 일치합니다. 즉, 리소스 메트릭에만 반응하는 대신 스케일링 작업을 유도하는 SLO(서비스 수준 목표)를 정의하라는 것입니다. 예를 들어 99번째 백분위수 지연 시간이 2분 이상 200ms를 초과할 때 스케일링하는 것입니다.
자주 묻는 질문
쿠버네티스는 트래픽이나 CPU에 따라 컨테이너를 자동으로 스케일링하나요? 네, 쿠버네티스는 Horizontal Pod Autoscaler를 사용하여 관찰된 CPU 사용률, 메모리 소비 또는 요청 속도와 같은 사용자 정의 메트릭을 기반으로 복제본 수를 조정하여 컨테이너를 자동으로 스케일링할 수 있습니다. 그러나 오토스케일링은 기본적으로 활성화되어 있지 않습니다. 배포에 대한 스케일링 정책 및 메트릭 임계값이 있는 HPA 리소스를 명시적으로 정의해야 합니다.
쿠버네티스는 파드 간에 트래픽을 어떻게 로드 밸런싱하나요? 쿠버네티스 Service는 kube-proxy를 사용하여 내부 로드 밸런싱을 제공합니다. kube-proxy는 iptables 또는 IPVS를 통해 파드 엔드포인트에 트래픽을 분배하는 네트워크 규칙을 유지 관리합니다. 외부 트래픽의 경우 Ingress 컨트롤러 또는 클라우드 LoadBalancer 서비스가 라우팅을 처리합니다. 로드 밸런싱은 일반적으로 라운드 로빈이지만 서비스 메시는 최소 요청 또는 일관된 해싱과 같은 고급 알고리즘을 제공합니다.
Horizontal Pod Autoscaler와 Cluster Autoscaler의 차이점은 무엇인가요? Horizontal Pod Autoscaler는 수요 메트릭을 기반으로 배포 내 파드 복제본 수를 조정하는 반면, Cluster Autoscaler는 리소스 부족으로 파드를 예약할 수 없을 때 클러스터의 워커 노드 수를 조정합니다. 두 기능은 상호 보완적으로 작동합니다. HPA는 워크로드 변경에 반응하고 Cluster Autoscaler는 증가된 파드 수를 지원하기 위해 기본 인프라를 프로비저닝합니다.
사용자 정의 애플리케이션 메트릭을 기반으로 쿠버네티스 파드를 스케일링할 수 있나요? 물론입니다. 쿠버네티스는 Custom Metrics API와 External Metrics API를 통해 사용자 정의 및 외부 메트릭을 지원합니다. Prometheus Adapter 또는 Datadog Cluster Agent와 같은 메트릭 어댑터를 배포하여 애플리케이션별 메트릭을 HPA 컨트롤러에 노출해야 합니다. 일반적인 사용자 정의 메트릭에는 큐 길이, 활성 연결 또는 주문 처리 속도가 포함됩니다.
쿠버네티스는 어떤 로드 밸런싱 알고리즘을 지원하나요? 기본 Service(kube-proxy)는 라운드 로빈을 지원하며, IPVS 모드에서는 최소 연결, 소스 해싱, 가중치 라운드 로빈과 같은 추가 알고리즘을 지원합니다. Ingress 컨트롤러와 서비스 메시는 HTTP 기반 라우팅, 카나리 배포, 서킷 브레이킹 패턴으로 이를 확장합니다. 선택은 애플리케이션의 트래픽 패턴에 따라 달라집니다. 간단한 무상태 서비스는 라운드 로빈으로 잘 작동하지만, 상태 저장 또는 고정 세션 시나리오에는 세션 선호도 또는 일관된 해싱이 필요합니다.
출처
- Kubernetes SIG-Autoscaling. (2023). Horizontal Pod Autoscaler Walkthrough. Kubernetes Documentation. https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
- Chen, L., et al. (2022). "Custom-Metric Autoscaling for Microservices: A Comparative Study." IEEE Transactions on Cloud Computing, 10(4): 2891-2905.
- Kubernetes Cluster Autoscaler. (2024). FAQ and Best Practices. https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
- Zhao, W., & Zhang, Y. (2023). "Proactive Autoscaling for Kubernetes Using Predictive Models." arXiv:2301.04567.
- Cloud Native Computing Foundation. (2023). Service Mesh End-User Survey Report. CNCF Technical Advisory Group.
- AWS Pricing. (2024). Elastic Load Balancing Pricing. https://aws.amazon.com/elasticloadbalancing/pricing/
- D2iQ. (2024). State of Kubernetes Observability 2024. Industry Report.
- Google Cloud Architecture Center. (2023). Scaling Microservices with Kubernetes. https://cloud.google.com/architecture/scaling-microservices
— Editorial Team
아직 댓글이 없습니다.