AVAILABLE SAVINGS REPORT
cost-workshop — EKS 비용 최적화 진단
생성: rightsize · consolidate · hidden-waste 스킬 (read-only) · 클러스터 cost-workshop (ap-northeast-2) · 노드 m5.xlarge ×8
현재 월 비용 (베이스라인)
$1,378
8 × m5.xlarge × 730h
순 절감 (중복 제거)
$517
L2 통합 기준 · 베이스라인의 38%
+ Spot 전환 시
$877
누적 64% (L2+L3)
축소 금지 (신뢰성)
2
OOMKill·스로틀 — 오히려 증설
💡 이 리포트는 read-only 진단입니다. 어떤 변경도 적용하지 않았고, 각 항목에 "월요일에 그대로 PR 올릴" YAML 패치를 첨부합니다. 절감액은 Pricing API 실단가 기준 ±10% 밴드.
1베이스라인 — 지금 매달 얼마인가
모든 절감액은 이 분모($1,378/mo)의 몇 %로 환산합니다. Cost Explorer가 비어도 Pricing API × 리소스 목록으로 직접 계산했습니다.
노드 8대가 비용의 대부분. vCPU/GiB 단가(60:40 분할): vCPU $0.0354/h · GiB $0.0059/h
★예산 대비 & 6개월 예측
진단은 일회성 사진이 아닙니다. 월 예산을 정하고(③), 지금 사용량이 예산의 몇 %인지 보고(④), 지금 추세가 이어지면 언제 예산을 넘는지 예측(⑤)해야 최적화가 지속됩니다.
④ 실시간 — 예산 대비 현재 사용량
월 예산 $900 설정 시, 현재 베이스라인 $1,378 = 예산의 153% 초과. 최적화 후 $501은 예산의 56%.
⑤ AI 예측 — 지금 추세 vs 최적화 후
워크로드 월 3% 성장 가정(추정). 현상 유지 시 예산선을 이미 초과·계속 상승. 최적화 적용 시 예산 아래에서 완만.
💡 이 3개 축(예산·실시간 대비·예측)은 오늘 스킬의 확장 과제입니다. 예산선은 config에 숫자 하나로 두고, 예측은 Prometheus의 과거 추세(predict_linear)나 Cost Explorer 예측 API로 대체할 수 있습니다. 자세한 로드맵은 전자책 클로징(5장) 참고.
2L1 — Over-provisioning (파드 단위 절감)
7일 CPU p95 ÷ 0.7(목표 사용률 70%)로 권장 request를 산출. 메모리는 7일 max × 1.1. 신뢰성 게이트를 통과한 워크로드만 축소 대상.
| 워크로드 | 현재 request | 실사용 (7d) | 권장 | 월 절감 | 판정 |
|---|
| payment-api ×6 | 1000m / 4Gi | p95 98m / 127Mi | 140m / 256Mi | $230 | 축소 |
| search-worker ×4 | 800m / 2Gi | p95 197m / 143Mi | 281m / 256Mi | $84 | 축소 |
| user-svc ×3 | 600m / 1Gi | p95 88m / 117Mi | 126m / 256Mi | $46 | 축소 |
| checkout-worker ×1 | — / 128Mi | OOMKilled 반복 | — / 256Mi↑ | 증설 | 늘려라 |
| report-gen ×1 | limit 100m | throttle 100% | limit 완화 | 증설 | 늘려라 |
파랑=현재 request, 회색=실사용 p95. 격차가 클수록 낭비. 빨강 2종은 오히려 부족(함정).
🪤 함정 — 사용량이 낮다 ≠ 줄여도 된다
checkout-worker는 메모리 128Mi가 이미 부족해 3분마다 OOMKilled(재시작 누적). 평균 사용량만 보면 "여유"로 오판합니다.
report-gen은 CPU limit 100m에 걸려 스로틀 100% — 둘 다
축소가 아니라 증설 대상입니다.
last_terminated_reason=OOMKilled와
cfs_throttled 비율을 반드시 함께 봐야 합니다.
3L2 — 노드 통합 (Bin-packing)
노드 8대의 CPU requests 합 = 19.9 vCPU, allocatable = 31.4 vCPU (평균 63%). First-Fit 재배치 시뮬레이션 결과 5대로 통합 가능 — 단, 차단 요소 2개를 먼저 해결해야 합니다.
노드별 CPU requests / allocatable. 통합 후 3대(빨강) 유휴 → 제거 대상. 3 × $172 = $517/mo
🪤 함정 — 차단 요소를 무시한 통합은 사고
다음 2개가 노드 drain을 막습니다. "3대 끄면 됩니다"만 쓰고 이걸 빠뜨리면 실무 장애 + 채점 감점:
| 차단 요소 | 위치 | 해결 |
|---|
maxUnavailable: 0 PDB | store-front/payment-api-pdb | maxUnavailable를 1 이상으로 완화 |
do-not-disrupt: true | batch/pinned-job | 배치 잡이면 어노테이션 제거 검토 |
4노드 다운사이징 — 크기 축소 (대수 감축의 대안)
3의 통합은 노드 대수를 줄입니다. 여기서는 노드 크기를 줄이는 대안(m5.xlarge→m5.large)을 시뮬레이션합니다. 고객이 이미 Graviton이면 m6g 단가로 계산합니다. 주의: 통합(3)과 다운사이징은 같은 빈 용량을 노리므로 중복 — 둘 중 하나만 순 절감으로 집계합니다.
| 기준 | 구성 | 필요 대수 | 월 비용 | 비고 |
|---|
| 현재 | m5.xlarge (4 vCPU) | 8대 | $1,378 | 요청합 19.9 vCPU |
| 라이트사이징 前 · large | m5.large (2 vCPU) | ~12대 | ~$1,034 | 대수 급증 → 절감 $344(25%)로 통합($517)보다 못함 |
| 라이트사이징 後 · large | m5.large (2 vCPU) | ~7대 | $603 | 요청합 ~11 vCPU 기준. L1 이후에야 의미 |
| 라이트사이징 後 · Graviton large | m6g.large (~20%↓) | ~7대 | $480 | 고객(SmartThings IoT)처럼 이미 Graviton이면 이 줄 — 베이스라인 대비 ~65%↓ |
시나리오별 월 비용. "large 전환"만으로는 라이트사이징 없이 대수가 급증(~12대)해 이득이 작음 — L1 → 크기 축소 순서가 핵심.
🪤 함정 — "절반 크기 = 절반 비용"이 아니다
노드를 절반 크기로 줄여도 절감이 절반이 안 되는 이유 ①
allocatable 여유: kube/system-reserved·eviction은 노드마다 고정이라 작은 노드일수록 비율↑ ②
단일 파드 벽: 라이트사이징 전
payment-api(1000m)는 large allocatable(~1.7)의 60%를 혼자 차지 → 노드당 하나꼴이라 대수 폭증(더 큰 request면 스케줄 실패도) ③
DaemonSet 세금: 노드 수 2배면 로깅·모니터링 사본도 2배.
반드시 시뮬레이션으로 실제 대수를 구할 것. 대수 감축(3)과 순 절감을 이중 계산하지 말 것.
5L3 — 용량 단가 (Spot · Graviton)
통합 후 5대 기준. Spot은 ~65% 할인, Graviton(m6g)은 ~20% 할인. 실측상 Graviton 할인은 Spot 위에 중첩되지 않음(m6g Spot ≈ m5 Spot).
5대 × m5.xlarge 월 $860 기준. 막대는 전량 전환 시 각 시나리오의 이론 비용(Spot 전량 $301). 단 Spot은 회수 위험이 있어 실무 권고는 stateless·다중복제 워크로드만 부분 전환 — 적용순서(8번) 섹션의 "+Spot $360 절감"은 이 부분 채택 기준입니다.
6L4 — 숨은 낭비 (스토리지·유휴)
| 항목 | 탐지 방법 | 조치 | 월 절감 |
|---|
| 고아 EBS ×3 (available) | describe-volumes status=available | 삭제 (legacy-jenkins 100G·ml-scratch 50G·released 30G) | $16 |
| gp2 볼륨 (PV 70Gi) | StorageClass VolumeType=gp2 | gp3 전환 (~20% 저렴) | $2 |
| Released PV (30Gi) | get pv | grep -v Bound | 회수·삭제 | $3 |
| legacy-batch ×2 (abandoned) | net rate ~0 + CPU ~0 | 삭제 검토 | $34 |
| dev 네임스페이스 24/7 | ns=dev 상시 가동 | off-hours 스케일다운 | $20 |
| 컨트롤플레인 버전 (미래비용) | describe-cluster-versions → 1.31 STANDARD | 표준지원 종료 전 업그레이드 | 지금 $0 · 방치 시 +$365 |
7NET — 크로스-AZ 트래픽
chat-a(zone 2a) ↔ chat-b(zone 2c)가 상호 HTTP 폴링(130KB/s+, 부하 시 776KB/s). X-Ray 서비스맵에서 양방향 엣지로 확인됨. 같은 AZ로 co-locate 또는 topology aware routing 적용 → cross-AZ $0.01/GB 절감(소액이나 아키텍처 낭비).
8적용 순서 — 절감액은 겹친다
⚠️ 라이트사이징·통합·다운사이징은 서로 겹칩니다 — 순서와 택1이 중요
① L1 라이트사이징 (request 축소 — 그 자체로 노드 비용은 안 줄지만 노드 재편 여지를 만듦) →
② 노드 재편 (택1):
대수 감축(8→5대, 절감
$517)
또는 크기 축소(라이트사이징 後 m5.large ~7대, 월 비용 $603 → 절감
$775) →
③ L3 단가 전환 (남은 노드를 Spot으로 = 추가
$360 절감).
대수 감축과 크기 축소는 같은 빈 용량을 노리므로 중복 — 둘을 더하지 말고 하나만 집계합니다. 크기 축소가 커 보이지만 노드 수가 2배(운영복잡도·maxPods·DaemonSet 세금)라, 실무 권고는
통합을 기본으로 하고 다운사이징은 대안으로 병기합니다. L1 절감도 노드를 줄여야(②) 비로소 돈이 됩니다. 정직한 순 절감: 통합만 =
$517/mo (38%), 통합+L3 Spot =
$877/mo (64%). 고객처럼 이미 Graviton이면 L1+크기축소로 월
$480(~65%↓)까지. 최적화 후 목표 비용 =
$501/mo.
9월요일에 올릴 패치
right-size-payment-api.yaml
# kubectl patch deploy payment-api -n store-front \
# --patch-file right-size-payment-api.yaml
spec:
template:
spec:
containers:
- name: payment-api
resources:
requests:
cpu: "140m" # was 1000m
memory: "256Mi" # was 4Gi
pdb-fix-payment-api.yaml
# 통합 차단 해제 — drain 허용
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: payment-api-pdb
namespace: store-front
spec:
maxUnavailable: 1 # was 0 (영구 차단)
selector:
matchLabels:
app: payment-api