Hallo und willkommen zurück.
Im heutigen Video werden wir die Architektur der Skalierung auf der Basis von Amazon SKUs auf einer
hohen Ebene besprechen.
In vielen Unternehmen korreliert die Anzahl der EC2-Instanzen, die in der Produktionsumgebung
ausgeführt werden, direkt mit der Anzahl der Nachrichten, die Teil der Rettung sind.
Nehmen wir an, es befinden sich zehn Nachrichten in der US-Warteschlange, und da zwei EC-2-Instanzen
laufen, kümmert sich jede EC-2-Instanz um die Verarbeitung von fünf Nachrichten und lädt die Artefakte nach der
Verarbeitung in den S3-Bucket hoch.
Nehmen wir an, morgen findet ein großer Verkauf statt, und in den USA gibt es statt zehn Nachrichten 10.000
Nachrichten.
Da sich in der Warteschlange eine große Anzahl von Nachrichten befindet, gibt es nun zwei Möglichkeiten.
Erstens haben Sie nur zwei einfach zu bedienende Instanzen und die Verarbeitung von 10.000 Nachrichten wird viel Zeit in Anspruch
nehmen.
Das ist also die erste Option.
Die zweite Möglichkeit besteht darin, die Anzahl der EC two-Instanzen, die in der Produktionsumgebung laufen,
zu erhöhen, sagen wir von 2 auf 20.
Wenn jetzt also 20 zwei Instanzen laufen, werden 10.000 Nachrichten viel schneller verarbeitet.
Die Erhöhung der Anzahl der EC-2-Instanzen führt jedoch auch zu einer Erhöhung der Kosten.
Jetzt, nach Abschluss des Verkaufs, ist die Anzahl der Nachrichten in der Warteschlange von 10.000 auf zehn zurückgegangen.
Was Sie jetzt tun müssen, ist, die zusätzliche EG zu beenden.
Zwei Instanzen, die wir betreiben, um die Gesamtkosten zu senken.
In der Produktionsumgebung möchten Sie nun eine solche Architektur implementieren, bei der zwei EC-Instanzen auf
der Grundlage der Anzahl der Nachrichten in der Warteschlange gestartet und beendet werden.
Und in der Tat werden Sie in vielen Organisationen sehen, dass eine solche Art von Architektur implementiert wird.
Schauen wir uns also kurz an, was alles getan werden muss, um diese Art von
Architektur zu erreichen.
Wenn Sie eine Gruppe mit automatischer Skalierung verwenden, können Sie diese so konfigurieren, dass die beiden einfachen Instanzen
je nach der Anzahl der Nachrichten, die Teil der Rettung sind, gestartet oder beendet werden.
Dies lässt sich anhand dieses Diagramms erklären, in dem Sie eine Anwendung haben, die die Anzahl
der Nachrichten in der Warteschlange liest und die Daten in Cloud Watch speichert.
Abhängig von den Daten in Cloud Watch startet die automatische Skalierung entweder eine neue Gruppe von Instanzen oder sie beendet
die zusätzliche Gruppe von Instanzen, die wir gerade betreiben.
Nun stellt sich die Frage, woher diese spezielle Anwendung weiß, wie viele Nachrichten sich in der Rettungsphase
befinden.
Und die Antwort darauf ist eine der sechs Attributspalten, die ungefähre Anzahl der Nachrichten.
Lassen Sie uns also einen kurzen Blick darauf werfen.
Für die heutige Demo habe ich eine Rettungsaktion und zwei Nachrichten, die zur Verfügung stehen.
Wenn wir also die Rettung öffnen, erhalten wir die URL der Warteschlange.
Anhand dieser URL können Sie dann überprüfen, wie viele Nachrichten vorhanden sind.
Lassen Sie uns also einen kurzen Blick darauf werfen.
Ich habe also einen CLI-Befehl, der uns acht uns get attributes nennt, wir geben die URL der Warteschlange hier drüben an und wir geben
den Attributnamen an und der Name des Attributs hier ist die ungefähre Anzahl der Nachrichten.
Das ist dem, was wir besprochen haben, sehr ähnlich, und die Region ist AP Südost.
Wenn ich jetzt kurz die Eingabetaste drücke, sehen Sie, dass die Anzahl der angezeigten Nachrichten zwei ist. Das ist dasselbe,
was die Anwendung tun kann, und sie kann es an einen zentralen Dienst veröffentlichen, von dem aus die automatische
Skalierung die Instanzen nach Bedarf starten und beenden wird.
Dies ist also eines der Architekturdesigns, die implementiert werden können, wenn Sie einen Anwendungsfall haben, bei dem Sie Instanzen
auf der Grundlage der Anzahl von Nachrichten starten und beenden möchten.
Damit endet unser heutiges Video.