AWS Lambda, serverless itp.
AWS Lambda to usługa pozwalająca uruchomić zaimportowany wcześniej kod. Jest to narzędzie działające w tzw. modelu serverless, czyli do wykonania kodu nie potrzebujemy powoływać serwera. Naszym zadaniem jest określenie zestawu funkcji jakie chcemy zrealizować, oraz w jakich okolicznościach mają być zrealizowane (np. na podstawie eventu z CloudWatch), pozostała reszta dzieje się sama. Cały trend związany z “serverless” jest obecnie dość modny ponieważ niesie za sobą wiele korzyści, jak pozbycie się pracy związanej z utrzymaniem maszyn wirtualnych, oraz bardzo często oszczędności finansowych. Używając AWS Lambda płacimy za ilość wykonań kodu oraz za czas wykonania.
Aby nie pisać tylko o tym jak to Cloud jest super i w ogóle, postanowiłem też podzielić się z wami ciekawym wg mnie zadaniem jakie miałem do zrealizowania.
Monitoring strony www.
Otóż jestem człowiekiem leniwym a więc zawsze staram się upraszać wszystko do granic możliwości. Jeden z moich serwisów www jest dość prostym środowiskiem, a mianowicie jedna instancja EC2 z wordpress i bazą danych. Nie roztaczając się teraz nad słusznością tego rozwiązania przyjmijmy, że tak musi być 🙂 Architektura taka jest podatna na wiele problemów jak brak redundancji itp. dlatego też postanowiłem zrobić sobie monitoring tego serwisu, a w dalszym etapie opcje samouzdrawiania się środowiska. W tym poście pokaże wam w jaki sposób wykorzystałem AWS Lambda oraz CloudWatch do monitoringu.
Założenia
Założeniem jest aby monitorować czy zwracany jest kod 200 http dla konkretnego url. Oczywiście chcę to robić z zewnątrz a nie np. w cron na samym serwerze aby wykluczyć wszelkie ewentualne problemy wokół samej instancji. W Internecie jest sporo serwisów oferujących takie rzeczy ale ja pomyślałem, że w sumie można wykorzystać do tego AWS Lambda.
Ma to działać tak, że co jakiś kwant czasu sprawdzane jest czy zwracany jest kod 200. Następnie wynik ten przekazywany jest do AWS CloudWatch jako custom metric. Aby łatwiej zrobić alarmy przyjąłem trzy wartości metryki:
- Jeśli jest http 200 lub 304 to wartość metryki jest 200.
- Jeśli np nie udało się wogóle podłaczyć do serwera (np gdy apache stanie kołkiem) wtedy metryka jest ustawiana na 100.
- W każdym innym przypadku metryka ustawia się na 50.
Następnie dla danej metryki skonfigurowany został Alarm, gdy wartość spadnie poniżej 200 ma zostać wysłane powiadomienie email, że coś jest nie tak. W kolejnej wersji będą to akcję mające dokonać “samo naprawienia” się.
Aby zyskać na uniwersalności rozwiązania podzieliłem to na dwie funkcje Lambda:
- WebsiteCheck – której zadaniem jest sprawdzić czy można się połączyć na dany URL, sprawdzić kod http i przekazać go do funkcji generującej wartość metryki w CloudWatch.
- SendMetric – funkcja ta otrzymuje dwa parametry nazwę metryki oraz wartość jaką ma ustawić w CloudWatch.
Konfiguracja
Kod obydwu funkcji można pobrać z GitHub. Przyznam, że jestem początkującym pythonowcem więc być może kod da się zoptymalizować.
Aby to wszystko zadziałało, potrzebne będą IAM-owe role:
- Dla funkcji WebsiteCheck można użyć predefiniowanej roli “AWSLambdaBasicExecutionRole” oraz możliwość wywołania SendMetric (lambda:InvokeFunction).
- Dla Funkcji SendMetric wystarczy ta predefiniowana.
Następnie tworzymy obydwie funkcje (pomijając blueprint) wg ustawień jak na obrazku. Należy tylko pamiętać o wybraniu odpowiednich ról.
Funkcja WebsiteCheck potrzebuje jeszcze określenia Event Source jak np. CloudWatch Events – Schedule
Na koniec pozostaje wam ustawienie Alarmu w CloudWatch dla nowo powstałej metryki i odpowiedniej akcji z nim związanej. U mnie w tej chwili jest to notyfikacja na email.
Jeśli z kolei chcecie dodać kolejną stronę, wtedy tworzymy jedynie kolejną funkcję WebsiteCheck i definiujemy w niej nowy url.
Ile to kosztuje?
Przy założeniu, że sprawdzanie strony wywołujemy co 5 minut to mamy 8640 wywołań w miesiącu i średnim czasie wykonania 500ms koszt jest równy 0USD (pierwszy milion wywołań per miesiąć jest za free). Co z resztą łatwo można policzyć na lambda kalkulatorze:
Jeśli chodzi o elementy CloudWatch, to każdy klient otrzmuje 10 metryk i 10 alarmów za free:
“New and existing customers also receive 10 metrics (applicable to Detailed Monitoring for Amazon EC2 instances, Custom Metrics, or CloudWatch Logs*), 10 alarms, and 1 million API requests each month at no additional charge.”
Mam nadzieję, że mój pomysł do czegoś może wam się przydać 🙂 Komentujcie, hejtujcie i testujcie 🙂
Zbuduje swoje bezpieczne środowisko AWS.
