ในโลกธุรกิจดิจิทัลที่ทุกวินาทีมีความหมาย ความสามารถในการตอบสนองต่อความต้องการของลูกค้าได้อย่างรวดเร็วคือหัวใจสำคัญ ไม่ว่าจะเป็นช่วงแคมเปญ Flash Sale ที่มีผู้ใช้งานทะลักเข้ามาพร้อมกัน, ระบบประมวลผลคำสั่งซื้อหลังบ้าน, หรือการวิเคราะห์ข้อมูลแบบเรียลไทม์ แอปพลิเคชันของเราต้องพร้อมสเกล (Scale) เพื่อรับมือกับภาระงานที่พุ่งสูงขึ้นได้เสมอ
สำหรับผู้ที่ทำงานบนแพลตฟอร์มอย่าง Kubernetes คงไม่มีใครไม่รู้จัก HPA (Horizontal Pod Autoscaler) เครื่องมือพื้นฐานที่คอยเพิ่ม-ลดจำนวนแอปพลิเคชันของเราโดยอัตโนมัติตามการใช้งาน CPU หรือ Memory
แต่จะเกิดอะไรขึ้นถ้าภาระงานที่แท้จริงไม่ได้สะท้อนออกมาที่ CPU ในทันที? เราอาจกำลังเผชิญกับสถานการณ์ที่แอปพลิเคชันสเกลไม่ทันการณ์ ส่งผลให้ระบบช้า และท้ายที่สุดคือการสร้างประสบการณ์ที่ไม่ดีให้กับลูกค้า
วันนี้เราจะพาทุกท่านไปรู้จักกับ KEDA ฮีโร่ที่จะเข้ามาอัปเกรดการสเกลบน Kubernetes ให้ก้าวไปอีกระดับ ตอบโจทย์โลกธุรกิจที่ขับเคลื่อนด้วยอีเวนต์ (Event-Driven) อย่างแท้จริง
KEDA: ฮีโร่ผู้มองการณ์ไกล
KEDA (Kubernetes Event-driven Autoscaling) คือโปรเจกต์ Open Source ที่ออกแบบมาเพื่อเสริมความสามารถของ Horizontal Pod Autoscaler (HPA) โดยเฉพาะ หัวใจสำคัญของ KEDA คือการปลดล็อกให้ Kubernetes สามารถสเกลแอปพลิเคชันตาม “Event” จากภายนอกได้โดยตรง แทนที่จะถูกจำกัดแค่การวัดผลจาก CPU หรือ Memory ภายในระบบเท่านั้น
นี่คือ 2 ความสามารถหลักของ KEDA:
1. สเกลเชิงรุกจากภาระงานจริง (Proactive Scaling) 🚀
KEDA จะเชื่อมต่อโดยตรงกับแหล่งกำเนิดอีเวนต์ (Event Source) ที่หลากหลาย เช่น จำนวนข้อความใน Message Queue (RabbitMQ, Kafka), จำนวนไฟล์ใน Storage, หรือผลลัพธ์จาก Prometheus Query
ทำให้ KEDA สามารถสั่งสเกลแอปพลิเคชัน (เพิ่ม Pods) ได้ ล่วงหน้า ก่อนที่ภาระงานเหล่านั้นจะเข้ามาสร้างภาระหนักให้ CPU/Memory จนเกิดปัญหาคอขวด (Bottleneck) ซึ่งเป็นการแก้ปัญหาที่ต้นเหตุและช่วยให้ผู้ใช้งานได้รับประสบการณ์ที่ราบรื่นเสมอ
2. สเกลสู่ศูนย์เมื่อไม่มีภาระงาน (Scale to Zero) 💰
โดยปกติ Kubernetes จะต้องมีแอปพลิเคชันอย่างน้อย 1 Pod ทำงานรอเสมอ ซึ่งก่อให้เกิดต้นทุนแม้ไม่มีการใช้งาน
KEDA แก้ปัญหานี้โดยการตรวจสอบ Event Source หากไม่พบภาระงานใดๆ ที่รอการประมวลผล (เช่น Queue ว่างเปล่า) KEDA จะสามารถสั่งลดจำนวน Pods ลงเหลือ 0 ได้ และจะปลุกมันขึ้นมาทำงานอีกครั้งเมื่อมีอีเวนต์แรกเข้ามาเท่านั้น และการที่ Pods หายไปนี้เป็นการส่งสัญญาณให้เครื่องมือจัดการเซิร์ฟเวอร์อัตโนมัติอย่าง Karpenter หรือ Cluster Autoscaler สามารถเข้ามาลดจำนวนเซิร์ฟเวอร์ (Nodes) ที่ว่างงานทิ้งไปได้ ซึ่งนี่คือหัวใจของการประหยัดค่าใช้จ่ายบนคลาวด์อย่างแท้จริงตามหลักการ “Pay-per-use”
ใช้งานซับซ้อนไหม?
หลายคนอาจคิดว่าการเพิ่มความสามารถระดับนี้ต้องมาพร้อมกับความซับซ้อน แต่ KEDA ถูกออกแบบมาให้ใช้งานง่ายอย่างน่าทึ่ง เราเพียงแค่ต้องสร้างไฟล์ตั้งค่าที่เรียกว่า “ScaledObject” เพื่อบอก KEDA ว่าเราต้องการอะไร ตัวอย่างเช่น หากเราต้องการสเกลแอปพลิเคชันตามจำนวนข้อความใน RabbitMQ เราจะเขียนมันออกมาได้ดังนี้
โดยสรุป ไฟล์นี้เป็นการกำหนดค่าให้ KEDA ใช้คิวชื่อว่า new-orders-queue เป็นตัวชี้วัดเพื่อสเกล order-processor-deployment โดยอัตโนมัติ ยกตัวอย่างเช่น หากมี 500 ข้อความในคิว KEDA จะคำนวณตามกฎ (QueueLength) ที่ตั้งไว้ และขยายจำนวน Pods ไปที่ 50 ตัว ซึ่งเป็นขีดจำกัดสูงสุดที่ระบบจะสเกลได้
เห็นไหม…เราแค่ประกาศความต้องการของเราในรูปแบบง่ายๆ ที่เหลือ KEDA จะไปจัดการสร้างและบริหาร HPA ที่ซับซ้อนให้เราเองโดยอัตโนมัติ
ถ้าหากอยากลองติดตั้งหรือสนใจการทำงานของ KEDA สามารถตามไปอ่านต่อได้ที่ https://keda.sh/docs/2.17/deploy/
บทสรุป
HPA ยังคงเป็นเครื่องมือที่ยอดเยี่ยมและเป็นรากฐานที่สำคัญ แต่ในโลกที่ขับเคลื่อนด้วยความเร็วและอีเวนต์ การพึ่งพาแค่ CPU/Memory อาจไม่เพียงพออีกต่อไป KEDA (Kubernetes Event-driven Autoscaling) จึงเข้ามาเป็นโซลูชันสำคัญที่ทำให้ Kubernetes สามารถสเกลตามภาระงานจริงจากภายนอกได้ ด้วยความสามารถในการ สเกลเชิงรุก (Proactive Scaling) เพื่อรักษาเสถียรภาพ และ การสเกลสู่ศูนย์ (Scale to Zero) เพื่อบริหารจัดการต้นทุนอย่างมีประสิทธิภาพ ทำให้ KEDA กลายเป็นส่วนประกอบที่จำเป็น สำหรับการสร้างระบบ Cloud-Native ที่มีทั้งความยืดหยุ่น (Resilience) และความคุ้มค่าสูงสุด (Cost-efficiency)
ท้ายนี้หากองค์กรของท่านกำลังมองหาโซลูชันด้าน DevOps ช่วยปรับรูปแบบการทำงานให้เป็นอัตโนมัติ ลดต้นทุนการทำธุรกิจ SCB TechX พร้อมเป็นโซลูชันที่ช่วยพัฒนา และ Deliver ผลิตภัณฑ์และบริการออกสู่ตลาด ต่อยอดองค์กรของท่านให้เติบโตอย่างยั่งยืน
สนใจบริการโปรดติดต่อเราที่ https://bit.ly/4etA8Ym
อ่านรายละเอียดเพิ่มเติมคลิก https://bit.ly/4dpGl6U
เอกสารอ้างอิง
