Wolken binne as in magyske doaze - jo freegje wat jo nedich binne, en de boarnen ferskine gewoan út it neat. Firtuele masines, databases, netwurk - dit alles is allinich foar jo. D'r binne oare wolkenhierders, mar yn jo Universe binne jo de ienige hearsker. Jo binne der wis fan dat jo altyd de nedige boarnen krije, jo nimme gjinien yn 'e rekken en jo bepale selsstannich hoe't it netwurk sil wêze. Hoe wurket dizze magy dy't makket dat de wolk elastysk boarnen allocearje en hierders folslein fan elkoar isolearje?
De AWS-wolk is in mega-super kompleks systeem dat sûnt 2006 evolúsjonêr evoluearre is. In part fan dizze ûntwikkeling hat plakfûn Vasily Pantyukhin - Amazon Web Services Architect. As arsjitekt krijt er net allinnich in blik fan binnen op it einresultaat, mar ek op de útdagings dy't AWS oerwint. Hoe grutter it begryp fan hoe't it systeem wurket, hoe grutter it fertrouwen. Dêrom sil Vasily de geheimen fan AWS-wolktsjinsten diele. Hjirûnder is it ûntwerp fan fysike AWS-tsjinners, elastyske databankskalberens, in oanpaste Amazon-database en metoaden foar it fergrutsjen fan de prestaasjes fan firtuele masines, wylst se tagelyk har priis ferminderje. Kennis fan Amazon's arsjitektoanyske oanpak sil jo helpe om AWS-tsjinsten effektiver te brûken en kin jo nije ideeën jaan foar it bouwen fan jo eigen oplossingen.
Oer de sprekker: Vasily Pantyukhin () begon as Unix-admin by .ru-bedriuwen, wurke oan grutte Sun Microsystem-hardware foar 6 jier, en preke in data-sintraal wrâld by EMC foar 11 jier. It evoluearre fansels ta privee wolken, en yn 2017 ferhuze nei iepenbiere. No jout hy technysk advys om te helpen wenjen en ûntwikkeljen yn 'e AWS-wolk.
Disclaimer: alles hjirûnder is de persoanlike miening fan Vasily en kin net oerienkomme mei de posysje fan Amazon Web Services. It rapport wêrop it artikel is basearre is beskikber op ús YouTube-kanaal.
Wêrom praat ik oer it Amazon-apparaat?
Myn earste auto hie in hânmjittich oerdracht. It wie geweldich fanwege it gefoel dat ik de auto koe ride en der folsleine kontrôle oer ha. Ik mocht ek graach dat ik op syn minst rûchwei it prinsipe fan syn wurking begrepen. Natuerlik stelde ik my foar dat de struktuer fan 'e doaze frij primityf wie - sa'n ding as in gearbox op in fyts.
Alles wie geweldich, útsein ien ding - fêst yn files. It liket derop dat jo sitte en neat dogge, mar jo wikselje hieltyd gear, drukke op 'e koppeling, gas, rem - it makket jo echt wurch. It fileprobleem wie foar in part oplost doe't it gesin in automatyske auto krige. Under it riden hie ik tiid om wat nei te tinken en nei in harkboek te harkjen.
In oar mystearje ferskynde yn myn libben, om't ik folslein stopte te begripen hoe't myn auto wurket. In moderne auto is in kompleks apparaat. De auto past him tagelyk oan tsientallen ferskillende parameters: gasdruk, rem, rydstyl, dykkwaliteit. Ik begryp net mear hoe't it wurket.
Doe't ik begon te wurkjen oan 'e Amazon-wolk, wie it ek in mystearje foar my. Allinnich dit mystearje is in folchoarder fan grutte grutter, om't d'r ien bestjoerder yn 'e auto sit, en yn AWS binne d'r miljoenen. Alle brûkers tagelyk stjoere, druk op it gas en rem. It is geweldich dat se gean wêr't se wolle - it is in wûnder foar my! It systeem past him automatysk oan, skaleart en elastysk oan elke brûker oan, sadat it him liket dat hy allinich is yn dit Universum.
De magy sloech wat ôf doe't ik letter as arsjitekt by Amazon kaam te wurkjen. Ik seach hokker problemen wy tsjinkomme, hoe't wy se oplosse, en hoe't wy tsjinsten ûntwikkelje. Mei tanimmend begryp fan hoe't it systeem wurket, ferskynt mear fertrouwen yn 'e tsjinst. Dat ik wol in foto diele fan wat der ûnder de motorkap fan 'e AWS-wolk is.
Wat sille wy prate oer
Ik keas in ferskaat oanpak - ik selektearre 4 nijsgjirrige tsjinsten dy't it wurdich binne te praten oer.
Server optimalisaasje. Efemere wolken mei in fysike belichaming: fysike datasintra wêr't fysike servers binne dy't bromje, ferwaarme en blinkje mei ljochten.
Serverless funksjes (Lambda) is wierskynlik de meast skaalbere tsjinst yn 'e wolk.
Databank skaalfergrutting. Ik sil jo fertelle hoe't wy ús eigen skaalbere databases bouwe.
Netwurk skaalfergrutting. It lêste diel wêryn ik it apparaat fan ús netwurk sil iepenje. Dit is in prachtich ding - elke wolkbrûker leaut dat hy allinich yn 'e wolk is en oare hierders hielendal net sjocht.
Noat. Dit artikel sil tsjinneroptimalisaasje en databankskalearring besprekke. Wy sille netwurkskalearring beskôgje yn it folgjende artikel. Wêr binne de serverless funksjes? In apart transkripsje waard publisearre oer harren "" It praat oer ferskate ferskillende skaalmetoaden, en besprekt yn detail de Firecracker-oplossing - in symbioaze fan 'e bêste kwaliteiten fan in firtuele masine en konteners.
Tsjinners
De wolk is ephemeral. Mar dizze ephemeraliteit hat noch in fysike belichaming - tsjinners. Yn it earstoan wie har arsjitektuer klassyk. Standert x86-chipset, netwurkkaarten, Linux, Xen-hypervisor wêrop firtuele masines waarden útfierd.
Yn 2012, dizze arsjitektuer koe goed mei syn taken. Xen is in geweldige hypervisor, mar it hat ien grutte nadeel. Hy hat genôch hege overhead foar apparaat emulaasje. As nije, rappere netwurkkaarten of SSD-skiven beskikber wurde, wurdt dizze overhead te heech. Hoe om te gean mei dit probleem? Wy besletten om op twa fronten tagelyk te wurkjen - optimisearje sawol hardware as hypervisor. De taak is tige serieus.
Optimalisearjen fan hardware en hypervisor
Alles tagelyk dwaan en it goed dwaan sil net wurkje. Wat "goed" wie wie ynearsten ek ûndúdlik.
Wy besletten in evolúsjonêre oanpak te nimmen - wy feroarje ien wichtich elemint fan 'e arsjitektuer en smite it yn produksje.
Wy stappe op elke rake, harkje nei klachten en suggestjes. Dan feroarje wy in oare komponint. Dat, yn lytse stappen, feroarje wy de heule arsjitektuer radikaal op basis fan feedback fan brûkers en stipe.
De transformaasje begon yn 2013 mei it meast komplekse ding - it netwurk. YN С3 eksimplaren, in spesjale Network Accelerator card waard tafoege oan de standert netwurk card. It waard letterlik ferbûn mei in koarte loopback kabel op de foarkant paniel. It is net moai, mar it is net sichtber yn 'e wolk. Mar direkte ynteraksje mei hardware ferbettere jitter en netwurk trochfier.
Folgjende wy besletten om te ferbetterjen tagong ta blokkearjen gegevens opslach EBS - Elastic Block Storage. It is in kombinaasje fan netwurk en opslach. De muoite is dat wylst Network Accelerator-kaarten op 'e merke bestienen, d'r gjin opsje wie om gewoan Storage Accelerator-hardware te keapjen. Dus wy kearden ta in opstarten Annapurna Labs, dy't spesjale ASIC-chips foar ús ûntwikkele. Se lieten EBS-voluminten op ôfstân monteare as NVMe-apparaten.
Yn gefallen C4 wy hawwe twa problemen oplost. De earste is dat wy in stifting ymplementearre foar de takomst fan belofte, mar nij op dat stuit, NVMe-technology. As twadde hawwe wy de sintrale prosessor signifikant loslitten troch de ferwurking fan oanfragen nei EBS oer te setten nei in nije kaart. It die goed út, dus no is Annapurna Labs diel fan Amazon.
Tsjin novimber 2017 realisearre wy dat it tiid wie om de hypervisor sels te feroarjen.
De nije hypervisor waard ûntwikkele basearre op wizige KVM kernel modules.
It makke it mooglik om de overhead fan apparaatemulaasje fûneminteel te ferminderjen en direkt te wurkjen mei nije ASIC's. Instances С5 wiene de earste firtuele masines mei in nije hypervisor rinnen ûnder de motorkap. Wy neamden him Nitro.
Evolúsje fan eksimplaren op 'e tiidline.
Alle nije soarten firtuele masines dy't sûnt novimber 2017 binne ferskynd rinne op dizze hypervisor. Bare Metal-eksimplaren hawwe gjin hypervisor, mar se wurde ek neamd Nitro, sûnt se brûke spesjalisearre Nitro cards.
Yn 'e kommende twa jier is it oantal soarten Nitro-eksimplaren mear as in pear tsientallen: A1, C5, M5, T3 en oaren.
Instance types.
Hoe moderne Nitro-masines wurkje
Se hawwe trije haadkomponinten: de Nitro-hypervisor (hjirboppe besprutsen), de feiligenschip en de Nitro-kaarten.
Feiligens chip yntegrearre direkt yn it moederbord. It kontrolearret in protte wichtige funksjes, lykas it kontrolearjen fan it laden fan it host OS.
Nitro kaarten - Der binne fjouwer soarten fan. Allegear binne ûntwikkele troch Annapurna Labs en binne basearre op mienskiplike ASIC's. Guon fan har firmware is ek gewoan.
Fjouwer soarten Nitro kaarten.
Ien fan de kaarten is ûntwurpen om te wurkjen mei netwurkVPC. Dit is wat sichtber is yn firtuele masines as in netwurkkaart ENA - Elastyske netwurkadapter. It omfettet ek ferkear by it ferstjoeren fan it fia in fysyk netwurk (wy sille hjir oer prate yn it twadde diel fan it artikel), kontrolearret de Firewall fan Security Groups, en is ferantwurdlik foar routing en oare netwurk dingen.
Selektearje kaarten wurkje mei blok opslach EBS en skiven dy't binne ynboud yn de tsjinner. Se ferskine oan de gast firtuele masine as NVMe-adapters. Se binne ek ferantwurdlik foar gegevensfersifering en skiifmonitoring.
It systeem fan Nitro cards, hypervisor en feiligens chip wurdt yntegrearre yn in SDN netwurk of Software Defined Network. Ferantwurdlik foar it behearen fan dit netwurk (Control Plane) controller card.
Fansels bliuwe wy nije ASIC's ûntwikkelje. Bygelyks, oan 'e ein fan 2018 hawwe se de Inferentia-chip frijlitten, wêrtroch jo effisjinter kinne wurkje mei masine-leartaken.
Inferentia Machine Learning Processor-chip.
Scalable Database
In tradisjonele databank hat in lagen struktuer. Om sterk te ferienfâldigjen, wurde de folgjende nivo's ûnderskieden.
- SQL - klant en fersyk dispatchers wurkje oan it.
- Bepalingen transaksjes - hjir is alles dúdlik, ACID en dat alles.
- caching, dat wurdt fersoarge troch buffer pools.
- Logging - leveret wurk mei opnij logs. Yn MySQL wurde se Bin Logs neamd, yn PosgreSQL - Write Ahead Logs (WAL).
- Storage - direkte opname op skiif.
Layered databank struktuer.
D'r binne ferskate manieren om databases te skaaljen: sharding, Shared Nothing-arsjitektuer, dielde skiven.
Al dizze metoaden behâlde lykwols deselde monolityske databankstruktuer. Dit beheint skaalfergrutting signifikant. Om dit probleem op te lossen, hawwe wy ús eigen databank ûntwikkele - Amazon Aurora. It is kompatibel mei MySQL en PostgreSQL.
Amazon Aurora
It wichtichste arsjitektoanyske idee is om de opslach- en lognivo's te skieden fan 'e haaddatabase.
Foarútsjen sil ik sizze dat wy it cachingnivo ek ûnôfhinklik makken. De arsjitektuer hâldt op in monolyt te wêzen, en wy krije ekstra graden fan frijheid by it skaalfergrutting fan yndividuele blokken.
De log- en opslachnivo's binne apart fan 'e databank.
In tradisjonele DBMS skriuwt gegevens nei in opslachsysteem yn 'e foarm fan blokken. By Amazon Aurora hawwe wy tûke opslach makke dy't taal kin prate opnij-logs. Binnen feroaret de opslach logs yn gegevensblokken, kontrolearret har yntegriteit en makket automatysk reservekopy.
Dizze oanpak kinne jo útfiere sokke nijsgjirrige dingen as kloning. It wurket fûneminteel rapper en ekonomysk fanwege it feit dat it net nedich is om in folsleine kopy fan alle gegevens te meitsjen.
De opslachlaach wurdt ymplementearre as in ferspraat systeem. It bestiet út in heul grut oantal fysike servers. Elk redo-log wurdt tagelyk ferwurke en bewarre seis knopen. Dit soarget foar gegevensbeskerming en load balancing.
Lês skaalfergrutting kin berikt wurde mei passende replika's. Ferspraat opslach elimineert de needsaak foar syngronisaasje tusken de haaddatabase-eksimplaar, wêrmei wy gegevens skriuwe, en de oerbleaune replika's. Aktuele gegevens wurde garandearre beskikber foar alle replika's.
It ienige probleem is it cache fan âlde gegevens op reade replika's. Mar dit probleem wurdt oplost oerdracht fan alle redo logs nei replika's oer it ynterne netwurk. As it log yn 'e cache is, wurdt it markearre as ferkeard en oerskreaun. As it net yn 'e cache is, wurdt it gewoan fuorthelle.
Wy sorteare de opslach út.
Hoe kinne jo DBMS-tiers skaalje
Hjir is horizontale skaalfergrutting folle dreger. Sa litte wy it paad nei ûnderen gean klassike fertikale skaalfergrutting.
Litte wy oannimme dat wy in applikaasje hawwe dy't kommunisearret mei de DBMS fia in masterknooppunt.
By fertikaal skaalfergrutting tawize wy in nije knooppunt ta dy't mear processors en ûnthâld sil hawwe.
Dêrnei wikselje wy de applikaasje fan 'e âlde masterknoop nei de nije. Problemen ûntsteane.
- Dit sil signifikante applikaasje downtime fereaskje.
- It nije masterknooppunt sil in kâlde cache hawwe. Databankprestaasjes sille allinich maksimaal wêze nei't de cache is opwaarme.
Hoe kinne jo de situaasje ferbetterje? Stel in proxy yn tusken de applikaasje en de masterknooppunt.
Wat sil dit ús jaan? No hoege alle applikaasjes net mei de hân te wurde omlaat nei it nije knooppunt. De switch kin dien wurde ûnder in proxy en is yn prinsipe flugger.
It liket derop dat it probleem is oplost. Mar nee, wy hawwe noch lêst fan de needsaak om de cache op te waarmjen. Derneist is in nij probleem ferskynde - no is de proxy in potinsjeel punt fan mislearring.
Finale oplossing mei Amazon Aurora serverless
Hoe hawwe wy dizze problemen oplost?
In proxy efterlitten. Dit is gjin aparte eksimplaar, mar in hiele ferspraat float fan proxy's troch hokker applikaasjes ferbine mei de databank. Yn gefal fan mislearring kin elk fan 'e knopen hast direkt wurde ferfongen.
In swimbad tafoege mei waarme knopen fan ferskate grutte. Dêrom, as it nedich is om in nije knooppunt fan in gruttere of lytsere grutte te tawizen, is it fuortendaliks beskikber. It is net nedich om te wachtsjen foar it laden.
It hiele skaalfergruttingsproses wurdt regele troch in spesjaal tafersjochsysteem. Monitoring kontrolearret konstant de tastân fan 'e hjoeddeistige masterknooppunt. As it bygelyks detektearret dat de prosessorlading in krityske wearde hat berikt, meldt it it swimbad fan waarme eksimplaren oer de needsaak om in nij knooppunt te tawizen.
Ferdielde proxy's, waarme eksimplaren en tafersjoch.
In knooppunt mei de fereaske krêft is beskikber. Buffer pools wurde kopiearre nei it, en it systeem begjint te wachtsjen op in feilich momint om te wikseljen.
Meastal komt it momint om te wikseljen frij fluch. Dan wurdt kommunikaasje tusken de proxy en it âlde masterknooppunt ophâlden, alle sesjes wurde oerskeakele nei de nije node.
Wurkje mei de databank opnij.
De grafyk lit sjen dat de ophinging yndie tige koart is. De blauwe grafyk toant de lading, en de reade stappen litte de skaalmominten sjen. Koarte termyn dips yn 'e blauwe grafyk binne krekt dat koarte fertraging.
Trouwens, Amazon Aurora lit jo folslein jild besparje en de databank útsette as it net yn gebrûk is, bygelyks yn it wykein. Nei it stopjen fan de lading fermindert de DB stadichoan syn krêft en wurdt in skoft útskeakele. As de lading weromkomt, komt it wer soepel omheech.
Yn it folgjende diel fan it ferhaal oer it Amazon-apparaat sille wy prate oer skaalfergrutting fan netwurken. Ynskriuwe en bliuw op 'e hichte sadat jo it artikel net misse.
op Vasily Pantyukhin sil in rapport jaan "" Hokker ûntwerppatroanen foar ferdielde systemen wurde brûkt troch Amazon-ûntwikkelders, wat binne de redenen foar tsjinstfalen, wat is Cell-basearre arsjitektuer, Constant Work, Shuffle Sharding - it sil ynteressant wêze. Minder dan in moanne oant de konferinsje - . 24. Oktober finale priisferheging.
Boarne: www.habr.com