Pilvet ovat kuin taikalaatikko - kysyt mitä tarvitset, ja resurssit vain ilmestyvät tyhjästä. Virtuaalikoneet, tietokannat, verkko - kaikki tämä kuuluu vain sinulle. On muitakin pilvivuokralaisia, mutta universumissasi olet ainoa hallitsija. Olet varma, että saat aina tarvittavat resurssit, et ota ketään huomioon ja päätät itsenäisesti, millainen verkko tulee olemaan. Miten tämä taika toimii, joka saa pilven kohdistamaan joustavasti resursseja ja eristämään vuokralaiset kokonaan toisistaan?
AWS-pilvi on mega-erittäin monimutkainen järjestelmä, joka on kehittynyt evoluutionaalisesti vuodesta 2006 lähtien. Osa tästä kehityksestä tapahtui Vasily Pantyukhin - Amazon Web Services -arkkitehti. Arkkitehtina hän saa sisäkuvan paitsi lopputuloksen myös AWS:n voittamista haasteista. Mitä enemmän ymmärrät järjestelmän toiminnasta, sitä suurempi on luottamus. Siksi Vasily jakaa AWS-pilvipalveluiden salaisuudet. Alla on fyysisten AWS-palvelimien suunnittelu, joustava tietokannan skaalautuvuus, mukautettu Amazon-tietokanta ja menetelmät virtuaalikoneiden suorituskyvyn parantamiseksi ja samalla niiden hinnan alentamiseksi. Amazonin arkkitehtonisten lähestymistapojen tuntemus auttaa sinua käyttämään AWS-palveluita tehokkaammin ja voi antaa sinulle uusia ideoita omien ratkaisujesi rakentamiseen.
Tietoja puhujasta: Vasily Pantyukhin () aloitti Unix-järjestelmänvalvojana .ru-yrityksissä, työskenteli suurten Sun Microsystem -laitteistojen parissa 6 vuotta ja saarnasi datakeskeistä maailmaa EMC:ssä 11 vuotta. Se kehittyi luonnollisesti yksityisiksi pilviksi, ja vuonna 2017 se siirtyi julkisiin pilviin. Nyt hän tarjoaa teknisiä neuvoja, jotka auttavat elämään ja kehittymään AWS-pilvessä.
Vastuuvapauslauseke: kaikki alla on Vasilyn henkilökohtaista mielipidettä, eikä se välttämättä vastaa Amazon Web Services -palvelua. Artikkelin perustana oleva raportti löytyy YouTube-kanavaltamme.
Miksi puhun Amazon-laitteesta?
Ensimmäisessä autossani oli manuaalivaihteisto. Se oli hienoa, koska tunsin, että voisin ajaa autoa ja hallita sitä täysin. Pidin myös siitä, että ymmärsin ainakin suunnilleen sen toimintaperiaatteen. Luonnollisesti kuvittelin laatikon rakenteen olevan melko alkeellista - jotain polkupyörän vaihteiston kaltaiseksi.
Kaikki oli hienoa, paitsi yksi asia - jumissa liikenneruuhkissa. Vaikuttaa siltä, että istut etkä tee mitään, mutta vaihdat jatkuvasti vaihteita, painat kytkintä, kaasua, jarrua - se todella väsyttää. Ruuhkaongelma ratkesi osittain, kun perhe sai automaattiauton. Ajon aikana ehdin miettiä jotain ja kuunnella äänikirjaa.
Toinen mysteeri ilmestyi elämääni, koska lakkasin ymmärtämästä autoni toimintaa kokonaan. Nykyaikainen auto on monimutkainen laite. Auto mukautuu samanaikaisesti kymmeniin eri parametreihin: kaasun painamiseen, jarruihin, ajotyyliin, tien laatuun. En ymmärrä enää miten se toimii.
Kun aloin työskennellä Amazon-pilven parissa, se oli myös minulle mysteeri. Vain tämä mysteeri on suuruusluokkaa suurempi, koska autossa on yksi kuljettaja, ja AWS:ssä heitä on miljoonia. Kaikki käyttäjät ohjaavat, painavat kaasua ja jarruttavat samanaikaisesti. On hämmästyttävää, että he menevät minne haluavat – se on minulle ihme! Järjestelmä mukautuu, skaalautuu ja mukautuu joustavasti automaattisesti jokaiseen käyttäjään niin, että hänestä tuntuu, että hän on yksin tässä universumissa.
Taika laantui hieman, kun tulin myöhemmin töihin arkkitehdiksi Amazoniin. Näin, mitä ongelmia kohtaamme, kuinka ratkaisemme ne ja miten kehitämme palveluita. Kun ymmärrys järjestelmän toiminnasta lisääntyy, palveluun tulee lisää luottamusta. Joten haluan jakaa kuvan siitä, mitä AWS-pilven alla on.
Mistä puhuisimme
Valitsin monipuolisen lähestymistavan - valitsin 4 mielenkiintoista palvelua, joista kannattaa puhua.
Palvelimen optimointi. Efemeriset pilvet fyysisellä suoritusmuodolla: fyysiset tietokeskukset, joissa on fyysisiä palvelimia, jotka humisevat, kuumenevat ja vilkkuvat valoilla.
Palvelimettomat toiminnot (Lambda) on luultavasti skaalautuvin palvelu pilvessä.
Tietokannan skaalaus. Kerron sinulle, kuinka rakennamme omia skaalautuvia tietokantojamme.
Verkon skaalaus. Viimeinen osa, jossa avaan verkkomme laitteen. Tämä on hieno asia - jokainen pilven käyttäjä uskoo olevansa yksin pilvessä eikä näe muita vuokralaisia ollenkaan.
Huomautus. Tässä artikkelissa käsitellään palvelimen optimointia ja tietokannan skaalausta. Tarkastelemme verkon skaalausta seuraavassa artikkelissa. Missä ovat palvelimettomat toiminnot? Heistä julkaistiin erillinen kopio”" Siinä puhutaan useista eri skaalausmenetelmistä ja käsitellään yksityiskohtaisesti Firecracker-ratkaisua - virtuaalikoneen ja konttien parhaiden ominaisuuksien symbioosia.
Palvelimet
Pilvi on lyhytaikainen. Mutta tällä lyhytaikaisuudella on edelleen fyysinen ruumiillistuma - palvelimet. Aluksi niiden arkkitehtuuri oli klassista. Vakio x86-piirisarja, verkkokortit, Linux, Xen-hypervisor, jossa virtuaalikoneita ajettiin.
Vuonna 2012 tämä arkkitehtuuri selviytyi tehtävistään melko hyvin. Xen on loistava hypervisor, mutta sillä on yksi suuri haittapuoli. Hänellä on tarpeeksi korkeat yleiskustannukset laitteen emulointiin. Kun uusia, nopeampia verkkokortteja tai SSD-asemia tulee saataville, tämä yleiskustannus kasvaa liian suureksi. Kuinka käsitellä tätä ongelmaa? Päätimme työskennellä kahdella rintamalla kerralla - optimoida sekä laitteiston että hypervisorin. Tehtävä on erittäin vakava.
Laitteiston ja hypervisorin optimointi
Kaiken tekeminen kerralla ja hyvin tekeminen ei toimi. Se, mikä oli "hyvää", oli myös aluksi epäselvää.
Päätimme omaksua evolutionaarisen lähestymistavan – muutamme yhden tärkeän elementin arkkitehtuurista ja laitamme sen tuotantoon.
Astumme jokaisen haravan päälle, kuuntelemme valituksia ja ehdotuksia. Sitten vaihdamme toisen komponentin. Joten pienissä erissä muutamme radikaalisti koko arkkitehtuuria käyttäjien palautteen ja tuen perusteella.
Muutos alkoi vuonna 2013 monimutkaisimmasta asiasta - verkosta. SISÄÄN С3 tapauksissa vakioverkkokorttiin lisättiin erityinen Network Accelerator -kortti. Se yhdistettiin kirjaimellisesti lyhyellä silmukkakaapelilla etupaneelissa. Se ei ole kaunis, mutta se ei näy pilvessä. Mutta suora vuorovaikutus laitteiston kanssa paransi olennaisesti värinää ja verkon läpimenoa.
Seuraavaksi päätimme parantaa pääsyä lohkotietovarastoon EBS - Elastic Block Storage. Se on verkon ja tallennustilan yhdistelmä. Vaikeus on, että vaikka Network Accelerator -kortteja oli markkinoilla, ei ollut vaihtoehtoa ostaa vain Storage Accelerator -laitteistoa. Joten käännyimme startupiin Annapurna Labs, joka kehitti meille erityisiä ASIC-siruja. He sallivat EBS-etätaltioiden asentamisen NVMe-laitteiksi.
Tapauksissa C4 ratkaisimme kaksi ongelmaa. Ensimmäinen on se, että otimme käyttöön perustan tulevaisuudelle lupaavalle, mutta tuolloin uudelle NVMe-teknologialle. Toiseksi kuormittimme keskusprosessorin merkittävästi siirtämällä pyyntöjen käsittelyn EBS:lle uudelle kortille. Se osoittautui hyvin, joten nyt Annapurna Labs on osa Amazonia.
Marraskuuhun 2017 mennessä tajusimme, että oli aika vaihtaa itse hypervisori.
Uusi hypervisor kehitettiin modifioitujen KVM-ydinmoduulien perusteella.
Se teki mahdolliseksi vähentää perusteellisesti laitteen emuloinnin yleiskustannuksia ja työskennellä suoraan uusien ASIC:ien kanssa. Esineet С5 olivat ensimmäiset virtuaalikoneet, joissa oli uusi hypervisori konepellin alla. Nimesimme hänet Nitro.
Tapahtumien kehitys aikajanalla.
Kaikki uudet virtuaalikoneet, jotka ovat ilmestyneet marraskuun 2017 jälkeen, toimivat tällä hypervisorilla. Bare Metal -esiintymissä ei ole hypervisoria, mutta niitä kutsutaan myös Nitroiksi, koska ne käyttävät erikoistuneita Nitro-kortteja.
Seuraavien kahden vuoden aikana Nitro-esiintymien tyyppien määrä ylitti pari tusinaa: A1, C5, M5, T3 ja muut.
Instanssityypit.
Kuinka nykyaikaiset Nitro-koneet toimivat
Niissä on kolme pääkomponenttia: Nitro hypervisor (käsitelty yllä), turvasiru ja Nitro-kortit.
Turvasiru integroitu suoraan emolevyyn. Se ohjaa monia tärkeitä toimintoja, kuten isäntäkäyttöjärjestelmän latauksen hallintaa.
Nitro kortit – Niitä on neljää tyyppiä. Kaikki ne ovat Annapurna Labsin kehittämiä, ja ne perustuvat yleisiin ASIC:eihin. Jotkut niiden laiteohjelmistoista ovat myös yleisiä.
Neljä erilaista Nitro-korttia.
Yksi korteista on suunniteltu toimimaan verkkoVPC. Tämä näkyy virtuaalikoneissa verkkokorttina ENA - Elastinen verkkosovitin. Se myös kapseloi liikenteen, kun se siirretään fyysisen verkon kautta (puhumme tästä artikkelin toisessa osassa), hallitsee Security Groups -palomuuria ja vastaa reitityksestä ja muista verkkoasioista.
Tietyt kortit toimivat lohkotallennustilan kanssa EBS ja palvelimeen sisäänrakennetut levyt. Ne näkyvät vierasvirtuaalikoneelle muodossa NVMe-sovittimet. He vastaavat myös tietojen salauksesta ja levyn valvonnasta.
Nitro-korttien, hypervisorin ja turvasirun järjestelmä on integroitu SDN-verkkoon tai Ohjelmiston määrittämä verkko. Vastaa tämän verkon hallinnasta (Control Plane) ohjainkortti.
Jatkamme tietysti uusien ASIC-koodien kehittämistä. Esimerkiksi vuoden 2018 lopussa he julkaisivat Inferentia-sirun, jonka avulla voit työskennellä tehokkaammin koneoppimistehtävien kanssa.
Inferentia koneoppimisprosessorisiru.
Skaalautuva tietokanta
Perinteisessä tietokannassa on kerrosrakenne. Yksinkertaistaaksemme seuraavat tasot erotetaan toisistaan.
- SQL — Asiakas- ja tilausvälittäjät työskentelevät sen parissa.
- Varaukset liiketoimia - Kaikki on selvää täällä, ACID ja kaikki.
- välimuisti, jonka tarjoavat puskurialtaat.
- Kirjaaminen - tarjoaa työtä redo-lokien kanssa. MySQL:ssä niitä kutsutaan Bin Logsiksi, PosgreSQL:ssä - Write Ahead Logs (WAL).
- Varastointi - suora tallennus levylle.
Kerrostettu tietokantarakenne.
On olemassa erilaisia tapoja skaalata tietokantoja: sharing, Shared Nothing -arkkitehtuuri, jaetut levyt.
Kaikki nämä menetelmät säilyttävät kuitenkin saman monoliittisen tietokantarakenteen. Tämä rajoittaa merkittävästi skaalausta. Tämän ongelman ratkaisemiseksi kehitimme oman tietokannan − Amazon Aurora. Se on yhteensopiva MySQL:n ja PostgreSQL:n kanssa.
Amazon Aurora
Arkkitehtoninen pääidea on erottaa tallennus- ja kirjaustasot päätietokannasta.
Tulevaisuudessa sanon, että teimme myös välimuistitason itsenäiseksi. Arkkitehtuuri lakkaa olemasta monoliitti, ja saamme lisää vapausasteita yksittäisten lohkojen skaalauksessa.
Kirjaus- ja tallennustasot ovat erillisiä tietokannasta.
Perinteinen DBMS kirjoittaa tiedot tallennusjärjestelmään lohkojen muodossa. Amazon Auroralla loimme älykkään tallennustilan, joka osaa puhua kieltä redo-lokit. Sisällä tallennus muuttaa lokit tietolohkoiksi, valvoo niiden eheyttä ja varmuuskopioi automaattisesti.
Tämän lähestymistavan avulla voit toteuttaa sellaisia mielenkiintoisia asioita kuin kloonaus. Se toimii pohjimmiltaan nopeammin ja taloudellisemmin, koska se ei vaadi täydellistä kopiota kaikista tiedoista.
Tallennuskerros on toteutettu hajautettuna järjestelmänä. Se koostuu erittäin suuresta määrästä fyysisiä palvelimia. Jokainen redo-loki käsitellään ja tallennetaan samanaikaisesti kuusi solmua. Tämä varmistaa tietosuojan ja kuormituksen tasapainotuksen.
Luku skaalaus voidaan saavuttaa käyttämällä asianmukaisia kopioita. Hajautettu tallennus eliminoi tarpeen synkronoida päätietokanta-ilmentymän, jonka kautta kirjoitamme tietoja, ja jäljellä olevien replikoiden välillä. Ajantasaiset tiedot ovat taatusti kaikkien replikoiden saatavilla.
Ainoa ongelma on vanhojen tietojen tallentaminen välimuistiin luetuissa replikoissa. Mutta tämä ongelma on ratkaistu kaikkien redo-lokien siirto replikoihin sisäisen verkon kautta. Jos loki on välimuistissa, se merkitään virheelliseksi ja korvataan. Jos se ei ole välimuistissa, se yksinkertaisesti hylätään.
Järjestimme varastotilan.
Kuinka skaalata DBMS-tasoja
Tässä vaakasuuntainen skaalaus on paljon vaikeampaa. Mennään siis vauhdittua tietä klassinen pystyskaalaus.
Oletetaan, että meillä on sovellus, joka kommunikoi DBMS:n kanssa pääsolmun kautta.
Pystysuorassa skaalauksessa varaamme uuden solmun, jossa on enemmän prosessoreita ja muistia.
Seuraavaksi vaihdamme sovelluksen vanhasta pääsolmusta uuteen. Ongelmia syntyy.
- Tämä vaatii merkittäviä sovellusten seisokkeja.
- Uudella pääsolmulla on kylmävälimuisti. Tietokannan suorituskyky on maksimaalinen vasta, kun välimuisti on lämmennyt.
Kuinka parantaa tilannetta? Aseta välityspalvelin sovelluksen ja pääsolmun välille.
Mitä tämä antaa meille? Nyt kaikkia sovelluksia ei tarvitse uudelleenohjata manuaalisesti uuteen solmuun. Vaihto voidaan tehdä välityspalvelimen alla ja se on pohjimmiltaan nopeampi.
Vaikuttaa siltä, että ongelma on ratkaistu. Mutta ei, kärsimme edelleen tarpeesta lämmittää välimuistia. Lisäksi on ilmaantunut uusi ongelma - nyt välityspalvelin on mahdollinen vikakohta.
Lopullinen ratkaisu Amazon Aurora -palvelimettomalla
Miten ratkaisimme nämä ongelmat?
Jätti välityspalvelimen. Tämä ei ole erillinen esiintymä, vaan koko hajautettu välityspalvelinkanta, jonka kautta sovellukset muodostavat yhteyden tietokantaan. Vian sattuessa mikä tahansa solmu voidaan vaihtaa lähes välittömästi.
Lisätty joukko erikokoisia lämpimiä solmuja. Siksi, jos on tarpeen varata uusi suurempi tai pienempi solmu, se on heti käytettävissä. Ei tarvitse odottaa sen latautumista.
Koko skaalausprosessia ohjataan erityisellä valvontajärjestelmällä. Valvonta valvoo jatkuvasti nykyisen pääsolmun tilaa. Jos se havaitsee esimerkiksi, että prosessorin kuormitus on saavuttanut kriittisen arvon, se ilmoittaa lämpimien esiintymien poolille tarpeesta varata uusi solmu.
Hajautetut välityspalvelimet, lämpimät esiintymät ja valvonta.
Tarvittavalla teholla varustettu solmu on käytettävissä. Puskurivarastot kopioidaan siihen, ja järjestelmä alkaa odottaa turvallista hetkeä siirtyäkseen.
Yleensä vaihdon hetki tulee melko nopeasti. Sitten välityspalvelimen ja vanhan pääsolmun välinen yhteys keskeytetään, kaikki istunnot vaihdetaan uuteen solmuun.
Työskentely tietokannan kanssa jatkuu.
Kaavio osoittaa, että jousitus on todella lyhyt. Sininen kaavio näyttää kuormituksen ja punaiset vaiheet skaalausmomentit. Lyhytaikaiset laskut sinisessä kaaviossa ovat juuri sitä lyhyttä viivettä.
Muuten, Amazon Aurora antaa sinun säästää rahaa kokonaan ja sammuttaa tietokannan, kun se ei ole käytössä, esimerkiksi viikonloppuisin. Kuorman pysäyttämisen jälkeen DB vähentää vähitellen tehoaan ja sammuu joksikin aikaa. Kun kuorma palaa, se nousee taas tasaisesti.
Amazon-laitetta koskevan tarinan seuraavassa osassa puhumme verkon skaalauksesta. Tilaa ja pysy kuulolla, jotta et jää paitsi artikkelista.
Päälle Vasily Pantyukhin antaa raportin "" Mitä suunnittelumalleja hajautetuille järjestelmille Amazon-kehittäjät käyttävät, mitkä ovat palveluhäiriöiden syyt, mikä on solupohjainen arkkitehtuuri, jatkuva työ, satunnaisjako - se on mielenkiintoista. Alle kuukausi konferenssiin - . 24. lokakuuta lopullinen hinnankorotus.
Lähde: will.com