Mraky sú ako čarovná škatuľka – pýtate sa, čo potrebujete, a zdroje sa len tak z ničoho nič objavia. Virtuálne stroje, databázy, sieť – to všetko patrí len vám. Existujú aj iní nájomníci cloudu, ale vo svojom vesmíre ste jediným vládcom. Máte istotu, že vždy dostanete požadované zdroje, nikoho neberiete do úvahy a nezávisle určujete, aká bude sieť. Ako funguje táto mágia, vďaka ktorej cloud pružne prideľuje zdroje a úplne izoluje nájomníkov od seba?
AWS cloud je mega-super komplexný systém, ktorý sa od roku 2006 evolučne vyvíja. Časť tohto vývoja sa odohrala Vasilij Pantyukhin - architekt Amazon Web Services. Ako architekt získa vnútorný pohľad nielen na konečný výsledok, ale aj na výzvy, ktoré AWS prekonáva. Čím väčšie pochopenie fungovania systému, tým väčšia dôvera. Preto sa Vasily podelí o tajomstvá cloudových služieb AWS. Nižšie je uvedený návrh fyzických serverov AWS, elastická škálovateľnosť databázy, vlastná databáza Amazon a metódy na zvýšenie výkonu virtuálnych strojov pri súčasnom znížení ich ceny. Znalosť architektonických prístupov Amazonu vám pomôže efektívnejšie využívať služby AWS a môže vám poskytnúť nové nápady na vytváranie vlastných riešení.
O rečníkovi: Vasily Pantyukhin () začínal ako správca Unixu v spoločnostiach s doménou .ru, 6 rokov pracoval na veľkom hardvéri Sun Microsystem a 11 rokov kázal dátovo-centrický svet v EMC. Prirodzene sa vyvinul do súkromných cloudov a v roku 2017 prešiel na verejné. Teraz poskytuje technické poradenstvo, ktoré pomáha žiť a rozvíjať sa v cloude AWS.
Zrieknutie sa zodpovednosti: všetko nižšie je Vasilyho osobný názor a nemusí sa zhodovať s pozíciou Amazon Web Services. Správa, na ktorej je článok založený, je k dispozícii na našom kanáli YouTube.
Prečo hovorím o zariadení Amazon?
Moje prvé auto malo manuálnu prevodovku. Bolo to skvelé kvôli pocitu, že môžem riadiť auto a mať nad ním úplnú kontrolu. Páčilo sa mi aj to, že som aspoň zhruba pochopil princíp jeho fungovania. Prirodzene, štruktúru boxu som si predstavoval dosť primitívnu – niečo ako prevodovku na bicykli.
Všetko bolo super, až na jednu vec – uviaznutie v zápchach. Zdá sa, že sedíte a nič nerobíte, ale neustále preraďujete, stláčate spojku, plyn, brzdu – to vás skutočne unavuje. Problém s dopravnou zápchou sa čiastočne vyriešil, keď rodina dostala automatické auto. Počas jazdy som mal čas nad niečím premýšľať a počúvať audioknihu.
V mojom živote sa objavila ďalšia záhada, pretože som úplne prestal chápať, ako moje auto funguje. Moderné auto je zložité zariadenie. Auto sa súčasne prispôsobuje desiatkam rôznych parametrov: stlačenie plynu, brzda, štýl jazdy, kvalita vozovky. Už nechápem ako to funguje.
Keď som začal pracovať na cloude Amazon, bolo to pre mňa tiež záhadou. Len táto záhada je rádovo väčšia, pretože v aute je jeden vodič a v AWS sú ich milióny. Všetci používatelia súčasne riadia, stláčajú plyn a brzdu. Je úžasné, že idú, kam chcú – je to pre mňa zázrak! Systém sa automaticky prispôsobuje, škáluje a elasticky prispôsobuje každému užívateľovi tak, aby sa mu zdalo, že je v tomto Vesmíre sám.
Kúzlo sa trochu vytratilo, keď som neskôr prišiel pracovať ako architekt v Amazone. Videl som, akým problémom čelíme, ako ich riešime a ako rozvíjame služby. S rastúcim pochopením toho, ako systém funguje, sa objavuje väčšia dôvera v službu. Chcem sa teda podeliť o obrázok toho, čo je pod kapotou cloudu AWS.
O čom by sme sa mali rozprávať
Zvolil som diverzifikovaný prístup – vybral som 4 zaujímavé služby, ktoré stoja za reč.
Optimalizácia servera. Prchavé mraky s fyzickým stelesnením: fyzické dátové centrá, kde sú fyzické servery, ktoré bzučia, zahrievajú sa a blikajú svetlami.
Funkcie bez servera (Lambda) je pravdepodobne najškálovateľnejšia služba v cloude.
Škálovanie databázy. Poviem vám o tom, ako budujeme vlastné škálovateľné databázy.
Škálovanie siete. Posledná časť, v ktorej otvorím zariadenie našej siete. To je úžasná vec – každý používateľ cloudu verí, že je v cloude sám a ostatných nájomníkov vôbec nevidí.
Poznámka. Tento článok sa bude zaoberať optimalizáciou servera a škálovaním databázy. Škálovaniu siete sa budeme venovať v nasledujúcom článku. Kde sú funkcie bez servera? Bol o nich uverejnený samostatný prepis “" Hovorí o niekoľkých rôznych metódach škálovania a podrobne rozoberá riešenie Firecracker - symbiózu najlepších kvalít virtuálneho stroja a kontajnerov.
Servery
Oblak je efemérny. Ale táto efemérnosť má stále fyzické stelesnenie - servery. Spočiatku bola ich architektúra klasická. Štandardný x86 čipset, sieťové karty, Linux, Xen hypervízor, na ktorom boli spustené virtuálne stroje.
V roku 2012 sa táto architektúra vyrovnala so svojimi úlohami celkom dobre. Xen je skvelý hypervízor, no má jednu veľkú nevýhodu. Má toho dosť vysoká réžia na emuláciu zariadenia. Keď budú k dispozícii nové, rýchlejšie sieťové karty alebo disky SSD, táto réžia bude príliš vysoká. Ako sa s týmto problémom vysporiadať? Rozhodli sme sa pracovať na dvoch frontoch naraz - optimalizovať hardvér aj hypervízor. Úloha je veľmi vážna.
Optimalizácia hardvéru a hypervízora
Robiť všetko naraz a robiť to dobre nebude fungovať. Čo bolo „dobré“, bolo tiež spočiatku nejasné.
Rozhodli sme sa pre evolučný prístup – meníme jeden dôležitý prvok architektúry a vrháme ho do výroby.
Šliapeme na každé hrable, počúvame sťažnosti a návrhy. Potom zmeníme ďalší komponent. V malých prírastkoch teda radikálne meníme celú architektúru na základe spätnej väzby od používateľov a podpory.
Transformácia začala v roku 2013 tou najzložitejšou vecou – sieťou. IN С3 inštanciách bola k štandardnej sieťovej karte pridaná špeciálna karta Network Accelerator. Bol pripojený doslova pomocou krátkeho loopback kábla na prednom paneli. Nie je to pekné, ale v oblaku to nie je vidieť. Ale priama interakcia s hardvérom zásadne zlepšila jitter a priepustnosť siete.
Ďalej sme sa rozhodli zlepšiť prístup k blokovým dátovým úložiskám EBS – Elastic Block Storage. Ide o kombináciu siete a úložiska. Problém je v tom, že kým karty Network Accelerator na trhu existovali, neexistovala možnosť jednoducho kúpiť hardvér Storage Accelerator. Tak sme sa obrátili na startup Annapurna Labs, ktorý pre nás vyvinul špeciálne čipy ASIC. Umožnili pripojenie vzdialených zväzkov EBS ako zariadení NVMe.
V prípadoch C4 vyriešili sme dva problémy. Prvým je, že sme implementovali základ pre budúcnosť sľubnej, no v tom čase novej technológie NVMe. Po druhé, výrazne sme odbremenili centrálny procesor prenesením spracovania požiadaviek do EBS na novú kartu. Dopadlo to dobre, takže Annapurna Labs je teraz súčasťou Amazonu.
V novembri 2017 sme si uvedomili, že je čas zmeniť samotný hypervízor.
Nový hypervízor bol vyvinutý na základe upravených modulov jadra KVM.
Umožnil zásadne znížiť réžiu emulácie zariadení a pracovať priamo s novými ASIC. Inštancie С5 boli prvé virtuálne stroje s novým hypervízorom bežiacim pod kapotou. Pomenovali sme ho Nitro.
Vývoj prípadov na časovej osi.
Všetky nové typy virtuálnych strojov, ktoré sa objavili od novembra 2017, bežia na tomto hypervízore. Inštancie Bare Metal nemajú hypervízor, ale nazývajú sa aj Nitro, keďže používajú špecializované Nitro karty.
Počas nasledujúcich dvoch rokov počet typov inštancií Nitro prekročil niekoľko desiatok: A1, C5, M5, T3 a ďalšie.
Typy inštancií.
Ako fungujú moderné stroje Nitro
Majú tri hlavné komponenty: hypervízor Nitro (diskutovaný vyššie), bezpečnostný čip a karty Nitro.
Bezpečnostný čip integrovaný priamo do základnej dosky. Ovláda mnoho dôležitých funkcií, ako napríklad riadenie načítania hostiteľského OS.
Nitro karty - Sú štyri druhy. Všetky sú vyvinuté Annapurna Labs a sú založené na bežných ASIC. Niektoré z ich firmvéru sú tiež bežné.
Štyri typy Nitro kariet.
Jedna z kariet je určená na prácu sieteVPC. To je to, čo je viditeľné vo virtuálnych strojoch ako sieťová karta ENA - elastický sieťový adaptér. Tiež zapuzdruje prevádzku pri jej prenose cez fyzickú sieť (hovoríme o tom v druhej časti článku), riadi firewall bezpečnostných skupín a je zodpovedný za smerovanie a ďalšie sieťové veci.
Vybrané karty fungujú s blokovým ukladaním EBS a disky, ktoré sú zabudované do servera. Na hosťujúcom virtuálnom počítači sa javia ako NVMe adaptéry. Sú tiež zodpovední za šifrovanie dát a monitorovanie disku.
Systém Nitro kariet, hypervízora a bezpečnostného čipu je integrovaný do siete SDN resp Sieť definovaná softvérom. Zodpovedný za správu tejto siete (riadiaca rovina) karta ovládača.
Samozrejme, pokračujeme vo vývoji nových ASIC. Napríklad koncom roka 2018 vydali čip Inferentia, ktorý vám umožňuje efektívnejšie pracovať s úlohami strojového učenia.
Čip procesora Inferentia Machine Learning.
Škálovateľná databáza
Tradičná databáza má vrstvenú štruktúru. Pre veľké zjednodušenie sa rozlišujú nasledujúce úrovne.
- SQL — pracujú na ňom klienti a dispečeri požiadaviek.
- Ustanovenia transakcií - tu je všetko jasné, ACID a tak ďalej.
- ukladanie do vyrovnávacej pamäte, ktorú poskytujú buffer pooly.
- Ťažba dreva — poskytuje prácu s redo protokolmi. V MySQL sa nazývajú Bin Logs, v PosgreSQL - Write Ahead Logs (WAL).
- Skladovanie – priame nahrávanie na disk.
Vrstvená štruktúra databázy.
Existujú rôzne spôsoby škálovania databáz: sharding, architektúra Shared Nothing, zdieľané disky.
Všetky tieto metódy si však zachovávajú rovnakú monolitickú databázovú štruktúru. To výrazne obmedzuje škálovanie. Na vyriešenie tohto problému sme vyvinuli vlastnú databázu − Amazonská Aurora. Je kompatibilný s MySQL a PostgreSQL.
Amazonská Aurora
Hlavnou architektonickou myšlienkou je oddeliť úrovne úložiska a protokolovania od hlavnej databázy.
Pri pohľade do budúcnosti poviem, že sme osamostatnili aj úroveň ukladania do vyrovnávacej pamäte. Architektúra prestáva byť monolitom a získavame ďalšie stupne voľnosti pri škálovaní jednotlivých blokov.
Úrovne protokolovania a ukladania sú oddelené od databázy.
Tradičný DBMS zapisuje údaje do úložného systému vo forme blokov. V Amazon Aurora sme vytvorili inteligentné úložisko, ktoré dokáže hovoriť jazykom redo-logs. Vnútri úložisko premieňa protokoly na dátové bloky, monitoruje ich integritu a automaticky zálohuje.
Tento prístup umožňuje realizovať také zaujímavé veci, ako je klonovanie. Funguje zásadne rýchlejšie a ekonomickejšie vďaka tomu, že nevyžaduje vytvorenie úplnej kópie všetkých údajov.
Úložná vrstva je implementovaná ako distribuovaný systém. Pozostáva z veľmi veľkého počtu fyzických serverov. Každý redo log sa spracuje a uloží súčasne šesť uzlov. To zaisťuje ochranu údajov a vyrovnávanie záťaže.
Zmena mierky čítania sa dá dosiahnuť použitím vhodných replík. Distribuované úložisko eliminuje potrebu synchronizácie medzi hlavnou inštanciou databázy, cez ktorú zapisujeme dáta, a zvyšnými replikami. Je zaručené, že všetky repliky budú mať k dispozícii aktuálne údaje.
Jediným problémom je ukladanie starých údajov do vyrovnávacej pamäte na čítaných replikách. Ale tento problém sa rieši prenos všetkých redo logov na repliky cez internú sieť. Ak je log v cache, je označený ako nesprávny a prepísaný. Ak nie je vo vyrovnávacej pamäti, jednoducho sa zahodí.
Uskladnenie sme vyriešili.
Ako škálovať úrovne DBMS
Tu je horizontálne škálovanie oveľa ťažšie. Poďme teda po vychodených cestách klasické vertikálne škálovanie.
Predpokladajme, že máme aplikáciu, ktorá komunikuje s DBMS cez hlavný uzol.
Pri vertikálnom škálovaní alokujeme nový uzol, ktorý bude mať viac procesorov a pamäte.
Ďalej prepneme aplikáciu zo starého hlavného uzla na nový. Vznikajú problémy.
- To si vyžiada značné prestoje aplikácie.
- Nový hlavný uzol bude mať studenú vyrovnávaciu pamäť. Výkon databázy bude maximálny až po zahriatí vyrovnávacej pamäte.
Ako zlepšiť situáciu? Nastavte proxy medzi aplikáciou a hlavným uzlom.
Čo nám to dá? Teraz nemusia byť všetky aplikácie manuálne presmerované na nový uzol. Prepnutie je možné vykonať pod proxy a je zásadne rýchlejšie.
Zdá sa, že problém je vyriešený. Ale nie, stále trpíme potrebou zahrievať kešku. Okrem toho sa objavil nový problém - proxy je teraz potenciálnym bodom zlyhania.
Konečné riešenie s Amazon Aurora bez servera
Ako sme tieto problémy vyriešili?
Zanechal proxy. Nejde o samostatnú inštanciu, ale o celú distribuovanú flotilu proxy serverov, cez ktoré sa aplikácie pripájajú k databáze. V prípade poruchy je možné takmer okamžite vymeniť ktorýkoľvek z uzlov.
Pridaný bazén teplých uzlov rôznych veľkostí. Preto, ak je potrebné prideliť nový uzol väčšej alebo menšej veľkosti, je okamžite k dispozícii. Nie je potrebné čakať, kým sa načíta.
Celý proces škálovania je riadený špeciálnym monitorovacím systémom. Monitoring neustále monitoruje stav aktuálneho hlavného uzla. Ak napríklad zistí, že zaťaženie procesora dosiahlo kritickú hodnotu, upozorní skupinu teplých inštancií na potrebu prideliť nový uzol.
Distribuované proxy, teplé inštancie a monitorovanie.
K dispozícii je uzol s požadovaným výkonom. Do nej sa skopírujú zásobníky vyrovnávacej pamäte a systém začne čakať na bezpečný okamih na prepnutie.
Okamžik na zmenu zvyčajne prichádza pomerne rýchlo. Potom je komunikácia medzi proxy a starým hlavným uzlom pozastavená, všetky relácie sa prepnú na nový uzol.
Práca s databázou pokračuje.
Graf ukazuje, že odpruženie je skutočne veľmi krátke. Modrý graf zobrazuje zaťaženie a červené kroky zobrazujú momenty zmeny mierky. Krátkodobé poklesy v modrom grafe sú presne tým krátkym oneskorením.
Mimochodom, Amazon Aurora vám umožňuje úplne ušetriť peniaze a vypnúť databázu, keď sa nepoužíva, napríklad cez víkendy. Po zastavení záťaže DB postupne znižuje výkon a na nejaký čas sa vypne. Keď sa záťaž vráti, opäť sa plynule zdvihne.
V ďalšej časti príbehu o zariadení Amazon budeme hovoriť o škálovaní siete. Prihlásiť sa na odber a sledujte, aby vám článok neušiel.
Na Vasily Pantyukhin podá správu “" Aké dizajnové vzory pre distribuované systémy používajú vývojári Amazonu, aké sú dôvody zlyhania služieb, aká je architektúra Cell-based, Constant Work, Shuffle Sharding – to bude zaujímavé. Menej ako mesiac do konferencie - . 24. októbra konečné zvýšenie ceny.
Zdroj: hab.com