Kako skalirati SaaS po zagonu, ne da bi pokvarili izdelek

Vsi praznujejo zagon. Skoraj nihče vas ne opozori na del, ki pride za tem — na tisto čudno, napeto leto, ko izdelek, ki vam je prinesel prvih sto strank, začne popuščati pod težo naslednjih tisoč. Nič dramatičnega se ne zgodi. Stvari preprosto postanejo počasnejše, bolj nestabilne, težje spremenljive. Nekega torka ugotovite, da funkcija, ki je nekoč vzela en dan, zdaj vzame en teden, in nihče ne zna povsem povedati, zakaj. Tam, in ne ob zagonu, se večina SaaS izdelkov tiho dobi ali izgubi.

Sedeli smo z mnogimi ustanovitelji prav na tej točki. Ne propadajo — to je tisto zmedeno. Prihodki rastejo, ekipa se širi, predstavitve gredo dobro. A pod površjem izdelek stoka. Tiketi za podporo naraščajo hitreje kot uporabniki. Uvedbe, ki so bile nekoč dolgočasne, zdaj pridejo z zadržanim dihom. Koda, ki je pred letom dni delovala pametno, zdaj deluje kot minsko polje, kjer vsaka sprememba tvega, da sproži kaj drugega. Niso storili nič narobe. Preprosto so prerasli to, kar so zgradili, in nihče jim ni povedal, da naj bi se to zgodilo.

To je torej vodnik, ki bi si ga želeli za več ustanoviteljev, preden so se pojavile razpoke. Ne govori o hiperskaliranju, Kubernetesu ali o tem, kaj je nek samorog naredil pri petdesetih milijonih uporabnikov. Govori o dolgočasni, odločilni sredini — o prehodu iz deluje za peščico v deluje za mnoge — brez prepisovanja vsega, brez prestrašitve strank in brez izgorelosti ekipe. Cilj ni popolna arhitektura. Cilj je izdelek, ki še naprej raste, namesto takega, ki se tiho začne lomiti.

Kaj se v resnici lomi, ko SaaS raste

Tukaj je del, ki ustanovitelje najbolj preseneti: težave s skaliranjem skoraj nikoli ne pridejo kot dramatičen izpad, na katerega se pripravljate. Strežnik se ne vname. Namesto tega izdelek razvije neke vrste blago vročino. Strani, ki so se naložile v hipu, začnejo trajati tri sekunde. Poročilo, ki je dobro teklo za prve stranke, doseže časovno omejitev za veliko, ki se je pravkar prijavila. Ista napaka se nenehno vrača, ker sta dva dela kode skrivaj odvisna drug od drugega na način, ki ga nihče ni dokumentiral.

Tisto, kar se v resnici lomi, so redko vaši strežniki — to so vaše predpostavke. Na začetku ste gradili za obliko svojih prvih uporabnikov: nekaj računov, malo podatkov, preprosti delovni tokovi, vsi približno enaki. Rast ne dodaja le več istega. Dodaja raznolikost. Stranko z desetkrat več podatki. Ekipo, ki funkcijo uporablja na način, ki si ga nikoli niste predstavljali. Konico ob ponedeljkih ob 9. uri, ko se vsi prijavijo hkrati. Vsaka od njih tiho krši predpostavko, vgrajeno v vašo kodo pred letom dni, ko je bila njena kršitev nepredstavljiva.

Štiri mesta, kjer se to ponavadi prvič pokaže, so predvidljiva. Podatkovna baza je skoraj vedno kanarček — poizvedbe, ki so bile hipne nad majhnimi tabelami, se z rastjo podatkov plazijo. Počasna končna točka: ena ali dve strani, ki na zahtevo opravita preveč dela, v redu, dokler se promet ne nakopiči. Krhka uvedba, kjer je objava česar koli postala zastrašujoča, ker je koda preveč zapletena, da bi o njej razumno razmišljali. In obremenitev podpore, ki sploh ni infrastruktura, je pa najbolj resničen zgoden signal, da izdelek ne ustreza več temu, kako ga ljudje dejansko uporabljajo.

Past reševanja težav, ki jih še nimate

Preden govorimo o popravljanju stvari, opozorilo, ki je rešilo več izdelkov kot katera koli optimizacija. Največja grožnja rastočemu SaaS ni prezrtje obsega — je prezgodnje loventje zanj. V trenutku, ko ustanovitelj začuti prvo upočasnitev, je nagon poseči po arhitekturi, o kateri je bral na nekem slavnem inženirskem blogu. Mikrostoritve. Čakalna vrsta sporočil. Postavitev v več regijah. Razdrobitev podatkovne baze, preden ima milijon vrstic.

Tako porabite šest mesecev in celo premoženje za gradnjo infrastrukture za obseg, ki ga niste dosegli, medtem ko se dejanski izdelek preneha premikati. Še huje, zdaj ste vsako prihodnjo spremembo otežili, saj je porazdeljen sistem dramatično bolj zapleten za gradnjo in razhroščevanje kot preprost, ki ste ga imeli. Zamenjali ste težavo, ki je še niste imeli, za zagotovljeno, ki jo imate danes: nič se ne objavi.

Disciplina je tu ista, ki dobre izdelke naredi že na začetku: rešite težavo, ki je pred vami, ne tiste, ki vam laska, da si jo predstavljate. Dolgočasen, dobro razumljen monolit, ki ga lahko hitro spreminjate, bo pri skaliranju prekosil moderen porazdeljen sistem, ki se ga bojite dotakniti. Zapletenost je strošek, ki ga plačujete vsak dan, ne enkraten nakup.

Merite, preden kar koli spremenite

Skoraj vsak ustanovitelj, ki ga srečamo v tej fazi, je prepričan, da ve, kje je težava. V polovici primerov se motijo — ne zato, ker bi bili malomarni, ampak ker je intuicija grozen profiler. Del kode, ki se zdi počasen, je pogosto v redu; pravi krivec je neka tiha poizvedba, ki teče štirideset­krat na strani, na katero nihče ni pomislil. Ne morete popraviti tistega, česar niste izmerili, ugibanje pa je tu način, kako ekipe porabijo tedne za optimiziranje napačne stvari.

Za začetek ne potrebujete imenitnega observability sklada. Potrebujete tri dolgočasne številke pred očmi, ves čas. Katere končne točke so najpočasnejše in kako počasne pod resničnim prometom. Katere poizvedbe podatkovne baze porabijo največ skupnega časa — ne najpočasnejša posamezna poizvedba, ampak tista, katere čas se sešteje čez tisoče klicev. In kje se napake dejansko dogajajo, z dovolj konteksta, da jih reproducirate. S temi tremi se megla običajno razkadi v enem dnevu.

1. 1
   Vklopite osnovno spremljanje

   Odzivni časi po končni točki, stopnje napak in beleženje počasnih poizvedb na podatkovni bazi. Gostovana orodja to zmorejo v enem popoldnevu. Ne morete izboljšati številke, ki je ne vidite.
2. 2
   Najdite pravo trojico najhujših

   Razvrstite po skupnem porabljenem času, ne po občutku. Trije krivci skoraj vedno povzročijo večino bolečine. Zapišite si jih — to je vaš dejanski načrt.
3. 3
   Popravite enega, ponovno izmerite

   Spremenite eno samo stvar, nato ponovno preverite številke. Potrdite, da je pomagalo, preden nadaljujete. Dve spremembi hkrati in nikoli ne boste vedeli, katera je bila pomembna.
4. 4
   Ustavite se, ko je dovolj dobro

   Določite 'dovolj hitro', preden začnete — recimo vsaka stran pod sekundo pri trenutni obremenitvi. Onkraj tega je optimizacija požiralnik časa, ne zmaga.

Ta zadnji korak je pomembnejši, kot je videti. Delo na zmogljivosti je resnično zasvojljivo; vedno je še ena milisekunda za postrgati. A vaše stranke ne čutijo razlike med 200 ms in 120 ms, ure, ki jih porabite za njegovo lovljenje, pa so ure, ki jih ne porabite za funkcijo, ki bi posel dejansko razrasla. Izmerite, popravite trojico najhujših, razglasite zmago, pojdite naprej.

Podatkovna baza je skoraj vedno prvi zid

Če bi morali staviti denar na to, kje rastoč SaaS zadene ob svoj prvi pravi strop, bi vsakič stavili na podatkovno bazo. To je edini del sistema, kjer se majhne zgodnje odločitve najbolj kopičijo. Poizvedba brez indeksa se nad tisoč vrsticami izvede v hipu in se nad milijonom zatakne. Koda se ni spremenila. Podatki so se — in podatki samo rastejo.

Dobra novica je, da je podatkovna baza tudi kraj, kjer prebivajo najcenejši popravki z največjim učinkom. Klasičen je manjkajoči indeks: ena sama vrstica, ki večsekundno poizvedbo spremeni v hipno, ker baza neha pregledovati vsako vrstico, da bi našla tistih nekaj, ki jih potrebuje. Takoj za njim je težava poizvedbe N+1 — stran, ki namesto enega vprašanja bazi tiho postavi isto majhno vprašanje stokrat v zanki. Oba sta pogosta, oba sta nevidna, dokler ne pogledate, in oba sta običajno popravek za en dan, ko ju enkrat najdete.

Tu obstaja zaporedje, na katero se velja opreti, in se splača slediti mu po vrsti, namesto preskočiti na konec. Najprej popravite poizvedbe — indekse, N+1, počasno poročilo. Nato dodajte predpomnjenje za podatke, ki se nenehno berejo, a redko spreminjajo. Šele po tem je smiselno govoriti o bralnih replikah, večjih instancah ali ločevanju podatkov. Večina SaaS izdelkov poznejših korakov nikoli ne potrebuje. Le prve so potrebovali narejene kot je treba.

Skalirati izdelek pomeni skalirati to, kako ga spreminjate

Tukaj je premik, ki ustanovitelje ujame nepripravljene: po določeni točki skaliranje preneha biti o tem, da izdelek prenese več uporabnikov, in začne biti o tem, da vaša ekipa prenese več sprememb. Ko sta bila vi in en razvijalec, je vsak imel ves sistem v glavi. Spremenili ste lahko karkoli, ker ste vedeli, česa se bo dotaknilo. Pri petih ali desetih ljudeh se ta miselni model razdrobi — in koda, ki je predpostavljala, da vsi vedo vse, postane breme.

To je pravi razlog, zakaj uvedbe postanejo zastrašujoče. Ni tako, da bi koda čez noč postala slabša; gre za to, da nihče več ne more povsem napovedati polmera eksplozije spremembe. Rešitev ni junaštvo ali zamrznitev objavljanja. Je naložba v nablesteči oder, ki večji ekipi omogoča gibanje brez stopanja drug drugemu na prste: avtomatiziran nabor testov, ki ujame očitne okvare, uvedbe, ki so rutina namesto obreda, in način, da slabo izdajo izklopite v sekundah namesto v paniki.

• Nabor testov, ki pokriva tistih nekaj tokov, ki bi bili katastrofalni, če bi se pokvarili — prijava, plačilo, glavno dejanje. Ne vsega; tiste kritične redke.
• Uvedbe, ki tečejo na gumb, ne kot obred, tako da postane objavljanje po malem in pogosto varno namesto napeto.
• Hiter način za povrnitev spremembe, tako da je slaba izdaja petminutni dogodek, ne celonočni incident.
• Zastavice funkcij, tako da lahko kodo objavite najprej za nekaj strank in jo takoj izklopite, če se obnaša slabo.
• Dovolj dokumentacije, da dopust ene osebe ne zamrzne celotnega področja izdelka.

Nič od tega se ne pokaže v predstavitvi. Nič od tega neposredno ne doda funkcije. In prav to je delo, ki ločuje izdelek, ki še naprej pospešuje, od takega, ki se z vsako novo zaposlitvijo upočasnjuje. Ekipe, ki dobro skalirajo, so tiste, ki svojo sposobnost, da izdelek varno spreminjajo, obravnavajo kot funkcijo samo po sebi — ker pri obsegu to natanko je.

Kratka zgodba s točke pokanja

Da to konkretiziramo, tukaj je sestavljen primer, povzet po delu, ki smo ga opravili — podrobnosti zabrisane, oblika zvesta resničnosti. Majhen SaaS za upravljanje terenskih servisnih ekip se je dobro zagnal in zrasel na nekaj sto plačujočih podjetij. Ustanovitelji so bili navdušeni in izčrpani v enaki meri. Nato je podpisala njihova doslej največja stranka: podjetje z več uporabniki in več zgodovinskimi podatki kot prejšnjih deset strank skupaj.

V enem tednu se je nadzorna plošča, v kateri so vsi živeli, za to stranko upočasnila do plazenja — in, nenavadno, tudi za vse ostale. Tiketi za podporo so poskočili. Ustanovitelji so domnevali, da potrebujejo veliko večji strežnik, in se pripravljali na bolečo, drago prearhitekturo. To je bil trenutek, ko so nas poklicali, in nagon je bil razumljiv, a napačen.

Arhitekture se nismo dotaknili. Vklopili smo beleženje počasnih poizvedb in opazovali eno popoldne. Krivec je bil skoraj v zadrego majhen: glavna nadzorna plošča je seznam opravil vsakega uporabnika nalagala s klasičnim vzorcem N+1 in sprožala eno poizvedbo na opravilo. Za majhno stranko je to pomenilo nekaj ducatov neškodljivih poizvedb. Za novega velikana je to pomenilo na tisoče na nalaganje strani — kar je na deljeni infrastrukturi povleklo ves sistem navzdol za vse.

Nauk, ki so ga ustanovitelji odnesli, ni bil tehničen. Bil je v tem, da je zastrašujoča težava skaliranja, ki so si jo predstavljali — tista, ki je zahtevala predelavo in zbiranje sredstev — bila, ko je bila izmerjena, dvodnevni popravek, skrit za zastrašujočim simptomom. Bili so na robu, da bi mesece porabili za reševanje napačne težave. Tista vrzel, med namišljeno krizo in izmerjeno, je kraj, kjer se zapravi večina denarja za skaliranje.

Kdaj je res čas, da kos predelate

Vsa ta previdnost glede prezgodnjega skaliranja se lahko bere kot nikoli ne refaktoriraj, nikoli ne predelaj. Ni tako. Včasih je del izdelka res dosegel konec svoje življenjske dobe in njegovo ponovno krpanje je draga izbira. Trik je v razlikovanju resnične strukturne meje od običajnih bolečin rasti, ki bi jih izmerjen popravek obvladal.

Pošten signal je ta: komponento predelajte, ko so stroški njene spremembe postali dosledno višji od stroškov njene zamenjave. Ne, ko je grda — grda koda, ki je stabilna in se je redko kdo dotakne, je v redu. Iščete del sistema, kjer je vsaka sprememba počasna in tvegana, kjer se iste napake nenehno vračajo, kjer novi razvijalci ne morejo varno delati in kjer ste že preizkusili cenejše popravke in zadeli ob zid. Ko je več od teh resničnih hkrati, je osredotočeno prepisovanje tega enega kosa prava poteza.

In ko že predelujete, predelajte kos — ne izdelka. Popolno prepisovanje iz nič je sirenski spev skaliranja, tisto, kar deluje čisto in na koncu potopi leto, medtem ko konkurenti objavljajo. Zamenjajte tisto eno strohnelo komponento za jasno mejo, medtem ko preostali izdelek še naprej teče in služi. Kirurško, ne junaško.

Pogosta vprašanja