ทำ API Rate Limiting ด้วย Nginx ให้ระบบรับ Traffic Spike ได้ดีขึ้น

ภาพรวม

ยิง API ถี่เกินไป ไม่ได้แปลว่าระบบพังเสมอไป บางครั้งปัญหามาจาก client เรียกซ้ำเร็วเกิน, bot ไล่ยิง, หรือ user กดรีเฟรชรัวๆ ⚡

หนึ่งในด่านหน้าที่ช่วยลดภาระ backend ได้ดีมาก คือ Nginx Rate Limit 🛡️

ข้อดีของการกันตั้งแต่ชั้น Nginx ลดโหลดก่อนถึง app server 🚦 ลด request ไร้ประโยชน์ ช่วยต้าน brute force และ abuse เบื้องต้น 🔒 ทำให้ API เสถียรมากขึ้นตอนทราฟฟิกพุ่ง 📈

แนวคิดสำคัญมี 2 ส่วน limit_req_zone ใช้กำหนดพื้นที่เก็บสถานะการนับ request limit_req ใช้กำหนดกติกาว่าจะให้ผ่านได้แค่ไหน

ตัวอย่างที่ใช้บ่อย จำกัดตาม IP เช่น 10 requests ต่อวินาที เหมาะกับ public API หรือ endpoint ที่เสี่ยงโดนยิงหนัก 🌐

ตัวอย่าง config แบบอ่านง่าย

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

server { location /api/ { limit_req zone=api_limit burst=20 nodelay; } }

ความหมายแบบภาษาคน 👨‍💻 $binary_remote_addr = นับแยกตาม IP ของผู้เรียก zone=api_limit:10m = พื้นที่จำสถานะ 10 MB rate=10r/s = เฉลี่ยให้ 10 ครั้งต่อวินาที burst=20 = เกินได้ชั่วคราวอีก 20 ครั้ง nodelay = ถ้าอยู่ใน burst ให้ปล่อยผ่านทันที ไม่ต้องรอ

จุดที่หลายคนพลาด 😵 ตั้ง rate ต่ำเกินไปจน mobile app ใช้งานสะดุด เปิด burst น้อยเกิน ทำให้ request ที่มาพร้อมกันโดน 429 ง่าย ใช้ nodelay โดยไม่เข้าใจว่า traffic spike จะหลุดเข้า backend เร็วขึ้น

อีกเทคนิคที่มีประโยชน์มาก แยก rate limit ตาม endpoint

เช่น /login ควรเข้มกว่าปกติ เพราะเสี่ยง brute force 🔐 /search อาจต้องเผื่อ burst มากหน่อย เพราะ user พิมพ์ต่อเนื่อง /webhook ควรระวังเป็นพิเศษ ถ้ามี provider ส่ง event มารัวๆ 📩

ตัวอย่างแนวคิด login_limit เข้ม api_limit กลางๆ upload_limit ผ่อนขึ้นนิด เพราะ request ใหญ่และนาน 📦

หลายระบบพังเพราะ limit ตาม IP อย่างเดียว แต่โลกจริงมี NAT, office network, mobile carrier ทำให้ผู้ใช้จำนวนมากออก IP เดียวกันได้ 🏢

ถ้ากันแรงเกิน คนจริงจะโดนหางเลขทันที วิธีคิดที่ดีกว่า ดูร่วมกับ path, method, token, หรือชั้น auth ด้วย

อีกเรื่องที่คนมองข้าม 429 Too Many Requests ไม่ควรเป็นแค่ error เงียบๆ 🚨 ควรส่ง header หรือข้อความที่ client เอาไปจัดการต่อได้ เช่น retry หลังจากกี่วินาที

ถ้าใช้ร่วมกับ app logic จะยิ่งดี ชั้น Nginx กรองของหยาบ ชั้นแอปตรวจสิทธิ์เชิงลึก ชั้น database ไม่ต้องรับภาระเกินจำเป็น 🧠

แนวทาง rollout แบบปลอดภัย เริ่มจาก endpoint เสี่ยงก่อน เก็บ log การโดน limit ดูเปอร์เซ็นต์ 429 ค่อยๆ ปรับ rate ตามพฤติกรรมจริง 📊

ทริคที่ช่วยได้มากสำหรับ production แยก limit สำหรับ bot, guest, และ user ที่ login แล้ว เพราะแต่ละกลุ่มมีพฤติกรรมไม่เหมือนกัน 🤖

บางทีมใช้ rate limit เป็นเหมือนสวิตช์ฉุกเฉิน ตอนระบบเริ่มหน่วง ก็ลดเพดานบาง endpoint ชั่วคราว ช่วยยื้อระบบให้รอดระหว่างแก้ incident ได้ ⏱️

ถ้าดูแล API ที่มีคนใช้งานจริง การทำ rate limit ไม่ใช่แค่กันโจมตี แต่มันเป็นเครื่องมือบริหารทรัพยากรของระบบด้วย 💼

ตั้งดี ระบบนิ่งขึ้น ตั้งพลาด ลูกค้าจริงใช้งานสะดุด ต่างกันแค่เข้าใจ traffic ของตัวเองมากพอหรือยัง ✨

Nginx ไม่ได้มีดีแค่ serve static หรือ reverse proxy ถ้าใช้ rate limit ให้ถูกจุด มันช่วยเซฟ backend ได้แบบเห็นผลเร็วมาก 🚀

แนวทางนำไปใช้

• นำแนวคิดจากโพสต์นี้ไปทดลองกับงานจริงของคุณ
• แยกเป็นขั้นตอนเล็ก ๆ แล้วทำทีละส่วน
• บันทึกผลลัพธ์และสิ่งที่เรียนรู้เพื่อต่อยอด

สรุป

ตั้งค่า limit_req_zone, rate, burst และ nodelay ให้เหมาะกับแต่ละ endpoint เพื่อกรอง request ก่อนถึงแอป ลด abuse และควบคุมทรัพยากรของระบบ