Doporučené postupy pro opakované použití kontejneru AWS Lambda

Optimalizace teplých startů při připojení AWS Lambda k jiným službám

AWS Lambda poskytuje vysokou škálovatelnost díky bezserveru a bez státní příslušnosti, což umožňuje okamžité vytvoření mnoha kopií funkce lambda (jak je zde popsáno). Při psaní kódu aplikace však budete pravděpodobně chtít přístup k některým stavovým datům. To znamená připojení k datovému úložišti, jako je například instance RDS nebo S3. Připojení k jiným službám od společnosti AWS Lambda však přidá vášmu funkčnímu kódu čas. Mohou také existovat vedlejší účinky z velké škálovatelnosti, jako je dosažení maximálního počtu povolených připojení k instanci RDS. Jednou z možností, jak tomu čelit, je použití opakovaného použití kontejneru v AWS Lambda k přetrvávání připojení a zkrácení doby běhu lambda.

Existuje několik užitečných diagramů, které vysvětlují životní cyklus požadavku lambda.

Během studeného startu, kdy je vaše funkce vyvolána poprvé nebo po období nečinnosti, dochází k následujícím:

  • Kód a závislosti jsou staženy.
  • Je spuštěn nový kontejner.
  • Běhové prostředí je zavázáno.

Poslední akcí je spuštění kódu, ke kterému dochází při každém vyvolání funkce lambda. Pokud je kontejner znovu použit pro následné vyvolání funkce lambda, můžeme přeskočit dopředu na spuštění kódu. Toto se nazývá teplý start a toto je krok, který můžeme optimalizovat při připojení k jiným službám definováním připojení mimo rozsah metody handler.

Připojení k dalším službám AWS od Lambda

Příklad: Připojte se k instanci RDS, odtud pocházejí ikony AWS

Máme základní a běžný příklad, kterým můžeme projít - chceme se připojit ke zdroji kontejneru a načíst data obohacení. V tomto příkladu přijde užitečná zátěž JSON s ID a Lambda Function se připojí k instanci RDS spuštěné PostgreSQL a najde odpovídající název ID, abychom mohli vrátit obohacené užitečné zatížení. Protože se funkce lambda připojuje k RDS, který žije ve VPC, musí nyní lambda fungovat také v soukromé podsíti. To přidává pár kroků ke studenému startu - musí být připojeno elastické síťové rozhraní VPC (ENI) (jak je uvedeno v blogu Jeremyho Dalyho, to přidá čas na vaše studené starty).

Poznámka: Vyhnuli bychom se použití VPC, pokud bychom místo RDS používali úložiště klíčů a hodnot s DynamoDB.

Projdu dvě řešení tohoto úkolu, první je moje „naivní“ řešení, zatímco druhé řešení se optimalizuje pro časy zahajovacího startu tím, že znovu použije připojení pro následné vyvolání. Poté porovnáme výkon každého řešení.

Možnost 1 - Připojte se k RDS v rámci obsluhy

Tento příklad kódu ukazuje, jak bych se k této úloze mohl naivně přiblížit - připojení k databázi je v rámci metody handler. Před vrácením užitečného zatížení je k dispozici jednoduchý výběrový dotaz, který načte jméno ID, které nyní obsahuje jméno.

Podívejme se, jak se tato možnost provádí během malého testu s výbojem 2000 vyvolání se souběžností 20. Minimální doba trvání je 18 ms s průměrem 51 ms a maximálně přes 1 sekundu (doba studeného startu).

Lambda Trvání

Níže uvedený graf ukazuje, že existuje maximálně osm připojení k databázi.

Počet připojení k databázi RDS v 5minutovém okně.

Možnost 2 - Použijte globální připojení

Druhou možností je definovat připojení jako globální mimo metodu handler. Poté uvnitř obslužné rutiny přidáme kontrolu, abychom zjistili, zda připojení existuje, a připojíme se pouze v případě, že ne. To znamená, že připojení je provedeno pouze jednou na kontejner. Nastavení spojení tímto způsobem s podmínkou na místě znamená, že není nutné navazovat spojení, pokud to nevyžaduje logika kódu.

Již neuzavíráme připojení k databázi, takže spojení zůstává pro následné vyvolání funkce. Opětovné použití připojení významně zkracuje dobu teplého startu - průměrné trvání je přibližně 3krát rychlejší a minimum je 1 ms místo 18 ms.

Lambda Durations

Připojení k instanci RDS je časově náročná úloha a nemusíte se připojit pro každou vyvolání, což je pro výkon výhodné. Při připojení k databázi pro jednoduchý databázový dotaz dosáhneme maximálního počtu připojení k databázi 20, což odpovídá úrovni souběžnosti (provedli jsme 20 souběžných vyvolání x 100krát). Když se výbuch vyvolání zastaví, spojení se postupně uzavírají.

Nyní, když AWS zvýšila povolenou délku lambda na 15 minut, to znamená, že připojení k databázi by mohlo trvat déle a mohlo by být v nebezpečí dosažení maximálního počtu připojení RDS. Výchozí maximální připojení lze přepsat v nastavení skupiny parametrů RDS, i když zvýšení maximálního počtu připojení může způsobit problémy s přidělením paměti. Menší instance mohou mít výchozí hodnotu max_connections menší než 100. Mějte na paměti tyto limity a přidejte aplikační logiku pro připojení k databázi pouze v případě potřeby.

Použití globálního připojení pro jiné úkoly

Lambda Připojení k S3

Běžným úkolem, který bychom mohli s Lambdou potřebovat, je přístup ke stavovým datům z S3. Úryvek kódu níže je plán služby Python Lambda Function poskytovaný společností AWS - ke kterému se můžete přihlásit přihlášením do konzoly AWS a kliknutím sem. V kódu můžete vidět, že klient S3 je při inicializaci kontejneru plně definován mimo obslužnou rutinu, zatímco u příkladu RDS bylo globální spojení nastaveno uvnitř obslužné rutiny. Oba přístupy nastaví globální proměnné, které jim umožní, aby byly k dispozici pro následné vyvolání.

Fragment kódu s3-get-object lambda blueprint https://console.aws.amazon.com/lambda/home?region=us-east-1#/create/new?bp=s3-get-object-python

Dešifrování proměnných prostředí

Konzola lambda vám dává možnost šifrování proměnných prostředí pro další zabezpečení. Následující úryvek kódu je příkladem Java poskytovaného skriptu AWS pomocného skriptu pro dešifrování proměnných prostředí z funkce Lambda. Na tento úryvek kódu můžete přejít podle tohoto návodu (konkrétně krok 6). Protože DECRYPTED_KEY je definován jako globální třída, funkce decryptKey () a logika jsou volány pouze jednou na lambda kontejner. Uvidíme proto výrazné zlepšení doby teplého startu.

https://console.aws.amazon.com/lambda/home?region=us-east-1#/functions and https://docs.aws.amazon.com/lambda/latest/dg/tutorial-env_console.html

Využití globálních proměnných v jiných řešeních FaaS

Tento přístup není izolován od AWS Lambda. Metodu použití globálního připojení lze použít také na funkce serverů jiných poskytovatelů cloudu. Stránka tipů a triků funkce Google Cloud Functions poskytuje dobré vysvětlení nelichotivých proměnných (pokud je proměnná vždy inicializována mimo metodu handler) versus líné proměnné (globální proměnná je nastavena pouze v případě potřeby) globální proměnné.

Další doporučené postupy

Zde je několik dalších doporučených postupů, které byste měli mít na paměti.

Testování

Použití FaaS usnadňuje architekturu mikroprocesů. A s malými, samostatnými funkcemi jde ruku v ruce s účinným testováním jednotek. Chcete-li pomoci jednotkovým testům:

  • Nezapomeňte vyloučit testovací závislosti z balíčku lambda.
  • Oddělte logiku od metody handler, jako byste to měli u hlavní metody programu.

Závislosti a velikost balíčku

Zmenšení velikosti balíčku nasazení znamená, že stahování kódu bude při inicializaci rychlejší, a proto zlepší vaše chladné časy začátku. Odstraňte nepoužité knihovny a mrtvý kód, čímž se zmenší velikost souboru nasazení ZIP. Sada AWS SDK je poskytována pro běhové časy Pythonu a JavaScriptu, takže je nemusíte zahrnout do vašeho implementačního balíčku.

Pokud je Node.js preferovaným runtime modulem Lambda, můžete použít minifikaci a uglifikaci, abyste snížili velikost kódu funkce a minimalizovali velikost balíčku implementace. Některé, ale ne všechny aspekty minifikace a uglifikace, lze použít na jiné runtime, např. nemůžete odstranit mezeru z pythonového kódu, ale můžete odstranit komentáře a zkrátit názvy proměnných.

Nastavení paměti

Pokuste se najít optimální množství paměti pro Lambda funkci. Platíte za přidělení paměti, takže zdvojnásobení paměti znamená, že musíte zaplatit dvojnásobek za milisekundu; ale výpočetní kapacita se zvyšuje s přidělenou pamětí, takže by mohla potenciálně zkrátit dobu běhu na méně než polovinu toho, co to bylo. Existuje již několik užitečných nástrojů pro výběr optimálního nastavení paměti, jako je toto.

Uzavřít…

Jedna věc, kterou je třeba zvážit, je, zda je nutné použít metodu opakovaného použití připojení. Pokud je funkce lambda vyvolávána jen zřídka, například jednou denně, nebudete mít prospěch z optimalizace pro teplé starty. Často existuje kompromis mezi optimalizací výkonu a čitelností kódu - pojem „uglifikace“ mluví samo za sebe! Navíc přidání globálních proměnných do kódu pro opětovné použití připojení k jiným službám může váš kód obtížněji sledovat. Přicházejí na mysl dvě otázky:

  • Rozumí nový člen týmu vašemu kódu?
  • Budete vy i váš tým moci tento kód v budoucnu ladit?

Ale je pravděpodobné, že jste si vybrali Lambdu pro její rozsah a chcete vysoký výkon a nízké náklady, takže najít rovnováhu, která odpovídá potřebám vašeho týmu.

Tyto názory jsou názory autora. Pokud není v tomto příspěvku uvedeno jinak, společnost Capital One není přidružena ani schválena žádnou z uvedených společností. Všechny použité ochranné známky a jiné duševní vlastnictví jsou vlastnictvím příslušných vlastníků. Tento článek je © 2019 Capital One.