Wir haben unsere eigenen Dienste gedrosselt

Die Mythex-API erlaubt 300 Anfragen pro Minute von einer Netzwerkadresse. Dieses Limit schützt uns davor, dass eine einzelne Person oder ein Skript die API überflutet. In der Produktion begann es stattdessen, unsere eigenen Dienste abzuweisen: den Teil unseres Edge, der veröffentlichte Apps ausliefert, und den Dienst, der den KI-Agenten betreibt. Denn jeder von ihnen erreicht die API nur von einer Handvoll Adressen. Anfragen mit unserem internen Zugangsschlüssel sind jetzt ausgenommen, alle anderen werden genau wie zuvor begrenzt.

Das Symptom

Die API begann, einige unserer internen Aufrufe mit 429 Too Many Requests zu beantworten. Drei Arten von Aufrufen waren betroffen, und jede davon ist für jemanden, der Mythex nutzt, wichtig:

• Nachschlagen, welche App auf einer eigenen Domain liegt. Wenn ein Besucher eine veröffentlichte App auf ihrer eigenen Domain öffnet, fragt unser Edge bei der API nach, wo diese Website liegt. Ein 429 bedeutet dort einen Besucher, der eine Website nicht erreicht.
• Speichern eines laufenden Agenten-Durchlaufs. Während der Agent arbeitet, wird sein Fortschritt laufend gespeichert, damit eine Antwort einen Neuladevorgang oder eine abgebrochene Verbindung übersteht. Ein 429 bedeutet dort Fortschritt, der nicht gespeichert wurde.
• Prüfen des Zugriffs auf eine Vorschau. Die Vorschau einer App, die Sie gerade bauen, ist geschützt, und die Schranke fragt bei der API nach. Ein 429 bedeutet dort eine Vorschau, die sich nicht öffnet.

Keiner dieser Aufrufe kam von Personen. Alle kamen von uns.

Warum es passierte

Ein Limit pro Adresse macht eine Annahme: Eine Adresse ist ungefähr ein Aufrufer. Für Menschen stimmt das annähernd. Für unsere eigene Infrastruktur ist es grundlegend falsch.

• Der Edge-Dienst, der veröffentlichte Apps und Vorschauen ausliefert, erreicht die API von wenigen gemeinsam genutzten ausgehenden Adressen. Jeder Besucher jeder veröffentlichten App und jede Vorschauprüfung kommt so an, als stamme sie von einer dieser wenigen Adressen.
• Der Orchestrator, also der Dienst, der Agenten-Durchläufe ausführt, erreicht die API von einer Container-Adresse. Jeder laufende Durchlauf, für jeden Nutzer, teilt sich diese.

Das Budget, das für eine Person gedacht war, wurde also auf den gesamten Verkehr eines ganzen Dienstes verteilt. Diese Dienste haben es zusammen aufgebraucht, und das Limit tat, was es sollte: Es wies sie ab.

Die Korrektur

Unsere eigenen Dienste weisen sich bereits aus. Jeder interne Aufruf trägt ein internes Token, und jede Route im internen Bereich der API prüft dieses Token, bevor sie etwas tut.

Der Rate-Limiter nutzt jetzt dieselbe Prüfung. Eine Anfrage, deren Token mit dem internen übereinstimmt, steht auf einer Erlaubnisliste und wird nicht auf das Budget pro Adresse angerechnet. Alles andere wird genau wie bisher gezählt: 300 Anfragen pro Minute und Adresse.

Zwei Details verhinderten, dass daraus ein Schlupfloch wurde:

1. Ein falsches Token bekommt keine Ausnahme. Die Erlaubnisliste passt nur auf das echte interne Token. Eine Anfrage mit einem erfundenen Token wird wie jede andere gezählt und gedrosselt, und die internen Routen weisen sie weiterhin mit 401 Unauthorized ab.
2. Das Limit selbst hat sich nicht geändert. Wir haben die Zahl nicht erhöht, um Platz zu schaffen. Eine Erhöhung hätte das Problem nur so lange verdeckt, bis der Verkehr wieder wächst, und sie hätte den Schutz für den Fall geschwächt, für den das Limit gedacht ist.

Wir haben die Einstellungen des Limiters in eine kleine Funktion verlegt und Tests dafür geschrieben. Einer schickt 20 Anfragen mit dem internen Token an einen Limiter, der 5 erlauben soll, und erwartet, dass alle 20 gelingen. Ein anderer schickt gewöhnliche Anfragen von einer Adresse und erwartet, dass die ersten fünf gelingen und die danach abgewiesen werden. Ein dritter schickt Anfragen mit einem gefälschten Token und erwartet, dass sie auf die gleiche Weise abgewiesen werden.

Was wir daraus mitnehmen

• Limits tragen Annahmen in sich. „Eine Adresse, ein Aufrufer“ steckt in einem Limit pro Adresse. Die Annahme stimmt nicht mehr, sobald Ihre eigenen Dienste hinter gemeinsamen Adressen sitzen, und das tun viele: Load Balancer, Edge-Netzwerke, Container, Firmennetze.
• Unterscheiden Sie Ihren eigenen Verkehr anhand der Identität, nicht der Adresse. Adressen sagen, wie Verkehr ankommt, nicht, wer ihn geschickt hat. Wir hatten bereits einen Nachweis, dass ein Aufruf von uns stammt. Der Limiter hat ihn nur nicht angesehen.
• Beheben Sie es nicht, indem Sie die Zahl erhöhen. Ein größeres Limit hätte die 429er eine Zeit lang verschwinden lassen, weniger geschützt und wäre später wieder gescheitert.
• Sehen Sie nach, wer gedrosselt wird. Ein 429, das bei Ihrem eigenen Dienst landet, ist eine Fehlermeldung über Ihre Limits, kein Zeichen, dass der Limiter funktioniert.

Was das für Sie bedeutet, wenn Sie auf Mythex bauen

Auf Ihrer Seite müssen Sie nichts ändern. Veröffentlichte Apps auf eigenen Domains, Agenten-Durchläufe und Vorschauen hängen nicht mehr davon ab, wie ausgelastet der Rest von Mythex ist. Der eigene Verkehr Ihrer App ist Sache Ihrer App: Das beschriebene Limit gilt für unsere API, nicht für die Apps, die Sie veröffentlichen.

Betreiben Sie ein eigenes Backend, gilt dieselbe Falle für jedes Ratenlimit, das Sie hinzufügen. Unsere Leitfäden zu was eine API ist und zur Sicherheits-Checkliste für mit KI gebaute Apps sind ein guter Anfang. Und für einen weiteren Fall, in dem unsere eigene Infrastruktur sich selbst im Weg stand, lesen Sie wie wir Deployments auf null 502-Fehler gebracht haben.