Ein Unternehmen betreibt einen Essenslieferdienst. Aufgrund des jüngsten Wachstums hat das Auftragsverarbeitungssystem des Unternehmens während der Spitzenverkehrszeiten Skalierungsprobleme. Die aktuelle Architektur umfasst Amazon EC2-Instanzen in einer Auto Scaling-Gruppe, die Bestellungen von einer Anwendung entgegennehmen. Eine zweite Gruppe von EC2-Instanzen in einer Auto Scaling-Gruppe erfüllt die Bestellungen. Der Bestellannahmeprozess erfolgt schnell, aber der Auftragsabwicklungsprozess kann länger dauern. Daten dürfen aufgrund eines Skalierungsereignisses nicht verloren gehen. Ein Solutions Architect muss sicherstellen, dass sowohl der Bestellannahmeprozess als auch der Auftragsabwicklungsprozess während der Spitzenverkehrszeiten angemessen skaliert werden können. Welche Lösung erfüllt diese Anforderungen?

Die korrekte Antwort ist die Verwendung von Amazon SQS-Warteschlangen für beide Prozesse und die Skalierung der Auto Scaling-Gruppen basierend auf der Anzahl der Nachrichten in jeder Warteschlange. SQS entkoppelt die Prozesse, sodass der schnelle Bestellannahmeprozess nicht durch den langsameren Auftragsabwicklungsprozess blockiert wird. Nachrichten gehen nicht verloren, da SQS sie speichert, bis sie verarbeitet werden. Die Skalierung basierend auf der Warteschlangenlänge stellt sicher, dass genügend EC2-Instanzen vorhanden sind, um die Arbeitslast effizient zu verarbeiten, ohne Über- oder Unterskalierung. Die anderen Optionen sind weniger geeignet: Die Einstellung der Mindestkapazität auf den Spitzenwert ist ineffizient und teuer, da die Ressourcen auch außerhalb der Spitzenzeiten vorgehalten werden. Das Erstellen neuer Auto Scaling-Gruppen über SNS ist zu komplex und nicht die vorgesehene Methode zur dynamischen Skalierung bestehender Gruppen. Die Skalierung basierend auf Benachrichtigungen, die die Warteschlangen senden, ist vage; die Anzahl der Nachrichten ist eine spezifischere und effektivere Metrik für die Skalierung.