Škálování Laravelu v praxi: od malého projektu po tisíce uživatelů

Laravel patří už několik let mezi nejpoužívanější PHP frameworky. Vývojáře láká jednoduchostí, čistou architekturou a stabilním ekosystémem, který pokrývá většinu potřeb moderní webové aplikace. Díky silné komunitě navíc neustále vznikají balíčky a nástroje, které zrychlují práci a přidávají nové funkce.

Jenže v roce 2025 už nestačí aplikaci „nějak rozběhnout“. Uživatelé očekávají rychlou odezvu, vysokou dostupnost a bezchybnou bezpečnost. Každý výpadek nebo pomalý request znamená ztrátu zákazníků – a pokud chybí promyšlený vývoj webových aplikací na míru, dříve nebo později se škálování stane bolestivým a drahým problémem.

Za poslední roky jsem viděl projekty, které zvládly vyrůst z pár stovek uživatelů na desítky tisíc. Ale i takové, které se pod vlastní vahou sesypaly a nakonec se celé přepisovaly od nuly – protože opravit chaotický základ bylo dražší než začít znovu. V tomhle článku proto najdete postupy, jak stavět Laravel aplikace tak, aby dokázaly růst spolu s byznysem a nezměnily se za pár let v neudržitelnou brzdu.

Architektura jako základ

Jedna z nejčastějších chyb menších projektů je začít bez plánu. Pár modelů, kontrolery, Blade šablony – a první verze běží. Jenže jakmile se začne nabalovat byznysová logika, kód se rychle změní v nepřehledný monolit. Každá změna pak stojí dvojnásobek času a riziko chyb roste s každým novým commitem.

Pokud má aplikace vydržet roky, je potřeba od začátku myslet na modulární návrh. Laravel k tomu má ideální předpoklady. Zároveň stojí za to vědět, jak udržet Laravel aplikaci čistou pomocí PHPStan, Rector a Pint.

Jak na modulární architekturu v Laravelu

• Rozdělení do doménových celků: Místo jedné obří složky App rozděl aplikaci podle domén: Users, Orders, Billing, Blog. Každá oblast má vlastní logiku, testy i kontrakty. Díky tomu můžeš vyvíjet i škálovat jednotlivé části nezávisle.
• Používej balíčky pro strukturu: Pokud nechceš modulární strukturu řešit sám, skvělým startem je nWidart/laravel-modules. Přidá jasně oddělené moduly se svou konfigurací, routami i pohledy.
• Kontrakty a adaptéry místo přímých závislostí: Služby třetích stran (platební brána, mailing, storage) nevolej napřímo. Definuj si rozhraní, například PaymentGatewayInterface, a k němu adaptér. Pokud se rozhodneš přejít na jiného poskytovatele, jen vyměníš adaptér, aniž bys musel přepisovat aplikaci.
• Services a actions místo „tlustých“ controllerů: Controllery mají být co nejtenčí. Složitější logiku rozděl do menších tříd: CreateOrderAction, InvoiceService apod. Takový kód se lépe testuje, čte i udržuje.
• Monolit místo mikroservisy: V 90 % případů se vyplatí dobře navržený monolit. Je levnější, rychlejší na vývoj a jednodušší na správu. Mikroservisy mají smysl až u opravdu velkých projektů, kde týmy potřebují izolovat části systému a škálovat je nezávisle. Více se tomu věnuju v článku Laravel architektura: proč většina projektů nepotřebuje microservices.

Architektura je první krok, kde se rozhoduje, jestli aplikace zvládne růst, nebo se časem stane noční můrou. Laravel ti dává do ruky flexibilní základ, ale záleží na tom, jak si ho nastavíš.

Správně navržená databáze

Databáze je místo, kde většina Laravel aplikací narazí na limity. Opravit špatně navržený model po roce vývoje bývá několikanásobně dražší než udělat to dobře hned od začátku. Pokud chcete aplikaci, která vydrží růst, musíte nad strukturou tabulek a dat přemýšlet od prvního dne.

• Normalizace jako základ: Každá tabulka má mít jasný účel a data se nesmí duplikovat. Do objednávek nepatří celá adresa zákazníka, ale jen user_id.
• Denormalizace jako vědomá volba: U větších databází mohou JOINy zpomalovat. V reportech nebo historii objednávek se vyplatí uložit kopii jména a adresy přímo k objednávce. Výkon roste, ale dělá se to jen vědomě a cíleně.
• Indexy rozhodují o rychlosti: Správný složený index (např. (user_id, created_at)) dokáže zrychlit dotaz z vteřin na milisekundy. Vždy používejte EXPLAIN, abyste viděli, jak dotaz databáze provádí.
• Pozor na N+1 dotazy v Eloquentu: Elegantní ORM rychle vyrobí stovky dotazů. Řešením je eager loading (with, load, withCount). Už od začátku zapněte Laravel Debugbar, abyste měli přehled.
• Repliky a asynchronní operace: Rozdělte databázi na primární (zápisy) a repliky (čtení). Laravel to podporuje přímo v config/database.php. Těžké exporty a reporty posílejte do front (Queues), nikdy nechte uživatele čekat.

Výkon a optimalizace

Výkon aplikace není něco, co byste měli řešit až po spuštění. Měl by být součástí vývoje už od prvního dne. Vyhnete se tak drahému ladění v produkci i zklamaným uživatelům. Držte se tří jednoduchých pravidel: co jde, uložte do cache; co nelze cachovat, zpracujte co nejrychleji; a co je opravdu náročné, přesuňte do fronty mimo request.

• Cache jako první linie: Redis obsluhuje session, fronty, rate limiting i fragmenty šablon. Reverzní proxy jako Nginx nebo Varnish navíc odbaví statický obsah, aniž by zatěžoval PHP a databázi.
• Optimalizace databáze: N+1 dotazy hlídám debugbarem, pomáhá i batch insert/update místo stovek malých dotazů. Velké reporty posílám do jobů, nikdy do requestu.
• PHP runtime: OpCache je povinnost. composer dump-autoload -o zrychlí autoload. U I/O heavy projektů testuju Laravel Octane s RoadRunnerem nebo Swoole – ale až po měření, nikdy preventivně.
• Monitoring výkonu: Laravel Telescope ukáže dotazy, cache hity i běh jobů. Pro detailní profilování se hodí Blackfire nebo New Relic. Bez metrik jen tipujete.

Server a provoz

Na začátku běží většina projektů na jednom serveru. PHP-FPM, nginx, databáze i Redis jsou na jednom stroji. Pro MVP nebo menší aplikaci je to ideální – levné, jednoduché, rychle nasazené. Typicky jde o VPS s 2 – 4 vCPU, 4 – 8 GB RAM a SSD diskem kolem 100 GB. Do stovek requestů za sekundu taková konfigurace stačí.

Jenže postupně přichází limity, databáze začne být zahlcená, Redis maže klíče, CPU je trvale vytížené přes 70 %. V tu chvíli je potřeba udělat první krok.

Krok 1: oddělit Redis a databázi

Redis nepotřebuje velký výkon, takže mu stačí menší stroj (2 vCPU, 2 – 4 GB RAM). Databáze naopak potřebuje více prostředků, 4 – 8 vCPU, 8 – 16 GB RAM, ideálně NVMe disk. Tím odlehčíte aplikačnímu serveru a snížíte latenci. V praxi to znamená, že původní „všechno v jednom“ server dál běží jen jako webserver a Redis s databází přesouváte na nové instance.

Krok 2: load balancer a více webserverů

Jakmile aplikace obsluhuje tisíce uživatelů, už jeden webserver nestačí. Přidává se load balancer – HAProxy nebo nginx – který rozděluje požadavky mezi více webserverů. Zároveň tu končí SSL, takže webservery už řeší jen čistý provoz. Původní server se tak stává první webovou instancí, přidává se druhá se stejnou konfigurací (2 – 4 vCPU, 4 – 8 GB RAM). Statická data je vhodné poslat na CDN a session i cache držet v Redis, aby byly sdílené mezi všemi instancemi.

Krok 3: dedikované worker servery

Aplikace začíná čím dál více využívat fronty – exporty, notifikace, generování PDF, zpracování obrázků. Laravel Horizon sice umí běžet na jednom stroji, ale pro větší provoz je lepší dedikovat servery jen pro joby. Mají typicky 4 – 8 vCPU a dostatek RAM podle náročnosti úloh. Původní webservery se tak uvolní od background procesů a zůstávají čistě pro obsluhu requestů.

Krok 4: databázové repliky

Většina aplikací má výrazně více čtecích dotazů než zápisů. V této fázi se původní databáze rozdělí na primární (pro zápisy) a repliky (pro čtení). Laravel to podporuje přímo v config/database.php. Primár má nejvyšší výkon (8 – 16 vCPU, 16 – 32 GB RAM), repliky mohou být menší. Výsledkem je odlehčení primáru klidně o 70 – 90 % dotazů.

Krok 5: vyčištění původního serveru

Původní první stroj, kde kdysi běželo všechno, má teď jediný úkol – databázi. Zbývající služby (nginx, PHP-FPM, Redis, Supervisor) se odinstalují, aby nic nerušilo výkon databáze. Ta tak má vyhrazený stroj, který se dá dále vertikálně posilovat, dokud nenarazíte na limity.

Krok 6: runtime optimalizace

Až v této fázi má smysl řešit runtime. Zapnutý OpCache je povinnost, composer dump-autoload -o pomůže s rychlejším autoloadem. Pokud aplikace běží na I/O heavy úlohách, je možné nasadit Laravel Octane s RoadRunnerem nebo Swoole – ale vždy až po měření s nástroji jako Blackfire nebo New Relic.

Nasazování ve více-serverovém prostředí

Když běží aplikace na jednom serveru, nasazení je jednoduché. Stačí spustit build a restartovat služby na jediném stroji. Jenže ve chvíli, kdy máte oddělené webservery, worker servery a databázi, proces se komplikuje. Najednou musíte nasazovat na více instancí a dávat pozor, abyste nic nerozbili.

Osvědčilo se mi, že čím dříve začnete s automatizací nasazování, tím hladší bude další růst. Pro menší projekty většinou stačí Git-based skript, ale u více serverů je potřeba počítat s několika kroky navíc:

• Paralelní nasazení: Aplikaci je nutné dostat na všechny web a worker servery současně. U jednoho stroje udělá deploy všechno, u více instancí je potřeba spouštět skript nad všemi servery.
• Kontrola služeb: Před restartem se hodí zkontrolovat jejich stav. Například php artisan horizon:status vám řekne, jestli Horizon běží, a restartovat ho tak můžete bezpečně. Podobně lze ověřit stav PHP-FPM.
• Zero-downtime nasazení: Místo toho, abyste uživatelům během nasazení shodili web, použijte blue-green deployment nebo atomic symlink release. To znamená, že připravíte novou verzi bokem a pak jen přepnete symlink uživatelé si ničeho nevšimnou.
• Jednotný deploy nástroj: Jakmile přidáte více serverů, vyplatí se mít jeden entrypoint, který spustí nasazení na všech strojích. Může to být vlastní Bash/PHP skript nebo specializovaný nástroj (Envoyer, Deployer, Ansible).

Kontejnery a clustery: kdy mají smysl

Kontejnery (Docker, Kubernetes) dnes patří mezi nejčastější řešení škálování aplikací. Umožňují rychlé nasazování, snadnou replikaci serverů a pokročilé věci jako autoscaling. Pro velké projekty s desítkami instancí a týmy, které potřebují jednotné prostředí, je to jasná volba.

Jenže realita menších a středních projektů je jiná. Pokud stavíte aplikaci na jednom nebo několika málo serverech, nasazení do clusteru často znamená víc složitosti než užitku. Potřebujete orchestrace, monitoring, CI/CD pipeline přizpůsobenou kontejnerům – a to všechno stojí čas i peníze.

Pro menší projekty se proto vyplatí držet jednoduchosti:

• VPS + snapshots: Clonování strojů a základní automatizace často vyřeší stejný problém rychleji a levněji než Kubernetes.
• Docker jen lokálně: Docker dává smysl pro sjednocení dev prostředí, ale do produkce nemusí být nutně potřeba.
• Cluster až při růstu: Jakmile máte více týmů, stovky tisíc uživatelů nebo nároky na autoscaling, pak je správný čas přemýšlet o Kubernetes nebo jiném orchestrátoru.

Monitoring a dohled

Škálování bez monitoringu neexistuje. Pokud nevidíte, co se děje s aplikací pod zátěží, kde se hromadí fronty nebo které dotazy brzdí databázi, jen tipujete – a to je cesta k výpadkům.

Na co se zaměřit:

• Výkon aplikace: Latence, počet requestů, chybovost (error rate). → nástroje: Laravel Telescope pro vývoj, Blackfire nebo New Relic pro profilování.
• Fronty: Délka a rychlost zpracování jobů. → sledujte v Laravel Horizon a doplňte monitoring přes Prometheus/Grafana.
• Databáze: Slow query log, počet připojení, replikace. → Datadog nebo Elastic APM vám ukážou bottlenecky v reálném čase.
• Server: CPU, RAM, disk, síťové limity. → Prometheus + Grafana jsou open-source standard, pro rychlejší start je tu Datadog.
• Cron a joby: Aby bylo jasné, že běží a nezasekly se. → Healthchecks.io je jednoduchý a spolehlivý způsob, jak mít přehled.

Logy a alerty: Bez centralizace logů nemáte kontrolu. ELK stack nebo Logtail umožní sledovat vše na jednom místě. Nastavte alerty na kritické stavy (např. latence > 500 ms, RAM > 90 %, fronta > 100 jobů

Bezpečnost a správa dat

S růstem aplikace roste i její atraktivita pro útočníky. Každý incident stojí peníze, reputaci i výkon, proto je lepší řešit bezpečnost od začátku. Laravel má mnoho věcí zabudovaných, ale záleží na správném nastavení a disciplíně.

Klíčové oblasti

• Validace a sanitizace vstupů: Všechny requesty přes Form Requests. Pro HTML obsah knihovna mewebstudio/purifier, aby se předešlo XSS.
• Rate limiting: Middleware throttle na login, reset hesla i veřejné API. Omezíte brute-force útoky i přetížení serveru.
• Dvoufaktorová autentizace (2FA): Administrace bez 2FA je dnes slabina. Laravel Fortify nebo google2fa-laravel integrují MFA snadno.
• Správa tajných klíčů: API klíče, hesla a přístupy patří do Vault, AWS KMS nebo GCP Secret Manager – nikdy do .env na serveru.
• Audit logy: Pomocí spatie/laravel-activitylog lze sledovat, kdo a kdy co změnil. Důležité pro GDPR i důvěru.
• Maskování citlivých dat v logách: Celé heslo nebo číslo karty se nikdy nesmí objevit v logu. Laravel umožňuje nastavit hidden attributes i custom maskování.
• Ochrana proti DDoS: Cloudflare, Fastly nebo AWS CloudFront jako CDN a WAF. Zachytí útok dřív, než dojde na server.

Závěr

Růst aplikace stojí na pevných základech – čistém kódu, promyšlené databázi, škálovatelné infrastruktuře a dobrém monitoringu. Laravel nabízí všechny potřebné nástroje, jen je potřeba s nimi pracovat správně.

Pokud hledáte partnera, který vám pomůže navrhnout a postavit aplikaci připravenou na růst, kontaktujte mě.