Die Übersetzung des Artikels wurde speziell für die Studierenden des Kurses erstellt. . Interessiert es Sie, in diesem Bereich weiterzuentwickeln? Sehen Sie sich den Masterclass von Yegor Zuev (TeamLead bei InBit) an, und schließen Sie sich der nächsten Kursgruppe an: Start am 26. September.
Immer mehr Menschen wechseln zu AWS Lambda wegen der Skalierbarkeit, Leistung, Kosteneffizienz und der Möglichkeit, Millionen und sogar Billionen von Anfragen pro Monat zu verarbeiten. Es ist nicht erforderlich, die Infrastruktur zu verwalten, auf der der Dienst läuft. Das automatische Scaling ermöglicht es, Tausende gleichzeitiger Anfragen pro Sekunde zu bedienen. Ich denke, AWS Lambda kann zu Recht als einer der gefragtesten Dienste von AWS betrachtet werden.
AWS Lambda
AWS Lambda ist ein ereignisgesteuertes Serverless-Computing-Service, das die Ausführung von Code ohne Bereitstellung und Verwaltung von Servern ermöglicht und andere AWS-Dienste basierend auf benutzerdefinierter Logik ergänzt. Lambda reagiert automatisch auf verschiedene Ereignisse (sogenannte Trigger), wie HTTP-Anfragen über das Amazon API Gateway, Änderungen an Daten in Amazon S3-Buckets oder in Amazon DynamoDB-Tabellen; alternativ kann Ihr Code über API-Aufrufe ausgelöst werden, indem das AWS SDK und Zustandsübergänge in AWS Step Functions verwendet werden.
Lambda führt den Code auf einer hochverfügbaren Recheninfrastruktur aus und übernimmt vollständig die Verwaltung der zugrunde liegenden Plattform, einschließlich der Wartung von Servern und Betriebssystemen, der Ressourcenzuweisung, der automatischen Skalierung, der Überwachung des Codes und der Protokollierung. Das bedeutet, dass Sie lediglich Ihren Code hochladen und einstellen müssen, wie und wann er ausgeführt werden soll. Der Service kümmert sich in der Folge um den Start und gewährleistet die hohe Verfügbarkeit Ihrer Anwendung.
Wann auf Lambda umsteigen?
AWS Lambda ist eine benutzerfreundliche Rechenplattform, die für viele Anwendungsszenarien geeignet ist, sofern die Programmiersprache und die Laufzeitumgebung Ihres Codes vom Service unterstützt werden. Wenn Sie sich auf Ihren Code und die Geschäftslogik konzentrieren möchten und die Wartung der Server, die Ressourcenzuweisung und die Skalierung einem externen Anbieter zu einem fairen Preis überlassen wollen, sollten Sie definitiv auf AWS Lambda umsteigen.
Lambda eignet sich hervorragend für die Erstellung von Software-Schnittstellen. In Kombination mit dem API Gateway können Sie die Kosten erheblich senken und schneller auf den Markt reagieren. Es gibt verschiedene Möglichkeiten, Lambda-Funktionen einzusetzen und serverlose Architekturen zu gestalten – jeder kann etwas Passendes entsprechend seinen Zielen auswählen.
Lambda ermöglicht die Ausführung einer Vielzahl von Aufgaben. Dank der Unterstützung von CloudWatch können Sie geplante Aufgaben erstellen und bestimmte Prozesse automatisieren. Es gibt keine Einschränkungen bezüglich der Art und Intensität der Service-Nutzung (Speicherverbrauch und Zeit werden hierbei berücksichtigt), sodass Sie problemlos an einem vollwertigen Mikrodienst auf Basis von Lambda arbeiten können.
Hier können serviceorientierte Aktionen erstellt werden, die nicht ständig ausgeführt werden. Ein typisches Beispiel ist das Skalieren von Bildern. Selbst in verteilten Systemen bleibt die Relevanz von Lambda-Funktionen bestehen.
Wenn Sie sich nicht mit der Zuteilung und Verwaltung von Rechenressourcen befassen möchten, sollten Sie AWS Lambda ausprobieren. Wenn Sie keine schweren ressourcenintensiven Berechnungen benötigen, versuchen Sie ebenfalls AWS Lambda. Wenn Ihr Code regelmäßig ausgeführt wird, dann ist AWS Lambda genau das Richtige für Sie.
Sicherheit
Bisher gibt es keine Beschwerden hinsichtlich der Sicherheit. Allerdings verlieren einige allgemein anerkannte Regeln für Cloud-Sicherheit an Bedeutung, da viele interne Prozesse und spezifische Implementierungsmerkmale dieses Modells in der von Nutzern verwalteten Umgebung von AWS Lambda verborgen sind.
Wie die meisten AWS-Dienste erfolgt die Bereitstellung von Lambda im Rahmen des Shared Responsibility Modells von AWS und dem Kunden bezüglich Sicherheit und Compliance. Dieses Prinzip verringert die betriebliche Belastung für den Kunden, da AWS die Aufgaben für Wartung, Administration und Kontrolle der Servicekomponenten übernimmt – von der Betriebssystemebene und der Virtualisierung bis hin zur physischen Sicherheit der Infrastruktur.
Wenn es um AWS Lambda geht, verwaltet AWS die zugrunde liegende Infrastruktur, die zugehörigen Basisdienste, das Betriebssystem und die Anwendungsplattform. Während der Kunde jedoch für die Sicherheit seines Codes, die Speicherung sensibler Daten, den Zugriff auf diese sowie auf den Lambda-Service und die Ressourcen (Identity and Access Management, IAM) verantwortlich ist, einschließlich der verwendeten Funktionen.
Das folgende Diagramm zeigt das Modell der geteilten Verantwortung, das für AWS Lambda gilt. Der Verantwortungsbereich von AWS ist orange markiert, während die Verantwortung des Kunden blau dargestellt ist. Wie Sie sehen können, übernimmt AWS eine größere Verantwortung für Anwendungen, die auf dem Service bereitgestellt werden.
Das Modell der geteilten Verantwortung, das auf AWS Lambda anwendbar ist
Die Lambda-Laufzeitumgebung
Der Hauptvorteil von Lambda besteht darin, dass der Dienst bei der Ausführung einer Funktion in Ihrem Namen selbst die erforderlichen Ressourcen bereitstellt. Sie müssen keine Zeit und Mühe in die Systemadministration investieren, sondern können sich auf die Geschäftslogik und das Codieren konzentrieren.
Der Lambda-Service ist in zwei Ebenen unterteilt. Die erste ist die Steuerungsebene. Laut Wikipedia ist die Steuerungsebene der Teil des Netzwerks, der für die Übertragung von Steuersignalen und das Routing verantwortlich ist. Sie ist das Hauptkomponenten, die globale Entscheidungen über die Zuweisung, Pflege und Verteilung von Arbeitslasten trifft. Darüber hinaus dient die Steuerungsebene als Netzwerk-Topologie des Anbieters, die für das Routing und die Verwaltung des Verkehrs verantwortlich ist.
Die zweite Ebene ist die Datenebene. Sie hat, wie die Steuerungsebene, ihre eigenen Aufgaben. Die Steuerungsebene stellt APIs zur Verfügung, um Funktionen zu verwalten (CreateFunction, UpdateFunctionCode), und steuert die Interaktion von Lambda mit anderen AWS-Diensten. Die Datenebene verwaltet die API-Aufrufe (Invoke API), die Lambda-Funktionen auslösen. Nach dem Aufruf einer Funktion weist die Steuerungsebene entweder eine vorhandene, für diese Funktion vorbereitete Laufzeitumgebung zu oder wählt sie aus und führt dann den Code darin aus.
AWS Lambda unterstützt eine Vielzahl von Programmiersprachen, darunter Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 und andere über die entsprechenden Laufzeitumgebungen. AWS aktualisiert diese regelmäßig, verteilt Sicherheitsupdates und führt andere Wartungsarbeiten an diesen Umgebungen durch. Lambda ermöglicht die Nutzung weiterer Sprachen, sofern Sie die entsprechende Laufzeitumgebung selbst implementieren. In diesem Fall sind Sie dann auch für deren Wartung verantwortlich, insbesondere für die Sicherheit.
Wie funktioniert das alles und wie wird der Service Ihre Funktionen ausführen?
Jede Funktion läuft in einer oder mehreren dedizierten Umgebungen, die nur während des Lebenszyklus dieser Funktion existieren und danach gelöscht werden. In jeder Umgebung wird gleichzeitig nur ein Aufruf ausgeführt, jedoch wird sie wiederverwendet, wenn mehrere serielle Aufrufe derselben Funktion auftreten. Alle Ausführungsumgebungen laufen auf virtuellen Maschinen mit Hardwarevirtualisierung – den sogenannten microVMs. Jede microVM wird einem bestimmten AWS-Konto zugewiesen und kann von Umgebungen mehrfach zur Ausführung verschiedener Funktionen in diesem Konto verwendet werden. MicroVMs sind in die strukturellen Blöcke der Hardwareplattform Lambda Worker integriert, die im Eigentum von AWS stehen und von diesem verwaltet werden. Dieselbe Ausführungsumgebung kann nicht von verschiedenen Funktionen verwendet werden, da microVMs einzigartig für verschiedene AWS-Konten sind.
Isolationsmodell in AWS Lambda
Die Isolierung von Ausführungsumgebungen wird durch mehrere Mechanismen realisiert. Auf der höchsten Ebene befinden sich separate Kopien der folgenden Komponenten in jeder Umgebung:
- Funktionscode
- Alle Lambda-Schichten, die für die Funktion ausgewählt wurden
- Ausführungsumgebung der Funktion
- Minimale Benutzerumgebung auf Basis von Amazon Linux
Zur Isolation verschiedener Ausführungsumgebungen kommen folgende Mechanismen zum Einsatz:
- cgroups – Beschränkung des Zugriffs auf CPU-Ressourcen, Speicher, Speicherbandbreite und Netzwerk für jede Ausführungsumgebung;
- namespaces – Gruppierung von Prozess-IDs, Benutzer-IDs, Netzwerkschnittstellen und anderen Ressourcen, die vom Linux-Kernel verwaltet werden. Jede Ausführungsumgebung arbeitet in ihrem eigenen Namensraum;
- seccomp-bpf – Einschränkung der Systemschnittstellen, die in der Ausführungsumgebung verwendet werden dürfen;
- iptables und Routing-Tabellen – Isolation der Ausführungsumgebungen voneinander;
- chroot – Bereitstellung eines eingeschränkten Zugangs zum zugrunde liegenden Dateisystem.
In Kombination mit den proprietären Isolierungstechnologien von AWS garantieren die genannten Mechanismen eine zuverlässige Abgrenzung der Ausführungsumgebungen. Auf diese Weise isolierte Umgebungen können nicht auf die Daten anderer Umgebungen zugreifen oder diese verändern.
Obwohl mehrere Ausführungsumgebungen eines AWS-Kontos auf einer einzigen microVM betrieben werden können, dürfen microVM unter keinen Umständen von verschiedenen AWS-Konten gemeinsam genutzt werden. Zur Isolierung von microVM in AWS Lambda kommen nur zwei Mechanismen zum Einsatz: EC2-Instanzen und Firecracker. Die Gastisolierung in Lambda auf Basis von EC2-Instanzen wird seit 2015 angewendet. Firecracker ist ein neuer Open-Source-Hypervisor, der speziell von AWS für serverlose Arbeitslasten entwickelt wurde und 2018 vorgestellt wurde. Die physische Hardware, auf der die microVM betrieben werden, wird von Arbeitslasten verschiedener Konten gemeinsam genutzt.
Speichern von Umgebungen und Prozesszuständen
Obwohl die Ausführungsumgebungen von Lambda einzigartig für verschiedene Funktionen sind, kann dieselbe Funktion wiederholt aufgerufen werden, das heißt, die Ausführungsumgebung kann mehrere Stunden bestehen, bevor sie zerstört wird.
In jeder Lambda-Ausführungsumgebung steht ein beschreibbares Dateisystem über das Verzeichnis /tmp zur Verfügung. Der Zugriff auf dessen Inhalt aus anderen Ausführungsumgebungen ist nicht möglich. Bezüglich der Speicherung von Prozesszuständen existieren die in /tmp gespeicherten Dateien während des gesamten Lebenszyklus der Ausführungsumgebung. Dies ermöglicht das Ansammeln von Ergebnissen mehrerer Aufrufe, was besonders nützlich für ressourcenintensive Vorgänge wie das Laden von maschinellen Lernmodellen ist.
Datenübertragung von Aufrufen
Die Invoke API-Schnittstelle kann in zwei Modi genutzt werden: Im Ereignismodul und im Anfrage-Antwort-Modus. Im Ereignismodul wird der Aufruf in eine Warteschlange für die spätere Ausführung eingefügt. Im Anfrage-Antwort-Modus wird die Funktion sofort mit der bereitgestellten Nutzlast aufgerufen, woraufhin eine Antwort zurückgegeben wird. In beiden Fällen wird die Funktion in der Lambda-Umgebung ausgeführt, jedoch mit unterschiedlichen Nutzlastwegen.
Bei Anfrage-Antwort-Calls wird die Nutzlast von einer API zur Anforderungshandhabung (API Caller), wie dem AWS API Gateway oder AWS SDK, an den Load Balancer gesendet und anschließend an den Lambda Aufrufdienst (Invoke Service) weitergeleitet. Letzterer bestimmt die geeignete Laufzeitumgebung zur Ausführung der Funktion und überträgt die Nutzlast dorthin, um den Aufruf abzuschließen. Der Load Balancer empfängt den TLS-geschützten Verkehr über das Internet. Der Verkehr innerhalb des Lambda-Dienstes, nach dem Load Balancer, verläuft durch ein internes VPC in einer bestimmten AWS-Region.
AWS Lambda Aufrufverarbeitungsmodell: Anfrage-Antwort-Modus
Ereignisaufrufe können sofort ausgeführt oder in eine Warteschlange eingereiht werden. In einigen Fällen wird die Warteschlange durch den Amazon SQS-Dienst (Amazon Simple Queue Service) realisiert, der die Aufrufe über einen internen Poller an den Lambda Aufrufdienst überträgt. Der übertragene Verkehr ist TLS-geschützt, wobei keine zusätzliche Datenverschlüsselung für Daten in Amazon SQS vorgesehen ist.
Ereignisbasierte Aufrufe liefern keine Antworten – jegliche Rückmeldungen werden vom Lambda Worker einfach ignoriert. Aufrufe, die auf Ereignissen von Amazon S3, Amazon SNS, CloudWatch und anderen Quellen basieren, werden von Lambda im Ereignismodus verarbeitet. Aufrufe aus Amazon Kinesis und DynamoDB, SQS-Warteschlangen, Application Load Balancer und API Gateway werden im „Request-Response“-Modus bearbeitet.
Überwachung
Sie können die Überwachung und Auditierung Ihrer Lambda-Funktionen mit verschiedenen Mechanismen und AWS-Diensten durchführen, darunter:
Amazon CloudWatch
Erfasst verschiedene Statistiken, wie die Anzahl der Anfragen, die Ausführungsdauer von Anfragen und die Anzahl der Anfragen, die mit einem Fehler endeten.
Amazon CloudTrail
Ermöglicht das Führen von Protokollen, die kontinuierliche Überwachung und das Speichern von Informationen über Aktivitäten in Ihrem Konto, die mit Ihrer AWS-Infrastruktur verbunden sind. Sie erhalten eine vollständige Historie der Aktionen, die über die AWS Management Console, das AWS SDK, Befehlszeilentools und andere AWS-Dienste ausgeführt wurden.
AWS X-Ray
Bietet vollständige Einblicke in alle Phasen der Antragsverarbeitung in Ihrer Anwendung basierend auf einer Karte ihrer internen Komponenten. Ermöglicht die Analyse von Anwendungen während der Entwicklung und im Produktionsumfeld.
AWS Config
Sie können Änderungen an der Konfiguration von Lambda-Funktionen (einschließlich deren Löschung) sowie an Laufzeitumgebungen, Tags, Handlernamen, Codegröße, Speicherkapazität, Timeout-Einstellungen und Parallelisierungsparametern sowie an der IAM-Rolle von Lambda, Subnetzen und Sicherheitsgruppen überwachen.
Fazit
AWS Lambda bietet eine leistungsstarke Sammlung von Tools zur Erstellung sicherer und skalierbarer Anwendungen. Viele der Sicherheits- und Compliance-Methoden in AWS Lambda sind vergleichbar mit denen anderer AWS-Services, obwohl es Ausnahmen gibt. Stand März 2019 erfüllt Lambda die Anforderungen von SOC 1, SOC 2, SOC 3, PCI DSS, dem US-amerikanischen Gesetz über die Kontinuität und Rechenschaftspflicht im Gesundheitswesen (HIPAA) und weiteren Vorschriften. Daher sollten Sie, wenn Sie an die Implementierung einer neuen Anwendung denken, den AWS Lambda-Service in Betracht ziehen - er könnte perfekt für Ihr Projekt geeignet sein.
Quelle: habr.com
