การตั้งค่า Rate Limiting และ Throttling ที่ดี

Sharing is caring!

บทนำ

Rate Limiting และ Throttling เป็นกลไกสำคัญที่ใช้ในการป้องกันระบบจากการใช้งานที่มากเกินไป (overload) หรือการโจมตี เช่น DDoS หรือ bot spam บทความนี้จะพาคุณเข้าใจหลักการทำงาน วิธีตั้งค่า และตัวอย่างที่ใช้งานจริงสำหรับนักพัฒนา API หรือ Web Service

Rate Limiting คืออะไร?

Rate Limiting คือการจำกัดจำนวนคำขอ (requests) ที่ client สามารถส่งเข้ามาได้ในช่วงเวลาหนึ่ง เช่น:

• 100 requests ต่อ 1 นาที
• 10 requests ต่อ 1 วินาที

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

Throttling คืออะไร?

Throttling คือการหน่วงความเร็วของการเข้าถึงเมื่อผู้ใช้หรือ client ส่ง request เกินจากที่กำหนด เช่น

• Delay คำขอที่เกินออกไป
• ค่อย ๆ ปล่อยคำขอ (Leaky Bucket)

ความแตกต่าง

Feature	Rate Limiting	Throttling
เป้าหมาย	จำกัดจำนวน	หน่วงเวลา
เมื่อเกิน limit	บล็อก / ปฏิเสธ	ดีเลย์ / คิว
Response	429 Too Many Requests	ช้าแต่ยังตอบกลับ

กลยุทธ์ยอดนิยม

• Fixed Window – นับจำนวนคำขอในช่วงเวลาคงที่ เช่น ทุก 1 นาที
• Sliding Window – ใช้เวลาปัจจุบันลบย้อนหลัง เช่น 1 นาทีล่าสุด
• Token Bucket – มี token เพิ่มขึ้นเรื่อย ๆ ถ้าไม่มี token → ปฏิเสธ
• Leaky Bucket – อนุญาต request ด้วยอัตราคงที่

ตัวอย่างการตั้งค่าใน NGINX

http {
  limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

  server {
    location /api/ {
      limit_req zone=mylimit burst=10 nodelay;
    }
  }
}

จากตัวอย่างนี้:

• จำกัดไว้ที่ 5 requests/sec
• อนุญาต burst ได้อีก 10 requests ชั่วคราว

ตัวอย่างการตั้งค่าใน Express.js

const rateLimit = require("express-rate-limit");

const limiter = rateLimit({
  windowMs: 1 * 60 * 1000, // 1 นาที
  max: 100, // จำกัด 100 requests ต่อ IP
  message: "คุณส่งคำขอมากเกินไป กรุณารออีกสักครู่"
});

app.use("/api/", limiter);

แนวทางการออกแบบที่ดี

• ⛔ อย่าบล็อกทันที ควรใช้ burst buffer
• 📊 ควร Log การโดน limit เพื่อวิเคราะห์
• 📌 แจ้ง client ด้วย HTTP 429 + Retry-After
• 🌐 ใช้ Redis หรือ Memcached เพื่อแชร์ quota ข้ามเซิร์ฟเวอร์

Monitoring และ Metrics ที่ควรเก็บ

• จำนวน requests ที่โดน block (HTTP 429)
• อัตรา burst
• เวลาเฉลี่ยของการตอบกลับ (response time)

กรณีศึกษา

1. GitHub API

GitHub จำกัด request ที่ 60 ต่อชั่วโมงสำหรับ anonymous และ 5000 ต่อ token สำหรับ authenticated

2. Google Maps API

ใช้ทั้ง Quota per day และ QPS (Query Per Second)

สรุป

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

บทความนี้ใช้เวลาอ่าน 10 – 15 นาที เขียนโดยทีมงาน poolsawat.com