4. júna 2026, Luboš Zápotočný
Prečo pokladňa zlyháva pri 10 % záťaži serverov
Nevyťažené servery, nedostupná pokladňa. Súperenie o zámky, cache stampede a synchrónne platobné volania, pred ktorými vás autoscaling nezachráni.
Je to najmätúcejší incident, aký môže e-commerce tím zažiť. Kampaň sa spustí, pokladňa začne zlyhávať na timeouty a dashboardy trvajú na tom, že je všetko v poriadku: CPU na 10 %, pamäť v poriadku, rezervy dosť. Inštinkt velí pridať servery. Servery prídu, sú rovnako nevyťažené ako tie ostatné a pokladňa je naďalej nedostupná.
Zmätok pramení zo zlého mentálneho modelu. Záťaž má dve zložky: prácu a čakanie. Vaše servery stoja v rade, a rady na grafe CPU nevidno.
Časté príčiny
Súperenie o databázové zámky. Pokladňa je miesto, kde e-shop prestáva čítať a začína zapisovať: rezervovať zásobu, vytvoriť objednávku, uložiť adresu. Tieto zápisy sa serializujú na zámkoch riadkov a kampaňová prevádzka sa pritom koncentruje na tých istých pár riadkoch. Sto zákazníkov, ktorí prechádzajú pokladňou počas tej istej kampane, sa serializuje na tých istých horúcich riadkoch: čítačoch poradia objednávok, tabuľkách objednávok a košíkov, rezervovanej zásobe. Každá transakcia drží svoje zámky, kým čaká na inú prácu. Priepustnosť klesá, hoci CPU zostáva takmer nevyťažené. Na Magente to má typický prejav: hlásenia o čakaní na zámky a deadlockoch, ktoré ráno po výpredaji plnia logy.
Cache stampede. Horúci záznam v cache (stránka kategórie, na ktorú mieri každá reklama) expiruje pod špičkovou prevádzkou. Každá požiadavka, ktorá ho netrafí, teraz stránku regeneruje súčasne a bombarduje databázu identickými drahými dopytmi. Cache, ktorá e-shop zrýchlila, teraz spôsobí jeho výpadok, a kedy sa to stane, určuje jej TTL.
Synchrónne volania tretích strán v ceste pokladne. Sadzby dopravy, autorizácia platby, výpočet dane, antifraud kontrola: každé z nich je sieťové volanie do cudzieho systému, vykonané, kým váš worker drží spojenie a často aj databázovú transakciu. Keď sa jeden poskytovateľ pod tou istou kampaňovou záťažou spomalí z 200 ms na 10 sekúnd, každý worker postupne skončí zablokovaný v tom volaní. Či a kedy budete mať výpadok, potom závisí od aktuálneho stavu vášho dodávateľa.
Vyčerpanie workerov a spojení. Tri problémy vyššie zdieľajú spoločný zosilňovač: workery, ktoré čakajú, stále obsadzujú svoj slot aj svoje databázové spojenie. PHP-FPM procesy dimenzované na bežnú prevádzku sa naplnia zablokovanými požiadavkami, nové požiadavky nedostanú worker ani spojenie vôbec a zrazu je nedostupné všetko, čo ešte potrebuje PHP worker, akokoľvek málo tá stránka robí.
Ani jeden z tých štyroch problémov nie je problém hardvéru, a práve preto vás autoscaling nezachráni: nové inštancie sa zaradia do toho istého radu na ten istý zámok riadku za tým istým pomalým dodávateľom. Pridané inštancie len paralelizujú čakanie.
Ako to zbadať vopred
Diagnostický posun je od vyťaženia k času. Kam idú milisekundy požiadavky v pokladni: na prácu, alebo na čakanie na zámky, cache a cudzie API? Distribuované trace na to odpovedajú priamo; slow-query log plus čítače lock-wait v databáze na to odpovedajú lacno. Ak pred ďalšou kampaňou pridáte len jeden graf, nech sú to čakania na zámky.
Opravy vyplývajú z diagnózy a väčšina z nich je neefektná: timeouty na každom volaní tretej strany a cachované fallbacky tam, kde zastaraná odpoveď neuškodí (mierne zastaraná sadzba dopravy nevadí, autorizácia platby ale musí prebehnúť naživo), ochrana proti stampede, aby horúci kľúč prestavoval jeden proces, kým ostatné servírujú staršiu verziu, presun nepodstatných zápisov mimo transakcie do fronty a rezervovanie zásoby tak neskoro vo funneli, ako to biznis dovolí, namiesto jej držania už od košíka. Ktorá z nich je dôležitá pre váš e-shop, je empirická otázka; audit výkonu ju zodpovie z vašich traceov, nie z cudzích skúseností, a naša DevOps práca sa potom stará, aby oprava vydržala.
Kampaňové zlyhania bývajú väčšinou zlyhaniami súbežnosti. Skôr než objednáte ďalšie servery, pozrite sa do traceov, kam sa vám stráca čas.