Kada servis koriste stotine miliona ljudi, čak i mala promena u načinu čuvanja podataka može napraviti ogromnu razliku. Canva je morala da pronađe način da brzo proverava opozvane korisničke sesije, a da pritom ne preoptereti svoju bazu podataka tokom svakog novog pokretanja servera.
Problem je nastao zato što je svaki Canva gateway tokom pokretanja učitavao veliki broj podataka iz MySQL baze. Sa stotinama servera koji su istovremeno tražili milione zapisa, deploy procesi su počeli da stvaraju svojevrsni udar na bazu.
Rešenje nije bilo dodavanje još više servera za bazu, već potpuno drugačiji pristup skladištenju podataka. Canva je postojeći sistem prebacila na kompaktni binarni format smešten u Amazon S3, čime je smanjila memorijsku potrošnju keša za čak 87,5 odsto.
Zašto je Canva uopšte morala da menja sistem sesija?
Canva koristi browser kolačiće kako bi sačuvala informacije o korisničkoj sesiji, uključujući identitet korisnika, dozvole i uloge. Pošto su kolačići šifrovani, gateway serveri mogu da provere podatke bez stalnog obraćanja eksternoj bazi.
Međutim, postoji problem. Ako se korisnik odjavi ili mu se promene privilegije, postojeći kolačić mora biti opozvan gotovo trenutno.
Zbog toga svaki gateway čuva listu opozvanih sesija direktno u memoriji. Takav pristup je veoma brz jer se provera obavlja bez mrežnog poziva prema bazi.
Do problema je došlo kada je broj korisnika porastao. Canva je morala da čuva oko 12 sati istorije opozvanih sesija, a svaki novi gateway je prilikom pokretanja povlačio veliki broj tih zapisa iz MySQL baze.
Sa velikim brojem servera koji se istovremeno pokreću tokom deploya, baza je dobijala ogroman broj zahteva.
Zašto Redis nije bio dovoljno dobro rešenje?
Prva ideja bila je klasična za distribuirane sisteme: ubaciti dodatni keš između baze i gateway servera.
Canva je razmatrala korišćenje Redis-a, popularne tehnologije za keširanje podataka. Gateway bi tada prilikom pokretanja podatke preuzimao iz Redis-a umesto direktno iz MySQL-a.
Ipak, ovaj pristup je imao novi problem. Redis nije idealan za situacije gde su potrebne jake garancije trajnosti podataka. Osim toga, kompanija bi morala da održava još jedan veliki distribuirani sistem.
Drugim rečima, problem bi samo bio prebačen sa jedne baze na drugu.
Canva je zato tražila sistem koji može da čuva velike količine podataka, da bude pouzdan i da omogući brzo čitanje. Tu je izbor pao na Amazon S3, servis napravljen upravo za skladištenje velikih količina trajnih podataka.
Pretvaranje promenljivog keša u statične fajlove
Najveći izazov bio je što opozvane sesije nisu statični podaci. Lista se stalno menja jer novi korisnici bivaju odjavljeni, dok stari zapisi prestaju da budu relevantni.
Canva je rešila problem tako što je vremenski prozor od 12 sati podelila na segmente od po 30 minuta. Svaki segment postao je poseban objekat u S3 skladištu.
Gateway server više nije morao da učitava celu bazu. Umesto toga, preuzimao je samo najnovije segmente koji su mu potrebni.
Svaki zapis o opozvanoj sesiji sadrži dva ključna podatka: korisnika na koga se odnosi i vreme do kojeg sesija mora biti nevažeća. Canva je uspela da ove informacije spakuje u samo 16 bajtova.
Podaci su zatim sortirani tako da gateway može brzo da pronađe odgovarajuće zapise koristeći binarnu pretragu.
Ovaj pristup je doneo još jednu važnu prednost. Raniji sistem je za svaki zapis koristio više Java objekata, što je stvaralo veliki memorijski trošak. Novi format je smanjio veličinu keša za skoro osam puta.
Kako Canva sprečava gubitak podataka
Prebacivanje podataka u S3 rešilo je problem čitanja, ali je otvorilo novo pitanje: kako stalno ažurirati fajlove?
Direktno menjanje S3 objekta pri svakom novom opozivu bilo bi presporo i skupo. Zato Canva koristi poseban asinhroni proces koji u pozadini preuzima nove opozive iz baze i dodaje ih u postojeće segmente.
Da bi sprečila konflikte između više radnika, kompanija koristi optimističku kontrolu konkurentnosti. Svaka promena proverava da li je podatak u međuvremenu promenjen pre nego što se upiše nova verzija.
Canva koristi i ZooKeeper izbor lidera kako bi smanjila broj potencijalnih konflikata između procesa. Ipak, taj mehanizam nije jedina zaštita, jer sistem mora ostati bezbedan čak i kada jedan server zastane tokom izvršavanja.
Rezultat: brži deploy i manji troškovi infrastrukture
Nakon prelaska na novi sistem, Canva je ubrzala deploy procese i smanjila broj replika baze potrebnih za rad sistema. Umesto velikog broja dodatnih servera, ostavili su samo dve replike baze radi pouzdanosti.
Najveća promena bila je u načinu skaliranja. Prethodni sistem je opterećivao bazu u zavisnosti od broja gateway servera koji se pokreću i količine istorijskih zapisa.
Novi sistem mnogo predvidljivije raste zajedno sa brojem novih opozvanih sesija i ukupnim saobraćajem.
Najvažnija lekcija iz ovog projekta jeste da se veliki distribuirani sistemi ne rešavaju samo teorijom. Canva je testirala više pristupa na stvarnoj infrastrukturi pre nego što je izabrala konačno rešenje.
U vremenu kada AI alati mogu brzo da generišu prototipove kompleksnih sistema, stvarno testiranje na očekivanom opterećenju i dalje ostaje ključni korak. Arhitektura koja izgleda dobro na papiru ne mora nužno biti najbolji izbor u produkciji.
0 komentara