Malá Serverless služba v AWS

Když nám celá platforma běží v AWS, tak pouštět věci CRONem je trochu zastaralé, těžkopádné a hlavně drahé. V tomto článku ukážeme, jak jsme vyřešili spouštění zpožděných plánovaných úloh ve Webnodu po migraci do AWS.

Co se snažíme vyřešit?

1)

Chceme spouštět zpožděné operace na základě nějaké akce uživatele a chceme, aby používaly nativní (levnější) službu AWS.
-> Jasné řešení : Amazon EventBridge Scheduler

2)

Event Bridge musí "něco" provolat a toto "něco" musí být spuštěno kdykoli, kdy plánovač chce a nesmí být zbytečně drahé, když to není potřeba.
-> Nejlepší řešení, které nás napadlo: AWS Lambda

3)

Nyní však potřebujeme nějaký způsob nasazení AWS Lambda funkcí, který bude splňovat:

• Běh v jazyce, který známe (PHP)
• Bude automaticky nasazovatelný
• Snadné přepínání mezi architekturou x86 a ARM (můžeme si tak vybrat řešení s nejlepším poměrem cena-výkon)
• Může běžet v našich více prostředích (testing/staging/production)
• Lze snadno upgradovat.
• Celé prostředí by mělo být konfigurovatelné

Lambda: Bref přichází na pomoc

Bref a jeho integrace s open-source verzí Serverless řeší všechny problémy, které nás napadly. Jediné, co musíme udělat, je připravit konfiguraci serverless.yaml a PHP "skript", který bude zpracovávat požadované funkce.

Tento přístup nám umožňuje vyvíjet Lambda funkci jako jakoukoli jinou aplikaci, kterou známe. Navíc máme výhodu, že na rozdíl od jiných programovacích jazyků v jazyce PHP již request (nebo v tomto případě event) běží jako samostatný proces.

Náš Use-case

Potřebujeme, aby jedna z našich aplikací kontrolovala stav objednávky zákazníka hodinu po jejím vytvoření a upozornila ho, pokud objednávka nebyla dokončena. Podobným případem použití, který možná znáte, je e-shop, který vám připomene, že máte zboží v košíku, a vyzve vás k dokončení objednávky.

Již máme aplikaci, která sleduje vytvoření objednávky, API endpoint pro kontrolu stavu objednávky a provádění následných akcí. Potřebujeme pouze zavolat toto API rozhraní hodinu po vytvoření objednávky.

V našem předchozím řešení (on premises) bychom toho dosáhli vytvořením nové CRON úlohy, která by pravidelně kontrolovala nezpracované události a zapracovala je po uplynutí daného času. Tento přístup vyžadoval, aby proces CRON běžel nepřetržitě, i kdyby nebyly naplánovány žádné události.

Nyní můžeme jednoduše vytvořit událost, která spustí Lambda funkci. Tato funkce slouží jako lehký prostředník mezi zpožděným plánem a naším rozhraním API.

Jak je implementována naše Lambda funkce

Naše implementace je vytvořena pomocí jediného repozitáře, který obsahuje Pipeline, pomocí niž je schopný se sám nasadit na AWS. Toto úložiště si lze představit v segmentech:

• Serverless konfigurace;
• Index.php
• "Task", který má být proveden.
• Gitlab deployment

Serverless Konfigurace

V tomto kroku nastavíme klíčové aspekty Lambda funkce, jako je její název, přístupová práva, proměnné prostředí, PHP runtime a architektura procesoru.

Index.php

V našem případě se jedná o malý soubor, který inicializuje úlohu s jejími závislostmi konstruktoru pomocí našeho nastavení Dependency Injection (DI).

Task

Zde můžeme pracovat, jako by tato úloha byla součástí větší aplikace. Můžeme využívat závislosti, používat libovolné composer balíčky a v podstatě pracovat, jako bychom byli v jakékoli jiné aplikaci, aniž bychom museli rozumět tomu, jak samotný kontext Lambdy.

Gitlab Deployment

K nasazení používáme gitlab a gitlab-ci.yml. V tomto souboru máme konfiguraci, která umožňuje:

• Z "Merge requestu" nasazení pro testování
• Z master/main nasazení na testing/staging/production prostředí

Monitoring

V současné době máme dvě úrovně monitorování funkce Lambda.

Logy z aplikace

Díky integraci stávajících balíčků do naší funkce Lambda máme přístup k podrobným Logům a trackování. Díky tomu můžeme sledovat Logy od okamžiku vytvoření v aplikaci Webnode Checkout až po konečnou akci zpracovávanou rozhraním Webnode API, která je spuštěna touto Lambda funkcí.

Cloudwatch

V aplikaci AWS CloudWatch můžeme sledovat a kontrolovat každý běh Lambda funkce, sledovat její účtovaný čas a konfigurovat alarmy pro detekci a řešení případných problémů.

Závěr

Celkově to pro nás představuje nový přístup k řešení plánovaných nebo odložených událostí. Přestáváme se spoléhat na systém CRON a místo toho využíváme specifická cloudová řešení, abychom snížili náklady a zároveň optimalizovali rychlost a spolehlivost.

Ti z nás, kteří na tomto projektu pracovali, doufají, že tento trend zavádění nových a zajímavých technologií bude pokračovat i nadále a že se s vámi v budoucnu podělíme o další příběhy.