Serverless - best practices auf AWS Lambda

ObjektForum Karlsruhe, 18.09.2017

Ben Romberg

Agenda 1. Was bedeutet “Serverless”?2. Aktuelle Serverless Provider3. AWS Lambda

a. Vorstellung Grundfunktionalitätb. Typische Use-Casesc. Limitierungen

4. Best practices

2Link zu dieser Präsentation: http://tiny.cc/serverless-objektforum

Vorstellung

3https://www.xing.com/profile/Ben_Romberg

1.ServerlessFrei von Servern?

4

Serverless Serverless verhält sich zu Servern, wie

Java zu Betriebssystemen (“OS-less”)

5

▪ Serverless: “Kümmer dich nicht um die Server”, “Serverworryless”

▪ Hochgeladener Code wird automatisch deployt▪ Kosten nur für tatsächlich verwendete Ressourcen (CPU,

Memory)▪ Nahtlose Skalierbarkeit▪ Einfache weltweit redundante Verfügbarkeit▪ Kein Wartungsaufwand

- OS Updates- Runtime Updates (z.B. JVM)

Server Immobilien

6

● Eigene Hardware

● Cloud Instanz

● Serverless

● Eigenes Haus

● Wohnung

● Hotelzimmer

FaaS vs. BaaS

● Eigener Code● Managed Container● z.B. AWS Lambda

● Thema dieses Vortrags

Mehr zu FaaS vs. BaaS unter https://martinfowler.com/articles/serverless.html

● Kein eigener Code notwendig● Managed Service/Backend● Populär bei mobile Apps und

Webseiten● z.B. Google Firebase

Serverless Datenbanken

▪ Serverless Konzept auf Datenbanken übertragen▪ Anforderungen:

- Globale Verfügbarkeit- Kosten skalieren exakt mit benötigten

Ressourcen- Kein Wartungsaufwand

▪ Existierende Anbieter:- Azure Data Lake (Analytics)- Google Cloud Datastore (NoSQL)- FaunaDB (NoSQL, global)

8Mehr zu Serverless Datenbanken unter https://serverless.com/blog/serverless-database-wish-list/

2.ServerlessProvider

9

10

Aktuelle Serverless (FaaS) Provider AWS Lambda Google Cloud Functions

Azure Cloud Functions Apache OpenWhiskauf IBM BlueMix

11

AWS Lambda Google CF Azure CF IBM OpenW.

Laufzeitumgebungen Java.NET CoreNode.jsPython

Node.js C#, F#Node.jsPHPPythonbash

JavaNode.jsPHPPythonSwiftDocker

Memory 128 - 1536 MB 128 - 2048 MB 128 - 1536 MB 128 - 512 MB

Kosten pro Mio. Request $0.20 $0.40 $0.20 $0

Kosten pro GB-Sekunde $0.00001667 ~$0.0000165 $0.000016 $0.000017

Maximale Laufzeit 5 Minuten 9 Minuten 5 Minuten 5 Minuten

Verfügbar seit 11/2014 02/2016 03/2016 02/2016

3.aAWS LambdaDie eierlegende Wollmilchsau?

12

13

“

14

AWS Lambda Logs

AWS Lambda Event Trigger

15

synchron,alle anderenasynchron

AWS Lambda Monitoring

16

3.bAWS Lambda

Typische Use-cases

17

Use-case:

Cloud Automatisierung

Hier: Automatisierte Backups von EBS Volumes

18https://aws.amazon.com/answers/infrastructure-management/ebs-snapshot-scheduler/

Use-case:

Komplexe Analytics Workflows

Hier: ETL Workflow (Extract, Transform, Load)

19https://aws.amazon.com/blogs/big-data/automating-analytic-workflows-on-aws/

Use-case:

HochskalierbareWebseiten

Hier: Kombination mit S3, API Gateway und DynamoDB

20https://www.slideshare.net/AmazonWebServices/aws-april-2016-webinar-series-continuous-delivery-with-aws-lambda

Use-case:

Hohe Spitzenlast bei “Crazylister”

Hier: 100,000e Requests in wenigen Sekunden

21https://aws.amazon.com/blogs/startups/from-0-to-100-k-in-seconds-instant-scale-with-aws-lambda/

3.cAWS Lambda

Limitierungen

22

AWS Lambda

Limitierungen

▪ Memory: 1536 MB, 1 CPU▪ Laufzeit: 5 Minuten▪ Funktionsgröße:

- Gepackt: 50 MB- Extrahiert: 250 MB

▪ “/tmp” space: 512 MB▪ Request Größe:

- Synchron: 6 MB (auch für Response)- Asynchron: 128 KB

▪ Asynchron: bei Error 2 Retries mit steigendem Delay▪ Anzahl Prozesse/Threads: 1024▪ Anzahl offene Files: 1024▪ Parallel ausgeführte Container (“Concurrent

executions”): 1000 (soft limit)

23

AWS Lambda

Ausfälle

▪ Letzte Ausfälle auf us-east-1 (größte Region in AWS):- 22.06.2017: 9 Stunden- 11.04.2017: 4 Stunden- 28.02.2017: 9 Stunden

- Großer S3 Ausfall, kein S3 -> kein Lambda!- 03.11.2016: 19 Stunden (für asynchrone Requests)

▪ 99,5% Verfügbarkeit in den letzten 12 Monaten▪ Keine Availability Zones

- Ausfälle betreffen in der Regel immer ganze Region- -> Redundanz in mehreren Regionen sinnvoll

24

AWS Lambda

System-Umgebung

Stand:15.09.2017

▪ Container sind keine EC2 Instanzen (keine Metadaten verf.)▪ 2x 2.90 GHz CPUs, 3.7 GB RAM▪ Linux version 4.9.43-17.38.amzn1.x86_64 (/proc/version)

- 4.9 = 12/2016, letztes LTS release- 4.9.43 = 13.08.2017, letzte Version 4.9.49- Vermutlich stark an Amazon Linux Release Zyklus

gekoppelt▪ JDK 1.8.0 Update 141 (18.07.2017)

- Letztes Update 144 (26.07.2017)▪ Auf Java wird Memory fragmentiert, bei kleinen Funktionen

z.B. Metaspace Error- java.lang.OutOfMemoryError: Metaspace- Memory Size: 128 MB Max Memory Used: 53 MB

▪ Systemumgebung wird automatisch und ohne Vorankündigung aktualisiert

25Mehr Details auf http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html

AWS Lambda

Laufzeit-Umgebungen

Wie oft werden Laufzeitumgebungen an aktuelle Versionen angepasst? Als Beispiel Node.js:

▪ 11/2014: AWS Lambda eingeführt mit Node.js 0.10▪ 04/2016: Node.js 4.3 hinzugefügt (Release war 03/2016)▪ 11/2016: Node.js 0.10 deprecated▪ 03/2017: Node.js 6.10 hinzugefügt (Release war 02/2017)▪ 04/2017: Node.js 0.10 entfernt▪ Vermutlich:

- 1 Jahr um zu neuer Version zu wechseln- 6 Monate Ankündigung bis Version entfernt wird- Neue Major Versionen (z.B. Java 9) werden 1 Monat

nach Release verfügbar sein- .NET Core 2.0 wurde am 14.08.2017 released...

26

“AWS Lambda Cold Starts

27

Request Container im Pool verfügbar?

Container starten (Cold Start)

Funktion ausführen

Container zurück in den Pool

Container stoppen nach >4:30 Min. Inaktivität

Container shutdown nach 7-8 Stunden

Container Pool

Response senden

ja

nein

▪ Lambda Funktionen werden in Lambda “Containern” ausgeführt- Mindestverfügbarkeit nach Deployment: 4:30 Minuten (auf dem selben Container)- Maximale Containerlaufzeit: ~7-8 Stunden

“AWS Lambda Cold Start Auswirkungen

28▪ Cold Starts stark abhängig von Laufzeitumgebung, Funktionsgröße, Memory und VPC▪ VPC hat sporadische “Super Cold Starts”, wenn ENI (Elastic Network Interface) initialisiert werden muss

Laufzeit- umgebung

Funktions- Größe

Memory VPC Laufzeit Log

Laufzeit Extern

Cold Start Log

Cold start Extern

Cold start + ENI

Python 1 KB 1536 MB 1 ms 15 ms 1 ms 200 ms

.NET Core 210 KB 1536 MB 1 ms 15 ms 400 ms 1100 ms

Node.js 1 KB 1536 MB 1 ms 15 ms 40 ms 400 ms

Java 2 MB 1536 MB 1 ms 15 ms 70 ms 800 ms

Java 20 MB 1536 MB 1 ms 15 ms 400 ms 8000 ms

Java 2 MB 256 MB 1 ms 15 ms 500 ms 1400 ms

Java 2 MB 1536 MB ✔ 1 ms 15 ms 70 ms 800 ms 8500 ms

AWS Lambda

Cold Start Lösungen

▪ Am Besten: Cold Start akzeptabel- Asynchrones Event Processing- Latenz unkritisch- Fast jeder nutzt Lambda Funktionen aktuell nur für

solche Applikationen▪ Theoretisch können Cold Starts passieren:

- Nach >4:30 Minuten Inaktivität- Alle 7-8 Stunden pro Container- Bei nebenläufigen Zugriffen (jederzeit)- Beim Wechsel auf eine neue Version der Funktion

(garantiert)▪ Cron-Job jede Minute?

- Löst nur den ersten Fall- Kann nur einen Container warm halten

▪ Lambdacult

29

AWS Lambda

API Gateway

▪ Beim direkten Aufruf einer Lambda Funktion +15 ms zusätzlich zur Runtime (+ SSL Handshake)

▪ Über API Gateway bis zu 150 ms zusätzliche Latenz▪ API Gateway hat auch “Cold Starts” (mehrere Sekunden)▪ API Gateway recht teuer - Beispielrechnung:

- 100 Requests/Sekunde, 1024 MB RAM, <100 ms Laufzeit, 1 KB Request + Response

- Lambda Kosten: $484 / Monat- API Gateway Kosten: $930 / Monat

▪ Eigenen Proxy schreiben?▪ Lambdacult

30

AWS Lambda

Weitere Probleme

▪ Vendor Lock-in- Schwer auf andere Serverless Provider zu übertragen- Kann nicht selber hosten- Auf Verfügbarkeit von AWS angewiesen

▪ Sicherheit- Keine Kontrolle über OS und Laufzeitumgebung- Code/Binaries liegen auf von AWS verwalteten Servern

▪ DoS Attacke bzw. unabsichtliche Event-Kaskaden würden hohe Kosten verursachen

- Keine Möglichkeit einzelne Funktion zu drosseln- Wenn Concurrent Executions Limit erreicht wird liegen

alle Funktionen innerhalb einer Region lahm- API Gateway bietet Drosselung pro Gateway an, aber

nicht z.B. auf IP Basis

31

4.Serverless

Best practices

32

Best practices

Error Handling

▪ CloudWatch Alarm für “Errors” und “Throttles” Metriken für:- Timeouts (Funktion überschreitet maximale Laufzeit)- Container Probleme- Ausfälle- “Throttles” = Concurrent Executions Limit erreicht- Kein Einfluss auf HTTP Response, kann in API Gateway

gemapt werden▪ Applikationsfehler können gelogt werden

- “Metric Filter” in CloudWatch Logs erstellen + Alarm- Volle Kontrolle über HTTP Response

▪ Alarm für regelmäßig laufende Funktionen33

Best practices

Logging

▪ CloudWatch Logs nett für Experimente, jedoch schnell unübersichtlich und langsam

▪ AWS Elasticsearch leicht integrierbar

▪ Alternative: In Lambda Funktion streamen▪ Applikationsseitiges Log-Streaming nicht zu empfehlen

34

Best practices

Versionierung

▪ Per Default nur $LATEST Version (mutable) mit aktuellem Code + Konfiguration verfügbar

▪ $LATEST Version kann immer in nummerierte Version (1, 2, 3, ...) eingefroren werden (immutable)

▪ Benannte Aliase können auf nummerierte Version (oder $LATEST) zeigen, leicht änderbar

35

Empfehlung

▪ Alias für “Live” Version, der auf nummerierte Version zeigt

▪ Leicht neue Versionen auszutesten▪ Leicht auf alte Versionen zu reverten▪ $LATEST nur zum testen verwenden▪ Description mit Git-Hash + Build-Date

Best practices

Tools

▪ Serverless Framework- Für alle Sprachen und Serverless Provider- Automatische Konfiguration von AWS Lambda, API

Gateway, CloudWatch, Logs, ...- Vergleichbar mit Terraform für Cloud Management

▪ Zappa (Open Source) oder Chalice (von AWS)- Speziell für Python auf AWS Lambda

▪ Lokale Testumgebung:- z.B. Java, viele kleine Frameworks für alle Sprachen- Selber schreiben, einfaches Interface

▪ Funktions-Einstellungen:- Timeout: Großzügig, keine Nachteile außer Kostengefahr- Memory: 1536 MB- Weniger Memory nur bei hohem Volumen und niedriger

CPU Auslastung- Asynchron: Dead-Letter Queue konfigurieren- VPC nur bei Notwendigkeit (Cold starts)

36

Best practices

Code

▪ Environment Variablen nutzen!- Aktuelle Region: AWS_REGION- Aktuelle Funktion: AWS_LAMBDA_FUNCTION_NAME- Usw. für Funktions-Version, Credentials, …

▪ Context nutzen!

▪ In der Regel schreibt man keinen “Monolithen” sondern mehrere Funktionen

- Eigener kleiner Lambda-Wrapper lohnt sich!

37

Best practices

Sicherheit

▪ Keine Credentials in Code/Config!▪ Jede Lambda Funktion ist einer IAM Role zugewiesen▪ AWS Zugriff über IAM Role managen

- Aktualisiert über automatisiertes Skript bei Deployment- Kann in Versionskontrolle verwaltet werden

▪ Externe Credentials per AWS Key Management Service (KMS)

38

Best practices

Zusammen-fassung

Serverless heute?

▪ Zum ausprobieren und kennenlernen▪ Cloud Automatisierung▪ Event Processing, Data Pipeline (z.B. für Analytics)▪ Abfangen großer Spikes

Größte Vorteile

▪ Kein Wartungsaufwand von Servern, OS und Laufzeitumgebung

▪ Einfache Verwaltung, auch über mehrere Regionen- Leicht zu automatisieren

▪ Nahezu beliebige Skalierbarkeit▪ Kosten linear zur Nutzung

Serverless morgen?

▪ Gibt noch viele Probleme zu berücksichtigen▪ Potenzial, klassische serverbasierte Applikationslandschaft

abzulösen 39

Vielen Dank!

Folien gibt’s auf tiny.cc/serverless-objektforum

ben@lambdacult.com

40