© zffoto/Shutterstock.com
Migration nach AWS – Teil 7

Optimierungen für Serverless-Anwendungen


In den vorangehenden sechs Teilen dieser Serie haben wir uns mit der schrittweisen Optimierung einer Anwendung hin zu einer Serverless-Architektur, der Verschlüsselung von Daten und Optimierungen für Container beschäftigt. In diesem abschließenden Teil der Serie werfen wir einen Blick auf mögliche Optimierungen für AWS-Lambda-Funktionen mit dem Ziel, die Sicherheit, Zuverlässigkeit und Performance zu erhöhen sowie die Kosten zu senken.

Im Folgenden möchten wir betrachten, wie wir unsere serverlose Architektur aus dem vierten Artikel ganz konkret hinsichtlich Geschwindigkeit, Durchsatz, Zuverlässigkeit und Kosten optimieren können. Auch in serverlosen Architekturen gibt es in der Regel noch Konfigurationseinstellungen, die wir für unseren konkreten Workload überprüfen und optimieren sollten. In den folgenden Absätzen werden wir jeden Service unserer Architektur betrachten und mögliche Optimierungen diskutieren.

Optimierung unseres API Gateway

Wie in Teil 4 bereits dargestellt, besitzt das Amazon API Gateway [1] drei unterschiedliche Ausprägungen:

  • Edge-optimized (Standard): Zu bevorzugen, sollten unsere Kunden in Europa oder weltweit verteilt sein. Durch die verwaltete Integration mit Amazon CloudFront [2] werden Daten nah bei unseren Kunden für den schnellen Zugriff zwischengespeichert und der Netzwerkpfad ist mittels des Amazon-Netzwerk-Backbone optimiert.

  • Regional: Zu bevorzugen, wenn unsere Kunden nur aus einem begrenzten Einzugsbereich kommen (z. B. Deutschland) und wir unser Amazon API Gateway nah oder innerhalb dieses Einzugsbereichs bereitstellen können (z. B. Frankfurt). Ein weiterer Grund kann sein, dass wir volle Kontrolle über die Amazon-CloudFront-Distribution benötigen, um sie selbst konfigurieren zu können.

  • Private: Zu bevorzugen, sollte unser API nur intern aus bestimmten Amazon VPCs [3] aufrufbar sein.

Die Wahl der Ausprägung hat einen Einfluss auf die Kosten unseres API Gateways und die Latenz des Aufrufs.

Mit der Nutzung des Amazon API Gateway profitieren wir ohne zusätzliche Kosten vom automatischen Schutz durch AWS Shield Standard [4]. AWS Shield Standard bietet Schutz vor den am häufigsten vorkommenden Infrastrukturangriffen (Ebenen 3 und 4) wie SYN/UDP-Floods, Reflexionsangriffe und andere. Durch deren Abwehr wird eine hohe Verfügbarkeit Ihrer Anwendungen unter AWS sichergestellt. Um einen noch höheren Schutz vor Angriffen zu erhalten, können wir gegen zusätzliche Kosten AWS Shield Advanced in Verbindung mit einer Amazon-CloudFront-Distribution nutzen.

Amazon API Gateway bietet auch eine Integration mit der AWS WAF [5]. Diese Web Application Firewall erlaubt es, uns sehr effektiv vor gängigen Cross-Site-Scripting- oder SQL-Injection-Angriffen aus dem Web zu schützen. Darüber hinaus erlaubt es uns die AWS WAF, bestimmte IP-Adressbereiche oder CIDR-Blöcke auszuschließen (Blacklisting) oder nur bestimmte zuzulassen (Whitelisting).

Explizit soll hier auch nochmal auf die Möglichkeit hingewiesen werden, dass das Amazon API Gateway eine direkte Integration mit anderen AWS Services anbietet. Sollte unsere AWS-Lambda-Funktion keine Geschäftslogik beinhalten und die Anfragen nur an die Amazon DynamoDB weiterleiten, können wir auf diese AWS-Lambda-Funktion verzichten [6] und das Amazon API Gateway den Service aufrufen lassen. Das reduziert unsere Latenz und spart Kosten.

Standardmäßig drosselt das Amazon API Gateway Zugriffe auf 10 000 Requests pro Sekunde [7]. Sollten wir eine solche Last nicht erwarten bzw. sollte unser Backend diese Last nicht handeln können, sollten wir diese Konfiguration auf einen angemessenen Wert reduzieren. Hier haben wir die Möglichkeit, Limits auf unseren Stages (unterschiedliche Versionen unseres API) oder noch feingranularer auf Methodenebene zu definieren. Das ist sinnvoll, da zum Beispiel unsere signup-Methode viel seltener aufgerufen wird als eine Abfrage auf eine Resource. Das erhöht die Ausfallsicherheit unseres API aufgrund einer Überlastung unseres Backends.

Diese Limitierungen machen keine Unterscheidung, von wem der Aufruf kommt. Sollten wir die Anforderung besitzen, bestimmte Kunden möglichst gar nicht zu drosseln (z. B. weil sie ein Premiumabonnement besitzen), dann kommen API Keys ins Spiel. Dabei definieren wir Nutzungspläne, die wir mit Aufruflimits versehen. Diese Limits können wir wieder auf Ebene unseres API, einer Stage oder einzelner Methoden definieren. Wir legen geringere Limits für unsere Basiskunden und höhere für unsere Premiumkunden fest. Im Anschluss erzeugen wir für unsere Kunden API Keys, die wir mit den entsprechenden Nutzungsplänen verknüpfen.

Auf der AWS re:invent 2019 wurde das neue Amazon API Gateway HTTP API vorgestellt [8], das, verglichen mit dem REST API, noch einen reduzierten Funktionsumfang hat, aber eine geringere Latenz besitzt und circa 70 Prozent geringere Kosten verursacht. Über die nächsten Monate werden bekannte Funktionen aus dem Amazon API Gateway REST API auch für das HTTP API zur Verfügung gestellt. Also sollte man immer mal wieder vorbeischauen.

Optimierung unserer Funktionen

Nicht neu für uns ist, dass sich die Größe unserer Funktion und deren Abhängigkeiten direkt auf die Dauer der ersten Ausführung unserer Lambda-Funktion auswirkt, den so genannten Kaltstart. Darüber hinaus können aber auch die Wahl der Frameworks, die Wiederverwendung...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang