Von Esra Kayabali am 13. Juli 2026
Am 13. Juli 2006 haben wir Amazon Simple Queue Service (Amazon SQS) als einen der ersten drei Dienste für Kunden gestartet, zusammen mit Amazon EC2 und Amazon S3. Aus eigener Erfahrung hatten wir gelernt, dass verteilte Systeme eine zuverlässige Möglichkeit benötigen, Nachrichten zwischen Komponenten auszutauschen, ohne enge Abhängigkeiten zu schaffen. Wenn ein Dienst einen anderen direkt aufrief und dieser langsam oder nicht verfügbar war, breiteten sich Fehler kaskadenartig im gesamten System aus. Message Queuing löste dieses Problem, indem es Diensten eine asynchrone Kommunikation ermöglichte: Ein Produzent konnte eine Nachricht in eine Warteschlange einstellen und fortfahren, während ein Konsument sie bei Bedarf abholte. Dieser Ansatz verhinderte, dass einzelne Dienstausfälle den Rest des Systems beeinträchtigten.
Als Amazon SQS im Juli 2006 öffentlich gestartet wurde, machte es dieses Muster für jeden AWS-Kunden verfügbar. Zwanzig Jahre später ist diese Kernfunktion – das Entkoppeln von Produzenten und Konsumenten – nach wie vor der Grund, warum Kunden SQS nutzen. Die Skalierung, Leistung und die betrieblichen Steuerungsmöglichkeiten sehen heute jedoch ganz anders aus.
Jeff Barr behandelte die ersten 15 Jahre der SQS-Meilensteine in seinem Beitrag zum 15. Jubiläum, von der ursprünglichen Nachrichtengrößenbegrenzung von 8 KB im Jahr 2006 über FIFO-Warteschlangen, serverseitige Verschlüsselung bis hin zur Lambda-Integration. In den letzten fünf Jahren haben wir SQS weiter skaliert, stärkere Sicherheitsstandards eingeführt und neue Funktionen bereitgestellt, die immer komplexere Workload-Muster unterstützen.
Wichtige Meilensteine zwischen 2021 und 2026
Im Mai 2021 starteten wir den Hochdurchsatzmodus für FIFO-Warteschlangen in der allgemeinen Verfügbarkeit und unterstützten damit bis zu 3.000 Transaktionen pro Sekunde (TPS) pro API-Aktion – eine Verzehnfachung des vorherigen Limits. In den folgenden zwei Jahren erhöhten wir diese Obergrenze kontinuierlich: auf 6.000 TPS im Oktober 2022, auf 9.000 TPS im August 2023 und auf 18.000 TPS im Oktober 2023, bevor wir im November 2023 in ausgewählten Regionen 70.000 TPS pro API-Aktion erreichten.
Im November 2021 führten wir die serverseitige Verschlüsselung mit von Amazon SQS verwalteten Schlüsseln (SSE-SQS) ein und boten Kunden damit eine Verschlüsselungsoption, die keine Schlüsselverwaltung erforderte. Im Oktober 2022 machten wir SSE-SQS zur Standardeinstellung für alle neu erstellten Warteschlangen, sodass Kunden sie nicht mehr explizit aktivieren mussten.
Wir erweiterten schrittweise die Möglichkeiten, wie Kunden nicht verarbeitete Nachrichten aus Dead-Letter-Warteschlangen wiederherstellen können. Im Dezember 2021 fügten wir das DLQ-Redrive zurück zur Quell-Warteschlange direkt in der SQS-Konsole hinzu. Im Juni 2023 erweiterten wir diese Funktion auf das AWS SDK und die CLI durch neue APIs, einschließlich StartMessageMoveTask, CancelMessageMoveTask und ListMessageMoveTasks. Im November 2023 fügten wir die Redrive-Unterstützung für FIFO-Warteschlangen hinzu.
Im November 2022 führten wir ABAC ein und gaben Kunden die Möglichkeit, Zugriffsberechtigungen basierend auf Warteschlangen-Tags zu konfigurieren, anstatt statische Richtlinien bei skalierenden Ressourcen pflegen zu müssen.
Im November 2023 ergänzten wir die Unterstützung des JSON-Protokolls im AWS SDK, was die Ende-zu-Ende-Nachrichtenverarbeitungslatenz um bis zu 23 % für eine 5-KB-Nutzlast reduzierte und die clientseitige CPU- und Speichernutzung senkte.
Wir fügten die Möglichkeit hinzu, eine Warteschlange direkt aus der SQS-Konsole mit EventBridge Pipes zu verbinden, um Nachrichten ohne benutzerdefinierten Integrationscode an eine breite Palette von AWS-Servicezielen weiterzuleiten.
Wir brachten die zuvor nur für Java verfügbare Extended Client Library für Python-Entwickler heraus, sodass Nachrichten bis zu 2 GB über SQS gesendet werden können, indem die Nutzlast in Amazon S3 gespeichert und eine Referenz durch die Warteschlange geleitet wird.
Wir erhöhten das Limit für In-Flight-Nachrichten bei FIFO-Warteschlangen von 20.000 auf 120.000 Nachrichten, sodass Verbraucher deutlich mehr Nachrichten gleichzeitig verarbeiten können, ohne durch die vorherige Obergrenze eingeschränkt zu sein.
Wir führten faire Warteschlangen ein, um das Problem des „lauten Nachbarn“ in Multi-Tenant-Standardwarteschlangen zu mildern. Durch die Angabe einer Nachrichtengruppen-ID beim Senden von Nachrichten können Kunden verhindern, dass ein einzelner Mandant die Zustellung für andere verzögert, ohne dass Änderungen auf der Verbraucherseite erforderlich sind.
Wir erhöhten die maximale Nachrichtennutzlast von 256 KiB auf 1 MiB für Standard- und FIFO-Warteschlangen, um Kunden das Senden größerer Nachrichten zu ermöglichen, ohne Daten in externe Speicher auslagern zu müssen. Die AWS Lambda-Eventquellenzuordnung für SQS wurde parallel aktualisiert, um die neue Nutzlastgröße zu unterstützen.
Die Konstante im Wandel
Trotz zwei Jahrzehnten an Funktionserweiterungen hat sich der grundlegende Anwendungsfall von SQS nicht verändert. Kunden nutzen den Dienst, um Services zu entkoppeln, Verkehrsspitzen zu puffern und Systeme zu bauen, die auch beim Ausfall einzelner Komponenten widerstandsfähig bleiben. Dasselbe Muster gilt nun auch für KI-Workloads. Kunden verwenden SQS-Warteschlangen, um Anfragen an große Sprachmodelle zu puffern, den Inferenzdurchsatz zu verwalten und die Kommunikation zwischen autonomen KI-Agenten zu koordinieren, die als unabhängige Dienste arbeiten. Ein Beispiel für diese Architektur in der Praxis finden Sie unter „Erstellen asynchroner KI-Agenten mit Amazon Bedrock“.
Um mehr über Amazon SQS zu erfahren, besuchen Sie die Amazon SQS-Produktseite, lesen Sie den Entwicklerleitfaden oder entdecken Sie aktuelle Neuigkeiten in den AWS-Blogs.
— Esra
Esra Kayabali ist Principal Solutions Architect bei AWS und spezialisiert auf Analytik, einschließlich Data Warehousing, Data Lakes, Big Data Analytics, Batch- und Echtzeit-Datenströme sowie Datenintegration. Sie verfügt über mehr als zehn Jahre Erfahrung in der Softwareentwicklung und Lösungsarchitektur. Sie engagiert sich leidenschaftlich für kollaboratives Lernen, Wissensaustausch und begleitet die Community auf ihrem Weg in die Cloud-Technologien.
Kommentare werden geladen …
