Svaki sistem koji smo ikad videli da se urušava izgledao je savršeno — dok nije prestao. Ne zbog greške u kodu, ne zbog hardverskog kvara. Urušio se zato što je napravljen za okruženje koje više nije postojalo.

Ovo nije teorija. To je obrazac koji se ponavlja dovoljno često da ima ime: tehnički dug skalabilnosti. I za razliku od većine tehničkih dugova, ovaj se ne vraća polako — vraća se odjednom, u trenutku kad ga najmanje možete priuštiti.

Kako izgleda sistem koji nije planiran za rast

Dijagram monolitne arhitekture koja ne podnosi rast saobraćaja — Monolitna arhitektura bez jasnih granica između modula najčešće je polazna tačka problema.

Zamislite aplikaciju koja je napravljena za interno korišćenje — pedesetak zaposlenih, predvidiv saobraćaj, poznate operacije. Radi brzo, tim je zadovoljan, klijent je srećan. Šest meseci kasnije firma lansira javni proizvod koji se oslanja na isti backend. Broj korisnika raste sa 50 na 5.000 za tri nedelje.

Šta se dešava:

Baza podataka počinje da "juri" zahteve umesto da im odgovara.
Delovi sistema koji nikad nisu morali da budu brzi sada postaju usko grlo.
Tim počinje da gasi požare umesto da isporučuje funkcionalnosti.
Svaka nova zakrpa otvara novi problem negde drugde.

Sistem nije pao jer je loše napisan. Pao je jer je pisan za drugačiji kontekst nego što je na kraju bio zahtevano od njega.

Tri mesta gde skalabilnost najčešće puca

Vizualizacija uskog grla u sistemu — jedan servis koji blokira sve ostale — Jedno usko grlo može da neutrališe ceo sistem, bez obzira na to koliko su drugi delovi optimizovani.

1. Baza podataka projektovana za mali obim

Najčešće usko grlo nije server — nego baza. Tabele bez odgovarajućih indeksa, upiti koji rade N+1 operacije, relacije koje imaju smisla na malom skupu podataka ali postaju noćna mora na milion redova. Ovo se ne vidi u razvoju jer razvojne baze imaju 200 redova. Vidi se tek u produkciji.

2. Sinhrone operacije tamo gde bi trebalo da budu asinhrone

Sistem koji čeka na svaki odgovor pre nego što nastavi — slanje mejla, obrada fajla, poziv ka eksternom API-ju — funkcioniše sasvim fer kad je opterećenje malo. Kad saobraćaj poraste, svako čekanje se multiplicira. Ono što je trajalo 200ms sad traje 4 sekunde, jer su u redu 20 zahteva ispred.

3. Monolitna arhitektura bez jasnih granica

Monolit sam po sebi nije problem. Problem nastaje kad su svi delovi sistema čvrsto zavisni jedan od drugog — kad promena u modulu za korisnike utiče na modul za plaćanja, koji utiče na modul za notifikacije. Takav sistem ne može da se skalira horizontalno jer se ne može razdvojiti. Ne možete dodati više servera za deo sistema koji je pod opterećenjem — morate skalirati sve ili ništa.

Šta ovo košta u praksi

Grafikon koji pokazuje eksponencijalni rast troškova refaktorisanja sistema bez planirane skalabilnosti — Troškovi refaktorisanja rastu eksponencijalno — ne linearno — kako sistem starí i postaje kompleksniji.

Postoje dve vrste troškova koje firme obično ne računaju unapred.

Direktni troškovi: Refaktorisanje arhitekture koja nije planirana za skalabilnost košta višestruko više od toga da je ta arhitektura bila planirana od početka. Procena "prepisaćemo to kad zatreba" ne uzima u obzir da ćete tada prepisivati sistem koji je u produkciji, pod saobraćajem, uz koji postoji tim koji ne sme da stane.

Indirektni troškovi: Svaki sat nestabilnosti u produkciji je sat u kom vaši korisnici donose zaključke o vašem proizvodu. Te zaključke je teško promeniti. Reputacioni trošak degradiranog iskustva u trenutku rasta može biti veći od tehničkih troškova popravke.

Šta planiranje skalabilnosti zapravo znači

Nije u pitanju predviđanje budućnosti. Nije u pitanju ni "over-engineering" sistema koji još uvek nema korisnike. U pitanju je postavljanje pravih pitanja u pravo vreme:

Koji delovi sistema će biti pod najvećim opterećenjem kad korisnici porastu?
Koje operacije moraju biti sinhrone, a koje mogu biti asinhrone?
Gde su granice između modula sistema i jesu li one jasne?
Kako izgleda baza podataka kad ima 100 puta više redova?

Odgovori na ova pitanja pre nego što počne razvoj koštaju razgovor i par sati analize. Odgovori na ista pitanja godinu dana nakon lansiranja koštaju mesece rada i usporenu isporuku svega ostalog.

Nije u pitanju veličina tima — nego struktura odluka

Arhitekturalni dijagram sistema planiranog za horizontalno skaliranje — Dobar arhitekturalni plan ne mora biti komplikovan — mora biti svestan konteksta u kom će sistem rasti.

Jedan od najčešćih argumenata koje čujemo je: "Mi smo mali tim, ne možemo si priuštiti da razmišljamo o skalabilnosti." Paradoks je upravo suprotan — mali tim si može najmanje priuštiti da ne razmišlja o tome, jer nema kapaciteta da naknadno rešava probleme koji su mogli biti predupređeni.

Planiranje skalabilnosti nije skupo. Ignorisanje skalabilnosti jeste.

Zaključak

Sistemi koji se urušavaju pod opterećenjem retko su loše napisani. Najčešće su savršeno napisani za kontekst koji je promenjen. Razlika između sistema koji podnosi rast i sistema koji se bori sa njim ne leži u broju developera ni u veličini budžeta — leži u pitanjima koja su postavljena pre nego što je napisan prvi red koda.

U SCAONS-u svaki projekat počinje analizom konteksta i jasnom arhitekturalnom odlukom. Ne zato što smo oprezni — nego zato što smo videli šta se desi kad se taj korak preskoči.

What happens when you do not plan for scalability from the start