Weel 12: AWS Lambda, EventBridge, SQS, SNS
AWS Lambda
Lambda je AWS event-driven servis ciji je osnovni zadatak izvrsavanje Lambda funkcije onda kada se desi okidac tj. trigger a koji je izazvan dogadjajem koji se desio - event.
Lambda servis ce izvristi Lambda funkciju specijalnizovanu za handle-ovanje tog event-a. Dakle, u ovom slucaju ne znamo gdje se nasa funkcija u pozadini izvrsava, ali to za nas nije od kljucne vaznosti.
Lambda funkcija je dio koda koji Lambda servis izvrsava. Kada kreiramo Lambda funkciju, potrebno je da izaberemo jezik u kojem pisemo kod funkcije odnosno runtime koji ce funkcija koristiti. Tada se kreira i runtime enviroment, okruzenje podeseno na osnovu jezika koji smo izabrali za nasu Lambda funkciju.
Runtime enviroment
Runtime enviroment ima svoju memoriju direct memory koju alociramo unaprijed pri kreiranju Lambda funkcije, a jedan dio memorije ce biti odvojen za virtual CPU.
Alokacija memorije od 128MB do 1024MB sa 1MB koracima
1769 MB memorije dodjeljuje 1 vCPU Ne mozemo sami izabrati velicinu CPU koju zelimo, vec ce se taj dio odvojiti zavisno od memorije koju smo alocirali. Ovaj nacin dodjele CPU-a je indirektan.
Runtime enviroment ima alociranu dodatnu memoriju za fajlove u folderu /tmp - 512 MB, koja moze da se poveca do 10240 MB - dozvoljeno je koristenje ali /tmp folder je prazan pri svakom novom pozivu funkcije jer se tu cuvaju temporary files
Izborom jezika koji ce biti koristen za izvrsenje koda, odredjuje se i koje komponente ce nam biti dostupne.
Svaki put kada se Lambda funkcija pozove na izvrsenje, kreira se novi runtime enviroment sa svim potrebnim komponentama koje Lambda funkcija zahtjeva za adekvatno izvrsenje. Kod se ucita, izvrsi i terminira.
Lambda funkcije su stateless
Sto znaci no data left from pevious invocation. Nakon svakog novog poziva, pokrece se "cisto" radno okruzenje, bez zaostalih fajlova iz prethodnih poziva.
Lambda funkciju osim kao samo dio koda mozemo posmatrati i kao paket koji sadrzi sve potrebne postavke za izvrsenje - deployment package. Kada se desi event i Lambda funkcija je pozvana na izvrsenje, deployment paket se preuzme i izvrsi unutar podesenog runtime enviroment-a.
CloudWatch Events
CloudWatch Events dostavljaju stream ili veci broj eventa koji su se desili nekim od AWS servisa, sto se desava skoro pa real-time uz mali delay. Na primjer, CW Events mozemo koristiti da obavjesti Lambda funkciju da se desilo terminiranje EC2 instance i treba nesto poduzeti.
Postoji samo jedan Event Bus koji nije prikazan unutar User Interface-a, iako smo u interakciji s njim kada trazimo evente i saljemo te evente ka target servisima kada zelimo da se nesto desi
Amazon EventBridge
EventBridge ima iste funkcionalnosti kao i CloudWatch Events uz dodatnu mogucnost hendlovanja eventima od strane third-parties application ili custom application. Iz ovih razloga, preporuka je da se polako krene u migraciju sa CW Events na EventBridge.
Pored defaultnog Event Bus-a, mozemo kreirati dodatne bus-ove bilo da su namijenjeni nasoj aplikaciji ili third-parties aplikacijama
Kljucni koncepti
Ako se desi X, Y puta... uradi Z
X predstavlja servis koji kreira event producer of an event
Y broj puta koliko se nesto desilo ili period vremena, za specifikaciju koristimmo UNIX cron format koji omogucava da specificiramo jedan ili vise puta kada se nesto treba desiti
Z je target servis kojem se dostavlja event da se dogadjaj X desio
Oba servisa imaju istu baznu arhitekturu, koriste default entity - Event Bus, te imaju default event bus za AWS account
Event Bus mozemo zamisliti kao pokretnu traku sa koferima na aerodromu. Gdje bi koferi predstavljali evente, aerodrom je nas AWS account, putnici su AWS servisi koji preuzimaju evente, a stuff aerodroma su AWS servisi koji dostavljaju evente. Na traku, stuff postavlja kofere na kojima pisu podaci o putniku, traka nosi kofere, a putnik kada prepozna svoj kofer i podatke uzima svoj kofer sa trake i odlazi. Na slican nacin EventBridge prihvata evente od servisa unutar AWS accounta, nosi te evente, a servisi koji budu obavjesteni da im stize event, rade polling tog eventa sa trake i vrse dalju obradu.
Kod oba servisa kreiramo rules koji odgovaraju sablonima eventa koji dolaze u bus, kada se prepozna unutar bus-a event, odgovarajuci rule salje event dalje ka target servisu
Mozemo uraditi i schedule rules, kako bismo podesili sablone eventa koji se desavaju u neko specificno vrijeme i za to ponovo koristimo UNIX CRON system
Amazon Simple Queue Service (SQS)
SQS - Simple Queue Service nam pruza upravljanje redovima (queues) poruka. To je public service, znaci da je dostupan bilo gdje sa AWS public space endpoints pristupom. To ukljucuje privatni VPC ako ima konektivnost ka servisima. U potpunosti je upravljiv, npr. kreiramo queue i onda servis dostavlja taj queue kao servis. Queues su HA (highly available), tako da ne moramo da brinemo o replikaciji i izdrljivosti. Postoje dva tipa queues-a:
Standard queues - najvise se koristi, ali postoji mogucnost da ne dobijemo poruke organizirano.
FIFO queues - pruza i garantira nam da poruke dolaze organizirano, i kada dobijemo poruke, vidimo ih organizirano, npr. poruka 1, poruka 2, poruka 3....
Posmatrajmo Standard queues kao autoput sa vise traka, dok je FIFO queues kao put sa jednom trakom bez prilike da bilo koga preteknemo. Standard queues nam garantira barem jednu isporuku ali ne garantira order te isporuke. Sa standardnim queues mozemo dobiti istu poruku dostavljenu 2x i order moze biti drugaciji. FIFO nam garantira order i isporuku tacno jednom.
Amazon Simple Notification Service (SNS)
SNS je kljucna komponenta mnogih arhitektura u AWS-u.
SNS je visoko dostupan, trajan, siguran, pub-sub messaging servis. Vise o pub-sub servisu mozete pogledati ovdje
Potreban nam je network connectivity sa javnim AWS endpointom kako bi pristupili SNS-u.
Koordinacija slanja i primanja poruka.
Poruke su sadrzaji velicine do 256 KB.
SNS Topics su glavni entitet SNS-a - Tu se permisije kontroliraju kao i vecina konfiguracija koja se definira.
Publisher salje poruke u TOPIC.
TOPICS imaju Subscribere i oni po defaultu primaju sve poruke koje se salju u TOPIC.
Subscriberi mogu da dodju u vise formi: HTTP(s), e-mail (JSON), SQS, Mobile Push, SMS poruke i Lambda .
HTTP(s): omogucuje slanje notifikacija putem HTTP(s) protokola. To je URL endpoint koji će primiti HTTP zahtijev sa sadrzajem notifikacije. Ova forma je veoma korisna kada bismo zeljeli da notifikacije stignu do web aplikacije.
E-mail (JSON): salju se notifikacije putem e-maila. Npr. navodi se adresa subscribera i onda notifikacija bude isporucena u JSON formatu putem e-mail poruke.
SQS (Simple Queue Service): SNS omogucuje integraciju sa SQS. Moze se subscribe-ati SQS queue na SNS topic, tako da svaka notifikacija bude dostavljena u queue kao poruka.
Mobile Push: salju se notifikacije putem mobilnih push servisa. Uradi se subscribe mobilne aplikacije na SNS topic, a notifikacije će biti dostavljene putem push servisa na uredjajima korisnika.
SMS poruke: moze se pretplatiti telefonski broj kao subscriber, a notifikacija će biti isporucena kao SMS poruka.
Lambda: SNS moze pozvati cak Lambda funkciju kao subscribera. Kada se notifikacija posalje na SNS topic, Lambda funkcija će biti automatski pokrenuta i moci ce obraditi notifikaciju na zeljeni način.
Amazon API Gateway
API Gateway omogucava kreiranje i upravljanje APIs (engl. Application Programming Interface).
API predstavlja softverski mehanizam koji pojednostavljuje development na nacin da radi apstrakciju detalja implementacije, prikazuje samo one detalje i objekte koji su potrebni developeru, te uspostavlja nacin komunikacije izmedju pruzatelja usluge i korisnika.
API Gateway je highly available i scalable servis.
API Gateway Endpoint types
Regional - klijenti se nalaze u istoj regiji
Edge-optimized - koristi CloudFront
Private - moze se koristiti samo unutar VPC
RESTful API Gateway
REST API
developer ima punu kontrolu nad zahtjevima i odgovorima
HTTP API
jednostavniji i jeftiniji za koristenje
manje kasnjenje
ne pruzaju mogunosti potpune kontrole nad zahtjevima i odgovorima
Autorizacija i autetifikacija API Gateway
None - otvoreni pristup
IAM - koristenje IAM servisa i IAM Credentials za pristup
JWT - JSON Web Tokens se koriste u pozadini za provjeru autenticnosti zahtjeva kada se koristi OpenID Connect ili OAuth 2.0. REST APIs mogu koristiti Amazon Cognito kao JWT authorizer.
Lambda authorizers - koristi se lambda funkcija za provjeru tokena ili se zahtijevaju parametri za odobravanje pristupa
Monitoring tools
CloudWatch - po default-u API Gateway svaku minutu salje odredjene metrike prema CloudWatch servisu
AWS X-Ray - prati i analizira zahtjeve end-to-end
AWS Config - procjena i pregled azuriranja konfiguracije
AWS CloudTrail - upravlja pozivima koji su upuceni prema API Gateway-u od strane korisnika, role ili nekog drugog AWS servisa.
Snimci predavanja
DevOps Mentorship Program - Week 12 - Serverless, AWS Lambda, EventBridge (#tier-1-group-1)
DevOps Mentorship Program - Week 12 - Amazon SNS, Amazon SQS (#tier-1-group-2) PART I
DevOps Mentorship Program - Week 12 - Alma Kazija - Amazon API Gateway (#tier-1-group-2) PART II
Materijali za ucenje
Korisni alati
Zadatak
Materijali za dodatno citanje
Last updated