Überlegungen zum Design

Optionen für die Bereitstellung

Wenn dies die erste Installation ist oder Sie sich nicht sicher sind, was Sie installieren sollen, stellen Sie die virtual-waiting-room-on-aws-getting-started.template verschachtelte CloudFormation Vorlage bereit, die den Kern, die Autorisierer und die Beispielvorlagen für Wartezimmer installiert. Dies bietet Ihnen einen minimalen Wartezeitraum mit einem einfachen Ablauf.

Unterstützte Protokolle

Die AWS Lösung Virtual Waiting Room on kann in Folgendes integriert werden:

• JSONBibliotheken und Tools zur Überprüfung von Web-Tokens

• Bestehende API Gateway-Bereitstellungen

• RESTAPIKunden

• OpenID-Kunden und Anbieter

Strategien für den Zutritt zum Wartezimmer

Inlet-Strategien beinhalten die Logik und die Daten, die erforderlich sind, um Kunden vom Wartezimmer zur Website zu bewegen. Eine Inlet-Strategie kann als Lambda-Funktion, Container, EC2 Amazon-Instance oder jede andere Rechenressource implementiert werden. Es muss sich nicht um eine Cloud-Ressource handeln, solange sie den Warteraum als öffentlich und privat APIs bezeichnen kann. Bei der Inlet-Strategie werden Ereignisse über den Wartebereich, die Website oder andere externe Indikatoren erfasst, anhand derer entschieden werden kann, wann mehr Kunden Tokens ausgeben lassen und die Website betreten können. Es gibt verschiedene Ansätze für Inlet-Strategien. Welchen Sie wählen, hängt von den Ihnen zur Verfügung stehenden Ressourcen und den Einschränkungen bei der Gestaltung der zu schützenden Website ab.

Die wichtigste Maßnahme der Inlet-Strategie besteht darin, das increment_serving_num Amazon API Gateway als privat zu bezeichnen, API wobei ein relativer Wert angegeben wird, der angibt, wie viele weitere Kunden die Site betreten können. In diesem Abschnitt werden zwei Beispiele für Inlet-Strategien beschrieben. Diese können unverändert oder kundenspezifisch verwendet werden, oder Sie können einen völlig anderen Ansatz verwenden.

MaxSize

Mithilfe der MaxSize Strategie wird die MaxSizeInlet Lambda-Funktion mit der maximalen Anzahl von Clients konfiguriert, die die Website gleichzeitig nutzen können. Dies ist ein fester Wert. Ein Kunde gibt eine SNS Amazon-Benachrichtigung aus, die die MaxSizeInlet Lambda-Funktion aufruft, um den Bereitstellungszähler basierend auf der Nachrichtennutzlast zu erhöhen. Die Quelle der SNS Nachricht kann aus einer beliebigen Quelle stammen, z. B. aus Code auf der Website oder aus einem Überwachungstool, das den Nutzungsgrad der Website beobachtet.

Die MaxSizeInlet Lambda-Funktion erwartet den Empfang einer Nachricht, die Folgendes beinhalten kann:

• exited :Anzahl der abgeschlossenen Transaktionen

• Liste der AnfragenIDs, die als abgeschlossen markiert werden sollen

• Liste der AnträgeIDs, die als aufgegeben markiert werden sollen

Anhand dieser Daten wird bestimmt, um wie viel der Servierzähler erhöht werden muss. Es kann vorkommen, dass aufgrund der aktuellen Anzahl von Clients keine zusätzliche Kapazität zur Erhöhung des Zählers zur Verfügung steht.

Regelmäßig

Bei Verwendung der periodischen Strategie ruft eine CloudWatch Regel jede Minute die PeriodicInlet Lambda-Funktion auf, um den Servierzähler um eine feste Menge zu erhöhen. Der periodische Eingang wird mit der Startzeit, der Endzeit und der Inkrementmenge des Ereignisses parametrisiert. Wahlweise überprüft diese Strategie auch einen CloudWatch Alarm. Wenn sich der Alarm im OK Status befindet, wird das Inkrement ausgeführt, andernfalls wird es übersprungen. Die Standortintegratoren können eine Nutzungsmetrik mit einem Alarm verbinden und diesen Alarm verwenden, um die regelmäßige Eingabe zu unterbrechen. Bei dieser Strategie wird die Bereitstellungsposition nur geändert, solange die aktuelle Uhrzeit zwischen der Start- und Endzeit liegt, und optional befindet sich der angegebene Alarm im OK Status.

Anpassung und Erweiterung der Lösung

Der Site-Administrator Ihres Unternehmens muss entscheiden, welche Integrationsmethoden für den Warteraum verwendet werden sollen. Es gibt zwei Optionen:

1. Grundlegende Integration direkt mithilfe von APIs API Gateway-Autorisierern.

2. OpenID-Integration über einen Identitätsanbieter.

Zusätzlich zu der oben genannten Integration müssen Sie möglicherweise die Domainnamenumleitung konfigurieren. Sie sind auch für die Bereitstellung einer maßgeschneiderten Webseite für Wartezimmer verantwortlich.

Die AWS Lösung Virtual Waiting Room on ist so konzipiert, dass sie durch zwei Mechanismen erweitert werden kann: EventBridge für die unidirektionale Benachrichtigung über Ereignisse und REST APIs für die bidirektionale Kommunikation.

Kontingente

Die primäre Skalierungsbeschränkung für Virtual Waiting Room on AWS ist die Lambda-Drosselgrenze für die installierte AWS Region. Bei der Installation in einem AWS Konto mit dem standardmäßigen Lambda-Kontingent für gleichzeitige Ausführung kann die Virtual Waiting Room AWS On-Lösung bis zu 500 Clients pro Sekunde verarbeiten, die eine Position in der Warteschlange anfordern. Die Rate von 500 Clients pro Sekunde basiert auf der Lösung, bei der alle gleichzeitigen Quotenlimits für alle Lambda-Funktionen exklusiv verfügbar sind. Wenn die Region im Konto mit anderen Lösungen geteilt wird, die Lambda-Funktionen aufrufen, sollte der virtuelle Warteraum auf der AWS Lösung mindestens 1.000 gleichzeitige Aufrufe verfügbar sein. Mithilfe von CloudWatch Kennzahlen können Sie die gleichzeitigen Lambda-Aufrufe in Ihrem Konto im Zeitverlauf grafisch darstellen und so eine Entscheidung treffen. Sie können die Service Quotas Quotas-Konsole verwenden, um Erhöhungen zu beantragen. Durch die Erhöhung des Lambda-Drossellimits werden die monatlichen Kontogebühren nur dann erhöht, wenn tatsächlich zusätzliche Aufrufe erfolgen.

Erhöhen Sie Ihr Drossellimit für jede weitere 500 Clients pro Sekunde um 1.000.

Eingehende Benutzer pro Sekunde werden erwartet	Empfohlenes Kontingent für gleichzeitige Ausführung
0-500	1.000 (Standard)
501-1.000	2.000
1.001-1.500	3,000

Lambda hat ein festes Burst-Limit von 3.000 gleichzeitigen Aufrufen. Weitere Informationen finden Sie unter Lambda-Funktionsskalierung. Der Client-Code sollte einige API Aufrufe erwarten und erneut versuchen, wenn ein Fehlercode zurückgegeben wird, der auf eine vorübergehende Drosselung hinweist. Der Beispielclient für Wartezimmer enthält diesen Code als Beispiel für das Entwerfen von Clients, die bei Ereignissen mit hoher Kapazität und hohen Auslastungsraten eingesetzt werden.

Diese Lösung ist auch mit reservierter und bereitgestellter Lambda-Parallelität mit benutzerdefinierten Konfigurationsschritten kompatibel. Einzelheiten finden Sie unter Managing Lambda Reserved Concurrency.

Die Obergrenze für Benutzer, die den Warteraum betreten, ein Token erhalten und mit einer Transaktion fortfahren können, ist durch die Obergrenze der Elasticache-Zähler (OSSRedis) begrenzt. Die Zähler werden für die Bereitstellungsposition im Wartezimmer und für die Erfassung des Gesamtstatus der Lösung verwendet. Die in Elasticache (RedisOSS) verwendeten Zähler haben eine Obergrenze von 9.223.372.036.854.775.807. Eine DynamoDB-Tabelle wird verwendet, um eine Kopie jedes Tokens zu speichern, das an einen Benutzer im Wartezimmer ausgegeben wurde. DynamoDB hat keine praktische Beschränkung für die Größe einer Tabelle.

Regionale Bereitstellungen

Die von dieser Lösung verwendeten Dienste werden in allen AWS Regionen unterstützt. Die aktuelle Verfügbarkeit von AWS Diensten nach Regionen finden Sie in der Liste der AWS regionalen Dienste.