Wir wurden kontaktiert, um ein Tuning für die Leistung in einer großen AWS-Umgebung durchzuführen.
Es wird verwendet, um die Serverseite einer mobilen Anwendung für eine Fernsehsendung zu hosten, die es den Zuschauern ermöglicht, während der Sendung über verschiedene Fragen abzustimmen. Da die Sendung nur einmal pro Woche ausgestrahlt wird, ist dies ein perfekter Anwendungsfall für eine On-Demand-Cloud-Umgebung, die nur während der Sendung betrieben wird und nach deren Ende alle VMS heruntergefahren oder zerstört werden. Auf diese Weise werden die Kosten auf ein Minimum reduziert, und es besteht keine Notwendigkeit, dafür ständig teure private physische Server in einem privaten Rechenzentrum vorzuhalten.
DIE HERAUSFORDERUNG
Die Belastung durch die Gesamtheit der Zuschauer, die meist zwischen 200 000 und 300 000 liegt, und die eine Minute lang parallel über eine bestimmte Frage abstimmen müssen. Dies könnte eine ernsthafte Herausforderung für das System darstellen.
DIE LÖSUNG
Mit Chefkoch und AWS OpsWorks wird die Umgebung innerhalb weniger Minuten, einige Stunden vor der Show, gestartet. Dank der ausgeklügelten Automatisierung ist die Umgebung hoch skalierbar und die Anzahl der Maschinen kann je nach erwarteter Belastung angepasst werden. So haben wir insgesamt 15 HAProxies, 30 Webserver, auf denen die Django-Anwendungen laufen, dann ein Dutzend Cache-Server mit Memcached und AWS Aurora und DynamoDB für die Datenspeicherung sowie den auf Redis basierenden ElasticCache-Dienst von Amazon Web Services. Es gibt bestimmte Funktionen, die asynchron ausgeführt werden können, und dafür werden RabbitMQ und Celery verwendet. Alle Bilder und statischen Inhalte werden in S3 gehalten.
Data Dog Agents sammeln wertvolle Daten für die Leistungsoptimierung der Maschinen.
Der HA-Proxy-Ausgleich basiert auf den DNS-Round-Robin-Funktionen (DNS RR) von Route 53, wobei jeder HAProxy mit demselben A-Eintrag und einer eindeutigen DNS RR-Set-ID definiert ist. Beispiel:
Dieser erste Satz von Screenshots zeigt Sitzungsdaten von zwei verschiedenen HAProxies, die in derselben Sekunde aufgenommen wurden. Wenn Sie auf die Sitzungsdaten Cur (aktuelle Anzahl) achten, können Sie sehen, wie ungleichmäßig die Verbindungen zwischen den HAProxies verteilt sind.
Proxy 2: sehr belastet (~377 Sitzungen pro Webserver)
Proxy 3: überhaupt nicht: Sitzungen Cur : 0-3
Wenn wir uns das Diagramm in der Datadog-Überwachung über die Zeit ansehen, ist dies auch deutlich sichtbar. Jede Farbe steht für eine einzelne HAProxy-Sitzungsanzahl. Es scheint, dass AWS Route 53 auf eine seltsame Art und Weise ausbalanciert, indem es die erste Proxy-IP an * ALLE* Clients sendet und dann nach einigen Sekunden die zweite IP an alle Clients. Daher landen alle Clients am Ende für einen bestimmten Zeitraum auf demselben HAProxy. Sie werden im Laufe der Zeit ausgeglichen, aber die Spitzen häufen sich nur auf einem einzigen HAProxy, der anfällig für Überlastung ist.
Da die Backend-Grenzwerte dynamisch von der Chef-Konfigurationsverwaltung nach folgender Formel berechnet werden:
(websrv_instance_type_coeficient / count_of_haproxies)
In diesem Fall schadet eine größere Anzahl von HAProxies eher, da die maximalen Verbindungen pro Backend reduziert werden, da das System davon ausgeht, dass sich die Summe aller Backend-Limits der HAProxies summiert, wenn die Verbindungen richtig ausgeglichen sind. Im Fall der ungleichmäßigen AWS DNS RR können wir jedoch jeweils nur einen HAProxy verwenden. Dies birgt das Risiko, dass das Backend-Limit pro Proxy erreicht wird.
Da bei den von uns durchgeführten Lasttests eine andere Art von Datensatz verwendet wird, bei der ein einzelner A-Datensatz alle Ziel-IPs enthält und der Client dann eine auswählt und sich mit dieser verbindet, konnten wir dies nicht reproduzieren. Laut AWS-Dokumentation gibt es jedoch eine Beschränkung auf bis zu 8 IPs.
F: "Unterstützt Amazon Route 53 mehrere Werte in der Antwort auf DNS-Anfragen?"
A: "Route 53 unterstützt jetzt Antworten mit mehreren Werten als Antwort auf DNS-Abfragen. Die Möglichkeit, mehrere überprüfbare IP-Adressen als Antwort auf DNS-Abfragen zurückzugeben, ist zwar kein Ersatz für einen Load Balancer, aber eine Möglichkeit, DNS zur Verbesserung der Verfügbarkeit und des Lastausgleichs zu nutzen. Wenn Sie den Datenverkehr nach dem Zufallsprinzip an mehrere Ressourcen, wie z. B. Webserver, weiterleiten möchten, können Sie für jede Ressource einen mehrwertigen Antwortdatensatz erstellen und optional jedem Datensatz eine Amazon Route 53-Gesundheitsüberprüfung zuordnen. Amazon Route 53 unterstützt bis zu acht gesunde Datensätze als Antwort auf jede DNS-Anfrage."
DIE SCHLUSSFOLGERUNG
Wir schlagen als ersten Schritt vor:
→ Reduzieren Sie die Anzahl der laufenden HAProxies während einer Show auf maximal 8, am besten vier. Auf diese Weise sind die Grenzwerte pro Backend und Proxy höher, selbst wenn die Kunden auf demselben Proxy landen. Den Daten zufolge sind die Proxy-Maschinen selbst nicht stark belastet und können mehr Anfragen verarbeiten. Die einzige Einschränkung ist die Begrenzung der aktiven TCP-Verbindungen auf etwa 65000 TCP-Sitzungen pro HAProxy, d. h. 4 sollten problemlos 200 000 offene Verbindungen abdecken.
→ Umstellung auf die Verwendung eines einzigen DNS-Eintrags mit mehrwertigen Antworten. Dies wurde mit Lasttests getestet und zeigt eine bessere Verteilung der Anfragen.
Verfügbarkeit, Skalierbarkeit und Kosteneffizienz klingen wie die perfekte Kombination?
Möchten Sie eine hoch skalierbare On-Demand-Cloud-Umgebung, die Ihnen hilft, Ihre Kosten auf ein Minimum zu reduzieren, ohne dass Sie ständig teure physische Server in einem privaten Rechenzentrum vorhalten müssen?
Als langfristige Lösung:
→ Umstellung auf ELB - Elastic Load Balancer, der einen echten Lastausgleich vornimmt.
Wir haben die Korrektur zur Umstellung auf Multivalue-DNS implementiert; außerdem haben wir sichergestellt, dass die Berechnung der Grenzwerte der Proxys die Möglichkeit einer ungleichmäßigen Verteilung der Anfragen aufgrund des DNS-Round-Robin-Mechanismus berücksichtigt. Nach unseren Korrekturen/Hilfen liefen die nächsten Sendungen wirklich reibungslos, und die Produzenten erhielten keine Beschwerden mehr von den Zuschauern darüber, dass sie nicht abstimmen konnten. Das war ein tolles Gefühl nach all dem Schweiß, den wir in diese Leistungsoptimierung gesteckt haben.
Entdecken Sie die Dienstleistungen von ITGix und erfahren Sie mehr über unser Know-how.