Hodeiak kutxa magiko bat bezalakoak dira: behar duzuna galdetzen duzu eta baliabideak ezerezetik agertzen dira. Makina birtualak, datu-baseak, sarea - hori guztia zuri bakarrik dagokio. Beste hodei maizter batzuk daude, baina zure Unibertsoan zu zara agintari bakarra. Ziur zaude beti jasoko dituzula beharrezko baliabideak, ez duzula inor kontuan hartzen eta modu independentean zehazten duzu sarea nolakoa izango den. Nola funtzionatzen du hodeiak baliabideak elastikoki banatu eta maizterrak elkarrengandik guztiz isolatzen dituen magia honek?
AWS hodeia 2006az geroztik ebolutiboki eboluzionatzen ari den sistema mega-super konplexua da. Garapen horren zati bat gertatu zen Vasily Pantyukhin - Amazon Web Services Arkitektoa. Arkitekto gisa, azken emaitza ez ezik, AWSk gainditzen dituen erronkei buruzko begirada bat jasotzen du. Sistemaren funtzionamendua zenbat eta handiagoa izan, orduan eta konfiantza handiagoa izango da. Hori dela eta, Vasilyk AWS hodeiko zerbitzuen sekretuak partekatuko ditu. Jarraian, AWS zerbitzari fisikoen diseinua, datu-base elastikoen eskalagarritasuna, Amazon datu-base pertsonalizatua eta makina birtualen errendimendua areagotzeko metodoak daude, aldi berean prezioa murrizteko. Amazonen arkitektura-ikuspegiak ezagutzeak AWS zerbitzuak modu eraginkorragoan erabiltzen lagunduko dizu eta zure irtenbideak eraikitzeko ideia berriak emango dizkizu.
Hizlariari buruz: Vasily Pantyukhin () Unix-en administratzaile gisa hasi zen .ru enpresetan, 6 urtez Sun Microsystem hardware handietan lan egin zuen eta 11 urtez EMCn datuetan oinarritutako mundua predikatu zuen. Berez hodei pribatuetara eboluzionatu zen, eta 2017an publikoetara pasatu zen. Orain aholkularitza teknikoa ematen du AWS hodeian bizi eta garatzen laguntzeko.
Oharra: behean dagoen guztia Vasily-ren iritzi pertsonala da eta baliteke Amazon Web Services-en posizioarekin ez bat etorriko. Artikuluaren oinarrian dagoen txostena gure YouTube kanalean dago eskuragarri.
Zergatik ari naiz Amazon gailuaz hitz egiten?
Nire lehen autoak eskuzko transmisioa zuen. Ikaragarria izan zen autoa gidatu eta erabat kontrolatu nezakeen sentsazioagatik. Era berean, gustatu zait gutxi gorabehera bere funtzionamenduaren printzipioa gutxi gorabehera ulertu nuela. Berez, kutxaren egitura nahiko primitiboa zela imajinatu nuen, bizikleta baten kaxa baten antzeko zerbait.
Dena bikaina izan zen, gauza bat izan ezik: auto-ilarak sartuta. Eseri eta ezer egiten ez zarela ematen du, baina martxak aldatzen ari zarela etengabe, enbragea, gasa, balazta sakatzen ari zara - benetan nekatu egiten zaitu. Auto-ilarak arazoa partzialki konpondu zen familiak auto automatiko bat eskuratu zuenean. Gidatzen ari nintzela, zerbait pentsatu eta audioliburu bat entzuteko denbora izan nuen.
Nire bizitzan beste misterio bat agertu zen, nire autoak nola funtzionatzen duen ulertzeari erabat utzi nionelako. Auto moderno bat gailu konplexua da. Autoa hamaika parametro ezberdinetara egokitzen da aldi berean: gasa sakatzea, balazta, gidatzeko estiloa, errepidearen kalitatea. Jada ez dut ulertzen nola funtzionatzen duen.
Amazon hodeian lanean hasi nintzenean, niretzat ere misterio bat zen. Misterio hori bakarrik magnitude ordena handiagoa da, autoan gidari bat baitago, eta AWSn milioika daude. Erabiltzaile guztiek aldi berean gidatzen dute, gasa sakatu eta balaztatu. Harrigarria da nahi duten tokira joatea - mirari bat da niretzat! Sistema automatikoki egokitu, eskalatu eta elastikoki egokitzen zaio erabiltzaile bakoitzari, Unibertso honetan bakarrik dagoela iruditu dezan.
Magia pixka bat desagertu zen geroago Amazonen arkitekto gisa lan egitera etorri nintzenean. Ikusi nuen zer arazo ditugun, nola konpontzen ditugun eta nola garatzen ditugun zerbitzuak. Sistemak nola funtzionatzen duen gero eta ulertzean, zerbitzuarekiko konfiantza handiagoa agertzen da. Beraz, AWS hodeiaren azpian dagoenaren argazki bat partekatu nahi dut.
Zertaz hitz egingo dugu
Ikuspegi dibertsifikatu bat aukeratu nuen: hitz egitea merezi duten 4 zerbitzu interesgarri aukeratu ditut.
Zerbitzariaren optimizazioa. Gorpuzketa fisikoa duten hodei iragankorrak: datu-zentro fisikoak, non zerbitzari fisikoak dauden, argiekin burrunba, berotzen eta keinu egiten dutenak.
Zerbitzaririk gabeko funtzioak (Lambda) hodeiko zerbitzu eskalagarriena da.
Datu-basearen eskalatzea. Gure datu-base eskalagarriak nola eraikitzen ditugun azalduko dizut.
Sarearen eskalatzea. Gure sareko gailua irekiko dudan azken zatia. Gauza zoragarria da - hodeiko erabiltzaile bakoitzak hodeian bakarrik dagoela uste du eta ez dituela beste maizterrak batere ikusten.
Ohar. Artikulu honetan zerbitzariaren optimizazioa eta datu-baseen eskalatzea eztabaidatuko da. Hurrengo artikuluan sarearen eskalatzea aztertuko dugu. Non daude zerbitzaririk gabeko funtzioak? Beraiei buruz aparteko transkripzio bat argitaratu zen "" Hainbat eskalatze-metodoi buruz hitz egiten du eta Firecracker irtenbidea zehatz-mehatz eztabaidatzen du - makina birtual baten eta edukiontzien ezaugarri onenen sinbiosia.
Zerbitzariak
Hodeia iragankorra da. Baina efimero honek oraindik ere gorpuzte fisiko bat du: zerbitzariak. Hasieran, haien arkitektura klasikoa zen. x86 chipset estandarra, sare-txartelak, Linux, Xen hipervisorea zeinetan makina birtualak exekutatzen ziren.
2012an, arkitektura honek nahiko ondo egin zien aurre bere zereginei. Xen hipervisor bikaina da, baina eragozpen handi bat du. Nahikoa dauka Gailuaren emulaziorako gastu handia. Sareko txartel edo SSD unitate berriak eta azkarragoak eskuragarri dauden heinean, gainkostu hori handiegia bihurtzen da. Nola aurre egin arazo honi? Bi frontetan aldi berean lan egitea erabaki genuen - optimizatu bai hardwarea bai hipervisora. Zeregin oso serioa da.
Hardwarea eta hipervisorea optimizatzea
Dena aldi berean egiteak eta ondo egiteak ez du balio izango. Zer "ona" zen ere ez zegoen argi hasieran.
Ikuspegi ebolutiboa hartzea erabaki genuen: arkitekturaren elementu garrantzitsu bat aldatzen dugu eta ekoizpenera botatzen dugu.
Rake bakoitza zapaltzen dugu, kexak eta iradokizunak entzuten ditugu. Ondoren, beste osagai bat aldatuko dugu. Beraz, zati txikietan, arkitektura osoa errotik aldatzen dugu erabiltzaileen eta laguntzaren iritzian oinarrituta.
Eraldaketa 2013an hasi zen gauzarik konplexuenarekin: sarea. IN С3 kasuetan, Network Accelerator txartel berezi bat gehitu zitzaion sare-txartel estandarrari. Literalki konektatu zen aurreko panelean loopback kable labur batekin. Ez da polita, baina ez da hodeian ikusten. Baina hardwarearekin zuzeneko interakzioak funtsean hobetu zituen jitter eta sarearen transmisioa.
Ondoren, datuen biltegiratze blokeatzeko sarbidea hobetzea erabaki genuen EBS - Elastic Block Storage. Sarearen eta biltegiaren konbinazioa da. Zailtasuna da Network Accelerator txartelak merkatuan zeuden bitartean, ez zegoen aukerarik Storage Accelerator hardwarea erosteko. Beraz, startup batera jo genuen Annapurna Labs, ASIC txip bereziak garatu zigun. Urrutiko EBS bolumenak NVMe gailu gisa muntatzea baimendu zuten.
Kasuetan C4 bi arazo konpondu ditugu. Lehena da etorkizuneko etorkizunerako oinarri bat ezarri genuela, baina garai hartan berria, NVMe teknologia. Bigarrenik, prozesadore zentrala nabarmen deskargatu genuen EBSra eskaeren prozesamendua txartel berri batera transferituz. Ondo atera zen, beraz, orain Annapurna Labs Amazonen parte da.
2017ko azarorako, hipervisorea bera aldatzeko garaia zela konturatu ginen.
Hipervisor berria KVM kernel-modulu aldatuetan oinarrituta garatu zen.
Gailuaren emulazioaren gainkostua murriztea eta ASIC berriekin zuzenean lan egitea ahalbidetu zuen. Instantziak С5 hipervisor berri bat kaputxa azpian exekutatzen zuten lehen makina birtualak izan ziren. Izena jarri genion Nitro.
Instantziaren bilakaera denbora-lerroan.
2017ko azaroaz geroztik agertu diren makina birtual mota berri guztiak hipervisor honetan exekutatzen dira. Bare Metal instantziak ez dute hipervisorerik, baina Nitro ere deitzen zaie, Nitro txartel espezializatuak erabiltzen baitituzte.
Hurrengo bi urteetan, Nitro instantzia motak pare bat dozena gainditu zituen: A1, C5, M5, T3 eta beste batzuk.
Instantzia motak.
Nola funtzionatzen duten Nitro makina modernoak
Hiru osagai nagusi dituzte: Nitro hipervisorea (goian aztertua), segurtasun txipa eta Nitro txartelak.
Segurtasun txipa zuzenean plakan integratuta. Funtzio garrantzitsu asko kontrolatzen ditu, hala nola OS ostalariaren karga kontrolatzea.
Nitro txartelak - Lau mota daude. Horiek guztiak Annapurna Labs-ek garatu ditu eta ASIC arruntetan oinarritzen dira. Haien firmware batzuk ere ohikoak dira.
Lau Nitro txartel mota.
Txarteletako bat lan egiteko diseinatuta dago sareaVPC. Hau da makina birtualetan sare-txartel gisa ikusten dena ENA - Sare egokitzaile elastikoa. Sare fisiko baten bidez transmititzean trafikoa ere kapsulatzen du (artikuluaren bigarren zatian hitz egingo dugu horretaz), Segurtasun Taldeen suebakia kontrolatzen du eta bideratzeaz eta sareko beste gauzez arduratzen da.
Aukeratutako txartelak blokeen biltegiratzearekin funtzionatzen dute EBS eta zerbitzarian eraikitako diskoak. Makina birtual gonbidatuari bezala agertzen dira NVMe egokigailuak. Datuen enkriptatzeaz eta diskoaren monitorizazioaz ere arduratzen dira.
Nitro txartelen sistema, hipervisor eta segurtasun-txipa SDN sare batean integratuta dago edo Software Definitutako Sarea. Sare hau kudeatzeko arduraduna (Kontrol Plana) kontroladore txartela.
Jakina, ASIC berriak garatzen jarraitzen dugu. Esaterako, 2018 amaieran Inferentia txipa kaleratu zuten, ikaskuntza automatikoko atazekin modu eraginkorragoan lan egiteko aukera ematen duena.
Inferentia Machine Learning Prozesadorearen txipa.
Datu-base eskalagarria
Datu-base tradizionalak geruzadun egitura du. Asko sinplifikatzeko, honako maila hauek bereizten dira.
- SQL — Bezeroek eta eskaera bidaltzaileek lan egiten dute.
- Xedapenak transakzioak - Hemen dena argi dago, ACID eta guzti.
- cachean gordetzea, buffer igerilekuek eskaintzen dutena.
- Erregistratzea — Berregin erregistroekin lana eskaintzen du. MySQL-n Bin Logs deitzen zaie, PosgreSQL - Write Ahead Logs (WAL)-en.
- biltegiratze – zuzeneko grabaketa diskora.
Geruzatutako datu-baseen egitura.
Datu-baseak eskalatzeko modu desberdinak daude: sharding, Shared Nothing arkitektura, partekatutako diskoak.
Hala ere, metodo hauek guztiek datu-basearen egitura monolitiko bera mantentzen dute. Horrek nabarmen mugatzen du eskalatzea. Arazo hau konpontzeko, gure datu-base propioa garatu dugu - Amazon Aurora. MySQL eta PostgreSQL-ekin bateragarria da.
Amazon Aurora
Ideia arkitektoniko nagusia biltegiratze- eta erregistro-mailak datu-base nagusitik bereiztea da.
Aurrera begira, caching maila ere independente egin dugula esango dut. Arkitekturak monolito izateari uzten dio, eta askatasun gradu gehigarriak lortzen ditugu bloke indibidualak eskalatzean.
Erregistro- eta biltegiratze-mailak datu-basetik bereizita daude.
DBMS tradizional batek biltegiratze sistema batean datuak idazten ditu bloke moduan. Amazon Auroran, hizkuntza hitz egin dezakeen biltegiratze adimenduna sortu dugu berregin-erregistroak. Barruan, biltegiratzeak erregistroak datu-bloke bihurtzen ditu, haien osotasuna kontrolatzen du eta automatikoki babeskopia egiten du.
Planteamendu honek gauza interesgarriak gauzatzeko aukera ematen du klonazioa. Funtsean azkarrago eta ekonomikoago funtzionatzen du, datu guztien kopia osoa sortzea behar ez duelako.
Biltegiratze-geruza sistema banatu gisa ezartzen da. Zerbitzari fisiko kopuru oso handiz osatuta dago. Redo log bakoitza aldi berean prozesatzen eta gordetzen da sei korapilo. Horrek datuen babesa eta karga orekatzea bermatzen du.
Irakurketa eskalatzea erreplika egokiak erabiliz lor daiteke. Biltegiratze banatuak datu-basearen instantzia nagusiaren eta gainerako errepliken arteko sinkronizazio beharra ezabatzen du, horren bidez datuak idazten ditugun. Datu eguneratuak erreplika guztien eskura egongo direla bermatuta dago.
Arazo bakarra irakurritako errepliketan datu zaharrak gordetzea da. Baina arazo hau konpontzen ari da redo log guztien transferentzia barne sarearen bidezko errepliketara. Erregistroa cachean badago, oker gisa markatu eta gainidatzita dago. Cachean ez badago, baztertu besterik ez dago.
Biltegia antolatu dugu.
Nola eskalatu DBMS mailak
Hemen, eskalatze horizontala askoz zailagoa da. Goazen beraz bidegorritik behera eskalatze bertikal klasikoa.
Demagun nodo nagusi baten bidez DBMSarekin komunikatzen den aplikazio bat dugula.
Bertikalean eskalatzean, prozesadore eta memoria gehiago izango dituen nodo berri bat esleitzen dugu.
Ondoren, aplikazioa nodo nagusi zaharretik berrira aldatuko dugu. Arazoak sortzen dira.
- Horrek aplikazioaren geldialdi garrantzitsua eskatuko du.
- Nodo nagusi berriak cache hotza izango du. Datu-basearen errendimendua maximoa izango da cachea berotu ondoren soilik.
Nola hobetu egoera? Konfiguratu proxy bat aplikazioaren eta nodo nagusiaren artean.
Zer emango digu honek? Orain aplikazio guztiak ez dira eskuz nodo berrira birbideratu behar. Aldaketa proxy baten bidez egin daiteke eta funtsean azkarragoa da.
Badirudi arazoa konponduta dagoela. Baina ez, oraindik cachea berotzeko beharra pairatzen dugu. Horrez gain, arazo berri bat agertu da - orain proxy-a porrot-puntu bat da.
Amazon Aurora zerbitzaririk gabeko azken irtenbidea
Nola konpondu genituen arazo hauek?
Proxy bat utzi du. Hau ez da aparteko instantzia bat, aplikazioak datu-basera konektatzen diren proxy flota oso banatua baizik. Porrotaren kasuan, nodoren bat ia berehala ordezkatu daiteke.
Tamaina ezberdinetako nodo epelen multzoa gehitu da. Hori dela eta, tamaina handiagoko edo txikiagoko nodo berri bat esleitzea beharrezkoa bada, berehala dago eskuragarri. Ez da kargatu arte itxaron behar.
Eskalatze-prozesu osoa monitorizazio-sistema berezi batek kontrolatzen du. Monitorizazioak etengabe kontrolatzen du uneko nodo nagusiaren egoera. Adibidez, prozesadorearen karga balio kritiko batera iritsi dela hautematen badu, instantzia beroen multzoari nodo berri bat esleitu beharraren berri ematen dio.
Proxy banatuak, instantzia beroak eta jarraipena.
Beharrezko potentzia duen nodo bat dago eskuragarri. Buffer igerilekuak bertan kopiatzen dira, eta sistema aldatzeko une seguru baten zain hasten da.
Normalean aldatzeko unea nahiko azkar etortzen da. Ondoren, proxyaren eta nodo nagusi zaharraren arteko komunikazioa eten egiten da, saio guztiak nodo berrira aldatzen dira.
Datu-basearekin lan egiteko curriculumak.
Grafikoak erakusten du suspentsioa oso laburra dela. Grafiko urdinak karga erakusten du, eta urrats gorriak eskalatze uneak. Grafiko urdinean epe laburreko jaitsierak atzerapen labur hori dira, hain zuzen.
Bide batez, Amazon Aurorak dirua guztiz aurrezteko eta datu-basea desaktibatzeko aukera ematen du erabiltzen ez denean, adibidez, asteburuetan. Karga gelditu ondoren, DB pixkanaka bere potentzia murrizten du eta denbora pixka bat itzaltzen da. Karga itzultzen denean, leunki igoko da berriro.
Amazon gailuari buruzko istorioaren hurrengo zatian sarearen eskalatzeari buruz hitz egingo dugu. Harpidetu eta adi egon artikulua galdu ez dezazun.
On Vasily Pantyukhinek txosten bat emango du "" Amazoneko garatzaileek sistema banatuetarako zer diseinu-eredu erabiltzen dituzten, zeintzuk diren zerbitzuen hutsegiteen arrazoiak, zer den Cell-en oinarritutako arkitektura, Constant Work, Shuffle Sharding - interesgarria izango da. Konferentziarako hilabete baino gutxiago falta da - . Urriaren 24ko prezioen behin betiko igoera.
Iturria: www.habr.com