Kako AWS priprema svoje elastične usluge. Skaliranje servera i baze podataka

Oblaci su poput čarobne kutije - pitate šta vam treba, a resursi se jednostavno pojavljuju niotkuda. Virtuelne mašine, baze podataka, mreža - sve ovo pripada samo vama. Postoje i drugi zakupci oblaka, ali u vašem svemiru vi ste jedini vladar. Sigurni ste da ćete uvijek dobiti potrebne resurse, ne vodite računa o nikome i sami određujete kakva će mreža biti. Kako funkcioniše ova magija koja čini da oblak elastično raspoređuje resurse i potpuno izoluje stanare jedne od drugih?

AWS oblak je mega-super složen sistem koji se evolucijski razvija od 2006. godine. Dio ovog razvoja se dogodio Vasilij Pantjuhin - Amazon Web Services Architect. Kao arhitekta, on dobija pogled iznutra ne samo na krajnji rezultat, već i na izazove koje AWS savladava. Što je bolje razumevanje kako sistem funkcioniše, veće je poverenje. Stoga će Vasilij podijeliti tajne AWS usluga u oblaku. Ispod je dizajn fizičkih AWS servera, elastična skalabilnost baze podataka, prilagođena Amazon baza podataka i metode za povećanje performansi virtuelnih mašina uz istovremeno smanjenje njihove cene. Poznavanje Amazonovih arhitektonskih pristupa pomoći će vam da efikasnije koristite AWS usluge i može vam dati nove ideje za izgradnju vlastitih rješenja.

O govorniku: Vasilij Pantyukhin (kokoška) započeo je kao Unix administrator u .ru kompanijama, radio na velikom hardveru Sun Microsystema 6 godina i propovijedao svijet usmjeren na podatke u EMC-u 11 godina. Prirodno je evoluirao u privatne oblake, a 2017. prešao u javne. Sada pruža tehničke savjete kako bi pomogao u životu i razvoju u AWS oblaku.

Odricanje od odgovornosti: sve ispod je Vasilijevo lično mišljenje i možda se ne poklapa sa stavom Amazon Web Services. Video snimanje Izvještaj na kojem se zasniva članak dostupan je na našem YouTube kanalu.

Zašto govorim o Amazon uređaju?

Moj prvi auto je imao ručni menjač. Bilo je odlično zbog osjećaja da mogu voziti auto i imati potpunu kontrolu nad njim. Svidjelo mi se i to što sam barem otprilike razumio princip njegovog rada. Naravno, zamišljao sam da je struktura kutije prilično primitivna - nešto poput mjenjača na biciklu.

Sve je bilo odlično, osim jedne stvari - zaglavljeni u saobraćajnoj gužvi. Čini se kao da sjedite i ne radite ništa, ali stalno mijenjate brzine, pritiskate kvačilo, gas, kočnicu - to vas zaista umara. Problem saobraćajne gužve je delimično rešen kada je porodica dobila auto-automat. Dok sam vozio, imao sam vremena da razmislim o nečemu i poslušam audio-knjigu.

Još jedna misterija pojavila se u mom životu, jer sam potpuno prestao da razumijem kako moj auto radi. Savremeni automobil je složen uređaj. Automobil se istovremeno prilagođava na desetine različitih parametara: pritisak na gas, kočnicu, stil vožnje, kvalitet puta. Više ne razumijem kako to funkcionira.

Kada sam počeo da radim na Amazon oblaku, i za mene je to bila misterija. Samo je ova misterija za red veličine veća, jer u autu je jedan vozač, a u AWS-u ih ima na milione. Svi korisnici istovremeno upravljaju, pritiskaju gas i kočnicu. Neverovatno je da idu kuda žele - za mene je to čudo! Sistem se automatski prilagođava, skalira i elastično prilagođava svakom korisniku tako da mu se čini da je sam u ovom Univerzumu.

Magija je malo nestala kada sam kasnije došao da radim kao arhitekta u Amazonu. Vidio sam sa kakvim se problemima suočavamo, kako ih rješavamo i kako razvijamo usluge. Sa sve većim razumijevanjem kako sistem funkcionira, pojavljuje se više povjerenja u uslugu. Stoga želim podijeliti sliku onoga što se nalazi ispod haube AWS oblaka.

O čemu da pričamo

Odabrao sam raznolik pristup - odabrao sam 4 zanimljive usluge o kojima vrijedi govoriti.

Optimizacija servera. Efemerni oblaci sa fizičkim oličenjem: fizički centri podataka u kojima postoje fizički serveri koji bruje, greju i trepću svetlima.

Funkcije bez servera (Lambda) je vjerovatno najskalabilniji servis u oblaku.

Skaliranje baze podataka. Reći ću vam o tome kako gradimo vlastite skalabilne baze podataka.

Mrežno skaliranje. Posljednji dio u kojem ću otvoriti uređaj naše mreže. Ovo je divna stvar - svaki korisnik oblaka vjeruje da je sam u oblaku i uopće ne vidi druge stanare.

Bilješka. Ovaj članak će raspravljati o optimizaciji servera i skaliranju baze podataka. Razmotrit ćemo skaliranje mreže u sljedećem članku. Gdje su funkcije bez servera? O njima je objavljen poseban transkript “Mali, ali pametan. Otpakivanje Firecracker mikrovirtuelno" Govori o nekoliko različitih metoda skaliranja i detaljno razmatra Firecracker rješenje - simbiozu najboljih kvaliteta virtuelne mašine i kontejnera.

Serveri

Oblak je prolazan. Ali ta prolazna priroda ipak ima fizičko utjelovljenje – servere. U početku je njihova arhitektura bila klasična. Standardni x86 čipset, mrežne kartice, Linux, Xen hipervizor na kojem su pokrenute virtuelne mašine.

U 2012. godini ova arhitektura se prilično dobro nosila sa svojim zadacima. Xen je odličan hipervizor, ali ima jedan veliki nedostatak. Dosta mu je visoki troškovi za emulaciju uređaja. Kako nove, brže mrežne kartice ili SSD diskovi postaju dostupni, ovi troškovi postaju previsoki. Kako se nositi s ovim problemom? Odlučili smo da radimo na dva fronta odjednom - optimizirati i hardver i hipervizor. Zadatak je veoma ozbiljan.

Optimizacija hardvera i hipervizora

Uraditi sve odjednom i to dobro neće raditi. Šta je „dobro“ takođe je u početku bilo nejasno.

Odlučili smo se za evolutivni pristup - mijenjamo jedan važan element arhitekture i bacamo ga u proizvodnju.

Nagazimo na svaku grabu, slušamo pritužbe i sugestije. Zatim mijenjamo drugu komponentu. Dakle, u malim koracima, radikalno mijenjamo cjelokupnu arhitekturu na osnovu povratnih informacija korisnika i podrške.

Transformacija je počela 2013. godine sa najsloženijom stvari - mrežom. IN S3 U slučajevima, standardnoj mrežnoj kartici dodana je posebna kartica Network Accelerator. Bio je povezan bukvalno kratkim loopback kablom na prednjoj ploči. Nije lijepo, ali se ne vidi u oblaku. Ali direktna interakcija sa hardverom je suštinski poboljšala podrhtavanje i mrežnu propusnost.

Zatim smo odlučili da poboljšamo pristup blok memoriji podataka EBS - Elastic Block Storage. To je kombinacija mreže i skladišta. Poteškoća je u tome što, dok su kartice Network Accelerator postojale na tržištu, nije bilo mogućnosti da se jednostavno kupi hardver Storage Accelerator. Pa smo se okrenuli startupu Annapurna Labs, koji je za nas razvio posebne ASIC čipove. Dozvolili su da se udaljeni EBS volumeni montiraju kao NVMe uređaji.

U slučajevima C4 riješili smo dva problema. Prvi je da smo implementirali temelj za budućnost obećavajuće, ali u to vrijeme nove, NVMe tehnologije. Drugo, značajno smo rasteretili centralni procesor prebacivanjem obrade zahtjeva u EBS na novu karticu. Ispalo je dobro, tako da je sada Annapurna Labs dio Amazona.

Do novembra 2017. shvatili smo da je vrijeme da promijenimo sam hipervizor.

Novi hipervizor je razvijen na osnovu modifikovanih modula KVM kernela.

Omogućio je fundamentalno smanjenje troškova emulacije uređaja i direktan rad s novim ASIC-ovima. Instance S5 bile su prve virtuelne mašine sa novim hipervizorom koji je radio ispod haube. Dali smo mu ime Nitro.

Evolucija instanci na vremenskoj liniji.

Sve nove vrste virtuelnih mašina koje su se pojavile od novembra 2017. rade na ovom hipervizoru. Bare Metal instance nemaju hipervizor, ali se nazivaju i Nitro, jer koriste specijalizovane Nitro kartice.

U naredne dvije godine broj tipova Nitro instanci premašio je nekoliko desetina: A1, C5, M5, T3 i drugi.

Tipovi instanci.

Kako rade moderne Nitro mašine

Imaju tri glavne komponente: Nitro hipervizor (o kome je već bilo riječi), sigurnosni čip i Nitro kartice.

Sigurnosni čip integrisan direktno u matičnu ploču. On kontrolira mnoge važne funkcije, kao što je kontrola učitavanja host OS-a.

Nitro kartice - Postoje četiri vrste njih. Sve ih je razvila Annapurna Labs i zasnovani su na uobičajenim ASIC-ovima. Neki od njihovih firmvera su također uobičajeni.

Četiri vrste Nitro kartica.

Jedna od kartica je dizajnirana za rad mrežaVPC. To je ono što je vidljivo u virtuelnim mašinama kao mrežna kartica ENA - Elastični mrežni adapter. Također inkapsulira promet prilikom njegovog prijenosa kroz fizičku mrežu (o tome ćemo govoriti u drugom dijelu članka), kontrolira firewall sigurnosnih grupa i odgovoran je za usmjeravanje i druge mrežne stvari.

Odabrane kartice rade sa blok memorijom EBS i diskove koji su ugrađeni u server. Gostujućoj virtuelnoj mašini se pojavljuju kao NVMe adapteri. Oni su također odgovorni za enkripciju podataka i nadzor diska.

Sistem Nitro kartica, hipervizora i sigurnosnog čipa integrisan je u SDN mrežu ili Softverski definirana mreža. Odgovoran za upravljanje ovom mrežom (Control Plane) kartica kontrolera.

Naravno, nastavljamo sa razvojem novih ASIC-ova. Na primjer, krajem 2018. objavili su čip Inferentia, koji vam omogućava da efikasnije radite sa zadacima mašinskog učenja.

Inferentia čip procesora za mašinsko učenje.

Skalabilna baza podataka

Tradicionalna baza podataka ima slojevitu strukturu. Da bismo uvelike pojednostavili, razlikuju se sljedeći nivoi.

• SQL — na tome rade dispečeri klijenata i zahteva.
• Odredbe transakcije - Ovde je sve jasno, ACID i sve to.
• keširanje, koju obezbjeđuju puferski pulovi.
• Logging — omogućava rad sa redo logovima. U MySQL-u se zovu Bin Logs, u PosgreSQL-u - Write Ahead Logs (WAL).
• Skladištenje – direktno snimanje na disk.

Slojevita struktura baze podataka.

Postoje različiti načini za skaliranje baza podataka: dijeljenje, Shared Nothing arhitektura, dijeljeni diskovi.

Međutim, sve ove metode održavaju istu monolitnu strukturu baze podataka. Ovo značajno ograničava skaliranje. Da bismo riješili ovaj problem, razvili smo vlastitu bazu podataka − Amazon Aurora. Kompatibilan je sa MySQL i PostgreSQL.

Amazon Aurora

Glavna arhitektonska ideja je da se nivoi skladištenja i evidentiranja odvoje od glavne baze podataka.

Gledajući unaprijed, reći ću da smo također učinili neovisnim nivo keširanja. Arhitektura prestaje da bude monolit i dobijamo dodatne stepene slobode u skaliranju pojedinačnih blokova.

Nivoi evidentiranja i skladištenja su odvojeni od baze podataka.

Tradicionalni DBMS zapisuje podatke u sistem skladištenja u obliku blokova. U Amazon Aurori smo kreirali pametnu pohranu koja može govoriti jezik redo-logs. Unutra, skladište pretvara evidencije u blokove podataka, nadgleda njihov integritet i automatski pravi rezervne kopije.

Ovaj pristup vam omogućava da implementirate takve zanimljive stvari kao što su kloniranje. Funkcionalno radi brže i ekonomičnije zbog činjenice da ne zahtijeva stvaranje potpune kopije svih podataka.

Sloj za skladištenje je implementiran kao distribuirani sistem. Sastoji se od veoma velikog broja fizičkih servera. Svaki redo log se obrađuje i pohranjuje istovremeno šest čvorova. Ovo osigurava zaštitu podataka i balansiranje opterećenja.

Skaliranje čitanja može se postići korištenjem odgovarajućih replika. Distribuirano skladište eliminira potrebu za sinhronizacijom između glavne instance baze podataka, preko koje pišemo podatke, i preostalih replika. Zagarantovano je da će ažurirani podaci biti dostupni svim replikama.

Jedini problem je keširanje starih podataka na pročitanim replikama. Ali ovaj problem se rješava prijenos svih redo dnevnika na replike preko interne mreže. Ako je dnevnik u kešu, on je označen kao netačan i prepisan. Ako nije u kešu, jednostavno se odbacuje.

Sredili smo skladište.

Kako skalirati nivoe DBMS-a

Ovdje je horizontalno skaliranje mnogo teže. Pa idemo niz utabanu stazu klasično vertikalno skaliranje.

Pretpostavimo da imamo aplikaciju koja komunicira sa DBMS-om preko glavnog čvora.

Prilikom vertikalnog skaliranja, dodjeljujemo novi čvor koji će imati više procesora i memorije.

Zatim prebacimo aplikaciju sa starog glavnog čvora na novi. Nastaju problemi.

• Ovo će zahtijevati značajno vrijeme zastoja aplikacije.
• Novi glavni čvor će imati hladnu keš memoriju. Performanse baze podataka će biti maksimalne tek nakon što se predmemorija zagrije.

Kako poboljšati situaciju? Postavite proxy između aplikacije i glavnog čvora.

Šta će nam ovo dati? Sada sve aplikacije ne moraju biti ručno preusmjerene na novi čvor. Prebacivanje se može izvršiti pod proxyjem i suštinski je brže.

Čini se da je problem riješen. Ali ne, još uvijek patimo od potrebe za zagrijavanjem keša. Osim toga, pojavio se novi problem - sada je proxy potencijalna tačka kvara.

Konačno rješenje s Amazon Aurora bez servera

Kako smo riješili ove probleme?

Ostavio proxy. Ovo nije zasebna instanca, već čitava distribuirana flota proksija preko kojih se aplikacije povezuju na bazu podataka. U slučaju kvara, bilo koji od čvorova može se zamijeniti gotovo trenutno.

Dodan bazen toplih čvorova različitih veličina. Stoga, ako je potrebno dodijeliti novi čvor veće ili manje veličine, on je odmah dostupan. Nema potrebe čekati da se učita.

Cijeli proces skaliranja kontrolira se posebnim sistemom za praćenje. Monitoring stalno prati stanje trenutnog glavnog čvora. Ako otkrije, na primjer, da je opterećenje procesora dostiglo kritičnu vrijednost, obavještava skup toplih instanci o potrebi da se dodijeli novi čvor.

Distribuirani proksiji, tople instance i praćenje.

Dostupan je čvor sa potrebnom snagom. Skupovi međuspremnika se kopiraju u njega i sistem počinje da čeka siguran trenutak za prebacivanje.

Obično trenutak za prebacivanje dođe prilično brzo. Tada se prekida komunikacija između proxyja i starog glavnog čvora, sve sesije se prebacuju na novi čvor.

Rad sa bazom podataka se nastavlja.

Grafikon pokazuje da je suspenzija zaista vrlo kratka. Plavi grafikon prikazuje opterećenje, a crveni koraci pokazuju momente skaliranja. Kratkoročni padovi na plavom grafikonu su upravo to kratko kašnjenje.

Inače, Amazon Aurora vam omogućava da potpuno uštedite novac i isključite bazu podataka kada nije u upotrebi, na primjer, vikendom. Nakon zaustavljanja opterećenja, DB postupno smanjuje svoju snagu i gasi se neko vrijeme. Kada se opterećenje vrati, ponovo će lagano rasti.

U sljedećem dijelu priče o Amazon uređaju govorit ćemo o skaliranju mreže. Pretplatite se mail i ostanite sa nama kako ne biste propustili članak.

U HighLoad++ Vasilij Pantjuhin će dati izvještaj “Hjuston, imamo problem. Dizajn sistema za kvar, razvojni obrasci za interne Amazon cloud usluge" Koje šablone dizajna za distribuirane sisteme koriste Amazon programeri, koji su razlozi otkazivanja servisa, šta je Cell-based arhitektura, Konstantni rad, Shuffle Sharding - biće zanimljivo. Manje od mjesec dana do konferencije - rezervišite svoje karte. Konačno poskupljenje 24. oktobra.

izvor: www.habr.com