Pravděpodobně jste viděli architekturu, která vypadá takto:
Kolik paměti bychom měli přidělit funkci Lambda pro zpracování souborů? Jedním přístupem je vzít nějaká ukázková data a spustit je pomocí Lambda Power Tuning, ale co když zpracováváme soubory různých velikostí? Nejjednodušší způsob, jak z toho ven, je neustále zvětšovat paměť, dokud nebudete moci bezpečně zpracovávat všechna nahrávání, ale to něco stojí. Podívejme se, jak můžeme vybrat správné množství paměti pro každý z našich souborů!
Opravdu to stojí za to?
Je lákavé přidat funkce, jako je tato, během počátečního vývojového procesu, ale pojďme si spočítat, zda se nám skutečně vrátí naše časové investice.
Příklad 1 — upload s nízkou návštěvností
Při jedné žádosti za sekundu (RPS) vyřídíme zhruba dva a půl milionu žádostí za měsíc. Pokud ke zpracování většiny souborů potřebuje 256 MB RAM a 1024 MB RAM ke zpracování 10 % souborů, které jsou náhodou větší, naše náklady jsou následující:
- Všechna vyvolání na 1024 MB, všechna za 3 s: 98.67 $ / měsíc
- 90 % vyvolání při 1024 MB, 10 % při 256 MB, vše trvá 3 s: 23.29 $ / měsíc
Úspora sedmdesáti dolarů je příjemná, ale musíme vyhodnotit vývojářské náklady na implementaci této funkce a provozní náklady více lambd (např. pomocí složitějších řídicích panelů, které zobrazují více dat).
Příklad 2 — upload s vysokým provozem
Při stovce RPS jsou čísla zajímavější:
- Všechna vyvolání na 1024 MB, všechna za 3 s: 3,410.39 $ / měsíc
- 90 % vyvolání při 1024 MB, 10 % při 256 MB, vše trvá 3 s: 10,414.36 $ / měsíc
Co když velké soubory tvoří pouze 1 % nahraných souborů?
- Všechna vyvolání na 1024 MB, všechna za 3 s: 3,410.39 $ / měsíc
- 99 % vyvolání při 1024 MB, 1 % při 256 MB, vše trvá 3 s: 2,710.55 $ / měsíc
Budete muset provést vlastní výpočty, abyste se rozhodli, co dává smysl pro váš kontext. Podívejme se, jak můžeme vybrat správné množství paměti Lambda pro naši velikost vstupního souboru.
Funkce Lambda správné velikosti
Než budeme pokračovat: předpokládá se, že rozumíte velikosti (velikosti) dat, která vaše funkce zpracuje, a provedli jste Lambda Power Tuning, abyste našli nejhospodárnější nastavení paměti pro každou kategorii. Tento proces vám může poskytnout tabulku, která vypadá takto:
| Minimální velikost souboru | Maximální velikost souboru | Ideální lambda RAM |
|---|---|---|
| 100 KB | 256 MB | |
| 100 KB | 25 MB | 1024 MB |
| 25 MB | Žádný | 4096 MB |
Původní metodou spouštění funkce Lambda nebo jiné události při nahrání souboru do bucketu S3 je použití upozornění na objekty, ale ty nám neumožňují provádět žádné pokročilé filtrování. Na konci roku 2021 vydala AWS integraci s EventBridge. Díky tomu můžeme vytvořit pravidlo události, které směruje událost vytvořenou v objektu na správné místo. Událost vypadá takto:
"version": "0", "id": "2ffe83a5-48ff-fccd-2dda-a57a03c22f4b", "detail-type": "Object Created", "source": "aws.s3", "account": "123456789012", "time": "2023-06-18T19:17:31Z", "region": "eu-west-1", "resources": [ "arn:aws:s3. right-size-lambdas-files" ], "detail": "version": "0", "bucket": "name": "right-size-lambdas-files" >, "object": "key": "large", "size": 31457280, "etag": "f6877c498a97505d3a45f485cefc2a40-2", "sequencer": "00648F584721ECA86B" >, "request-id": "2JR2MJWXPFG2JME4", "requester": "123456789012", "source-ip-address": "123.123.123.123", "reason": "CompleteMultipartUpload" > > Uvidíte, že událost obsahuje pole velikosti v bajtech. Možná jste již dříve vytvořili pravidlo EventBridge, které vypadá takto:
"detail": "bucket": "name": [ "right-size-lambdas-files" ] > >, "detail-type": [ "Object Created" ], "source": [ "aws.s3" ] > Nemůžeme se ale shodovat s přesným počtem bajtů – pokaždé to bude jiné. Naštěstí můžeme použít číselný operátor k přiřazení rozsahu. Podívejme se, jak to vypadá u prvního záznamu v naší tabulce:
"detail": "object": "size": [ "numeric": [ ">", , "< p">, 100000 ] > ] > > > Výše uvedené pravidlo události zachycuje nejmenší soubory se dvěma podmínkami. Pravidlo události Lambda střední velikosti vypadá téměř identicky, jen s různými hodnotami velikosti a pravidlo události velkých souborů má pouze počáteční rozsah:
"detail": "object": "size": [ "numeric": [ ">", 25000000 ] > ] > > > Zachytí všechny soubory větší než 25 MB.
Můžeme aktualizovat náš diagram architektury, abychom naznačili, že vybíráme správnou Lambdu pro tuto práci:
A je to! Malé soubory jdou do Lambdy s nejmenší pamětí a největší soubory dostanou celé čtyři gigabajty RAM.
Plně funkční příklad
Plně funkční příklad této techniky najdete na GitHubu. Používá přesně stejnou kódovou základnu k vytvoření tří funkcí Lambda různých velikostí. Pokusit se!
Proč investovat do čističky vzduchu?
Při vysokých objemech může mít smysl směrovat soubory do funkce Lambda odpovídající velikosti. To však nenahrazuje Lambda Power Tuning – stále chceme najít nákladově nejefektivnější nastavení paměti pro každou skupinu souborů, které chceme zpracovat.
Pomocí EventBridge můžeme filtrovat podle rozsahů číselných hodnot. To nám umožňuje odeslat správnou událost vytvořenou objektem S3 na příslušnou lambdu beze změn v našem kódu Lambda!
Viz také
- Lambda Power Tuning
- Plně funkční ukázkový projekt
Učíte se AWS’ CDK v TypeScriptu? Podívejte se na můj kurz na Udemy.
