9 důvodů proč podlehnout trendu DevOps a kontejnerových technologií

DevOps a kontejnerizace nejsou jen pomíjivé trendy. Můžou vám pomoct zefektivnit vývoj i zvýšit spokojenost zákazníků. Tady je top 9 důvodů.

e-commerce Kubernetes vývoj

9 důvodů proč podlehnout trendu DevOps a kontejnerových technologií

vshosting~

DevOps a kontejnerizace patří mezi oblíbené IT buzzwordy dnešní doby. Nikoli bezdůvodně. Kombinace těchto přístupů je jedním z důvodů, proč se daří práci vývojářů stále zefektivňovat. V tomto článku se zaměříme se na 9 hlavních důvodů, proč by se i vám tyto vývojové přístupy mohly vyplatit.

Pár rychlých vysvětlivek na úvod

DevOps je složenina z anglických slov Development (Vývoj) a Operations (Provoz), a jde vlastně o přístup k vývoji software, který klade důraz na spolupráci vývojářů s IT odborníky starajícími se o provoz aplikací. To vede k mnoha výhodám, které si tu postupně rozebereme.

Kontejnerizace do DevOps skvěle zapadá a můžeme ji chápat jako podpůrný nástroj DevOps přístupu. Podobně jako kontejnery fyzické, které standardizovaly přepravu zboží, softwarové kontejnery představují standardní jednotku „přepravy“ softwaru. Díky tomu je IT odborníci mohou nasadit napříč prostředími v podstatě bez úprav (podobně jako fyzický kontejner můžete bez problému přeložit z lodi na vlak nebo na kamion).

Top 9 výhod DevOps a kontejnerů

1) Synergie mezi týmy

U DevOps přístupu spolu vývojáři a admini úzce spolupracují a účastní se všech fází vývojového procesu. Tyto dva světy bývaly tradičně striktně oddělené, ale jejich de facto sloučení má mnohé výhody.

Spolupráce vede k větší efektivitě celého vývojového i operačního procesu a tím i k jeho zrychlení. Neméně důležitým aspektem je i to, že kooperace kolegů ze dvou odlišných oblastí s sebou často nese nejrůznější inovativní, „out of the box řešení“, na která by jinak nikdo nepřišel.

2) Transparentní komunikace

Častým problémem nejen v IT firmách bývá kvalitní komunikace. Každý má spoustu práce a hledí si svého. Výsledkem pak bývají nedorozumění, chybné předpoklady a z toho plynoucí konflikty a zbytečná práce.

Součástí myšlenky DevOps je zavedení transparentní a pravidelné komunikace mezi vývojáři a administrátory, díky čemuž všichni táhnou za jeden provaz. Obě skupiny jsou také zapojeny do všech fází tvorby aplikací či jejich částí.

3) Méně bugů a dalších „nehod“

Mezi principy DevOps patří také časté vydávání menších částí aplikací, oproti méně frekventovaným releasům větších celků. Díky tomu eliminujete riziko dopadu chybného kódu na celek. Jinak řečeno: pokud se náhodou něco pokazí, nerozbijete tím celou aplikaci. Spolu s důrazem na důkladné testování tento postup vede k výrazně nižší frekvenci výskytu bugů a jiných chyb.

Pokud spolu s DevOps využijete kontejnery, můžete těžit z jejich standardizace. Ta mimojiné zajišťuje, že vývojové, testovací i produkční prostředí (tj. kde aplikace výsledně běží) je definováno identicky. Tím výrazně snížíte výskyt bugů, které se při vývoji a testování neprojevily, a ukážou se až při spuštění v produkčním prostředí.

4) Snazší hledání i oprava chyb

Opravě případných chyb a zajištění hladkého chodu aplikace napomáhá i pro DevOps typické metodické ukládání všech předchozích verzí kódu. Díky nim lze velmi rychle identifikovat případný problém, který může nastat po vydání nové části aplikace.

Když už k chybě dojde, stačí aplikaci jednoduše vrátit na předchozí verzi – zabere to maximálně pár minut. Vývojáři poté v klidu daný bug opraví zatímco uživatel aplikaci může bez potíží používat. Hledání eventuální chyby je také mnohem snazší, protože vydávaná část aplikace, ve které je potřeba bug najít, je velmi malá.

5) Bezproblémová automatizace a škálovatelnost

Kontejnerová technologie také výrazně zjednodušuje škálování a pomáhá DevOps týmu automatizovat některé činnosti. Například tvorbu a nasazování kontejneru lze automatizovat přes API, což přispívá k úspoře času a nákladů na vývoj.

Co se škálovatelnosti týče, aplikace můžete provozovat v libovolném počtu instancí kontejnerů, a to podle aktuální potřeby. Počet kontejnerů lze téměř okamžitě navyšovat (například během vánoční špičky) nebo naopak snižovat. Díky tomu ušetříte velkou část nákladů na infrastrukturu třeba v období, kdy poptávka po vašem zboží není tak velká. Zároveň když se zájem nečekaně zvedne – řekněme, že jste online lékárna v době pandemie – kapacitu bleskurychle navýšíte a hotovo.

6) Detailní monitoring byznysových metrik

K DevOps i kontejnerizaci nevyhnutelně patří i detailní monitoring, který pomáhá rychle identifikovat chyby v kódu. Monitoring je ale klíčový i k měření byznysových metrik. Díky nim můžete vyhodnotit, zda právě vydaná změna pomáhá dosáhnout vašich cílů nebo ne.

Pro představu: dejme tomu, že jste se u svého e-shopu rozhodli pro redesign domovské stránky, jehož cílem je zvýšení počtu objednávek o 10 %. Díky detailnímu monitoringu brzy po vydání zjistíte, jestli jste vytyčených 10 % dosáhli či nikoliv. Kdybyste oproti tomu udělali 5 změn v e-shopu najednou, bude vyhodnocení účinnosti jednotlivých opatření mnohem složitější. Řekněme, že celkovým výsledkem těchto 5 změn je zvýšení počtu objednávek o 7 %. Která z novinek způsobila největší nárůst? A nezpůsobuje naopak některá z nich snížení počtu objednávek? Kdo ví.

7) Agilnější a rychlejší vývoj

Výsledkem všeho výše uvedeného je významné zrychlení celého procesu vývoje, od napsání kódu po úspěšné spuštění daného softwaru, a to i o 60 % a více.

Jak moc velké bude zefektivnění, tedy i úspory a potažmo nárůst tržeb, ovšem závisí na mnoha faktorech. Mezi ty nejdůležitější patří velikost vašeho vývojového týmu a míra využití podpůrných nástrojů, jakými je například technologie kontejnerizace, automatizace procesů a volba flexibilní infrastruktury. Zjednodušeně řečeno, čím větší tým máte a čím více využijete možností automatizace a flexibility zvolené infrastruktury, tím efektivnější celý proces bude.

8) Menší náklady na vývoj

Asi nikoho nepřekvapí, že rychlejší vývoj, lepší komunikace a spolupráce týmů zamezující zbytečné práci a menší výskyt bugů napomáhá snížení nákladů na vývoj jako takový. Zejména u firem s většími IT týmy může jít i o desítky procent (!).

Často se i ukáže, že díky synergiím a větší efektivitě spojeného týmu nepotřebujete mít ve firmě 20 IT specialistů, ale třeba jen 17. A to je také pořádný rozdíl v rozpočtu.

9) Spokojenější zákazníci

Akcelerace vývoje vede také k větší spokojenosti zákazníků. Váš byznys je totiž schopen pružněji reagovat na jejich požadavky a například do e-shopu přidat novou funkci, po které vaši klienti volají. Díky detailnímu monitoringu také lépe odhalíte, které změny zákazníci vítají a které je lepší zahodit. Snáze se tak odlišíte od konkurence a vybudujete si základnu skalních fanoušků, kteří jen tak jinam nakupovat nepůjdou.

Co si z toho odnést

Když si to shrneme, z vývojářského pohledu DevOps spolu s kontejnery usnadní a urychlí práci, zlepší komunikaci s adminy a drasticky sníží výskyt bugů. Byznysově to znamená výrazné snížení nákladů a větší spokojenost zákazníků (a tedy i vyšší tržby). Z toho plynoucí rovnici „vyšší tržby + nižší náklady = vyšší ziskovost“ netřeba rozvádět.

Aby všechno fungovalo, jak má, budete také potřebovat dobrého poskytovatele infrastruktury – typicky nějakou formy Kubernetes platformy. Většinu z vás nejspíš jako první napadnou tradiční cloudy od amerických firem. Bohužel, podle zkušeností našich klientů vám uživatelská (ne)přívětivost těchto providerů celý proces příliš neusnadní. Další variantou je poskytovatel, který vám Kubernetes platformu předpřipraví, zdarma poradí co a jak a poskytne vám nonstop podporu na telefonu. To v češtině a za výrazně nižší cenu. Nechceme se chlubit, ale přesně tohle splňuje Kubernetes platforma od vshosting~.

Příklad infrastruktury využívající kontejnerovou technologii – vshosting~

Vývoj a produkce: proč je za každou cenu oddělit

Která rizika s sebou nese spojení vývoje s produkcí a jak infrastrukturu nastavit lépe.

e-commerce vývoj

Vývoj a produkce: proč je za každou cenu oddělit

vshosting~

Ve vshosting~ je našim cílem nejen klientům poskytovat špičkový hosting, ale i dobře poradit. Za 14 let našeho fungování už jsme toho totiž viděli opravdu hodně, takže víme, co funguje i od čeho je lepší dát ruce pryč. Jedním z klíčových (a velmi drahých) nešvarů, se kterým se setkáváme, je sdílená infrastruktura pro vývoj i produkci. A to i u velkých projektů, které by v případě průšvihu mohly přijít o neskutečné peníze.

Vzhledem k tomu, jak velké riziko společná vývojová a produkční infrastruktura představuje, je takový průšvih neustále na spadnutí. Proč je vývoj v produkčním prostředí tak nebezpečný? A jak celou infrastrukturu nejlépe nastavit tak, abyste eliminovali riziko? Sepsali jsme to nejdůležitější.

Vývojové vs. produkční prostředí

Vývojové (a testovací) prostředí by mělo sloužit jen a pouze k vývoji a testování nového softwaru či featur. To se vztahuje jak na změny ve vlastní aplikaci, tak i např. na updaty softwarového vybavení serveru. Vývojáři v něm mohou v klidu experimentovat bez obav, že by ohrozili produkci.

Produkční prostředí je naopak to, kde aplikace běží „naostro“ – například e-shop, kde zákazníci vyhledávají a zkoumají produkty, dávají je do košíku a platí za objednávky. Produkce je jednoduše to, co „je vidět“ pro běžného uživatele i všechny systémy v pozadí, které jsou pro funkci aplikace zásadní (například databáze, skladové systémy atd.).

Ale hlavně: produkční prostředí je to, které vydělává. Proto by se kolem něj mělo chodit obloukem a ještě navíc po špičkách. Každý problém na produkci se totiž rapidně změní v ušlý zisk.

Rizika společné infrastruktury

Pokud od sebe neoddělíte vývoj a produkci, může se snadno stát, že vaši vývojáři pustí ven nedostatečně otestovaný software, který následně poškodí nebo rozbije celou aplikaci. Jinými slovy: „spadne“ produkce. Když budete mít dostatečnou smůlu, vaše aplikace nepojede klidně i několik hodin nebo dní než ji vývojáři opraví. To by v případě velkého e-shopu znamenalo klidně i statisíce v ušlých tržbách a zbytečně vynaložených nákladech na marketing. O extra nákladech na vývoj ani nemluvě.

Obzvlášť bolestivé jsou tyto případy v době vysokého provozu na vašem webu. U e-shopů jde typicky o předvánoční sezonu – podívejte se, kolik by vás stál byť jen hodinový výpadek. Může se ovšem jednat i o období, kdy intenzivně investujete například do televizní reklamy. Ta je velice drahá a nejde jen tak pozastavit, protože vám zrovna nefunguje e-shop.

Bohužel už jsme podobných situací viděli mnoho. Z toho důvodu všem našim klientům dlouhodobě doporučujeme, aby nový software tvořili ve vývojovém prostředí, pak otestovali v prostředí testovacím a teprve poté nasadili do produkce. Totéž platí pro rozšiřování softwarové výbavy produkčních serverů. Pouze důkladným otestováním mimo produkční prostředí se můžete vyhnout se situaci, že bug v produkci objevíte v pátek večer těsně před Vánoci.

V rámci odděleného vývojového prostředí můžete bez rizika provádět deploy nových verzí aplikace (např. upraveného e-shopu) a každou dobře otestovat před nasazením do produkce. Umožní vám také aktualizovat nové verze jednotlivých serverových komponent (nová verze DB, PHP, apod.) a otestovat jejich kompatibilitu a funkčnost. Teprve až si budete jisti, že vše správně funguje, převedete vše do produkčního prostředí. Celkově si tak ušetříte mnoho komplikací i snížíte náklady.

Jak vývoj a produkci oddělit: praktické tipy

Při výběru hostingového řešení mějte oddělení vývojového a testovacího prostředí od produkce na paměti. Ideální je mít pro účely vývoje a testů oddělený server a produkční prostředí provozovat na jiném serveru či clusteru serverů. Ve vshosting~ vám rádi zdarma poradíme s výběrem nejvhodnějšího řešení – ozvěte se nám.

Pomůžeme vám navrhnout vhodnou konfiguraci pro vaše vývojové a testovací prostředí tak, aby plně odráželo produkci a zároveň abyste zbytečně neplatili za výkon, který nepotřebujete. Vzhledem k tomu, že vývojové prostředí nemá návštěvnost jako vaše hlavní aplikace na produkci, nemusí být tak robustní. Například pokud vaše produkce sestává z clusteru 3 výkonných serverů, pro účely vývoje a testování vám bude dost možná stačit jeden menší virtuální server. Využití cloudu pro vývoj doporučujeme, protože jde typicky o nejúspornější variantu z nákladového hlediska.

Klientům, kteří u nás využívají managed služby, rádi zajistíme i tvorbu vývojového prostředí. Zjednodušeně řečeno „naklonujeme“ jejich produkci a upravíme tak, aby prostředí bylo identické a zároveň výkon nebyl zbytečně naddimenzován. Díky tomu získáte všechny benefity odděleného vývoje od produkce a ještě ušetříte čas i finance. Následně můžete veškeré úpravy provádět ve vývojovém prostředí a po jejich úspěšném otestování je jednoduše převést na produkci.

Výhody Kubernetes od vshosting~ oproti tradičním cloudům

Čím se liší vshosting~ Kubernetes platforma od těch od Amazonu, Googlu nebo Microsoftu? Rozdílů je překvapivě hodně.

Kubernetes služby vývoj

vshosting~

Klienti se nás často ptají, čím se naše nová služba Platform for Kubernetes liší od podobných produktů například od Amazonu, Googlu nebo Microsoftu. Rozdílů je poměrně hodně, proto jsme se je rozhodli do detailu popsat v tomto článku.

Individuální návrh infrastruktury

Většina tradičních cloud providerů poskytuje platformu pro infrastrukturu, ale návrh a samotná tvorba infrastruktury je na klientech – respektive na jejich vývojářích. Valná většina vývojářů Vám ovšem potvrdí, že by se mnohem raději věnovali vývoji než četbě 196-stranné příručky o tom, jak používat Amazon EKS. Příručku je navíc, narozdíl od většiny návodů, opravdu potřeba přečíst – nastavování Kubernetes u Amazonu totiž není zrovna intuitivní.

Ve vshosting~ víme, jak moc je tohle pro spoustu firem frustrující. Vývojový tým by se měl zabývat vývojem a neztrácet čas něčím, co ani nepatří do jeho specializace. Proto si zakládáme na tom, že narozdíl od tradičních cloudů, Kubernetes řešení šijeme každému klientovi na míru. Nemusíte si tedy u nás složitě vybírat z předdefinovaných balíčků, číst dlouhé návody ani vymýšlet, jaká infrastruktura bude pro Vaše potřeby nejlepší. Navrhneme infrastrukturu Kubernetes přesně pro potřeby Vaší aplikace, a to včetně load balancingu, networkingu, storage a dalších nezbytností.

Kromě toho Vám rádi pomůžeme s analýzou aplikace pro přechod do Kubernetes, pokud ho ještě nepoužíváte. Na základě Vašich požadavků také poradíme s výběrem těch nejvhodnějších technologií (konzultace je v ceně služby!), aby vše běželo, jak má a následné škálování bylo co možná nejjednodušší.

Když už jsme u škálování, to je u nás mimořádně snadné. Opět se nekoná žádné vybírání z balíčků výkonu atd., u vshosting~ prostě plynule škálujete dle aktuální potřeby. Nabízíme také možnost jemného škálování jen u potřebných prostředků. Potřebuje Vaše aplikace kvůli nárůstu klientů více RAM, nebo větší diskový prostor? Není problém.

Poté, co vytvoříme customizovaný návrh infrastruktury, provedeme individuální instalaci a nastavení Kubernetes i loadbalancerů před předáním do ostrého provozu. Jen pro představu, u Googlu, Amazonu nebo Microsoftu by všechny tyto úkony byly na Vás. U vshosting~ také vše ve spolupráci s Vámi pečlivě odladíme. Po spuštění poběží Kubernetes v našem cloudu nebo na špičkovém hardware v našem vlastním datacentru ServerPark.

Možnost kombinace fyzických serverů a cloudu

Další výhodou Kubernetes od vshosting~ je možnost kombinovat fyzické servery s cloudem – ostatní Kubernetes poskytovatelé toto vůbec neumožňují. Díky tomu si například můžete začít testovat Kubernetes na Virtual Machine s nižším výkonem a teprve poté přejít s projektem do produkce přidáním fyzických serverů (to vše u nás jde za běhu) s případným zachováním stávajících VMs pro vývoj.

Pro srovnání: třeba Google Vám sice nabídne buď možnost on-prem Google Kubernetes Engine nebo variantu v cloudu, ale musíte si vybrat jedno z toho. Navíc on-prem variantu si musíte spravovat „na vlastní triko“. Variantu kombinující fyzické servery a cloud nenajdete ani u Amazonu a Microsoftu.

U nás je možné fyzické servery s cloudem kombinovat dle libosti a navíc se Vám postaráme o kompletní správu – Vy už se můžete soustředit jen a jen na vývoj. Dohlédneme na správu operačních systémů všech Kubernetes nodů a loadbalancerů, zajistíme i průběžné upgrady operačních systémů, kernelu apod. (po domluvě i upgrade Kubernetes).

Vysoké SLA a senior support 24×7

Jedním z nejdůležitějších kritérií výběru dobré Kubernetes platformy je její dostupnost. Možná Vás proto překvapí, že Microsoft AKS ani Google GEK neposkytují SLA („financially-backed service level agreement“) a pouze tvrdí, že se „vynasnaží zajistit alespoň 99,5% dostupnost“.

Amazon EKS sice mluví o 99,9% SLA, ale vzhledem k jejich podmínkám vrácení kreditu jde ve skutečnosti pouze o garanci 95% dostupnosti – Amazon totiž vrací 100 % kreditu teprve při této úrovni dostupnosti. V případě pouze mírného poklesu pod 99,9 % dostupnosti Vám vrátí jen 10 % kreditu.

Ve vshosting~ Vám smluvně garantujeme 99,97% dostupnost, tedy ještě více než poněkud teoretické SLA u Amazonu a výrazně více než negarantovaná dostupnost 99,5 % u Microsoftu a Googlu. Reálně se dostupnost u nás pohybuje dokonce na 99,99 %. Managed Kubernetes řešení u nás navíc funguje v režimu high-availability cluster, tudíž v případě poruchy jednoho serveru nebo části cloudu celé řešení ihned startuje na záložním serveru či v jiné části cloudu.

Zaručujeme také vysokorychlostní konektivitu i neomezené datové toky do celého světa. Každému klientovi navíc garantujeme vyhrazenou šířku pásma do internetu. Naše síť má kapacitu až 1 Tbps a každá trasa je mnohonásobně zálohovaná.

Díky režimu high-availability cluster, vysoké kapacitě sítě a zálohovanému připojení je Kubernetes řešení od vshosting~ mimořádně odolné proti výpadku jakékoliv části clusteru. Kromě toho naše zkušené týmy Vaše řešení neustále monitorují a případné začínající problémy rychle identifikují, než se mohou projevit pro koncového uživatele. Máme také robustní AntiDDoS ochranu, která celý cluster efektivně chrání před kyberútoky.

Debugging a monitoring celé infrastruktury

Oproti tradičním cloud providerům, ve vshosting~ na Vaše řešení dohlížejí týmy senior administrátorů a techniků neustále 24/7, sedí přímo v našem datacentru a v případě problému reagují do 60 sekund – a to klidně v sobotu ve 2 ráno. Tito experti za Vás neustále monitorují desítky parametrů celého řešení (hardware, loadbalancery, Kubernetes) a díky tomu dokážou většině problémů zabránit předtím, než se pořádně projeví. Navíc garantujeme opravu nebo výměnu nefunkčního serveru do 60 minut.

Pro maximální zjednodušení od nás dostanete jeden servisní kontakt pro všechny služby: ať jde o Kubernetes jako takový, jeho správu nebo cokoliv ohledně infrastruktury. Vyřešíme běžnou údržbu i složitý debugging. V rámci ceny služby Platform for Kubernetes nabízíme také konzultace ohledně konkrétní podoby Dockerfiles (3 hodiny měsíčně).

Migrace webu: proč se jí všichni bojí a jak ji u nás řešíme

Odkud pramení největší obavy z migrace a co ve vshosting~ děláme pro to, aby vše proběhlo hladce.

e-commerce vývoj

vshosting~

„Ten náš současný hosting partner za moc nestojí, párkrát do roka nám dokonce neběží web, ale většinou to nějak funguje. Hlavně nechceme nikam migrovat!“

Největší překážkou výměny hostingového poskytovatele za lepšího je téměř vždy migrace. Obávaný přesun dat z jednoho hostingového řešení na jiné je totiž vždy spojen s výpadkem a s určitými riziky. Často se také při úvahách o migraci přijde na to, že je třeba provést nějaké změny v klientově aplikaci, aby po zmigrování vše fungovalo, jak má. Migrace je prostě na první pohled dost nevábný podnik.

Ale co rizika spojená s ne-migrací? Mnozí si je vůbec nepřipouští, protože „všechno funguje“, jenže tato neviditelná rizika jsou často mnohem větší a jejich potenciální následky mnohem nebezpečnější.

Podívejme se tedy na hlavní námitky proti migraci, jak je ve vshosting~ řešíme a jaká jsou rizika zachovávání statutu quo za každou cenu.

Změny v aplikaci či technologiích

Od migrace odrazujícím faktorem číslo jedna je nejčastěji nutnost provést aplikační či jiné technologické změny. Toto je obvyklý požadavek pro migraci v případě, že současná aplikace běží na zastaralé technologii nebo je nekompatibilní s novým hostingovým řešením.

Nutnost takové změny vždy představuje zátěž pro vývojový tým klienta, který musí upravovat aplikaci nebo se naučit pracovat s novou technologií. Komplikací může být i fakt, že klient vůbec žádný vývojářský tým k dispozici nemá, což je běžná situace zejména u menších projektů.

Na druhou stranu, zastaralost či nevhodnost použitých technologií je překážkou nejenom k migraci k jinému hostingovému partnerovi, ale i k dalšímu růstu internetového projektu, jeho zabezpečení a podobně. Doporučované aplikační změny se proto ve většině případů vyplatí bez ohledu na migraci a po jejich implementaci je přechod k novému hostingovému poskytovateli vcelku hračka.

Zastaralé technologie

Aplikace napsaná pomocí již nepodporované či obskurní technologie je častou překážkou migrace. Například taková appka napsaná v PHP 5.2 je v podstatě nezmigrovatelná, protože není kompatibilní s téměř žádnými současnými technologiemi. Je proto potřeba ji kompletně updatovat na aktuální, plně podporovanou verzi.

Úpravy aplikace pochopitelně nějsou žádný med a stojí spoustu vývojářského času. Na druhou stranu provoz aplikace běžící na zastaralé technologii je mimořádně nebezpečný – migrace, nemigrace. Takové PHP 5.2 totiž už dávno není podporováno, nejsou k němu vydávány bezpečnostní aktualizace ani opravy chyb. Kromě nekompatibility s moderními hostingovými řešeními je tedy taková aplikace ohrožena nejrůznějšími bezpečnostními útoky a hacky, které vzhledem k legislativě okolo GDPR mohou vést až k likvidačním pokutám (ve výši až 4 % obratu). Zastaralé aplikace také nebývají připraveny na to, vyrovnat se s významným přírůstkem trafficu a požadavků, pokud tedy chcete svůj byznys dále rozvíjet, aktualizaci appky se stejně nevyhnete.

Zjednodušeně řečeno: pokud je nějaká aplikace nemigrovatelná, je na místě, důkladně se zamyslet nad tím, proč tomu tak je a jak to vyřešit. S extrémně vysokou pravděpodobností je totiž něco velice špatně a nezávisle na migraci a hostingu hrozí velký průšvih.

Kompatibilita s hostingovým řešením

Dalším obvyklým scénářem je nutnost přechodu na technologii, které bude kompatibilní s nově zvoleným hostingovým řešením. Toto nastane typicky pokud se klient rozhodne k migraci z jednoduché, neredundantní infrastruktury na cluster nebo pokud chce přejít na škálovatelné řešení, ale jeho aplikace na škálování není připravena.

Příkladem je migrace z jednoho databázového serveru na databázový cluster, kdy pro ideální funkčnost klientovi doporučíme přechod ze single nodu na Galeru. Galera je pro cluster perfektním řešením a dlouhodobě bude pro klienta výhodou, ale vývojáři se musí naučit pracovat s jinou technologií, což v daný moment pravděpodobně všichni neocení.

Servisní okna a jiné nepříjemnosti

Dalším významným zdrojem obav z migrace je nutnost určitého servisního okna, kdy klientova aplikace jednoduše „nejede“. Tento krok se nedá obejít a u velkých projektů může trvat klidně celou noc. I otrlému e-shopaři při této představě není lehko.

U nás ve vshosting~ děláme vše pro to, aby výpadek byl co nejkratší, ale celý proces má své technologické limity, přes které bohužel nejede vlak. Z toho důvodu je klíčové servisní okno dobře načasovat, aby dopad na byznys klienta byl co možná nejmenší. Nové řešení před samotnou migrací také důkladně testujeme, abychom zabránili vzniku komplikací, které by výpadek mohly prodloužit.

Co když se něco pokazí?

Migrace je velký zásah a prostor pro případné chyby není malý. Proto je důležité přecházet pouze k poskytovatelům, kteří mají s migrací velké zkušenosti. Rizika tak dokážou důkladnou analýzou a pečlivým testováním nové hostingové infrastruktury účinně minimalizovat. A pokud se i tak něco úplně nepovede, jsou schopni situaci velmi rychle vyřešit.

Příkladem může být opět situace migrace databáze z jednonodového řešení například na 3-nodové. Dojde-li k tomu, že balancing přes nody nefunguje ideálně, zkušení administrátoři zvládnou databázové řešení dočasně směřovat na jeden nod, aby aplikace bez problému mohla fungovat. V mezičase na pozadí vyřeší balancing a až poté databázi přepnou na 3-nodové řešení.

Ve zcela nouzových případech je vždy i možnost udělat rollback, tedy navrátit vše do původního stavu před migrací. Na základě našich zkušeností je ale efektivnější snažit se nastalý problém co nejrychleji vyřešit (například nouzově přenastavením serverů, viz příklad s databází) a migraci dokončit. Problém, který bývá typicky aplikačního charakteru, lze adresovat následně. Ovšem i zde samozřejmě platí doporučení zvolit zkušeného poskytovatele hostingu, který je nenadálé situace schopen agilně zvládnout.

Ve vshosting~ se migrace bát nemusíte

Migrace k vshosting~ se není třeba obávat – přímo v našem datacentru totiž máme tým zkušených odborníků, kteří migrace dělají na denní bázi. Opravdu velkých migrací u nás děláme desítky ročně. Díky tomuto extenzivnímu know-how dokážeme drtivé většině potenciálních rizik předejít a vše pak probíhá hladce.

Před migrací celou aplikaci důkladně zanalyzujeme a otestujeme – mimo jiné jsme schopni pomocí performance testů zjistit výkonnost celého řešení. Na základě prvotní analýzy klientům poskytneme doporučení ohledně aplikačních změn a upozorníme je, na co si dát pozor, co změnit a čeho se vyvarovat.

Hostingové řešení u nás také navrhujeme individuálně, přesně podle potřeb dané aplikace. Nově navržené řešení velmi důkladně testujeme, a to včetně jeho kompatibility s klientovou aplikací a synchronizace se všemi zapojenými systémy (např. skladový systém, CMS, redakční systém, atd.). Díky tomu je nové řešení zcela vyladěné ještě před tím, než vůbec zahájíme migraci.

Ve specifických případech, kdy například klient nemá vlastní IT tým, jsme dokonce schopni migraci udělat zcela za něj (ovšem pouze v případě, že nejsou třeba žádné aplikační změny). Od klienta pak potřebujeme jen minimální součinnost: otestování funkčnosti nového řešení, následné odsouhlasení ostré migrace a podobně.

Datum a čas migrace samozřejmě pečlivě plánujeme spolu s klientem, aby došlo k co nejmenšímu dopadu na jeho byznys. Vzhledem k tomu, že naši zkušení administrátoři i technici jsou přítomni nonstop přímo v datacentru, nemáme problém migraci provést uprostřed noci, a to v jakýkoliv den.

Pokud i přes všechna opatření dojde ke komplikacím, velmi rychle identifikujeme jejich příčinu a problém vyřešíme, protože naši experti na provoz serverů dohlížejí 24/7 a monitorují desítky jeho parametrů.

Trend s názvem „horizontální škálování“: kdy má smysl a o co vlastně jde?

Horizontální škálování je čím dál častějším požadavkem našich klientů, ale má vždy opravdu smysl?

vývoj

Damir Špoljarič

Podívejme se blíže na to, co požadavek na horizontální škálování vlastně představuje a odkud pramení.

Hned na úvod je nutné říct, že horizontální škálování je dnes často vyžadováno primárně obchodně, technická stránka požadavků pro možnosti horizontálního škálování často pokulhává. V nejednom případě jde o požadavek, který by neměl být prioriotu pro provozovatele aplikace.

Horizontální vs. vertikální škálování

Škálování je buď vertikální nebo horizontální. Vertikální škálování tu s námi je mnoho let a zjednodušeně řečeno jde o navyšování výkonu daného serveru (ať už fyzického nebo virtuálního) nebo kontejneru. Je to nejsnazší způsob zajištění více výpočetních prostředků pro danou aplikaci.

Nevýhodou této metody je primárně její omezenost (výkon serveru nelze přidávat donekonečna). Tuto limitaci, alespoň v teoretické rovině, řeší horizontální škálování. To umožňuje paralelní přidávání nezávislých výpočetních kapacit a rozkládání zátěže mezi tyto kapacity – v ideálním případě donekonečna. Z pohledu škálování byznysu to zní skvěle. Ale…

U rozsáhlých aplikací s vizí obrovského růstu je horizontální škálování skutečně jediná možnost, jak zajistit maximální možnou škálovatelnost online aplikace. Nicméně některé služby je stále výhodnější škálovat vertikálně (například load balancery apod.). Bohužel dodnes stále některé platformy (typu AWS) nutí uživatele vybírat z předdefinovaných balíčků kombinací procesorů a pamětí. To považujeme ve vshosting~ za přežitek.

Cloudová platforma a hosting by měly být schopny se dynamicky přizpůsobit reálné potřebě konkrétních výpočetních prostředků každého klienta. Jinými slovy, pokaždé když klient potřebuje navýšit výkon pro svou aplikaci, měl mít možnost si jednoduše přidat x paměti a y procesorů bez nutnosti vždy znovu složitě zkoumat, který z nabízených „balíčků“ je pro něj ten nejvýhodnější.

Nástrahy horizontálního škálování: zkušenosti z praxe

Jak už jsme zmínili, v některých případech ani dynamická možnost vertikálního škálování nestačí a horizontální škálování se stává nezbytným. Ale vyplatí se opravdu důkladně zvážit, zda tomu tak právě ve Vašem případě skutečně je. Jakkoli je horizontálního škálování teoreticky atraktivní, v realitě naráží na řadu koncepčních nevýhod.

V první řadě horizontální škálování klade obrovské nároky na vývojáře, aby vytvářeli aplikace, které budou pro paralelní provoz a zpracovávání úloh připravené. Z praxe víme, že psaní takových aplikací je výrazně náročnější na znalosti, čas, testování (a tedy i o dost nákladnější).

Je také nutné vzít v potaz limity externích služeb, na které často narážíme. Typicky největší komplikace nastane například v případě, kdy aplikace pro provoz v paralelním režimu používá sdílený filesystem. Škálovatelnost je potom omezena pro celou aplikaci už z principu této několik desítek let staré technologie (vhodnou náhradou je například object storage). I cloudové platformy nebo infrastruktura postavená na distribuovaném řešení (například GlusterFS) dříve či později narazí na limity použité technologie, které se budou za provozu velmi špatně řešit.

Dalším problematickým aspektem bývají relační databáze, které také svým koncepčním pojetím nepočítají s tím, že je bude někdo clusterovat. Technologie v této oblasti výrazně pokročily, například skvělé zkušenosti máme s Galera Clusterem nad MariaDB, na kterém úspěšně provozujeme platformu Shoptet pro desítky tisíc e-shopů. Z tohoto pohledu jde o pokročilejší řešení, než které nabízí například Amazon s AWS Aurora.

AWS Aurora umožňuje horizontální škálování pouze pomocí tzv. „replicas“, což jsou read-only repliky jedné instance databáze. Jde tedy o velmi velmi osekané horizontální škálování, které navíc ztrácí v dnešní době smysl, neboť omezováním provozu z relační databáze (abychom udělali aplikaci více horizontálně škálovatelnou) se omezují zejména read operace na jejichž offloading se používají nástroje typu ElasticSearch. Tyto nástroje jsou naopak velmi dobře horizontálně škálovatelné, ale nejsou ze svého principu (princip ACID) určené k ukládání klíčových dat.

Read-only repliky jsou opět mechanismem starým desítky let, který nepovažujeme za technologii vhodnou pro horizontální škálování. Je tomu tak primárně z důvodu, že tato metoda nezajistí škálování 1:1 pro všechny druhy operací. Jiné možnosti AWS v případě SQL databází nenabízí.

Bezproblémové horizontální škálování díky vshosting~

Největší problém u moderních aplikací stavěných pro horizontální škálování vidíme v tom, že je pro jejich komplexnost velmi špatně predikovatelné, kde která část aplikace či komponenta narazí na jaký limit.

Ve vshosting~ asistujeme vývojářům našich klientů tak, aby jejich aplikace byla lépe a rychleji škálovatelná. Poradíme, jaké prvky v jejich aplikaci jsou či budou limitující pro další růst a připravíme individuální, robustní a plně škálovatelnou infrastrukturu bez kompromisů.

Nemá smysl prošlapávat tisickrát prošlapanou cestu, ve vshosting~ Vám díky našemu unikátnímu know-how poradíme na co se zaměřit při návrhu aplikací. Váš projekt připravíme pro globální expanzi i díky naší vlastní CDN, kterou již brzy budeme spouštět na třetím kontinentu (Asie).

Damir Špoljarič

CEO & Co-Founder

Milionové vývojové fuckups

aneb co chtít a nechtít od vývojářů Vašeho e-shopu

e-commerce vývoj

Damir Špoljarič

Náklady na vývoj e-shopu se mohou vyšplhat do milionů, o čase, který takový vývoj zabere ani nemluvě. Je proto obzvlášť důležité, aby taková investice nepřišla vniveč.

Ve vshosting~ hostujeme tisíce e-shopů a za 13 let svého fungování jsme už toho viděli opravdu mnoho. Dali jsme proto dohromady seznam věcí, na které klientům doporučujeme dát si při vývoji e-shopu pozor, pokud chtějí maximalizovat návratnost svojí investice.

Jak na celkový návrh aplikace

Držte se prověřených technologií

Dost možná Vás Vaši vývojáři budou přesvědčovat, že osvědčené technologie jsou “staré a nudné” a že místo nich máte použít horkou novinku. Tady je ale třeba zpozornět: zbrusu nové technologie jsou sice náramně cool, ale nesou s sebou i velké riziko, že do roka a do dne po nich ani pes neštěkne.

Výsledkem je pak nekompatibilita s mnoha systémy, které k chodu e-shopu potřebujete, zastarávání kvůli absenci nových updatů a samozřejmě i potíže s hledáním vývojářů, kteří s danou technologií dokáží pracovat. To vše poté vede ke špatné funkčnosti e-shopu, ztrátě klientů a tedy i tržeb.

Pokud takové riziko podstupovat nechcete, doporučujeme držet se nejpoužívanějších technologií e-shopů jako je PHP, MySQL, ElasticSearch, MongoDB nebo Redis.

Myslete na horizontální škálovatelnost

E-shop jistě tvoříte s vizí budoucího růstu. Aby Vaše technické řešení dokázalo držet krok se zvyšující se poptávkou, musí být snadno škálovatelné. Proto klientům doporučujeme, aby minimalizovali používání relačních databází a vyvarovali se těm hůře škálovatelným (jako je např. PostgreSQL).

Dalším vhodným krokem usnadňujícím horizontální škálování je eliminace sdíleného filesystému a místo něj použití object storage. Jak relační databáze, tak sdílený filesystém se rychle může stát zbytečnou brzdou růstu.

Nebojte se vyvíjet nad testing verzemi

Vývoj komplexního e-shopu může trvat i 1-2 roky, což je vzhledem k životnímu cyklu mnoha technologií poměrně dlouhá doba. Noční můrou je pak situace, kdy po milionové investici a roku či dvou vývoje e-shop spustíte a zjistíte, že už je z hlediska technologií v polovině životnosti nebo dokonce úplně zastaralý.

Pro prodloužení žívotního cyklu e-shopu doporučujeme, aby vývojáři používali nové verze ověřených technologií, které jsou teprve v testingu. Díky tomu bude Váš e-shop zastarávat pomaleji a návratnost Vaší investice do vývoje tak bude výrazně lepší.

Přejděte na microservices

Monolitické (tj. „v jednom kuse“) aplikace jsou v dnešním vývojovém světě na ústupu, a to z praktických důvodů. Když je u takové obří aplikace nutné část vyměnit či opravit, často to vede k chybám v celé aplikaci. Jakékoliv úpravy nebo implementace nových features jsou proto velmi problematické.

Z toho důvodu získávají na popularitě tzv. microservices, pomocí nichž lze vyvinout dlouhodobě udržitelné aplikace s možností nahrazení jen některé části. Vaši vývojáři tak nestráví veškerý čas opravováním bugů a mohou se místo toho věnovat vývoji nových features.

Skryté nástrahy vývoje e-shopu

U těchto technologií zpozorněte

Tady jsou top 3 technologie, které se při vývoji a následném používání e-shopu mohou stát kamenem úrazu: Varnish, PostgreSQL a Magento.

Varnish

Varnish je aplikační cache na zrychlení aplikace. Ovšem aplikace, která není bez Varnishe dostatečně rychlá, je podezřelá. Pro představu z našich klientů jich Varnish používá cca 2 %, ostatní ho nepotřebují protože jejich e-shop je dostatečně rychlý i bez něj.

PostgreSQL

Jak už jsme zmiňovali v souvislosti s horizontálním škálováním, PostgreSQL se rychle stane u velkých e-shopů brzdou. Je velmi špatně škálovatelné a dodnes neumí pořádně synchronní repliku. Pro velké e-shopy (i malé s ambicemi růstu) proto doporučujeme škálovatelnější technologie.

Magento

Magentu u nás přezdíváme „řešení pro ty, kteří mají neomezený rozpočet a nemají potřebu škálovat“. Jak je asi zřejmé, není Magento podle naší zkušenosti vhodné pro e-shopy s ambicemi růstu. Sice ulehčí vývoj, ale chybí mu škálovatelnost.

Pozor na skrytý vendor lock-in či licence

Další nástrahou při vývoji e-shopu může být přílišná závislost na některé z externích služeb. Častá je obtížná migrace k jiné službě v případě problémů nebo například výrazného zdražení služby. Přitom v mnoha případech je poměrně jednoduché analogickou službu vyřešit interně. Například takové fulltextové vyhledávání není třeba dělat externí službou, ale lze použít ElasticSearch in-house.

Dalším typickým příkladem je proprietární databáze (pokud je databáze napsaná na míru externí službě, nedá se nikam jinam přenést). Je třeba také dát pozor na neošetřené licence jako je například Java SDK.

Jak nepromarnit peníze za reklamu

Nakonec jsme dali dohromady pár organizačních a technicky-provozních rad, které Vám pomůžou zajistit, že peníze, které investujete do reklamy, nepřijdou kvůli limitům Vašeho e-shopu vniveč.

Oddělte vývojové, testovací a produkční prostředí

Tipem číslo jedna je nutnost oddělení vývojového, testovacího a produkčního prostředí. Produkční prostředí (to, které vydělává) je svaté – kolem něj je třeba chodit obloukem, protože každý problém se rapidně změní v ušlý zisk.

Vývojáři by nové věci měli dělat ve vývojovém prostředí, pak otestovat v prostředí testovacím a teprve poté nasadit do produkce. Pouze důkladným otestováním mimo produkční prostředí se můžete vyhnout se situaci, že bug v produkci objevíte v pátek večer o Vánocích a podobně.

Znejte limity e-shopu a pravidelně testujte

Jistě se shodneme, že poznat limity Vašeho e-shopu až při spuštění televizní kampaně není ten nejvhodnější/nejlevnější okamžik. Proto našim klientům doporučujeme, aby investovali do tzv. performance testů. Ty slouží k ověření limitů a slabých míst v simulované vysoké návštěvnosti webu.

Dobré performance testy navíc pouze „nebuší“ do aplikace, ale simulují skutečného návštěvníka webu – např. prohlížením produktů, přidáváním zboží do košíku, vyhledáváním ve fulltextu atp. Díky tomu přesněji zjistíte, kde se nacházejí slabá místa vašeho webu a budete moci s touto informací dále pracovat.

Bezpečnost (nad rámec bezpečného návrhu aplikace)

Nejen kvůli GDPR platí staré dobré „bezpečnost nade vše“. Když v dnešní době uniknou hesla z Vašeho e-shopu, riskujete kromě ztráty důvěry svých zákazníků i nepěkné pokuty a další nepříjemnosti.

Pro co největší snížení rizika, že k něčemu podobnému dojde, můžeme ze zkušenosti doporučit 3 hlavní opatření:

Pravidelné penetrační testy (otestují slabá místa z hlediska bezpečnosti)
AntiDDOS ochranu (jen od začátku roku jsme zaznamenali přes 1500 relevantních útoků, velká část je způsobovaná automaticky)
Zálohy + možnost rychlého obnovení (jak dlouho trvá obnova ze záloh? Pár minut nebo několik dní?)

Horizontální škálování MySQL

Jak efektivně rozložit databázi do několika serverů a čeho se vyvarovat.

managed databáze služby vývoj

vshosting~

Databázové servery jsou kritickou částí infrastruktury každého webového projektu a se vzrůstající velikostí roste také jejich význam. Dříve či později se ale dostaneme do stavu, kdy výkonové požadavky na databázi nebude možné řešit pouze přidáváním další paměti a vylepšováním procesorů. Navyšování zdrojů jednoho serveru má své technické limity a časem skončíme u nutnosti rozložit zátěž do více serverů.

Před realizací takového kroku je více než vhodné si ujasnit, čeho chceme dosáhnout. Některé modely distribuce zátěže nám pouze pomohou zvládnout vyšší množství požadavků, některé nám vyřeší i problém případné nedostupnosti jednoho ze strojů.

Škálování, vysoká dostupnost a další pojmy

Nejdříve se pojďme podívat na základní pojmy, se kterými budeme dnes operovat. Není jich mnoho, ale bez jejich znalosti se nehneme dál. Zkušení škálovači mohou tuto část s klidným svědomím přeskočit.

Škálovatelnost (scalability)

Schopnost systému (v našem případě databázového prostředí) reagovat na zvýšenou nebo sníženou potřebu zdrojů. V praxi rozeznáváme dva základní druhy škálování a to škálování vertikální a horizontální.

Při vertikálním škálování zvyšujeme prostředky, které má daná databáze k dispozici. Typicky se jedná o přidávání dostupné paměti serveru a zvyšování počtu jader. Vertikálně lze škálovat prakticky libovolnou aplikaci, dříve či později ale narazíme na hardwarové limity platformy.

Proti tomu stojí horizontální škálování, kdy výkon aplikace zvyšujeme přidáváním dalších serverů. Tímto způsobem můžeme zvyšovat výkon prakticky neomezeně, aplikace musí ale s tímto způsobem distribuce počítat.

Vysoká dostupnost (high availability)

Schopnost systému reagovat na výpadek části systému. Předpokladem pro vysokou dostupnost je schopnost provozovat aplikaci ve více instancích.

Další instance mohou být plnohodnotně zastupitelné a zpracovávat požadavky paralelně (active-active setup) nebo mohou být v režimu stand-by, kdy na sebe pouze zrcadlí data, ale nejsou schopny odbavovat provoz (active-passive setup). V případě problému je vybrána jedna z instancí v passive režimu a je převedena do active.

Master node

Řídící komponenta systému. V případě databází se jedná o instanci v režimu čtení i zápisu. Pokud máme více plnohodnotných master nodů, mluvíme o tzv. multi-master setupu.

Slave node

Záložní kopie dat. V klidovém stavu na sebe zrcadlí data a funguje v režimu pouze pro čtení. Pokud dojde k výpadku master nodu, je jeden ze slave nodů vybrán a převeden do master režimu. Po opravě původního master nodu se buď nový master vráti do stavu slave, nebo zůstává masterem a původní master je připojen jako slave node.

Asynchronní replikace

Po zápisu dat na master nodu je tento zápis potvrzen klientovi a zapsán do transakčního logu. Později v čase je tato změna replikována na slave nody. Dokud nedojde k replikaci, jsou nová nebo změněná data dostupná pouze na master nodu a v případě jeho výpadku jsou nedostupná. Asynchronní replikace je typická pro MySQL.

Synchronní replikace

Klientovi je zápis potvrzen až poté, co jsou data zapsaná na všechny nody v clusteru. Odpadá zde riziko výpadku nových dat (data jsou změněna všude nebo nikde), je ale výrazně náchylnější k problémům na síti mezi nody.

V případě síťového výpadku je výkon clusteru dočasně degradován, nebo je dokonce dočasně zastaven příjem nových požadavků na změnu dat. Tento způsob replikace se využívá v případě multi-master setupů v kombinaci s pluginem Galera.

Master – Slave replikace

Master – slave je základní podoba replikace databázového clusteru. V tomto návrhu máme jeden řídící master node, který přijímá všechny typy dotazů. Slave node (případně více nodů) na sebe zrcadlí změny pomocí asynchronní replikace. Slave nody tedy nemusí mít k dispozici nejnovější kopii dat.

Pokud dojde k výpadku master nodu, je vybrán slave s nejnovější kopií dat a ten je prohlášen za nový master. Každý slave node si ověřuje, o kolik je zpožděn oproti master nodu. Tuto hodnotu můžeme zjistit v proměnné Seconds_behind_master a je velmi důležité ji monitorovat. Vzrůstající hodnota ukazuje na problém v replikaci změn na master nodu.

Slave node funguje v režimu read-only, dokáže tedy odbavovat dotazy typu select. V tom případě mluvíme o tzv. read/write splitu, o kterém se zmíníme dále.

Master – Master replikace

Master – master setup je takový, kde máme právě dva master nody. Oba dva jsou schopni odbavovat všechny typy dotazů, mezi nimi ale probíhá asynchronní replikace. To přináší nevýhodu v případě, kdy data zapsaná na první node nemusí být okamžitě dostupná na druhém nodu. V praxi toto nastavujeme tak, že každý node je zároveň slave nodem druhého.

Tento setup se hodí v okamžiku, kdy před MySQL servery postavíme loadbalancer, který na každý stroj směřuje polovinu spojení. Každý node je ale samostatným masterem, neví nic o tom, že druhý node je taky v master režimu a je tedy nutné nastavit krok auto incrementu na 2. Pokud toto neprovedeme, bude docházet ke kolizím primárních klíčů, které využívají auto increment.

Každý z master nodů může mít u sebe další slave nody, které lze použít pro čtení dat (read/write split) a jako zálohu.

Multi – Master replikace

O multi-master setupu mluvíme v okamžiku, kdy máme v clusteru více než dva master nody. Tento setup nelze postavit v základní MySQL, ale musíme použít implementaci protokolu wsrep, např. plugin Galera.

Wsrep implementuje synchronní replikaci a tedy je velmi náchylný na problém na straně sítě a vyžaduje také časovou synchronizaci všech nodů. Umožňuje ale zasílat všechny typy dotazů na všechny nody v clusteru, takže je velmi vhodný pro řešení loadbalancingu. Nevýhodou je fakt, že všechny replikované tabulky musí používat engine innodb, tabulky využívající jiný engine nebudou replikovány.

Shardování

Shardování je dělení dat na logické segmenty. V MySQL se pro tento způsob ukládání dat používá název partitioning a prakticky znamená, že data jedné tabulky jsou rozkládány na různé servery, různé tabulky nebo různé datové soubory v rámci jednoho serveru.

Shardování dat je vhodné v situaci, kdy máme data, která tvoří oddělené skupiny. Typickou ukázkou jsou např. historické záznamy (shardujeme podle času) nebo data uživatelů (shardy vytváříme podle ID uživatele). Díky rozkladu dat do samostatných skupin můžeme efektivně kombinovat různé druhy storage, kdy aktuální data máme na rychlých SSD discích a starší data, u kterých nepředpokládáme časté využití, ukládáme na levnější rotační disky.

Shardování se velmi často používá v NoSQL databázích, napřiklad ElasticSearch.

Read – Write splitting

V režimu Master-Slave replikace máme k dispozici výkon slave nodů, který ale nemůžeme použít pro zápisové operace. Pokud ale máme aplikaci, kde tvoří většinu dotazů pouze selecty (typicky webové projekty), můžeme jejich výkon využít pro čtení. V tomto případě tedy aplikace směřuje zápisové operace (insert, delete, update) na master node, ale selecty posílá na skupinu slave nodů.

Díky tomu, že jeden master node může mít mnoho slave nodů, pomůže nám read/write splitting se zvýšením odezvy celé aplikace pomocí rozkládání čtecích operací.

Toho chování není potřeba na straně databázového serveru nijak konfigurovat, je ale potřeba jej řešit na straně aplikace. Nejjednodušší variantou je v aplikaci udržovat dvě spojení, jedno pro zápis a druhé pro čtení. Aplikace se pak podle typu dotazu rozhoduje, jaké spojení pro daný dotaz použije.

Druhou variantou, vhodnou pro případ, kdy nejsme schopni implementovat read/write split na úrovni aplikace, je využití aplikační proxy, která rozumí dotazům a je schopna je automaticky předávat na odpovídající nody. Aplikace si drží pouze jedno spojení na proxy a nestará se o druhy dotazů. Typickým představitelem takové proxy je řešení od Maxscale. Bohužel se jedná o komerční produkt, nabízí ale verzi zdarma s omezením na tři databázové nody.

Škálujeme za vás

Nemáte kapacitu či chuť na to, spravovat si a škálovat databáze sami? Uděláme to za vás.

Postaráme se i o velmi složitý provoz a vyladění široké škály databází. Zajistíme jejich maximální stabilitu, dostupnost a škálovatelnost. Náš tým adminů spravuje desítky tisíc databázových serverů a clusterů, takže budete v rukou opravdových expertů.

Dockerizace standalone aplikací

Jak na dockerizaci jakéhokoliv typu aplikace a dosažení jejich provozu v Docker kontejneru.

Kubernetes služby vývoj

vshosting~

Většina návodů pro dockerizaci aplikací, které naleznete na internetu, je určena pro specifický jazyk a prostředí. My se ale budeme věnovat obecným postupům určeným pro jakýkoliv typ aplikace a ukážeme vám, jak je možné dosáhnout jejich provozu v Docker kontejneru.

Výběr base image

Pro bezproblémový provoz a následné jednoduché úpravy a upgrady je vhodné vybrat co nejideálnější (a autorem dobře podporovaný) base image. Vzhledem k tomu, že na Docker Hub může nahrávat image naprosto kdokoliv, je dobré vybraný image důkladně prozkoumat a ověřit si, zda neobsahuje nějaký škodlivý software, nebo například staré verze knihoven s bezpečnostními problémy.

Dobrou volbou pro začátek jsou image označené jako „Docker certified“, které poskytují určitou formu garance, že image je v pořádku a pravidelně aktualizovaný. Příkladem pro takový image je PHP nebo Node.js.

Dále můžeme také doporučit sbírku od firmy Bitnami, která obsahuje spoustu předpřipravených image aplikací a vývojových prostředí.

Doinstalování dalšího software

Podle toho, jaký image jsme si pro svůj projekt vybrali, můžeme provést instalaci dalšího software, tak, abychom splnili všechny předpoklady pro bezproblémový provoz aplikace.

Nejlepším řešením je použít balíčkovací systém distribuce, na které je image založen (obvykle Ubuntu/Debian, Alpine Linux nebo CentOS). Je také velmi důležité udržovat seznam nainstalovaného softwaru co nejužší, například neinstalovat do kontejneru textové editory, kompilátory a jiné nástroje pro vývoj.

Vlastní soubory v Docker image

Do výsledného image budeme také chtít přidat vlastní soubory. Ať už konfigurace, přímo zdrojové kódy nebo binární soubory z aplikace. V Dockerfile se k tomu používají příkazy ADD nebo COPY, který je transparentnější, ale neumožňuje některé pokročilejší funkce, jako je například rozbalení archivu do image.

Definice oprávnění

Ačkoliv je to ta nejjednodušší cesta, vyhněte se spouštění aplikace v kontejneru za uživatele root, přináší to mnohá bezpečnostní rizika a zesiluje možnost úniku z kontejneru v případě kompromitace aplikace nebo po využití nějaké bezpečnostní chyby v softwaru třetích stran, které využíváte.

Definice portů služby

Pokud vaše aplikace nepoužívá uživatele root, případně nemá zvýšené capabilities (CAP_NET_ADMIN), není možné používat tzv. privileged ports. (1-1024). To však v Dockeru není nutné. Použijte jakýkoliv vyšší port (např. 8080 a 8443 místo 80/443 u webserveru) a proveďte mapování portu prostřednictvím parametrů Dockeru.

Spuštění aplikace v kontejneru

Jakkoliv je jednoduché spouštět přímo binární soubor vaší aplikace (nebo web serveru, Node.js, apod.), mnohem sofistikovanější cestou je vytvořit si vlastní tzv. entrypoint – tedy skript, který provede úvodní konfiguraci aplikace, může reagovat na proměnné prostředí apod. Dobrý příklad tohoto řešení můžeme najít například v oficiálním image PostgreSQL.

Metody konfigurace

Velká většina aplikaci vyžaduje pro správné spuštění správnou konfiguraci. Je samozřejmě možné použít přímo konfigurační soubor (například v mountovaném adresáři zvenku kontejneru), ale ve spoustě případů je lepší použít předem připravený entrypoint skript, který nám vhodnou konfiguraci při spuštění připraví pomocí template a proměnných prostředí kontejneru.

Aplikační data

Vyhněte se ukládání dat na filesystém kontejneru, ve standardní konfiguraci dojde po restartu kontejneru k jejich smazání. Využijte bind mounts (adresář vně kontejneru), nebo mounted volume.

Stejně tak je nutné vyřešit ukládání/odesílání logů. Nejvhodnější je samozřejmě použití centralizovaného logování pro všechny vaše aplikace (ELK stack), dobrou službu však odvede i obyčejný remote syslog.

Co dál?

Vždy je co zlepšovat. Nad rámec tohoto článku je možné se zamyslet nad různými možnosti configuration managementu, ELK stacku pro logování, sbírání aplikačních a systémových metrik přes Prometheus a možnosti dosažení load balancingu a high-availability pro naši aplikaci s použitím Kubernetes – které vám ve vshosting~ rádi postavíme přímo na míru vašemu projektu 🙂

NTP servery: proč jsou tak důležité?

Proč je důležitá přesná synchronizace času a jakou roli v ní hrají NTP servery.

e-commerce vývoj

Damir Špoljarič

Předtím, než se dostaneme k tomu, co je to NTP server a jaké je jeho využití, je třeba zmínit důležitost přesné synchronizace času.

Časová synchronizace je nezbytná pro všechny počítačové sítě a především pro ty, které provádějí transakce citlivé na čas. Čas, ve formě časových známek, je používán například pro určení, kdy došlo k transakci nebo kdy je třeba ji uskutečnit. Pokud se čas v rámci sítě liší, může dojít ke ztrátě dat nebo transakce nemusí vůbec proběhnout.

Co je to NTP?

NTP (Network Time Protocol) je protokol pro synchronizaci vnitřních hodin počítačů, který zajišťuje, aby všechny počítače v síti měly stejný a přesný čas. NTP byl vyvinut Davidem L. Millsem na univerzitě v Delawaru a do provozu uveden v roce 1985. Pracuje s využitím jediného zdroje času, který umožňuje synchronizovat čas mezi všemi zařízeními, které jsou součástí sítě a byl navržen tak, aby odolával zpoždění následkem doručovaní paketů. NTP se řadí mezi nejstarší dosud používané IP protokoly.

Přesný čas díky síti GPS

Jedním z nejbezpečnějších a nejpřesnějších způsobů získávání přesného času je využití časových kódů přenášených sítí GPS. Atomové hodiny na palubě satelitů generují tyto časové kódy, které jsou pak velmi přesné. Systém GPS je navíc k dispozici kdekoli na planetě s výhledem na oblohu.

GPS časové kody přijímá NTP GPS server, který je zároveň i zpracovává a distribuuje po síti.

NTP servery v každodenním životě

NTP časové servery fungují všude kolem nás. Bezpečnostní kamery, bankomaty, radary na měření rychlosti a všechny další systémy, které se zabývají časově citlivými daty jsou závislé na synchronizaci času. NTP je zásadní také v případě měnových kurzů, kde se ceny mění každou vteřinu. Satelitní navigační systémy, jako např. GPS, se rovněž spoléhají na přesné měření času pro bezchybné výpočty polohy.

Atomové hodiny

NTP servery berou přesný čas z atomových hodin. Ty jsou jedním z nejpřesnějších časoměrných zařízení v historii. V současnosti je cca 400 atomových hodin na celém světě, které přispívají k výpočtu Mezinárodního atomového času (TAI). Jejich chybovost je pouze jedna vteřina za 100 milionů let.

Přestupná sekunda

Čas se měří i podle rotace země, která trvá o zlomek vteřiny ročně déle než měření atomových hodin. Aby se čas srovnal, jednou za pár let se k atomovému času přidá takzvaná přestupná sekunda (leap second). Od roku 1972 bylo přidáno 27 přestupných sekund. V praxi pak čas na atomových hodinách vypadá o půlnoci, kdy je vteřina přidána, takto:

23:59:59

23:59:60

00:00:00

00:00:01

Přesný čas je zásadní pro chod serverů

Čas je spojením mezi virtuálním světem a světem reálným. Příkladem je nákup na e-shopu. Vytvoření objednávky zboží v e-shopu musí být zaznamenáno s přesným datem a časem kvůli návaznosti na další transakce v reálném světě (platba ve lhůtě splatnosti, dodání ve smluvené dodací lhůtě, vyřízení reklamace atd.)

Přesný čas je nutný také pro běh základních aplikací jakými jsou kalendáře, budíky a spouštění úloh na serverech. Většina operací v rámci skupin serverů (clustery, cloudy, distribuované storage systémy) musí probíhat zároveň ve stejný čas nebo musí mít přesně danou časovou posloupnost, a proto je synchronizace času nutná.

NTP ve vshosting~

vshosting~ provozuje dva fyzické časové servery:ntp1.vshosting.cz a ntp2.vshosting.cz. Oba servery jsou vyhrazené pro tento účel a RTC HW v těchto serverech je upraven pro vyšší přesnost. Oba servery se synchronizují z atomových hodin (stratum 1) Ústav fotoniky a elektroniky AVČR a Fyzikálně-technického federálního institutu (PTB.de).

Softwarové load balancery

aneb jak na bezproblémovou škálovatelnost aplikací

vývoj

Damir Špoljarič

S rozmachem veřejných cloudů začínají i menší projekty řešit vysokou dostupnost aplikací a snadné škálování. Zásadní komponentu v návrhu takového řešení hrají load balancery. Load balancer je aplikace, která distribuuje požadavky z Internetu na aplikační stroje a v případě problému dokáže nefunkční aplikační server odpojit z provozu.

Na ilustraci vidíte, jak takový typický návrh balancované aplikace vypadá:

Požadavky jdou z Internetu na load balancer, který se na základě vnitřních metrik rozhodne, kterému aplikačnímu serveru předá požadavek k vyřízení. Z Internetu jsou dostupné pouze load balancery, aplikační stroje jsou “schované” za nimi. Škálování aplikace probíhá jednoduše tak, že se nový aplikační stroj připojí do load balanceru a ten začne požadavky zasílat i na něj. Load balancery se staví ve dvojicích, kdy druhý slouží jako záloha v případě, že primární load balancer selže.

Load balancer vs. reverzní proxy

Podobnou roli jako load balancery může sehrát i reverzní proxy. Zatímco load balancer pracuje na úrovni spojení, reverzní proxy rozumí přenášeným datům, čímž dokáže efektivněji řídit provoz a cachovat odpovědi aplikačních serverů. Zároveň je ale většinou jednoúčelová a pracuje pouze s protokolem, na který je navržena.

Nejčastěji se reverzní proxy nasazují před webové servery, kdy je spousta odpovědí prakticky totožná. Díky cache dokáží dramaticky snížit nároky na aplikační stroje, a tím snížit náklady na provoz. Některé load balancery dokážou pracovat v obou režimech.

Softwarový vs. hardwarový load balancer

Softwarové load balancery jsou univerzální a nasazují se jako běžná aplikace zpravidla na linuxový server. Díky tomu je jejich provoz levný, avšak při vysokém množství požadavků mohou trpět problémy s výkonem. Pro nasazení ve velkých prostředích se používají hardwarové load balancery, které mají podobu “krabic” o rozměru 1U nebo 2U. Mají výrazně vyšší výkon a stabilitu (běžně v režimu “nastavit a zapomenout”), ovšem zároveň se jejich pořizovací cena pohybuje v řádech statisíců až milionů korun. Nejznámějším zástupcem rodiny hardwarových load balancerů jsou výrobky firmy F5.

Podíváme se důkladněji na čtyři zástupce softwarových load balancerů, které se praxi používají nejčastěji.

HAProxy je nejčastěji nasazovaný load balancer. Vyznačuje se vysokou stabilitou, výkonem a snadnou konfigurací. Dokáže pracovat v režimu TCP load balanceru, kdy pouze předává požadavky aplikačním strojům, tak i v režimu reverzní proxy pro HTTP, kdy je schopna předávat požadavky na základě jejich metadat, jako je požadovaná URL nebo HTTP hlavičky. V režimu HTTP balanceru se také umí postarat o terminaci SSL šifrování, kdy na aplikační stroje jde požadavek už nešifrovaný a nemusí tedy pálit výkon dešifrováním a opětovným šifrováním provozu. Bohužel si není schopna sama řešit požadavky na certifikáty pro nové domény, ale musí mít všechny certifikáty k dispozici při startu. Hodí se tedy v prostředí, kde je malé množství různých domén a certifikátů. Velkou výhodou HAProxy jsou velmi kvalitní statistiky provozu dostupné přes webové rozhraní nebo přes unix socket. V režimu HTTP podporuje kromě staršího HTTP/1.1 i moderní protokol HTTP/2.

Trpí ovšem i několika neduhy. Z nejzásadnějších můžeme zmínit chybějící podporu rekonfigurace on-the-fly, kdy pro změnu konfigurace load balanceru je vyžadován restart služby. Dále se můžeme potkat s problémy při nedostupnosti DNS pro překlad jmen cílových serverů a chybějící podpora pro clusterované řešení.

Pro výběr cílového aplikačního serveru používá několik předpřipravených algoritmů. Můžete směřovat požadavky prostým i váženým round-robinem (kdy jsou požadavky distribuovány střídavě přes všechny aplikační servery) nebo lze využít módu leastconn, kdy se požadavek předává na stroj s nejmenším množstvím aktuálně obsluhovaných požadavků. Zároveň je schopna hlídat dostupnost a zdraví aplikačních serverů pravidelným zasíláním požadavků na nastavený endpoint a na základě odpovědi od serveru odstřihnout nefungující server z provozu. Podporuje také servery v režimu backup, na které je směrován provoz, pokud není dostupný žádný z hlavních serverů.

Konfigurace load balanceru se provádí v souboru /etc/haproxy/haproxy.conf. Jedná se o jednoduchý konfigurační soubor, kde se nastavují frontendy (tj. veřejně dostupné služby, které HAProxy přijímá) a backendy (seznamy aplikačních serverů, které zpracovávají požadavky). HAProxy má velmi dobře zpracovanou dokumentaci. Díky jejímu rozšíření naleznete na webu spoustu návodů, jak ji nastavit přesně podle vašich požadavků.

HAProxy se nachází ve většině distribucí, bohužel velmi často ve starých verzích. Aktuální verze je dostupná na webu haproxy.org, kde naleznete i aktuální balíky pro distribuce. HAProxy podporuje nasazení na linuxu, BSD, Solarisu a AIXu. Windows ani Mac podporován není. Kromě open-source komunitní verze je dostupná i komerční podoba s placenou podporou pod názvem HAProxy Enterprise Edition a hardwarový load balancer postavený na HAProxy s názvem ALOHA hardware appliance.

Traeffik je moderní load balancer pracující v režimu HTTP proxy. Konfiguraci může mít uloženu v textových souborech ve formátu TOML nebo v distribuovaném key-value storage. Aktuálně podporuje úložiště etcd a consul. Dokáže komunikovat s Kubernetes a automaticky vyhledávat nové stroje a odpojovat zrušené. Na rozdíl od HAProxy podporuje živou konfiguraci, kdy je schopen hlídat změny v konfiguračních souborech nebo v konfiguračním úložišti a reagovat na změny.

Podporuje pouze balancování HTTP provozu, není tedy moc praktický pro použití v interní síti. Jeho velkou výhodou je přímá podpora pro Let’s encrypt, kdy je schopen si automaticky žádat o certifikáty pro neznámé domény a zároveň hlídat expiraci existujících certifikátů.

Velkou nevýhodou Traeffiku jsou časté chyby v dokumentaci. V nasazení jste tedy často odkázáni na metodu pokus-omyl a konzultace na veřejném Slack channelu projektu.

Když už se vám podaří Traeffik rozjet, má velmi slušný výkon a stabilitu. V základu nabízí jednoduché webové rozhraní s přehledem zaregistrovaných aplikačních serverů a základní statistiky provozu.

Traeffik je dostupný jako staticky linkovaná binárka (je psaný v Go) na webu projektu nebo na GitHubu, kde je k dispozici i aktuální seznam nahlášených chyb. Autoři Traeffiku také nově nabízí komerční podporu.

Nginx je webový server, který má podporu loadbalancování tak nějak mimoděk. Má velmi vysoký výkon při práci s HTTP provozem, kdy využívá svůj vysoký potenciál coby webového serveru. Velmi dobře cachuje odpovědi z aplikačních serverů, reaguje na různé typy požadavků a je schopen je ve vysoké škále upravovat.

Vzhledem k jeho hlavnímu účelu web serveru je velmi vhodný pro balancování HTTP provozu, zvládá ale také balancování TCP a UDP spojení. Nginx je díky své popularitě k nalezení v repozitářích distribucí v poměrně nových verzích. K dispozici je i placená verze s podporou pod názvem Nginx+.

Nginx nepodporuje on-the-fly konfiguraci, pro změnu je nutný reload služby. Healthcheck pro aplikační servery je dostupný přes modul ngx_http_healthcheck_module, který ovšem pracuje pouze na úrovni HTTP (kontroluje HTTP status).

IPVS

IPVS, plným názvem IP virtual server, je load balancer zabudovaný přímo v linuxovém kernelu pomocí modulu ip_vs. Díky tomu dosahuje velmi vysokých výkonů, srovnatelných s hardwarovými load balancery, zároveň má velmi malý dopad na systémové prostředky a vynikající stabilitu. IPVS je pouze L3 load balancer, pracuje tedy na úrovni TCP/UDP spojení. Není schopen předávat požadavky na základě metadat (nevidí do přenášených dat), takže je vhodný pro řešení balancingu služeb pouze na základě portu služeb.

Konfiguruje se přes utilitu lmanager, která je dostupná ve všech linuxových distribucích. Po tomto balanceru sáhněte, pokud chcete na jednom místě balancovat více různých služeb a jde vám primárně o výkon. Své uplatnění tedy nalezne u velkých internetových projektů, jako balancer na úrovni datacenter a pro exponované služby. Zvládá on-the-fly konfiguraci, kontroluje dostupnost cílových serverů a podporuje balancování pomocí algoritmu round-robin včetně podpory různých vah u cílových serverů (wrr algoritmus).

Nasazení jakéhokoliv loadbalanceru je nutná podmínka k automatickým reakcím na výpadky aplikačních serverů a velký krok k zajištění bezproblémové škálovatelnosti aplikací. Díky velmi příznivému poměru potřebného výkonu a počtu spojení se jeho použití nijak drasticky neprojeví na ceně provozu infrastruktury. Load balancer vždy vybírejte s ohledem na druh provozu, velmi často si vystačíte se specializovaným load balancerem pro konkrétní sadu protokolů a využijete možnosti, které nabízí balancer, který rozumí přenášeným datům.

Článek byl publikován naším Senior Infrastructure Adminem na webu www.starejajtak.cz