W skrócie: Kredyty AI niemal doprowadziły do awarii produkcyjnej bazy danych, ponieważ autonomiczny agent wpadł w rekurencyjne pętle, generował nieefektywne zapytania, wyczerpał pulę połączeń i skalował się bez skutecznych limitów. Artykuł dowodzi, że przecenione zasoby obliczeniowe mogą osłabiać dyscyplinę inżynierską, dlatego systemy łączące AI z bazą danych potrzebują izolowanych replik tylko do odczytu, limitów zapytań na bramie, deterministycznych kontroli zapytań, przeglądu przez człowieka, testów obciążeniowych, monitoringu i zabezpieczeń umożliwiających wycofanie zmian, zanim otrzymają dostęp do produkcji.
- Rekurencyjna pętla agenta zwiększyła liczbę połączeń z bazą danych ze 150 do 4 500 i zużywała około 200 € mocy obliczeniowej na godzinę.
- Pięćdziesiąt równoległych wątków agenta generowało duże skany bez indeksów, które poważnie obciążyły bazę danych i jej dziennik zapisu z wyprzedzeniem (write-ahead log).
- Pozorna dostępność darmowych kredytów sprawiła, że zespół pominął standardowe testy obciążeniowe i analizę odporności na stres.
- Agenci AI powinni korzystać z izolowanych, automatycznie skalowanych replik do odczytu, a nie z instancji zapisujących.
- Zalecane zabezpieczenia obejmują limity zapytań na sesję, przegląd przez człowieka po 50 zapytaniach w ciągu 60 sekund oraz deterministyczne kontrole przed wykonaniem wygenerowanych zapytań.
Najdroższą częścią automatyzacji AI nie zawsze jest rachunek za model. Jest nią to, co się dzieje, gdy szybki system zostaje dopuszczony do danych produkcyjnych bez granic, przeglądu i możliwości wycofania zmian.
Na kanale Slack zapada szczególny rodzaj ciszy, gdy produkcyjna baza danych osiąga 99% wykorzystania CPU i tak już zostaje. To nie jest cisza bezczynnego systemu; to cisza zespołu inżynierów, który uświadamia sobie, że „darmowe pieniądze”, które właśnie przyjął, w tej chwili rozbierają jego infrastrukturę. Większość osób nie zdaje sobie sprawy, że kredyty AI są często wysoko oprocentowaną pożyczką pod zastaw długu technicznego – taką, której spłaty ktoś zażąda o 3:00 w nocy we wtorek.
Właśnie otrzymaliśmy grant w wysokości 10 000 € w kredytach chmurowych na przyspieszenie prac nad wewnętrznymi narzędziami LLM. Wyglądało to na licencję na eksperymenty bez tarć związanych z zatwierdzaniem budżetu. Budowaliśmy autonomicznego agenta, który miał przeszukiwać naszą wewnętrzną dokumentację i mapować ją na metadane aktywnego schematu, aby pomóc młodszym programistom poruszać się po naszych systemach legacy. Miał zwiększać produktywność. Zamiast tego stał się atakiem typu distributed denial-of-service przeprowadzonym z wnętrza naszego własnego VPC.
Zapewne słyszeli Państwo, że największym ryzykiem związanym z AI są halucynacje lub prywatność danych. To powierzchowne obawy zarządów. Dla tych z nas, którzy wdrażają kod, prawdziwym zagrożeniem są nieograniczone pętle wykonania, które powstają, gdy niedeterministyczny model dostaje klucze do deterministycznego środowiska. Nie straciliśmy danych przez hakera; prawie straciliśmy je przez rekurencyjną pętlę, która co godzinę spalała 200 € „darmowej” mocy obliczeniowej, jednocześnie zamęczając naszą instancję Postgres.
Problem zaczął się od prostego przeoczenia w prompt engineeringu. Testowaliśmy nowy agentowy przepływ pracy, w którym model miał za zadanie „znaleźć wszystkie osierocone tabele i porównać ich znaczniki czasu ostatniej aktualizacji”. W tradycyjnym skrypcie pisze się skończoną pętlę. W frameworku agentowym to model decyduje, kiedy skończył. Ponieważ nasz schemat był złożony – w wyniku lat długu super aplikacji – AI utknęła w logicznej pętli. Wciąż znajdowała „możliwe” powiązania, uruchamiała nowe podzadania, aby je zweryfikować, a każde podzadanie otwierało nowe połączenie z bazą danych.
W ciągu czterdziestu minut agent wyczerpał pulę połączeń. Ponieważ nie ustawiliśmy ścisłych limitów dla „darmowej” usługi obliczeniowej AI, skalowała się ona horyzontalnie, aby zaspokoić „popyt” generowany przez własną rekurencyjną logikę. Na żywo obserwowaliśmy, jak liczba połączeń z bazą danych skoczyła ze 150 do 4 500, skutecznie odcinając każdego prawowitego użytkownika i usługę. Ironia była namacalna: korzystaliśmy z autopilotów AI, aby ulepszyć naszą strategię, a nie wdrożyliśmy podstawowych bezpieczników (circuit breakers), których każdy doświadczony inżynier wymagałby dla zwykłego zadania cron.
To ukryty koszt gorączki złota wokół AI. Gdy moc obliczeniowa jest postrzegana jako darmowa, dyscyplina inżynierska zwykle słabnie. Przestajemy traktować kod jako zobowiązanie i zaczynamy traktować go jako towar jednorazowego użytku. Zignorowaliśmy fakt, że nawet jeśli tokeny LLM są pokrywane z grantu, wpływ na IOPS i pamięć zarządzanej bazy danych jest jak najbardziej realnym kosztem, który trafia na główny rachunek za chmurę.
Złudzenie nieskończonej piaskownicy
Gdy otrzymuje się pięciocyfrową kwotę w kredytach, instynkt podpowiada, by zwiększyć współbieżność. Chce się zobaczyć, jak szybko nadejdzie „nowa era”. Skonfigurowaliśmy agenta tak, by działał w 50 równoległych wątkach, sądząc, że nasza instancja RDS poradzi sobie z obciążeniem. Nie uwzględniliśmy jednak niedeterministycznej natury zapytań generowanych przez AI. W przeciwieństwie do programisty, który pisze przewidywalny JOIN, AI generowała ogromne skany bez indeksów po tabelach zawierających miliony wierszy.
To nie był tylko spadek wydajności; to był niemal całkowity upadek dziennika zapisu z wyprzedzeniem (WAL). Baza danych spędzała tyle czasu na zarządzaniu blokadami i przełączaniu kontekstu między tysiącami przychodzących żądań AI, że przestała przetwarzać sygnały heartbeat z naszych serwerów aplikacyjnych. Dzieliły nas trzy minuty od przełączenia awaryjnego bazy danych, które prawdopodobnie skończyłoby się uszkodzeniem danych z powodu ogromnej liczby niezatwierdzonych transakcji w toku.
Dlaczego zdarza się to doświadczonym zespołom? Ponieważ prompt engineering to nowa inżynieria oprogramowania, a my nie wykształciliśmy jeszcze „nosa” do niebezpiecznych promptów, tak jak mamy go do złego SQL. Traktujemy prompt jak sugestię, ale dla autonomicznego agenta jest to polecenie zużycia wszystkich dostępnych zasobów aż do osiągnięcia celu. Jeśli cel jest źle zdefiniowany, zużycie jest nieskończone.
Drugie dno: kredyty odwróciły naszą uwagę
Oto, co zrozumieliśmy zbyt późno: 10 000 € w kredytach zadziałało jak psychologiczny skrót omijający nasze standardowe procedury testów obciążeniowych i analizy odporności na stres. Gdybyśmy od pierwszego dnia płacili za te tokeny z budżetu operacyjnego, zaczęlibyśmy od jednego wątku. Monitorowalibyśmy opóźnienia. Zbudowalibyśmy warstwę proxy, która oczyszczałaby zapytania AI, zanim trafią na produkcję. „Darmowy” charakter zasobu zachęcił nas do pominięcia inżynierii, w której najpierw się myśli – a to właśnie ona definiuje filozofię naszej firmy.
Byliśmy tak skupieni na „przełomie”, że zignorowaliśmy „awarię”. To powszechny wzorzec na obecnym rynku. Firmy pędzą, by rozwiązać kryzys długu wiedzy, rzucając AI na swoje silosy danych, tylko po to, by odkryć, że ich infrastruktura nie jest gotowa na ogromną „gadatliwość” aplikacji opartych na LLM. Agent AI nie tylko czyta dane; przesłuchuje je, często w najmniej efektywny możliwy sposób.
Wdrożenie bezpieczników
Aby ocalić bazę danych, musieliśmy zamknąć całą przestrzeń nazw Kubernetes, w której działały workery AI. Było to toporne narzędzie, ale zadziałało. Gdy dym opadł, wprowadziliśmy trzy niepodlegające negocjacjom zasady dla każdej interakcji AI z bazą danych, które dziś stosujemy u wszystkich naszych klientów:
- Obowiązek repliki tylko do odczytu: żaden agent AI, bez względu na to, jak „bezpieczny”, nie może łączyć się z instancją zapisującą. Agenci działają na izolowanych, automatycznie skalowanych replikach do odczytu, gdzie skok CPU do 100% nie zatrzyma procesu checkoutu.
- Limitowanie oparte na tokenach na poziomie bramy: zbudowaliśmy middleware, który zlicza wywołania bazy danych w ramach każdej „sesji agenta”. Jeśli agent przekroczy 50 zapytań w oknie 60 sekund, sesja zostaje zakończona i oznaczona do przeglądu przez człowieka.
- Wzorzec „Explain Before Execute”: zanim jakiekolwiek zapytanie wygenerowane przez AI zostanie uruchomione, musi przejść przez deterministyczny parser, który sprawdza brakujące klauzule WHERE lub złączenia bez indeksów. Jeśli zapytanie wygląda na pełny skan tabeli, zostaje odrzucone, zanim w ogóle trafi do sieci.
W jakim stopniu Państwa obecna „strategia AI” opiera się na założeniu, że infrastruktura poradzi sobie z nieprzewidywalnym zachowaniem modelu? Jeśli nie buduje się takich zabezpieczeń, nie jest to innowacja; to tylko czekanie, aż kredyty puszczą dom z dymem.
Nadal korzystamy z kredytów, ale traktujemy je jak prąd wysokiego napięcia. Mają ogromną moc, ale wymagają solidnej izolacji. Wróciliśmy do inżynierii, w której najpierw się myśli, dbając o to, by każdą integrację AI poprzedzała ścisła mapa alokacji zasobów. Celem nie jest po prostu wdrożenie AI; celem jest wdrożenie AI, które nie wymaga przywracania z kopii zapasowej w środowy poranek.
Ostatecznie grant w wysokości 10 000 € okazał się tanią lekcją. Kosztował nas kilka godzin przestoju i sporo dumy, ale uchronił przed znacznie większą katastrofą w przyszłości. AI to mnożnik, ale mnoży wszystko – łącznie z wadami architektury i brakiem dyscypliny. Jeśli zamierzają Państwo dać AI klucze do swojej bazy danych, najpierw trzeba zbudować klatkę wokół silnika.
Kolejny krok
Ten tekst może posłużyć jako checklista bezpieczeństwa automatyzacji AI. Porozmawiajmy z DataTip.