Nastavení vaší aplikace: Jak vybrat nejlepší konfiguraci serveru?

Úvod

Technologie a internet se staly ústřední součástí našeho běžného, akademického i profesního života. Proto není překvapením obrovské množství webových stránek a aplikací, které existují současně. Pokud podnikáte, jistě chcete mít přidruženou webovou platformu. Aplikace vám umožní snadno propagovat a poskytovat vaše služby cílovým zákazníkům.

Bez ohledu na důvod, proč vytváříte webovou aplikaci, se musíte rozhodnout, jak ji vytvořit. Pokud jde o výběr nejlepšího nastavení serveru, máte k dispozici mnoho možností. Zvolená architektura serveru určí, jak budete vše ve svém prostředí spouštět a spravovat. Proto je třeba toto rozhodnutí učinit po pečlivém zvážení.

Jak vybrat správné nastavení serveru

Jak se tedy rozhodnout, která architektura je pro vaši aplikaci ta „správná“? Chcete-li tak učinit, musíte nejprve popřemýšlet o tom, jaké jsou požadavky na vaši webovou aplikaci. Musí existovat určité funkce, které musíte začlenit, aby efektivně fungovala pro váš konkrétní případ použití. Možná například usilujete o aplikaci, kterou lze snadno škálovat. Nebo možná potřebujete, aby vaše aplikace fungovala hladce v prohlížečích i na mobilních zařízeních. Zároveň může být vaším hlavním zájmem také rozpočet.

Bez ohledu na to, jaké jsou vaše požadavky, byste měli vědět, že pro svou aplikaci můžete vytvořit řešení na míru. V tomto návodu prozkoumáme různé typy serverů, které lidé běžně používají pro své webové aplikace. Budeme hovořit o různých případech použití a o tom, kdy je nejlepší použít konkrétní nastavení. Abychom vám pomohli se rozhodnout, zda je pro vás vhodné, uvedeme také některé výhody a nevýhody jednotlivých architektur serverů.

1. Vše na jednom serveru

Jak napovídá název, celé prostředí nahrayete na jeden jediný server. Prostředí by zahrnovalo váš webový server, aplikační server i databázový server. Funguje to například na konfiguraci stacku Linux, Apache, MySQL, a PHP (LAMP). Můžete postupovat podle našich návodů, jak nainstalovat LAMP stack na server Ubuntu a jak nainstalovat LAMP stack na CentOS.

Kdy to použít:

Tento typ uspořádání funguje nejlépe, pokud máte málo času. Nastavení je jednoduché a rychlé. Proto funguje pro zjednodušené webové aplikace.

Výhody:

• Jednoduché a snadno pochopitelné a implementovatelné.
• Nastavení v celé své šíři zabere málo času.

Nevýhody:

• Neumožňuje horizontální škálovatelnost.
• Nabízí velmi málo z hlediska izolace komponent.
• Aplikace a databáze v podstatě soupeří o stejné prostředky, protože jsou na jednom serveru.
• V důsledku toho se můžete potýkat se špatným výkonem.

2. Samostatný databázový server

Hlavním problémem při použití jednoho serveru je soupeření o omezené prostředky. Toto nastavení se snaží tento problém vyřešit. Zde je systém řízení báze dat neboli DBMS udržován odděleně od aplikačního serveru. Databázový server je v privátní síti a má své vlastní prostředky. To vede k lepšímu výkonu a vyšší bezpečnosti.

Kdy to použít:

Opět platí, že pokud chcete nasadit rychlé nastavení, je konfigurace poměrně jednoduchá. Je to ideální řešení, pokud se obáváte, že databáze a aplikace budou soupeřit o stejné prostředky.

Výhody:

• Samostatné, vyhrazené systémové prostředky pro aplikaci a databázi, včetně CPU, paměti, I/O atd.
• Větší potenciál pro škálovatelnost v aplikační i databázové vrstvě.
• Prostředky můžete přidávat a odebírat podle potřeby.
• Pokud databázi odeberete z veřejného internetu, můžete také zvýšit úroveň zabezpečení.

Nevýhody:

• O něco složitější než nastavení s jedním serverem.
• Nízká šířka pásma nebo vysoká latence síťového připojení mezi oběma servery může způsobit problémy s výkonem.

3. Reverzní proxy nebo nástroj pro vyrovnávání zátěže

Zde přicházejí na řadu nástroje pro vyrovnávání zátěže vstupují do hry. Nástroje pro vyrovnávání zátěže (load balancery) se obvykle používají v serverových prostředích ke zvýšení výkonu a spolehlivosti. Dělají to tak, že „vyrovnávají zátěž“, tj. distribuují pracovní zátěž mezi pole serverů.

Kdy to použít:

Nástroje pro vyrovnávání zátěže jsou mimořádně užitečné, když potřebujete provést horizontální škálování. Horizontální škálování v podstatě znamená přidání dalších serverů do prostředí. Můžete také použít reverzní proxy na aplikační vrstvě k obsluze několika aplikací najednou pomocí jedné domény a portu. HAProxy, Nginx, a Varnish jsou příklady softwaru, který umožňuje vyrovnávání zátěže pomocí reverzní proxy.

Výhody:

• V případě, že jeden server v řadě selže, ostatní servery kompenzují jeho funkci vyrovnáváním pracovní zátěže.
• Umožňuje provádět horizontální škálování pro zvýšení nebo snížení kapacity prostředí.
• Omezuje také připojení klientů, což nabízí ochranu proti útokům DDOS.

Nevýhody:

• V případě, že systémové prostředky nejsou dostatečné, může load balancer omezit výkon vaší aplikace.
• K zajištění správného výkonu je nutná správná konfigurace.
• Výrazně složitější než nastavení s jedním serverem nebo oddělenými servery.
• Musíte vzít v úvahu faktory, jako je ukončení SSL (SSL termination) a aplikace, které vyžadují persistentní relace (sticky sessions).
• Hlavním důvodem k obavám při používání load balancerů je to, že představují jediný bod selhání (single point of failure). To znamená, že pokud load balancer přestane fungovat, celá vaše služba přestane běžet.

4. HTTP akcelerátor nebo reverzní proxy s mezipamětí

Jedná se o nastavení, které můžete použít ke zvýšení rychlosti, s jakou doručujete obsah uživateli vaší aplikace. K dosažení tohoto zkrácení času využívá různé techniky. Nejdůležitější z nich je ukládání odpovědí z aplikačního serveru do mezipaměti. Akcelerátor uloží obsah do své paměti, když o něj uživatel požádá poprvé. Proto, když přijdou jakékoli podobné budoucí požadavky, poskytne obsah rychle bez interakce s aplikačním serverem. Nginx, Varnish i Squid jsou schopny HTTP akcelerace.

Kdy to použít:

Pochopitelně je toto nastavení nejvhodnější pro soubory a obsah, které uživatelé požadují velmi často. Velmi dobře funguje také pro dynamické webové aplikace s velkým množstvím obsahu.

Výhody:

• Ukládání do mezipaměti a komprese výrazně zvyšují rychlost aplikace a zpracování požadavků.
• Snížení zátěže procesoru (CPU) také zlepšuje výkon webu.
• Můžete to také použít jako reverzní proxy pro vyrovnávání zátěže.

Nevýhody:

• Musíte jej dobře vyladit, abyste z něj získali nejlepší výkon.
• V případě, že je míra úspěšnosti mezipaměti (cache-hit rate) nízká, můžete zaznamenat slabý výkon.

5. Replikace databáze typu Primary-Replica

Nastavení replikace databáze typu primary-replica je obvykle velmi užitečné pro systémy, které provádějí více čtení než zápisů. Takovou architekturu mohou velmi dobře využít například redakční systémy (CMS). Pro replikaci potřebujete jeden primární uzel (primary) a jeden nebo více replikačních uzlů. Čtení se distribuuje mezi všechny uzly. Aktualizace jdou pouze do primárního uzlu.

Kdy to použít:

Jak jsme zmínili, nastavení databáze založené na replikaci pomáhá zlepšit výkon čtení systému. Můžete jej použít pro aplikace jako CMS.

Výhody:

• Zlepšuje výkon čtení databáze, protože jej rozděluje mezi repliky.
• Pokud primární uzel používáte pouze pro aktualizace, můžete také zlepšit výkon zápisu.

Nevýhody:

• Každá aplikace, která se pokouší o přístup k databázi, musí být schopna rozhodnout, kterému uzlu odeslat aktualizace a kterému požadavky na čtení.
• V případě selhání primární repliky se aktualizace zastaví. Chcete-li v aktualizacích pokračovat, musíte problém vyřešit.
• Neexistuje žádný mechanismus převzetí služeb při selhání (failover), který by řešil případný výpadek primárního uzlu.

Kombinace různých nastavení serverů

Naštěstí je také možné kombinovat různé techniky, abyste dosáhli požadovaného výsledku. To znamená, že můžete vyvažovat zátěž aplikačních serverů s caching servery v jediném prostředí a replikovat databázi. Tento postup vám umožní využít funkčnost obou serverů. Nastavení to však nijak nekomplikuje ani neztěžuje.

Příklad:

Pokusíme se takové prostředí pochopit na příkladu:

V takovém prostředí bude load balancer posílat statické požadavky na caching servery. Statický obsah zahrnuje mimo jiné CSS, obrázky a Javascript. Jakékoli jiné požadavky na obsah pak bude směrovat na aplikační servery.

Řekněme, že uživatel požaduje z prostředí nějaký statický obsah. Zde je popis toho, co se stane:

• Load balancer nejprve určí, zda se jedná o cache-hit (zásah do mezipaměti) nebo cache-miss (minutí mezipaměti). Obsah typu cache-hit je v mezipaměti přítomen, zatímco obsah typu cache-miss tam není. Zjišťuje to dotazem na cache-backend.
• V případě cache-hit odešle load balancer obsah uživateli.
• V případě cache-miss předá cache server požadavek na backend aplikace.
• App-backend vyhledá a odešle obsah z databáze.
• Cache-backend přijme obsah z load balanceru. Tento obsah také uloží do mezipaměti předtím, než jej vrátí load balanceru.
• Ten pak předá odpověď uživateli.

Na druhou stranu, zde je to, co se stane, pokud uživatel požaduje dynamický obsah:

• Požadavek přijde od uživatele na load balancer.
• Tento požadavek přichází na app-backend.
• App-backend vyhledá požadovaný obsah a vrátí jej load balanceru.
• Uživatel obdrží obsah.

Jednou z hlavních výhod takového kombinovaného prostředí je jeho vyšší spolehlivost. Nejen to, má také vynikající výkonnostní schopnosti. Stále však existují dvě slabá místa (single points of failure) – load balancer a primární databázový server.

Závěr

Každé nastavení serveru můžete ve svém prostředí použít samostatně. Na druhou stranu byste jich také mohli několik zkombinovat a vytvořit tak personalizované řešení. Neexistuje žádná „správná“ odpověď. Vše závisí na funkčnosti, kterou chcete z architektury získat.

Základní znalosti o tom, jak jednotlivá nastavení serverů fungují, vám pomohou se rozhodnout pro vaši vlastní aplikaci. Nejlepší je začít v malém a jednoduše. S přibývajícími zkušenostmi můžete složitost svého nastavení dále zvyšovat.

Ať se daří!