Bei CrowdHandler treffen wir oft auf Menschen, die sich zum ersten Mal auf hohen Besucherverkehr vorbereiten. Manchmal brauchen sie eigentlich nur einen Warteraum.
Oft richten sie jedoch auch zum ersten Mal Server und Lastenausgleich ein – und sind sehr daran interessiert, diese Themen mit uns zu besprechen.
Ohne nun allzu abweisend klingen zu wollen: Das ist nicht das Hauptanliegen unseres Produkts. Für uns spielt das keine große Rolle, da unser Produkt unabhängig davon ist, welche Architektur hinter dem „Wartezimmer“ steckt. Unser Hauptanliegen ist die Transaktionsrate, die unsere Kunden verarbeiten können.
Tatsächlich ist es selten sinnvoll, die Kapazitäten so weit zu erhöhen, dass sie das Zehnfache des üblichen Datenverkehrs bei gelegentlichen Spitzenauslastungen bewältigen können. Je besser Ihre Website jedoch optimiert ist, desto kürzer werden die Wartezeiten sein.
Die meisten Webentwickler haben durchaus respektable Karrieren, ohne jemals an etwas wirklich Populärem gearbeitet zu haben. Daher sind sie überrascht, wenn sie feststellen, dass viele der vermeintlichen Best-Practice-Empfehlungen den Kontakt mit der Realität nicht überstehen.
Unsere Fachkompetenz haben wir ursprünglich durch die Entwicklung hochverfügbarer Websites für große Medien- und Unterhaltungsmarken erworben. Daher verfügen wir über einiges an Wissen zur Skalierung von Websites. Wir wissen, was wirklich funktioniert und was nicht.
Was keine Rolle spielt
Anzahl der Anwendungsserver
Möglicherweise wechseln Sie von einem Shared-Server zu einem dedizierten Server. Vielleicht wechseln Sie sogar von einem dedizierten Server zu mehreren Servern hinter einem Load Balancer (sei es bei einem herkömmlichen Hosting-Anbieter oder einem Cloud-Dienst wie AWS).
Tatsächlich kommt es nur selten vor, dass Anwendungsserver bis an ihre Belastungsgrenze ausgereizt sind, daher ist diese Zahl nicht besonders aussagekräftig.
Die Bearbeitung von JavaScript-, PHP- oder .NET-Aufgaben zur Erstellung von HTML oder JSON ist einfach nicht besonders ressourcenintensiv. Selbst ein einzelner Server kann schon eine ganze Menge Datenverkehr bewältigen.
In der Regel werden Anwendungsserver aus Redundanzgründen skaliert (um Anfragen auch dann zu bedienen, wenn ein Server ausfällt). In Szenarien mit hohem Datenaufkommen verbringen Anwendungsserver meist den Großteil ihrer Zeit damit, auf etwas anderes zu warten – häufig auf eine Datenbank oder eine API (die als Remote-Datenbank fungiert).
Ein Anwendungsserver stürzt in der Regel ab, wenn ihm während des Wartens auf Antworten von vorgelagerten Systemen die ausgehenden Verbindungen ausgehen. Zehn Anwendungsserver, die alle beim Warten auf dieselbe Datenbankabfrage oder denselben API-Aufruf hängen bleiben, sind dabei keine große Hilfe.
Hinzufügen von CPUs zu Ihrem Datenbank-Server (DB-Server)
Heißt das also, dass man sich zuerst den Datenbankserver ansehen sollte?
Der Begriff „Cluster“ wird oft leichtfertig verwendet, aber solange Sie kein Sharding in Ihre Anwendung integriert haben (schauen Sie sich das einmal an), können Sie nicht einfach zusätzliche Datenbankserver hinzufügen, um die Leistung zu skalieren.
Sicher, Sie könnten auf einen leistungsstärkeren Datenbank-Server mit mehr CPU-Kernen umsteigen. Allerdings belasten die meisten modernen Anwendungen die Datenbank nicht besonders stark mit CPU-Rechenleistung. Die Abfragen, die Sie ausbremsen, werden oft durch die Festplattengeschwindigkeit (E/A) begrenzt – insbesondere in ausgefeilten Cloud-Umgebungen, in denen sich Ihr Datenbankspeicher wer weiß wo befindet und man E/A-Drosselung leicht übersehen kann, bis man sich wirklich damit auseinandersetzen muss. Dann stellen Sie fest, wie teuer echte E/A-Leistung sein kann.
Festplatten-E/A hinzufügen
Wenn Sie die Ausführungszeiten von Abfragen auf Ihrem DB-Server untersuchen, werden Sie feststellen, dass eine Aufstockung der CPU-Leistung und der Festplatten-E/A zwar etwas helfen mag, aber nicht ausreicht, um zu verhindern, dass die Website unter Last zusammenbricht. Eine Verdopplung oder gar Vervierfachung Ihrer Datenbankspezifikationen wird Ihre Website nicht wie durch Zauberhand retten.
Warum nicht? In der Regel liegt es daran, dass Ihre Abfragen schlecht optimiert sind – oft werden sie von einem beliebten, aber ineffizienten Framework generiert – und nicht richtig indiziert werden. Durch die Verwendung der richtigen Indizes könnten Ihre Abfragen bis zu 1.000 Mal schneller ausgeführt werden. Das ist wesentlich kostengünstiger, als 1.000 Mal mehr für Ihren DB-Server auszugeben.
„Unbegrenzte“ Skalierbarkeit in der Cloud
Klingt einfach: Einfach auf eine Schaltfläche klicken, um mehr Ausführungen/Prozesse/Hamster zu erhalten.
Aber selbst wenn Sie all diese Konfigurationen perfekt hinbekommen und mit den Kosten einverstanden sind: Wenn Sie auf Transaktionen angewiesen sind (was bei den meisten Websites der Fall ist), werden Sie in der Transaktionsphase an einen Engpass stoßen – sei es in Ihrer Datenbank (transaktionale Datenbanken lassen sich nicht unbegrenzt skalieren; schauen Sie nach) oder bei einem Drittanbieter-Dienst wie einer Zahlungs-API (diese basieren ebenfalls auf transaktionalen Datenbanken mit Ratenbeschränkungen).
Was wirklich zählt
Die Landing Page zwischenspeichern
Du weißt doch, diese eine Seite, die jeder auf Instagram und so weiter teilen wird?
Im Cache speichern.
Verschwenden Sie keine Serverressourcen, indem Sie dieselbe Seite hunderttausend (oder millionenfach) neu generieren. Wenn es sich um eine dynamische Seite handelt, machen Sie sie statisch – oder zumindest teilweise statisch. Fügen Sie eine Schaltfläche für einen separaten Call-to-Action-Schritt hinzu, falls Nutzer Bestandsdaten oder andere dynamische Daten laden müssen.
Sie sind sich nicht sicher, auf welcher Seite die Nutzer am häufigsten landen? Finden Sie es heraus. Das sind entscheidende Daten. Passen Sie Ihre Cache-Einstellungen an und nutzen Sie einen Reverse-Proxy (wie Varnish) oder ein CDN (wie Cloudflare) – oder stellen Sie sogar eine komplett statische Datei über den Webserver bereit. Entwickler mögen diese Lösung vielleicht nicht, aber für Websites, die Millionen von Zugriffen erwarten, macht das Caching 80 % der Arbeit aus.
Verwenden Sie ein CDN (Content Delivery Network)
Ein CDN ist eine hochentwickelte, verteilte Caching-Ebene. Auch wenn die vollständige Optimierung schwierig sein kann, ist der Einstieg ganz einfach. Glauben Sie, dass CDNs nur dazu dienen, statische Dateien weltweit zu verteilen?
Nicht ganz. Viele der Websites mit dem höchsten Traffic nutzen heutzutage ein CDN, ganz gleich, wie „dynamisch“ sie auch erscheinen mögen. Tatsächlich basiert dieses Prinzip auf Frameworks wie Next.js/Vercel, die auf diese Weise bemerkenswerte Leistungswerte erzielen. Das ist jedoch nichts Neues – Fernsehsender, E-Commerce- und Ticketverkaufsseiten nutzen CDNs schon seit langem, noch bevor Sie geboren wurden. Neue Frameworks optimieren lediglich diesen Ansatz. Zu den CDN-Optionen gehören unter anderem:
- Cloudflare: Preiswert, beliebt und einfach zu konfigurieren.
- CloudFront: Ist Teil von AWS und bietet praktische Vorteile, wenn Sie Ihre Website dort hosten.
- Akamai: Einer der Pioniere, der von vielen großen Online-Shops genutzt wird.
Nutzen Sie den Warteraum
Die meisten Websites unterliegen Transaktionsbeschränkungen, die sich nicht einfach durch Skalierung umgehen lassen. Selbst große Anbieter wie Ticketmaster nutzen Warteschlangen bei Verkaufsspitzen – und das, obwohl sie über zahlreiche Server verfügen. Beginnen Sie damit, alles zu zwischenspeichern, was sich zwischenspeichern lässt, und richten Sie dann einen Warteraum für die wirklich dynamischen Teile ein. Das ist ein besserer erster Schritt, als Server willkürlich zu skalieren, in der Hoffnung, die Nachfrage zu befriedigen.
Richten Sie einen Warteraum ein, legen Sie eine Transaktionsrate fest, von der Sie wissen, dass Sie sie bewältigen können, und beobachten Sie Ihre Website unter Spitzenauslastung, um reale Engpässe zu erkennen – diese finden sich oft im Slow-Query-Protokoll Ihrer Datenbank oder in den API-Antwortzeiten. Möglicherweise lassen sich Skalierungsprobleme schon allein durch das Hinzufügen eines Indexes zu einer Tabelle beheben. Und Sie lernen aus dem tatsächlichen Traffic-Verhalten, nicht aus theoretischen Lasttests oder Vermutungen.
CrowdHandler
In Situationen mit hohem Datenverkehr ist nicht endloses Skalieren die effektivste Strategie, sondern ein intelligentes Ressourcenmanagement. Warteräume spielen dabei eine entscheidende Rolle.
CrowdHandler ist auf die Bereitstellung flexibler, einfach zu integrierender virtueller Warteräume spezialisiert, die Ihnen helfen, Zeiten mit hohem Kundenaufkommen zu bewältigen.
Melden Sie sich noch heute für eine kostenlose Testversion an.