Resource Right-Sizing: ลด Cost โดย Optimize Resource Usage

การซื้อ resource ใน cloud ยืดหยุ่นกว่า on-premise มาก แต่ความยืดหยุ่นนี้เองที่ทำให้เกิดปัญหา — ทีมส่วนมาก provision resource ไว้เผื่อ peak load แล้วลืมปรับลง ทำให้ CPU, memory, disk วิ่งที่ 10-20% ตลอดเวลา ขณะที่จ่ายเงินเต็มจำนวน การทำ Right-Sizing คือการปรับขนาด resource ให้ตรงกับการใช้งานจริง เพื่อลดการใช้จ่ายโดยไม่กระทบประสิทธิภาพ

บทความนี้จะอธิบายหลักการ Right-Sizing ทั้งบน VM (AWS EC2, GCP Compute Engine), Kubernetes (VPA/HPA), และ managed service พร้อมเครื่องมือวิเคราะห์และแนวทางปฏิบัติเพื่อลดการใช้ทรัพยากรเกินจำเป็นได้ 30-50% โดยไม่สร้างความเสี่ยงให้ production workload

Right-Sizing คืออะไร

Right-Sizing คือกระบวนการวิเคราะห์การใช้งานจริงของ resource แล้วปรับ specification ให้ match กับ workload — ลด over-provisioned resource (จ่ายเกินจำเป็น) และแก้ under-provisioned resource (ประสิทธิภาพตก) สถานะที่ดีคือ utilization อยู่ช่วง 60-80% ในเวลาปกติ โดยมี headroom สำหรับ spike

สัญญาณว่า resource ควร Right-Size

CPU utilization ต่ำ — เฉลี่ย <20% นาน 7-14 วัน = over-provisioned
Memory utilization ต่ำ — <30% ตลอด = ลด memory tier ได้
CPU/Memory pegged — ใช้งาน >90% นาน = under-provisioned ต้องเพิ่ม
Disk I/O ต่ำ — เปลี่ยนจาก Provisioned IOPS เป็น gp3/pd-balanced
Idle resource — instance, disk, IP ที่ไม่ถูกใช้งานเลย = ควรลบ

Metrics ที่ต้องวิเคราะห์ก่อน Right-Size

การ right-size ต้องอิง data ไม่ใช่ความรู้สึก — ใช้ metric จาก CloudWatch, Cloud Monitoring, Prometheus อย่างน้อย 7-14 วัน เพื่อหาค่า baseline, peak และ pattern การใช้งาน

Metric	หน่วย	ค่าที่ควรดู	หมายเหตุ
CPU Utilization	%	avg, p95, p99, max	p99 สำคัญกว่า avg
Memory Used	GB / %	avg, max	อย่าดูแค่ avg เพราะ GC อาจทำให้ดูต่ำ
Network In/Out	Mbps	p95, burst	เชื่อมโยงกับ instance family
Disk IOPS	IOPS	avg, p99	Burst ส่งผลต่อ gp3 baseline
Disk Throughput	MB/s	p99	ดูพร้อม IOPS
Disk Used	% / GB	max	ลดขนาด disk ยากกว่าเพิ่ม

ทำไม p95/p99 สำคัญกว่า avg

การดูเฉลี่ยอย่างเดียวทำให้ตัดสินใจผิด — workload ที่ CPU avg 25% แต่ p99 สูงถึง 95% แปลว่ามีช่วงสั้น ๆ ที่ต้องการ CPU เต็มที่ หากลดขนาดตาม avg จะทำให้ตอบสนองช้าในช่วง peak การใช้ p95/p99 ให้ภาพที่สมจริงกว่า

# PromQL: หา CPU p99 ของ 14 วันที่ผ่านมา per instance
quantile_over_time(0.99,
  100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
[14d:5m])

# Memory used p99
quantile_over_time(0.99,
  (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100
[14d:5m])

Right-Sizing บน AWS EC2

AWS มีเครื่องมือช่วยวิเคราะห์ EC2 หลายตัว — Compute Optimizer (แนะนำอัตโนมัติจาก ML), Trusted Advisor (rule-based), Cost Explorer Rightsizing Recommendations สามารถเริ่มจาก Compute Optimizer ที่ใช้งานฟรีและแม่นยำที่สุด

AWS Compute Optimizer

Compute Optimizer วิเคราะห์ CloudWatch metric อย่างน้อย 14 วัน แล้วแนะนำ instance type ใหม่ โดยจัดอยู่ใน category ดังนี้ Under-provisioned, Optimized, Over-provisioned พร้อมประมาณการเงินที่ประหยัดได้ต่อเดือน สามารถเปิดใช้งานระดับ Organization ได้เพื่อวิเคราะห์ทุก account

# Enable Compute Optimizer
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# ดู recommendation ของ EC2
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123456789012:instance/i-0abc123 \
  --query 'instanceRecommendations[0].recommendationOptions'

# ดู EBS volume recommendation
aws compute-optimizer get-ebs-volume-recommendations

EC2 Instance Family เลือกอย่างไร

Workload	Family แนะนำ	เหตุผล
Web server / API	m7i, m7g (Graviton)	สมดุล CPU/Memory + Graviton ถูกกว่า 20%
CPU-intensive	c7i, c7g	CPU:Memory ratio สูง
Memory-intensive (cache, DB)	r7i, r7g, x2idn	RAM สูง
Batch / ML training	g5, p4d, trn1	GPU / Trainium
Dev / Test	t4g (burstable)	ราคาถูก, credit-based

ใช้ Graviton เพื่อประหยัด

Graviton (ARM processor ของ AWS) ถูกกว่า x86 ประมาณ 20% และให้ประสิทธิภาพดีกว่าในหลาย workload — Java, Go, Python, Node.js มีการ build สำหรับ ARM สมบูรณ์แล้ว สำหรับ container ใช้ multi-arch image (buildx) เพื่อ support ทั้ง x86 และ ARM

Right-Sizing บน GCP Compute Engine

GCP ใช้ Recommender service ที่ analyze ข้อมูลจาก Cloud Monitoring โดยแนะนำการ right-size VM อัตโนมัติและยังสามารถใช้ Custom Machine Type ที่ปรับ vCPU/Memory แยกได้อย่างอิสระ ช่วยให้ตรงกับ workload มากกว่าการเลือก fixed type

# ดู VM sizing recommendation
gcloud recommender recommendations list \
  --project=prod-project \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender

# Apply recommendation
gcloud recommender recommendations mark-claimed \
  RECOMMENDATION_ID \
  --project=prod-project \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender

Custom Machine Type

บน GCP หาก workload ต้องการ CPU:Memory ratio ที่ไม่ตรงกับ type มาตรฐาน สามารถสร้าง Custom Machine Type ได้ เช่น VM 4 vCPU + 10 GB RAM แทนที่จะเลือก n2-standard-4 (16 GB) — ทำให้ใช้จ่ายน้อยกว่าและ resource ตรงกับงานมากขึ้น

gcloud compute instances create my-vm \
  --custom-cpu=4 \
  --custom-memory=10GB \
  --zone=us-central1-a

Right-Sizing บน Kubernetes

บน Kubernetes การ right-size ต้องพิจารณา 2 ระดับ — Pod-level (CPU/Memory request/limit) และ Cluster-level (node size และจำนวน) เครื่องมือหลักที่ใช้คือ VPA สำหรับแนะนำ request/limit และ HPA สำหรับ scale replica ตาม load

Vertical Pod Autoscaler (VPA)

VPA วิเคราะห์การใช้งานจริงของ pod แล้วแนะนำค่า CPU/Memory request ที่เหมาะสม มี 3 mode: Off (แค่แนะนำ), Auto (restart pod ด้วย value ใหม่), Initial (ใช้เฉพาะตอน pod เริ่ม) — production แนะนำ Off ก่อน เพื่อดูคำแนะนำก่อน apply เอง

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Off"  # แค่ recommend ไม่ restart
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi

# ดูคำแนะนำจาก VPA
kubectl describe vpa my-app-vpa

# Output (ตัวอย่าง):
# Recommendation:
#   Container Recommendations:
#     Container Name:  my-app
#     Lower Bound:
#       Cpu:     25m
#       Memory:  262144k
#     Target:
#       Cpu:     87m
#       Memory:  350000k
#     Upper Bound:
#       Cpu:     250m
#       Memory:  500000k

Horizontal Pod Autoscaler (HPA)

HPA ปรับจำนวน replica ตาม metric เช่น CPU, memory หรือ custom metric เช่น RPS, queue depth ใช้ร่วมกับ VPA ไม่ได้ในรูปแบบ CPU/memory (VPA ก็ปรับ request ตาม CPU) — แต่ใช้ร่วมกันได้ถ้า HPA ใช้ custom metric

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60

Cluster Autoscaler และ Karpenter

ระดับ Cluster — Cluster Autoscaler ปรับจำนวน node ตาม pending pod ส่วน Karpenter (AWS) เลือก instance type ที่ดีที่สุดอัตโนมัติและรองรับ Spot Instance อย่างมีประสิทธิภาพ ช่วยลด Cloud Spending ได้ 40-70% เพราะเลือก type ตรงกับ workload จริง ไม่ได้ผูกกับ Node Group เดียว

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
      - key: karpenter.k8s.aws/instance-category
        operator: In
        values: ["m", "c", "r"]
      - key: karpenter.k8s.aws/instance-size
        operator: NotIn
        values: ["nano", "micro"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: 720h

เครื่องมือช่วยวิเคราะห์

เครื่องมือ	ใช้กับ	License	จุดเด่น
AWS Compute Optimizer	EC2, EBS, Lambda, ASG	ฟรี	ML-based, native
GCP Recommender	Compute Engine	ฟรี	Custom Machine Type suggestion
Goldilocks	K8s (VPA wrapper)	Open Source	Dashboard สรุป VPA recommendation
Kubecost	K8s	Freemium	Allocation + right-size
Cast.ai	K8s (AWS/GCP/Azure)	Commercial	Autonomous optimization
Vantage	AWS/GCP/Azure	Commercial	Multi-cloud FinOps

Goldilocks (Open Source)

Goldilocks เป็น UI layer ของ VPA ที่แสดงคำแนะนำในรูปแบบ table เปรียบเทียบค่าเดิมและค่าที่แนะนำ ใช้ง่ายกว่าการอ่าน VPA YAML และเหมาะกับการ review ทั้ง cluster — ติดตั้งด้วย Helm ภายใน 5 นาที

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install goldilocks fairwinds-stable/goldilocks \
  --namespace goldilocks --create-namespace

# Label namespace ที่ต้องการ analyze
kubectl label ns my-app goldilocks.fairwinds.com/enabled=true

# Port-forward แล้วดู dashboard
kubectl -n goldilocks port-forward svc/goldilocks-dashboard 8080:80

ขั้นตอนปฏิบัติการ Right-Sizing

รวบรวม metric — เก็บข้อมูลอย่างน้อย 14 วันเพื่อให้ครอบคลุม pattern รายสัปดาห์
หา candidate — filter resource ที่ utilization <30% หรือ >80% นาน
จัดลำดับตามผลประหยัด — จัดการตัวที่ประหยัดมากก่อน
Test ใน non-prod — apply ขนาดใหม่ใน dev/staging ก่อน
Canary deploy — prod ให้ rollout ทีละ % เพื่อดูผลกระทบ
Monitor หลังเปลี่ยน — ดู error rate, latency, throughput 1-2 สัปดาห์
Rollback plan — เตรียมพร้อม rollback ถ้าประสิทธิภาพตก
Document — บันทึกไว้ว่าทำไมถึงเลือกขนาดนี้

Pitfalls ที่ต้องระวัง

ลดขนาดมากเกินไป — ทำให้ OOM kill หรือ CPU throttle ในช่วง peak
ไม่ดู p99 — avg ดี แต่ tail latency แย่เพราะ resource ไม่พอ
Memory leak — right-size ไม่ช่วยถ้ามี leak — ต้องแก้ code ก่อน
Burst workload — batch job, cron — อาจต้อง burstable instance
Stateful workload — DB/cache ลดขนาดยากเพราะ data transfer
Reserved Instance lock-in — อย่า right-size ตัวที่มี RI จนกว่า RI จะหมดอายุ
Compliance constraint — บางระบบต้องการ instance type เฉพาะ

สรุป

Right-Sizing เป็น lever ที่ใหญ่ที่สุดในการลดค่าใช้จ่าย cloud — resource ส่วนใหญ่ over-provisioned ตั้งแต่วันแรกเพราะทีมเลือก “ใหญ่ไว้ก่อน” การทำ right-size อย่างเป็นระบบด้วยเครื่องมือเช่น Compute Optimizer, GCP Recommender, VPA + Goldilocks, Karpenter ช่วยประหยัดได้ 30-50% โดยไม่กระทบประสิทธิภาพ

กุญแจสำคัญคือการใช้ data จากการใช้งานจริงอย่างน้อย 14 วัน, ดู p95/p99 ไม่ใช่แค่ avg, test ใน non-prod ก่อน, monitor อย่างใกล้ชิดหลัง apply และเตรียม rollback plan — เมื่อทำเป็น routine (ทุกไตรมาส) จะทำให้ cloud infrastructure อยู่ในสภาพ optimal ตลอดเวลา ไม่ต้องรอให้บิลพุ่งแล้วค่อยมาแก้