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: poruchy, ktoré autoscaling nevyrieši.
Je to jeden z najmätúcejších incidentov, aké môže e-commerce tím zažiť. Kampaň sa spustí, pokladňa začne narážať na časové limity a dashboardy ukazujú, že je všetko v poriadku: CPU na 10 %, pamäť v poriadku, dostatok rezerv. 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 ich koncentruje do tých istých niekoľkých najčastejšie zapisovaných riadkov: počítadiel poradia objednávok, tabuliek objednávok a košíkov, rezervovanej zásoby. Každá transakcia drží svoje zámky, kým čaká na inú prácu. Priepustnosť sa zrúti, hoci vyťaženie CPU zostáva nízke. Na Magente sa to v logoch prejaví ako chyby lock-wait timeout a deadlock z MySQL.
Cache stampede. Často žiadaný záznam v cache (stránka kategórie, na ktorú mieri každá reklama) vyprší pri špičkovej prevádzke. Každá požiadavka, ktorá ho už nenájde, teraz stránku regeneruje súčasne s ostatnými a zaťažuje databázu identickými drahými dopytmi. Databáza dostane jednu kópiu tej práce za každú súbežnú požiadavku.
Synchrónne volania tretích strán priamo v pokladni. 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í. Pokladňa je potom nedostupná tak dlho, kým je ten poskytovateľ pomalý.
Vyčerpanie workerov a spojení. Tri vyššie uvedené problémy spája jeden 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, nech na tej stránke zostáva akokoľvek málo práce.
Ani jeden z tých štyroch problémov nie je hardvérový problém, a práve preto ho autoscaling nevyrieši: 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á kapacita čaká paralelne, namiesto toho, aby pridala priepustnosť.
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ý tracing na to odpovedá priamo; slow-query log a čí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 rutinná: 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úť v reálnom čase), ochrana proti stampede, aby často žiadaný kľúč obnovoval jeden proces, kým ostatné poskytujú 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 na ňu odpovie z vašich vlastných záznamov tracingu a naša práca na DevOps sa stará o to, aby opravy zostali funkčné.
Väčšina týchto incidentov sa ukáže ako problém súbežnosti, takže skôr než objednáte ďalšie servery, začnite tracingom.