Limitàvem els nostres propis serveis

L'API de Mythex permet 300 peticions per minut des d'una adreça de xarxa. Aquest límit existeix per protegir-nos d'una persona o d'un script que bombardegi l'API. En producció, va començar a rebutjar els nostres propis serveis (la part del nostre edge que serveix les apps publicades i el servei que executa l'agent d'IA), perquè cadascun crida l'API des d'només unes quantes adreces. Les peticions que porten la nostra credencial interna ara queden exemptes, i tothom més continua limitat exactament com abans.

El símptoma

L'API va començar a respondre algunes de les nostres pròpies crides internes amb 429 Too Many Requests. Es van veure afectats tres tipus de crida, i cadascun importa a algú que fa servir Mythex:

• Consultar quina app viu en un domini personalitzat. Quan un visitant obre una app publicada en el seu propi domini, el nostre edge pregunta a l'API on és aquest lloc. Un 429 allà vol dir un visitant que no pot arribar a un lloc.
• Desar un torn d'agent en execució. Mentre l'agent treballa, el progrés es desa a mesura que avança, perquè una resposta sobrevisqui a una recàrrega o a una connexió perduda. Un 429 allà vol dir progrés que no s'ha desat.
• Comprovar l'accés a una previsualització. La previsualització d'una app que estàs construint està protegida, i el control pregunta a l'API. Un 429 allà vol dir una previsualització que no s'obre.

Cap d'aquestes crides no la feia una persona. Totes les feiem nosaltres.

Per què va passar

Un límit de peticions per adreça fa una suposició: una adreça és aproximadament un sol client. Per a les persones, això és prou proper. Per a la nostra pròpia infraestructura, és molt equivocat.

• El servei d'edge que serveix les apps publicades i les previsualitzacions es connecta a l'API des de unes quantes adreces de sortida compartides. Cada visitant de cada app publicada, i cada comprovació de previsualització, arriba semblant que ve d'una d'aquelles poques adreces.
• L'orquestrador (el servei que executa els torns de l'agent) es connecta a l'API des d'una sola adreça de contenidor. Cada torn en execució, per a cada usuari, la comparteix.

Així que el pressupost pensat per a una persona es repartia entre tot el trànsit de tot un servei. Aquests serveis el van consumir entre tots, i el limitador va fer el que se li havia dit: els va refusar.

La solució

Els nostres propis serveis ja demostren qui són. Cada crida interna porta un token intern, i cada ruta de la secció interna de l'API comprova aquest token abans de fer res.

El limitador de peticions ara fa servir la mateixa comprovació. Una petició el token de la qual coincideix amb el token intern està en una llista permesa i no es compta dins del pressupost per adreça. Tota la resta es compta exactament com abans: 300 peticions per minut per adreça.

Dos detalls van evitar que això es convertís en un forat:

1. Un token equivocat no té cap passi. La llista permesa només coincideix amb el token intern real. Una petició amb un token inventat es compta i es limita com qualsevol altra, i les rutes internes la rebutgen igualment amb 401 Unauthorized.
2. El límit en si no va canviar. No vam pujar el número per fer lloc. Pujar-lo hauria amagat el problema fins que el trànsit tornés a créixer, i hauria debilitat la protecció per al cas que el límit existeix.

Vam moure la configuració del limitador a una petita funció i hi vam escriure proves. Una envia 20 peticions amb el token intern a un limitador configurat per permetre 5, i espera que les 20 reeixin. Una altra envia peticions normals des d'una adreça i espera que les cinc primeres reeixin i les següents siguin refusades. Una tercera envia peticions amb un token falsificat i espera que siguin refusades de la mateixa manera.

Què ens hem endut

• Els límits porten suposicions. «Una adreça, un client» està integrat en un límit per adreça. Deixa de ser cert en el moment que els teus propis serveis són darrere d'adreces compartides, i molts ho són: equilibradors de càrrega, xarxes d'edge, contenidors, xarxes d'oficina.
• Distingeix el teu propi trànsit per la identitat, no per l'adreça. Les adreces són com arriba el trànsit, no qui l'ha enviat. Ja teníem una credencial que demostra que una crida és nostra; el limitador simplement no la mirava.
• No ho arreglis pujant el número. Un límit més alt hauria fet desaparèixer els 429 durant un temps, hauria protegit menys i hauria fallat més endavant.
• Mira qui és limitat. Un 429 que cau sobre el teu propi servei és un informe d'error sobre els teus límits, no un signe que el limitador funciona.

Què significa si construeixes a Mythex

Res a canviar pel teu costat. Les apps publicades en dominis personalitzats, els torns de l'agent i les previsualitzacions ja no depenen de com n'estigui de carregada la resta de Mythex. El trànsit de la teva app és assumpte teu: el límit descrit aquí és a la nostra API, no a les apps que publiques.

Si executes un backend propi, la mateixa trampa s'aplica a qualsevol límit de peticions que afegeixis. Les nostres guies sobre què és una API i la llista de comprovació de seguretat per a apps creades amb IA són un bon punt de partida. I per a un altre cas en què la nostra pròpia infraestructura es posava en el seu propi camí, vegeu com hem aconseguit desplegaments amb zero errors 502.