Ad-hoc ülesannete ajastamine DynamoDB TTL ja Lambda abil

Foto Emma Matthews saidil Unsplash

CloudWatchi sündmused võimaldavad teil Lambda abil hõlpsalt cron-töid luua. Kuid see pole mõeldud paljude ad-hoc ülesannete käitamiseks, igaüks täidetakse üks kord kindlal kellaajal. CloudWatchi sündmuste vaikelimiit on madalad 100 reeglit regiooni kohta kontol. See on pehme limiit, seega on võimalik limiidi suurendamist taotleda. Kuid madal esialgne piirmäär näitab, et see pole mõeldud kasutamiseks juhtudel, kui peate ajastama miljoneid ajutisi ülesandeid.

CloudWatch Events on mõeldud korduvate ülesannete täitmiseks.

https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/cloudwatch_limits_cwe.html

Probleem

Seda on võimalik teha peaaegu igas programmeerimiskeeles. Näiteks .Netis on klass Taimer ja JavaScriptil on funktsioon setInterval. Kuid ma leian sageli, et tahan teenuse abstraktsiooni kasutamist. Sellise teenuse kasutamiseks on palju juhtumeid, näiteks:

  • Mängude turniirisüsteem peaks turniiri alguse ja lõppemise ajal täitma äriloogikat.
  • Ürituste süsteem (arvan, et eventbrite.com või meetup.com) vajaks mehhanismi, et osalejatele õigeaegselt meeldetuletusi saata.
  • Ülesande jälgija (mõtle Wunderlist) vajaks mehhanismi meeldetuletuste saatmiseks, kui ülesande täitmise tähtaeg tuleb.

Kuid AWS ei paku seda tüüpi töökoormuste jaoks teenust. CloudWatchi sündmused on lähim asi, kuid nagu eespool arutatud, pole see mõeldud ülaltoodud kasutusjuhtudeks. Saate neid siiski rakendada cron-töödega. Kuid sellistel rakendustel on ka muid väljakutseid.

Olen juba paar korda oma karjääri jooksul sellist teenuse abstraktsiooni rakendanud. Katsetasin mitmeid erinevaid lähenemisviise:

  • cron job (koos CloudWatchi sündmustega)
  • mähitakse klass .Net Timer HTTP lõpp-punktina
  • kasutades SQS-i nähtavuse ajalõppu ülesannete peitmiseks kuni nende täitmiseni

Ja viimasel ajal olen näinud, kuidas mitmed inimesed kasutavad nende sihtotstarbeliste ülesannete rakendamiseks rakendust DynamoDB Time-To-Live (TTL). Selles postituses vaatleme seda lähenemisviisi ja näeme, kus see võiks teie jaoks olla rakendatav.

Kuidas mõõta lähenemist?

Seda tüüpi ajutiste ülesannete puhul on tavaliselt oluline:

  • Täpsus: kui lähedal minu ülesande täitmise ajale ülesanne täidetakse? Mida lähemale, seda parem.
  • Skaala (avatud ülesannete arv): kas lahendusskaala toetab paljusid avatud ülesandeid, s.t ülesandeid, mis on ajastatud, kuid mida pole veel täidetud?
  • Skaala (levialad): kas lahendus saab skaleerida paljude ülesannete samaaegset täitmist? Näit. miljonid inimesed määrasid taimeri, et meelde tuletada, et nad vaatavad Superbowli, nii et kõik taimerid tulistavad avalöögi vahetus läheduses.

DynamoDB TTL kui ajastamismehhanism

Kõrgetasemeliselt näeb see lähenemisviis välja järgmine:

  • Scheduled_items DynamoDB tabel, mis sisaldab kõiki täitmiseks kavandatud ülesandeid.
  • Ajastamisfunktsioon, mis kirjutab ajastatud ülesande tabelisse tvarkaraš_items, kusjuures TTL on seatud ajastatud täitmise ajale.
  • Graafiku täitmise funktsioon, mis tellib DynamoDB voo ajakava_teoste jaoks ja reageerib REMOVE sündmustele. Need sündmused vastavad sellele, millal üksused on tabelist kustutatud.

Skaleeritavus (avatud ülesannete arv)

Kuna avatud ülesannete arv tähendab lihtsalt tabelis Scheduled_items olevate üksuste arvu, võib see lähenemisviis laiendada miljonitele avatud ülesannetele.

DynamoDB saab hakkama ka suurte läbilaskevõimetega (tuhandeid TPS). Nii et seda lähenemisviisi saab kasutada ka stsenaariumide korral, kus sekundis on kavandatud tuhandeid üksusi.

Skaleeritavus (levialad)

Kui korraga kustutatakse palju üksusi, pannakse need lihtsalt järjekorda DynamoDB voos. AWS skaleerib ka voos olevate kildude arvu automaatselt, nii et läbilaskevõime suurenemisel tõuseb kildude arv vastavalt.

Kuid sündmusi töödeldakse järjestikku. Nii et teie funktsiooni töötlemine sündmuse töötlemiseks võib võtta veidi aega, sõltuvalt:

  • - tema positsioon voos ja -
  • kui kaua võtab iga sündmuse töötlemine aega.

Ehkki see lähenemisviis võib toetada paljusid ülesandeid, mis kõik aeguvad samal ajal, ei saa see siiski tagada, et ülesanded täidetakse õigeaegselt.

Täpsus

See on selle lähenemisviisi kohta suur küsimus. Ametliku dokumentatsiooni kohaselt kustutatakse aegunud kaubad 48 tunni jooksul. See on tohutu veamäär!

Katsena seadistasin sammfunktsioonide olekumasina, et:

  1. lisage tabelisse Timer_items konfigureeritav arv üksusi, kusjuures TTL aegub vahemikus 1–10 minutit
  2. jälgige ülesande kavandatud aega ja seda, millal funktsioon ajakava järgi seda tegelikult valib
  3. oodake kõigi üksuste kustutamist

Olekumasin näeb välja selline:

Tegin mitu katset. Tulemused on ühtsed, olenemata tabelis olevate üksuste arvust. Kiire pilguheit laua taga annab teile teada, et keskmiselt täidetakse ülesannet 11 minuti jooksul pärast kavandatud aega.

USA-EAST-1

Kordasin katseid veel mitmes AWS-i piirkonnas:

Ma ei tea, miks on US-EAST-1 ja teiste piirkondade vahel nii suur erinevus. Üks seletus on see, et TTL-i protsess nõuab pärast tabeli loomist natuke aega sisenemist. Kuna arenesin alguses USA-EAST-1 piirkonna vastu, on selle TTL-protsess teiste piirkondadega võrreldes “soojenenud”.

Järeldused

Minu katse tulemuse põhjal näib, et DynamoDB TTL-i kasutamine ajastamismehhanismina ei taga mõistlikku täpsust.

Ühelt poolt on lähenemisviis skaala väga hea. Kuid teisest küljest täidetakse plaanitud toiminguid vähemalt mitu minutit taga, mis muudab selle mitmel juhul kasutamiseks sobimatuks.