การ Optimize Kafka Consumers ด้วย Kubernetes และ KEDA
ในปี 2023 ผมได้ไปงาน KubeDay ที่ Singapore มี Session ที่น่าสนใจมากมายเกี่ยวกับ Kubernetes (k8s) ซึ่งหนึ่งในนั้นก็คือ การ Optimize Kafaka Consumers ด้วย Kubernetes และ Kubernetes Events Driven Autoscaling (KEDA) เป็น Open-source project ที่เอามาทำ Autoscaling
โดยคนที่มาแชร์คือ Mr. Shbuham Badkur, Miss. Simran Aggarwal และ Mr. Yuanzhe Liu ซึ่ง เป็น Senior Software Engineer ของ “Grab”
ที่เป็นที่รู้จักกันว่า Grab เป็น Real-time data platform ซึ่ง Grab ก็เป็นหนึ่ง Application ที่ใช้ Kafka ในการจัดการเป็นล้าน Record ต่อวัน
ลองคิดดูว่าถ้าเกิดมี Data เข้ามาใน Platform วันละเป็นล้านน จะทำยังไงให้มันมีประสิทธิภาพ
ซึ่ง Grab มี Challenge คือ
- ต้อง scalability และ availability แต่ cost-effective
- การ balance load ในแต่ละ Pod
- ต้องการทำตาม Service Level Agreements และการรักษาความสดใหม่ ความถูกต้องของข้อมูล
- ต้องการมอบประสบการณ์ที่ดีให้ Service Team และไม่ต้องการให้ทำ Data tuning มากเกินไป
ก่อนที่จะมาใช้ KEDA Grab ใช้วิธีไหนมาบ้างมาดูกัน
Vertical Pod Autoscaler (VPA)
วิธีนี้จะสร้าง Replica มาเท่ากับจำนวนของ Topic Partitions และทำการ Autoscaling ตาม Memory และ CPU metrics
ในช่วง Peak เป็นที่น่าพึงพอใจ แต่ตอนที่มัน Off-Peak ไม่ได้ประสิทธิภาพตามที่ต้องการ ตามทฤษฎีแล้ว ควรจะมีโหลดที่เท่ากันใน Pod ทั้งหมด แต่ในทางปฏิบัติแล้ว ไม่ได้เข้าใกล้เลยด้วยซ้ำ และการทำให้จำนวน Pod เท่ากับจำนวน Partition แล้ว Autoscale ตลอดทำให้ non cost-effective อีกด้วย
Horizontal Pod Autoscaler (HPA)
HPA ช่วยยังไงจากตอนที่ใช้ VPA เราใช้จำนวน Pod เท่ากับจำนวน Partition โดยจะ Scale ตามความต้องการใช้งานโดยวัดวิธีเดียวกับ VPA เลยคือ Memory และ CPU metrics
เมื่อ Load เข้ามาน้อยก็จะปรับจำนวน Pod ลงทำให้จากที่เคยใช้ CPU ได้ประมาณ 50% ซึ่งสูงกว่า 20% เลยทีเดียวซึ่งตอบโจทย์เรื่อง cost-effectiveness แต่การที่ สามารถทำการ scale in หรือ scale out ตามโหลดงานที่ deployment ทั้งหมดกำลังประมวลผลอยู่ ทำให้การกำหนด partition สำหรับแต่ละ pod ไม่สามารถควบคุมได้
ปัญหาอื่นคือการใช้ทรัพยากรไม่สมดุลระหว่าง pods การใช้เฉลี่ยของ CPU และ memory utilization metrics เพื่อดำเนินการ scaling นั่นหมายความว่าอาจมีสถานการณ์ที่หนึ่งหรือสอง pods ใช้ทรัพยากรมากเกินไปและปัญหานี้ HPA ไม่สามารถตรวจจับได้
ทำให้เกิดความล่าช้าของการประมวลผล และเกิด higher consumer lag เมื่อการใช้ทรัพยากรมากกว่าที่ได้รับการกำหนดไว้สำหรับการประมวลผล ทำให้ขัดกับ SLAs
ความจำเป็นในการปรับแต่งทรัพยากรอย่างต่อเนื่องด้วย HPA ก็เป็นปัญหาเช่นกัน มีทรัพยากรจำนวนคงที่ซึ่งกำหนดไว้สำหรับการปรับใช้แต่ละครั้ง โดยพื้นฐานแล้ว HPA สามารถขยายขนาดออกตามจำนวน Replicas สูงสุดเพื่อประมวลผลโหลด ในสถานการณ์ที่มีการเปลี่ยนแปลงการรับส่งข้อมูลทั่วไปภายใน Topic จะต้องเข้ามาปรับแต่งด้วยมือจากผู้ใช้ เพื่อให้มีทรัพยากรที่เหมาะสมสำหรับการประมวลผล
Kubernetes Event Driven Autoscaler (KEDA)
KEDA เป็นกลไกการ scale ที่ตอบสนองตามเหตุการณ์หรือ event-driven ที่เปิดให้เรา scale pods ในแนวนอนตาม trigger หรือ event จากภายนอก เหมาะกับแอปพลิเคชันที่มี Action ตาม Event ต่างๆ
ด้วยการใช้ KEDA เราสามารถนำเข้า Metric ที่กำหนดเองเพื่อ scale การใช้งานของ Kafka consumer lag ที่เกี่ยวข้องโดยตรงกับ SLAs และยังช่วยในการเพิ่มประสิทธิภาพในการใช้ทรัพยากรด้วย เช่นการกำหนดเป้าหมายของการใช้ทรัพยากร CPU ให้มากกว่า 80% เพื่อเพิ่มประสิทธิภาพในการใช้ทรัพยากร
KEDA มีความสามารถในการทำการ Scale ที่ซับซ้อนและมีการ monitor ของ Datadog นอกจากนี้ โดยการใช้ Datadog scaler ที่มีใน KEDA เราสามารถนำ metric ที่กำหนดเองจากแดชบอร์ด Datadog เข้าสู่กระบวนการ auto-scaling ได้
และยังมีตัวช่วยคือ
Resource Advisor (CRD)
Resource Advisor เป็นเครื่องมือสำหรับการจัดการและเพิ่มประสิทธิภาพทรัพยากร ประกอบด้วยส่วนประกอบทั้งหมด 4 ส่วนคือ
- Scheduler : ซึ่งเป็น Schedule ที่ช่วยลีกเลี่ยงการเกิด Confilict ที่เกิดจากการ Auto scaling โดย KEDA
- Data collector : ซึ่งจะเก็บข้อมูลประวัติศาสตร์เพื่อทราบความต้องการในการประมวลผลและทรัพยากรของแอปพลิเคชันก่อนที่จะเปลี่ยนขนาดพอร์ต
- Recommender : ซึ่งทำการแนะนำโดยใช้ข้อมูลที่เก็บรวบรวมโดยตัวเก็บข้อมูล
Updater : ซึ่งทำหน้าที่การจัดสรรทรัพยากรโดยตัวทำการอัปเดต
สรุป
Grab ใช้ KEDA และ CRD และตอบโจทย์ Challengs 4 ข้อ คือ
- ต้อง scalability และ availability แต่ cost-effective
- การ balance load ในแต่ละ Pod
- ต้องการทำตาม Service Level Agreements และการรักษาความสดใหม่ ความถูกต้องของข้อมูล
- ต้องการมอบประสบการณ์ที่ดีให้ Service Team และไม่ต้องการให้ทำ Data tuning มากเกินไป
บทความนี้เป็นการฟังและสรุปจากตัวผมเองผิดพลาดประการใดขออภัยด้วยครับ
อ้างอิง
Optimizing Kafka Consumers with Kubernetes and KEDA Shubham Badkur, Yuanzhe Liu & Simran Aggarwal @ KubeDay Singapore 2023
