Rate Limiter เป็น Component ที่สำคัญสำหรับควบคุม Traffic Rates ที่ส่งมาจาก Clients หรือ Services ช่วยป้องกันการโจมตี, ลดต้นทุน และรับประกันความเสถียรของ Server Resources
บทนำ
บทนี้สำรวจการออกแบบและการ Implement Rate Limiter ซึ่งเป็น System Component ที่ใช้ควบคุม Traffic Rates ที่ส่งมาจาก Clients หรือ Services Rate Limiters มีความสำคัญสำหรับการป้องกันการใช้งานเกินขนาด, ลดต้นทุน และรับประกันความเสถียรของ Server Resources
ข้อดีของ Rate Limiting
- ป้องกัน DoS Attacks: บล็อกการเรียกที่มากเกินไปเพื่อหลีกเลี่ยงการใช้ทรัพยากรจนหมด
- ลดต้นทุน: จำกัด Requests ที่ไม่จำเป็นเพื่อลดค่าใช้จ่ายของ Server
- ป้องกัน Overloads: กรอง Requests ที่มากเกินไปเพื่อรักษาประสิทธิภาพ Server
ขั้นตอนที่ 1: ทำความเข้าใจปัญหา
คุณสมบัติหลัก
- Server-side API Rate Limiter
- รองรับหลาย Throttle Rules
- รองรับระบบขนาดใหญ่ในสภาพแวดล้อมแบบ Distributed
- แจ้ง Users เมื่อถูก Throttle
ข้อกำหนด
- Request Throttling ที่แม่นยำ
- Latency ต่ำ
- การใช้ Memory ต่ำ
- ความสามารถแบบ Distributed
- การจัดการ Exception ที่ชัดเจน
- Fault Tolerance สูง
ขั้นตอนที่ 2: High-Level Design
ภาพที่ 1: สถาปัตยกรรม Rate Limiter
ตัวเลือกการวางตำแหน่ง
- Client-Side Implementation: ไม่น่าเชื่อถือเนื่องจากอาจถูกใช้ผิดวัตถุประสงค์
- Server-Side Implementation: ต้องการควบคุมและความน่าเชื่อถือ
- Middleware (API Gateway): ตัวเลือกที่ยืดหยุ่นสำหรับ Rate Limiting แบบบูรณาการ
ขั้นตอนที่ 3: อัลกอริทึม Rate Limiting
1. Token Bucket
ภาพที่ 2: Token Bucket Algorithm
Tokens ถูกเพิ่มลงใน Bucket ด้วยอัตราคงที่; แต่ละ Request ใช้ Token หนึ่ง
- Parameters: ขนาด Bucket และอัตราการ Refill
ข้อดี
- Implement ง่าย
- ใช้ Memory อย่างมีประสิทธิภาพ
- รองรับ Traffic Bursts
ข้อเสีย
- ต้องปรับ Parameters อย่างระมัดระวัง
2. Leaking Bucket
ภาพที่ 3: Leaking Bucket Algorithm
ประมวลผล Requests ด้วยอัตราคงที่โดยใช้ FIFO Queue
ข้อดี
- ใช้ Memory อย่างมีประสิทธิภาพ
- อัตราการไหลออกที่คงที่
ข้อเสีย
- Traffic Bursts อาจทำให้ Requests ล่าสุดล่าช้า
3. Fixed Window Counter
แบ่งเวลาเป็นช่วงคงที่และใช้ Counters เพื่อจำกัด Requests
ข้อดี
- เรียบง่าย
- มีประสิทธิภาพสำหรับ Use Cases เฉพาะ
ข้อเสีย
- Traffic Spikes ที่ขอบของ Time Windows อาจทำให้ Requests มากเกิน Quota ได้
4. Sliding Window Log
ติดตาม Timestamps เพื่ออนุญาต Time Window แบบ Rolling
ข้อดี
- Rate Limiting ที่แม่นยำ
ข้อเสีย
- การใช้ Memory สูง
5. Sliding Window Counter
ผสมผสานวิธี Fixed Window และ Sliding Log เพื่อลด Spikes
ข้อดี
- ใช้ Memory อย่างมีประสิทธิภาพ
- รองรับ Traffic Bursts
ข้อเสีย
- การประมาณอาจไม่เข้มงวด 100%
ขั้นตอนที่ 4: สถาปัตยกรรม High-Level
Data Storage
ใช้ In-memory Caching (เช่น Redis) สำหรับ Counter Operations ที่รวดเร็ว
ขั้นตอนการทำงาน
- Client ส่ง Request ไปยัง Middleware
- Middleware ตรวจสอบ Counters ใน Redis
- Request ถูกประมวลผลหรือปฏิเสธตาม Limits
ข้อพิจารณาขั้นสูง
สภาพแวดล้อมแบบ Distributed
- ความท้าทาย: Race Conditions, ปัญหาการ Synchronize
- วิธีแก้ไข: ใช้ Locks, Lua Scripts หรือ Sorted Sets ใน Redis
การเพิ่มประสิทธิภาพ
- การตั้งค่าหลาย Data Center เพื่อลด Latency
- ใช้ Eventual Consistency Models สำหรับ Synchronization
การ Monitor
วิเคราะห์เป็นประจำเพื่อให้แน่ใจว่าอัลกอริทึมมีประสิทธิภาพและปรับ Rules ตามความจำเป็น
เนื้อหานี้อ้างอิงจาก ByteByteGo - System Design Interview - An Insider's Guide