Rekujt e ngjajnĂ« me njĂ« kuti magjike â kĂ«rkon atĂ« qĂ« tĂ« nevojitet, dhe burimet thjesht shfaqen nga askund. Makinat virtuale, databazat, rrjeti â gjithçka Ă«shtĂ« vetĂ«m pĂ«r ty. EkzistojnĂ« dhe tenanta tĂ« tjerĂ« tĂ« reve, por nĂ« universin tĂ«nd je qeveritari i vetĂ«m. Je i sigurt se gjithmonĂ« do tĂ« marrĂ«sh burimet e nevojshme, nuk ke nevojĂ« tĂ« nĂ«nshtrohesh ndaj askujt dhe pĂ«rcakton vetĂ« se si do tĂ« jetĂ« rrjeti. Si funksionon kjo magji qĂ« bĂ«n qĂ« reja tĂ« alokojĂ« burimet elastike dhe tĂ« izolojĂ« plotĂ«sisht tenantĂ«t nga njĂ«ri-tjetri?
Reva AWS Ă«shtĂ« njĂ« sistem megasuperkomplikuar, i cili evoluon qĂ« nga viti 2006. NjĂ« pjesĂ« e kĂ«tij zhvillimi ka pĂ«rfituar Vasiliy Pantyukhin â arkitekti i Amazon Web Services. Si arkitekt, ai sheh nga brenda jo vetĂ«m rezultatin pĂ«rfundimtar, por edhe sfidat qĂ« ekalon AWS. Sa mĂ« shumĂ« kuptim tĂ« ketĂ« pĂ«r funksionimin e sistemit, aq mĂ« shumĂ« besim krijohet. Prandaj, Vasili do tĂ« ndajĂ« sekretet e shĂ«rbimeve tĂ« reves AWS. PoshtĂ«, do tĂ« gjeni strukturĂ«n e serverĂ«ve fizikĂ« tĂ« AWS, elasticitetin e shkallĂ«zueshmĂ«risĂ« sĂ« DB, databazĂ«n e personalizuar Amazon dhe metodat pĂ«r rritjen e performancĂ«s sĂ« makinave virtuale pĂ«rkrah uljes sĂ« çmimit tĂ« tyre. Njohja e qasjes arkitektonike tĂ« Amazon do tĂ« ndihmojĂ« nĂ« pĂ«rdorimin mĂ« efektiv tĂ« shĂ«rbimeve AWS dhe ndoshta do tĂ« ofrojĂ« ide tĂ« reja pĂ«r ndĂ«rtimin e zgjidhjeve tuaja.
Rreth folësit: Vasili Pantiukhin () filloi si Unix admin në kompanitë.ru, për 6 vjet u angazhua me pajisje të mëdha Sun Microsystem, dhe për 11 vjet predikoi qendrueshmërinë e të dhënave në EMC. Në mënyrë natyrale evolucionoi në re private, dhe në vitin 2017 kaloi në ato publike. Tani, me këshilla teknike ndihmon për të jetuar dhe zhvilluar në re AWS.
Disclaimër: gjithçka më poshtë është mendimi personal i Vasilit dhe mund të mos përputhet me pozitat e Amazon Web Services. i referatit, mbi të cilin është krijuar ky artikull, është i disponueshëm në kanalin tonë YouTube.
Pse po flas për thelbin e Amazon
Makina ime e parĂ« kishte "dorĂ«" â me transmetim mekanik. Ishte e shkĂ«lqyer pĂ«r ndjesinĂ« se mund ta kontrolloja makinĂ«n dhe ta menaxhoja plotĂ«sisht. MĂ« pĂ«lqente gjithashtu se tĂ« paktĂ«n e kuptoja nĂ« njĂ« farĂ« mĂ«nyre principin e funksionimit tĂ« saj. Sigurisht, e pĂ«rfytyroja funksionimin e kutisĂ« mjaft primitivisht â diku si njĂ« kuti shpejtĂ«sie nĂ« biçikletĂ«.
E gjitha ishte e shkĂ«lqyer, pĂ«rveç njĂ« gjĂ«je â qĂ«ndrimit nĂ« trafik. Siç duket, ulur dhe nuk bĂ«j asgjĂ«, por vazhdimisht kaloj nĂ« ingranazhe, shtyp frikĂ«n, gazin, frenin â nga kjo, ndiej vĂ«rtet lodhje. Problemi i trafikut u zgjidh pjesĂ«risht kur nĂ« familje erdhi njĂ« makinĂ« automatike. Pas timonit, pati kohĂ« tĂ« mendoj pĂ«r diçka, tĂ« dĂ«gjoj njĂ« audioklibĂ«r.
NjĂ« mister tjetĂ«r u shfaq nĂ« jetĂ«n time, sepse unĂ« sapo ndalova sĂ« kuptuari si funksionon makina ime. NjĂ« makinĂ« moderne â Ă«shtĂ« njĂ« pajisje e ndĂ«rlikuar. Ajo adaptohet nĂ« tĂ« njĂ«jtĂ«n kohĂ« ndaj dhjetra parametrave tĂ« ndryshĂ«m: shtypi mbi gaz, fren, stili i vozitjes, cilĂ«sia e rrugĂ«s. UnĂ« s'po e kuptoj mĂ« se si funksionon kjo.
Kur fillova tĂ« merrem me Amazon Cloud, kjo ishte gjithashtu njĂ« mister pĂ«r mua. Por ky mister Ă«shtĂ« njĂ« shkallĂ« mĂ« i lartĂ«, sepse nĂ« makinĂ« ka njĂ« shofer, ndĂ«rsa nĂ« AWS janĂ« miliona. TĂ« gjithĂ« pĂ«rdoruesit drejtojnĂ« nĂ« tĂ« njĂ«jtĂ«n kohĂ«, shtypin gazin dhe frenin. ĂshtĂ« e mrekullueshme qĂ« ata arrijnĂ« atje ku duan â pĂ«r mua, kjo Ă«shtĂ« njĂ« mrekulli! Sistemi adaptohet automatikisht, shkallĂ«zohet dhe pĂ«rshtatet elastikisht me secilin pĂ«rdorues, aq sa ai mendon se Ă«shtĂ« vetĂ«m nĂ« kĂ«tĂ« Univers.
Magjia paksa u shpërbë kur më vonë erdha të punoj si arkitekt në Amazon. Pashë përballjet që kishim, si i zgjidhim ato, si zhvillojmë shërbimet. Me rritjen e kuptimit të funksionimit të sistemit, rritet besimi në shërbim. Prandaj, dëshiroj të ndaj pamjen e asaj që ndodhet nën kapakët e AWS Cloud.
Për çfarë do të flasim
Kam zgjedhur njĂ« qasje diversifikuar â kam pĂ«rzgjedhur 4 shĂ«rbime interesante, pĂ«r tĂ« cilat ia vlen tĂ« flasim.
Optimizimi i serverëve. Cloud-et efemer me përmasat fizike: qendrat e të dhënave fizike, ku janë serverë fizikë, që zhurmojnë, ngrohen dhe ndriçohen me ndriçim.
Funksionet Serverless (Lambda) â ndoshta shĂ«rbimi mĂ« i shkallĂ«zuar nĂ« cloud.
Shkëmbimi i bazës së të dhënave. Do të flas për mënyrën se si ndërtuam bazat tona të dhënash të shkallëzuara.
ShkallĂ«zimi i rrjetit. Pjesa e fundit, ku do tĂ« zbuloj ndĂ«rtimin e rrjetit tonĂ«. Kjo Ă«shtĂ« njĂ« gjĂ« e mrekullueshme â çdo pĂ«rdorues i cloud mendon se Ă«shtĂ« vetĂ«m nĂ« cloud dhe nuk e sheh fare tĂ« tjerĂ«t.
Shënim. Në këtë artikull do të flasim për optimizimin e serverëve dhe zgjerimin e bazave të dhënash. Zgjerimi i rrjetit do të shqyrtohet në artikullin tjetër. Ku janë funksionet serverless? Për to është publikuar një shpjegim i veçantë "'. Në të ndodhen disa metoda të ndryshme të zgjerimit, dhe zgjidhja Firecracker është shqyrtuar në detaje - një simbiozë e cilësive më të mira të makinave virtuale dhe konteinerëve.
Serverët
Revolucioni i cloud-it Ă«shtĂ« efemer. Por kjo efemeritet ka njĂ« manifestim fizik - serverĂ«t. Fillimisht, arkitektura e tyre ishte klasike. Ăipseti standard x86, kartat e rrjetit, Linux, hipervizori Xen, mbi tĂ« cilin funksiononin makinat virtuale.
Në vitin 2012, një arkitekturë e tillë arrinte të përballonte detyrat e saj. Xen është një hipervizor i shkëlqyer, por ka një disavantazh të rëndësishëm. Ai ka shpenzime të larta për emulimin e pajisjeve. Me daljen në treg të kartave të reja rrjeti më të shpejta ose diskëve SSD, këto shpenzime bëhen tepër të larta. Si mund ta zgjidhim këtë problem? Vendosëm të punojmë në dy fronte - optimizimin e harduerit dhe hipervizorit. Kjo është një detyrë shumë e rëndësishme.
Optimizimi i harduerit dhe hipervizorit
TĂ« bĂ«sh gjithçka njĂ«herĂ«sh dhe mirĂ« nuk do tĂ« funksionojĂ«. ĂfarĂ« Ă«shtĂ« "mirĂ«", fillimisht gjithashtu ishte e paqartĂ«.
Vendosëm të përdorim një qasje evolucionare - të ndryshojmë një element të rëndësishëm të arkitekturës dhe ta hedhim atë në prodhim.
Kërkojmë të përballojmë çdo pengesë, dëgjojmë ankesat dhe sugjerimet. Pastaj ndryshojmë një tjetër komponent. Kështu, me inkrementime të vogla, transformojmë tërë arkitekturën bazuar në reagimet nga përdoruesit dhe mbështetjen.
Transformimet filluan në vitin 2013 me më të vështirën - rrjetin. Në C3 instancat, karta standarde e rrjetit u shtua me një kartë speciale Network Accelerator. Ajo u lidh literalisht me një kabllo loopback në panelin e përparmë. E shëmtuar, por në cloud nuk duket. Megjithatë, ndërveprimi direkt me harduerin përmirësoi ndjeshëm jitter-in dhe kapacitetin e rrjetit.
Më pas u vendos të përmirësojmë qasjen në ruajtjen e dhënave EBS - Elastic Block Storage. Kjo është një kombinim i rrjetit dhe magazinimit. Sfidë është se nëse në treg ekzistonin karta Network Accelerator, mundësia për të blerë harduerin Storage Accelerator nuk kishte. Prandaj, ne iu drejtua një startup-i Annapurna Labs, e cila zhvilloi për ne çipa të specializuar ASIC. Këta lejuan lidhjen e volumeve të largëta EBS si pajisje NVMe.
NĂ« instancat C4 ne zgjodhĂ«m dy sfida. E para â realizuam njĂ« plan tĂ« ardhshĂ«m pĂ«r teknologjinĂ« e re NVMe. E dyta â ndjeshĂ«m ngarkuam procesorin qendror duke transferuar pĂ«rpunimin e kĂ«rkesave pĂ«r EBS nĂ« njĂ« kartĂ« tĂ« re. Doli mirĂ«, prandaj tani Annapurna Labs â Ă«shtĂ« pjesĂ« e Amazon.
Në nëntor të vitit 2017, ne kuptuam se erdhi koha për të ndryshuar edhe hipervizorin.
Hipervizori i ri u zhvillua mbi bazën e moduleve të përmirësuara të bërthamës KVM.
Ai lejon të reduktohen ndjeshëm kostot për emulimin e pajisjeve dhe të punojë direkt me ASIC-të e rinj. Instancat C5 ishtë virtualizimi i parë, nën kapuçin e të cilit punon hipervizori i ri. Ne e quajtëm atë Nitro.
Evolucioni i instancave në një shkallë kohore.
Të gjitha llojet e reja të makinave virtuale që u shfaqën që nga nëntori 2017, punojnë mbi këtë hipervizor. Makinat Bare Metal nuk kanë hipervizor, por ato gjithashtu quhen Nitro, pasi ato përdorin karta të specializuara Nitro.
Në dy vitet e ardhshme, numri i llojeve të instancave Nitro tejkaloi disa dhjetëra: A1, C5, M5, T3 dhe të tjera.
Llojet e instancave.
Si janë të organizuara makinat Nitro moderne
Ato kanë tre komponentë kryesorë: hipervizorin Nitro (për të cilin u diskutua më lart), çipin e sigurisë dhe kartat Nitro.
Ăipi i sigurisĂ« Ă«shtĂ« i integruar pikĂ«risht nĂ« bord. Ai kontrollon shumĂ« funksione tĂ« rĂ«ndĂ«sishme, pĂ«r shembull, kontrollin e ngarkesĂ«s sĂ« OS-sĂ« sĂ« hostit.
Kartat Nitro - ato ekzistojnë në katër lloje. Të gjitha janë zhvilluar nga Annapurna Labs dhe bazohen në ASIC të zakonshëm. Një pjesë e firmware-t të tyre gjithashtu është e përbashkët.
Katër lloje kartash Nitro.
NjĂ« nga kartat Ă«shtĂ« e destinuar pĂ«r tĂ« punuar me rrjetinVPC. Ajo Ă«shtĂ« e dukshme nĂ« virtualizime si karta rrjetit ENA â Adaptori i Rrjetit Elastik. Ajo gjithashtu inkapsulon trafikun gjatĂ« transmetimit pĂ«rmes rrjetit fizik (pĂ«r kĂ«tĂ« do flasim nĂ« pjesĂ«n e dytĂ« tĂ« artikullit), kontrollon Firewall grupet e SigurisĂ«, pĂ«rgjigjet pĂ«r ruterimin dhe gjĂ«ra tĂ« tjera rrjetore.
Kartat e veçanta punojnë me ruajtjen bllokuese EBS dhe diskët, të cilët janë të integruar në server. Për makinën virtuale të pritjes ato paraqiten si adaptues NVMe. Ato gjithashtu përgjigjen për enkriptimin e të dhënave dhe monitorimin e disqeve.
Sistemi i kartave Nitro, hipervizorit dhe çipit të sigurisë është i bashkuar në një rrjet SDN ose Rrjeti i Definimit të Softuerit. Për menaxhimin e këtij rrjeti (Control Plane) përgjigjet kontrolluesi i hartës.
Sigurisht, ne vazhdojmë zhvillimin e ASIC-ve të rinj. Për shembull, në fund të vitit 2018, çrelease çipi Inferentia, i cili lejon një funksionim më efikas me detyrat e mësimit të makinerive.
Ăipi Inferentia Procesori i MĂ«simit tĂ« Makinerive.
Baza e dhënash e shkallëzuar
Një bazë e dhënash tradicionale ka një strukturë të stratifikuar. Nëse e thjeshtojmë shumë, mund të identifikojmë nivelet e mëposhtme.
- SQL â nĂ« tĂ« punojnĂ« menaxherĂ«t e klientĂ«ve dhe kĂ«rkesave.
- Sigurimi i transaksioneve â kĂ«tu gjithçka Ă«shtĂ« e qartĂ«, ACID dhe gjithçka e tillĂ«.
- KeĆĄimi, e cila sigurohet nga pool-et e buffers.
- Regjistrimi â e siguron punĂ«n me redo-logĂ«t. NĂ« MySQL ata quhen Bin Logs, nĂ« PosgreSQL â Write Ahead Logs (WAL).
- Ruajtja â regjistrimi direkt nĂ« disk.
Struktura e stratifikuar e bazës së të dhënave.
K existojnë mënyra të ndryshme për të shkallëzuar bazat e të dhënave: sharding, arkitektura Shared Nothing, disqe të ndarë.
MegjithatĂ«, tĂ« gjitha kĂ«to metoda ruajnĂ« tĂ« njĂ«jtĂ«n strukturĂ« monolitike tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave. Kjo e kufizon dukshĂ«m shkallĂ«zimin. PĂ«r tĂ« zgjidhur kĂ«tĂ« problem, ne zhvilluam bazĂ«n tonĂ« tĂ« tĂ« dhĂ«nave â Amazon Aurora. Ajo Ă«shtĂ« e pĂ«rputhshme me MySQL dhe PostgreSQL.
Amazon Aurora
Ideja kryesore arkitekturore është ndarja e niveleve të ruajtjes dhe logimit nga baza e të dhënave kryesore.
Duke bërë një hap para, do të them se niveli i kesh-it po ashtu e bëmë të pavarur. Arkitektura nuk është më një monolit, dhe ne marrim gradë të reja lirie në shkallëzimin e blloqeve të ndryshme.
Nivelet e logimit dhe ruajtjes janë ndarë nga baza e të dhënave.
Një DBM tradicionale regjistron të dhënat në sistemin e ruajtjes në formë bllokesh. Në Amazon Aurora krijuam një ruajtje "inteligjente", e cila mund të flasë në gjuhën e redo-logëve. Brenda vetes, ruajtja i kthen logët në blloqe të dhënash, monitoron integritetin e tyre dhe bën automatikisht backup.
Ky qasje lejon realizimin e gjërave interesante si klonimi. Ai funksionon në mënyrë themelore më shpejt dhe më ekonomik për shkak të faktit se nuk kërkon krijimin e një kopjeje të plotë të të gjitha të dhënave.
Niveli i ruajtjes Ă«shtĂ« realizuar si njĂ« sistem tĂ« shpĂ«rndarĂ«. Ai pĂ«rbĂ«het nga njĂ« numĂ«r shumĂ« tĂ« madh serverash fizikĂ«. Ădo redo-log pĂ«rpunohen dhe ruhen nĂ« tĂ« njĂ«jtĂ«n kohĂ« nga gjashtĂ« node. Kjo siguron mbrojtjen e tĂ« dhĂ«nave dhe shpĂ«rndarjen e ngarkesĂ«s.
Mundësia e shkallëzimit në lexim mund të sigurohet me anë të replika të përshtatshme. Shtëpia e shpërndarë eleminon nevojën për sinkronizim mes instancës kryesore të DB, përmes së cilës ne regjistrojmë të dhënat, dhe llojeve të tjera të replika. Të dhënat aktuale janë garantuar qasje për të gjitha replikat.
Problemi i vetëm është ruajtja në cache e të dhënave të vjetra në replikat e leximit. Por ky problem zgjidhet duke transmetuar të gjitha log-et redo në replikat përmes rrjetit të brendshëm. Nëse log-u është në cache, ai shënohet si i pavlefshëm dhe ri-shkruhet. Nëse nuk është në cache, thjesht hidhet poshtë.
Kemi kuptuar ruajtjen.
Si të shkallëzojmë nivelet e DBMS
Këtu, shkallëzimi horizontal është shumë më i komplikuar. Prandaj, do të ndjekim një rrugë të përshkruar në shkallëzimin klasik vertikal.
Le të supozojmë se kemi një aplikacion që komunikon me DBMS përmes një node master.
Gjatë shkallëzimit vertikal, ne ndajmë një node të re, e cila do të ketë më shumë procesorë dhe memorie.
Pastaj, ne kalojmë aplikacionin nga node master e vjetër në të re. Ndodhin probleme.
- Kjo do të kërkojë një kohë të dukshme ndalimi për aplikacionin.
- Node e re master do të ketë një cache të ftohtë. Performanca e DB do të jetë maksimale vetëm pas ngrohjes së cache-it.
Si ta përmirësojmë situatën? Të vendosim një proxy mes aplikacionit dhe node master.
ĂfarĂ« na jep kjo? Tani, tĂ« gjitha aplikacionet nuk Ă«shtĂ« nevoja tâi redirectionohet manualisht nĂ« node e re. Kalimi mund tĂ« bĂ«het nĂ«n proxy dhe ndihmon qĂ« tĂ« jetĂ« thelbĂ«sisht mĂ« i shpejtĂ«.
Duket se problemi Ă«shtĂ« zgjidhur. Por jo, ne ende vuajmĂ« nga nevoja pĂ«r ngrohjen e cache-it. PĂ«r mĂ« tepĂ«r, u shfaq njĂ« problem i ri â tani proxy Ă«shtĂ« njĂ« pikĂ« potenciale dĂ«shtimi.
Zgjidhja përfundimtare me Amazon Aurora serverless
Si i zgjidhëm këto probleme?
E lĂ«mĂ« proxy-nĂ«. Ky nuk Ă«shtĂ« njĂ« instancĂ« e veçantĂ«, por njĂ« flotĂ« tĂ« tĂ«rĂ« tĂ« shpĂ«rndarĂ« proxy, pĂ«rmes sĂ« cilĂ«s aplikacionet lidhĂ«n me DB. Ădo nodĂ« nĂ« rast se del jashtĂ« funksionit mund tĂ« zĂ«vendĂ«sohet pothuajse menjĂ«herĂ«.
Shtojmë një fond të node-ve të ngrohta të madhësive të ndryshme. Prandaj, nëse është e nevojshme të alokojmë një node më të madhe apo më të vogël, ajo është menjëherë e disponueshme. Nuk është nevoja të presim që të ngarkohet.
E gjithë processi i shkallëzimit kontrollohet nga një sistem të veçantë monitorimi. Monitoring constantly checks the status of the current master node. If it detects, for example, that the CPU load has reached a critical level, it notifies the pool of warm instances about the need to allocate a new node.
Distributed proxies, warm instances, and monitoring.
A node of the required capacity is available. Buffer pools are copied to it, and the system begins to wait for a safe moment to switch.
Usually, the moment to switch occurs quite quickly. Then, communication between the proxy and the old master node is suspended, and all sessions are switched to the new node.
Work with the database resumes.
The graph shows that the pause is indeed very brief. The blue graph indicates load, and the red steps mark the scaling moments. The short dips in the blue graph are precisely that brief delay.
By the way, Amazon Aurora allows you to save significantly and turn off the database when it is not in use, for example, on weekends. After stopping, the database gradually reduces its power and turns off for a while. When the load returns, it smoothly ramps up again.
In the next part of the story about Amazon's architecture, we will talk about network scaling. Subscribe and stay updated so you don't miss the article.
NĂ« Vasily Pantyukhin will present a report titled "". What design patterns do Amazon developers use in distributed systems, what are the reasons for service failures, what is Cell-based architecture, Constant Work, Shuffle Sharding â it will be interesting. Less than a month until the conference â . Prices will increase on October 24.
Burimi: habr.com
