ใช้ NGINX Proxy Cache ลดโหลด Backend

proxy cache เก็บผลตอบกลับจาก backend เพื่อตอบคำขอซ้ำโดยไม่เรียกแอปทุกครั้ง เหมาะกับหน้าเว็บหรือ API แบบอ่านมากและข้อมูลเปลี่ยนไม่บ่อย บทความนี้สรุปแนวคิดจากเอกสารทางการของ NGINX และจุดที่ควรตรวจเมื่อนำไปใช้จริง

ภาพรวม

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

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

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

NGINX ใช้ cache key และนโยบายอายุข้อมูลกำหนดว่า response ใดใช้ซ้ำได้

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

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

เหมาะกับหน้าเว็บหรือ API แบบอ่านมากและข้อมูลเปลี่ยนไม่บ่อย

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

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

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

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

ข้อควรระวัง

ห้าม cache ข้อมูลส่วนตัวร่วมกันโดยไม่รวมตัวตนใน key และต้องวางแผน invalidation

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

สรุป

proxy cache เก็บผลตอบกลับจาก backend เพื่อตอบคำขอซ้ำโดยไม่เรียกแอปทุกครั้ง เหมาะกับหน้าเว็บหรือ API แบบอ่านมากและข้อมูลเปลี่ยนไม่บ่อย ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่

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