Cloud – ak funguje synchronizacia?

Ahojte. Stale mi nie je jasne ako na cloude(AWS napriklad) funguje synchronizacia dat medzi jendotlivimi uzlami. Napr mam 1 web ktory mi bezi na 10 webserveroch na ktore smeruje loadbalancer navstevnikov. Ako sa riesi zosynchronizovanie DB ak navstevnik A napriklad zakupi nejaky produkt(skratka zmeni stav nejakej globalnej hodnoty) ktory sa tym vypreda a navstevnik B ktory je ale na uplne inom webserveri vidi aktualnu informaciu ze uz dany produkt nie je dostupny? Toto ma zaujima pre pripad ze su servery v jednej lokalite a pre pripad ze su v inych lokalitach(EU, US). Predpokladam ze rovnaky princip plati aj pre subory takze to nebudem dalej rozpisovat.

Tenhle problém se dá vzít z několika stran. Vezmu si jednu :) Jsou webservery a ty se automaticky zapínají a vypínají. Na webserveru tedy nesmí být žádná postradatelná data. Je tam pouze aplikace a všechna data se ukládají někde mimo. Obrázky například v AWS S3 (velké úložiště, které se samo stará o distribuci) a databáze také někde mimo. Ideálně NoSQL, které se dobře škáluje (v AWS to je DynamoDB) méně ideálně SQL (třeba MySQL) v AWS RDS. Všechna data tak jsou uložena někde mimo, takže instance se zapne a když není potřeba, tak se zahodí. Základem je, že se celá aplikace musí rozdělit na bloky (obrázky, databáze, ...) a každý se pak řeší samostatně. Drze tu doporučím vlastní články na tohle téma. Přímo tohle neřeší, ale rozebírá se to v komentářích pod nimi:

Proč jsme migrovali do cloudu Amazonu (AWS) | Souki.cz

Jak na AWS cloud – první kroky | Souki.cz

AWS cloud za hubičku! – první server, úspory a load balancer | Souki.cz

Vychytávky v Amazon cloudu | Souki.cz

Opravdu pěkné články, Souki, díky

Ještě dám příklad z praxe. Máme spoustu eshopů a ty mají nějaké layouty, což je třeba 10 TPL souborů pro každý eshop. Ty se poměrně často mění, ale ještě častěji se čtou. Je potřeba mít na všech instancích stejnou verzi, ale zároveň je potřeba s nimi pracovat rychle, takže se nemůžou při každém načtení stránky odněkud tahat. Jde se na to proto chytře.Když se udělá změna v TPL eshopu, tak se to commitne v repozitáři. Následně automat tyto soubory vyexportuje a přidá k nim soubor ".version" jehož obsahem je ID commitu (hash). To celé se uploaduje do AWS S3 a hodnota ID commitu se uloží i do Memcache (AWS Elasticache) pod klíčem eshopu.Když se pak načítá stránka, tak se web server podívá, zda má lokálně složku s TPL pro konkrétní eshop. Pokud nemá, tak si ji stáhne z S3 (to trvá třeba 300ms) a dál je používá lokálně.Při dalším načtení stránky už má TPL soubory, ale neví, jestli aktuální. Takže vezme lokální soubor ".version", a porovná ho s hodnotou v Memcache (to trvá kolem 1ms).Pokud odpovídají, tak se použijí lokální soubory. Pokud ne, stáhnou se aktuální z AWS S3 (tím se aktualizuje i ".version" a další načtení už půjde lokálně)

Vdaka Souki, tvoje clanky som cital. Ide mi prave o to "Obrázky například v AWS S3 (velké úložiště, které se samo stará o distribuci) a databáze také někde mimo. " Mam to chapat tak ze ja sa o to vobec starat nemusim a vsetko riesi dana cloudova sluzba(RDS, EBS/S3) ? Pri tje db(mysql) si to stale nejako neviem predstavit ako sa to da dostatocne rychlo zosynchronizovat.

AWS S3 je prakticky nekonečné úložiště. Jen se tam sypou soubory a ono se to samo stará o redundanci atd. Komunikuje s tím pak přes REST API - třeba CSS soubor tak jde klidně načítat přímo z S3. Nejde ale připojit jako disk (teda jde, ale je to hodně špatný nápad), takže s ním musí aplikace počítat a zapisovat do něj přímo.Je to dostatečně rychlé třeba pro přímé servírování obrázků apod, ale ne dostatečně rychlé, aby se z toho přímo načítaly PHP soubory. Doporučuju představovat si to třeba jako domácí NAS - v pohodě z toho jdou přehrávat filmy, ale Windows bych z toho nebootoval.EBS jsou disky, ze kterých instance startuje a na kterých je uložený operační systém atd. Pokud to bude webová aplikace, tak doporučuju moc se s nimi nezabývat (resp. nepoužívat je na data).Databáze se nijak nesynchronizuje - je prostě jen jedna. Jediné co jde, je mít jednu databázi jako master a další jako slave. Aplikace pak zapisuje pouze do master, ale číst může i ze slave, čímž se může rozkládat zátěž. Na replikaci mezi EU a USA je ale lepší zapomenout. U některých aplikací to možná bude fungovat, ale obvykle je lepší najít jiné řešení. Ať už se totiž vymyslí jakékoliv propojení, tak bude narážet na to, že cesta EU-USA prostě nějakou dobu trvá.Daleko praktičtější jsou pro cloud NoSQL databáze. Ty už ve své podstatě počítají s tím, že se budou škálovat. Není proto problém přidávat a ubírat instance, jako se to dělá u webserverů. Zatímco spuštění slave serveru (ze kterého se navíc může jen číst) bude u MySQL trvat třeba i pár hodin, tak instance u NoSQL startují do minutu. Zase ale mají jiné nevýhody oproti relačním databázím, takže to není úplně jednoduchá volba.Asi by ale bylo dobré upřesnit, zda řešíme provoz v rámci jednoho regionu (třeba EU) nebo celosvětově. V rámci regionu je totiž poměrně jednoduché a všechny služby AWS už s tím počítají - stačí jen správně postavit aplikaci, aby se tomu nebránila a nevymýšlela kolo. Mezi regiony se to ale začne dost komplikovat.

Ok, uz mi to dava zmysel.

U AWS jsou nejlepší read replicas, co potřebuješ číst, tak vezmeš přes replicu, případně přes load balancer s replicami a co zapisovat dáš přímo na zdrojovou DB. Mám to na několika projektech a funguje to báječně. Sice to chce zásah do programové logiky, ale využiješ efektivněji výkon a hlavně v těch replicas jsou data v reálném čase.

Napsal jdrda;1075618

U AWS jsou nejlepší read replicas, co potřebuješ číst, tak vezmeš přes replicu, případně přes load balancer s replicami a co zapisovat dáš přímo na zdrojovou DB. Mám to na několika projektech a funguje to báječně. Sice to chce zásah do programové logiky, ale využiješ efektivněji výkon a hlavně v těch replicas jsou data v reálném čase.

Není ta replikace asynchronní?

Napsal Souki;1075673

Není ta replikace asynchronní?

Těžko říct, ale i když udělám zápis a hned čtu, data už tam jsou, tak buď to mají extrémně rychlé nebo je tam zámek, dokud se to nezaktualizuje.

Napsal jdrda;1075688

Těžko říct, ale i když udělám zápis a hned čtu, data už tam jsou, tak buď to mají extrémně rychlé nebo je tam zámek, dokud se to nezaktualizuje.

Replikace v AWS RDS je asynchronní. Proto je v Cloudwatch metrika "slave lag". Ta prodleva je obvykle ve zlomku sekundy, což u spousty aplikací vůbec nevadí, ale je potřena na to pamatovat. Typicky se na to naráží, pokud se replica používá pro failover - po přepnutí na ní můžou chybět data z posledních pár sekund. Synchronní replikace se používá v případě Multi-AZ. Tam sedí instance stejné velikosti v jiné zóně a okamžitě replikuje změny, aby mohla být použita jako failover. Pokud se dotaz nepodaří provést na záložní instanci, neprovede se ani na hlavní.