เลือกวิธี Load Balancing ของ NGINX

NGINX กระจายคำขอไปยัง upstream server หลายตัว เหมาะกับ API ที่มีหลาย instance และต้องการกระจายคำขอพร้อมเพิ่มความพร้อมใช้งาน บทความนี้สรุปแนวคิดจากเอกสารทางการของ NGINX และจุดที่ควรตรวจเมื่อนำไปใช้จริง

ภาพรวม

NGINX รับและจัดเส้นทาง HTTP ก่อนถึงแอป การตั้ง location, upstream, header, timeout และ log มีผลต่อความถูกต้อง ความเร็ว และความปลอดภัยของบริการ

หัวข้อนี้ตอบโจทย์เฉพาะเรื่อง: NGINX กระจายคำขอไปยัง upstream server หลายตัว จึงควรเริ่มจากปัญหาที่ต้องแก้และผลลัพธ์ที่คาดหวัง ไม่ใช่เพียงเปิดฟีเจอร์เพราะมีอยู่ในเครื่องมือ

หลักการทำงาน

วิธีแบบ round robin, least connections และ ip hash ให้ผลต่างกันตามลักษณะโหลด

ให้ตรวจทั้งสถานะที่เครื่องมือรายงานและผลลัพธ์ปลายทางที่ผู้ใช้หรือระบบอื่นได้รับ หากสองส่วนไม่ตรงกัน ควรกลับไปตรวจค่าตั้งต้นและขอบเขตที่ฟีเจอร์นี้รับผิดชอบก่อนเปลี่ยนค่าเพิ่มเติม

เหมาะกับงานแบบไหน

เหมาะกับ API ที่มีหลาย instance และต้องการกระจายคำขอพร้อมเพิ่มความพร้อมใช้งาน

ก่อนทดลอง ให้ระบุสิ่งที่จะใช้วัดผล เช่น เวลาตอบสนอง ความพร้อมใช้งาน ความถูกต้องของข้อมูล หรือภาระการดูแล แล้วเทียบกับสภาพเดิม วิธีนี้ช่วยให้รู้ว่าฟีเจอร์แก้ปัญหาจริงหรือย้ายภาระไปอีกจุดหนึ่ง

ขั้นตอนนำไปใช้

1. ตรวจไฟล์ตั้งค่าด้วย nginx -t ก่อน reload
2. ทดสอบ URL และ header ทั้งเส้นทางที่ถูกและควรถูกปฏิเสธ
3. ดู access log, error log และเวลา upstream หลังเปลี่ยนค่า

เริ่มจากขอบเขตเล็กและเก็บผลทดสอบไว้กับการเปลี่ยนแปลง หากจะใช้ใน production ให้กำหนดผู้ติดตามผลและเงื่อนไขที่จะหยุดการขยายการใช้งาน

ข้อควรระวัง

load balancer ไม่แก้ปัญหา session state เอง ต้องวาง shared session หรือออกแบบแอปให้เหมาะ

แปลงข้อควรระวังนี้เป็นรายการตรวจในการทบทวนงาน เพราะปัญหาจากค่าตั้งต้นอาจไม่แสดงทันทีในสภาพแวดล้อมทดสอบ

สรุป

NGINX กระจายคำขอไปยัง upstream server หลายตัว เหมาะกับ API ที่มีหลาย instance และต้องการกระจายคำขอพร้อมเพิ่มความพร้อมใช้งาน ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่

อ่านเพิ่มเติม: เอกสารทางการของ NGINX