Magento je výkonná e-commerce platforma, která zahrnuje vše, co je třeba pro prodej online. Kromě samotného e-shopu dokáže řešit i sklad, marketing, fakturace a účetnictví. V současné době Magento přichází ve dvou verzích: Magento Open Source (dříve Magento Community Edition) a Magento Commerce (který je určen pro vetší společnosti s vlastními vývojáři).

Magento je jednou z nejvíce využívaných e-commerce platforem a v hodnocení uživatelů získává konzistentně vysoké hodnocení. Ke správnému fungování Magenta je nicméně třeba mít zkušeného vývojáře samotné aplikace a také zkušeného poskytovatele hostingu, který ví, jak servery pro Magento optimalizovat.

Potřeba výkonného hostingu

Jak jsme již zmínili, u Magenta nelze podcenit hosting. Platforma je náročná na výkon a tomu musí odpovídat i parametry hostingu. Pokud se oprostíme od problémů a chyb samotné aplikace, tak je většina problémů v Magento způsobena malým výkonem webového serveru, resp. prostředím, kde je Magento provozováno. Magento je pomalejší a má mnohem více requestů než ostatní systémy, ale existuje několik způsobů jak platformu urychlit.

Zrychlení Magenta

Magento obvykle nelze provozovat přímo na webovém serveru, ale je nutné využívat cachovací proxy (aktuálně je podporovaný pouze Varnish).
Pokud chcete, a v dnešní době je to už standard, provozovat SSL verzi, je nutné před Varnish proxy předsadit Nginx nebo jiný SSL terminátor. Co se týká samotného webového serveru, je možné použít Apache s PHP modulem nebo Nginx s PHP-FPM. Jedním z nejúčinnějších způsobů, jak dál urychlit Magento, je použití akcelerátorů PHP. U základních instalací je APC prohlašována za nejlepší řešení.

Možná jsou tedy dvě řešení:

• NGINX → VARNISH → APACHE (PHP-MODUL + APC, Memcache, Redis) → MariaDB
• NGINX → VARNISH → NGINX (PHP-FPM + APC, Memcache, Redis) → MariaDB

V případě větších instalací je pak vhodné využívat Redis pro cache i jako session handler.
Pokud se rozhodnete provozovat celou instalaci na jednom serveru, je nutné mít výkonný hardware nebo hosting, který Magento přímo podporuje. O paměť, CPU a IOPS budou soupeřit hlavně PHP, MySQL a Varnish.

Provoz Magenta v clusteru

Pokud se rozhodnete provozovat Magento v nějakém clusterovém režimu (buď kvůli výkonu nebo kvůli vysoké dostupnosti), Magento s tímto nastavením nativně nepočítá. Existuje několik možností, jak cluster sestavit:

• Složitější varianta je používat za load balancerem Varnish na každém backendu, ale pak je nutné se správně vypořádat s disvalidací cache a s podobnými dalšími problémy.
• Jednodušší způsob je nechat balancing na Varnish cache, která je sama o sobě dostatečně výkonná, aby dokázala zvládnout předávat požadavky na mnoho backendů.

Při clusterových instalacích se zároveň doporučuje počítat s dedikovaným serverem pro admin backend, u kterého paradoxně cachovaní není úplně žádoucí. U verzí 2 a méně se doporučuje povolit funkci Magento Compilation pro urychlení úložiště Magento.

Z naší zkušenosti vyplývá, že nejčastěji dochází ke zpomalování vlivem následujících chyb v aplikaci:

44 % SQL dotazů uvnitř smyčky
25 % načítání stejného modelu několikrát
14 % využití redundantního datového souboru
10 % výpočet velikosti pole na každé iteraci smyčky
7 % neefektivní využití paměti

Závěr: Zkušený hosting a zkušený programátor vyladí fungování Magenta

Mezi výhody Magenta patří robustnost a to, že je univerzální. Na druhou stranu je těžké zajistit, aby fungovalo optimálně. Pokud uvažujete o využití Magenta pro váš e-shop, ujistěte se, že:

1. programátor aplikace má s Magentem zkušenosti,
2. hosting, který jste si vybrali ví, jak server pro Magento vyladit tak, aby vše perfektně fungovalo a neztrácela se rychlost.

Scaling je často skloňované slovo a zaklínadlo všech moderních online apps jako must have. Byť je často škálování považováno za výhradní atribut infrastruktury, pravdou je, že škálování ovlivňuje zejména aplikace a její technologické požadavky. Vysvětlíme si, čemu byste se měli jako vývojáři moderních aplikací pokusit vyhnout, aby byla zajištěna maximální možnost škálování.

Scaling, Autoscaling, Scale-up, Scale-out

Na začátek krátké vysvětlení základních pojmů. Škálování, tedy scaling, je navyšování výpočetních prostředků aplikací nebo paralelizace výpočetních jednotek (v zásadě stále „přidávání výkonu“). Pokud se má škálování odehrávat dynamicky a automaticky dle aktuální potřeby, jde o autoscaling. Autoscaling se rozhoduje podle různých metodik – load serveru, objem datových toků, počet requestů, latence requestu, množství chyb, které vrací aplikace z důvodu nemožnosti request odbavit.

V Zeropsu budeme u autoscaling podporovat téměř vše zde uvedené. Oproti AWS a jiným obdobným tradičním cloudovým službám však nebudeme uživatele trápit laděním metrik a Zerops provede nastavení podle best practices pro daný use case, zkrátka Zero Operations ;-).

Scale-up je model vertikálního škálování, což je nejtypičtější způsob škálování, na který aplikace nemusí být nijak zvlášť připravená. V zásadě jde o navyšování výkonu serveru. Tento model má tu nevýhodu, že často nejde provádět za běhu, jeho možnosti nejsou neomezené a je také možné, že některé aplikace již nedokáží takový výkon v rámci jednoho serveru utilizovat a bottleneck je poté někde „uvnitř“ aplikace.

Scale-out je škálování formou paralelizace výpočetních jednotek – přidávání serverů, virtuálních serverů, kontejnerů za load balancerem. Na tento způsob škálování musí být aplikace připravena, výhodou oproti tomu je větší rozsah možností škálování.

Scaling killer 1 – relační databáze

Nejtypičtějším zabijákem škálování jsou relační databáze (MySQL, PostgreSQL, …), což jsou produkty, které vznikly před více než 20 lety v době, kdy pojem škálování v tomto pojetí prakticky neexistoval. Podpora pro clusterování byla různě dolepována až následně, popř. řešena jinými produkty třetích stran. Nejdříve je tedy potřeba se zamyslet, zda vůbec relační databázi ve vaší aplikaci potřebujete používat.

Například e-shopy s objednávkami, fakturami, uživateli apod., vyžadující ukládání dat do něčeho, co splňuje vlastnosti ACID, se bez relační databáze neobejdou. Zamyslete se nad tím, zda není možné v případě vašeho use case použít některou z noSQL databází, které byly většinou už od začátku koncipovány jako clusterovatelné, tedy škálovatelné.

Stále se ještě setkávám s tím, že někdo do relační databáze ukládá logy, sessions a další, což jsou všechno věci, na které existují specializované nástroje (pro sessions například in-memory noSQL databáze redis, logy např. syslog apod.). Naprosto nejhorší z pohledu škálování a relačních databází jsou zápisové operace, kde je reálná možnost škálování pouze vertikálně.

U selectů je ještě možné provoz rozdělit. Například Amazon RDS umožňuje přidávat read-only replicy, Zerops bude podporovat Galera cluster jako službu a bude zajišťovat výrazně větší pohodlí z pohledu škálování. Nicméně princip nemožnosti škálovat zápisové operace horizontálně platí v obou případech. Měli byste se tak vyhnout například využívání relační databáze k ukládání různých statistik, číselných řad a dalších (přesně k tomuto účelu se hodí více noSQL databáze – mongo, ElasticSearch apod.).

Relační databázi z pohledu horizontálního škálování je třeba brát jako nutné zlo a operace, zejména zápisové, je potřeba maximálně omezit z pohledu náročnosti a intenzity.

Scaling killer 2 – sdílený filesystém

Moderní aplikace se bez sdíleného filesystému již obejdou, drtivá většina aplikací však stále ne. Aplikace předpokládá, že má v adresářové struktuře uloženy kromě aplikace i data – tedy obrázky, logy atd. Špatně napsané aplikace ukládají do adresářové struktury různé cache. Filesystém je další desítky let starou záležitostí, která již měla dávno zhynout.

Pokud se nebavíme o aplikaci globálního rozsahu a nepracuje se s filesystémem nekoncepčně, nejde zas o takový problém, protože se na limity pravděpodobně nemusí nikdy narazit. Pokud se ale s FS pracuje nekoncepčně, hrozí zásadní problém, který žádné škálování ničeho většinou nevyřeší, navíc jde často o problémy, které o sobě nedají vědět dříve, než se reálně projeví.

Typicky jde o :

• špatnou adresářovou strukturu – ukládání statisíců (nebo mnohem více) objektů (souborů, adresářů) v jednom adresáři. Otevření takového adresáře pak mnohdy trvá spoustu minut.
• velké množství operací s filesystémem – zbytečné operace při každém přístupu uživatele nad mnoha soubory a generování lstat operací (typicky jsou to funkce v PHPku na ověření existence obrázku při každém přístupu apod. nebo absence souborové cache, kdy aplikace při každém přístupu generuje přístup na filesystém)
• ukládání cache do adresářové struktury – pokud ukládání do adresářové struktury, tak určitě ne do sdíleného filesystému mezi více servery, ale do ramdisku na lokálním serveru. Na sdíleném filesystému krok přetížení hrozí čekáním na soubor cache vlivem zámku souboru, který zrovna vytvořil jiný server, který s cache pracuje.

Jak si poradit bez sdíleného filesystému? Je nutné dodržovat základní filosofii rozdělení aplikace a dat. Aplikace by měla být provozuschopná i v read-only režimu (poté může běžet klidně v ramce) a neměla by vytvářet žádné lokální soubory (případný temp adresář pro dočasná nedůležitá data se řeší jako jeden zapisovatelný adresář umístění také na ramdisku). S daty se pracuje tak, že se použijí nástroje, které jsou k tomu určené – například syslog pro vzdálené logování, object storage pro práci s obrázky a dalšími uživatelskými daty, no a samozřejmě databáze.

Výše uvedení zabijáci škálování jsou nejčastější příčinou zhoršených možností škálování infrastruktury, se kterými se 11 let setkáváme u velkých internetových projektů.