- Languages supported
-
Fargate: AWS Fargate ist eine serverlose Rechenengine für Container, die zusammen mit Amazon ECS zur Orchestrierung verwendet wird. Sie unterstützt jede Programmiersprache oder Laufzeitumgebung, die in einen Docker-Container gepackt werden kann. Diese Flexibilität bedeutet, dass Sie praktisch jede Sprache, jedes Framework oder jede Bibliothek verwenden können, die Ihren Anwendungsanforderungen entspricht. Sie könnenPython,Java, GoNode.js, .NETRuby, PHP oder sogar benutzerdefinierte Sprachen und Umgebungen verwenden. Fargate kann sie ausführen, solange sie in einem Container gekapselt sind. Aufgrund dieser umfassenden Sprachunterstützung ist Fargate ideal für die Ausführung verschiedener Anwendungen. Dazu gehören ältere Systeme, mehrsprachige Microservices und moderne Cloud-native Anwendungen.
Lambda: AWS Lambda bietet im Vergleich zu Fargate native Unterstützung für eine begrenzte Anzahl von Sprachen. Lambda-Funktionen wurden speziell für ereignisgesteuerte Workloads entwickelt. Lambda unterstützt offiziell die folgenden Sprachen und Laufzeiten:
-
Node.js
-
Python
-
Java
-
Go
-
Ruby
-
C#
-
PowerShell
Lambda unterstützt auch benutzerdefinierte Laufzeiten. Bei benutzerdefinierten Laufzeiten können Sie Ihre eigene Sprache oder Laufzeitumgebung mitbringen. Dies erfordert jedoch mehr Einrichtung und Verwaltung im Vergleich zur Verwendung nativ unterstützter Optionen. Wenn Sie Ihre Lambda-Funktion von einem Container-Image aus bereitstellen, können Sie Ihre Funktion hineinschreiben. Rust Verwenden Sie ein AWS OS-only Basisimage und nehmen Sie den Rust Runtime-Client in Ihr Image auf. Wenn Sie eine Sprache ohne einen von AWS-bereitgestellten Runtime-Interface-Client verwenden, müssen Sie Ihren eigenen erstellen.
- Event-driven invocation
-
Lambda ist von Natur aus für ereignisgesteuertes Rechnen konzipiert. Lambda-Funktionen werden als Reaktion auf Datenänderungen, Benutzeraktionen oder geplante Aufgaben ausgelöst. Es lässt sich nativ in viele integrieren. AWS-Services Dazu gehören Amazon S3 (z. B. das Aufrufen einer Funktion beim Hochladen einer Datei), DynamoDB (z. B. das Auslösen bei Datenaktualisierungen) und API Gateway (z. B. zur Verarbeitung von HTTP-Anfragen). Die ereignisgesteuerte Lambda-Architektur ist ideal für Anwendungen, die sofort auf Ereignisse reagieren müssen. Diese Anwendungen benötigen keine persistenten Rechenressourcen.
Fargate ist nicht von Haus aus ereignisgesteuert. Mit einer zusätzlichen Standardlogik kann es jedoch in Ereignisquellen wie Amazon SQS und Kinesis integriert werden. Lambda erledigt den Großteil dieser Integrationslogik für Sie. Bei Fargate müssen Sie diese Integration mithilfe der APIs für diese Dienste selbst implementieren.
- Runtime/use cases
-
Fargate ist für die Ausführung von containerisierten Anwendungen konzipiert. Es bietet eine flexible Laufzeitumgebung, in der Sie die CPU-, Speicher- und Netzwerkeinstellungen für Ihre Container definieren können. Fargate arbeitet nach einem containerbasierten Modell. Es unterstützt lang laufende Prozesse, persistente Dienste und Anwendungen mit spezifischen Laufzeitanforderungen. Die Container in Fargate können unbegrenzt ausgeführt werden, da es keine feste Begrenzung der Ausführungszeit gibt. Dies macht es ideal für Anwendungen, die kontinuierlich ausgeführt werden müssen. Mit den Richtlinien für den Container-Neustart in Fargate können einzelne Container innerhalb einer Aufgabe automatisch neu gestartet werden, ohne dass die gesamte Aufgabe neu gestartet werden muss. Dies verbessert die Widerstandsfähigkeit für Workloads mit mehreren Containern. Fargate lässt sich mit CloudWatch Container Insights integrieren und bietet eine verbesserte Beobachtbarkeit. Mit dieser Funktion erhalten Sie detaillierte Kennzahlen und Traces für jeden Container zur Überwachung der Anwendungsleistung.
Lambda-Funktionen sind für kurzlebige, ereignisgesteuerte Aufgaben optimiert. Lambda-Funktionen haben eine maximale Ausführungszeit von 15 Minuten pro Aufruf. Dadurch eignen sich Lambda-Funktionen gut für Szenarien wie Dateiverarbeitung, Datenstreaming in Echtzeit und HTTP-Anforderungsverarbeitung. Diese Aufgaben sind kurz und erfordern keine langwierigen Prozesse.
Mit den dauerhaften Funktionen in Lambda können Sie Workflows mit langer Laufzeit erstellen, deren Zustand über mehrere Aufrufe hinweg bis zu 1 Jahr lang bestehen bleibt. Stabile Funktionen bieten eine integrierte Fehlerbehandlung, automatische Wiederholungsversuche und die Wiederherstellung nach Fehlern. Ein SDK für langlebige Funktionen ist für JavaScript, TypeScript PythonJava, und C# (.NET) verfügbar. Während Wartezeiten wird Ihre Funktion unterbrochen, ohne dass Rechenkosten anfallen. Mit langlebigen Funktionen können Sie Anwendungsfälle bewältigen, für die zuvor persistente Rechenumgebungen erforderlich waren.
Wenn Sie zwischen langlebigen Funktionen und Fargate für lang andauernde Workloads wählen, sollten Sie das Ausführungsmuster berücksichtigen. Dauerhafte Funktionen sind kostengünstig für Workflows, die die meiste Zeit mit Warten verbringen, wie z. B. menschliche Genehmigungen, geplante Verzögerungen oder externe API-Rückrufe. Während der Wartezeiten fallen keine Rechengebühren an. Fargate eignet sich eher für Workloads, die eine kontinuierliche Rechenleistung erfordern, wie z. B. Datenverarbeitung, persistente Netzwerkverbindungen oder Dienste, die ohne Unterbrechung aktiv bleiben müssen.
In Lambda ist die Laufzeitumgebung abstrakter. Sie haben weniger Kontrolle über die zugrunde liegende Infrastruktur. Bei Standardfunktionen ist jeder Aufruf unabhängig und zustandslos. Jeder Status oder alle Daten, die zwischen Aufrufen bestehen bleiben müssen, müssen extern verwaltet werden. Beispiele hierfür sind Datenbanken oder Speicherdienste.
- Scaling
-
Fargate skaliert, indem es die Anzahl der laufenden Aufgaben anpasst. Dies basiert auf dem gewünschten Status, der in Ihrem Container Orchestration Service (Amazon ECS) definiert ist. Die Skalierung kann manuell oder automatisch über Amazon EC2 Auto Scaling erfolgen. Weitere Informationen finden Sie im AWS Containers-Blog unter Unter der Haube: Amazon ECS und Fargate erhöhen die Startraten von Aufgaben.
In Fargate wird jede Aufgabe in ihrer isolierten Umgebung ausgeführt. Bei der Skalierung werden je nach Auslastung zusätzliche Aufgaben gestartet oder gestoppt. Der Amazon ECS Service Scheduler kann bis zu 500 Aufgaben in weniger als einer Minute pro Service starten. Dies gilt für Web- und andere Dienste mit langer Laufzeit. Amazon ECS unterstützt auch prädiktive Skalierung. Es verwendet historische Muster, um proaktiv die Anzahl der Aufgaben zu erhöhen, bevor es zu Nachfragespitzen kommt. Die Richtlinien zur Zielverfolgung der CPU- und Speicherauslastung unterstützen eine metrische Auflösung von 20 Sekunden. Dies ermöglicht eine schnellere Erkennung von Skalierungssignalen. Amazon ECS kann Serviceaufgaben auch automatisch auf mehrere Availability Zones verteilen. Dadurch wird eine hohe Verfügbarkeit gewährleistet. Fargate ist in den AWS
Fault Injection Service (FIS) integriert. Mit FIS können Sie kontrollierte Fehlerinjektionsexperimente durchführen, um die Widerstandsfähigkeit von Anwendungen zu testen.
Bei Lambda ist Parallelität die Anzahl der Anfragen während des Fluges, die Ihre AWS Lambda Funktion gleichzeitig bearbeitet. Dies unterscheidet sich von der Parallelität in Fargate. Jede Fargate-Aufgabe kann gleichzeitige Anfragen verarbeiten, solange Rechen- und Netzwerkressourcen verfügbar sind. Für jede gleichzeitige Anfrage stellt Lambda eine separate Instance Ihrer Ausführungsumgebung bereit. Wenn Ihre Funktionen mehr Anfragen erhalten, skaliert Lambda automatisch die Anzahl der Ausführungsumgebungen. Dies wird so lange fortgesetzt, bis Sie das Limit für die Parallelität Ihres Kontos erreicht haben. Standardmäßig bietet Lambda Ihrem Konto ein Gesamtlimit von 1.000 gleichzeitigen Ausführungen. Dieses Limit gilt für alle Funktionen in einer. AWS-Region Sie können bei Bedarf eine Kontingenterhöhung beantragen.
Bei Lambda Managed Instances funktioniert die Skalierung anders. Anstatt für jede gleichzeitige Anforderung eine neue Ausführungsumgebung bereitzustellen, skalieren Managed Instances asynchron auf der Grundlage der CPU-Ressourcenauslastung. Jede Ausführungsumgebung kann mehrere gleichzeitige Aufrufe verarbeiten. Dieser Ansatz maximiert die Ressourcenauslastung. Er eignet sich gut für stationäre oder vorhersehbare Arbeitslasten.
Für jede Lambda-Funktion, die den Standard-Berechnungstyp verwendet, beträgt die Parallelitätsskalierungsrate 1.000 Ausführungsinstanzen alle 10 Sekunden. Dies setzt sich bis zur maximalen Anzahl gleichzeitiger Konten fort. Weitere Informationen finden Sie unter Lambda-Funktionen skalieren jetzt 12-mal schneller, wenn sie Anfragen mit hohem Volumen im Compute-Blog verarbeiten. AWS Wenn die Anzahl der Anfragen in einem Zeitraum von 10 Sekunden 1.000 übersteigt, werden die zusätzlichen Anfragen gedrosselt. Das folgende Diagramm zeigt, wie die Lambda-Skalierung unter Annahme einer Kontenparallelität von 7000 funktioniert.
- Cold start and cold-start mitigation
-
Bei Lambda-Funktionen kann es zu Kaltstarts kommen. Diese treten auf, wenn eine Funktion aufgerufen wird, nachdem sie einige Zeit inaktiv war. Bei einem Kaltstart initialisiert der Lambda-Dienst eine neue Ausführungsumgebung. Dazu gehören das Laden der Laufzeit, der Abhängigkeiten und des Funktionscodes. Die Kaltstartdauer variiert je nach Laufzeit, Paketgröße und Initialisierungslogik zwischen unter 100 Millisekunden und über 1 Sekunde. Bei Laufzeiten mit längeren Initialisierungszeiten wie Java oder C# können Kaltstarts ohne Optimierung länger dauern. Kaltstarts können die Leistung von Anwendungen beeinträchtigen, die Antworten mit niedriger Latenz erfordern.
Um Kaltstarts in Lambda zu verhindern, sollten Sie die folgenden Strategien in Betracht ziehen:
-
Funktionsgröße minimieren: Reduzieren Sie die Größe Ihres Funktionspakets und seiner Abhängigkeiten. Dies kann die für die Initialisierung benötigte Zeit verkürzen.
-
Erhöhen Sie die Speicherzuweisung: Höhere Speicherzuweisungen erhöhen die CPU-Kapazität. Dies kann die Initialisierungszeit verkürzen.
-
Funktionen warm halten: Rufen Sie Ihre Lambda-Funktionen regelmäßig auf (z. B. mithilfe von CloudWatch Events). Dadurch bleiben sie aktiv und die Wahrscheinlichkeit von Kaltstarts wird verringert.
-
Lambda SnapStart: Verwenden Sie die Funktionen Lambda SnapStart forJava,Python, und .NET, um die Startzeit zu reduzieren. SnapStart erstellt einen Snapshot der initialisierten Ausführungsumgebung. Nachfolgende Aufrufe werden vom Snapshot aus fortgesetzt, anstatt einen vollständigen Kaltstart durchzuführen.
-
Bereitgestellte Parallelität: Diese Funktion hält eine bestimmte Anzahl von Funktionsinstanzen warm und bereit, Anfragen zu bearbeiten. Dadurch wird die Kaltstart-Latenz reduziert. Es erhöht jedoch die Kosten. Sie zahlen für die bereitgestellten Instanzen, auch wenn sie Anfragen nicht aktiv bearbeiten.
-
Lambda Managed Instances: Führen Sie Funktionen auf einer Vielzahl von EC2-Instance-Typen aus. Dazu gehören Prozessoren wie Netzwerkoptionen Graviton4 mit hoher Bandbreite. Pre-provisioned Ausführungsumgebungen machen Kaltstarts überflüssig. Lambda kümmert sich um den Instanzlebenszyklus, Betriebssystem- und Laufzeit-Patches, Routing, Lastenausgleich und automatische Skalierung. Lambda Managed Instances unterstützen auch mehrere gleichzeitige Aufrufe pro Ausführungsumgebung. Sie bieten EC2-Preisvorteile wie Compute Savings Plans und Reserved Instances.
Fargate ist im Allgemeinen nicht auf die gleiche Weise von Kaltstarts betroffen wie Lambda. Die Zeit zum Starten einer Fargate-Aufgabe korreliert direkt mit der Zeit, die benötigt wird, um die in der Aufgabe definierten Container-Images aus der Image-Registrierung abzurufen. Fargate unterstützt auch das verzögerte Laden von Container-Images, die mit Seekable OCI (SOCI) indexiert wurden. Das verzögerte Laden von Container-Images mit SOCI reduziert die Zeit zum Starten von Amazon ECS-Aufgaben auf Fargate. Fargate verwendet das SOCI-Index-Manifest v2. Dies bietet eine verbesserte Leistung beim verzögerten Laden. Nachdem eine Aufgabe auf Fargate gestartet wurde, handelt es sich um einen Prozess mit langer Laufzeit. Es ist immer bereit, Anfragen zu bearbeiten. Wenn Sie als Reaktion auf Skalierungsereignisse neue Aufgaben starten müssen, kann es bei der Initialisierung zu Verzögerungen kommen. Dies ist im Vergleich zu Lambda-Kaltstarts in der Regel weniger signifikant.
- Memory and CPU options
-
Fargate bietet eine granulare Kontrolle über Speicher- und CPU-Ressourcen für Ihre containerisierten Anwendungen. Wenn Sie eine Aufgabe in Fargate starten, können Sie die genauen CPU- und Speicheranforderungen für Ihre Anwendung angeben. Die CPU- und Speicherzuweisungen sind unabhängig. Sie können Kombinationen wählen, die am besten zu Ihrer Arbeitslast passen. Sie können CPU-Werte zwischen 0,25 vCPUs und 32 vCPUs auswählen. Der Arbeitsspeicher reicht je nach Konfiguration zwischen 0,5 GB und 244 GB pro Aufgabe.
Diese Flexibilität ist ideal für Anwendungen mit bestimmten Leistungsmerkmalen. Beispiele hierfür sind speicherintensive Datenbanken oder CPU-bound Rechenaufgaben. Fargate ermöglicht es Ihnen, Ihre Ressourcenzuweisung zu optimieren. Sie können Kosten und Leistung effektiv in Einklang bringen.
In Lambda sind Speicher und CPU miteinander verbunden. Die CPU wird automatisch proportional zu der von Ihnen ausgewählten Speichermenge zugewiesen. Sie können Speicherzuweisungen zwischen 128 MB und 10 GB in Schritten von 1 MB wählen. Die CPU skaliert mit dem Arbeitsspeicher auf bis zu 6 vCPUs. Höhere Speichereinstellungen führen zu mehr CPU-Leistung. Sie haben jedoch keine direkte Kontrolle über die CPU-Zuweisung selbst.
Dieses Modell ist auf Einfachheit ausgelegt. Sie können die Speichereinstellungen schnell anpassen, ohne die CPU-Konfigurationen verwalten zu müssen. Es ist jedoch möglicherweise weniger flexibel für Arbeitslasten, die ein bestimmtes Gleichgewicht zwischen CPU- und Speicherressourcen erfordern. Das Lambda-Modell eignet sich für Aufgaben, bei denen Sie eine einfache Skalierung auf der Grundlage des Speicherbedarfs wünschen. Es ist möglicherweise nicht optimal für Anwendungen mit komplexen oder hochspezifischen Ressourcenanforderungen.
- Networking
-
Wenn Sie Aufgaben in Fargate bereitstellen, werden diese in einer Amazon VPC (Amazon Virtual Private Cloud) ausgeführt. Dadurch haben Sie die volle Kontrolle über die Netzwerkumgebung. Sie können Sicherheitsgruppen, Netzwerkzugriffskontrolllisten (ACLs) und Routingtabellen konfigurieren. Jede Fargate-Aufgabe erhält ihre eigene Netzwerkschnittstelle mit einer dedizierten privaten IP-Adresse. Sie können bei Bedarf eine öffentliche IP-Adresse zuweisen.
Fargate unterstützt erweiterte Netzwerkfunktionen wie Load Balancing (mithilfe von AWS Elastic Load Balancing), VPC-Peering und direkten Zugriff auf andere Funktionen AWS-Services innerhalb der VPC. Sie können auch AWS PrivateLink für sichere, private Verbindungen zu unterstützten Geräten verwenden. AWS-Services Dadurch wird vermieden, dass das Internet durchquert wird. Fargate-Aufgaben unterstützen auch Amazon VPC Lattice. Dies bietet standardisierte Konnektivität, Sicherheit und Beobachtbarkeit von Service zu Service. Fargate-Aufgaben können in Konfigurationen ausgeführt werden. IPv6-only Dadurch können Aufgaben ausschließlich über IPv6 kommunizieren.
Standardmäßig werden Lambda-Funktionen in einer verwalteten Netzwerkumgebung ausgeführt. Sie haben keine direkte Kontrolle über Netzwerkschnittstellen oder IP-Adressen. Lambda kann jedoch mithilfe von Hyperplane an eine vom Kunden verwaltete VPC angeschlossen werden. AWS Auf diese Weise können Sie den Zugriff auf Ressourcen in Ihrer VPC kontrollieren.
Wenn Lambda-Funktionen an eine vom Kunden verwaltete VPC angehängt werden, erben sie die VPC-Sicherheitsgruppen und Subnetzkonfigurationen. Dadurch können sie sicher mit anderen AWS-Services
(z. B. RDS-Datenbanken) innerhalb derselben VPC interagieren. Da Lambda skaliert wird, indem es viele Umgebungen zur gleichzeitigen Ausführung erstellt, unterhält jede Umgebung ihre eigene Datenbankverbindung. Bei hoher Parallelität können die Grenzwerte für Datenbankverbindungen ausgeschöpft werden. Verwenden Sie für den relationalen Datenbankzugriff Amazon RDS Proxy, um Verbindungen zu bündeln und zu verwalten. Dadurch wird eine Erschöpfung der Verbindungen bei hoher Parallelität vermieden.
Der Lambda-Service verwendet eine Plattform zur Virtualisierung von Netzwerkfunktionen, um NAT-Funktionen bereitzustellen. Dadurch wird die Lambda-VPC mit Kunden-VPCs verbunden. Es konfiguriert die erforderlichen elastischen Netzwerkschnittstellen (ENIs), wenn Lambda-Funktionen erstellt oder aktualisiert werden. Es ermöglicht auch, ENIs aus Ihrem Konto in mehreren Ausführungsumgebungen gemeinsam zu nutzen. Dadurch kann Lambda Netzwerkressourcen effizienter nutzen, wenn Funktionen skaliert werden.
ENIs sind eine erschöpfbare Ressource mit einem weichen Limit von 250 pro Region. Überwachen Sie die Nutzung der elastischen Netzwerkschnittstelle, wenn Sie Lambda-Funktionen für den VPC-Zugriff konfigurieren. Lambda-Funktionen in derselben AZ und derselben Sicherheitsgruppe können ENIs gemeinsam nutzen. Wenn Sie die Grenzwerte für Parallelität in Lambda erhöhen, prüfen Sie, ob Sie eine Erhöhung der elastischen Netzwerkschnittstelle benötigen. Wenn das Limit erreicht ist, werden Aufrufe von VPC-enabled Lambda-Funktionen gedrosselt.
- Pricing model
-
Die Fargate-Preisgestaltung basiert auf den Ressourcen, die Ihren Containern zugewiesen sind. Konkret bedeutet dies die vCPU und den Arbeitsspeicher, die Sie für jede Aufgabe auswählen. Die Abrechnung erfolgt pro Sekunde, wobei eine Mindestgebühr von einer Minute anfällt. Die Kosten hängen direkt von den Ressourcen ab, die Ihre Anwendung verbraucht. Sie zahlen für das, was Sie bereitstellen, unabhängig davon, ob die Anwendung aktiv Anfragen verarbeitet. Fargate eignet sich gut für vorhersehbare Workloads, bei denen Sie bestimmte Ressourcenkonfigurationen benötigen. Sie können die Kosten optimieren, indem Sie die zugewiesenen Ressourcen anpassen. Fargate Spot ist sowohl für x86- als auch für ARM-based Linux-Workloads verfügbar. Dies bietet erhebliche Kosteneinsparungen für fehlertolerante Anwendungen. Für verwandte Dienste können zusätzliche Gebühren anfallen. Dazu gehören Datenübertragung, Speicherung und Netzwerke (z. B. VPC, Elastic Load Balancing).
Lambda hat eine andere Preisstruktur, die ereignisgesteuert ist und pro Ausführung bezahlt wird. Die Gebühren richten sich nach der Anzahl der Anfragen und der Ausführungsdauer. Die Dauer wird in Millisekunden gemessen. Lambda berücksichtigt auch die Menge an Speicher, die Sie Ihrer Funktion zuweisen. Die Kosten skalieren auf der Grundlage des verwendeten Speichers und der Ausführungszeit. Das Preismodell beinhaltet eine kostenlose Stufe. Es bietet 1 Million kostenlose Anfragen und 400.000 GB-seconds Rechenzeit pro Monat. Dadurch ist Lambda besonders kostengünstig für sporadische Workloads mit geringem Volumen.
Das Lambda-Preismodell ist ideal für Anwendungen mit unvorhersehbaren oder sprunghaften Datenverkehrsmustern. Sie zahlen nur für die tatsächlichen Funktionsaufrufe und die Ausführungszeit. Sie müssen keine ungenutzten Kapazitäten bereitstellen oder dafür bezahlen.
Mit Lambda Managed Instances bietet Lambda eine instanzbasierte Preisgestaltung, die EC2-Preismodelle verwendet. Dazu gehören Reserved Instances On-Demand und Compute Savings Plans. Dies kann die Kosteneffizienz bei stationären oder vorhersehbaren Workloads steigern.
Sowohl Fargate als auch Lambda kommen für Compute-Sparpläne in Frage. https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html Diese können die Kosten um bis zu 66% senken, wenn Sie sich dafür verpflichten, die Rechenleistung konstant zu nutzen. Dies wird in Dollar pro Stunde für eine Laufzeit von 1 oder 3 Jahren gemessen.
Wenn Sie die Kosten der beiden Dienste vergleichen, zahlen Sie bei Lambda bei geringerem Verkehrsaufkommen in der Regel weniger. Die Abrechnung der Ressourcen pro Sekunde von Fargate ist jedoch bei anhaltenden Workloads mit hohem Durchsatz tendenziell wirtschaftlicher. Wenn das Anforderungsvolumen wächst, skalieren die Lambda-Kosten linear. Im Gegensatz dazu bleiben die Fargate-Kosten unabhängig von den Anfragen, die innerhalb der bereitgestellten Ressourcen bearbeitet werden, relativ stabil.
