Unser Slack-Bot hat drei Monate lang problemlos 200 Nachrichten pro Tag verarbeitet. Dann sprach ein Technologie-Blogger in einem Newsletter darüber, und wir sprangen innerhalb von 48 Stunden von 200 auf 12.000 Nachrichten.
Alles hörte auf zu funktionieren. Nicht auf spektakuläre Weise — der Server ist nicht in Brand geraten oder so. Er hat einfach… langsamer geworden. Und weiterhin langsamer. Dann begann er, Nachrichten zu verlieren. Und schließlich wurde es völlig still, während 12.000 Menschen sich fragten, warum der KI-Bot, von dem sie gerade erfahren hatten, nicht antwortete.
Hier ist, was passiert ist, was wir getan haben und wie wir innerhalb einer Woche von „Spaß-Nebenprojekt“ zu „Ding, von dem die Leute tatsächlich abhängig sind“ gewechselt sind.
Die ersten 6 Stunden: Leugnen und Panik
Der Newsletter kam am Dienstag um 9 Uhr in die Postfächer. Um 10 Uhr hatte unsere Nachrichtenwarteschlange einen Rückstand von 400 Nachrichten. Mittags betrug der Rückstand 2.000 und die Antwortzeit 45 Sekunden (normalerweise weniger als 3 Sekunden).
Meine erste Reaktion: „Hmm, das sind viele Nachrichten.“ Meine zweite Reaktion, 20 Minuten später: „Oh nein.“
Der Flaschenhals lag nicht bei der CPU oder dem Speicher — es war die API des KI-Modells. Jede Nachricht erforderte einen API-Aufruf, und wir erreichten schnell die Ratenlimits. Unser kostenloser API-Plan erlaubte 60 Anfragen pro Minute. Wir benötigten mehr als 200 pro Minute.
Schnelle Lösung: Upgrade des API-Plans. Wir haben unser Limit innerhalb von 30 Minuten auf 500 Anfragen pro Minute hochgesetzt, indem wir auf einen kostenpflichtigen Plan umgestiegen sind. Die Warteschlange begann sich zu leeren. Krise teilweise abgewendet.
Aber dann kam die zweite Welle.
Stunden 6-24: Alles andere fällt aus
Die API-Durchsatzsteigerung offenbarte alle anderen Flaschenhälse, die wir bei niedrigem Volumen nicht bemerkt hatten.
Datenbankverbindungen überlastet. Jede Nachricht löste eine Abfrage in der Datenbank für den Benutzerkontext aus. Bei 200 Nachrichten pro Tag kein Problem. Bei 12.000 war unser Verbindungs-Pool erschöpft. Die Benutzer erhielten Fehler „Dienst nicht verfügbar“.
Behebung: Erhöhung der Größe des Verbindungs-Pools, Hinzufügen der Verbindungsoptimierung mit PgBouncer und Implementierung von Lese-Replikaten für Kontextabfragen.
Speicherleck im Nachrichtenmanager. Eine Variable, die den Kontext des Gesprächs speicherte, wuchs ohne Bereinigung. Bei niedrigem Volumen wuchs sie langsam und wurde durch gelegentliches Neustarten gereinigt. Bei hohem Volumen verbrauchte sie den gesamten verfügbaren Speicher in etwa 4 Stunden.
Behebung: Hinzufügen einer angemessenen Bereinigung nach der Verarbeitung jeder Nachricht. Dieser Fehler war seit dem ersten Tag vorhanden — bis jetzt hatte er keine Bedeutung.
Einzel-Thread-Verarbeitung. Die Nachrichten wurden nacheinander verarbeitet. Eine nach der anderen. Bei 200 Nachrichten pro Tag war das in Ordnung. Bei 12.000 bedeutete das, dass jede Nachricht hinter jeder anderen warten musste.
Behebung: Implementierung einer parallelen Verarbeitung mit einer geeigneten Aufgabenwarteschlange. Die Nachrichten werden auf mehrere Arbeiter verteilt. Dadurch hat sich die durchschnittliche Antwortzeit von 45 Sekunden auf weniger als 5 verringert.
Der Moment „Oh, wir brauchen eine echte Infrastruktur“
Nach 24 Stunden wurde mir klar, dass unsere Architektur „das funktioniert auf einem VPS für 10 $/Monat“ nicht mit einem anhaltenden Wachstum umgehen könnte. Wir benötigten:
Einen echten Lastenausgleich. Nicht weil wir mehrere Server benötigten, sondern weil wir Statusprüfungen, automatische Neustarts und die Möglichkeit, Updates ohne Ausfallzeiten zu deployen, brauchten.
Eine Nachrichtenwarteschlange. Eine von Redis unterstützte Aufgabenwarteschlange, die den Empfang der Nachrichten vom Verarbeiten der Nachrichten entkoppelt. Wenn das KI-Modell langsam ist, warten die Nachrichten in der Warteschlange, anstatt in den Wartezeiten zu sterben. Wenn ein Arbeiter abstürzt, wird die Nachricht erneut versucht, anstatt verloren zu gehen.
Überwachung mit echten Alarmen. Wir hatten Protokolle. Wir hatten keinen Alarm. Der Unterschied ist bedeutend, wenn die Dinge um 2 Uhr morgens ausfallen und niemand die Protokolle überwacht.
Horizontale Skalierbarkeit. Die Fähigkeit, mehr Arbeiter hinzuzufügen, wenn die Last steigt. Unsere Architektur passt sich automatisch an: Wenn die Tiefe der Warteschlange einen bestimmten Schwellenwert überschreitet, werden automatisch neue Arbeiter bereitgestellt.
Was wir in einer Woche erreicht haben
Tag 1-2: Notfall-Upgrade des Ratenlimits, Behebung des Verbindungs-Pools, Behebung des Speicherlecks.
Tag 3-4: Implementierung der Nachrichtenwarteschlange, parallele Verarbeitung.
Tag 5-6: Lastenausgleich, Überwachung mit Alarmen, horizontale Skalierbarkeit.
Tag 7: Endlich geschlafen.
Die Gesamtkosten der Infrastruktur stiegen von 10 $/Monat auf etwa 120 $/Monat. Aber wir sind von 200 Nachrichten pro Tag dazu übergegangen, bequem 50.000 zu verarbeiten. Und die Architektur kann immer noch einfach durch das Hinzufügen von Arbeitern skalieren.
Die Checkliste zur Skalierbarkeit, die ich gerne gehabt hätte
Wenn Ihr KI-Bot wächst und Sie bereit sein wollen, bevor der Anstieg kommt:
Einrichten der Überwachung mit Alarmen jetzt. Antwortzeit, Fehlerquote, Tiefe der Warteschlange, Speicherverbrauch. Alarmgrenzen bei 2x den Normalwerten. Sie wollen über Probleme informiert werden, bevor die Benutzer sie Ihnen melden.
Implementierung einer Nachrichtenwarteschlange. Selbst bei niedrigem Volumen. Dies entkoppelt den Empfang von der Verarbeitung, ermöglicht Wiederholungen und macht die horizontale Skalierbarkeit später trivial.
Analysieren Sie Ihre Ressourcennutzung pro Nachricht. Wie viele Datenbankanforderungen pro Nachricht? Wie viel Speicher? Wie viele API-Aufrufe? Multiplizieren Sie diese Zahlen mit Ihrem Wachstumsziel und sehen Sie, wo die Flaschenhälse sind.
Testen Sie mit dem 10-fachen Ihrer aktuellen Last. Verwenden Sie ein Lasttest-Tool, um ein Nachrichtenvolumen, das um das 10-fache erhöht wurde, eine Stunde lang zu simulieren. Sehen Sie, was ausfällt. Beheben Sie es, bevor es in der Produktion ausfällt.
Haben Sie einen dokumentierten Lastenausgleichsplan. „Wenn der Verkehr sich verdoppelt, tun Sie diese drei Dinge.“ Einen Plan auf Papier zu haben bedeutet, dass Sie ihn um 2 Uhr morgens ausführen können, wenn Sie halb eingeschlafen sind, anstatt zu versuchen, Lösungen unter Druck zu entwickeln.
Was ich über KI in großem Maßstab gelernt habe
Das KI-Modell ist in der Regel nicht der Flaschenhals — alles, was es umgibt, ist es. Datenbankanfragen, Kontextmanagement, Ausgabeformatierung, Nachrichtenweiterleitung — die ganze „langweilige“ Infrastruktur, die Sie beim Bauen eines Prototyps auslassen. In großem Maßstab sind die langweiligen Elemente wichtiger als die KI-Elemente.
Außerdem: Die Ratenlimits sind die am meisten unterschätzte Skalierbarkeitseinschränkung in KI-Anwendungen. Ihre brillante Architektur ist unwichtig, wenn die API des Modells nur 60 Anfragen pro Minute zulässt. Überprüfen Sie Ihre Grenzen, bevor Sie starten, und haben Sie einen Plan, wenn Sie sie überschreiten.
Der virale Gipfel war stressig, aber letztendlich positiv. Es hat uns gezwungen, die Infrastruktur aufzubauen, die wir von Anfang an hätten aufbauen sollen. Und jetzt sind wir bereit für den nächsten Anstieg — wann immer er kommt.
🕒 Published: