เรากำลังจำกัดอัตราการเรียกของบริการของเราเอง

API ของ Mythex อนุญาต 300 คำขอต่อนาทีจากที่อยู่เครือข่ายหนึ่งที่อยู่ ขีดจำกัดนั้นมีไว้เพื่อปกป้อง API จากคนเดียวหรือสคริปต์เดียวที่ยิงคำขอรัว ในโปรดักชัน มันเริ่มปฏิเสธบริการของเราเองแทน ได้แก่ส่วน edge ที่เสิร์ฟแอปที่เผยแพร่แล้ว และบริการที่รัน agent AI เพราะแต่ละบริการเข้าถึง API จากที่อยู่จำนวนน้อยมาก ตอนนี้คำขอที่มี internal credential ของเราได้รับการยกเว้น และทุกคนอื่นยังถูกจำกัดเหมือนเดิม

อาการ

API เริ่มตอบการเรียกภายในบางส่วนของเราด้วย 429 Too Many Requests มีการเรียกสามประเภทที่โดนผลกระทบ และแต่ละอย่างสำคัญต่อคนที่ใช้ Mythex:

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

ไม่มีอันไหนเป็นคนที่เรียก API ทั้งหมดเป็นเราเอง

ทำไมมันเกิดขึ้น

ขีดจำกัดอัตราต่อที่อยู่ทำให้สมมติฐานเดียว: หนึ่งที่อยู่คือผู้เรียกหนึ่งราย สำหรับคน มันใกล้เคียงพอ สำหรับโครงสร้างพื้นฐานของเราเอง มันผิดอย่างมาก

• บริการ edge ที่เสิร์ฟแอปที่เผยแพร่และพรีวิวเข้าถึง API จาก ที่อยู่ขาออกที่ใช้ร่วมกันไม่กี่ที่ ผู้เข้าชมทุกคนของแอปที่เผยแพร่ทุกแอป และการตรวจพรีวิวทุกครั้ง มาถึงโดยดูเหมือนมาจากที่อยู่ไม่กี่ที่เหล่านั้น
• orchestrator ซึ่งเป็นบริการที่รันเทิร์นของ agent เข้าถึง API จาก ที่อยู่ container เดียว ทุกเทิร์นที่กำลังรันของทุกผู้ใช้ใช้ที่อยู่นั้นร่วมกัน

ดังนั้นงบประมาณที่มีไว้สำหรับคนหนึ่งคนจึงถูกแบ่งให้ทราฟฟิกทั้งหมดของบริการทั้งบริการ บริการเหล่านั้นใช้มันจนหมดรวมกัน และตัวจำกัดก็ทำตามที่ถูกตั้งไว้: มันปฏิเสธพวกเขา

วิธีแก้

บริการของเราพิสูจน์ตัวตนอยู่แล้ว การเรียกภายในทุกครั้งมี internal token และทุก route ภายใต้ส่วนภายในของ API จะตรวจ token นั้นก่อนทำอะไรก็ตาม

ตอนนี้ตัวจำกัดอัตราใช้การตรวจสอบเดียวกัน คำขอที่ token ตรงกับ internal token จะอยู่ใน allow list และไม่นับเข้างบประมาณต่อที่อยู่ ทุกอย่างอื่นนับเหมือนเดิม: 300 คำขอต่อนาทีต่อที่อยู่

รายละเอียดสองอย่างทำให้สิ่งนี้ไม่กลายเป็นช่องโหว่:

1. token ปลอมไม่ได้รับการยกเว้น allow list จับคู่เฉพาะ internal token จริงเท่านั้น คำขอที่มี token ที่สร้างขึ้นจะถูกนับและจำกัดเหมือนคำขออื่น และ route ภายในยังคงปฏิเสธด้วย 401 Unauthorized
2. ตัวเลขขีดจำกัดไม่เปลี่ยน เราไม่ได้เพิ่มตัวเลขเพื่อเปิดทาง การเพิ่มมันจะซ่อนปัญหาไว้จนกว่าทราฟฟิกจะโตอีกครั้ง และจะทำให้การป้องกันอ่อนลงสำหรับกรณีที่ขีดจำกัดมีไว้

เราย้ายการตั้งค่าของตัวจำกัดไปไว้ในฟังก์ชันเล็กๆ ฟังก์ชันเดียว และเขียน test ให้มัน อันหนึ่งส่ง 20 คำขอพร้อม internal token ไปยังตัวจำกัดที่อนุญาต 5 และคาดว่าทั้ง 20 จะสำเร็จ อีกอันส่งคำขอธรรมดาจากที่อยู่หนึ่ง และคาดว่าห้าอันแรกจะสำเร็จ ส่วนที่เหลือจะถูกปฏิเสธ อันที่สามส่งคำขอพร้อม token ปลอม และคาดว่าจะถูกปฏิเสธในลักษณะเดียวกัน

สิ่งที่เราเรียนรู้

• ขีดจำกัดมีสมมติฐานติดมาด้วย "หนึ่งที่อยู่ หนึ่งผู้เรียก" ฝังอยู่ในขีดจำกัดต่อที่อยู่ มันหยุดเป็นจริงทันทีที่บริการของคุณเองอยู่หลังที่อยู่ที่ใช้ร่วมกัน และหลายบริการเป็นแบบนั้น: load balancer, เครือข่าย edge, container, เครือข่ายสำนักงาน
• แยกทราฟฟิกของคุณเองด้วยตัวตน ไม่ใช่ที่อยู่ ที่อยู่เป็นวิธีที่ทราฟฟิกมาถึง ไม่ใช่ว่าใครส่งมา เรามี credential ที่พิสูจน์ว่าคำขอเป็นของเราอยู่แล้ว ตัวจำกัดแค่ไม่ได้มองไปที่มัน
• อย่าแก้ด้วยการเพิ่มตัวเลข ขีดจำกัดที่ใหญ่ขึ้นจะทำให้ 429 หายไปชั่วคราว แต่จะปกป้องน้อยลง และจะล้มเหลวอีกในภายหลัง
• ดูว่าใครกำลังถูกจำกัด 429 ที่ตกกับบริการของคุณเองคือรายงานบั๊กเกี่ยวกับขีดจำกัดของคุณ ไม่ใช่สัญญาณว่าตัวจำกัดทำงาน

มันหมายถึงอะไรถ้าคุณสร้างบน Mythex

ไม่มีอะไรที่คุณต้องเปลี่ยนฝั่งคุณ แอปที่เผยแพร่บนโดเมนที่กำหนดเอง เทิร์นของ agent และพรีวิว ไม่พึ่งพาความยุ่งของส่วนอื่นของ Mythex อีกต่อไป ทราฟฟิกของแอปคุณเป็นเรื่องของแอปคุณ ขีดจำกัดที่กล่าวถึงที่นี่อยู่บน API ของเรา ไม่ได้อยู่บนแอปที่คุณเผยแพร่

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