Serverless - best practices auf AWS Lambda ObjektForum Karlsruhe, 18.09.2017 Ben Romberg
Agenda 1. Was bedeutet Serverless? 2. Aktuelle Serverless Provider 3. AWS Lambda a. Vorstellung Grundfunktionalität b. Typische Use-Cases c. Limitierungen 4. Best practices Link zu dieser Präsentation: http://tiny.cc/serverless-objektforum 2
Vorstellung https://www.xing.com/profile/ben_romberg 3
1. Serverless Frei von Servern? 4
Serverless Serverless verhält sich zu Servern, wie Java zu Betriebssystemen ( OS-less ) 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) 5
Server Immobilien Eigene Hardware Eigenes Haus Cloud Instanz Wohnung Serverless Hotelzimmer 6
FaaS vs. BaaS Eigener Code Managed Container z.b. AWS Lambda Thema dieses Vortrags Kein eigener Code notwendig Managed Service/Backend Populär bei mobile Apps und Webseiten z.b. Google Firebase Mehr zu FaaS vs. BaaS unter https://martinfowler.com/articles/serverless.html
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) Mehr zu Serverless Datenbanken unter https://serverless.com/blog/serverless-database-wish-list/ 8
2. Serverless Provider 9
Aktuelle Serverless (FaaS) Provider AWS Lambda Google Cloud Functions Azure Cloud Functions Apache OpenWhisk auf IBM BlueMix 10
AWS Lambda Google CF Azure CF IBM OpenW. Laufzeitumgebungen Java.NET Core Node.js Python Node.js C#, F# Node.js PHP Python bash Java Node.js PHP Python Swift Docker 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 11
3.a AWS Lambda Die eierlegende Wollmilchsau? 12
13
AWS Lambda Logs 14
AWS Lambda Event Trigger synchron, alle anderen asynchron 15
AWS Lambda Monitoring 16
3.b AWS Lambda Typische Use-cases 17
Use-case: Hier: Automatisierte Backups von EBS Volumes Cloud Automatisierung https://aws.amazon.com/answers/infrastructure-management/ebs-snapshot-scheduler/ 18
Use-case: Hier: ETL Workflow (Extract, Transform, Load) Komplexe Analytics Workflows https://aws.amazon.com/blogs/big-data/automating-analytic-workflows-on-aws/ 19
Use-case: Hier: Kombination mit S3, API Gateway und DynamoDB Hochskalierbare Webseiten https://www.slideshare.net/amazonwebservices/aws-april-2016-webinar-series-continuous-delivery-with-aws-lambda 20
Hier: 100,000e Requests in wenigen Sekunden Use-case: Hohe Spitzenlast bei Crazylister https://aws.amazon.com/blogs/startups/from-0-to-100-k-in-seconds-instant-scale-with-aws-lambda/ 21
3.c AWS 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 SystemUmgebung 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 Mehr Details auf http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html 25
AWS Lambda LaufzeitUmgebungen 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 Container stoppen nach >4:30 Min. Inaktivität Container Pool Request Container im Pool verfügbar? nein Container starten (Cold Start) ja Funktion ausführen Container shutdown nach 7-8 Stunden Container zurück in den Pool Response senden Lambda Funktionen werden in Lambda Containern ausgeführt Mindestverfügbarkeit nach Deployment: 4:30 Minuten (auf dem selben Container) Maximale Containerlaufzeit: ~7-8 Stunden 27
AWS Lambda Cold Start Auswirkungen Laufzeitumgebung FunktionsGröße Python Memory VPC Laufzeit Log Laufzeit Extern Cold Start Log Cold start Extern 1 KB 1536 MB 1 ms 15 ms 1 ms 200 ms 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.net Core Cold start + ENI 8500 ms 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 28
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 Funktionen 33
Best practices 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 Logging 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 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 35
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 Zusammenfassung 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