Domov › Telefon › Proč potřebujeme horizontální a vertikální měřítka? Škálovatelnost systému. Horizontální škálování databázových serverů pro OLTP systémy nebo co je na trhu

Proč potřebujeme horizontální a vertikální měřítka? Škálovatelnost systému. Horizontální škálování databázových serverů pro OLTP systémy nebo co je na trhu

Neustále rostoucí počet návštěvníků stránek – vždy skvělý úspěch pro vývojáře a administrátory. Samozřejmě s výjimkou těch situací, kdy se provoz zvýší natolik, že dojde k pádu webového serveru nebo jiného softwaru. Neustálé přerušení webových stránek je pro společnost vždy velmi nákladné.

To však lze opravit. A pokud nyní uvažujete o škálování, jste na správné cestě.

Stručně řečeno, škálovatelnost je schopnost systému zvládnout velký objem provozu a přizpůsobit se jeho růstu při zachování požadovaného UX. Existují dva způsoby škálování:

Vertikální (také nazývané zvětšování): zvýšení systémové prostředky, jako je přidání paměti a výpočetní výkon. Tato metoda umožňuje rychle vyřešit problémy se zpracováním provozu, ale její zdroje se mohou rychle vyčerpat.
Horizontální (neboli škálování): přidání serverů do clusteru. Pojďme se na tuto metodu podívat blíže.

Co je horizontální škálování?

Jednoduše řečeno, cluster je skupina serverů. Nástroj pro vyrovnávání zatížení je server, který distribuuje pracovní zátěž mezi servery v clusteru. Kdykoli můžete do existujícího clusteru přidat webový server, aby zvládl větší provoz. To je podstata horizontálního škálování.

Nástroj pro vyrovnávání zatížení je zodpovědný pouze za rozhodnutí, který server v clusteru zpracuje přijatý požadavek. V zásadě funguje jako reverzní proxy.

Horizontální škálování- nepochybně více spolehlivá metoda zvýšení výkonu aplikace, ale konfigurace je obtížnější než vertikální škálování. Hlavním a nejtěžším úkolem v tomto případě je neustále udržovat všechny aplikační uzly aktualizované a synchronizované. Řekněme, že uživatel A odešle požadavek na mydomain.com, načež balancer předá požadavek serveru 1. Poté požadavek uživatele B zpracuje server 2.

Co se stane, když uživatel A provede změny v aplikaci (například nahraje soubor nebo aktualizuje obsah databáze)? Jak lze tuto změnu přenést na zbytek serverů v clusteru?

Odpověď na tyto a další otázky naleznete v tomto článku.

Oddělení serveru

Příprava systému na škálování vyžaduje oddělení serverů; je velmi důležité, aby servery s méně zdroji měly méně povinností než větší servery. Rozdělení aplikace na tyto „části“ vám navíc umožní rychle identifikovat její kritické prvky.

Řekněme, že máte aplikaci PHP, která vám umožňuje ověřovat a nahrávat fotografie. Aplikace je založena na zásobníku LAMP. Fotografie se ukládají na disk a odkazy na ně se ukládají do databáze. Výzvou je zde podpora synchronizace mezi více aplikačními servery, které sdílejí tato data (nahrané soubory a uživatelské relace).

Chcete-li tuto aplikaci škálovat, musíte oddělit webový server a databázový server. V klastru se tak objeví uzly, které sdílejí databázový server. To zvýší výkon aplikace snížením zatížení webového serveru.

V budoucnu můžete nakonfigurovat vyrovnávání zátěže; Můžete si o tom přečíst v příručce ""

Konzistence relace

S odděleným webovým serverem a databází se musíte zaměřit na zpracování uživatelských relací.

Relační databáze a síťové systémy souborů

Data relací jsou často uložena v relační databáze data (jako je MySQL), protože takové databáze se snadno konfigurují.

Toto řešení však není nejspolehlivější, protože se v tomto případě zvyšuje zatížení. Server musí zapsat do databáze každou operaci čtení a zápisu samostatná žádost a v případě náhlého nárůstu provozu má databáze tendenci selhat dříve než ostatní komponenty.

Síťové souborové systémy jsou dalším jednoduchým způsobem ukládání dat; není třeba provádět změny v databázi zdrojové texty, nicméně síťové systémy zpracovávat I/O operace velmi pomalu a to může mít dopad negativní dopad na výkonu aplikace.

Lepkavé relace

Sticky relace jsou implementovány na nástroji pro vyrovnávání zatížení a nevyžadují žádné změny aplikačních uzlů. Toto je nejpohodlnější způsob zpracování uživatelských relací. Nástroj pro vyrovnávání zatížení vždy nasměruje uživatele na stejný server, čímž eliminuje potřebu distribuovat data relace mezi zbývající uzly v clusteru.

Toto řešení má však i jeden závažný nedostatek. Nyní vyvažovač nejen rozděluje zatížení, ale také má dodatečný úkol. To může ovlivnit jeho výkon a způsobit jeho selhání.

Servery Memcached a Redis

Můžete také nakonfigurovat jeden nebo více další servery ke zpracování relací. Tohle je nejvíc spolehlivým způsobemřešení problémů souvisejících se zpracováním relace.

Závěrečné akce

Horizontální škálování aplikace se zpočátku zdá jako velmi složité a matoucí řešení, ale pomáhá eliminovat vážné problémy s provozem. Hlavní věcí je naučit se pracovat s vyrovnávačem zátěže, abyste pochopili, které komponenty vyžadují další konfiguraci.

Škálování a výkon aplikace spolu velmi úzce souvisí. Samozřejmě ne všechny aplikace a weby potřebují škálování. Na to je však lepší myslet předem, nejlépe ve fázi vývoje aplikace.

Štítky: ,

Škálovatelnost – schopnost zařízení zvýšit svou
možnosti
zvýšením počtu funkčních bloků,
vystupovat samostatně a
stejné úkoly.
Glossary.ru

Obvykle lidé začnou přemýšlet o škálování, když jeden
server se nemůže vypořádat s prací, která mu byla přidělena. S čím přesně není?
vyrovnat se? Provoz jakéhokoli webového serveru se z velké části scvrkává na základy
Povoláním počítačů je zpracování dat. Odpověď na požadavek HTTP (nebo jakýkoli jiný).
zahrnuje provádění některých operací s některými daty. resp.
máme dvě hlavní entity – data (charakterizovaná svým objemem) a
výpočty (charakterizované složitostí). Server si s tím nemusí být schopen poradit
fungovat kvůli velkému množství dat (nemusí se fyzicky vejít
server), nebo kvůli velké výpočetní zátěži. Tady se mluví
samozřejmě o celkové zátěži - náročnost vyřízení jednoho požadavku může být
je malý, ale velký počet z nich může zahltit server.

Budeme mluvit hlavně o škálování na příkladu
typický rostoucí webový projekt, ale zde popsané principy jsou vhodné i pro
další oblasti použití. Nejprve se podíváme na architekturu projektu a jednoduchost
jeho distribuce komponenty na několik serverů a pak si o tom promluvíme
škálování výpočtů a dat.

Typická architektura webu

Život typického webu začíná velmi jednoduchou architekturou
- jedná se o jeden webový server (svou roli obvykle hraje Apache),
který se stará o veškerou práci při obsluze požadavků HTTP,
přijaté od návštěvníků. Klientům pak dává tzv. „statiku“.
na disku serveru leží soubory, které nevyžadují zpracování: obrázky (gif,
jpg, png), šablony stylů (css), klientské skripty (js, swf). Stejný server
odpovídá na dotazy, které vyžadují výpočty - obvykle formování
html stránky, i když někdy jsou obrázky a další dokumenty vytvářeny za běhu.
Nejčastěji jsou odpovědi na takové požadavky generovány skripty napsanými v PHP,
perl nebo jiné jazyky.

Nevýhodou takového jednoduchého pracovního schématu je, že se liší
povaha požadavků (nahrávání souborů z disku a výpočetní práce skripty)
zpracovává stejný webový server. Výpočetní dotazy vyžadují
uchovávat mnoho informací v paměti serveru (překladač skriptovacího jazyka,
samotné skripty, data, se kterými pracují) a dá zabrat hodně
výpočetní prostředky. Vydávání statických dat naopak vyžaduje málo prostředků
procesor, ale může zabírat dlouho, pokud má klient nízkou
rychlost komunikace. Vnitřní struktura server Apache předpokládá, že každý
připojení je řešeno samostatným procesem. To je vhodné pro spouštění skriptů,
není však optimální pro zpracování jednoduché dotazy. Ukazuje se, že těžké (od
skripty a další data) Procesy Apache tráví spoustu času čekáním (nejprve při příjmu
požadavek, poté při odesílání odpovědi), plýtvání pamětí serveru.

Řešením tohoto problému je distribuce zpracovatelské práce
žádosti mezi dvěma různé programy- tj. rozdělení na frontend a
backend Odlehčený frontend server plní úkoly obsluhy statického obsahu a ostatní
požadavky jsou přesměrovány (proxy) na backend, kde se formace provádí
stránky. O čekání na pomalé klienty se stará také frontend, a pokud jej používá
multiplexování (když jeden proces obsluhuje několik klientů – tzv
práce, například nginx nebo lighttpd), pak čekání prakticky nic
náklady.

Mezi další součásti webu je třeba poznamenat databázi, v
který obvykle ukládá hlavní systémová data – nejoblíbenější jsou zde
zdarma DBMS MySQL a PostgreSQL. Úložiště je často přidělováno samostatně
binární soubory, který obsahuje obrázky (například ilustrace k článkům
stránky, avatary a fotografie uživatelů) nebo jiné soubory.

Obdrželi jsme tedy schéma architektury sestávající z
několik komponent.

Typicky, na začátku života webu, všechny komponenty architektury
umístěné na stejném serveru. Pokud přestane zvládat zátěž, pak
existuje jednoduché řešení - přesunout nejsnáze oddělitelné části na jiné
server. Nejjednodušší způsob, jak začít s databází, je přesunout ji na samostatný server a
změnit přístupové údaje ve skriptech. Mimochodem, v tuto chvíli stojíme před námi
důležitost správné architektury programový kód. Pokud pracujete s databází
předloženo samostatný modul, společné pro celý web – poté opravte parametry
připojení bude snadné.

Způsoby dalšího oddělení komponent jsou také jasné - například můžete přesunout frontend na samostatný server. Ale obvykle frontend
vyžaduje málo systémových prostředků a v této fázi jeho odstranění nebude znamenat významné
zvýšení produktivity. Nejčastěji je stránka omezena výkonem.
skripty - generování odpovědi (html stránky) zabere příliš mnoho dlouho.
Dalším krokem je proto obvykle škálování backendového serveru.

Rozdělení výpočtu

Typická situace pro rostoucí web - databáze již existuje
přesunuto na samostatný stroj, rozdělení na frontend a backend je dokončeno,
provoz však stále roste a backend nemá čas na zpracování
žádosti. To znamená, že musíme výpočty rozdělit do několika
servery. To je snadné - stačí koupit druhý server a nainstalovat jej
Obsahuje programy a skripty nezbytné pro fungování backendu.
Poté se musíte ujistit, že požadavky uživatelů jsou distribuovány
(vyvážené) mezi přijatými servery. O různými způsoby vyvažování
bude diskutováno níže, ale prozatím poznamenáváme, že to obvykle provádí frontend,
který je nakonfigurován tak, aby rovnoměrně rozděloval požadavky mezi
servery.

Je důležité, aby všechny backend servery byly schopny správně
reagovat na žádosti. To obvykle vyžaduje práci s každým z nich
stejný aktuální soubor dat. Pokud všechny informace uložíme do jednoho
databáze, pak sám DBMS poskytne sdílení a konzistence dat.
Pokud jsou některá data uložena lokálně na serveru (například php sessions
klient), pak byste měli přemýšlet o jejich převedení na sdílené úložiště, nebo o více
komplexní algoritmus distribuce požadavků.

Nejen práci lze distribuovat na několik serverů
skripty, ale také výpočty prováděné databází. Pokud DBMS provádí hodně
složitých dotazů, které zabírají čas CPU serveru, můžete vytvořit několik
kopie databáze na různých serverech. To vyvolává problém synchronizace
data při změnách a lze zde použít několik přístupů.

Synchronizace na aplikační úrovni. V tomto případě naše
skripty nezávisle zapisují změny do všech kopií databáze (a samy nesou
odpovědnost za správnost údajů). To není nejlepší možnost protože on
vyžaduje pečlivou implementaci a je vysoce odolný vůči chybám.
Replikace- tedy automatická replikace
změny provedené na jednom serveru ovlivní všechny ostatní servery. Obvykle kdy
Při použití replikace se změny vždy zapisují na stejný server – nazývá se master a zbývající kopie se nazývají slave. Většina DBMS má
vestavěný popř externí fondy organizovat replikaci. Rozlišovat
synchronní replikace – v tomto případě bude čekat požadavek na změnu dat
dokud se data nezkopírují na všechny servery, a teprve potom se úspěšně dokončí – a asynchronně – v tomto případě se změny zkopírují na podřízené servery z
zpoždění, ale požadavek na zápis se dokončí rychleji.
Multimistr replikace. Tento přístup je podobný
předchozí, ale zde můžeme změnit data bez přístupu
jeden konkrétní server, ale na jakoukoli kopii databáze. Zároveň změny
synchronně nebo asynchronně budou převedeny do jiných kopií. Někdy se toto schéma nazývá
termín "databázový klastr".

možné různé možnosti distribuce systému mezi servery.
Například můžeme mít jeden databázový server a několik backendů (velmi
typické schéma), nebo naopak - jeden backend a několik databází. Co když škálujeme
jak backendový server, tak databázi, pak můžete zkombinovat backend a kopii databáze
jedno auto. V každém případě, jakmile budeme mít několik kopií
jakýkoli server, vyvstává otázka, jak mezi ně správně distribuovat
zatížení.

Metody vyvažování

Vytvořme několik serverů (pro jakýkoli účel - http, databáze atd.), z nichž každý může zpracovávat požadavky. Před
stojíme před úkolem, jak mezi ně rozdělit práci, jak zjistit jakou
server poslat požadavek? Existují dva hlavní způsoby distribuce požadavků.

Vyrovnávací jednotka. V tomto případě klient odešle požadavek jednomu
pevný server, který zná, a ten již přesměruje požadavek na jeden z
fungující servery. Typickým příkladem je web s jedním frontendem a několika
back-end servery, na které jsou požadavky posílány proxy. „Klient“ však může
být uvnitř našeho systému – skript může například odeslat požadavek
na databázový proxy server, který předá požadavek jednomu ze serverů DBMS.
Samotný vyrovnávací uzel může pracovat jak na samostatném serveru, tak na jednom
z fungujících serverů.
Výhody tohoto přístupu jsou
o které klient nemusí nic vědět vnitřní struktura systémy - o množství
serverech, o jejich adresách a funkcích - pouze
vyvažovačka Nevýhodou však je, že vyvažovací jednotka je jednoduchá
bod selhání systému - pokud selže, bude to celý systém
nefunkční. Navíc, kdy těžký náklad balancer se může jednoduše zastavit
vyrovnat se s jejich prací, takže tento přístup není vždy použitelný.
Vyvažování na straně klienta. Pokud se chceme vyhnout
existuje jediný bod selhání alternativní možnost- svěřit výběr serveru
samotnému klientovi. V tomto případě musí klient vědět o vnitřní struktuře našeho
systémy, aby si mohly správně vybrat, na který server se obrátit.
Nepochybnou výhodou je absence bodu selhání - pokud je jedním z nich
servery bude klient moci kontaktovat ostatní. Cena za to však je
složitější klientská logika a menší flexibilita vyvažování.

Samozřejmě existují i kombinace těchto přístupů. Například,
takový známá metoda vyvažování zátěže, stejně jako vyvažování DNS, je založeno na
že při určování IP adresy webu je dán klient
adresu jednoho z několika stejných serverů. DNS tedy funguje jako a
role vyrovnávacího uzlu, ze kterého klient přijímá „distribuci“. Však
samotná struktura DNS serverů implikuje absenci bodu selhání z důvodu
duplikace – tedy spojení výhod dvou přístupů. Samozřejmě, tenhle
Metoda vyvažování má i nevýhody – například takový systém je obtížně dynamicky
obnovit.

Práce s webem se obvykle neomezuje na jeden požadavek.
Proto je při navrhování důležité pochopit, zda mohou sekvenční dotazy
klienta správně zpracovávají různé servery, nebo to musí být klient
připojen k jednomu serveru při práci s webem. To je zvláště důležité, pokud
web ukládá dočasné informace o relaci uživatele (v tomto
V tomto případě je možná i distribuce zdarma – pak je ale nutné skladovat
sessions (úložiště společné pro všechny servery). „Připoutat“ návštěvníka
můžete určit konkrétní server jeho IP adresou (která se však může změnit),
nebo pomocí cookie (ve kterém je předem zaznamenán identifikátor serveru), nebo dokonce
jednoduše přesměrováním na požadovanou doménu.

Na druhou stranu počítačové servery nemusí mít stejná práva.
V některých případech je výhodné udělat opak, alokovat pro něj samostatný server
zpracování požadavků jednoho typu – a získat vertikální členění
funkcí. Poté klient nebo vyrovnávací uzel vybere server
v závislosti na typu obdržené žádosti. Tento přístup nám umožňuje se oddělit
důležité (nebo naopak ne kritické, ale obtížné) požadavky od ostatních.

Distribuce dat

Naučili jsme se distribuovat výpočty, takže velké
docházka pro nás není problém. Objemy dat však stále rostou,
jejich skladování a zpracování je stále obtížnější - což znamená, že je čas postavit
distribuované úložiště dat. V tomto případě již nebudeme mít jedno resp
obsahuje několik serverů úplná kopie databází. Místo toho data
budou distribuovány podle různé servery. Jaká schémata distribuce jsou možná?

Vertikální distribuce(vertikální dělení) - v nejjednodušším případě
představuje přenos jednotlivých databázových tabulek na jiný server. Na
V tomto případě budeme muset změnit skripty pro přístup k různým serverům
různé údaje. V limitu můžeme každou tabulku uložit na samostatný server
(ačkoli v praxi to pravděpodobně nebude přínosné). Pochopitelně s tímhle
distribuce, ztrácíme možnost vytvářet SQL dotazy, které kombinují data
dvě tabulky umístěné na různých serverech. V případě potřeby můžete implementovat
sloučení logiky v aplikaci, ale nebude to tak efektivní jako v DBMS.
Proto při rozdělování databáze na oddíly musíte analyzovat vztahy mezi tabulkami,
distribuovat co nejvíce nezávislé tabulky.
Složitější případ
vertikální distribuce základny je rozklad jedné tabulky, kdy část
některé z jeho sloupců skončí na jednom serveru a některé z nich na jiném. Tato technika
je méně častý, ale dá se použít např. k oddělení malých
a často aktualizovaná data z velkého objemu zřídka používaných dat.
Horizontální distribuce(horizontální dělení) - skládá se z
distribuce dat z jedné tabulky na několik serverů. Ve skutečnosti, na
každý server vytvoří tabulku stejné struktury a uloží ji
určitý údaj. Data můžete mezi servery distribuovat různými způsoby
kritéria: podle rozsahu (záznamy s id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
A, zbytek - na server B) nebo podle hash hodnoty určitého pole
evidence. Horizontální rozdělení dat umožňuje ukládat neomezeně
množství záznamů však výběr komplikuje. Nejúčinnější způsob výběru
záznamy pouze v případě, že je známo, na kterém serveru jsou uloženy.

Pro výběr správné schéma je nutná distribuce dat
pečlivě analyzovat strukturu databáze. Stávající tabulky (a příp
jednotlivá pole) lze klasifikovat podle četnosti přístupu k záznamům, podle četnosti
aktualizace a vztahy (nutnost provést výběr z několika
tabulky).

Jak již bylo zmíněno výše, kromě databáze web často potřebuje
úložiště pro binární soubory. Distribuované systémyúložiště souborů
(ve skutečnosti souborové systémy) lze rozdělit do dvou tříd.

Pracovní na úrovni operační systém . Navíc pro
aplikace pracující se soubory v takovém systému se neliší od pravidelná práce S
soubory. Výměnu informací mezi servery zajišťuje operační systém.
Příklady takových souborových systémů zahrnují dlouho známé
NFS rodina nebo méně známá, ale více moderní systém Lesk.
Realizováno na aplikační úrovni distribuováno
repozitáře znamenají, že práce na výměně informací se provádí sama
aplikace. Obvykle jsou umístěny funkce pro práci s úložištěm
samostatná knihovna. Jedním z nápadných příkladů takového úložiště je MogileFS, vyvinutý společností
od tvůrců LiveJournalu. Dalším běžným příkladem je použití
Protokol WebDAV a úložiště, které jej podporuje.

Nutno podotknout, že nejen distribuce dat rozhoduje
otázka skladování, ale částečně i otázka rozložení zátěže - na každé
server se stává méně záznamů, a proto jsou zpracovávány rychleji.
Kombinace metod distribuce výpočtů a dat umožňuje stavět
potenciálně neomezeně škálovatelná architektura schopná pracovat s
libovolné množství dat a jakékoli zatížení.

Závěry

Abychom shrnuli řečené, zformulujme závěry ve formě stručných tezí.

Dvěma hlavními (a souvisejícími) výzvami škálování jsou distribuce výpočetní techniky a distribuce dat
Typická architektura webu zahrnuje oddělení rolí a
zahrnuje frontend, backend, databázi a někdy úložiště souborů
Pokud ne velké objemyúdaje a těžkých břemen uplatnit
zrcadlení databáze - synchronní nebo asynchronní replikace
Pro velké objemy dat je nutné databázi distribuovat – rozdělit
to vertikálně nebo horizontálně
Binární soubory jsou uloženy v distribuovaných souborových systémech
(implementováno na úrovni OS nebo v aplikaci)
Bilancování (rozdělení požadavků) může být jednotné popř
rozděleno podle funkčnosti; s vyrovnávacím uzlem, nebo na straně klienta
Správná kombinace metod vám umožní odolat jakékoli zátěži;)

Odkazy

Ve studiu tohoto tématu můžete pokračovat na zajímavých anglicky psaných webech a blozích.

Ahoj! Jsem Alexander Makarov a můžete mě znát z frameworku Yii – jsem jedním z jeho vývojářů. Mám také práci na plný úvazek – a to už není startup – Stay.com, která se zabývá cestováním.

Dnes budu mluvit o horizontálním škálování, ale velmi, velmi obecně.

Co je to vlastně škálování? Je to příležitost ke zvýšení produktivity projektu minimální čas přidáním zdrojů.

Škálování obvykle nezahrnuje přepisování kódu, ale buď přidávání serverů nebo navyšování zdrojů stávajícího. Tento typ zahrnuje vertikální a horizontální měřítko.

Vertikální je, když se přidá více RAM, disků atd. již na existující server, a horizontální je, když dávají více serverů do datových center a tamní servery již nějak interagují.

Nejúžasnější otázka, kterou si kladou, je: proč je to potřeba, když mi na jednom serveru vše funguje dobře? Ve skutečnosti musíme zkontrolovat, co se stane. To znamená, že to nyní funguje, ale co bude později? Existují dva skvělé nástroje - ab a siege, které, jak se zdá, dohánějí mrak konkurenčních uživatelů, kteří začnou bušit server, zkoušet si vyžádat stránky, posílat nějaké požadavky. Musíte jim říct, co mají dělat, a nástroje generují zprávy, jako je tato:

Hlavní dva parametry: n - počet požadavků, které je třeba provést, c - počet souběžných požadavků. Kontrolují tak konkurenci.

Na výstupu dostaneme RPS, tzn. počet požadavků za sekundu, které je server schopen zpracovat, ze kterého bude zřejmé, kolik uživatelů dokáže obsloužit. Vše samozřejmě závisí na projektu, liší se, ale většinou vyžaduje pozornost.

Je zde ještě jeden parametr – Doba odezvy – doba odezvy, během které server průměrně obsluhoval stránku. Liší se, ale je známo, že kolem 300 ms je norma a cokoliv vyššího není moc dobré, protože těchto 300 ms zpracuje server a k tomu se přidá dalších 300-600 ms, které zpracuje klient. , tj. Zatímco se vše načítá - styly, obrázky a zbytek - čas také plyne.

Stává se, že se vlastně ještě není třeba starat o škálování - jdeme na server, aktualizujeme PHP, získáme 40% nárůst výkonu a vše je v pohodě. Dále nakonfigurujeme Opcache a vyladíme ji. Mimochodem, Opcache je vyladěna stejně jako APC, se skriptem, který najdete v repozitáři Rasmuse Lerdorfa a který ukazuje hity a miss, kde hity jsou kolik krát PHPšel do pokladny a misa - kolikrát šel do souborový systém získat soubory. Pokud spustíme celý web nebo spustíme nějaký prohledávač odkazů, nebo do něj ručně strčíme, pak budeme mít statistiky o těchto návštěvách a chybách. Pokud je 100 % zásahů a 0 % chyb, pak je vše v pořádku, ale pokud jsou chybky, je třeba zvýraznit více paměti aby se celý náš kód vešel do Opcache. Tento běžná chyba, což přiznávají - vypadá to, že tam je Opcache, ale něco nefunguje...

Často se také začnou usazovat, ale vůbec se na to nedívají, a proto vše funguje pomalu. Nejčastěji jdeme do databáze, koukáme - nejsou tam indexy, dáme indexy - vše funguje hned, stačí na další 2 roky, krása!

Musíte také povolit mezipaměť, nahradit apache nginx a php-fpm, abyste ušetřili paměť. Všechno bude skvělé.

Všechny výše uvedené jsou docela jednoduché a dají vám čas. Je čas na to, že to jednoho dne nebude stačit, a na to se musíme připravit už teď.

Jak můžete obecně pochopit, v čem je problém? Buď už máte vysokou zátěž, a to nemusí být nutně nějaký šílený počet požadavků atd., je to tehdy, když váš projekt zátěž nezvládne, a to již nelze řešit triviálními způsoby. Musíte růst buď širší, nebo vyšší. Něco je potřeba udělat a s největší pravděpodobností je na to málo času, je potřeba něco vymyslet.

První pravidlo je nikdy nic nedělat naslepo, tzn. potřebujeme vynikající monitorování. Nejprve získáme čas na některé zřejmé optimalizace, jako je povolení mezipaměti nebo ukládání domovské stránky do mezipaměti atd. Pak nastavíme monitoring, ten nám ukáže, co chybí. A to vše se mnohokrát opakuje – nikdy nemůžete přestat sledovat a zlepšovat.

Co může sledování ukázat? Můžeme se opřít o disk, tzn. do souborového systému, do paměti, do procesoru, do sítě... A může se stát, že se vše zdá být více či méně, ale objeví se nějaké chyby. To vše se řeší různými způsoby. Problém s diskem můžete vyřešit například přidáním nového disku na stejný server, nebo můžete nainstalovat druhý server, který bude pracovat pouze se soubory.

Na co si dát při sledování právě teď pozor? Tento:

dostupnost, tzn. zda je server naživu nebo ne;
nedostatek diskových prostředků, procesoru atd.;
chyby.

Jak to vše sledovat?

Zde je seznam skvělých nástrojů, které vám umožní sledovat zdroje a zobrazovat výsledky velmi pohodlným způsobem:

První 4 nástroje lze nainstalovat na server, jsou výkonné a cool. A ServerDensity je hostován někým, tj. platíme za to peníze a může shromažďovat všechna data ze serverů a zobrazovat je pro analýzu.

Existují dvě dobré služby pro sledování chyb:

Obvykle takto sledujeme chyby - buď vše zapíšeme do logu a pak se na to podíváme, nebo kromě toho začneme posílat e-maily nebo SMS vývojářům, to je normální, ale jakmile máme dav lidí přichází do služby, a tam je nějaký druh - chyba, začíná se to velmi opakovat velký počet Jednou e-mail začne šíleně spamovat, nebo se úplně zaplní, nebo vývojář úplně ztratí pozornost a začne e-maily ignorovat. Výše uvedené služby berou a shromažďují chyby stejného typu do jednoho velkého balíčku a navíc počítají, kolikrát se během nich chyby vyskytly v poslední době a celá záležitost je automaticky zařazena do priorit.

Sentry lze nainstalovat na váš server, je tam zdrojový kód, ale Rollbar ne, ale Rollbar je lepší, protože si účtuje peníze za počet chyb, tzn. vybízí je k nápravě.

Pokud jde o oznámení, zopakuji, že byste neměli spamovat, protože by se ztratila vaše pozornost.

Co je obecně potřeba analyzovat?

RPS a doba odezvy – pokud naše doba odezvy začne klesat, musíme něco udělat.

Počet procesů, vláken a velikostí front – pokud se to vše začne množit, zanášet atd., tak tady zase není něco v pořádku, musíme to rozebrat podrobněji a nějak změnit infrastrukturu.

Také stojí za to podívat se na obchodní analýzu. Google Analytics Je skvělý pro typy webových stránek a mixpanel je skvělý pro protokolování událostí, funguje na desktopových aplikacích, mobilních aplikacích a na webu. Můžete psát na základě nějakých vlastních dat, ale poradil bych hotové služby. Jde o to, že náš monitoring dokáže ukázat, že služba žije, že vše funguje, že celková doba odezvy je normální, ale když, řekněme, začneme sledovat registrace v mixpanelu, ukáže se, že jich je nějak málo. V tomto případě se musíte podívat na to, jak rychle jsou určité události a stránky zpracovávány a jaké jsou problémy Projekt by měl být vždy „propojen“ s analýzou, abyste vždy věděli, co se děje, a nepracoval naslepo.

Zátěž obecně vzniká buď plánovaně nebo ne, může vznikat postupně, nemusí postupně:

Jak se vypořádat se zátěží? O všem rozhoduje byznys a důležitá je pouze cena emise. Důležité:

aby služba fungovala,
aby to nebylo moc drahé a nezruinovalo to firmu.

Zbytek není moc důležitý.

Pokud je levnější profilovat, optimalizovat, zapisovat do mezipaměti, opravovat některé konfigurace, pak by to mělo být provedeno bez přemýšlení o škálování nebo nákupu dalšího hardwaru atd. Stává se ale, že hardware je levnější než práce programátora, zvláště pokud jsou programátoři velmi důvtipní. V tomto případě již začíná škálování.

Na obrázku je modrá věc internet, ze kterého přicházejí požadavky. Je nainstalován balancer, jehož jediným úkolem je distribuovat požadavky na samostatné front-end servery, přijímat od nich odpovědi a odesílat je klientovi. Tady jde o to, že 3 servery dokážou zpracovat (ideálně) 3x více požadavků, bez jakýchkoliv režijních nákladů na síť a práci samotného balanceru.

Co nám to dává? Výše zmíněná schopnost zpracovat více požadavků a také spolehlivost. Pokud v tradičním schématu nginx nebo aplikace spadne, nebo se disk dostane do problémů atd., vše se zastaví. Zde, pokud jeden z našich frontendů selže, pak je to v pořádku, balancer to s největší pravděpodobností pochopí a pošle požadavky na zbývající 2 servery. Může to být trochu pomalejší, ale to není velký problém.

Obecně je PHP skvělé pro škálování, protože se ve výchozím nastavení řídí principem Share Nothing. To znamená, že když vezmeme, řekněme, Javu pro web, tak se tam aplikace spustí, načte veškerý kód, zapíše co nejvíce dat do paměti programu, všechno se tam točí, funguje, na požadavek se stráví velmi málo času , velmi málo dodatečné zdroje. Existuje však přepadení – protože. Aplikace je napsaná tak, že musí běžet na jedné instanci, cachovat, číst z vlastní paměti, pak z ní při škálování nic dobrého nevzejde. Ale v PHP není ve výchozím nastavení nic běžného, a to je dobře. Cokoli chceme sdílet, vložíme do memcached a memcached lze číst z více serverů, takže vše je skvělé. Tito. U vrstvy aplikačního serveru je dosaženo volné vazby. To je úžasné.

Jak vyvážit zátěž obecně?

Nejčastěji to dělal Squid nebo HAProxy, ale to bylo dříve. Nyní autor nginx vzal a rozdělil balancer z nginx+ na nginx, takže nyní umí vše, co dělal Squid nebo HAProxy. Pokud začne selhávat, můžete nainstalovat nějaký skvělý drahý hardwarový balancer.

Problémy, které balancer řeší, jsou jak vybrat server a jak ukládat relace? Druhý problém je čistě PHP a server lze vybrat buď jeden po druhém ze seznamu, nebo podle geografie některých IP, nebo podle nějaké statistiky (nginx podporuje nejméně připojené, tj. který server má méně připojení, vyhodí je to na něj). Můžeme napsat nějaký kód pro balancer, který vybere, jak má fungovat.

Co když narazíme na balancer?

Existuje něco jako DNS Round robin - to je skvělý trik, který nám umožňuje neutrácet peníze za hardwarový balancer. co děláme? Vezmeme DNS server (většinou nikdo nehostí DNS server, je drahý, málo spolehlivý, když selže, nic dobrého z toho nevzejde, každý používá nějakou firmu), registrujeme více než jeden server do A záznamu , ale pár. Budou to A-záznamy z různých balancerů. Když tam prohlížeč přejde (ve skutečnosti neexistují žádné záruky, ale všechno moderní prohlížeče takto fungují), vybere si postupně jednu IP adresu z A-záznamů a skončí buď na jednom balanceru, nebo na druhém. Zátěž se samozřejmě nemusí rozložit rovnoměrně, ale alespoň se rozloží a vyvažovačka toho zvládne trochu víc.

Co dělat se sezeními?

Ve výchozím nastavení máme relace v souborech. Není tomu tak, protože každý z našich front-end serverů bude uchovávat relace ve svém vlastním souborovém systému a uživatel může přejít nejprve na jeden, pak na druhý, pak na třetí, tzn. pokaždé ztratí relace.

Existuje zřejmá touha vytvořit společný souborový systém a připojit NFS. Ale nemusíte to dělat - je to strašně pomalé.

Můžete to zapsat do databáze, ale také to nestojí za to, protože Databáze není pro tuto práci optimální, ale pokud nemáte jinou možnost, pak v zásadě postačí.

Do memcached můžete psát, ale velmi, velmi opatrně, protože memcached je koneckonců cache a má tendenci se vymazat, jakmile má málo zdrojů nebo není kam zapisovat nové klíče - pak se začne ztrácet staré bez varování se relace začnou ztrácet. Musíte to buď sledovat, nebo zvolit stejný Redis.

Redis - normální řešení. Jde o to, že máme Redis na samostatném serveru a všechny naše frontendy tam spěchají a začínají číst své relace z Redisu, ale Redis je jednovláknový a dříve nebo později se můžeme dostat do problémů je nainstalován stejný nginx a je informován, že potřebuje provést relaci, takže když uživatel přijde na server a dostane cookie relace, dostane se následně pouze na tento server ukazuje se, že pokud je Redis na každé instanci, jsou tam relace a propustnost čtení a zápisu bude mnohem lepší.

Co takhle cookies? Můžete si zapisovat do coockies, nebude žádné úložiště, vše je v pořádku, ale zaprvé musíme stále někam umístit data relace, a pokud začneme zapisovat do kulíšků, může se zvětšit a nevejde se do úložiště, ale , za druhé, do cookies můžete ukládat pouze ID a i tak budeme muset kontaktovat databázi pro některá data relace. V zásadě je to normální, problém to řeší.

Je tu skvělá věc - proxy pro memcached a Redis:

Zdá se, že po vybalení podporují paralelizaci, ale dělají to způsobem, o kterém bych neřekl, že je velmi optimální. Ale tato věc - twemproxy - funguje přibližně jako nginx s PHP, tzn. jakmile obdrží odpověď, okamžitě odešle data a uzavře spojení na pozadí, je rychlejší a spotřebovává méně zdrojů. Velmi dobrá věc.

Velmi často se tato chyba „cyklování“ vyskytuje, když začnou psát, například „Nepotřebuji sezení! Nyní vytvořím úžasný žeton, který se bude přenášet tam a zpět“... Ale když se nad tím zamyslíte, je to opět sezení.

PHP má takový mechanismus jako session handler, tzn. můžeme si dát vlastní handler a zapisovat do cookies, do databáze, do Redis - kdekoliv, a to vše bude fungovat se standardním startem relace atd.

Relace by měly být uzavřeny pomocí této skvělé metody.

Jakmile si vše přečteme z relace, nebudeme tam psát, musí být uzavřena, protože relace je často blokována. Ve skutečnosti by měl být blokován, protože bez blokování budou problémy s konkurencí. To je okamžitě vidět na souborech na jiných úložištích, blokátory nejsou dostupné pro celý soubor najednou, a to je o něco jednodušší.

Co dělat se soubory?

Můžete se s nimi vypořádat dvěma způsoby:

nějaké specializované řešení, které poskytuje abstrakci, a pracujeme se soubory jako se souborovým systémem. Je to něco jako NFS, ale NFS není potřeba.
„sharding“ pomocí PHP.

Specializované řešení z toho, co skutečně funguje, je GlusterFS. To je něco, co si můžete nastavit sami. Jde to, je to rychlé, dává to stejné rozhraní jako NFS, jen to funguje normální snesitelnou rychlostí.

A Amazon S3 je, pokud jste v cloudu Amazon, také dobrý souborový systém.

Pokud implementujete ze strany PHP, existuje nádherná knihovna Flysystem, pokrytá vynikajícími testy, lze s ní pracovat se všemi druhy souborových systémů, což je velmi pohodlné. Pokud okamžitě zapíšete veškerou práci se soubory s touto knihovnou, přenos z místního souborového systému do Amazon S3 nebo jiných bude jednoduchý - přepište řádek v konfiguraci.

Jak to funguje? Uživatel si stáhne soubor z prohlížeče, může buď přejít na frontend a odtud se šířit mezi souborovými servery, nebo na každém souborový server Vytvoří se skript pro nahrávání a soubor se nahraje přímo do systému souborů. Paralelně se do databáze zapíše, který soubor je na kterém serveru, a odtud ho můžeme přímo číst.

Nejlepší je distribuovat soubory pomocí nginx nebo Varnish, ale je lepší dělat vše s nginx, protože to všichni milujeme a používáme - zvládne to, je to dobré.

Co se děje s naší databází?

Pokud vše dopadne na PHP kód, uděláme spoustu frontendů a stále se obracíme na jednu databázi – ta bude zvládat poměrně dlouhou dobu. Pokud zatížení není hrozné, databáze žije dobře. Například jsme udělali JOINy o 160 milionech řádků v tabulce a všechno bylo skvělé, všechno běželo dobře, ale tam by se mělo alokovat více RAM do vyrovnávacích pamětí, do mezipaměti...

Co dělat s databází, když na ni narazíme? Existují techniky, jako je replikace. Obvykle se provádí replikace master-slave a existuje replikace master-master. Můžete provést replikaci ručně, můžete provést sharding a můžete provést rozdělení.

Co je hlavní otrok?

Jeden server je vybrán jako hlavní a několik serverů je vybráno jako sekundární. Zapisuje se do hlavního a můžeme číst z pána, nebo můžeme i z otroků (na obrázku jsou červené šipky to, co píšeme, zelené to, co čteme). V typickém projektu máme mnohem více čtení než zápisů. Existují atypické projekty.

V případě typického projektu umožňuje velké množství slave odlehčit jak masteru, tak obecně zvýšit rychlost čtení.

To také zajišťuje odolnost proti chybám – pokud jeden z podřízených jednotek selže, není třeba nic dělat. Pokud pán padne, můžeme z jednoho z otroků rychle udělat pána. Pravda, většinou se to nedělá automaticky, jde o nouzovou situaci, ale možnost existuje.

No a zálohy. Každý dělá zálohy databází jinak, někdy se to dělá s výpisem MySQL a to zamrzí celý projekt, což není moc dobré. Ale pokud vytvoříte zálohu z nějakého slave, poté, co jste to nejprve zastavili, uživatel si ničeho nevšimne. To je úžasné.

Kromě toho lze provádět těžké výpočty na otrokech, aby neovlivnily hlavní základnu, hlavní projekt.

Existuje něco jako rozdělení čtení/zápisu Existují 2 skupiny serverů – hlavní, podřízený, připojení na vyžádání a logika výběru připojení se liší. Jde o to, že pokud budeme vždy číst od otroků a vždy psát pánovi, dojde k malému přepadení:

těch. replikace neproběhne okamžitě a neexistuje žádná záruka, že byla dokončena, když vzneseme jakýkoli požadavek.

Existují dva typy vzorků:

pro čtení nebo výstup;
pro nahrávání, tedy když jsme něco vybrali a pak je potřeba toto něco změnit a zapsat zpět.

Pokud je ukázka pro zápis, tak můžeme buď vždy číst z masteru a zapisovat do masteru, nebo můžeme provést „SHOW SLAVE STATUS“ a podívat se tam na Seconds_Behind_Master (pro PostgreSQL je na obrázku i super-dotaz) - ukáže nám to číslo. Pokud je 0 (nula), vše již bylo replikováno a můžete bezpečně číst z podřízeného zařízení. Pokud je číslo větší než nula, pak se musíme podívat na hodnotu - buď bychom měli chvíli počkat a pak číst z slave, nebo rovnou číst z mastera. Pokud máme NULL, znamená to, že jsme to ještě nereplikovali, něco se zaseklo a musíme se podívat na protokoly.

Důvody pro takové zpoždění jsou buď pomalá síť, nebo replika, kterou nezvládá, nebo příliš mnoho slave (více než 20 na 1 master). Pokud je síť pomalá, pak je jasné, že je třeba ji nějak zrychlit, shromáždit do jednotlivých datových center atd. Pokud replika selže, musíte přidat repliky. Pokud je otroků příliš mnoho, musíte přijít s něčím zajímavým, s největší pravděpodobností vytvořit nějakou hierarchii.

Co je to mistr řemesla?

Toto je situace, kdy existuje několik serverů a všude se vše zapisuje a čte. Výhodou je, že může být rychlejší, je odolný vůči poruchám. V principu je vše stejné jako u otroků, ale logika je obecně jednoduchá – jednoduše vybereme náhodné spojení a pracujeme s ním. Nevýhody: zpoždění replikace je vyšší, existuje možnost získání nějakého druhu nekonzistentních dat, a pokud dojde k nějakému zhroucení, pak se začne šířit mezi všechny mastery a nikdo neví, který master je normální, který je rozbité... Celá tato věc se začíná replikovat napříč kruhem, tzn. Velmi dobře zanáší síť. Obecně platí, že pokud jste měli udělat mistra-mistra, musíte 100krát přemýšlet. S největší pravděpodobností si vystačíte s hlavním otrokem.

Replikaci můžete vždy provést ručně, tzn. uspořádat pár spojení a napsat 2, 3 najednou, nebo dělat něco na pozadí.

Co je to sharding?

Ve skutečnosti jde o šíření dat na několik serverů. Můžete stříhat samostatné tabulky. Vezměme si například tabulku fotografií, tabulku uživatelů atd. a přetáhněte je na samostatné servery. Pokud byly tabulky velké, pak se vše zmenšuje, spotřebovává se méně paměti, vše je v pořádku, ale nemůžete se PŘIPOJIT a musíte klást dotazy typu WHERE IN, tj. nejprve vybereme spoustu ID, pak všechna tato ID nahradíme do dotazu, ale k jinému připojení, k jinému serveru.

Část stejných dat můžete skartovat, tj. například vezmeme a vytvoříme několik databází s uživateli.

Můžete jednoduše vybrat server - zbytek dělení podle počtu serverů. Alternativou je pořízení karty, tzn. U každého záznamu ponechte klíč hodnoty v nějakém Redis nebo podobně, tedy tam, kde se každý záznam nachází.

Existuje jednodušší možnost:

Je to obtížnější, když nemůžete seskupit data. Abyste je získali, musíte znát ID dat. Žádné JOIN, ORDER atd. Ve skutečnosti redukujeme naše MySQL nebo PostgreSQL na úložiště klíč-hodnota, protože s nimi nemůžeme nic dělat.

Z běžných úkolů se stávají mimořádné:

Vyberte TOP 10.
Rozdělení stránek.
Vyberte si ten s nejnižšími náklady.
Vyberte příspěvky od uživatele X.

Pokud jsme to rozstříhali natolik, že se vše rozházelo po všech serverech, začíná se to řešit velmi netriviálním způsobem. V této situaci vyvstává otázka – proč SQL vůbec potřebujeme? Neměli bychom hned napsat Redisovi? Vybrali jsme správné úložiště?

Po vybalení je sharování podporováno věcmi jako:

memcache;
Redis;
Cassandra (ale říkají, že to v určitém okamžiku nezvládne a začne padat).

A co statistika?

Často rádi počítají statistiky z hlavního serveru – z jednoho databázového serveru. To je skvělé, ale dotazy ve statistikách jsou obvykle plíživé, vícestránkové atd., takže počítat statistiky z hlavních dat je velká chyba. Ve většině případů není pro statistiky potřeba realtime, takže můžeme nastavit replikaci v master slave a vypočítat tyto statistiky na slave. Nebo můžeme vzít něco hotového - Mixpanel, Google Analytics nebo podobně.

Toto je hlavní myšlenka, která pomáhá distribuovat vše mezi různé servery a různé velikosti. Za prvé, zisk z toho je hned vidět – i když máte jeden server a začnete něco dělat na pozadí, uživatel dostane odpověď mnohem rychleji, ale také následně rozloží zátěž, tzn. celé toto zpracování můžeme přetáhnout na jiný server, můžeme to dokonce zpracovat ne v PHP. Například na Stay.com se velikost obrázků mění v Go.

Gearmana si můžete okamžitě vzít. Jedná se o hotovou věc pro zpracování na pozadí. Pro PHP existují knihovny a ovladače... Nebo můžete použít fronty, tzn. ActiveMQ, RabbitMQ, ale fronty pouze přeposílá zprávy, nevolají ani nespouštějí samotné handlery, a pak budete muset něco vymyslet.

Obecný význam je vždy stejný - existuje hlavní software, který umisťuje nějaká data do fronty (obvykle to je „co mám dělat?“ a data pro to), a nějaká služba – buď je získá, nebo se do ní odešle (pokud se fronta dokáže aktivně chovat chování) tato data, zpracovává vše na pozadí.

Přejděme k architektuře.

Nejdůležitější při škálování je, aby byl projekt co nejméně propojený. Čím menší propojenost, tím snazší je změnit jedno řešení na jiné, tím snazší je přesunout část na jiný server.

Soudržnost probíhá v kódu. SOLID, GRASP jsou principy, které vám umožňují vyhnout se propojení v kódu. Ale konektivita v kódu samozřejmě ovlivňuje distribuci mezi servery, ale ne tolik jako konektivitu doménové vrstvy s naším prostředím. Pokud do ovladače napíšeme hodně kódu, ukáže se, že jej s největší pravděpodobností nebudeme moci použít jinde. Nebude pro nás snadné toto vše přenést z webového ovladače do konzole, a proto bude obtížnější to přenést na jiné servery a tam to zpracovat jinak.

Architektura orientovaná na služby.

Existují 2 přístupy k rozdělení systémů na části:

když se zaměřují na technické části, tedy například existuje fronta, odstranili službu řazení do fronty, došlo ke zpracování obrazu, odstranili tuto službu atd.
To je dobré, ale když tyto fronty, obrázky atd. interagují v rámci dvou doménových oblastí... Například v projektu existuje oblast prodeje a oblast zákazníků – to jsou různé oblasti, se kterými pracují různých uživatelů, ale oba mají různé fronty. Když všechno začne do sebe zapadat, z projektu se stane nepořádek;
Správným řešením je rozdělení na samostatné logické části, tzn. pokud oblasti Prodej a Zákazník používají uživatelský model, pak vytvoříme 2 uživatelské modely. Mohou číst stejná data, ale prezentují je mírně odlišně. Pokud takto rozložíte systém, pak je vše vnímáno mnohem lépe a je mnohem snazší to všechno rozházet.
Další důležitou věcí je, že díly musí vždy komunikovat přes rozhraní. Takže v našem příkladu, pokud Sales s něčím interaguje, pak to nezapisuje do databáze, nepoužívá obecný model a „mluví“ s jinými oblastmi prostřednictvím konkrétní smlouvy.

A co doménová vrstva?

Doménová vrstva je rozdělena na nějaké služby atd. - to je důležité pro vývoj aplikace, ale pro škálování jejího designu není příliš důležité. V doménové vrstvě je nesmírně důležité oddělit ji od prostředí, kontextu, ve kterém se provádí, tzn. z ovladače, konzolového prostředí atd., takže všechny modely lze používat v jakémkoli kontextu.

Existují 2 knihy o vrstvě domény, které doporučuji všem:

„Design řízený doménou: Řešení složitosti v srdci softwaru“ od Erica Evanse,
"Implementace návrhu řízeného doménou, implementace návrhu řízeného doménou."

o BoundedContext - http://martinfowler.com/bliki/BoundedContext.html (to, co bylo zmíněno výše - pokud máte dvě oblasti, které se zdánlivě prolínají, ale
různé, pak se vyplatí některé entity duplikovat, např. uživatelský model);
o DDD obecně - odkaz na jinou knihu.

V architektuře se zase vyplatí držet se zásady nic sdílet, tzn. pokud chcete udělat něco společného, vždy to dělejte vědomě. Je lepší dát logiku na stranu aplikace, ale stojí za to vědět, kdy přestat. Nikdy byste například neměli vytvářet uložené procedury v DBMS, protože jejich škálování je velmi obtížné. Pokud to přeneseme na aplikační stranu, bude to jednodušší – vytvoříme několik serverů a vše se bude provádět tam.

Nepodceňujte optimalizaci prohlížeče. Jak jsem již řekl, z 300-600 ms, které jsou požadavky provedeny na serveru, se k nim přidá 300-600 ms, které jsou vynaloženy na klienta. Klienta nezajímá, zda je náš server rychlý nebo zda stránka funguje tak rychle, proto vám doporučuji použít Google PageSpeed atd.

Jak už to tak bývá, abstrakce a fragmentace nejsou vůbec zadarmo. Pokud službu rozdělíme na mnoho mikroslužeb, tak už nebudeme moci pracovat s nováčky a budeme muset hodně, hodně platit našemu týmu, který se tím vším bude hrabat, třídit všechny vrstvy, navíc , může služba začít pracovat pomaleji. Pokud to není děsivé v kompilovaných jazycích, pak v PHP, alespoň do verze 7, to není moc...

Nikdy nechovejte slepě, vždy sledujte a analyzujte. Slepě, téměř všechna výchozí rozhodnutí jsou chybná. Přemýšlejte! Nevěřte, že existuje stříbrná kulka, vždy si to zkontrolujte.

Některé další užitečné odkazy:

Kontakty

Tato zpráva je přepisem jednoho z nejlepší výkony na školicí konferenci pro vývojáře vysokozátěžových systémů v roce 2015.

Staré věci! - říkáš.
- Věčné hodnoty! - odpovíme.

Některé z těchto materiálů používáme také v online školení o vývoji vysokozátěžových systémů – jedná se o řetězec speciálně vybraných dopisů, článků, materiálů, videí. Naše učebnice již obsahuje více než 30 unikátních materiálů. Připojit!

No a hlavní zprávou je, že jsme zahájili přípravy na jarní festival „Ruské internetové technologie“, který zahrnuje osm konferencí, vč. HighLoad++ Junior.

ALEXANDER KALENDAREV, RBC Media, programátor, [e-mail chráněný]

Problémy a řešení

Dříve nebo později, populární web nebo mobilní projekt s serverová část narazí na problém s výkonem. Jedním z řešení je horizontální měřítko databáze. mluvíme o úskalí a asi možné způsoby obcházet je

Každý rostoucí projekt čelí výzvě produktivity. Pokud si tedy myslíte, že váš projekt je ambiciózní a brzy si podmaní celý svět, pak je vhodné zahrnout možnost škálování na úrovni počátečního vývoje architektury.

Ujasněme si terminologii:

Výkon– schopnost aplikace splnit požadavky, jako je maximální doba odezvy, propustnost.
Propustnost (kapacita) – maximální příležitost aplikace, které mají projít určitou částku požadavky za jednotku času nebo zachovat určitý počet uživatelské relace.
Škálovatelnost je charakteristika aplikace, která ukazuje její schopnost udržovat výkon, jak se zvyšuje šířku pásma. Na druhé straně je škálování procesem zajištění růstu systému. Měřítko může být vertikální nebo horizontální.
Vertikální škálování- jedná se o zvýšení produktivity díky zvýšení výkonu železa, objemu BERAN atd. Dříve nebo později vertikální škálování dosáhne svého horního limitu.
Horizontální škálování je zvýšení produktivity díky rozdělení dat na více serverů.

Funkční oddělení dat

Existuje několik možností pro horizontální měřítko. Velmi často se například používá k oddělení dat na základě funkčního využití. Například data pro fotoalba jsou obsažena v jedné skupině serverů, data uživatelského profilu jsou umístěna v jiné skupině a uživatelská korespondence je umístěna ve třetí. Na Obr. Obrázek 1 ukazuje schéma horizontálního škálování podle funkční distribuce.

Škálování pomocí replikace

Nejjednodušší způsob škálování, často používaný pro malé a středně velké projekty, je použití replikace. Replikace je mechanismus pro synchronizaci více kopií objektu a databázových tabulek (viz obr. 2). Master-slave replikace je synchronizace dat z hlavního hlavního serveru na podřízené podřízené servery.

Vzhledem k tomu, většina webových a mobilní projekty Existuje řádově více operací čtení než operací zápisu, pak můžeme provádět operace zápisu na jednom hlavním serveru a číst data z mnoha podřízených serverů. Replikace musí být nakonfigurována mezi hlavním a podřízeným serverem.

Mnoho databází má vestavěnou replikaci, nebo, jak se říká, „out-of-the-box řešení“. Replikaci PostgreSQL lze například provádět pomocí následujících nástrojů:

Slony-I – asynchronní (master to multiple slave) replikace;
pgpool-I/II – synchronní multimaster replikace;
Pgcluster – synchronní multimaster replikace;
Bucardo;
Londýn;
RubyRep.
počínaje verzí 9.0, vestavěná streamingová replikace.

Při škálování pomocí replikace musíte použít různá spojení: jeden s hlavním serverem, pouze pro zápis nebo aktualizaci, a druhý, pouze s podřízeným serverem, přímo pro čtení. Pokud navíc používáme více podřízených serverů, pak může být strategie výběru náhodná, nebo je konkrétní databázový server přiřazen ke konkrétnímu webovému serveru.

Přečtěte si celý článek v časopise " Správce systému“, č. 10 za rok 2014 na str. 54-62.

PDF verze dané číslo lze zakoupit v našem obchodě.

) Dobrý den! Jsem Alexander Makarov a můžete mě znát z frameworku Yii – jsem jedním z jeho vývojářů. Mám také práci na plný úvazek – a to už není startup – Stay.com, která se zabývá cestováním.

Dnes budu mluvit o horizontálním škálování, ale velmi, velmi obecně.

Co je to vlastně škálování? To je příležitost ke zvýšení produktivity projektu v minimálním čase přidáním zdrojů.

Škálování obvykle nezahrnuje přepisování kódu, ale buď přidávání serverů nebo navyšování zdrojů stávajícího. Tento typ zahrnuje vertikální a horizontální měřítko.

Vertikální je, když se přidá více RAM, disků atd. na již existujícím serveru a horizontální je, když do datových center umístí více serverů a servery tam již nějak interagují.

Hlavní dva parametry: n - počet požadavků, které je třeba provést, c - počet souběžných požadavků. Kontrolují tak konkurenci.

Stává se, že se vlastně ještě není třeba starat o škálování - jdeme na server, aktualizujeme PHP, získáme 40% nárůst výkonu a vše je v pohodě. Dále nakonfigurujeme Opcache a vyladíme ji. Opcache je mimochodem vyladěna stejným způsobem jako APC, pomocí skriptu, který lze nalézt v repozitáři Rasmuse Lerdorfa a který ukazuje hity a miss, kde hity jsou, kolikrát PHP šlo do mezipaměti, a miss jsou kolikrát to šlo do systému souborů získat soubory. Pokud spustíme celý web nebo spustíme nějaký prohledávač odkazů, nebo do něj ručně strčíme, pak budeme mít statistiky o těchto návštěvách a chybách. Pokud je 100 % zásahů a 0 % chyb, pak je vše v pořádku, ale pokud dojde k chybám, pak musíme alokovat více paměti, aby se celý náš kód vešel do Opcache. Toto je běžná chyba, která se dělá - zdá se, že tam je Opcache, ale něco nefunguje...

Musíte také povolit mezipaměť, nahradit apache nginx a php-fpm, abyste ušetřili paměť. Všechno bude skvělé.

Všechny výše uvedené jsou docela jednoduché a dají vám čas. Je čas na to, že to jednoho dne nebude stačit, a na to se musíme připravit už teď.

Na co si dát při sledování právě teď pozor? Tento:

dostupnost, tzn. zda je server naživu nebo ne;
nedostatek diskových prostředků, procesoru atd.;
chyby.

Jak to vše sledovat?

Zde je seznam skvělých nástrojů, které vám umožní sledovat zdroje a zobrazovat výsledky velmi pohodlným způsobem:

Tato zpráva je přepisem jedné z nejlepších prezentací na školicí konferenci pro vývojáře vysoce zatěžovaných systémů v roce 2015.
Staré věci! - říkáš.
- Věčné hodnoty! - odpovíme.
vysoce naložený junior
Přidejte značky

Oblíbené v kategorii: