Jak jsme snížili náklady na provoz o 75 % bez zásahu do jádra systému

V online byznysu, kde se v reálném čase pracuje s velkým objemem obsahu a vysokou návštěvností, se každé rozhodnutí v infrastruktuře rychle projeví v nákladech. Přesně to jsme zjistili u jednoho klientského projektu, když se infrastruktura začala chovat jinak, než jsme čekali.

_____________________________________________________________________________________________________

Pracovali jsme na projektu, jehož hlavní stránka obsahovala rozumné množství obrázků. Nešlo o žádnou mediální galerii, ale o běžný web s vizuálním obsahem, který je dnes standardem.

Primárně jsme ale vyvíjeli sofistikovaný systém pro online aukce, s rozsáhlou backend logikou, důrazem na přesnost, stabilitu a robustní API. Šlo o typický komplexní portál s velkým množstvím doménové logiky, kde obrázky představovaly spíše doplněk celého řešení než jeho hlavní část.

Klíčovým požadavkem klienta ale bylo, že veškeré obrázky a dokumenty musí zůstat výhradně v privátní síti. Žádné externí služby ani veřejná úložiště. Veškerý přístup musel vždy vést přes zabezpečenou gateway. Projekt jsme úspěšně spustili. Po několika měsících provozu se ale ukázalo, že náklady nainfrastrukturu jsou výrazně vyšší, než jsme původně očekávali.


Malá odbočka z produkčního pekla:)

Už pár hodin po veřejném releasu jsme zaznamenali, že web, přestože prošel zátěžovými testy, začal výrazně zpomalovat a chovat se nestabilně. Analýza provozu ukázala řádově desítky tisíc requestů za vteřinu.

Šlo o přepis starého systému, takže na nový web automaticky dorazili boti, kteří byli zvyklí na původní řešení. Tahle kapitola by si zasloužila vlastníčlánek, tady ale zůstaneme u toho podstatného.

Po sérii optimalizací se nám podařilo provoz snížit na úroveň, která už server nezahlcovala, ale stále jsme se pohybovali ve vyšších stovkách requestů zavteřinu.

Projekt byl kombinací složitého inženýrského systému a klasické webové aplikacese silným SEO důrazem, kde jsme řešili i server-side rendering pro správnoui ndexaci obsahu. Právě tato kombinace komplexní logiky a „běžné webařiny“ sepozději ukázala jako důležitá.


Kde mizel rozpočet

Detailní pohled na faktury za infrastrukturu ukázal, že významnou část nákladů tvoří položka „odeslaná data“. Rychle se ukázalo, že hlavním viníkem jsou obrázky na hlavní stránce.

Přestože hlavní inženýrská výzva projektu ležela v aplikační logice, vysoký provoz a aktivita botů velmi rychle ukázaly, že skutečným bottleneckem může býti zdánlivě sekundární část systému, tedy statický obsah.

Cache byla nastavená správně, ale při kombinaci vysokého provozu a botů to jednoduše nestačilo. Zároveň jsme měli jasná omezení, která nebylo možné obejít:

·      obrázky nesměly opustit privátní síť

·      gateway musela zůstat jediným vstupním bodem dosystému

Jakékoliv řešení tedy muselo respektovat stávající bezpečnostní model.


Jednoduché řešení s velkým dopadem

Nakonec jsme našli řešení, které splnilo všechna bezpečnostní omezení a zároveň dramaticky snížilo náklady. Nasadili jsme CDN.

CDN jsme umístili přímo před gateway a nakonfigurovali ji tak, aby cachovala výhradně statický obsah, tedy obrázky a dokumenty. Opakované requesty, včetnětěch od botů, se tak obsloužily přímo z cache ještě předtím, než se dostaly k drahé části infrastruktury.

Gateway zůstala jediným vstupním bodem do systému a bezpečnostní model se nijak nezměnil. Změnila se pouze architektura doručování statického obsahu.


Výsledek

·      pokles nákladů na odeslaná data o 75 %

·      minimální zásah do existující architektury

·      rychlejší doručování obsahu koncovým uživatelům

Implementace byla překvapivě jednoduchá a nevyžadovala žádné zásadní změny v systému.


Závěr

Tenhle projekt nám znovu připomněl, že i relativně malá změna v infrastruktuře může výrazně ovlivnit provozní náklady. A to bez nutnosti sahat do jádra systému nebo narušovat existující bezpečnostní pravidla.

Při návrhu komplexních systémů je snadné soustředit se primárně na doménovou logiku a backendovou architekturu. Stejně důležité je ale nezapomínat na osvědčené nástroje vysoce vytížených webových aplikací a nebát se optimalizovat řešení i o prvky jako CDN nebo edge caching.

V některých případech stačí přehodnotit, kde a jak se obsluhuje statický obsah, a nechat infrastrukturu pracovat efektivněji místo toho, aby pracovala víc.

‍