Systémy pro zařazování úloh do front: Kompletní přehled
Potřebujete systém pro organizaci úloh do front? Hledáte možná něco lepšího? Níže naleznete veškeré podstatné informace!
Systémy front představují jeden z nejlépe střežených pokladů backendového vývoje.
Aniž bych se chtěl uchýlit k chvalozpěvům na systémy front, je zřejmé, že juniorní backendový vývojář se posune na úroveň středně pokročilého ve chvíli, kdy se naučí, jak integrovat fronty do systému. Fronty mají pozitivní dopad na zákaznickou zkušenost (jak si ukážeme dále), snižují komplexnost a zvyšují spolehlivost systému.
Samozřejmě, u jednoduchých webových aplikací s minimálním provozem nebo u prezentačních webů mohou být fronty zcela zbytečné, případně nemožné je nasadit, zejména pokud využíváte sdílený hosting. Nicméně netriviální aplikace ze systémů front výrazně profitují a velké aplikace se bez jejich využití v podstatě neobejdou.
Než začneme, jedno důležité upozornění: pokud již máte se systémy front zkušenosti a hledáte spíše srovnání různých možností, úvodní pasáže vám budou připadat zbytečné. Klidně tedy přeskočte dále. Úvodní sekce jsou určeny těm, kteří mají o systémech řazení úloh jen mlhavou představu, nebo se s jejich názvem setkali pouze okrajově.
Co to vlastně je systém řazení do front?
Začněme objasněním samotného pojmu fronta.
Fronta je v informatice datová struktura, která napodobuje reálné fronty, s nimiž se setkáváme v běžném životě. Například, když stojíte u pokladny, musíte se zařadit na konec fronty, přičemž obsloužen bude nejdříve ten, kdo stojí na začátku fronty. Tomuto principu se říká „kdo dřív přijde, ten dřív mele“. V informatice se dá napsat program, který ukládá své úkoly do fronty a zpracovává je jeden po druhém dle tohoto principu.
Je důležité si uvědomit, že samotná fronta neprovádí žádné zpracování. Je to pouze dočasný prostor, kde úkoly čekají, dokud si je někdo nepřevezme. Pokud to všechno zní příliš abstraktně, nezoufejte. Jedná se o abstraktní koncept, ale v následující sekci si ukážeme konkrétní příklady.
Proč jsou systémy řazení do front nezbytné?
Abychom to zbytečně nerozváděli, hlavní důvody pro nasazení systémů řazení do front jsou zpracování na pozadí, paralelní spouštění a obnova po selhání. Projděme si je na konkrétních příkladech:
Zpracování na pozadí
Představte si, že provozujete e-shop a máte marketingovou kampaň, kde hraje čas zásadní roli. Vaše aplikace odesílá potvrzovací e-mail těsně před dokončením platby a následným zobrazením děkovné stránky. Pokud dojde k výpadku e-mailového serveru, na který se připojujete, webová stránka se jednoduše nezobrazí, což poškodí uživatelský komfort.
Představte si ten nápor stížností, které byste museli řešit! V takovém případě je mnohem lepší přesunout odeslání e-mailu do fronty úloh a zákazníkovi zobrazit potvrzení o úspěšném nákupu.
Paralelní zpracování
Řada vývojářů, zejména ti, kteří se zabývají méně komplexními aplikacemi s nižším provozem, má ve zvyku používat pro zpracování na pozadí úlohy cron. To funguje bez problémů do té doby, dokud se objem vstupních dat nezvýší do takové míry, že to úloha cron není schopna zvládnout. Předpokládejme, že máte úlohu cron, která generuje analytické reporty a posílá je uživatelům e-mailem a váš systém zvládne zpracovat 100 reportů za minutu.
Jakmile se vaše aplikace rozroste a bude zpracovávat průměrně více než 100 požadavků za minutu, začne systém zaostávat a nikdy nebude schopen všechny úlohy dokončit.
V systému s frontami lze této situaci předejít. Nastaví se několik pracovních procesů, které si vybírají úlohy z fronty (každá obsahující 100 reportů) a pracují paralelně, čímž je úkol zpracován mnohem rychleji.
Obnova po selhání
Jako weboví vývojáři obecně nepředpokládáme selhání. Automaticky očekáváme, že naše servery a API, která používáme, budou vždy funkční. Realita je však jiná – výpadky sítě jsou poměrně časté a i kvalitní API se mohou ocitnout mimo provoz z důvodu problémů s infrastrukturou (než řeknete „to se mi nestane!“, vzpomeňte si na rozsáhlý výpadek Amazon S3). Když se vrátíme k příkladu s reporty, co se stane se 200 reporty, které se nepodařilo vygenerovat, pokud se při generování připojujeme k API pro platby a to je na 2 minuty nedostupné?
Je však pravda, že systémy front mají své nároky. Jejich zavedení je poměrně obtížné, protože se jedná o zcela novou oblast, a tím se zvyšuje složitost vaší aplikace i jejího nasazení. Úlohy ve frontě se navíc nedají vždy ovládat se 100% jistotou. Nicméně, jsou situace, kdy vytvoření aplikace bez front prostě není možné.
S tímto na paměti, se podíváme na některé z nejběžnějších řešení mezi současnými backendy/systémy front.
Redis
Redis je známý jako databáze typu klíč-hodnota, která primárně ukládá, aktualizuje a získává textová data bez znalosti jejich struktury. Dříve to možná platilo, ale dnes má Redis efektivní a velmi užitečné datové struktury, jako jsou seznamy, setříděné sady a dokonce i systém Pub-Sub, díky čemuž se stává velmi žádaným pro implementaci front.
Mezi výhody Redisu patří:
- Databáze je uložena kompletně v paměti, což zajišťuje rychlé čtení/zápis.
- Velmi efektivní: Snadno zvládá více než 100 000 čtení/zápisů za sekundu.
- Vysoce flexibilní schéma pro perzistenci dat. Můžete dosáhnout maximálního výkonu za cenu rizika ztráty dat při selhání, nebo zvolit plně konzervativní režim a obětovat výkon ve prospěch konzistence.
- Klastry jsou podporovány bez nutnosti dalších úprav.
Je třeba si uvědomit, že Redis nenabízí žádnou abstrakci pro zasílání zpráv/řazení do fronty/obnovu, takže je buď nutné použít existující knihovnu, nebo si vytvořit vlastní systém. Příkladem je, že Redis je výchozím backendem fronty pro Laravel PHP framework, kde byl implementován scheduler.
Naučit se Redis je poměrně jednoduché.
RabbitMQ
Mezi Redis a RabbitMQ existuje několik zásadních rozdílů, které je nutno si hned na začátku ujasnit.
RabbitMQ má mnohem více specializovanou, jasně definovanou roli a byl tak i navržen – je to systém pro zasílání zpráv. Jinými slovy, jeho silnou stránkou je fungovat jako prostředník mezi dvěma systémy, což není případ Redisu, který primárně funguje jako databáze. Z toho vyplývá, že RabbitMQ nabízí několik funkcí navíc, které u Redisu nenajdeme: směrování zpráv, opakování úloh, rozdělení zátěže atd.
Pokud se nad tím zamyslíme, fronty úloh lze také považovat za systém zasílání zpráv, kde scheduler, pracovní procesy a zadavatelé úloh jsou subjekty, které si mezi sebou předávají zprávy.
RabbitMQ nabízí následující výhody:
- Lepší abstrakce pro předávání zpráv, což snižuje množství práce na úrovni aplikace, pokud je zasílání zpráv to, co potřebujete.
- Odolnější vůči výpadkům a problémům s napájením (oproti Redisu, alespoň ve výchozím nastavení).
- Podpora klastrů a federací pro distribuovaná nasazení.
- Užitečné nástroje pro správu a monitorování vašeho nasazení.
- Podpora prakticky všech programovacích jazyků.
- Možnost nasazení pomocí nástroje dle vašeho výběru (Docker, Chef, Puppet atd.).
Kdy použít RabbitMQ? Řekl bych, že je to skvělá volba, pokud víte, že potřebujete použít asynchronní zasílání zpráv, ale nejste připraveni řešit obrovskou složitost některých dalších systémů řazení do front (viz níže).
ActiveMQ
Pokud se pohybujete v korporátní sféře (nebo vytváříte rozsáhlou aplikaci s vysokou mírou distribuce) a nechcete neustále znovu objevovat kolo (a při tom dělat chyby), měli byste se podívat na ActiveMQ.
V čem ActiveMQ vyniká:
- Je implementován v jazyce Java, což zajišťuje výbornou integraci s Java aplikacemi (dodržuje standard JMS).
- Podpora více protokolů: AMQP, MQTT, STOMP, OpenWire atd.
- Nabízí zabezpečení, směrování, vypršení platnosti zpráv, analýzu a další funkce ihned po instalaci.
- Integrovaná podpora oblíbených vzorů pro distribuované zasílání zpráv, což vám šetří čas i náklady na případné chyby.
To neznamená, že ActiveMQ je určen pouze pro Javu. Má klienty pro Python, C/C++, Node, .Net a další ekosystémy, takže by neměly být žádné obavy z problémů v budoucnu. Kromě toho je ActiveMQ postaven na otevřených standardech, takže vytvoření vlastních, odlehčených klientů by neměl být problém.
Mějte však na paměti, že ActiveMQ je pouze broker, neobsahuje backend pro ukládání zpráv. Pro ukládání zpráv bude stále nutné použít jeden z podporovaných backendů. Zmiňuji ho zde, protože není vázaný na konkrétní programovací jazyk (na rozdíl od populárních řešení jako Celery, Sidekiq atd.)
Amazon MQ
Amazon MQ si zde zaslouží krátkou, avšak důležitou zmínku. Pokud si myslíte, že ActiveMQ je pro vaše potřeby ideální, ale nechcete se zabývat budováním a údržbou infrastruktury, Amazon MQ nabízí spravovanou službu. Podporuje všechny protokoly, které podporuje i ActiveMQ, ve funkcích tedy není žádný rozdíl, protože ve skutečnosti používá ActiveMQ.
Výhodou je, že se jedná o spravovanou službu, takže se nemusíte o nic starat, stačí ji používat. To dává ještě větší smysl pro nasazení na AWS, protože můžete využít další služby a výhody přímo z vašeho prostředí (například rychlejší přenos dat).
Amazon SQS
Nemůžeme očekávat, že Amazon bude v takto důležité oblasti kritické infrastruktury nečinně přihlížet, že? 🙂
A tak zde máme Amazon SQS, což je plně hostovaná služba pro jednoduché fronty (doslova) od známého giganta AWS. Opět je nutné brát na vědomí jemné rozdíly, takže pamatujte, že SQS nepracuje s konceptem předávání zpráv. Podobně jako Redis je to jednoduchý backend pro přijímání a distribuci úloh ve frontách.
Kdy je tedy vhodné použít Amazon SQS? Zde je několik důvodů:
- Jste fanouškem AWS a nechcete se dotýkat jiných řešení (upřímně, takových lidí je hodně a myslím si, že na tom není nic špatného).
- Potřebujete hostované řešení, které zajistí nulovou míru selhání a nedojde ke ztrátě žádné z úloh.
- Nechcete vytvářet klastr a spravovat jej sami. Nebo ještě hůře, nechcete vytvářet monitorovací nástroje, když byste mohli tento čas využít na produktivní vývoj.
- Máte už nemalé investice do platformy AWS a setrvání v ní má pro vaše podnikání smysl.
- Chcete jednoduchý systém řazení do front bez zbytečností spojených s předáváním zpráv, protokoly a podobně.
Celkově vzato, Amazon SQS je spolehlivá volba pro každého, kdo chce začlenit fronty úloh do svého systému a nechce se starat o instalaci/monitorování.
Beanstalkd
Beanstalkd je na trhu už dlouho a jedná se o prověřený, rychlý a jednoduchý backend pro řazení úloh. Beanstalkd se od Redisu odlišuje několika zásadními vlastnostmi:
- Je to striktně systém řazení do front, nic víc. Posíláte do něj úlohy, které si později převezmou pracovní procesy. Pokud tedy vaše aplikace potřebuje jen minimum z funkcí pro předávání zpráv, měli byste se Beanstalkdu vyhnout.
- Nenabízí žádné pokročilé datové struktury, jako jsou sady, prioritní fronty atd.
- Beanstalkd funguje na principu FIFO (First In, First Out), tedy „kdo dřív přijde, ten dřív mele“. Neexistuje způsob, jak řadit úlohy podle priority.
- Nepodporuje shlukování (klastrování).
To vše znamená, že Beanstalkd je elegantní a rychlý systém front pro jednoduché projekty, které běží na jednom serveru. Pro mnohé je rychlejší a stabilnější než Redis. Pokud tedy máte s Redisem problémy, které nemůžete vyřešit a vaše potřeby jsou jednoduché, Beanstalkd stojí za vyzkoušení.
Závěrem
Pokud jste dočetli až sem (nebo jste se sem dostali rychlým přečtením 😉 ), je velká šance, že vás systémy řazení do front zajímají nebo je potřebujete. Pokud ano, seznam na této stránce vám dobře poslouží, pokud nehledáte systém front specifický pro jazyk/framework.
Rád bych vám řekl, že řazení do front je jednoduché a 100% spolehlivé, ale není tomu tak. Je to komplexní a protože vše probíhá na pozadí a velmi rychle, mohou chyby zůstat nepovšimnuty a stát se velice nákladnými. Přesto jsou fronty velmi důležité a zjistíte, že se jedná o mocný (možná i nejmocnější) nástroj ve vašem arzenálu. Hodně štěstí! 🙂