실무에서 자주 마주하는 상황입니다. 대규모 SaaS 서비스를 운영하는 개발 및 운영팀은 Kubernetes 클러스터의 확장성과 유연성을 활용하여 애플리케이션을 안정적으로 제공하고 있습니다. 그러나 예상치 못한 트래픽 증가나 서비스 배포 시마다 클러스터 자원 부족 문제에 직면하거나, 반대로 유휴 자원이 많아 불필요한 비용이 발생하는 상황을 겪곤 합니다. 이러한 자원 비효율성은 결국 클라우드 인프라 비용 상승으로 직결되며, 개발 및 운영 예산에 큰 부담으로 다가옵니다. 안정적인 서비스 운영과 동시에 비용 효율성을 확보하는 것은 모든 클라우드 네이티브 환경의 핵심 목표라 할 수 있습니다.
저희 팀 역시 이러한 도전 과제에 직면했습니다. 목표는 명확합니다. Kubernetes 클러스터의 자원 활용률을 최적화하여 불필요한 비용 지출을 줄이고, 동시에 애플리케이션의 성능과 가용성을 저해하지 않으면서 빠르게 스케일링할 수 있는 메커니즘을 구축하는 것이었습니다. 이는 단순히 인프라 비용을 절감하는 것을 넘어, 서비스 운영의 민첩성과 안정성을 동시에 확보하는 중요한 과정입니다.
도전 과제: 비효율적인 자원 관리와 높은 클라우드 비용
기존에는 주로 Kubernetes의 기본 기능인 Cluster Autoscaler를 활용하여 클러스터 노드를 관리해 왔습니다. Cluster Autoscaler는 유용한 도구이지만, 몇 가지 한계점이 존재합니다. 가장 큰 문제는 노드 프로비저닝 속도입니다. 새로운 노드가 필요한 경우, 기존에 정의된 EC2 Auto Scaling Group에서 인스턴스를 시작하는데 상당한 시간이 소요되어 워크로드 수요 변화에 즉각적으로 대응하기 어렵다는 점입니다. 특히 트래픽이 급증하는 상황에서는 Pod들이 Pending 상태에 머무르다가 서비스 지연이나 장애로 이어지는 경우가 발생하곤 했습니다.
또한, 스팟 인스턴스의 활용에 제약이 많았습니다. Cluster Autoscaler는 주로 온디맨드 인스턴스를 중심으로 작동하며, 스팟 인스턴스를 유연하게 활용하기 위한 복잡한 설정과 관리 부담이 따랐습니다. 이는 비용 최적화 측면에서 큰 손실로 다가왔습니다. 스팟 인스턴스는 온디맨드 인스턴스에 비해 최대 90%까지 저렴한 비용으로 컴퓨팅 자원을 활용할 수 있는 강력한 수단이기 때문입니다. 현장에서 가장 많이 묻는 질문 중 하나는 바로 스팟 인스턴스를 어떻게 안정적으로 활용할 수 있는지에 대한 것입니다.
이 외에도, 클러스터의 노드 타입이 고정되어 있어 다양한 워크로드의 요구사항을 충족하기 어려웠습니다. 메모리 집약적인 워크로드와 CPU 집약적인 워크로드가 혼재하는 환경에서는 단일 노드 타입으로 최적의 자원 활용률을 달성하기 쉽지 않습니다. 결과적으로, 많은 유휴 자원이 발생하거나 특정 노드에서 자원이 고갈되는 비효율적인 상황이 반복되었습니다. 이러한 문제들을 해결하고 더 나은 비용 효율성과 운영 안정성을 확보하는 것이 저희의 핵심 요구사항이었습니다.
기술 선택 과정: Karpenter와 Prometheus의 조합
이러한 도전 과제를 해결하기 위해 여러 솔루션을 검토했습니다. 기존 Cluster Autoscaler의 개선 방안부터 다양한 서드파티 노드 관리 솔루션까지 후보군에 올랐습니다. 그중 Amazon에서 개발한 Kubernetes 노드 프로비저너인 Karpenter가 저희의 요구사항에 가장 부합하는 것으로 판단되었습니다.
후보 기술 비교: Cluster Autoscaler vs. Karpenter
| 특징 | Cluster Autoscaler | Karpenter |
|---|
| 노드 프로비저닝 방식 | EC2 Auto Scaling Group 기반 | 직접 EC2 API 호출, Just-in-Time |
| 프로비저닝 속도 | 상대적으로 느림 (Auto Scaling Group Warmup) | 매우 빠름 (수 초 내) |
| 스팟 인스턴스 활용 | 설정 복잡, 제한적 | 기본 지원, 높은 유연성 |
| 노드 타입 유연성 | Auto Scaling Group 내 고정된 타입 | 워크로드 요구사항에 따라 동적으로 선택 |
| 스케일 다운 | 비활동 노드 제거 | Pod 재스케줄링 고려, 비용 최적화 우선 |
Karpenter는 Just-in-Time 프로비저닝 방식을 사용하여 Pod가 Pending 상태로 감지되면 즉시 해당 Pod의 요구사항에 가장 적합한 노드를 EC2 API를 통해 생성합니다. 이는 기존 Cluster Autoscaler의 Auto Scaling Group 기반 방식보다 훨씬 빠른 노드 준비 시간을 제공합니다. 또한, 스팟 인스턴스, 온디맨드 인스턴스, 다양한 인스턴스 패밀리(C, M, R 타입 등)를 유연하게 활용할 수 있어, 비용 효율성을 극대화할 수 있다는 점이 매력적이었습니다. Karpenter는 심지어 스케줄링 불가능한 Pod가 없더라도, 기존 노드에 분산된 Pod들을 더 작은 수의 노드로 재배치하여 유휴 노드를 줄이는 노드 통합(consolidation) 기능을 통해 비용 절감을 적극적으로 시도합니다.
이와 더불어, 클러스터의 리소스 사용률과 Pod의 상태를 정확히 모니터링하는 것이 중요하다고 판단했습니다. 이를 위해 Kubernetes 모니터링의 사실상 표준인 Prometheus를 선택했습니다. Prometheus는 다양한 Exporter를 통해 Kubernetes 내부 지표뿐만 아니라 노드, Pod, 컨테이너 수준의 상세한 지표를 수집하고 시계열 데이터베이스에 저장할 수 있습니다. 이 지표들은 Karpenter가 노드 프로비저닝 및 스케일 다운 결정을 내리는 데 중요한 통찰력을 제공하며, Grafana와 연결하여 시각화함으로써 클러스터 운영 상태를 한눈에 파악할 수 있게 합니다. Karpenter와 Prometheus를 통합하여 실시간으로 클러스터의 상태를 파악하고, 이에 기반한 최적의 노드 관리를 자동화할 수 있을 것이라는 결론에 도달했습니다.
구현 과정: Karpenter와 Prometheus를 활용한 동적 오토스케일링
이제 Karpenter와 Prometheus를 활용하여 Kubernetes 클러스터의 동적 오토스케일링을 구현하는 구체적인 과정을 설명하겠습니다. 실무에서 바로 적용할 수 있는 YAML/코드 중심의 가이드입니다.
Karpenter 설치 및 초기 설정
Karpenter는 Helm Chart를 통해 쉽게 설치할 수 있습니다. 설치 전에 Karpenter가 EC2 인스턴스를 프로비저닝하고 관리할 수 있도록 적절한 IAM 권한을 부여해야 합니다. 이는 AWS EC2 API에 접근하기 위한 Service Account와 IAM Role을 생성하는 과정이 필요합니다.
먼저, OIDC 공급자를 설정하고 Karpenter가 사용할 IAM Policy를 생성합니다.
aws iam create-policy \
--policy-name KarpenterControllerPolicy-${CLUSTER_NAME} \
--policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateLaunchTemplate", "ec2:CreateFleet", "ec2:RunInstances", "ec2:CreateTags", "ec2:TerminateInstances", "ec2:DeleteLaunchTemplate", "ec2:DescribeLaunchTemplates", "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups", "ec2:DescribeInstanceTypes", "ec2:DescribeInstanceTypeOfferings", "ec2:DescribeAvailabilityZones", "ec2:DeleteTags", "ec2:AssociateAddress", "ec2:DisassociateAddress" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeRole-${CLUSTER_NAME}" }, { "Effect": "Allow", "Action": "ssm:GetParameter", "Resource": "arn:aws:ssm:${AWS_REGION}::parameter/aws/service/ami-amazon-linux-2-recommended/recommendation/image_id" } ] }'
Karpenter 컨트롤러를 위한 IAM Role과 Service Account 생성
(IRSA: IAM Roles for Service Accounts)
TEMP_FILE=$(mktemp)
curl -fsSL https://raw.githubusercontent.com/kubernetes-sigs/karpenter/main/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml > $TEMP_FILE
aws cloudformation deploy
--stack-name Karpenter-${CLUSTER_NAME}
--template-file ${TEMP_FILE}
--capabilities CAPABILITY_NAMED_IAM
--parameter-overrides ClusterName=${CLUSTER_NAME} ClusterEndpoint=${CLUSTER_ENDPOINT}
이후 Helm을 사용하여 Karpenter를 설치합니다.
helm upgrade --install karpenter karpenter/karpenter --namespace karpenter --create-namespace \
--set serviceAccount.create=false \
--set serviceAccount.name=karpenter \
--set clusterName=${CLUSTER_NAME} \
--set clusterEndpoint=${CLUSTER_ENDPOINT} \
--set defaultProvisioner.enablePodDeletion=false
NodePool 및 EC2NodeClass 정의
Karpenter의 핵심은 NodePool과 EC2NodeClass 리소스입니다. NodePool은 노드 프로비저닝 정책을 정의하고, EC2NodeClass는 EC2 인스턴스의 상세 속성(AMI, 보안 그룹, 태그 등)을 정의합니다.
아래 예시는 스팟 인스턴스를 우선적으로 사용하며, 다양한 인스턴스 타입을 포함하는 NodePool 정의입니다.
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2
role: KarpenterNodeRole-${CLUSTER_NAME}
securityGroupSelector:
karpenter.sh/discovery: ${CLUSTER_NAME}
subnetSelector:
karpenter.sh/discovery: ${CLUSTER_NAME}
tags:
karpenter.sh/discovery: ${CLUSTER_NAME}
environment: production
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
nodeClassRef:
name: default
requirements:
- key: karpenter.k8s.aws/instance-category
operator: In
values: [c, m, r]
- key: karpenter.k8s.aws/instance-cpu
operator: Gt
values: ['2']
- key: karpenter.k8s.aws/instance-memory
operator: Gt
values: ['4Gi']
- key: karpenter.k8s.aws/instance-family
operator: In
values: [c5, c5a, m5, m5a, r5, r5a]
- key: karpenter.sh/capacity-type
operator: In
values: [spot, on-demand]
taints:
- key: dedicated
value: critical-workloads
effect: NoSchedule
startupTaints:
- key: karpenter.sh/provisioning
effect: NoSchedule
limits:
cpu: "1000"
memory: "1000Gi"
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: 720h
budgets:
- nodes: 1
이 NodePool 정의는 CPU 2코어 이상, 메모리 4GiB 이상인 C, M, R 인스턴스 패밀리 내에서 스팟 인스턴스를 우선적으로 사용하도록 Karpenter에 지시합니다. 특정 워크로드에 노드를 격리하려면 `taints`를 활용할 수 있습니다.
Prometheus와 Kube-state-metrics를 활용한 지표 수집
Karpenter가 효율적으로 작동하고 클러스터의 상태를 정확하게 파악하기 위해서는 Prometheus를 통한 모니터링이 필수적입니다. 특히 Kube-state-metrics는 Kubernetes API 서버에서 다양한 리소스의 상태를 지표로 노출하여 Prometheus가 수집할 수 있도록 합니다. 이를 통해 Pod의 Pending 상태, 노드의 자원 활용률, 노드 상태 등 Karpenter가 의사결정을 내리는 데 필요한 핵심 정보를 얻을 수 있습니다.
Prometheus Operator를 사용한다면 Kube-state-metrics를 쉽게 배포하고 ServiceMonitor를 통해 지표를 수집할 수 있습니다.
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: kube-state-metrics
namespace: monitoring
labels:
app.kubernetes.io/name: kube-state-metrics
spec:
endpoints:
- port: http-metrics
interval: 30s
selector:
matchLabels:
app.kubernetes.io/name: kube-state-metrics
namespaceSelector:
matchNames:
- kube-system
이 ServiceMonitor는 `kube-system` 네임스페이스에 배포된 `kube-state-metrics` Pod의 `http-metrics` 포트에서 30초마다 지표를 수집하도록 Prometheus에 지시합니다. 수집된 지표를 기반으로 Grafana 대시보드를 구성하여 Karpenter의 노드 프로비저닝 및 스케일 다운 이벤트를 추적하고, 클러스터의 전반적인 상태를 실시간으로 모니터링할 수 있습니다. 한 가지 팁을 드리면, Karpenter 자체도 컨트롤러 지표를 Prometheus 포맷으로 노출하므로, 이를 수집하여 Karpenter의 내부 동작까지 모니터링하는 것이 좋습니다.
결과 및 성과: 비용 절감과 운영 효율성 향상
Karpenter와 Prometheus 기반의 동적 오토스케일링을 도입한 후, 저희는 기대 이상의 성과를 달성할 수 있었습니다. 정량적, 정성적 지표 모두에서 확연한 개선이 나타났습니다.
주요 성과 요약:
- 클라우드 비용 절감: 기존 대비 평균 25%의 클라우드 인프라 비용 절감 효과를 보았습니다. 이는 스팟 인스턴스 활용률 증가와 노드 통합 기능 덕분입니다. 특정 피크 타임에 대한 불필요한 온디맨드 인스턴스 오버 프로비저닝이 줄어든 것이 주효했습니다.
- 자원 활용률 향상: 클러스터 전체의 CPU 및 메모리 자원 활용률이 평균 60%에서 85% 이상으로 향상되었습니다. Karpenter가 워크로드에 최적화된 노드 타입을 동적으로 선택하고 불필요한 유휴 노드를 빠르게 회수했기 때문입니다.
- 프로비저닝 속도 개선: 새로운 노드 프로비저닝에 소요되는 시간이 기존 수 분에서 수십 초 이내로 단축되었습니다. 덕분에 Pod Pending 상태가 크게 줄어들어 서비스 지연 문제가 해소되었습니다.
정성적인 측면에서는 운영팀의 업무 부담이 현저히 줄어들었습니다. 수동으로 노드 그룹을 조정하거나 인스턴스 타입을 변경하는 작업이 사라졌고, 클러스터 자원 부족으로 인한 긴급 대응 상황도 대폭 감소했습니다. 개발팀은 인프라 자원에 대한 걱정 없이 애플리케이션 개발 및 배포에 집중할 수 있게 되었습니다. Prometheus와 Grafana를 통해 실시간으로 클러스터의 상태와 비용 지표를 시각화할 수 있게 되면서, 더욱 데이터 기반의 의사결정이 가능해졌습니다.
Karpenter 도입 전후 비교:
| 항목 | 도입 전 (Cluster Autoscaler) | 도입 후 (Karpenter + Prometheus) |
|---|
| 평균 클라우드 비용 | 높음 | 25% 절감 |
| 평균 자원 활용률 | 60% | 85%+ |
| 노드 프로비저닝 시간 | 수 분 | 수십 초 이내 |
| 스팟 인스턴스 활용률 | 제한적 | 매우 높음 |
| 운영팀 업무 부담 | 높음 (수동 개입 많음) | 낮음 (자동화된 관리) |
| 서비스 가용성 | 트래픽 피크 시 지연 가능성 | 안정적인 확장성 확보 |
교훈 및 회고: 예측 불가능성 관리와 지속적인 튜닝
Karpenter 도입은 매우 성공적이었지만, 몇 가지 교훈도 얻었습니다. 가장 중요한 것은 스팟 인스턴스의 예측 불가능성 관리였습니다. 스팟 인스턴스는 비용 효율적이지만, 언제든지 회수될 수 있다는 특성을 가집니다. 이를 대비하여 critical한 워크로드에는 `nodeSelector`나 `nodeAffinity`를 사용하여 온디맨드 인스턴스나 특정 가용 영역에 고정시키는 전략을 병행하는 것이 중요합니다. 또한, Karpenter의 `disruption` 정책을 신중하게 설정하여 노드 회수 시 Pod의 서비스 연속성을 보장해야 합니다. `consolidationPolicy`와 `expireAfter` 설정은 초기에는 보수적으로 시작하여 점진적으로 최적화하는 것이 효과적이었습니다.
또한, Karpenter의 `NodePool` 정의를 통해 다양한 워크로드 요구사항을 충족시키기 위한 세밀한 튜닝이 필요했습니다. 예를 들어, 특정 GPU 워크로드를 위해 GPU가 있는 인스턴스 타입을 프로비저닝하거나, 스토리지가 많이 필요한 워크로드를 위해 스토리지가 충분한 인스턴스 타입을 지정하는 등의 최적화 작업이 중요합니다. 이 과정에서 Prometheus로 수집한 지표를 면밀히 분석하고, 애플리케이션별 자원 요구사항을 정확히 파악하는 것이 필수적이었습니다. 예상과 달리, 모든 Pod에 대해 단일 `NodePool`로 통합하는 것보다, 특정 워크로드 그룹에 특화된 `NodePool`을 여러 개 운영하는 것이 더 효율적인 경우도 많았습니다.
의외의 부수적 효과로는 클라우드 자원에 대한 팀원들의 이해도가 높아진 점입니다. Karpenter가 어떤 기준으로 노드를 프로비저닝하고 회수하는지, 스팟 인스턴스의 장단점은 무엇인지 등을 학습하면서 클라우드 인프라에 대한 전반적인 지식 수준이 향상되었습니다. 이는 DevSecOps 문화 정착에도 긍정적인 영향을 미쳤습니다.
적용 가이드: 단계적 도입과 모니터링 강화
Karpenter와 Prometheus를 활용한 Kubernetes 비용 최적화는 모든 클라우드 네이티브 환경에 적용 가능합니다. 유사한 환경에서 도입을 고려하고 있다면, 다음 단계부터 적용해 보시기 바랍니다.
- 모니터링 환경 선행 구축: Karpenter 도입 전에 Prometheus, Grafana 등을 활용하여 현재 클러스터의 자원 사용률, Pod 상태, 노드 수 등의 지표를 충분히 수집하고 분석할 수 있는 환경을 구축해야 합니다. 현재의 문제점을 정확히 파악하는 것이 최적화의 시작점입니다.
- 단계적 도입 로드맵 수립: 처음부터 모든 워크로드에 Karpenter를 적용하기보다, 중요도가 낮은 개발/테스트 환경부터 시작하여 점진적으로 프로덕션 환경으로 확장하는 것이 안전합니다. 특정 `NodePool`과 `EC2NodeClass`를 먼저 정의하고, 여기에 특정 `taint`와 `toleration`을 사용하여 워크로드를 점진적으로 마이그레이션하는 방법을 고려할 수 있습니다.
- 스팟 인스턴스 활용 전략 수립: 스팟 인스턴스 회수에 대비한 Pod Disruption Budget (PDB) 설정, Pod의 `terminationGracePeriodSeconds` 조정, 그리고 온디맨드 인스턴스 사용이 필수적인 워크로드 식별 및 격리 등 스팟 인스턴스 활용 전략을 미리 수립해야 합니다.
- 지속적인 튜닝과 최적화: Karpenter의 `NodePool` 정의는 한 번 설정했다고 끝나는 것이 아닙니다. 워크로드 변화에 따라 `instance-type` 요구사항, CPU/Memory 제약 조건, `disruption` 정책 등을 지속적으로 튜닝해야 합니다. Prometheus를 통해 수집된 지표가 이 튜닝의 중요한 가이드라인이 될 것입니다.
Karpenter는 단순한 오토스케일링 도구를 넘어, Kubernetes 클러스터 운영의 패러다임을 바꿀 수 있는 강력한 솔루션입니다. Prometheus와 통합하여 실시간 모니터링과 피드백 루프를 구축한다면, 비용 효율성과 운영 안정성이라는 두 마리 토끼를 모두 잡을 수 있을 것입니다. 지금 바로 Karpenter를 도입하여 클라우드 비용 최적화의 여정을 시작해 보시기 바랍니다.
