Auto scaling กับ Predictive scaling: ตั้งให้รับโหลดล่วงหน้า ไม่ใช่ตามหลัง

HPA แบบเดิมตอบสนองช้ากว่าทราฟฟิกที่พุ่งเป็นขั้นบันได มาดูวิธีผสม scheduled scaling, KEDA และ metric ที่ทำนายล่วงหน้าได้จริง

เผยแพร่: 12 กันยายน 2568
อ่าน: 2 นาที
เขียนโดย: SSUSEMAN

Auto scaling กับ Predictive scaling: ตั้งให้รับโหลดล่วงหน้า ไม่ใช่ตามหลัง — cloud — SUSEMANKubernetes · KEDA

Auto scaling แบบ HPA ทำงานจากค่าที่วัดได้ในอดีตอันใกล้ มันจึงตอบสนองช้ากว่าทราฟฟิกที่กระโดดเป็นขั้นบันไดเสมอ — และช่วงเวลาที่ช้ากว่าคือช่วงที่ผู้ใช้เห็นหน้าเว็บช้า

ทำไม HPA ตามไม่ทัน

HPA ใช้ค่า CPU หรือ custom metric ที่วัดจาก pods ที่มีอยู่ แล้วค่อยเพิ่ม replica เมื่อค่าเกิน target สมมติว่าทราฟฟิกเพิ่มสามเท่าในสามสิบวินาที:

metric ต้องรอ scrape interval (15–30 วินาที)
HPA ตัดสินใจเพิ่ม replica
pod ใหม่ใช้เวลา pull image + start + warm cache (20–60 วินาที)
traffic ที่เกินมาโดนคิวระหว่างนั้น

รวมแล้วเกือบสองนาทีกว่าความจุจะตามทัน ซึ่งเป็นสองนาทีที่ latency พุ่ง

สามชั้นที่ควรมี

ชั้นที่หนึ่ง — reactive: HPA บน custom metric ที่ใกล้ผู้ใช้ที่สุด เช่น request rate ต่อ pod ไม่ใช่ CPU เพราะ CPU ขึ้นช้ากว่าคนกดโหลด

ชั้นที่สอง — scheduled: ถ้ารู้ว่าทุกวันจันทร์ 09:00 มีคนเข้าพร้อมกัน ให้ pre-scale ล่วงหน้า 15 นาที ด้วย CronJob หรือ KEDA ScaledObject ที่ใช้ cron trigger

yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-morning-ramp
spec:
  scaleTargetRef:
    name: api
  minReplicaCount: 4
  maxReplicaCount: 40
  triggers:
    - type: cron
      metadata:
        timezone: Asia/Bangkok
        start: 0 45 8 * * *
        end: 0 30 11 * * *
        desiredReplicas: '18'
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        query: sum(rate(http_requests_total{job="api"}[2m])) / sum(kube_deployment_status_replicas{deployment="api"})
        threshold: '45'

ชั้นที่สาม — predictive: ใช้ seasonal model จากข้อมูลย้อนหลัง ตัวอย่างที่ได้ผลจริงคือ Facebook Prophet หรือ moving average แบบมี seasonal term แล้วเขียนค่าที่ทำนายลงเป็น metric ปลอมให้ HPA อ่าน

คำเตือน: predictive scaling ที่ไม่มี guardrail จะ scale ผิดจังหวะในวันหยุดนักขัตฤกษ์ ให้จำกัด max replica ไว้เสมอ

ตัวเลขจากการ tune จริง

บนงานล่าสุดของผม (e-commerce, โหลดพุ่งตอน 20:00) การเพิ่ม scheduled pre-scale ทำให้ p95 latency ลดจาก 1.8 วินาทีเหลือ 420 มิลลิวินาทีในช่วงพีค และลดจำนวน request ที่ timeout ลง 96%