Kuidas valida AWS Lambda abil parim pubi / alamsõnumite edastamise sündmuste allikas

AWS pakub AWS Lambda abil palju sõnumside mustrite, näiteks avaldamise / tellimise (sageli lühendatud pubiks / alamrühmaks) rakendamiseks. Selles artiklis võrdleme ja võrdleme mõnda neist valikutest.

Pubi / alammuster

Pubi / alam on sõnumsidemuster, kus kirjastajad ja tellijad eraldatakse vahendava sõnumimaakleri kaudu (ZeroMQ, RabbitMQ, SNS jne).

Allikas: avalda tellimusmuster (Vikipeedia)

AWS-i ökosüsteemis on maakleri roll ilmselge kandidaat lihtne teavitusteenus (SNS).

Kui funktsiooni jaoks on määratud DLQ, proovib SNS teie Lambda funktsioonil sõnumi töötlemiseks kolm korda töötada, enne kui see on saadetud DLQ-le. OpsGenie inimeste analüüsi kohaselt võib korduste arv olla aga koguni kuus.

Teine asi, mida tuleks arvestada, on selle seadistuse pakutavate paralleelsuste määr. Iga sõnumi jaoks loob SNS teie funktsiooni uue kutsumise. Nii et kui avaldate SNS-is 100 sõnumit, saate tellitud Lambda-funktsiooni samaaegselt täita ka 100 korraga.

See on suurepärane, kui optimeerite läbilaskevõimet.

Kuid sageli piirab meid maksimaalne läbilaskevõime, millega meie alljärgnevad sõltuvused saavad hakkama - andmebaasid, S3, sisemised / välised teenused jne.

Kui läbilaskevõime on lühike, on piisav tõenäosus, et korduskorraldused on piisavad (ka proovide vahel on juhuslik, eksponentsiaalne tagasivõtmine) ja te ei jäta ühtegi teadet vahele.

Vigaseid teateid proovitakse kaks korda eksponentsiaalse tagasi lülitamisega. Kui sarivõte on lühiajaline, siis tõenäoliselt õnnestub uuesti proovimine, mille tulemuseks pole sõnumi kadu.

Kui läbilaskevõime puruneb pika aja jooksul, saate maksimaalse korduste arvu ammendada. Sel hetkel peate lootma DLQ-le ja võib-olla ka inimese sekkumisele, et taastada sõnumid, mida ei saanud esimest korda töödelda.

Vigaseid teateid proovitakse kaks korda eksponentsiaalse tagasi lülitamisega. Kuid sõnumimäära puhkemine kattub uuesti tehtud katsetega, süvendades seda probleemi veelgi ja lõpuks on maksimaalne korduskorralduste arv ammendatud ning ekslikud teated tuleb selle asemel edastada DLQ-le (kui üks on täpsustatud).

Sarnaselt, kui alljärgnevas sõltuvuses ilmneb tõrge, siis kõik tõrke ajal vastuvõetud ja uuesti proovitud teated on tõrked.

Kõik allavoolu teate ajal vastu võetud või uuesti proovitud sõnumid ebaõnnestuvad ja saadetakse DLQ-le.

Võite ka Lambda piirmäära samaaegsete hukkamiste arvu kohta piirkonnas. Kuna see on kogu kontot hõlmav limiit, mõjutab see ka teie teisi konto süsteeme, mis sõltuvad AWS Lambdast: API-liidesed, sündmuste töötlemine, cron-tööd jne.

SNS-i kannatavad ka ajalised probleemid, näiteks liikluse purunemised, alamjooksu katkemine jne. Kinesis seevastu tegeleb nende teemadega palju paremini, nagu allpool kirjeldatud:

  • Paralleelsuse astet piirab kihtide arv, mida saab kasutada purskkaevude amortiseerimiseks sõnumimääras
Teatesageduse puhkemised amortiseeritakse, kuna maksimaalne läbilaskevõime on määratud numbriga. kildudest * maksimaalne partii suurus * 5 lugemist sekundis. Mis annab teile kaks hooba maksimaalse läbilaskevõime reguleerimiseks.
  • Kirjeid proovitakse kuni edu saavutamiseni, välja arvatud juhul, kui seisak kestab kauem kui voo säilitamispoliitika (vaikimisi on 24 tundi). Lõpuks saate dokumente töödelda
Tootmisahela järgmise etapi mõju leevendab taaskutse saamise kord.

Kuid Kinesise ojatel pole oma probleeme. Tegelikult on minu kogemus Kinesis Streams'i kasutamisel koos Lambdaga leidnud mitmeid hoiatusi, mida tuleb teenuse efektiivseks kasutamiseks mõista.

Nende hoiatuste kohta saate lugeda mõnes teises artiklis, millest ma siin kirjutasin.

Huvitav on see, et Kinesis Streams pole ainus AWS-is saadaval voogesituse võimalus. Samuti on olemas DynamoDB Streams.

DynamoDB-vooge saab kasutada Kinesis-voogude sarnase asendajana.

Üldiselt töötab DynamoDB Streams + Lambda samamoodi nagu Kinesis Streams + Lambda. Operatiivselt on sellel huvitavaid keerdkäike:

  • DynamoDB Streams skaleerib kildude arvu automaatselt
  • Kui töötlete DynamoDB vooge AWS Lambda abil, ei maksa te DynamoDB voogude loenduste eest (kuid siiski maksate lugemis- ja kirjutamismahu ühikute eest kogu DynamoDB tabeli enda eest)
Allikas: DynamoDB hinnakujundus
  • Kinesis Streams pakub võimalust pikendada andmete säilitamist 7 päevani, kuid DynamoDB Streams sellist võimalust ei paku
Allikas: DünamoDB voogude kasutamine

Fakt, et DynamoDB Streams skaleerib kildude arvu automaatselt, võib olla kahe teraga mõõk. Ühelt poolt välistab see vajaduse teie voogu hallata ja skaleerida (või pakkuda kodus küpsetatud automaatse skaleerimise lahendusi). Kuid teisest küljest võib see vähendada ka võimet amortiseerida koormuse naelu, mille te edasivoolusüsteemidele edastate.

Minu teada ei saa mingil viisil piirata kihtide arvu, mida DynamoDB voog võib skaleerida, ja see on midagi, mida kindlasti kaaluksite oma automaatse skaleerimise lahenduse rakendamisel.

Ma arvan, et kõige asjakohasem küsimus on: “mis on teie tõe allikas?”

Kas DynamoDB-s kirjutatud rida muudab selle teie süsteemi olekusse kanooniliseks? See kehtib kindlasti enamiku N-astme süsteemide kohta, mis on üles ehitatud andmebaasi ümber, sõltumata sellest, kas tegemist on RDBMS või NoSQL andmebaasiga.

Sündmustepõhises süsteemis, kus olek on modelleeritud sündmuste jadana (erinevalt hetkeseisust), võib tõe allikaks olla Kinesise voog. Näiteks kui sündmus on voogu kirjutatud, peetakse seda süsteemi olekuks kanooniks.

Siis on veel muid kaalutlusi seoses kulude, automaatse mastabeerimise ja muu sellisega.

Arengu seisukohast on DynamoDB voogudel ka mõned piirangud ja puudused:

  • Iga voog on piiratud sündmustega ühest lauast
  • Kirjed kirjeldavad DynamoDB-i sündmusi, mitte teie domeeni sündmusi, mis on alati minu meelest tekitanud nende sündmustega töötades dissonantsi

Välja arvatud Lambda kutsumiste kulud sõnumite töötlemiseks, on siin mõned kulude prognoosid SNS vs Kinesis Streams vs DynamoDB Streams kasutamise vahendajana. Ma oletan, et läbilaskevõime on ühtlane ja iga sõnumi suurus on 1KB.

Kuukulu 1 msg / s

Kuukulu on 1000 msg / s

Neid prognoose ei tohiks võtta nimiväärtuses. Alustuseks on eeldus täiesti ühtlase läbilaskevõime ja sõnumi suuruse kohta ebareaalne ning teil on vaja Kinesise ja DynamoDB voogude jaoks pisut ruumi, isegi kui te ei saavuta drossi piire.

Need prognoosid ütlevad mulle, et:

  1. Kinesise voogudes saate iga kirstuga kohutavalt palju
  2. Ehkki Kinesise voogude kasutamise algkulud on madalamad, vähenevad kulud, kui kasutusmõõdud suurenevad, võrreldes SNS- ja DynamoDB-voogudega, tänu märkimisväärselt madalamale miljoni päringu maksumusele.

Kui SNS-, Kinesise- ja DynamoDB-vood on maakleri peamised valikud, saavad Lambda funktsioonid tegutseda ka ise maakleritena ja levitada sündmusi teistele teenustele.

Seda lähenemisviisi kasutas awslabs-projekt aws-lambda-fanout. See võimaldab teil levitada sündmusi Kinesise ja DynamoDB voogudest muudele teenustele, mis ei saa otseselt tellida kolme peamist maakleri valikut (kas konto / piirkonna piirangute tõttu või seetõttu, et neid lihtsalt ei toetata).

Awslabsi projekt aws-lambda-fanout levitab sündmusi Kinesise ja DynamoDB voogude kaudu muudele teenustele mitme konto ja piirkonna vahel.

Ehkki see on kena idee ja vastab kindlasti mõnele konkreetsele vajadusele, tasub siiski meeles pidada sellega kaasnevaid täiendavaid keerukusi, näiteks osaliste rikete käsitlemine, alamjooksu katkestuste, valesti konfigureerimiste käsitlemine jne.

Järeldus

Mis on parim sündmusallikas pubi-subi tegemiseks koos AWS Lambdaga? Nagu enamik tehnilisi otsuseid, sõltub see ka probleemist, mida proovite lahendada, ja kitsendustest, millega töötate.

Selles postituses vaatasime maakleri rolli kandidaatidena SNS-i, Kinesise vooge ja DynamoDB-vooge. Käisime läbi mitu stsenaariumi, et näha, kuidas sündmuse allika valik mõjutab mastaapsust, paralleelsust ja vastupidavust ajaliste probleemide ja kulude suhtes.

Lambdaga töötades peaks teil nüüd olema palju parem ülevaade erinevate sündmuste allikate vahelistest kompromissidest.

Järgmise korrani!