Mraky jsou jako kouzelná skříňka – zeptáte se, co potřebujete, a zdroje se prostě objeví z ničeho nic. Virtuální stroje, databáze, síť – to vše patří pouze vám. Existují další nájemci cloudu, ale ve svém vesmíru jste jediným vládcem vy. Máte jistotu, že vždy dostanete potřebné zdroje, nemusíte nikoho brát v úvahu a sami si určujete, jaká bude síť. Jak funguje toto kouzlo, díky kterému cloud pružně alokuje zdroje a zcela izoluje tenanty od sebe navzájem?
Cloud AWS je mega-super komplexní systém, který se od roku 2006 evolučně vyvíjí. Část tohoto vývoje proběhla Vasilij Pantyukhin - architekt Amazon Web Services. Jako architekt získá vnitřní pohled nejen na konečný výsledek, ale také na výzvy, které AWS překonává. Čím větší pochopení toho, jak systém funguje, tím větší důvěra. Proto se Vasily podělí o tajemství cloudových služeb AWS. Níže je uveden návrh fyzických serverů AWS, elastická škálovatelnost databáze, vlastní databáze Amazon a metody pro zvýšení výkonu virtuálních strojů při současném snížení jejich ceny. Znalost architektonických přístupů Amazonu vám pomůže efektivněji využívat služby AWS a může vám poskytnout nové nápady pro vytváření vlastních řešení.
O řečníkovi: Vasily Pantyukhin () začínal jako unixový admin ve společnostech .ru, 6 let pracoval na velkém hardwaru Sun Microsystem a 11 let kázal ve společnosti EMC data-centrický svět. Přirozeně se vyvinul do privátních cloudů a v roce 2017 přešel do veřejných. Nyní poskytuje technické poradenství, které pomáhá žít a rozvíjet se v cloudu AWS.
Zřeknutí se odpovědnosti: vše níže je Vasilyho osobní názor a nemusí se shodovat s pozicí Amazon Web Services. Zpráva, na které je článek založen, je k dispozici na našem kanálu YouTube.
Proč mluvím o zařízení Amazon?
Moje první auto mělo manuální převodovku. Bylo to skvělé kvůli pocitu, že mohu řídit auto a mít nad ním úplnou kontrolu. Také se mi líbilo, že jsem alespoň zhruba pochopil princip jeho fungování. Strukturu skříně jsem si přirozeně představoval docela primitivní - něco jako převodovka na kole.
Všechno bylo skvělé, až na jednu věc - trčet v zácpách. Zdá se, že sedíte a nic neděláte, ale neustále měníte rychlostní stupně, mačkáte spojku, plyn, brzdu – opravdu vás to unaví. Problém s dopravní zácpou se částečně vyřešil, když rodina dostala automatické auto. Během jízdy jsem měl čas o něčem přemýšlet a poslechnout si audioknihu.
V mém životě se objevila další záhada, protože jsem úplně přestal chápat, jak moje auto funguje. Moderní auto je složité zařízení. Auto se přizpůsobuje současně desítkám různých parametrů: sešlápnutí plynu, brzda, styl jízdy, kvalita vozovky. Už nechápu, jak to funguje.
Když jsem začal pracovat na cloudu Amazon, bylo to pro mě také záhadou. Jen tato záhada je o řád větší, protože v autě je jeden řidič a v AWS jich jsou miliony. Všichni uživatelé současně řídí, sešlápnou plyn a brzdu. Je úžasné, že jdou, kam chtějí – pro mě je to zázrak! Systém se automaticky přizpůsobuje, škáluje a elasticky přizpůsobuje každému uživateli tak, že se mu zdá, že je v tomto Vesmíru sám.
Kouzlo se trochu vytratilo, když jsem později přišel pracovat jako architekt v Amazonu. Viděl jsem, jakým problémům čelíme, jak je řešíme a jak vyvíjíme služby. S rostoucím pochopením toho, jak systém funguje, se objevuje větší důvěra ve službu. Chci se tedy podělit o obrázek toho, co se skrývá pod kapotou cloudu AWS.
O čem budeme mluvit
Zvolil jsem diverzifikovaný přístup – vybral jsem 4 zajímavé služby, které stojí za řeč.
Optimalizace serveru. Pomíjivé mraky s fyzickým ztělesněním: fyzická datová centra, kde jsou fyzické servery, které hučí, zahřívají se a blikají světly.
Funkce bez serveru (Lambda) je pravděpodobně nejvíce škálovatelná služba v cloudu.
Škálování databáze. Řeknu vám o tom, jak budujeme vlastní škálovatelné databáze.
Škálování sítě. Poslední část, ve které otevřu zařízení naší sítě. To je úžasná věc – každý uživatel cloudu věří, že je v cloudu sám a ostatní tenanty vůbec nevidí.
Poznámka. Tento článek se bude zabývat optimalizací serveru a škálováním databáze. Škálování sítě se budeme zabývat v příštím článku. Kde jsou funkce bez serveru? Byl o nich zveřejněn samostatný přepis „" Hovoří o několika různých metodách škálování a podrobně pojednává o řešení Firecracker - symbióze nejlepších kvalit virtuálního stroje a kontejnerů.
Servery
Oblak je pomíjivý. Ale tato pomíjivost má stále fyzické ztělesnění - servery. Zpočátku byla jejich architektura klasická. Standardní x86 čipset, síťové karty, Linux, Xen hypervisor, na kterém byly spuštěny virtuální stroje.
V roce 2012 se tato architektura vypořádala se svými úkoly docela dobře. Xen je skvělý hypervizor, ale má jednu zásadní nevýhodu. Má toho dost vysoká režie pro emulaci zařízení. Jakmile budou k dispozici nové, rychlejší síťové karty nebo disky SSD, tato režie bude příliš vysoká. Jak se s tímto problémem vypořádat? Rozhodli jsme se pracovat na dvou frontách najednou - optimalizovat hardware i hypervizor. Úkol je velmi vážný.
Optimalizace hardwaru a hypervizoru
Dělat všechno najednou a dělat to dobře nebude fungovat. Co bylo „dobré“, bylo zpočátku také nejasné.
Rozhodli jsme se pro evoluční přístup – měníme jeden důležitý prvek architektury a vrháme ho do výroby.
Šlapeme na každé hrábě, nasloucháme stížnostem a návrhům. Poté vyměníme další součást. Po malých krocích tedy radikálně měníme celou architekturu na základě zpětné vazby od uživatelů a podpory.
Transformace začala v roce 2013 tím nejsložitějším – sítí. V С3 instance byla ke standardní síťové kartě přidána speciální karta Network Accelerator. Byl připojen doslova krátkým loopback kabelem na předním panelu. Není to hezké, ale v oblacích to není vidět. Ale přímá interakce s hardwarem zásadně zlepšila jitter a propustnost sítě.
Dále jsme se rozhodli zlepšit přístup k blokovému datovému úložišti EBS - Elastic Block Storage. Jedná se o kombinaci sítě a úložiště. Potíž je v tom, že zatímco karty Network Accelerator na trhu existovaly, neexistovala možnost jednoduše koupit hardware Storage Accelerator. Tak jsme se obrátili na startup Laboratoře Annapurna, který pro nás vyvinul speciální čipy ASIC. Umožňovaly připojení vzdálených svazků EBS jako zařízení NVMe.
V případech C4 vyřešili jsme dva problémy. První je, že jsme implementovali základ pro budoucnost slibné, ale v té době nové technologie NVMe. Zadruhé jsme výrazně odlehčili centrálnímu procesoru přenesením zpracování požadavků do EBS na novou kartu. Dopadlo to dobře, a tak je nyní Annapurna Labs součástí Amazonu.
V listopadu 2017 jsme si uvědomili, že je čas změnit samotný hypervizor.
Nový hypervizor byl vyvinut na základě upravených modulů jádra KVM.
Umožnil zásadně snížit režii emulace zařízení a pracovat přímo s novými ASIC. Instance С5 byly první virtuální stroje s novým hypervizorem běžícím pod kapotou. Pojmenovali jsme ho Nitro.
Vývoj instancí na časové ose.
Všechny nové typy virtuálních strojů, které se objevily od listopadu 2017, běží na tomto hypervizoru. Instance Bare Metal nemají hypervizor, ale také se jim říká Nitro, protože používají specializované Nitro karty.
Během následujících dvou let počet typů instancí Nitro přesáhl několik desítek: A1, C5, M5, T3 a další.
Typy instancí.
Jak fungují moderní stroje Nitro
Mají tři hlavní součásti: hypervizor Nitro (diskutovaný výše), bezpečnostní čip a karty Nitro.
Bezpečnostní čip integrované přímo do základní desky. Řídí mnoho důležitých funkcí, jako je řízení načítání hostitelského OS.
Nitro karty - Jsou čtyři druhy. Všechny jsou vyvinuty Annapurna Labs a jsou založeny na běžných ASIC. Některé z jejich firmwaru jsou také běžné.
Čtyři typy Nitro karet.
Jedna z karet je určena pro práci s síťVPC. To je to, co je vidět na virtuálních strojích jako síťová karta ENA - elastický síťový adaptér. Také zapouzdřuje provoz při jeho přenosu přes fyzickou síť (o tom si povíme v druhé části článku), řídí firewall bezpečnostních skupin a je zodpovědný za směrování a další síťové věci.
Vybrané karty pracují s blokovým úložištěm EBS a disky, které jsou zabudovány do serveru. Na hostujícím virtuálním počítači se zobrazují jako NVMe adaptéry. Jsou také zodpovědní za šifrování dat a monitorování disku.
Systém Nitro karet, hypervizoru a bezpečnostního čipu je integrován do SDN sítě resp Softwarově definovaná síť. Zodpovědný za správu této sítě (Control Plane) karta ovladače.
Samozřejmě pokračujeme ve vývoji nových ASIC. Například na konci roku 2018 vydali čip Inferentia, který vám umožní efektivněji pracovat s úlohami strojového učení.
Čip procesoru Inferentia Machine Learning.
Škálovatelná databáze
Tradiční databáze má vrstvenou strukturu. Pro velké zjednodušení rozlišujeme následující úrovně.
- SQL — pracují na něm klienti a dispečeři požadavků.
- Ustanovení transakce - tady je všechno jasné, ACID a tak.
- ukládání do mezipaměti, kterou poskytují buffer pooly.
- Protokolování — poskytuje práci s redo logy. V MySQL se nazývají Bin Logs, v PosgreSQL - Write Ahead Logs (WAL).
- Opatrování – přímý záznam na disk.
Vrstvená struktura databáze.
Existují různé způsoby škálování databází: sharding, architektura Shared Nothing, sdílené disky.
Všechny tyto metody však zachovávají stejnou monolitickou strukturu databáze. To výrazně omezuje škálování. K vyřešení tohoto problému jsme vyvinuli vlastní databázi − Amazonská Aurora. Je kompatibilní s MySQL a PostgreSQL.
Amazonská Aurora
Hlavní architektonickou myšlenkou je oddělit úrovně úložiště a protokolování od hlavní databáze.
Při pohledu do budoucna řeknu, že jsme také učinili nezávislou úroveň ukládání do mezipaměti. Architektura přestává být monolitem a získáváme další stupně volnosti ve škálování jednotlivých bloků.
Úrovně protokolování a úložiště jsou oddělené od databáze.
Tradiční DBMS zapisuje data do úložného systému ve formě bloků. V Amazon Aurora jsme vytvořili chytré úložiště, které umí mluvit jazykem redo-logy. Uvnitř úložiště mění protokoly na datové bloky, sleduje jejich integritu a automaticky zálohuje.
Tento přístup umožňuje implementovat takové zajímavé věci, jako je klonování. Funguje zásadně rychleji a ekonomičtěji díky tomu, že nevyžaduje vytvoření kompletní kopie všech dat.
Úložná vrstva je implementována jako distribuovaný systém. Skládá se z velkého počtu fyzických serverů. Každý redo log je zpracován a uložen současně šest uzlů. To zajišťuje ochranu dat a vyrovnávání zátěže.
Měřítko čtení lze dosáhnout pomocí vhodných replik. Distribuované úložiště eliminuje potřebu synchronizace mezi hlavní databázovou instancí, přes kterou zapisujeme data, a zbývajícími replikami. Je zaručeno, že aktuální data budou dostupná všem replikám.
Jediným problémem je ukládání starých dat do mezipaměti na čtených replikách. Ale tento problém se řeší přenos všech redo logů k replikám přes vnitřní síť. Pokud je log v cache, je označen jako nesprávný a přepsán. Pokud v mezipaměti není, jednoduše se zahodí.
Vyřešili jsme úložiště.
Jak škálovat úrovně DBMS
Zde je horizontální škálování mnohem obtížnější. Pojďme tedy po vyšlapané cestě klasické vertikální škálování.
Předpokládejme, že máme aplikaci, která komunikuje s DBMS prostřednictvím hlavního uzlu.
Při vertikálním škálování alokujeme nový uzel, který bude mít více procesorů a paměti.
Dále přepneme aplikaci ze starého hlavního uzlu na nový. Objevují se problémy.
- To bude vyžadovat značné prostoje aplikace.
- Nový hlavní uzel bude mít chladnou mezipaměť. Výkon databáze bude maximální až po zahřátí mezipaměti.
Jak situaci zlepšit? Nastavte proxy mezi aplikací a hlavním uzlem.
Co nám to dá? Nyní není třeba všechny aplikace ručně přesměrovávat na nový uzel. Přepnutí lze provést pod proxy a je zásadně rychlejší.
Zdá se, že problém byl vyřešen. Ale ne, stále trpíme potřebou zahřát keš. Navíc se objevil nový problém – nyní je proxy potenciálním bodem selhání.
Konečné řešení s Amazon Aurora bez serveru
Jak jsme tyto problémy vyřešili?
Zanechal proxy. Nejedná se o samostatnou instanci, ale o celou distribuovanou flotilu proxy, přes které se aplikace připojují k databázi. V případě poruchy lze téměř okamžitě vyměnit kterýkoli z uzlů.
Přidán bazén teplých uzlů různých velikostí. Pokud je tedy nutné přidělit nový uzel větší či menší velikosti, je okamžitě k dispozici. Není třeba čekat, až se načte.
Celý proces škálování je řízen speciálním monitorovacím systémem. Monitoring neustále sleduje stav aktuálního hlavního uzlu. Pokud například zjistí, že zatížení procesoru dosáhlo kritické hodnoty, upozorní skupinu teplých instancí na nutnost přidělit nový uzel.
Distribuované proxy, teplé instance a monitorování.
K dispozici je uzel s požadovaným výkonem. Do něj se zkopírují zásobníky vyrovnávacích pamětí a systém začne čekat na bezpečný okamžik k přepnutí.
Okamžik pro změnu obvykle přichází poměrně rychle. Poté je komunikace mezi proxy a starým hlavním uzlem pozastavena, všechny relace jsou přepnuty na nový uzel.
Práce s databází pokračuje.
Graf ukazuje, že odpružení je skutečně velmi krátké. Modrý graf ukazuje zatížení a červené kroky ukazují škálovací momenty. Krátkodobé poklesy v modrém grafu jsou právě tím krátkým zpožděním.
Mimochodem, Amazon Aurora umožňuje zcela ušetřit peníze a vypnout databázi, když se nepoužívá, například o víkendech. Po zastavení zátěže DB postupně snižuje výkon a na nějakou dobu se vypne. Po návratu zátěže se opět plynule zvedne.
V další části příběhu o zařízení Amazon budeme hovořit o škálování sítě. předplatit a zůstaňte naladěni, ať vám článek neunikne.
Na Vasily Pantyukhin podá zprávu “" Jaké návrhové vzory pro distribuované systémy používají vývojáři Amazonu, jaké jsou důvody selhání služeb, co je architektura založená na buňkách, Constant Work, Shuffle Sharding – to bude zajímavé. Do konference zbývá méně než měsíc - . 24. října konečné zvýšení ceny.
Zdroj: www.habr.com