เจาะลึก API Rate Limiting ข้อผิดพลาดและวิธีแก้ปัญหา

ทีมพัฒนาหลายแห่งมักเพิ่มระบบจำกัดความเร็วคำขอหรือ Rate Limiting ให้กับ API เป็นขั้นตอนสุดท้าย หลังจากที่ระบบเกิดปัญหาขึ้นแล้ว ไม่ว่าจะเป็นการถูกดูดข้อมูลโดย Scraper, ปัญหา Retry Loop จากฝั่งไคลเอนต์ หรือผู้ใช้งานเพียงคนเดียวที่ใช้ทรัพยากรจนหมด ส่งผลให้ระบบล่มสำหรับผู้ใช้คนอื่น ซึ่งในจุดนั้นกลายเป็นการแก้ปัญหาเฉพาะหน้ามากกว่าการออกแบบระบบตั้งแต่ต้น

บทความนี้พาไปสำรวจข้อผิดพลาดที่พบบ่อยที่สุดเกี่ยวกับการจำกัดคำขอในระบบโปรดักชัน เหตุผลที่ข้อผิดพลาดเหล่านี้เกิดขึ้น และแนวทางปฏิบัติที่ช่วยให้ระบบมีความยืดหยุ่นสูงขึ้น สัญชาตญาณแรกของหลายคนคือการจำกัดจำนวนคำขอที่ X ครั้งต่อนาทีต่อหนึ่ง API Key แต่ในทางปฏิบัติวิธีตัวเลขเดี่ยวนี้มักพังทลายอย่างรวดเร็ว

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ทางออกที่ดีกว่าคือการเลือกใช้ขั้นตอนวิธีแบบ Sliding Window หรือ Token Bucket แทนการรีเซ็ตแบบแข็งทุกๆ Nวินาที โดย Token Bucket จะเติมโทเคนด้วยอัตราคงที่และคิดค่าใช้จ่ายตามแต่ละคำขอ ซึ่งช่วยรองรับช่วงที่ทราฟฟิกพุ่งสูงชั่วคราวได้ดีกว่า นอกจากนี้ควรใช้การจำกัดตามต้นทุน (Cost-based Limiting) ไม่ใช่แค่การนับจำนวนอย่างเดียว เพื่อให้อินเทอร์เฟซการค้นหาที่มีราคาแพงใช้โควตามากกว่าการดึงข้อมูลตาม ID ธรรมดา

ข้อผิดพลาดที่ร้ายแรงที่สุดไม่ใช่การตั้งค่าตัวเลขผิดพลาด แต่เป็นการที่ระบบ Rate Limiting ไม่ได้ถูกกระจายอย่างถูกต้องผ่านเซิร์ฟเวอร์หลายตัว หากอินสแตนซ์แต่ละตัวเก็บบันทึกการนับในหน่วยความจำของตัวเอง ไคลเอนต์จะสามารถคูณขีดจำกัดที่แท้จริงตามจำนวนเซิร์ฟเวอร์ที่อยู่เบื้องหลังโหลดบาลานเซอร์ได้ วิธีแก้คือการรวมศูนย์ตัวนับผ่าน Redis

ที่มา: Dev.to