Upload
duonghanh
View
228
Download
0
Embed Size (px)
Citation preview
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
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/
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
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/
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
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
40