비용 최적화

5부 (운영 · 디버깅 · 비용)의 두 번째 챕터입니다. 27장 kubectl 디버깅 패턴에서 사고가 발생했을 때 어디부터 봐야 하는지의 결을 정리했다면, 이번 챕터는 사고는 아니지만 매달 청구서로 들어오는 결을 다룹니다. 26장 운영 체크리스트 §“비용"에서 다섯 가지 출처로 짧게 짚었던 항목들이 본격적인 비용 거버넌스의 한 사이클로 이어지는 단계입니다.

K8s 비용은 의도하지 않으면 빠르게 부풀어 오릅니다. “왜 다음 달 청구서가 두 배가 됐는가"의 가장 흔한 답은 한 가지 큰 변경이 아니라 여러 작은 누수의 합산입니다. 이번 챕터의 목표는 그 누수가 어디서 새는지를 파악하고, 분기마다 한 페이지의 점검 체크리스트로 막을 수 있는 시야입니다.

K8s 비용의 두 축 #

EKS 청구서를 한 번 펼쳐 보면 비용은 두 결로 나뉩니다.

비율은 환경마다 다르지만, 일반적인 운영 클러스터에서는 컴퓨트가 60~70%, 부가가 30~40 % 정도입니다. 컴퓨트 절감은 가시적이고 가장 큰 효과를 내지만, 부가의 NAT Gateway와 데이터 전송이 종종 컴퓨트보다 큰 누수를 만든다는 점을 잊기 쉽습니다. 두 축을 같이 보는 게 비용 최적화의 출발점입니다.

21장 EKS 클러스터 셋업의 §“비용의 첫 인상"에서 prod의 시작 비용을 월 $200~$300으로 잡았던 그 셋이 본격적인 운영에서 어떻게 흩어지는지가 본 챕터의 본문입니다.

requests의 비용 의미 #

11장 자원 요청과 한도에서 requests가 스케줄러의 입력이라는 결을 다뤘다면, 운영 관점에서 requests는 클러스터가 사용자에게 청구할 자원의 예약입니다. requests의 합 = 클러스터가 띄워야 하는 최소 노드 자원이고, 노드 가용량의 60~70% 이상을 requests로 채워야 13장 오토스케일링의 Cluster Autoscaler가 새 노드를 띄우는 결정을 합니다.

문제는 over-request입니다.

resources:
  requests:
    cpu: "2"          # 실제 평균 사용 0.1 core
    memory: "4Gi"     # 실제 평균 사용 200Mi
  limits:
    cpu: "4"
    memory: "8Gi"

이 매니페스트가 100개의 Pod에 적용되면, 클러스터는 200 core + 400 Gi를 예약합니다. 실제로 쓰는 건 10 core + 20 Gi입니다. 빈 자원에 노드 비용이 청구되는 모양입니다. 운영 클러스터에서 가장 흔한 비용 누수의 출처이고, 단일 변경으로 가장 큰 절감을 만들 수 있는 영역입니다.

적정 requests의 룰은 다음 정도입니다.

• CPU requests = 평균 사용량 × 1.2~1.5
• Memory requests = P95 사용량 × 1.1~1.3 (메모리는 burstable 하기 어렵습니다)
• limits는 requests보다 2~4배 (Burstable QoS) 또는 같음 (Guaranteed QoS)

평균 / P95의 측정은 25장 모니터링 · 알람의 container_cpu_usage_seconds_total과 container_memory_working_set_bytes 메트릭으로 한 달 정도 관찰하면 보입니다.

VPA recommendation만 — 권장값을 PR로 #

Vertical Pod Autoscaler (VPA)는 워크로드의 실제 사용량을 분석해 적정 requests / limits를 추천하는 컨트롤러입니다. 자동 apply 모드는 운영에서는 위험하지만 (Pod 재시작이 잦아짐), recommendation만 켜는 모드가 운영에서 안전한 패턴입니다.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myshop-api-vpa
  namespace: myshop
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myshop-api
  updatePolicy:
    updateMode: "Off"   # 권장만, 자동 적용 안 함

updateMode: Off가 핵심 — VPA가 메트릭을 분석해 권장값을 status에 적기만 하고, Pod의 실제 spec은 건드리지 않습니다.

kubectl describe vpa myshop-api-vpa -n myshop

이 출력의 “Container Recommendations” 섹션에 적정 CPU / Memory가 적혀 있습니다. 그 값을 22장 앱 배포 골격의 Helm values에 PR로 반영하는 흐름이 운영의 표준입니다. 자동화는 측정에, 결정은 사람에 — VPA의 가장 안전한 운영 모드입니다.

Goldilocks와 Robusta KRR이 같은 방향을 다른 UI로 제공합니다. Goldilocks는 네임스페이스 단위로 VPA 추천을 한 대시보드에 모아 주고, KRR은 CLI 한 명령으로 클러스터 전체의 권장값을 출력합니다. 어느 도구든 본질은 “측정된 권장값을 사람이 PR로 반영"의 패턴입니다.

bin packing — 노드 활용률과 descheduler #

requests가 적정해도 노드가 비효율적으로 채워지면 비용이 새어 나갑니다. bin packing이 노드의 자원을 얼마나 빽빽하게 사용하는지의 결입니다.

kubectl top nodes
kubectl describe node <node-name>   # Allocatable vs Allocated

kubectl describe node의 “Allocated resources” 섹션이 그 노드의 requests 합을 보여 줍니다. **노드 가용량의 60~80 %**가 운영의 적정 활용률입니다. 50% 미만이면 노드가 과대 프로비저닝, 90% 이상이면 새 Pod가 스케줄링되지 못할 위험입니다.

낮은 활용률의 노드가 누적되면 descheduler가 들어옵니다.

apiVersion: descheduler/v1alpha2
kind: DeschedulerPolicy
profiles:
  - name: LowNodeUtilization
    pluginConfig:
      - name: LowNodeUtilization
        args:
          thresholds:
            cpu: 20
            memory: 20
            pods: 20
          targetThresholds:
            cpu: 60
            memory: 60
            pods: 60
    plugins:
      balance:
        enabled: [LowNodeUtilization]

descheduler가 사용률 20% 미만 노드의 Pod를 evict 하면, Karpenter (또는 Cluster Autoscaler)가 그 노드를 회수합니다. 22장의 PodDisruptionBudget이 이 시점에서 다시 결정적입니다 — PDB 없는 워크로드가 evict의 첫 번째 희생자입니다.

Spot 노드 — 안전한 워크로드의 분류 #

EC2 Spot 인스턴스는 ON_DEMAND 대비 50~90% 저렴하지만, AWS가 2분 통지 후 회수할 수 있습니다. 이 결을 안전하게 활용하는 게 비용 절감의 가장 큰 영역입니다.

워크로드를 두 분류로 나누는 게 표준입니다.

이 분류를 매니페스트로 표현하는 표준 패턴이 node taint + tolerations입니다.

spec:
  template:
    spec:
      taints:
        - key: karpenter.sh/capacity-type
          value: spot
          effect: NoSchedule
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]

spec:
  tolerations:
    - key: karpenter.sh/capacity-type
      value: spot
      operator: Equal
      effect: NoSchedule

이 패턴이 “의도적으로 spot을 받아들이겠다고 선언한 워크로드만 spot 노드에 가게” 하는 보안 장치입니다. 새로 만든 워크로드가 실수로 spot에 떨어져 회수의 영향을 받는 일을 막습니다.

Fargate Spot도 같은 방향의 매니지드 옵션입니다. 노드 자체를 신경 쓰지 않으면서 70% 정도의 절감을 만들지만, GPU / DaemonSet / privileged Pod 같은 일부 워크로드를 띄울 수 없는 제약이 있습니다.

Karpenter — Cluster Autoscaler와의 결정 트리 #

13장 오토스케일링 §“Karpenter — EKS의 더 빠른 대안"에서 짚었던 모델을 본 챕터에서 본격적으로 다룹니다. Cluster Autoscaler와 Karpenter의 차이를 한 표로 정리합니다.

Karpenter의 NodePool과 NodeClass의 멘탈 모델이 핵심입니다.

apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2023
  role: "KarpenterNodeRole-myshop-prod"
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: myshop-prod
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: myshop-prod

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["t", "m", "c"]
        - key: karpenter.k8s.aws/instance-cpu
          operator: In
          values: ["2", "4", "8", "16"]
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  limits:
    cpu: 1000

NodeClass = 어디서, NodePool = 어떻게의 분리입니다. 한 NodeClass 위에 여러 NodePool을 두고 (general / batch / gpu 등), 워크로드의 라벨 / taint로 적절한 NodePool이 선택되도록 묶습니다.

on-demand fallback — spot 회수의 안전선 #

Karpenter의 강점 중 하나가 on-demand fallback입니다. requirements에 spot과 on-demand를 둘 다 두면, spot 인스턴스의 회수가 잦은 시점에 자동으로 on-demand로 전환합니다. spot의 비용 이점을 가져가면서 회수 시 가용성을 보장하는 패턴입니다.

결정 트리 #

- 워크로드의 자원 요구가 일정하고, 인스턴스 타입 1 ~ 2 개로 충분
  -> Cluster Autoscaler 가 단순
- 워크로드가 다양하고, 비용 절감이 우선
  -> Karpenter
- spot 의 비용 이점을 본격 활용
  -> Karpenter (자동 인스턴스 다양화)
- AWS 외 클라우드
  -> Cluster Autoscaler (Karpenter 는 AWS 중심)

본 책의 표준 경로는 21~22장에서 Cluster Autoscaler로 시작하고, 트래픽 패턴이 정착된 뒤 Karpenter로 전환하는 흐름입니다. 두 도구를 같은 클러스터에서 동시에 운영하는 것은 권장되지 않습니다 — 노드 회수의 결정 주체가 둘이 되면 서로의 동작을 방해합니다.

idle 자원 회수 — 점검 도구의 한 묶음 #

운영 한 달이 지나면 unused / idle 자원이 누적됩니다. 정기 점검의 자동화 도구들입니다.

이 도구들의 출력을 분기마다 한 페이지로 모아 PR의 입력으로 두는 흐름이 표준입니다. 한 분기에 워크로드의 20~30%가 권장값과 어긋난다는 게 보통의 결과이고, 그 정도의 right-sizing으로 컴퓨트 비용의 20~40% 절감이 일반적입니다.

비용 가시화 — OpenCost / Kubecost / Cost Allocation Tags #

OpenCost — 오픈소스 표준 #

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost \
  -n opencost --create-namespace

OpenCost가 Prometheus 메트릭과 AWS Cost API를 결합해 네임스페이스 · Deployment · 라벨 단위 비용을 계산합니다. 25장의 Prometheus와 자연스럽게 결합되고, Grafana 데이터 소스로 추가하면 비용 대시보드를 만들 수 있습니다.

Kubecost — 상용 강화판 #

Kubecost는 OpenCost의 상용 확장입니다 — 더 세밀한 가시화, 권장값 자동화, SSO 통합, multi-cluster 비용 통합 등이 추가됩니다. 작은 팀은 OpenCost로 시작하고, 비용 관리가 본격 업무가 되는 시점에 Kubecost로 옮기는 흐름이 자연스럽습니다.

AWS Cost Allocation Tags #

provider "aws" {
  region = "ap-northeast-2"

  default_tags {
    tags = {
      Project     = "myshop"
      Environment = "prod"
      Team        = "backend"
      CostCenter  = "engineering"
    }
  }
}

21장 EKS 셋업에서 적은 default_tags가 본 챕터의 비용 분배의 기반입니다. AWS Cost Explorer에서 이 태그들을 “Cost Allocation Tags"로 활성화하면 청구서가 태그별로 갈라져 보입니다. 태그 표준을 미리 잡아 두지 않으면 1년 뒤 비용 분배가 거의 불가능 합니다 — 셋업 시점에 잡아 두는 게 핵심입니다.

namespace / 라벨 단위 비용 분배 — chargeback vs showback #

여러 팀이 한 클러스터를 공유하는 환경에서는 누가 얼마를 썼는가의 문제가 본격 운영 이슈가 됩니다. 두 모델이 있습니다.

대부분 운영 환경의 출발점은 showback입니다. OpenCost의 출력으로 매월 팀별 사용량 리포트를 보내면, 자연스럽게 팀이 자기 워크로드의 requests와 라벨 정리를 시작합니다. 7장 Namespace와 라벨의 team / cost-center 표준 라벨이 본 절에서 본격적인 비용 책임의 키로 활용됩니다.

20장 GitOps의 App of Apps가 도입된 환경에서는 각 ArgoCD Application 매니페스트에 팀 라벨을 박아 두면 라벨이 자동으로 매니페스트 전체에 전파됩니다.

PV / EBS 비용 — gp3와 lifecycle #

스토리지 비용은 인스턴스 비용 다음으로 큰 비중을 차지하는 경우가 많습니다. 세 결을 짚습니다.

gp3 vs gp2 #

EBS의 기본 옵션이 gp2에서 gp3로 바뀐 게 비용 측면의 가장 큰 변화입니다. gp3가 같은 IOPS · 처리량에서 약 20% 저렴 합니다. 9장 PV / PVC / StorageClass의 StorageClass 매니페스트에서 gp3로 두는 게 운영 표준입니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
  encrypted: "true"
allowVolumeExpansion: true

snapshot의 누적 #

EBS snapshot은 자동으로 누적됩니다. RDS의 자동 스냅샷은 23장의 backup_retention_period로 관리되지만, K8s의 VolumeSnapshot이나 Velero의 백업으로 만들어진 snapshot은 별도 lifecycle이 없으면 영원히 쌓입니다.

aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`2024-01-01`].[SnapshotId,VolumeSize,Description]' \
  --output table

미사용 PV의 회수 #

kubectl get pv | grep Released

Released 상태의 PV는 그 PVC를 가졌던 Pod가 삭제됐지만 PV 자체는 남아 있는 상태입니다. EBS 볼륨이 계속 청구됩니다. ReclaimPolicy가 Retain 이면 수동 정리가 필요하고, Delete 이면 PVC 삭제 시 EBS도 함께 삭제됩니다.

네트워크 비용 — 가장 가려진 누수 #

AWS 네트워크 비용은 청구서에서 가장 발견하기 어려운 항목입니다. 세 출처가 있습니다.

AZ 간 트래픽 #

같은 region 안에서도 AZ가 다른 Pod 끼리의 통신은 GB 당 $0.01~$0.02가 청구됩니다 (양방향이라 실제론 두 배). myshop-api의 5개 Pod가 3개 AZ에 흩어져 있고, 각 Pod가 PgBouncer와 통신할 때마다 일부는 AZ 간 트래픽이 됩니다.

Topology-aware routing이 이를 줄이는 K8s 1.23+ 기능입니다.

apiVersion: v1
kind: Service
metadata:
  name: pgbouncer
  namespace: myshop
  annotations:
    service.kubernetes.io/topology-mode: Auto
spec:
  # ...

이 annotation이 켜져 있으면 같은 AZ의 endpoint가 우선됩니다. AZ 간 트래픽이 절반 이하로 떨어지는 게 일반적입니다.

NAT Gateway 데이터 전송 #

21장 EKS 셋업의 §“single NAT vs NAT per AZ"에서 짚었던 NAT 비용은 시간당 + GB 당입니다. 시간당은 NAT 한 개에 약 $32/월이고, GB 당은 데이터 전송량에 비례합니다.

- VPC Endpoint — S3, ECR, DynamoDB, CloudWatch, Secrets Manager
  -> 가장 큰 효과. NAT 트래픽의 60 ~ 80% 를 우회.
- 외부 API 캐싱 — 인스턴스 안의 캐시 또는 ElastiCache
  -> 반복 호출을 줄임.
- 같은 region 의 다른 AWS 서비스 통신은 VPC 내부 라우팅으로
  -> ECR, S3, DynamoDB 는 무료.

ALB의 LCU #

ALB의 비용 단위는 **LCU (Load Balancer Capacity Unit)**입니다 — 신규 연결, 활성 연결, 처리된 데이터, 룰 평가의 네 차원 중 가장 큰 값으로 청구됩니다. 22장 앱 배포 골격에서 만든 한 개의 ALB가 myshop-api, ArgoCD, Grafana의 세 진입점을 묶어 주는 패턴이 LCU 절감에도 도움이 됩니다 — 워크로드마다 ALB를 따로 만들지 않습니다.

다음 달 청구서 review 체크리스트 #

월별 비용 점검의 한 페이지 표준 체크리스트를 정리합니다.

[컴퓨트]
- 노드 활용률 — kubectl top nodes 의 평균이 60 ~ 80%?
- spot 비율 — interruptible 워크로드 대비 spot 사용률
- Karpenter consolidation — 최근 한 달의 노드 통합 이벤트 수
- VPA / KRR 권장값 — 미반영 워크로드 목록과 PR 진행 상황

[부가]
- NAT 데이터 전송량 — 지난 달 대비 변화
- VPC Endpoint 도입 가능 서비스 — S3 / ECR / Secrets Manager
- AZ 간 트래픽 비율 — topology-aware routing 적용 가능한 Service 목록
- ALB / NLB 개수 — 통합 가능한 진입점 있는지

[스토리지]
- gp2 PV 잔재 — gp3 로 마이그레이션 후보
- Released PV 의 EBS 볼륨 — 회수 가능량
- 옛 EBS / RDS snapshot — lifecycle 미적용 자원
- ECR 이미지 — lifecycle policy 적용 상태

[가시화]
- OpenCost 의 팀별 / 워크로드별 비용 1, 2, 3 위
- 지난 달 대비 +20% 이상 증가한 항목
- Cost Anomaly Detection 의 알림 이력
- 다음 달 예측 vs 예산

이 체크리스트가 한 페이지에 들어가고, 매월 한 번 정기적으로 채워지는 게 운영의 목표입니다. 모든 항목을 한 번에 풀려고 하지 말고, 매월 한두 항목만 개선하는 누적 모델이 지속 가능한 흐름입니다.

연습문제 #

1. dev 클러스터에 VPA recommendation 모드와 Goldilocks를 설치하고, myshop-api의 한 달치 데이터를 분석해 권장 requests / limits를 얻습니다. 현재 매니페스트의 requests와 권장값의 격차를 백분율로 계산하고, 그 격차가 한 달 노드 비용에 어떻게 반영되는지 OpenCost의 출력으로 검증합니다. 권장값을 22장의 Helm values에 반영하는 PR을 작성하고, 적용 전후의 노드 활용률 변화를 kubectl top nodes로 비교합니다.
2. Karpenter의 NodePool에 spot + on-demand의 두 capacity-type을 모두 적고, myshop-api Deployment에 spot taint를 받아들이는 toleration을 추가합니다. 한 주 동안 spot 인스턴스가 회수되는 빈도를 측정하고, 회수 시 Karpenter가 on-demand로 fallback 하는 모양을 kubectl get events로 추적합니다. spot의 비용 절감 효과와 22장의 PodDisruptionBudget이 회수 시점에 어떻게 보호 역할을 하는지를 한 단락으로 정리합니다.
3. 본인의 운영 클러스터 (또는 학습 클러스터)에 §“다음 달 청구서 review 체크리스트"의 한 페이지를 채워 봅니다. 각 항목에 현재 값 · 지난 달 대비 변화 · 다음 달 개선 가능성을 적고, 가장 큰 누수 출처 3 곳을 우선순위로 잡습니다. 26장의 정기 운영 캘린더와 결합해 분기 단위로 어느 항목을 어느 시점에 점검할지를 캘린더에 넣어 둡니다.

한 줄 요약: K8s 비용은 컴퓨트 60~70% + 부가 30~40%의 두 축이고, 가장 큰 누수는 over-request와 NAT Gateway · AZ 간 데이터 전송이다. VPA recommendation + Goldilocks / KRR로 권장값을 측정하고 PR로 사람이 반영하는 모델, Spot + Karpenter의 on-demand fallback, descheduler + bin packing의 노드 활용률 60~80% 유지, gp3 + ECR lifecycle의 스토리지 청소, topology-aware routing + VPC Endpoint의 네트워크 절감이 한 묶음으로 굴러간다. OpenCost · 라벨 단위 chargeback / showback으로 비용을 팀에게 가시화하면 자연스럽게 자기 정리가 시작된다. 매월 한두 항목씩만 개선하는 누적 모델이 지속 가능한 길이다.

다음 챕터 #

이번 챕터에서 비용 결을 다뤘다면, 다음 챕터는 보안 결입니다. 운영 클러스터의 보안은 한 번의 셋업이 아니라 정기 점검의 누적이고, 본 책의 여러 챕터 (6장 ConfigMap · Secret, 14장 RBAC / NetworkPolicy, 16장 IRSA, 17장 Admission Controller, 23장 External Secrets)에서 단편적으로 짚어 온 결을 한 묶음의 운영 매뉴얼로 묶는 단계입니다.

29장 시크릿 운영에서는 K8s Secret의 본질적 한계 (base64는 암호화가 아니라는 점)부터 sealed-secrets / external-secrets / SOPS의 세 옵션 비교, IRSA + RDS IAM auth의 “비밀번호 0” 운영, 회전 · 주입 · 감사의 네 축까지를 한 사이클로 다룹니다.