Verkaufsstarts für große Ereignisse wie Konzerte oder Sportveranstaltungen sind immer mit Spannung erwartete Ereignisse. Doch wenn es bei diesen Verkaufsstarts zu Problemen kommt, kann dies für Veranstalter und Kunden gleichermaßen ärgerlich sein. Ein bekanntes Beispiel hierfür ist das Debakel von Ticketmaster bei dem Verkauf von Taylor Swift Tickets für ihre “Eras Tour” letzten November. Aufgrund technischer Probleme war es für Kunden nur schwer möglich Tickets zu kaufen, was zu Frustration und Enttäuschung führte.
Doch wie kam es dazu? Das ist nicht das erste Mal, dass ein System unter zu großer Last zusammenbricht. Black Friday ist hier ein bekanntes Beispiel. Selbst Ticketmaster ist das in der Vergangenheit schon mehrfach passiert. Doch Taylor Swift hat die Aufmerksamkeit darauf noch einmal erhöht und bevorstehende Großevents, wie die Beyoncé Tour, erhöhen die Relevanz weiter. In diesem Blogeintrag werden wir zunächst die Taylor Swift Situation untersuchen, um herauszufinden wie es aus technischer Sicht dazu kommen konnte. Anschließend schauen wir auf mögliche Maßnahmen, die helfen können, um in der Zukunft besser mit solch starken Anstiegen im Traffic umzugehen und Abstürze zu vermeiden.
Was passiert ist
Taylor Swift ist eine der beliebtesten Musikerinnen des letzten Jahrzehnts und ihre Fans haben ihre Rückkehr auf Tournee sehnlichst erwartet. Im Jahr 2022 veröffentlichte sie ein neues Album und kündigte die zugehörige „Eras Tour“ an. Ihre erste seit sechs Jahren. Entsprechend groß war der Andrang auf die Tickets. Der Kartenverkauf erwies sich jedoch für viele als chaotisch und frustrierend, da das System von Ticketmaster unter dem Gewicht einer noch nie dagewesenen Nachfrage überlastet war.
Wie Ticketmaster sich auf den Ansturm vorbereitete
Der Verkauf der Tickets startete am 15. November 2022. Zum Verkauf standen insgesamt 2,4 Millionen Tickets für 52 verschiedene Shows. Aufgrund dieser hohen Zahlen und der großen Bekanntheit von Taylor Swift war schon im Vorhinein klar, dass es einen großen Andrang auf die Tickets geben wird. Um diesen Andrang zu steuern und gleichzeitig Bots und Scalpers vom Kauf der Tickets fernzuhalten wurde das eigens entwickelte System Verified Fans eingesetzt. Ein Konto bei Verified Fan war Voraussetzung, um Tickets erwerben zu können, denn von dort bekam eine begrenzte Anzahl an Fans einen eindeutigen Code, mit dem sie Zugang zum Ticketkaufprozess erhielten. Insgesamt haben sich 3,5 Mio Fans bei Verified Fans angemeldet. Von diesen erhielten am Verkaufstag 1,5 Mio nach Zufallsprinzip einen direkten Zugangscode und die restlichen 2 Mio Fans wurden zu einer Warteschlange hinzugefügt. Auf diese Nachfrage war das System eingestellt.
Thundering Herd stürmt das Ticketmaster System
Zur Überraschung von Ticketmaster wurde die Website am Tag des Kartenverkaufs jedoch von weit mehr Besuchern überschwemmt als erwartet: 14 Millionen versuchten auf die Website zuzugreifen. Deutlich mehr als die geplanten 1,5 Millionen Fans. Der übermäßige Datenverkehr wurde unter anderem durch Bots und Scalpers verursacht, die eigentlich gar keinen Zugang zur Website hätten haben sollen sowie durch Fans, die keinen Code erhalten hatten, aber trotzdem versuchten auf die Website zuzugreifen.
Eben solch eine enorme Menge an Personen, die schlagartig, zur gleichen Zeit Anfragen stellen, wird auch als Thundering Herd bezeichnet. Vorstellen kann man sich das im Prinzip wie eine Horde wildgewordener Stiere, die auf das Ticketmaster System losgeht und es förmlich niederstampft. Das Thundering Herds Problem entsteht, wenn eine Menge an Clients oder Prozessen plötzlich und zur gleichen Zeit auf eine bestimmte Ressource zugreifen wollen. Auf diese schlagartig gestiegene Nachfrage ist die Ressource nicht vorbereitet und kann nicht alle gleichzeitig bearbeiten. Als Folge stürzt sie ab und steht nicht mehr zur Verfügung. Daraus kann als Resultat ein Cascading Failure entstehen, wenn die unbearbeiteten Requests sich auf andere Netzwerkknoten verteilt.
Cascading Failure führt zu Systemfehlern und Abstürzen
Ein Cascading Failure in der IT bezieht sich auf eine Situation, in der ein Fehler in einem Teil des Systems eine Kettenreaktion auslöst, die schließlich zu einem vollständigen Systemausfall führen kann. Auslöser kann der Ausfall eines einzelnen Knotens oder Teilsystems sein, wodurch die Last auf weniger Knoten des verbleibenden Systems verteilt wird. Dadurch steigt die Wahrscheinlichkeit weiterer Systemausfälle, was zu einem Schneeballeffekt führt. Cascading Failures sind äußerst kritisch, da sie einen gesamten Dienst innerhalb kurzer Zeit lahmlegen und menschliches Eingreifen erforderlich machen können.
Eben solch einen plötzlichen Ansturm wie eine Thundering Herd und somit Überlastung des Systems erlebte Ticketmaster. Das führte zu einem Cascading Failure und letztendlich zu Systemfehlern und Abstürzen der Seite. Ein wesentliches Problem war, dass es keine Begrenzung für die Anzahl der angenommenen Requests gab. User konnten immer wieder, während sie noch auf die Antwort zu ihrer ersten Anfrage warteten, ungeduldig weitere Requests schicken, ohne dass diese abgelehnt wurden. Gleichzeitig ließ das Bots freie Hand, sodass unter anderem DDoS Attacken ausgeführt werden konnten. Insgesamt summierte sich die Anzahl an Requests so auf rund 3,5 Milliarden! Das Überstieg den vorherigen Spitzenwert um das Vierfache.
Fans am Boden zerstört, Taylor Swift wütend
Die Auswirkung: das System war völlig überlastet, wodurch es zu verschiedensten Systemfehlern kam. Fans wurden von der Warteliste gestrichen und verloren Tickets, die sich bereits in ihrem Einkaufswagen befanden. Rund 15% der Interaktionen auf der Seite enthielten Fehler. Um das System wieder zu stabilisieren, wurden mehr Fans in Warteschlangen gesetzt. Sie mussten so stundenlange Wartezeiten in Kauf nehmen, um zum Teil am Ende nur eine Fehlermeldung angezeigt zu bekommen. Die Erfahrung war so frustrierend, dass sogar Taylor Swift ihre Verärgerung zum Ausdruck brachte:
“I’m not going to make excuses for anyone because we asked [Ticketmaster], multiple times, if
– Taylor Swift [2]
they could handle this kind of demand and we were assured they could. … It really pisses me
off that a lot of [fans] feel like they went through several bear attacks to get them.”
Doch was kann verbessert werden, dass es nicht noch einmal zu so einer Situation kommt und auf so eine große Nachfrage besser reagiert werden kann?
Wie in Zukunft alle Swifties glücklich werden könnten
Der erste Gedanke, um mit solch einem Traffic Spike umzugehen: Skalieren. Letztendlich braucht es deutlich mehr Kapazitäten, um die Masse an Requests bearbeiten zu können.
1. Horizontales skalieren
Eine Möglichkeit das zu erreichen ist über horizontales Skalieren. Darunter wird die Möglichkeit verstanden, die Anzahl an System Ressourcen gemäß den Kapazitätsansprüchen anzupassen. Im Gegensatz zum vertikalen Skalieren wird die Kapazität nicht über die Verbesserung einzelner Komponenten oder die Erhöhung der Leistungsfähigkeit der vorhandenen Ressourcen verändert. Stattdessen werden zusätzliche Ressourcen, wie zum Beispiel weitere Server oder Computer, hinzugefügt, um die Kapazität eines Systems zu erhöhen. Das horizontale Skalieren bietet insbesondere den Vorteil, dass relativ einfach und schnell zusätzliche Kapazitäten geschaffen werden können, um den Workload zu bearbeiten. Ticketmaster setzt bereits seit 2014 auf Microservices. Daher eignet sich die Infrastruktur gut für eine horizontale Skalierung.
Dabei gibt es zwei Ansätze, wann die Skalierung erfolgen kann:
- Pre-Scaling über eine Kapazitätsplanung:
Mithilfe einer Kapazitätsplanung kann im Voraus festgelegt werden, ob, wann und wie skaliert werden soll. Dadurch kann sichergestellt werden, dass jederzeit genügend Ressourcen zur Verfügung stehen. So kann beispielsweise zu bestimmten Peaks eingeplant werden, dass mehr Rechenkapazität bereitgestellt werden muss. Wichtig hierfür ist, dass bekannt sein muss, wie sich die Nachfrage verhält, um so gezielt zu skalieren.
Ein großes Problem bei dem Ticketmaster Debakel war sicherlich, dass die tatsächliche Load unterschätzt wurde. Es wurde keine ordentliche Kapazitätsplanung durchgeführt. Insgesamt standen zu wenig Rechenkapazitäten zur Verfügung, sodass die Systeme, à la Thundering Herd, förmlich überrannt wurden.
- Auto-Scaling:
Der Nachteil am Pre-Scaling ist, dass die Ressourcen beansprucht werden, auch wenn es doch nicht zu der erwarteten hohen Nachfrage kommt. Entsprechend kann diese Methode kostenintensiv sein. Daher kann stattdessen Auto-Scaling sinnvoll sein. Beim Auto-Scaling wird die zur Verfügung stehende Ressourcenanzahl je nach vorherrschender Nachfrage dynamisch vom System angepasst.
Nachteil am Auto-Scaling ist, dass es nicht in Sekundenschnelle funktioniert. Zwar können kurzfristig automatisch mehr Kapazitäten zur Verfügung gestellt werden, trotzdem braucht es etwas Vorlaufzeit. Gerade bei einem Spike, wie es beim Taylor Swift Kartenverkauf der Fall war, ist so eine Methode zu langsam, um einen Systemabsturz vollends zu verhindern.
Im Fall von Ticketmaster ist eine Mischung aus beiden Skalierungsweisen sinnvoll. Anhand eines passenden Kapazitätsplans sollten genügend Ressourcen eingeplant und zur Verfügung gestellt werden. Sollte diese Annahme dennoch übertroffen werden muss Auto-Scaling ermöglicht sein, um kurzfristig reagieren und auch diese Nachfrage bedienen zu können.
2. Bot Management
Wie bereits beschrieben war ein Grund für die hohe Requestanzahl am 15. November, dass entgegen der Erwartung Bots auf der Seite waren. Präventive Maßnahmen wie der Einsatz des Verified Fan Systems waren also nicht erfolgreich. Ein adäquates Bot Management, um den Bottrafic zu stoppen hätte geholfen.
Ziel des Bot Managements ist es schlechte Bots zu identifizieren, um sie anschließend zu blockieren und so eindämmen zu können. Damit soll der ordnungsgemäße Betrieb des Systems und die Sicherheit der Benutzer und Daten gewährleistet werden. Mögliche Maßnahmen können sein:
- Rate Limiting
Rate Limiting ist ein Verfahren um die Überlastung eines Servers zu verhindern, indem die Anzahl der Anfragen, die ein Client an einen Server sendet, begrenzt wird. Wenn ein Client versucht mehr Anfragen als die festgelegte Rate zu senden, wird die überschüssige Anfrage entweder abgelehnt oder in eine Warteschlange gestellt, bis die Rate wieder unter der Grenze liegt.
Gerade so eine harte Grenze hätte Ticketmaster geholfen, dass es nicht zu den 3,5 Milliarden Requests kommt. Insbesondere als grundlegender Schutz gegen DDoS Attacken wäre der Bot Traffic so deutlich verringert worden.
- Anzeichen für Bot Traffic früh erkennen
Ein Anzeichen kann ein Anstieg an fehlgeschlagenen Logins in User Konten sein, da es eine Art des Angriffes ist User Konten zu übernehmen und mithilfe dieser den Angriff durchzuführen. Für gewöhnlich ist auch ein plötzlicher, starker Anstieg an Traffic ein Anzeichen für einen möglichen Bot Angriff. Allerdings war hier ähnlich wie auch zu Events wie Black Friday sowieso mit einem Traffic Spike zu rechnen. Daher hilft diese Information für den Ticketmaster Fall nicht.
3. Message Queues
Eine weitere Möglichkeit, um die Systeme bei einer Thundering Herd stabil zu halten, ist über den Einsatz einer Message Queue oder auch Warteschlange. Diese dient als Puffer zwischen den Clients und Servern. Die Request werden dort zunächst abgelegt und dann asynchron, sobald Rechenkapazität verfügbar ist, weiterverteilt. Das System kann so Anfragen aus der Queue abarbeiten, ohne dass es durch eine große Anzahl von gleichzeitigen Anfragen überlastet wird.
Zusätzlich bietet eine Queue die Möglichkeit die Anzahl an Anfragen, die ein System annehmen kann, zu begrenzen. Sobald die Queue voll ist, können keine weiteren Anfragen mehr angenommen werden und neue Clients bekommen einen Fehler angezeigt. Warteschlangen hat Ticketmaster bereits eingesetzt. Insbesondere eine harte Grenze hätte jedoch helfen können die Anzahl an Requests, die gleichzeitig zu bearbeiten sind, zu reduzieren und die Thundering Herd abzuschwächen.
4. Caching
Eine weitere Möglichkeit das Thundering Herd Problem abzuschwächen ist Caching einzusetzen, um vielfach verwendete Daten zwischenzuspeichern und somit schneller verfügbar zu machen. Im Falle von Ticketmaster eignen sich insbesondere Meta-Daten über das Event also bspw. wann findet es statt, wer ist der Act, wo findet das Konzert statt.
5. Testen, Testen, Testen
Ein weiterer wichtiger Aspekt ist das Testen. Ein Fehler kann einen Cascading Failure auslösen und zu großen Systemfehlern und Abstürzen führen. Entsprechend ist es wichtig das System und seine Komponenten ordentlich zu testen, um die Wahrscheinlichkeit eines solchen Fehlers möglichst gering zu halten. Dabei gilt es nicht nur die Funktionalität zu prüfen, sondern auch nicht funktionale Aspekte, wie bspw. welcher Load ein System standhalten kann. Insbesondere in Hinblick auf ein geplantes Großevent wie der Verkaufsstart von Taylor Swift Tickets sollte ein System getestet werden, um zu prüfen, ob das System vorbereitet ist. Möglichkeiten ein System auf seine Widerstandsfähigkeit zu prüfen sind dabei:
- Load Testing: Simulieren einer bestimmten Load, um zu prüfen, wie sich das System unter bestimmten Loads verhält. Es werden bspw. Antwortzeiten und Durchsatz des Systems gemessen.
- Scalability Testing: Testen, ob das System fähig ist, sich an verschiedene Loads anzupassen und entsprechend zu skalieren.
- Stress Testing: Überprüfung der Leistungsfähigkeit eines Systems unter extremen Bedingungen, die über die erwartete oder normale Arbeitslast hinausgehen. Im Gegensatz zu Load Testing geht es hier darum die Kapazitätslimits eines Systems aufzudecken.
- Chaos Engineering: Methode, um die Widerstandsfähigkeit eines Systems gegenüber unerwarteten Ereignissen und Fehlern zu verbessern, indem gezielt Chaos eingeführt wird. Es werden kontrolliert Störungen und Fehler ausgelöst, um zu sehen, wie das System auf diese Ereignisse reagiert und ob es in der Lage ist sich selbst wiederherzustellen. Bekanntes Beispiel: Netflix’s Simian Army.
- Monitoring: Die Überwachung der Systeme in Echtzeit, um Probleme, Engpässe oder Schwachstellen frühzeitig identifizieren und entsprechend reagieren zu können.
- Testing in Production: Das Durchführen von Tests in der produktiven Umgebung, um die tatsächliche Leistung und Reaktionsfähigkeit des Systems unter realen Bedingungen zu bewerten. Zwischen speziellen Testumgebungen und der Produktion gibt es oft große Unterschiede. Über das Testen in Produktion können daher Fehler identifiziert werden, die in speziellen Testumgebungen vielleicht nicht entdeckt worden wären. Dieses Zitat bringt es auf den Punkt:
„I’m more and more convinced that staging environments are like mocks – at best a pale imitation of the genuine article and the worst form of confirmation bias. It’s still better than having nothing – but “works in staging” is only one step better than “works on my machine”.“ [13]
Insbesondere Stress Testing und Chaos Engineering hätten bei der Ticketmaster Situation sicherlich geholfen Fehler und potenzielle Bottlenecks im Voraus zu identifizieren. Mit den Testarten lässt sich eine Thundering Herd simulieren und beobachten, wie das System darauf reagiert und ob es sich selbst wiederherstellt. Da genau so eine Stress bzw. Chaos Situation eingetreten ist hätte man über entsprechende Tests sehen können, dass das System auf eine solche Situation nicht vorbereitet ist. So hätte man die Fehler vorher lösen und mit der Thundering Herd klarkommen können. Dabei ist zu empfehlen diese Tests ebenfalls im produktiven System auszuführen, um möglichst nah an den realen Bedingungen zu sein. Denn wenn man es nicht vor dem geplanten Tag in Produktion schafft, wie soll es dann an dem Tag funktionieren?
Lessons Learned für Ticketmaster und Fazit
Die richtige Kapazitätsplanung mit ausgiebigen Stress und Chaos Engineering in produktiven Umgebungen, der direkten Bereitstellung einer Queue mit harter Grenze und der Begrenzung der Requests über Rate Limiting sind wichtige Aspekte die helfen können, um einer Thundering Herd vorzubeugen und diese im Ernstfall abzuschwächen.
Ob Ticketmaster aus dem Debakel mit dem Taylor Swift Kartenverkauf gelernt hat, konnten sie bereits kürzlich unter Beweis stellen. Anfang Februar dieses Jahres kündigte Beyoncé eine neue Tour an. Wie auch Taylor Swift ist sie eine weltweit bekannte und beliebte Sängerin, die zuletzt 2016 auf Tour war. Entsprechend war auch hier mit einer überdurchschnittlich hohen Nachfrage zu rechnen.
Ein großer Unterschied zum vorherigen Kartenverkauf war, dass sich Ticketmaster diesmal dazu entschied, nicht alle Tickets für alle Shows zur gleichen Zeit zum Verkauf freizugeben. Stattdessen wurden die Konzerte je nach Region in drei Gruppen, mit zeitlich versetzten Verkaufsstart eingeteilt. Bei Taylor Swift wurden dagegen zur gleichen Zeit 2,4 Millionen Tickets zu 52 Shows angeboten.
Auch scheint es so, als würden sie diesmal Rate Limiting eingesetzt haben. Ein paar Fans klagten über die Fehlermeldung 403. Ticketmaster gab dazu an, dies eingesetzt zu haben, um „known Bad Traffic“ zu blockieren. Insgesamt wurden so allein im Verkauf für Londoner Konzerttermine 1,5 Mio Requests blockiert. Sobald ein User die Website mehr als einmal innerhalb von 3 Sekunden aktualisiert oder innerhalb von 24 Stunden mehr als 1000 Seiten auf Ticketmasters Website besucht erscheint die 403 Fehlermeldung.
Insgesamt verliefen die Ticketverkäufe deutlich ruhiger als im vergangenen Jahr. Allerdings weiterhin nicht fehlerfrei. Es gab keinen großen Systemzusammenbruch, trotzdem gab es individuell einige Fehlermeldungen und weiterhin längere Wartezeiten.
Es scheint so, als konnte Ticketmaster zumindest zu großen Teilen aus dem Systemzusammenbruch bei Taylor Swift lernen. Trotzdem scheint es noch weiteres Verbesserungspotenzial zu geben.
Etwas Gutes hatte die Sache: in der Zeit, in der die Fans in den Ticketschleifen verweilen mussten, hatten sie sehr viel Zeit kreative neue Memes und Posts zu erschaffen. Hier nur zwei:
Hauptquellen:
[1] TAYLOR SWIFT | THE ERAS TOUR ONSALE EXPLAINED,
https://business.ticketmaster.com/business-solutions/taylor-swift-the-eras-tour-onsale-explained/
(Letzter Zugriff: 24.02.2023)
[2] How Ticketmaster became the most hated name in music, https://www.latimes.com/entertainmentarts/music/story/2023-01-23/ticketmaster-live-nation-taylor-swift-pearl-jam (Letzter Zugriff: 22.02.2023)
[3] The thundering herd — Distributed Systems rate limiting,
https://medium.com/@venkteshsubramaniam/the-thundering-herd-distributed-systems-rate-limiting9128d20e1f00 (Letzter Zugriff: 21.02.2023)
[4] How to Avoid Cascading Failures in Distributed Systems, https://www.infoq.com/articles/anatomycascading-failure/ (Letzter Zugriff: 21.02.2023)
[5] When Taylor Swift crashed Ticketmaster: A lesson on scaling for spikes,
https://learningdaily.dev/when-taylor-swift-crashed-ticketmaster-a-lesson-on-scaling-for-spikes9931e2c888e9 (Letzter Zugriff: 25.02.2023)
[6] How AWS Powered Amazon’s Biggest Day Ever, https://aws.amazon.com/de/blogs/aws/howaws-powered-amazons-biggest-day-ever/ (Letzter Zugriff: 23.02.2023)
[7] Getting Ready for Some Holiday Shopping? So Are the Bots.,
https://www.akamai.com/blog/news/getting-ready-for-some-holiday-shopping-so-are-the-bots (Letzter
Zugriff: 20.02.2023)
[8] Rate limiting — A Good Approach for Scalable System, https://medium.com/geekculture/ratelimiting-a-good-approach-for-scalable-system-45e338b77ffc (Letzter Zugriff: 24.02.2023)
[9] Part 3 — Complete System Design Series,
https://medium.com/coders-mojo/part-3-complete-system-design-series-e1362baa8a4c (Letzter
Zugriff: 24.02.2023)
[10] Spikability – An Application’s Ability to Handle Unknown and/or Inconsistent Load,
https://blog.iron.io/spikability-applications-ability-to/ (Letzter Zugriff: 25.02.2023)
[11] Testing in Production, the safe way,
https://copyconstruct.medium.com/testing-in-production-the-safe-way-18ca102d0ef1 (Letzter Zugriff:
22.02.2023)
[12] How to increase robustness of a large scale system by testing,
https://blog.mi.hdm-stuttgart.de/index.php/2020/02/24/how-to-increase-robustness-of-a-large-scalesystem-by-testing/ (Letzter Zugriff: 26.02.2023)
[13] Tweet von Cindy Sridharan,
https://twitter.com/copyconstruct/status/974530841190608897?ref_src=twsrc%5Etfw%7Ctwcamp%5E
tweetembed%7Ctwterm%5E974530841190608897%7Ctwgr%5E673ea8db29d296e5f2d7c5de16250f
5031317612%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.
html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3D
https3A%2F%2Ftwitter.com%2Fcopyconstruct%2Fstatus%2F974530841190608897image%3Dhttps3
A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fpbs.twimg.com252Fprofile_images2
52F952353315240603648252FEaEy7nw__400x400.jpg26key3Da19fcc184b9711e1b4764040d3dc5c
07 (Letzter Zugriff: 25.02.2023)
[14] Beyoncé tour: UK fans snap up tickets despite Ticketmaster glitches,
https://www.bbc.com/news/entertainment-arts-64533856 (Letzter Zugriff: 26.02.2023)
[15] Why am I seeing a 403 or Forbidden error message?, https://help.ticketmaster.com.au/hc/enau/articles/360006509354-Why-am-I-seeing-a-403-or-Forbidden-error-message- (Letzter Zugriff: 26.02.2023)
Leave a Reply
You must be logged in to post a comment.