Rate Limiting คืออะไร คู่มือภาษาง่ายสำหรับผู้สร้างแอป

Rate limiting คือกฎที่จำกัดจำนวนคำขอที่ใครคนหนึ่งส่งไปยังระบบได้ในช่วงเวลาที่กำหนด เช่น ล็อกอินได้ 5 ครั้งต่อนาที หรือเรียก API ได้ 100 ครั้งต่อชั่วโมง เมื่อถึงขีดจำกัดแล้ว คำขอเพิ่มเติมจะถูกปฏิเสธ (มักพร้อมรหัสข้อผิดพลาด 429 Too Many Requests) จนกว่าช่วงเวลาจะรีเซ็ต มันช่วยปกป้องแอปจากการใช้งานในทางที่ผิด ป้องกันไม่ให้ผู้ใช้คนเดียวที่ใช้งานหนักทำให้ทุกคนช้าลง และหยุดค่าใช้จ่ายที่ควบคุมไม่ได้

คุณจะเจอ rate limiting จากสองด้าน: บริการที่คุณเรียกใช้ จำกัด คุณ และแอปของคุณเอง ควรจำกัด ผู้ใช้ของมัน

ทำไม rate limiting จึงสำคัญเมื่อสร้างด้วย AI

แอปที่สร้างด้วย AI มักเชื่อมต่อกับบริการที่มีค่าใช้จ่าย เช่น โมเดล AI อีเมล SMS แผนที่ และแต่ละการเรียกมีค่าใช้จ่าย ดังนั้น rate limiting จึงเป็นทั้งฟีเจอร์ความปลอดภัยและฟีเจอร์ควบคุมงบประมาณ

• ควบคุมค่าใช้จ่าย หากแอปของคุณมีช่อง "ถาม AI" และไม่มีขีดจำกัด บอทสามารถส่งคำขอหลายพันครั้งข้ามคืน คุณต้องจ่ายสำหรับทุกคำขอ
• ความปลอดภัย หากไม่จำกัดหน้าล็อกอิน ผู้โจมตีสามารถลองรหัสผ่านหลายพันครั้งกับบัญชีเดียว ขีดจำกัดไม่กี่ครั้งต่อนาทีทำให้การนี้เป็นไปไม่ได้จริง
• คงการทำงานออนไลน์ โค้ดที่ทำงานผิดพลาดเพียงตัวเดียว บางครั้งเป็นโค้ดของคุณเองที่ติดลูป สามารถทำให้ฐานข้อมูลโอเวอร์โหลดและทำให้แอปล่มได้
• เคารพขีดจำกัดของบริการอื่น เมื่อแอปของคุณเรียก API ภายนอกบ่อยเกินไป คุณจะได้รับข้อผิดพลาด 429 และฟีเจอร์จะพังสำหรับผู้ใช้ของคุณ

เครื่องมือสร้างแอปด้วย AI จะสร้างสิ่งที่คุณขอ ถ้าคุณไม่พูดถึงขีดจำกัด มักจะถูกละไว้

ตัวอย่างในชีวิตประจำวัน

ลองนึกถึงนโยบายเติมกาแฟฟรีของร้านกาแฟ: "เติมฟรีหนึ่งครั้งต่อลูกค้าต่อการมาหนึ่งครั้ง"

• มันไม่ได้ห้ามใครดื่มกาแฟ
• มันหยุดคนหนึ่งคนที่ยืนอยู่หน้าเคาน์เตอร์ทั้งวันเพื่อเติมกระติกให้ทั้งออฟฟิศ
• เมื่อมีคนขอเติมครั้งที่สี่ บาริสต้าจะบอกอย่างสุภาพว่า "ตอนนี้ยังไม่ได้ครับ" นั่นคือ 429

ขีดจำกัดที่ดีจะมองไม่เห็นสำหรับลูกค้าปกติ และจะถูกสังเกตเห็นเฉพาะกับคนที่ทำอะไรผิดปกติ

rate limiting ทำงานอย่างไร

ตัวจำกัดอัตรา (rate limiter) ต้องการสามส่วน:

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

มีวิธีนับที่พบบ่อยไม่กี่แบบ:

ตัวนับต้องถูกเก็บในที่ที่เร็วและใช้ร่วมกันได้ บนเซิร์ฟเวอร์เล็กเครื่องเดียว หน่วยความจำก็ใช้ได้ เมื่อแอปทำงานบนหลายเครื่อง ตัวนับมักอยู่ในที่เก็บที่ใช้ร่วมกัน เช่น Redis หรือฐานข้อมูล ไม่เช่นนั้นแต่ละเครื่องจะนับแยกกัน และขีดจำกัดจริงจะกลายเป็นหลายเท่า

การตอบกลับเมื่อถูกจำกัดอัตราหน้าตาเป็นอย่างไร

เมื่อคำขอเกินขีดจำกัด API ที่ทำงานดีจะตอบกลับด้วย:

• สถานะ 429 Too Many Requests
• มักมี ส่วนหัว Retry-After บอกจำนวนวินาทีที่ต้องรอ
• บางครั้งมีส่วนหัวที่แสดงขีดจำกัดของคุณและจำนวนคำขอที่เหลือในช่วงนี้ (ชื่อแตกต่างกันไปตามผู้ให้บริการ)

แอปของคุณควรตอบสนองต่อ 429 ด้วยการรอแล้วลองใหม่ในภายหลัง โดยควรใช้ exponential backoff ซึ่งหมายถึงการรอนานขึ้นเรื่อยๆ หลังความพยายามที่ล้มเหลวแต่ละครั้ง (1 วินาที แล้ว 2 แล้ว 4) แทนการยิงคำขอซ้ำๆ ใส่บริการ

ตัวอย่างประกอบ: ผู้ช่วยเขียนด้วย AI

สมมติว่าคุณสร้างแอปที่ผู้ใช้วางข้อความและได้ข้อความเขียนใหม่จาก AI

ไม่มีขีดจำกัด: มีคนเขียนสคริปต์ที่ส่ง 20,000 คำขอข้ามคืน บิลของผู้ให้บริการ AI พุ่ง และบัญชีของคุณชนขีดจำกัดของผู้ให้บริการเอง ผู้ใช้จริงจึงเห็นข้อผิดพลาดตลอดช่วงเช้า

มีขีดจำกัดที่เหมาะสม:

1. ต่อผู้ใช้ที่ล็อกอิน: เขียนใหม่ได้ 30 ครั้งต่อชั่วโมงในแพ็กเกจฟรี และ 300 ครั้งในแพ็กเกจที่เสียเงิน เมื่อเกินขีดจำกัด ผู้ใช้จะเห็นว่า "คุณใช้สิทธิ์ของชั่วโมงนี้ครบแล้ว ลองใหม่ใน 12 นาที หรืออัปเกรด"
2. ต่อ IP address ในฟอร์มสมัครสมาชิก: สมัคร 5 ครั้งต่อชั่วโมง เพื่อหยุดบอทที่สร้างบัญชีฟรีหลายพันบัญชีเพื่อเลี่ยงขีดจำกัดต่อผู้ใช้
3. วงเงินใช้จ่าย ที่ตั้งไว้ในแดชบอร์ดของผู้ให้บริการ AI เป็นแนวป้องกันสุดท้ายหากทุกอย่างอื่นล้มเหลว
4. การจัดการขีดจำกัดของผู้ให้บริการ: หากผู้ให้บริการ AI ตอบ 429 เซิร์ฟเวอร์ของคุณจะรอแล้วลองใหม่หนึ่งหรือสองครั้ง จากนั้นแสดงข้อความที่เป็นมิตรว่า "ระบบไม่ว่าง กรุณาลองอีกครั้ง"

ขีดจำกัดต้องตรวจบนเซิร์ฟเวอร์ ขีดจำกัดที่มีเฉพาะในเบราว์เซอร์ เช่น การปิดปุ่มหลังคลิก 30 ครั้ง สามารถถูกเลี่ยงได้โดยใครก็ตามที่เรียก API ของคุณโดยตรง

คำศัพท์สำคัญ

ความเข้าใจผิดที่พบบ่อย

• "rate limiting มีไว้สำหรับแอปใหญ่เท่านั้น" แอปเล็กก็เป็นเป้าหมายเช่นกัน เพราะบอทสแกนอินเทอร์เน็ตทั้งหมดเพื่อหาฟอร์มและ endpoint AI ที่เปิดอยู่ ต้นทุนของการถูกละเมิดไม่ขึ้นกับขนาดของคุณ
• "ซ่อนปุ่มก็พอแล้ว" ขีดจำกัดฝั่งเบราว์เซอร์เป็นเพียงการช่วยเหลือ ไม่ใช่การป้องกัน ขีดจำกัดจริงต้องบังคับใช้บนเซิร์ฟเวอร์
• "ขีดจำกัดต่อ IP ยุติธรรมเสมอ" คนจำนวนมากอาจใช้ IP address เดียวกัน เช่น ออฟฟิศ โรงเรียน หรือเครือข่ายมือถือ ขีดจำกัดต่อผู้ใช้ยุติธรรมกว่าเมื่อคนล็อกอินแล้ว
• "429 หมายความว่าบริการพัง" มันหมายความว่าคุณเรียกบ่อยเกินไป ตรวจโค้ดหาลูป และแคชผลลัพธ์ที่ไม่เปลี่ยนบ่อย ดู การแคชคืออะไร
• "rate limiting แทนวงเงินใช้จ่ายได้" ใช้ทั้งคู่ ขีดจำกัดในแอปของคุณอาจมีบั๊ก วงเงินของผู้ให้บริการคือแนวป้องกันสำรอง

สิ่งที่ควรถามเครื่องมือสร้างแอปด้วย AI

• "เพิ่ม rate limiting ฝั่งเซิร์ฟเวอร์ให้การล็อกอิน การสมัคร การรีเซ็ตรหัสผ่าน และ endpoint AI แนะนำขีดจำกัดที่เหมาะสมด้วย"
• "จำกัดผู้ใช้ที่ล็อกอินแต่ละคนไว้ที่ [N] คำขอ AI ต่อชั่วโมง และแสดงข้อความที่ชัดเจนพร้อมเวลารอเมื่อถึงขีดจำกัด"
• "เมื่อ API ภายนอกตอบ 429 ให้ลองใหม่ด้วย exponential backoff สูงสุด 3 ครั้ง จากนั้นแสดงข้อผิดพลาดที่เป็นมิตร"
• "ตัวนับของ rate limit ถูกเก็บที่ไหน จะยังทำงานได้ไหมหากแอปทำงานบนหลายเครื่อง"
• "บันทึกทุกครั้งที่ผู้ใช้หรือ IP ชนขีดจำกัด เพื่อให้ฉันตรวจพบการละเมิดได้"
• "แอปนี้เรียกบริการภายนอกใดบ้าง และขีดจำกัดของบริการเหล่านั้นคืออะไร"

Rate limiting ใน Mythex

เอกสารของ Mythex ตรงไปตรงมาเรื่องนี้สำหรับฟีเจอร์ AI: rate limit การควบคุมความปลอดภัยและค่าใช้จ่ายในแอปที่คุณสร้างเป็นความรับผิดชอบของคุณในการออกแบบ ดู สร้างแอป AI ขอให้เอเจนต์เพิ่มขีดจำกัดในข้อความเดียวกับที่ขอฟีเจอร์ได้เลย ในแพ็กเกจ Pro บริการที่เผยแพร่แล้วสามารถทำงานได้ถึงสามเครื่องเมื่อทราฟฟิกหนาแน่น (ดู ขีดจำกัดการโฮสต์) ดังนั้นควรขอให้ตัวนับเก็บในฐานข้อมูล แทนที่จะเก็บในหน่วยความจำของเซิร์ฟเวอร์เครื่องเดียว

อ่านเพิ่มเติม: API คืออะไร วิธีใช้ LLM API และเช็กลิสต์ความปลอดภัยสำหรับแอปที่สร้างด้วย AI

คำถาม