Kuidas AWS «keedab» oma elastseid teenuseid. Serverite ja andmebaaside skaleerimine

Pilved on nagu maagiline karp - sa määratled, mida vajad, ja ressursid lihtsalt ilmuvad nagu mingist tühi kohast. Virtuaalmasinad, andmebaasid, võrk - kõik see kuulub ainult sinule. On olemas ka teisi pilveüürnike, kuid oma universumis oled sa ainus valitseja. Sa võid olla kindel, et saad alati vajalikke ressursse, ei pea kellegagi arvestama ja määrad ise, milline on võrk. Kuidas see ilu töötab, mis paneb pilve paindlikult ressursse jaotama ja täielikult isoleerib üürnikud üksteisest?

AWS pilv on megasuperkeeruline süsteem, mis on evolutsiooniliselt arenenud aastast 2006. Osa sellest arengust on näinud Vassili Pantiuhin — Amazon Web Services'i arhitekt. Arhitektina näeb ta seest mitte ainult lõpptulemust, vaid ka keerukusi, millega AWS silmitsi seisab. Mida rohkem mõistad süsteemi tööd, seda rohkem usaldust. Seetõttu jagab Vassili AWS-i pilveteenuste saladusi. Allpool on ülevaade AWS-i füüsiliste serverite seadistusest, paindlikust andmebaasi skaleerimisest, Amazonis kohandatud andmebaasist ja meetoditest virtuaalmasinate jõudluse parandamiseks, samal ajal nende hinda vähendades. Amazon architectural approach’id aitavad tõhusamalt kasutada AWS-i teenuseid ja võivad isegi anda uusi ideid oma lahenduste loomiseks.

Esinejast: Vassili Pantiuhin (Hen) alustas Unix-adminnina .ru ettevõtetes, kuus aastat tegeles suure rauaga Sun Microsystem'is, 11 aastat propageeris andmekeskuse keskset maailma EMC-s. Loomulikult arenes ta privaatsetest pilvedest avalikesse 2017. aastal. Praegu aitab ta tehniliste nõuannetega, et AWS-is elada ja areneda.

Ebaselgus: kõik, mis on allpool, on Vassili isiklik arvamus ja see ei pruugi kattuda Amazon Web Services'i seisukohaga. Videoklipp ettekandest, mille põhjal see artikkel on loodud, on saadaval meie YouTube'i kanalis.

Miks ma räägin Amazoniga seadistamisest

Minu esimene auto oli "kätega" - manuaalkäigukastiga. See oli suurepärane, sest tundsin, et suudan autot juhtida ja täielikult seda kontrollida. Mulle meeldis ka, et ma vähemalt enam-vähem mõistsin, kuidas see töötab. Loomulikult kujutasin ma kasti ülesehitust piisavalt primitiivselt - umbes nagu jalgratta käigukast.

Kõik oli suurepärane, välja arvatud üks asi — ummikud. Näiliselt istud ja ei tee midagi, aga pidevalt vahetad käike, tõstad clutchi, ja vajutad gaasi ning pidurit — sellest väsid tõeliselt. Uute autode automatiseerimine lahendas osaliselt ummikute probleemi, kui meie peres ilmus automaatkäigukastiga auto. Roolis olles on mul aega mõelda, kuulata audiokogusid.

Minu elus tekkis veel üks mõistatus, kuna ma ei mõistnud enam, kuidas minu auto töötab. Kaasaegne auto on keeruline seade. Auto kohandub samaaegselt kümnete erinevate parameetritega: gaasi vajutamine, pidur, sõidustiil, tee kvaliteet. Ma ei saa enam aru, kuidas see töötab.

Kui ma hakkasin tegelema Amazon Cloudiga, oli see minu jaoks samuti saladus. Kuid see saladus on kordades suurem, sest autos on ainult üks juht, kuid AWS-is on neid miljoneid. Kõik kasutajad sõidavad samal ajal, vajutavad gaasi ja pidurit. Huvitav on see, et nad jõuavad sinna, kuhu soovivad — see on minu jaoks ime! Süsteem kohandub automaatselt, skaleerub ja paindlikult kohandub iga kasutaja jaoks, nii et talle tundub, et ta on selles Universumit üksi.

Maagia hajus veidi, kui tulin hiljem Amazonisse arhitektina töötama. Nägin, milliste probleemidega me kokku puutume, kuidas me neid lahendame ja kuidas arendame teenuseid. Süsteemi töö mõistmine suurendab usaldust teenuse vastu. Seetõttu tahan jagada pilti sellest, mis on AWS-i pilve all.

Millest räägime

Olen valinud mitmekesise lähenemise — valisin neli huvitavat teenust, millest tasub rääkida.

Serverite optimeerimine. Efemeersed pilved füüsilise kehaga: füüsilised andmekeskused, kus seisavad füüsilised serverid, mis sumisevad, soojenevad ja vilguvad tuled.

Serverless funktsioonid (Lambda) — tõenäoliselt kõige skaleeritavam teenus pilves.

Andmebaasi skaleerimine. Räägin sellest, kuidas me ehitame oma skaleeritavad andmebaasid.

Võrgu skaleerimine. Viimane osa, kus avandan meie võrgu ülesehitust. See on imeline asi — iga pilve kasutaja arvab, et ta on pilves üksi ja ei näe teisi tenant’e.

Märkus. Käesolevas artiklis käsitleme serverite optimeerimist ja andmebaaside skaleerimist. Võrgu skaleerimist arutame järgmises artiklis. Kuhu jäävad serverless-funktsioonid? Nendest on ilmunud eraldi tõlgendus «Väike, aga vinge. Firecracker'i mikrovõrgu avamine». Selles on rääkida mitmest erinevast skaleerimisviisist ning üksikasjalikult on käsitletud Firecracker'i lahendust — parimate virtuaalmasina ja konteinerite omaduste sümbioos.

Serverid

Pilv on efemeerne. Kuid sellel efemeersusel on siiski füüsiline kehastus — serverid. Alguses oli nende arhitektuur klassikaline. Tavaline x86 kiibistik, võrgukaardid, Linux, hüperviisor Xen, millel käitusid virtuaalmasinad.

2012. aastal täitis selline arhitektuur oma ülesandeid kenasti. Xen on suurepärane hüperviisor, kuid ühe tõsise puudusega. Sel on piisavalt suured seadme emuleerimise kulud. Kui turule ilmusid uued kiiremad võrgukaardid või SSD-d, muutusid need kulud liiga kõrgeks. Kuidas sellega toime tulla? Otsustasime töötada kohe kahes suunas — optimeerida nii riistvara kui ka hüperviisorit. Ülesanne on väga tõsine.

Riistvara ja hüperviisori optimeerimine

Kõike korraga ja hästi ei õnnestu. Mis on «hästi», alguses ei olnud ka selge.

Otsustasime rakendada evolutsioonilist lähenemist — muutma ühte olulist arhitektuuri elementi ja viima selle produtsendile.

Astume kõigile takistustele, kuulame kaebusi ja ettepanekuid. Siis muutame teist komponenti. Nii, väikeste sammudega, muudame kogu arhitektuuri radikaalselt vastavalt kasutajate ja toe tagasisidele.

Muudatused algasid 2013. aastal kõige keerulisemast — võrgust. C3 instantsidesse lisati standardse võrgukaardi juurde spetsiaalne Network Accelerator kaart. See ühendati lihtsalt lühikese loopback kaabliga esipaneelil. Ehkki see nägi välja inetu, ei olnud see pilves näha. Kuid otsene suhtlemine riistvaraga parandas põhimõtteliselt jitterit ja võrgu läbilaskevõimet. Edasi otsustasime tegeleda EBS — Elastic Block Storage andmete plokkide säilitamise võrgu juurdepääsu parandamisega. See on võrgu ja ladustamise kombinatsioon. Probleem seisneb selles, et kui turul olid olemas Network Accelerator kaardid, siis ei olnud võimalust lihtsalt osta Storage Accelerator riistvara. Seetõttu pöördusime startup'i poole

Annapurna Labs Annapurna Labs, mis valmistati meile spetsiaalsed ASIC-kiibid. Need võimaldasid ühendada kaugseid EBS-mahte NVMe-seadmetena.

Instantsides C4 lahendasime kaks ülesannet. Esiteks - loobusime tuleviku suunaga perspektiivikast, kuid tol ajal veel uudsest NVMe-tehnoloogiast. Teiseks - oluliselt leevendasime keskprotsessori koormust, viies EBS-i päringute töötlemise uuele kaardile. See õnnestus, seetõttu on Annapurna Labs nüüd osa Amazonist.

November 2017. aastaks olime aru saanud, et on aeg muuta ka hüperviisorit.

Uus hüperviisor arendati välja täiustatud KVM-i tuumamoodulite põhjal.

See võimaldas oluliselt vähendada seadmete emulatsiooniga seotud kulu ja töötada otse uute ASIC-idega. Instantsid C5 olid esimesed virtuaalmasinad, mille all on uus hüperviisor. Nimeks saime selle Nitro.

Instantside evolutsioon ajajoone järgi.

Kõik uued virtuaalmasinate tüübid, mis ilmusid novembris 2017, töötavad selle hüperviisori peal. Raudse Bare Metal instantsidel ei ole hüperviisorit, kuid neid nimetatakse samuti Nitroks, kuna nad kasutavad spetsialiseeritud Nitro-kaarte.

Järgnevate kahe aasta jooksul ületas Nitro-instantside tüüpide arv paarikümne: A1, C5, M5, T3 ja teised.

Instantside tüübid.

Kuidas modernsed Nitro-masinad on üles ehitatud

Neil on kolm peamist komponenti: Nitro-hüperviisor (millest räägiti varem), turvakiip ja Nitro-kaardid.

Turvakiip on integreeritud otse emaplaadi. See kontrollib mitmeid olulisi funktsioone, näiteks hosti operatsioonisüsteemi laadimise kontrolli.

Nitro-kaardid – neid on neli tüüpi. Kõik need on välja töötatud Annapurna Labs'i poolt ja põhinevad üldistel ASIC-idel. Osa nende püsivara on samuti ühine.

Neli tüüpi Nitro-kaarte.

Üks kaart on ette nähtud tööks võrgugaVPC. Just see on virtuaalmasinates nähtav kui võrgukaart ENA — Elastic Network Adaptor. Samuti kapseldab see andmeid, kui need edastatakse füüsilise võrgu kaudu (sellest räägime artikli teises osas), kontrollib Security Groupi tulemüüri, vastutab marsruutimise ja teiste võrguasjade eest.

Erilised kaardid töötavad plokkhoidla EBS ja serverisse integreeritud ketastega. Külastavale virtuaalmasinale esitatakse need kui NVMe-adapterid. Samuti vastutavad nad andmete krüpteerimise ja ketaste jälgimise eest.

Nitro-kaartide, hüperviisori ja turvakiibi süsteem on ühendatud SDN-võrku ehk Software Defined NetworkSelle võrgu (Control Plane) haldamise eest vastutab kaardikontroller.

Muidugi jätkame uute ASIC-ide arendamist. Näiteks 2018. aasta lõpus tõime turule Inferentia kiibi, mis võimaldab töötada masinõppe ülesannetega efektiivsemalt.

Inferentia masinõppe protsessor.

Mastaabilehe andmebaas

Traditsiooniline andmebaas on kihiline struktuur. Kui väga lihtsustatult öelda, siis eristatakse järgmisi tasandeid.

• SQL — sellega töötavad kliendi- ja päringuhaldurid.
• Kindlustamine tehingud — siin on kõik selge, ACID ja kõik selline.
• Vahemälu, mida tagavad puhvritooted.
• Logimine — tagab redo-logide töö. MySQL-is nimetatakse neid Bin Logs, PostgreSQL-is — Write Ahead Logs (WAL).
• Salvestamine – andmete kirjutamine kettale.

Andmebaasi kihiline struktuur.

Andmebaaside mastaabilaiendamiseks on olemas erinevad meetodid: sharding, arhitektuur Shared Nothing, jagatud kettad.

Siiski, kõik need meetodid säilitavad sama monoliitse andmebaasi struktuuri. See piirab mastaapsust oluliselt. Selle probleemi lahendamiseks töötasime välja oma andmebaasi — Amazon Aurora. See on ühilduv MySQL-i ja PostgreSQL-iga.

Amazon Aurora

Peamine arhitektuuriidee — eraldada salvestuse ja logimise tasandid peamisest andmebaasist.

Korraks öeldes, et ka vahemälu tase on meil tehtud sõltumatuks. Arhitektuur lõpetab monoliidi olemise ja saame lisavabaduste mastaabilaiendamiseks erinevates blokides.

Logimise ja salvestamise tasandid on eraldatud andmebaasist.

Traditsiooniline DBMS salvestab andmed salvestussüsteemi plokkide kujul. Amazon Auroras lõime "nutika" salvestuse, mis suudab rääkida redo-logidest. Salvestuses muudetakse logid andmeplokkideks, jälgitakse nende terviklikkust ja varundatakse automaatselt.

See lähenemine võimaldab rakendada selliseid huvitavaid asju nagu kloneerimine. See töötab põhimõtteliselt kiiremini ja ökonoomsemalt, kuna ei vaja täieliku andmete koopia loomist.

Salvestustase on rakendatud jaotatud süsteemina. See koosneb väga suurest füüsiliste serverite arvust. Iga redo-log töödeldakse ja salvestatakse samaaegselt kuue sõlme poolt. See tagab andmete kaitse ja koormuse jaotamise.

Lugemise skaala saavutamiseks saab kasutada vastavaid koopiaid. Jaotatud salvestus kõrvaldab vajaduse sünkroonimise järele peamise andmebaasi instantsiga, mille kaudu me andmeid kirjutame, ja teiste koopiatega. Aktiivsed andmed on tagatud kõigile koopiatele.

Ainus probleem on lugemise koopiate vanade andmete vahemälu. Kuid seda probleemi on võimalik lahendada kõigi redo-logide edastamisega koopiatesse sisemiste võrkude kaudu. Kui logi on vahemälus, siis märgitakse see kehtetuks ja kirjutatakse üle. Kui vahemälus seda ei ole, siis lihtsalt kõrvaldatakse.

Salvestuse osas oleme selged.

Kuidas skaleerida andmebaasi tasemeid

Siin on horisontaalne skaleerimine palju keerulisem. Seetõttu liigume kindlat rada pidi klassikalise vertikaalse skaleerimise poole.

Oletame, et meil on rakendus, mis suhtleb andmebaasiga läbi meistrinoodi.

Vertikaalse skaleerimise korral jagame uue nodi, millel on rohkem protsessoreid ja mälu.

Seejärel suuname rakenduse vanalt meistrinoodilt uuele. Tõstatub probleem.

• See vajab rakenduse jaoks märkimisväärset seiskamist.
• Uuel meistrinode on külm vahemälu. Andmebaasi sooritusvõime on maksimaalne alles pärast vahemälu soojenemist.

Kuidas olukorda parandada? Paigaldada vaheproksi rakenduse ja meistrinode vahele.

Mida see meile annab? Nüüd ei ole kõik rakendused vaja käsitsi suunata uuele nodile. Ülemineku võib teha läbi vaheproksi ja see on oluliselt kiire.

Tundub, et probleem on lahendatud. Kuid ei, me kannatame endiselt vahemälu soojendamise vajaduse all. Lisaks on ilmnenud uus probleem — nüüd on vaheproksi potentsiaalne rikepunkt.

Lõplik lahendus Amazon Aurora serverless

Kuidas me need probleemid lahendasime?

Jätsime vaheproksi. See ei ole mingi eraldi instants, vaid terve jaotatud vaheproksi laevastik, mille kaudu rakendused on ühendatud andmebaasiga. Ükskõik millist nodi saab vajadusel peaaegu viivitamatult asendada.

Lisatud oli soe nodide tõttu erineva suurusega. Seetõttu on vajadusel uue suurema või väiksema nodi saamine kohe kergesti saadaval. Ei pea ootama, kuni see laaditakse.

Kogu skaleerimisprotsess on kontrollitud spetsiaalse jälgimissüsteemiga. Jälgimine jälgib pidevalt praeguse master-noodi olekut. Kui ta avastab näiteks, et protsessori koormus on jõudnud kriitilisele tasemele, teavitab ta soe instantside gruppi vajadusest uue noodiga varustamiseks.

Jaotatud proksid, soojad instantsid ja jälgimine.

Vajalikul võimsusel olev node on saadaval. Sellele kopeeritakse puhvri grupid ning süsteem hakkab ootama ohutut hetke ümberlülitamiseks.

Tavaliselt saab ümberlülitamise hetk kergesti kätte. Siis peatub side proksi ja vana master-noodi vahel, kõik sessioonid lülitatakse üle uuele nodile.

Andmebaasiga töötamine jätkub.

Graafikult on näha, et peatus on tõepoolest väga lühike. Sinisel graafikul on koormus ja punastele astmetele jäävad skaleerimise hetked. Lühikesed langused sinisel graafikul on just see lühike viivitus.

Muide, Amazon Aurora võimaldab äärmiselt säästlikult lõpetada andmebaasi, kui see ei ole kasutuses, näiteks nädalavahetustel. Pärast seiskamist hakkab andmebaasi koormus järk-järgult vähenema ja jääb mõneks ajaks välja lülitatud. Kui koormus naaseb, tõuseb see jälle sujuvalt.

Järgmises osas Amazonä seadistamise latiteerimisest räägime võrgu skaleerimisest. Registreeruge uudiskirjadele ja jälgige uuendusi, et mitte jääda artiklist ilma.

Pealehe HighLoad++ Vassili Pantjuhin esitab ettekande „Houston, meil on probleem. Talitlushäirete kavandamise süsteemid, Amazon'i pilveteenuste sisetöötamise mustrid“. Milliseid jaotatud süsteemide kujundamise mustreid kasutavad Amazon'i arendajad, millised on teenuste talitlushäirete põhjused, mis on Cell-based architecture, Constant Work, Shuffle Sharding — see on huvitav. Konverentsini on vähem kui kuu — broneerige pileteid. 24. oktoobril tõuseb hind.

Allikas: habr.com