Wolleke si wéi eng Zauberbox - Dir frot wat Dir braucht, an d'Ressourcen erschéngen just aus néierens. Virtuell Maschinnen, Datenbanken, Netz - all dat gehéiert nëmmen un Iech. Et ginn aner Wolleken Locataire, awer an Ärem Universum sidd Dir den eenzegen Herrscher. Dir sidd sécher datt Dir ëmmer déi erfuerderlech Ressourcen kritt, Dir musst kee Rechnung huelen an Dir bestëmmt onofhängeg wéi d'Netzwierk wäert sinn. Wéi funktionéiert dës Magie, déi d'Wollek elastesch Ressourcen verdeelt a Mieter komplett vuneneen isoléiert?
D'AWS Cloud ass e mega-super komplexe System deen zënter 2006 evolutiv evoluéiert huet. En Deel vun dëser Entwécklung huet stattfonnt Vasily Pantyukhin - Amazon Web Services Architekt. Als Architekt kritt hien net nëmmen d'Ennresultat, mee och d'Erausfuerderunge vun der AWS. Wat méi Verständnis wéi de System funktionnéiert, wat méi Vertrauen ass. Dofir wäert Vasily d'Geheimnisser vun AWS Cloud Servicer deelen. Drënner ass den Design vu kierperlechen AWS Serveren, elastescher Datebank Skalierbarkeet, eng personaliséiert Amazon Datebank a Methoden fir d'Performance vu virtuelle Maschinnen ze erhéijen a gläichzäiteg hire Präis ze reduzéieren. Wësse vun den architektoneschen Approchen vun Amazon hëlleft Iech AWS Servicer méi effektiv ze benotzen a kann Iech nei Iddie ginn fir Är eege Léisungen ze bauen.
Iwwert de Spriecher: Vasily Pantyukhin () ugefaang als Unix Admin bei .ru Firmen, huet 6 Joer laang u grousser Sun Microsystem Hardware geschafft an eng datenzentresch Welt bei EMC fir 11 Joer gepriedegt. Et huet sech natierlech zu private Wolleken entwéckelt, an 2017 ass op ëffentlech geplënnert. Elo bitt hien technesch Berodung fir ze hëllefen an der AWS Cloud ze liewen an z'entwéckelen.
Verzichterklärung: alles hei drënner ass dem Vasily seng perséinlech Meenung a kann net mat der Positioun vun Amazon Web Services zesummefalen. De Bericht op deem den Artikel baséiert ass op eisem YouTube Kanal verfügbar.
Firwat schwätzen ech iwwer den Amazon Apparat?
Meng éischt Auto hat eng manuell Transmissioun. Et war super wéinst dem Gefill datt ech mam Auto fuere konnt a komplett Kontroll doriwwer hunn. Ech hunn och gär datt ech op d'mannst de Prinzip vu senger Operatioun ongeféier verstanen hunn. Natierlech hunn ech d'Struktur vun der Këscht ganz primitiv virgestallt - sou eppes wéi eng Gearbox op engem Vëlo.
Alles war super, ausser enger Saach - am Stau hänke bliwwen. Et schéngt wéi wann Dir sëtzt an näischt maacht, awer Dir ännert stänneg Gears, dréckt d'Kupplung, Gas, Brems - et mécht Iech wierklech midd. De Stauproblem war deelweis geléist, wéi d'Famill en automateschen Auto krut. Beim Fueren hat ech Zäit fir eppes ze denken an en Audiobuch ze lauschteren.
En anert Geheimnis ass a mengem Liewen opgetaucht, well ech komplett opgehalen hunn ze verstoen wéi mäin Auto funktionnéiert. E modernen Auto ass e komplexen Apparat. Den Auto passt gläichzäiteg un Dosende vu verschiddene Parameteren: Gas drécken, Brems, Fahrstil, Stroossqualitéit. Ech verstinn net méi wéi et funktionnéiert.
Wéi ech ugefaang hunn un der Amazon Cloud ze schaffen, war et fir mech och e Geheimnis. Nëmmen dëst Geheimnis ass eng Uerdnung vun der Gréisst méi grouss, well et ee Chauffeur am Auto ass, an AWS et Millioune vun hinnen. All Benotzer gläichzäiteg steieren, dréckt de Gas an d'Brems. Et ass erstaunlech datt se goen wou se wëllen - et ass e Wonner fir mech! De System passt automatesch un, skaléiert an elastesch un all Benotzer un, sou datt et him schéngt wéi hien eleng an dësem Universum ass.
D'Magie huet e bëssen ofgeschaaft wéi ech spéider als Architekt bei Amazon schaffen komm sinn. Ech hu gesinn, wéi eng Problemer mir stellen, wéi mir se léisen, a wéi mir Servicer entwéckelen. Mat ëmmer méi Verständnis wéi de System funktionnéiert, erschéngt méi Vertrauen an de Service. Also ech wëll e Bild deelen vun deem wat ënner der Hood vun der AWS Wollek ass.
Iwwer wat wäerte mir schwätzen
Ech hunn eng diversifizéiert Approche gewielt - ech hunn 4 interessant Servicer ausgewielt, iwwer déi et wäert ze schwätzen.
Server Optimisatioun. Ephemeral Wolleke mat enger kierperlecher Ausféierung: physesch Datenzenteren, wou et physesch Serveren sinn, déi mat Luuchten hummen, erwiermen a blénken.
Serverlos Funktiounen (Lambda) ass wahrscheinlech dee skalierbarsten Service an der Wollek.
Datebank Skaléieren. Ech soen Iech iwwer wéi mir eis eege skalierbar Datenbanken bauen.
Netzwierk Skala. Dee leschten Deel an deem ech den Apparat vun eisem Netzwierk opmaachen. Dëst ass eng wonnerbar Saach - all Cloud Benotzer gleeft datt hien eleng an der Wollek ass a guer net aner Locataire gesäit.
Note. Dësen Artikel wäert d'Serveroptimiséierung an d'Datebankskaléierung diskutéieren. Mir wäerten d'Netzwierkskaléierung am nächsten Artikel betruechten. Wou sinn d'Serverlos Funktiounen? En separaten Transkript gouf iwwer si publizéiert "" Et schwätzt iwwer verschidde verschidde Skaléierungsmethoden, an diskutéiert am Detail d'Firecracker Léisung - eng Symbios vun de beschten Qualitéite vun enger virtueller Maschinn a Container.
Serveren
D'Wollek ass ephemeral. Awer dës Ephemeralitéit huet nach ëmmer eng kierperlech Ausféierung - Serveren. Am Ufank war hir Architektur klassesch. Standard x86 Chipsatz, Netzwierkkaarten, Linux, Xen Hypervisor op deem virtuelle Maschinnen lafen.
Am Joer 2012 huet dës Architektur seng Aufgaben ganz gutt gepackt. Xen ass e super Hypervisor, awer et huet ee groussen Nodeel. Hien huet genuch héich Overhead fir Apparat Emulatioun. Wéi nei, méi séier Netzwierkkaarten oder SSD-Laufwerke verfügbar ginn, gëtt dës Overhead ze héich. Wéi mat dësem Problem ze këmmeren? Mir hu beschloss op zwou Fronte gläichzäiteg ze schaffen - optiméiert souwuel Hardware wéi och Hypervisor. D'Aufgab ass ganz eescht.
Hardware an Hypervisor optimiséieren
Alles gläichzäiteg maachen an et gutt maachen wäert net schaffen. Wat "gutt" war, war och am Ufank onkloer.
Mir hu beschloss eng evolutiv Approche ze huelen - mir änneren ee wichtegt Element vun der Architektur an werfen se an d'Produktioun.
Mir trëppelen op all Rake, lauschteren op Reklamatiounen a Virschléi. Dann änneren mir eng aner Komponent. Also, a klenge Schrëtt verännere mir déi ganz Architektur radikal op Basis vu Feedback vun de Benotzer an Ënnerstëtzung.
D'Transformatioun huet am Joer 2013 ugefaang mat der komplexer Saach - dem Netz. IN С3 Fäll, eng speziell Network Accelerator Kaart gouf op d'Standard Netzwierkkaart bäigefüügt. Et war wuertwiertlech mat engem kuerzen Loopback Kabel op der viischter Panel verbonnen. Et ass net schéin, awer et ass net an der Wollek ze gesinn. Awer direkt Interaktioun mat Hardware huet grondsätzlech verbessert Jitter an Netzwierk Duerchgang.
Als nächst hu mir beschloss den Zougang zum Blockdatenlagerung EBS - Elastic Block Storage ze verbesseren. Et ass eng Kombinatioun vun Netzwierk a Späicheren. D'Schwieregkeet ass datt wärend Network Accelerator Kaarte um Maart existéiert, et war keng Optioun fir einfach Storage Accelerator Hardware ze kafen. Also hu mir eis op e Startup gemaach Annapurna Labs, déi speziell ASIC Chips fir eis entwéckelt hunn. Si hunn erlaabt Remote EBS Volumen als NVMe Geräter montéiert ze ginn.
An Fäll C4 mir hunn zwee Problemer geléist. Déi éischt ass datt mir e Fundament fir d'Zukunft vun der verspriechender, awer neier zu där Zäit, NVMe Technologie implementéiert hunn. Zweetens hu mir den zentrale Prozessor wesentlech entlaascht andeems d'Veraarbechtung vun Ufroen op EBS op eng nei Kaart transferéiert gouf. Et ass gutt erausgaang, also ass elo Annapurna Labs Deel vun Amazon.
Bis November 2017 hu mir gemierkt datt et Zäit war den Hypervisor selwer z'änneren.
Den neien Hypervisor gouf entwéckelt baséiert op modifizéierten KVM Kernel Moduler.
Et huet et méiglech grondsätzlech den Overhead vun der Apparat Emulatioun ze reduzéieren an direkt mat neien ASICs ze schaffen. Instanzen С5 waren déi éischt virtuell Maschinnen mat engem neien Hypervisor ënnert der Hood lafen. Mir hunn hien genannt Grupp.
Evolutioun vun Instanzen op der Timeline.
All nei Zorte vu virtuelle Maschinnen, déi zënter November 2017 opgetaucht sinn, lafen op dësem Hypervisor. Bare Metal Instanzen hunn keen Hypervisor, mä si ginn och Nitro genannt, well se spezialiséiert Nitro Kaarte benotzen.
An den nächsten zwee Joer ass d'Zuel vun den Aarte vun Nitro-Instanzen e puer Dosen iwwerschratt: A1, C5, M5, T3 an anerer.
Instanz Typen.
Wéi modern Nitro Maschinnen funktionnéieren
Si hunn dräi Haaptkomponenten: den Nitro Hypervisor (uewen diskutéiert), de Sécherheetschip an d'Nitro Kaarten.
Sécherheet Chip direkt an de Motherboard integréiert. Et kontrolléiert vill wichteg Funktiounen, wéi d'Kontroll vun der Luede vum Host OS.
Nitro Kaarten - Et gi véier Zorte vun hinnen. All si gi vun Annapurna Labs entwéckelt a baséieren op gemeinsame ASICs. E puer vun hirer Firmware ass och heefeg.
Véier Zorte vun Nitro Kaarte.
Eng vun de Kaarten ass entwéckelt fir mat ze schaffen ReseauVPC. Dëst ass wat a virtuelle Maschinnen als Netzwierkkaart sichtbar ass ENA - Elastesche Netzwierkadapter. Et encapsuléiert och de Traffic wann se duerch e kierperlecht Netzwierk iwwerdroen (mir schwätzen iwwer dëst am zweeten Deel vum Artikel), kontrolléiert d'Sécherheetsgruppen Firewall, an ass verantwortlech fir Routing an aner Netzwierksaachen.
Wielt Kaarte funktionnéieren mat Blocklagerung EBS an Disken déi an de Server gebaut sinn. Si schéngen dem Gaascht virtuell Maschinn als NVMe Adapter. Si sinn och verantwortlech fir Dateverschlësselung an Disk Iwwerwachung.
De System vun Nitro Kaarten, Hypervisor a Sécherheet Chip ass an engem SDN Reseau integréiert oder Software definéiert Netzwierk. Verantwortlech fir d'Gestioun vun dësem Netzwierk (Kontrollplane) Controller Kaart.
Natierlech entwéckelen mir weider nei ASICs. Zum Beispill, um Enn vum 2018 hunn se den Inferentia-Chip verëffentlecht, wat Iech erlaabt méi effizient mat Maschinnléieren Aufgaben ze schaffen.
Inferentia Machine Learning Prozessor Chip.
Skalierbar Datebank
Eng traditionell Datebank huet eng Layer Struktur. Wa mir vill vereinfachen, ginn déi folgend Niveauen ënnerscheet.
- SQL - Client an Ufro Dispatcher schaffen drun.
- Bestëmmungen Transaktiounen - alles ass kloer hei, SAIER an all dat.
- cachen, déi vu Pufferpools geliwwert gëtt.
- Logged - liwwert Aarbecht mat Redo-Logbicher. A MySQL gi se Bin Logs genannt, an PosgreSQL - Write Ahead Logs (WAL).
- Späicheren - Direkten Opnam op Disk.
Layered Datebank Struktur.
Et gi verschidde Weeër fir Datenbanken ze skaléieren: Sharding, Shared Nothing Architektur, Shared Disks.
Wéi och ëmmer, all dës Methoden behalen déiselwecht monolithesch Datebankstruktur. Dëst limitéiert d'Skaléierung wesentlech. Fir dëse Problem ze léisen, hu mir eis eege Datebank entwéckelt - Amazon Aurora. Et ass kompatibel mat MySQL a PostgreSQL.
Amazon Aurora
D'Haaptarchitektonesch Iddi ass d'Späicher- a Logniveaue vun der Haaptdatenbank ze trennen.
Wann ech no vir kucken, wäert ech soen datt mir och den Cacheniveau onofhängeg gemaach hunn. D'Architektur hält op e Monolith ze sinn, a mir kréien zousätzlech Fräiheetsgrade beim Skaléieren vun eenzelne Blocken.
D'Protokoll- a Späicherniveauen sinn getrennt vun der Datebank.
Eng traditionell DBMS schreift Daten an e Späichersystem a Form vu Blocken. Bei Amazon Aurora hu mir Smart Storage erstallt déi Sprooch schwätze kann nei-Logbicher. Bannen verwandelt d'Späichere Logbicher an Dateblocken, iwwerwaacht hir Integritéit an automatesch Backup.
Dës Approche erlaabt Iech esou interessant Saachen ëmzesetzen wéi klonen. Et funktionnéiert grondsätzlech méi séier a méi ekonomesch wéinst der Tatsaach datt et net erfuerdert eng komplett Kopie vun all Donnéeën ze kreéieren.
D'Späicherschicht gëtt als verdeelt System ëmgesat. Et besteet aus enger ganz grousser Zuel vu kierperleche Serveren. All Redo Log gëtt veraarbecht a gläichzäiteg gespäichert sechs Kniet. Dëst garantéiert Dateschutz a Belaaschtung.
Liesskaléieren ka mat passenden Repliken erreecht ginn. Verdeelt Lagerung eliminéiert de Besoin fir Synchroniséierung tëscht der Haaptdatenbankinstanz, duerch déi mir Daten schreiwen, an déi verbleiwen Repliken. Aktuell Donnéeën si garantéiert fir all Repliken verfügbar ze sinn.
Deen eenzege Problem ass d'Cache vun alen Daten op gelies Repliken. Mä dëse Problem gëtt geléist Transfert vun all redo Logbicher fir Repliken iwwer den internen Netzwierk. Wann de Logbuch am Cache ass, gëtt et als falsch markéiert an iwwerschriwwen. Wann et net am Cache ass, gëtt et einfach verworf.
Mir hunn d'Lagerung ausgesort.
Wéi Skala DBMS-Tier
Hei ass horizontal Skala vill méi schwéier. Also loosst eis de geschloene Wee erof goen klassesch vertikal Skala.
Loosst eis unhuelen datt mir eng Applikatioun hunn déi mam DBMS duerch e Master Node kommunizéiert.
Wann Dir vertikal skaléieren, verdeele mir en neien Node dee méi Prozessoren an Erënnerung wäert hunn.
Als nächst wiessele mir d'Applikatioun vum alen Master Node op den neien. Problemer entstinn.
- Dëst erfuerdert bedeitend Applikatiounsstoppzäit.
- Den neie Master Node wäert kale Cache hunn. D'Datebankleistung wäert maximal nëmme sinn nodeems de Cache opgewiermt ass.
Wéi d'Situatioun ze verbesseren? Setzt e Proxy tëscht der Applikatioun an dem Master Node op.
Wat wäert dat eis ginn? Elo mussen all Uwendungen net manuell op den neien Node ëmgeleet ginn. De Wiessel kann ënner engem Proxy gemaach ginn an ass grondsätzlech méi séier.
Et schéngt, datt de Problem geléist ass. Mee nee, mir leiden nach ëmmer ënner der Bedierfnes fir de Cache opzewiermen. Zousätzlech ass en neie Problem opgetaucht - elo ass de Proxy e potenzielle Punkt vum Echec.
Finale Léisung mat Amazon Aurora Serverlos
Wéi hu mir dës Problemer geléist?
Lénks e Proxy. Dëst ass keng separat Instanz, awer eng ganz verdeelt Flott vu Proxyen duerch déi Uwendungen mat der Datebank verbannen. Am Fall vun Echec kann ee vun de Wirbelen bal direkt ersat ginn.
Dobäi e Pool vu waarme Wirbelen vu verschiddene Gréissten. Dofir, wann et néideg ass en neien Node vun enger méi grousser oder méi klenger Gréisst ze verdeelen, ass et direkt verfügbar. Kee Grond fir ze waarden bis se lued.
De ganze Skaléierungsprozess gëtt vun engem speziellen Iwwerwaachungssystem kontrolléiert. Iwwerwaachung iwwerwaacht dauernd den Zoustand vum aktuelle Master Node. Wann et erkennt, zum Beispill, datt d'Prozessorbelaaschtung e kritesche Wäert erreecht huet, informéiert de Pool vu waarme Instanzen iwwer d'Noutwendegkeet fir en neien Node ze verdeelen.
Verdeelt Proxyen, waarm Instanzen an Iwwerwaachung.
E Node mat der erfuerderter Kraaft ass verfügbar. Bufferpools ginn op et kopéiert, an de System fänkt un fir e séchere Moment ze wiesselen.
Normalerweis kënnt de Moment fir ze wiesselen zimlech séier. Dann ass d'Kommunikatioun tëscht dem Proxy an dem alen Meeschterknuet suspendéiert, all Sessiounen ginn op den neien Node ëmgewiesselt.
Schafft mat der Datebank erëm.
D'Grafik weist datt d'Suspension jo ganz kuerz ass. Déi blo Grafik weist d'Laascht, an déi rout Schrëtt weisen d'Skaléierungsmomenter. Kuerzfristeg Dips an der bloer Grafik si genee déi kuerz Verzögerung.
Iwwregens, Amazon Aurora erlaabt Iech komplett Suen ze spueren an d'Datebank auszeschalten wann se net am Gebrauch ass, zum Beispill um Weekend. Nodeems Dir d'Laascht gestoppt huet, reduzéiert d'DB graduell seng Kraaft a schalt sech fir eng Zäit aus. Wann d'Laascht zréck geet, geet se nees glat erop.
Am nächsten Deel vun der Geschicht iwwer den Amazon Apparat schwätze mir iwwer d'Netzwierkskaléierung. Abonnéieren a bleiwt drun, fir den Artikel net ze verpassen.
op Vasily Pantyukhin gëtt e Bericht "" Wéi eng Designmuster fir verdeelt Systemer gi vun Amazon Entwéckler benotzt, wat sinn d'Grënn fir Servicefehler, wat ass Zell-baséiert Architektur, Constant Work, Shuffle Sharding - et wäert interessant sinn. Manner wéi engem Mount bis d'Konferenz - . 24. Oktober Finale Präiserhéijung.
Source: will.com