• CloudPouch NEW!
  • Akademia
  • Blog
  • O Serverless
  • O stronie

Prosty Scheduler Serverless ÔĆ░


Amazon Comprehend - detekcja wra┼╝liwych danych
Pracuj─ůc nad rozwi─ůzaniem zarz─ůdzaj─ůcym kluczami licencyjnymi mojej aplikacji CloudPouch musia┼éem si─Ö zmierzy─ç z odroczonym w czasie anulowaniem p┼éatnej subskrypcji.

W momencie, gdy u┼╝ytkownik z jakiego┼Ť powodu zrezygnuje ze swojej subskrypcji, jego klucz licencyjny musi dzia┼éa─ç a┼╝ do ko┼äca obecnego okresu rozliczeniowego. Poniewa┼╝ przypadek u┼╝ycia w moim systemie nie jest skomplikowany, postanowi┼éem go rozwi─ůza─ç w mo┼╝liwie prosty spos├│b, korzystaj─ůc z dost─Öpnych us┼éug serverless, zgodnie z pryncypiami architektury sterowanej zdarzeniami (Event-Driven Architecture).

Serverless scheduler

Temat implementacji schedulera w serverless przewija si─Ö do┼Ť─ç cz─Östo ju┼╝ od lat. Moim zdaniem jest to na tyle powtarzalny problem, ┼╝e AWS powinien nam dostarczy─ç zarz─ůdzane rozwi─ůzanie. Rozmowy na Slacku AWS Community Builders p├│ki co nie przynios┼éy ┼╝adnych skutk├│w i wci─ů┼╝ jeste┼Ťmy zdani na samych siebie.

Na szcz─Ö┼Ťcie AWS dostarcza kilka prymityw├│w z kt├│rych mo┼╝na skorzysta─ç buduj─ůc w┼éasny scheduler. Do najpopularniejszych mo┼╝na zaliczy─ç:

  • DynamoDB TTL
  • Cron w EventBridge (kiedy┼Ť w CloudWatch)
  • StepFunctions.

Wyb├│r rozwi─ůzania pod problem biznesowy

Wymienione powy┼╝ej rozwi─ůzania r├│┼╝ni─ů si─Ö znacznie od siebie.

Przede wszystkim oferuj─ů r├│┼╝n─ů dok┼éadno┼Ť─ç dzia┼éania, czyli przedzia┼é czasu mi─Ödzy wyznaczonym, a rzeczywistym czasem wywo┼éania akcji. Przyk┼éadowo dla DynamoDB TTL jest to nawet maksymalnie 48 godzin. Stosuj─ůc Cron w EventBridge mo┼╝emy wywo┼éa─ç funkcj─Ö Lambda co minut─Ö. Ogromna r├│┼╝nica, prawda?
To jest najwa┼╝niejsza, funkcjonalna charakterystyka, gdy┼╝ bezpo┼Ťrednio wp┼éywa na implementacj─Ö wymaga┼ä biznesowych. W wielu przypadkach trudno sobie wyobrazi─ç sytuacj─Ö, ┼╝e nasz Biznes akceptuje dwudniow─ů obsuw─Ö w wykonaniu jakiej┼Ť akcji dotycz─ůcej klienta czy u┼╝ytkownika.

Pozosta┼ée charakterystyki, kt├│rymi mo┼╝emy opisa─ç te rozwi─ůzania s─ů r├│wnie┼╝ wa┼╝ne. Dla wielu maksymalna ilo┼Ť─ç zaharmonogramowanych akcji b─Ödzie r├│wnie wa┼╝na, jak dok┼éadno┼Ť─ç. Kolejn─ů cech─ů b─Ödzie maksymalny czas odroczenia akcji w przysz┼éo┼Ťci. No i oczywi┼Ťcie czy akcja jest cykliczna czy jednorazowa.

Id─ůc dalej nie mo┼╝na zapomina─ç o kosztach dzia┼éania oraz poziomie skomplikowania rozwi─ůzania, wp┼éywaj─ůcym bezpo┼Ťrednio na czas implementacji.

Bior─ůc te wszystkie charakterystyki pod uwag─Ö, szybko si─Ö okazuje, ┼╝e scheduler schedulerowi nie r├│wny i ostateczne rozwi─ůzanie zale┼╝y od wymaga┼ä.

Przypadek biznesowy

Narz─Ödzie CloudPouch to aplikacja typu desktop s┼éu┼╝─ůca do analizy i optymalizacji koszt├│w chmury AWS. Jest dost─Öpna w modelu subskrypcyjnym, za ma┼é─ů miesi─Öczn─ů lub roczn─ů op┼éat─ů. Ka┼╝dy klient ma mo┼╝liwo┼Ť─ç anulowania swojej subskrypcji w dowolnym momencie. Wtedy jego klucz licencyjny musi dzia┼éa─ç a┼╝ do ko┼äca obecnego okresu rozliczeniowego, za kt├│ry zosta┼éa ju┼╝ pobrana op┼éata, czyli do czasu t1 przedstawionego na diagramie.

Mechanizm musi działać analogicznie dla rocznych subskrypcji.

Wyb├│r rozwi─ůzania

Bior─ůc pod uwag─Ö wymagania biznesowe oraz charakterystyki us┼éug AWS, zdecydowa┼éem si─Ö wybra─ç rozwi─ůzanie, kt├│re b─Ödzie naj┼éatwiejsze do implementacji i obs┼éugi. By┼é to klasyczny architektoniczny trade-off, gdy┼╝ prostota implementacji zosta┼éa uzyskana kosztem dok┼éadno┼Ťci.

Wybór mechanizmu DynamoDB TTL (Time To Live) okazał się być najlepszy, ponieważ:

  • dok┼éadno┼Ť─ç nie jest dla mnie najwa┼╝niejsza, w najgorszym wypadku klient otrzyma dwa dni subskrypcji gratis ­čśë
  • nie potrzebuj─Ö cyklicznych wywo┼éa┼ä - dan─ů licencj─Ö anuluje si─Ö tylko raz
  • jest prosty w implementacji - wystarczy sama tabela DynamoDB oraz jej stream
  • jest zgodny Event-Driven Architecture, a dodatkowo AWS zadba za mnie o to, aby wywo┼éa─ç akcj─Ö w przysz┼éo┼Ťci. Innymi s┼éowy nie musz─Ö pisa─ç Lambdy, kt├│re b─Ödzie cyklicznie sprawdza─ç czy nale┼╝y co┼Ť anulowa─ç
  • pozwala ┼éatwo sprawdzi─ç, kt├│re licencje maj─ů zosta─ç anulowane w przysz┼éo┼Ťci - wystarczy przejrze─ç elementy w tabeli DynamoDB
  • jest najta┼äszy, cho─ç przy mojej skali ka┼╝de rozwi─ůzanie by┼éoby darmowe ­čśë

Implementacja rozwi─ůzania

Rozwi─ůzanie jest bardzo proste i sk┼éada si─Ö z funkcji Lambda oraz tabeli DynamoDB wraz ze streamem.

W odpowiedzi na anulowanie subskrypcji przez u┼╝ytkownika wysy┼éane jest zdarzenie na szyn─Ö eventBus w us┼éudze EventBridge. Przy pomocy regu┼é to zdarzenie jest przekierowane do funkcji Lambda scheduler (oraz innych komponent├│w w pe┼énym rozwi─ůzaniu, co nie jest pokazane na diagramie). Funkcja Lambda scheduler zapisuje w tabeli Scheduling informacji o licencji kt├│ra ma zosta─ç anulowana. Ten element (ÔÇťrekordÔÇŁ) ma bardzo prost─ů struktur─Ö, sk┼éada si─Ö z informacji pozwalaj─ůcej jednoznacznie zidentyfikowa─ç licencj─Ö w tabeli PaidLicenses oraz czasu kiedy ma to nast─ůpi─ç.

Data anulowania jest zapisana w formacie Unix time pod atrybutem okre┼Ťlonym w konfiguracji tabeli DynamoDB. Ja nazwa┼éem ten atrybut ttl, zosta┼é on zdefiniowany w CloudFormation tworz─ůcym tabel─Ö w linijce 10:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SchedulingTable:
Type: AWS::DynamoDB::Table
Properties:
AttributeDefinitions:
- AttributeName: PK
AttributeType: S
KeySchema:
- AttributeName: PK
KeyType: HASH
TimeToLiveSpecification:
AttributeName: ttl
Enabled: true
BillingMode: PAY_PER_REQUEST
TableName: Scheduling
StreamSpecification:
StreamViewType: OLD_IMAGE

Korzystaj─ůc z Node.js (JavaScript) nale┼╝y zwr├│ci─ç uwag─Ö, aby obliczy─ç ttl w odpowiedniej jednostce czasu, czyli w sekundach a nie milisekundach. St─ůd te┼╝ dzielenie przez 1000:

1
const ttl = Math.floor(new Date(cancelationTimeString).getTime() / 1000)

 

Zasada działania

Us┼éuga AWS DynamoDB nieustannie monitoruje nasz─ů tabl─Ö danych i w momencie, gdy warto┼Ť─ç ttl b─Ödzie starsza ni┼╝ obecny czas to skasuje dany element.

Aby ca┼ée rozwi─ůzanie mia┼éo sens, musimy reagowa─ç na zdarzenia kasowania element├│w. Robimy to za pomoc─ů streamu, kt├│ry wywo┼éuje funkcj─Ö deactivatePaidLicense. Payload przes┼éany do tej funkcji zawiera wszystkie dane tego elementu, kt├│re by┼éy wcze┼Ťniej przechowywane w tabeli Scheduling, dzi─Öki czemu funkcja wie, kt├│r─ů licencje ma anulowa─ç, dokonuj─ůc odpowiedniej aktualizacji w tabeli PaidLicenses.

Po┼é─ůczenie pomi─Ödzy streamem a funkcj─ů Lambda jest zdefiniowane w pliku serverless.yml:

1
2
3
4
5
6
7
8
9
10
11
12
functions:
deactivatePaidLicense:
handler: src/deactivatePaidLicense/function.handler
description: Deactivate license upon Paddle event
events:
- stream:
type: dynamodb
arn: !GetAtt SchedulingTable.StreamArn
maximumRetryAttempts: 1
batchSize: 1
filterPatterns:
- eventName: [REMOVE]

Zastosowa┼éem tutaj filtr, dzi─Öki kt├│remu funkcja zostanie wywo┼éana tylko w wyniku usuni─Öcia elementu z tabeli. W ten spos├│b przenosimy logik─Ö z naszego kodu na konfiguracj─Ö infrastruktury AWS, co jest oczywi┼Ťcie najlepsz─ů praktyk─ů ­čśâ

Tabela Scheduling jest niezale┼╝n─ů tabel─ů, kt├│ra przechwuje tylko i wy┼é─ůczne dane dotycz─ůce anulowania licencji. Nie korzystam tutaj z podej┼Ťcia single-table design, dlatego nie musz─Ö si─Ö martwi─ç o inne typy encji.

Działanie w praktyce

Moje pobie┼╝ne testy pokaza┼éy, ┼╝e DynamoDB w regionie us-east-1 kasuje elementy z op├│┼║nieniem 10 do 12 minut po zdefiniowanym czasie w atrybucie ttl. Jest to du┼╝o szybciej ni┼╝ podane powy┼╝ej 48 godziny, jednak nadal dla wielu rozwi─ůza┼ä mo┼╝e nie by─ç akceptowalne. Dodatkowo uczulam, ┼╝e o ile s─ů to typowe czasy to nie mamy ┼╝adnej gwarancji, ┼╝e zawsze takie b─Öd─ů.

Moje obserwacje op├│┼║nie┼ä pokrywaj─ů si─Ö z testami, kt├│re przeprowadzi┼é Yan Cui.

W praktyce, ca┼ée rozwi─ůzanie przy minimalnym nak┼éadzie czasu po┼Ťwi─Öconego na programowanie realizuje moje wymagania biznesowe w doskona┼éy spos├│b. I o to chodzi┼éo ­čśâ

CloudPouch

Je┼Ťli jeste┼Ť ciekaw(a) do czego s┼éu┼╝y aplikacja CloudPouch, kt├│rej jestem autorem, zach─Öcam do skorzystania z bezp┼éatnego 7-dniowego triala lub zapoznania si─Ö z poni┼╝szym, kr├│tkim (p├│┼étorej minuty) filmikiem demonstracyjnym.




Cze┼Ť─ç

Nazywam si─Ö Pawe┼é Zubkiewicz i ciesz─Ö si─Ö, ┼╝e tu jeste┼Ť!
Od ponad 16 lat profesjonalnie tworz─Ö oprogramowanie, a od 2016 roku pasjonuje si─Ö Serverless.
T─ů stron─Ö stworzy┼éem z my┼Ťl─ů o Tobie i o nas wszystkich, kt├│rzy uwa┼╝aj─ů, ┼╝e trend serverless trwale zmieni spos├│b tworzenia oprogramowania.
Wi─Öcej o tej stronie...

Kategorie

Pobierz bezpłatny PDF

Poradnik 12 Rzeczy o Serverless

Wybrane artykuły