2023: Der Ruhm ist nur 11 MB/s entfernt

 (thmsmlr.com)
2 Punkte von GN⁺ 2024-04-08 | 1 Kommentare | Auf WhatsApp teilen
  • Selbst Websites in den Top 1000 mit rund 200 Millionen Besuchen pro Monat benötigen für HTML allein nur etwa 30 TB/Monat, also im Schnitt 11 MB/s Übertragungsrate – ein Umfang, den ein einzelner Server bewältigen kann
  • Die Rechnung basiert auf Business Insider mit 2 Seiten pro Besuch, 400 Millionen HTML-Dokumenten pro Monat und komprimiertem HTML von etwa 75 KB, unter der Annahme, dass JS, CSS und Bilder über ein CDN ausgeliefert werden
  • Edge-Ausführung hat zwar den Vorteil nutzernaher Server, aber wenn beim Rendern Datenbank-Roundtrips anfallen, wird die Latenz wieder zum Standort der Ursprungsdatenbank zurückgezogen
  • Auch die Kosten unterscheiden sich stark: Hetzner bietet Server mit 16 Kernen, 64 GB RAM und NVMe für $0.34/Stunde sowie nach 20 TB Freivolumen $1.5/TB, während AWS und Vercel deutlich höhere Bandbreitenpreise haben
  • Wenn keine besondere Cloud-Anforderung besteht, ist eine Konfiguration aus einzelnem Server + SQLite + Litestream + CDN einfacher und günstiger und vermeidet unnötige horizontale Skalierung

Die tatsächliche Größenordnung einer Top-Website bei 11 MB/s

  • Als Beispiel für eine Website aus den Top 1000 wird Business Insider verwendet
    • Laut SimilarWeb lag die Seite weltweit auf Rang 587 und hatte etwa 200 Millionen Besucher pro Monat
    • Bei durchschnittlich 2 Seiten pro Besuch müssen pro Monat 400 Millionen HTML-Dokumente ausgeliefert werden
    • Auf Basis eines Beispielartikels ist ein standardmäßiges HTML-Dokument nach Komprimierung etwa 75 KB groß
    • Multipliziert ergibt das für HTML allein einen Bandbreitenbedarf von etwa 30 TB/Monat
  • 30 TB/Monat entsprechen im Durchschnitt etwa 11 MB/s
    • Im Fall von Business Insider entspricht das ungefähr 150 Requests/Sekunde
    • Dabei wird angenommen, dass für HTML kein CDN verwendet wird, während JS, CSS und Bilder über ein CDN ausgeliefert werden können
    • Komprimiertes HTML mit 75 KB ist eher groß; je nach Implementierung kann man also die HTML-Größe reduzieren oder die Zahl der Requests erhöhen
  • Auf moderner Hardware ist die Erzeugung von 11 MB/s HTML durch Anwendungscode eine niedrige Hürde
    • Aktuelle AMD-Serverprozessoren bieten 64 Kerne und 128 Threads
    • Beim Zen 5 Turin Serverprozessor gibt es Gerüchte über 192 Kerne; bei Dual-Socket-Servern werden Konfigurationen mit fast 400 Kernen und bis zu 768 Threads genannt
    • Aus dieser Perspektive sind Docker, Serverless und horizontale Skalierung nicht immer notwendige Entscheidungen

Edge-Ausführung senkt die Latenz nicht immer

  • Die physikalische Untergrenze für die Roundtrip-Latenz zur anderen Seite der Erde liegt wegen der Lichtgeschwindigkeit bei etwa 200 ms
    • In der Praxis dauert es zu einem guten Rechenzentrum auf der anderen Seite der Erde oft ungefähr 300 ms
  • Wenn JS, CSS und Medien über ein CDN ausgeliefert werden, kann bereits eine Reduzierung der Serververarbeitungszeit um 300 ms beim ersten Rendern einen ähnlichen Effekt haben wie das Verschieben des Servers näher zum Nutzer
  • Serverless-Technologien der zweiten Generation haben das frühere Problem deutlich verringert, dass ein Cold Boot leicht das gesamte Latenzbudget von 300 ms aufbrauchte, aber Datenbank-Roundtrips bleiben weiterhin bestehen
  • Wenn für das Rendern einer Seite auch nur eine einzige Datenbankabfrage nötig ist, muss ein Edge-Server wieder zu einem Ort wie us-east-1 mit der Ursprungsdatenbank hin- und zurückkommunizieren
    • Die Latenz verschiebt sich vom Weg zwischen Nutzer und Ursprungsserver auf den Weg zwischen Edge-Server und Ursprungsserver
    • Komplexe Seiten benötigen beim Rendern oft 5 oder mehr Datenbankabfragen
    • Viele Web-Frameworks führen Abfragen in einem Single-Thread-Modell sequenziell aus, sodass mehrere Roundtrips zwischen Rechenzentren langsamer sein können als ein einziger Aufruf zum Ursprungsserver
  • Als Faustregel gilt: Kommunikation zwischen Rechenzentren ist 10-mal langsamer als Kommunikation innerhalb eines Rechenzentrums, und Kommunikation innerhalb eines Rechenzentrums ist 10-mal langsamer als Kommunikation innerhalb desselben Geräts
    • In diesem Kontext erscheint lokales SQLite als vorteilhafte Wahl zur Senkung der Latenz

Kostenunterschiede zwischen Hetzner, AWS und Vercel

  • Ein 16-Kern-Server von Hetzner mit 64 GB RAM und NVMe-Laufwerk kostet $0.34/Stunde
  • Als vergleichbarer x86-Server wird bei AWS EC2 m5a.4xlarge mit $0.68/Stunde genannt
  • Die Unterschiede bei den Bandbreitenpreisen sind noch größer
    • Hetzner bietet 20 TB Transfervolumen kostenlos und berechnet danach $1.5/TB
    • AWS bietet 100 GB kostenlos und berechnet danach $90/TB
    • Vercel wird als Beispiel mit zunächst 1 TB kostenlos und danach $200/TB genannt
  • Die Freikontingente von Cloud-Anbietern erleichtern den Einstieg, können aber bei wachsender Größe in hohe Kosten umschlagen

Einfacher Betrieb mit einer Einzelserver-Konfiguration

  • Wenn es keinen speziellen Cloud-Anwendungsfall gibt, etwa Video-Transkodierung, das Ausführen eigener AI-Modelle oder andere Aufgaben, die das System tatsächlich stark belasten, kann eine Website oder ein SaaS auf einem einzelnen Server laufen
  • Mit einem Server in Virginia lassen sich für englischsprachige Nutzer Latenzen unter 100 ms erreichen
  • Die empfohlene Konfiguration ist bewusst einfach und um einen einzelnen Server herum aufgebaut
    • Als Datenbank wird SQLite auf derselben Maschine verwendet
    • Mit Litestream wird SQLite fortlaufend gesichert
    • CSS, JS und Bilder werden im CDN gecacht
    • Das Server-Rendering findet nahe bei SQLite statt, um Roundtrips zu reduzieren und die Performance zu erhöhen
  • Auch Deployments müssen nicht kompliziert sein
    • Die CI kann den Code per SCP auf den Server kopieren
    • NGINX unterstützt Zero-Downtime-Deployments
    • Docker und Virtualisierung werden als Faktoren betrachtet, die Codeausführung und CI/CD verlangsamen

Wann horizontale Skalierung nötig ist – und wann nicht

  • Die Behauptung, horizontale Skalierung sei nötig, ist in den meisten Fällen übertrieben
  • Dahinter steht die Annahme, dass Serverleistung schneller wächst als das Internet
  • Wenn Latenz wirklich entscheidend ist, kann man zusätzlich Server in Deutschland und Kalifornien betreiben
    • Schreibzugriffe werden an den Primary geroutet
    • Für Lesezugriffe werden lokale Read Replicas verwendet
  • Eine solche Konfiguration ist ausreichend skalierbar, hat geringe betriebliche Komplexität und ist deutlich günstiger
  • HTML-Auslieferung im Umfang von 11 MB/s muss nicht unnötig kompliziert gemacht werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-08
Hacker-News-Kommentare

  • Mein früheres kleines Hosting-Geschäft ist genau an diesem Punkt auf- und abgestiegen, ohne dass wir damals verstanden hätten, was da eigentlich passierte.
    Als wir Anfang der 2000er wuchsen, kamen die großen Umsätze meist aus komplexen Stacks, und vieles davon – etwa redundante Load Balancer und Firewalls – war mehr, als die Kunden tatsächlich brauchten, aber sie wollten es so.
    Failover verursachte durch die operative Komplexität oft höhere Kosten, als es Nutzen brachte, wenn ein Server auf die vorgesehene Weise ausfiel. Wir bauten auch eine API-basierte Cloud-Hosting-Plattform als Gegenstück zu AWS, aber der Umsatz erreichte 2012 seinen Höhepunkt.
    Die Kunden wollten komplexere Lösungen, die AWS teilweise oder vollständig nutzten. Wir dagegen dachten, weil Hardware so viel leistungsfähiger geworden war als zehn Jahre zuvor, würden auch große Kunden weniger und einfachere Server wollen.
    Aber damit verkauften wir nicht Cleverness, sondern Preis, und wir verstanden den finanziellen Ehrgeiz nicht, der für so eine Umstellung nötig gewesen wäre. Einem billigen einzelnen Server traute niemand, und selbst zwei Server lieferten keine ausreichende Antwort auf die Frage der Skalierbarkeit.
    Am Ende hielt sich der Umsatz, aber wir konnten nicht schneller als Amazon einen Stack aus Managed Services und ein Software-Ökosystem aufbauen. Nachdem die neuen technischen Herausforderungen versiegten, verkauften wir das Unternehmen 2018.
    Weil wir bootstrapped gewachsen waren und eine unbegrenzte Hosting-Rechnung wie ein verrücktes Risiko wirkte, entstand auch unser Produktdesign aus dieser Denkweise heraus. Erst spät wurde klar, dass alle anderen bereit waren, dieses Risiko einzugehen.
    AWS setzte sich nicht nur durch, weil VC teure Produkte ermöglichte, sondern auch, weil ihre spezielle Art von Cleverness einer ganzen Generation von Softwareentwicklern eingepflanzt wurde. Das Wissen, wann man keine Cloud braucht und welche Alternativen es gibt, fühlt sich inzwischen allerdings ziemlich nischig an.

    • Die Komplexität und Cleverness von AWS wirkt auf Entwickler wie Katzenminze, und wenn es darum geht, Resume-driven Development zu stützen, gibt es kaum etwas Vergleichbares.

  • Mit den Zahlen gibt es ein paar Probleme.
    Erstens verteilt sich Traffic nicht gleichmäßig. Die im Artikel genannten 400 Millionen Page Loads pro Monat können einem rekursiven 80/20-Prinzip unterliegen; so betrachtet würden sich rund 205 Millionen Requests auf 5,8 Stunden konzentrieren, also etwa 9,7 Tausend Requests pro Sekunde.
    Das ist mit einem einzelnen System zwar möglich, aber nicht mehr trivial – besonders dann nicht, wenn man auch noch eine einzelne DB ohne Read Replicas will. Selbst bei gleichem Gesamt-Traffic liegt die für Spitzenlast nötige Bandbreitengrenze deutlich höher als der optimistisch gemittelte Wert von 11 MB/s.
    Zweitens gilt die Einweg-End-to-End-Latenz nur für Streaming-Daten. Bei einem realen Cold Start braucht man ohne HTTP/3 drei Roundtrips für die TCP-Verbindung und mindestens zwei für die TLS-Verbindung; erst danach gehen HTTP-Request und -Response hin und her.
    Um echte Menschen zu bedienen, muss alles Beobachtbare in unter einer Sekunde passieren; danach steigt der Anteil der Nutzer, die das System für kaputt halten und den Tab schließen, rapide an.
    Früher habe ich beim Betrieb einer Wettbörse geholfen: Der Traffic kam in extremen Spitzen, die Latenzanforderungen waren hart, und das Handelsvolumen konzentrierte sich auf einen winzigen Abschnitt des gesamten Event-Fensters. Beim Echtzeithandel musste das Ergebnis innerhalb von 100 ms ab dem Moment, in dem der Nutzer eine Aktion startete, auf dem Bildschirm erscheinen, und Netzwerk-Roundtrip-Latenzen fraßen das Budget für die Event-Verarbeitung auf.
    Siehe: https://www.nngroup.com/articles/response-times-3-important-...

    • Bei Diensten wie einem Business-Insider-Klon ist Punkt 1 entscheidend. Wenn ein großer Twitter-Account einen Artikel verlinkt, können sich die gesamten durchschnittlichen monatlichen Page Loads innerhalb weniger Minuten konzentrieren.
      Auch so eine Last kann man mit einer großen Single-Server-Konfiguration bewältigen, aber dann baut man im Grunde keinen einfachen Webserver mehr, sondern einen ziemlich starken Frontend-Load-Balancer mit eingebautem Webserver.
      AWS verlangt zwar hohe Preise, aber in Load Balancer und Netzwerkinfrastruktur steckt enorme Ingenieursarbeit, und dadurch müssen die übrigen Leute nicht zu Experten für diesen gesamten Teil des Stacks werden.
    • Das weltweite Beispiel ist etwas komisch, weil es den Verbindungsaufbau nicht berücksichtigt, aber die Hauptaussage bleibt gültig.
      Wie viele Dienste brauchen tatsächlich weltweite Erreichbarkeit? Hat man auch gleich Support für mehrere Sprachen gebaut?
      Wenn man innerhalb der USA oder der EU bedient, kann ein guter zentraler Server der gesamten Region Latenzen unter 30 ms liefern.
      Wenn es keine echten globalen Anforderungen gibt und man nicht auch noch eine globale Datenbank betreiben muss, wird Edge ziemlich überschätzt.

  • Da ein 500 Internal Server Error erscheint, bekommt der Autor offenbar mehr Traffic als 11 MB/s. Eine archivierte Version gibt es hier: https://archive.is/UVpg0

    • PR_END_OF_FILE_ERROR habe ich zum ersten Mal gesehen. Mehrere Websites sagen, das könne durch Proxy, VPN oder DNS-over-HTTPS entstehen, aber in meinem Fall trifft das nicht zu.

  • Ich glaube, dieser Artikel betrachtet die Sache aus dem falschen Blickwinkel.
    Der bessere Ansatz lautet: nicht zu früh skalieren.
    Man baut so viel, wie man braucht, und in den meisten Fällen ist sogar ein CDN ein unnötiger Kostenfaktor – vorausgesetzt, man zahlt nicht die überzogene Bandbreitensteuer eines Cloud-Anbieters.
    Wenn Performance-Probleme sichtbar werden, kümmert man sich dann darum. Und wenn aus einem gewöhnlichen Arbeitspferd plötzlich das Einhorn wird, das alle haben wollen, dann ist das ein Problem, das man gern hat.

    • Man kann mit einem einzelnen Server anfangen. Wir sind nicht Facebook, und der Erfolg eines Startups hängt im ersten Jahr nicht davon ab, ob es einmal im Monat 15 Minuten ungeplante Downtime gibt.
      Wenn das Produkt gut ist, versuchen Nutzer es eine Stunde später noch einmal, statt sofort zur Konkurrenz zu wechseln. Wenn Skalierungsprobleme auftreten, kann man für die ressourcenintensiven Teile auf ein skalierbares Hybridmodell umstellen.
      Wenn man aber von Anfang an Webscale, Dutzende Microservices, explodierende Fehlerzustände zwischen ihnen und das Verbrennen von VC-Geld durch AWS-Rechnungen vor dem ersten Kunden will, nur zu.
    • In meinem Fall habe ich mit DigitalOcean angefangen, weil es CDN, CI, Hochverfügbarkeit und Komfortfunktionen wie Git-Deployments für 5 Dollar im Monat bot.
      Einen eigenen physischen Server zu betreiben, ist ein späteres Problem, nicht das jetzige. Wenn ich irgendwann zwischen einer AWS-Rechnung über eine Million Dollar und einem großen Single Server wählen muss, werde ich das nicht anhand eines Blogposts entscheiden, sondern eigene Tests laufen lassen.

  • Wenn man AWS nutzt, kauft man auch einen Sündenbock mit. Ein Ausfall eines großen Cloud-Dienstes lässt sich dem Chef oder Investoren leicht erklären; deutlich schwieriger ist es, denselben kumulierten Ausfall mit einem menschlichen Fehler im eigenen Team zu erklären.

    • Menschliche Fehler sind sowohl vor als auch nach dem Cloud-Hype die häufigste Ausfallursache.
      Daher frage ich mich, wie das mit der Deutung zusammenpasst, dass die Cloud der Sündenbock ist.

  • Warum SQLite, wenn man auf vertikale Skalierung abzielt? Nichts hindert einen daran, selbst gehostetes Postgres oder Supabase auf demselben Server zusammen mit der App zu betreiben, und abgesehen vom höheren Einrichtungsaufwand fallen mir keine Nachteile ein
    Wenn man ganz ohne DB auskommt, den gesamten globalen Zustand im echten Arbeitsspeicher eines großen Servers hält, ihn ohne Redis-Roundtrips als prozessinterne Objekte verwaltet, gelegentlich Snapshots vom Speicher auf die Platte schreibt und eine kompilierte, multithreaded Sprache nutzt, kann man eine NIC mit über 1 Gbit auslasten und von einer einzigen Box aus die ganze Welt bedienen
    Ich wünschte fast, es gäbe einen realen Anwendungsfall für so eine Architektur

    • Warum sollte SQLite nicht gehen? Natürlich lautet die Antwort immer: „Es kommt darauf an“, aber die Haltung, SQLite sei keine echte Datenbank, wird heutzutage zunehmend infrage gestellt
      Außerhalb standardmäßiger relationaler Persistenzmuster sind die Funktionsunterschiede groß, sodass Postgres besser sein kann; in bestimmten Architekturmustern kann SQLite aber auch vorn liegen
      Bei content-zentrierten Anwendungen wie BusinessInsider kann das SQLite-basierte Baked-Data-Pattern bei Kosten und Latenz besser sein
      simonw (datasette) hat viele Tools und Texte dazu erstellt, SQLite in Produktionsumgebungen für content-zentrierte oder datenreiche Websites einzusetzen: https://simonwillison.net/2021/Jul/28/baked-data/
    • Weil SQLite diesen Benchmarks zufolge deutlich schneller ist, insbesondere bei der Roundtrip-Zeit
      Das ergibt Sinn, da SQLite im Prozess läuft und keine Serialisierung nötig ist. Außerdem hat es den zusätzlichen Vorteil, dass Operationen seriell verarbeitet werden können, was Tests, Schlussfolgerungen und den Aufbau von Cache-Schichten deutlich einfacher macht
      Wenn man keine Unix-Sockets nutzt, gibt es auch Netzwerk-Overhead, aber da hier vom selben Server die Rede war, bleibt das ein Zusatzpunkt. In der Praxis ist es sehr üblich, Postgres zur Isolation auf eine andere Maschine zu legen, und genau das ist auch einer der Hauptvorteile einer Netzwerk-DB
    • Wenn es auf einer einzelnen Maschine läuft, ist SQLite besser als Postgres/MySQL
      Es hat alle nötigen Funktionen und ist zudem einfacher und schneller. SQLite kann Daten im Terabyte-Bereich, mehrere Lesezugriffe und Live-Streaming-Backups bewältigen und ist insgesamt eine ziemlich ausgewogene SQL-Implementierung
      Postgres/MySQL würde ich wohl erst in Betracht ziehen, wenn man über vertikale Skalierung auf einer einzelnen Box hinausgeht
    • Der Autor meint möglicherweise, dass man SQLite am Edge verwenden kann
      https://blog.cloudflare.com/introducing-d1

  • Viele scheinen das Gefühl zu haben, den Status quo mit Verfügbarkeit und Zuverlässigkeit verteidigen zu müssen, sobald der Autor den Fokus auf Latenz, Bandbreite und Kosten legt
    Mein Fazit ist nicht, angesichts von Trade-offs die Vorteile der Cloud zu leugnen, sondern zu fragen, ob die inzwischen allgegenwärtigen Cloud-Architekturmuster und die daraus entstehenden Abhängigkeiten wirklich zwingend nötig sind
    Der Gegensatz „dies gegen jenes“ ist ein rhetorisches Mittel, um Alternativen vorzustellen; welche Lösung passt, hängt je nach Einsatzfall von sehr vielen Faktoren ab. Genau wegen solcher Faktoren bekommen Engineers schließlich Jobs
    Allerdings lassen sich auch innerhalb des vom Autor vorgeschlagenen Musters SRE-Bedenken ausräumen. „Was ist mit der Verfügbarkeit, wenn ein einzelner Server ausfällt?“ ist nahezu ein Strohmann, weil Verfügbarkeit in Systemen, die sich von den uns vertrauten unterscheiden, anders gelöst werden kann; die Lösung sollte sich danach richten, was tatsächlich wichtig ist

    • Warum soll das ein Strohmann sein? Ob On-Premises oder Cloud: Das ist eine Frage, die vernünftige Menschen in einem Design-Review selbstverständlich stellen würden

  • Mit einem sparsamen Budget kann man mit nur einer zusätzlichen Ebene deutlich mehr herausholen: API und SQLite-DB zusammen betreiben
    Idealerweise nutzt die API ein Binärserialisierungsformat mit geringem Overhead und persistente Verbindungen, während man für die Web-Auslieferung den Free Tier eines VC-finanzierten Edge-Dienstes nutzt, der Geld verbrennt. Cloudflare Workers ist derzeit recht großzügig, und ausgehender Traffic ist ebenfalls kostenlos
    Der Kernpunkt ist, dass SQLite selbst mit einem einzelnen Thread enorm viele Queries pro Sekunde verarbeiten kann. Viele Operationen lassen sich seriell durchschieben, was das Nachvollziehen erleichtert; auch Memory-Caching und Invalidierung auf API-Seite werden einfacher
    Wenn man das Web-Serving trennt, profitiert man von der Edge-Performance beim Handshake und kann bei statischen Seiten die DB ganz umgehen. Der Artikel unterschätzt das Roundtrip-Problem; reale Apps brauchen mehr Roundtrips, als man denkt, daher ist dieses Problem ziemlich real
    Der größte Teil der CPU-Nutzung außerhalb der DB entsteht durch Parsing, Deserialisierung, Datenkopien und TLS. Nimmt man große Brocken davon heraus, bekommt man selbst auf Einstiegsmaschinen leicht zigtausende Schreibvorgänge pro Sekunde, und Lesevorgänge sind noch schneller
    Trotzdem lohnt es sich immer, typische Engpässe, insbesondere I/O, zu benchmarken. Anbieter übertreiben oft oder formulieren irreführend, also sollte man es im Free Tier selbst ausprobieren. Für den Fall eines Wechsels sollte man auch Integrationstests und Benchmarks bereithalten

    • Ich experimentiere mit einem ähnlichen Konzept. PostgreSQL kann Query-Ergebnisse als JSON ausgeben; wenn man sie exakt an die Form anpasst, die die API an den Client ausliefert, muss man sie nicht erst parsen
      Bei großen Ergebnissen ist das ziemlich gut, aber ich hoffe, dass PostgreSQL selbst beim Erzeugen von JSON aus großen Datensätzen nicht zum Bottleneck wird

  • Es heißt, man müsse am Edge sein, nah bei den Nutzern, und die Latenz reduzieren.
    Aber wie groß ist das Latenzproblem in der Praxis wirklich?
    Das Buch-Empfehlungsprojekt Gnooks, das auf einem Server in Deutschland läuft, ist ein Beispiel: https://www.gnooks.com
    Ich frage mich, ob es sich für jemanden zu langsam anfühlt.
    In den letzten Jahren habe ich für dieses Projekt Tausende Nutzervorschläge bekommen, aber soweit ich mich erinnere, hat niemand Latenz als Thema angesprochen. Und das, obwohl die größte Nutzergruppe in den USA sitzt.

    • Diese Site hält den Großteil der Logik im Backend und macht pro Nutzerinteraktion nur einen Server-Roundtrip.
      Dadurch hat sie deutlich weniger Latenzprobleme als eine moderne PWA, bei der ein Großteil der Logik im Frontend implementiert ist und dann mehrere Anfragen ans Backend geschickt werden, um die nötigen Daten zu laden.
    • Von Australien aus merkt man, dass es keine schnelle lokale Site ist. Sie kann wie eine langsame lokale Site oder wie eine schnelle ausländische Site wirken; der Ping liegt erwartbar bei etwa 300ms.
      Trotzdem ist die Site selbst in Ordnung. Problematisch wird es, wenn eine Site ohnehin schon langsam ist.
    • Man kann das Internet in Australien über ein VPN nutzen.
      Wenn man das in Europa macht, bekommt man ungefähr die doppelte Latenz, die australische Nutzer sehen, und kann so die Worst-Case-Erfahrung abschätzen.
    • In Hanoi ist es besser als erwartet. Vom initialen DNS+TLS bis zum Seitenladen dauert es immer noch über 1 Sekunde, aber nachfolgende Requests sind wie erwartet besser und zumindest unter einer Sekunde.
    • Wie so oft bei alten Fragen: Es kommt darauf an.
      Das Gute ist, dass man das zuverlässig testen und prüfen kann, ob es tatsächlich wichtig ist. Dann bekommt man eine konkrete Antwort.

  • Der Artikel behandelt Verfügbarkeit überhaupt nicht. Ein Dienst, der auf einer einzelnen Box läuft, hat sowohl geplante als auch ungeplante Downtime.
    Man muss auch über RPO/RTO nachdenken. Wenn die Box abraucht – oder eher: falls sie abraucht –, muss man schauen, wie lange die Wiederherstellung dauert und wie viele Daten verloren gehen.
    Zu der Aussage, dass jede Datenbankabfrage beim Rendern einer Seite zurück zur DB in us-east-1 gehen müsse, gibt es auch solche Optionen:
    https://aws.amazon.com/rds/aurora/global-database/
    https://aws.amazon.com/dynamodb/global-tables/
    https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce...
    https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
    Es gibt noch viele ähnliche Dinge, und wer versucht, dasselbe selbst irgendwie zusammenzuflicken, wird es schwer haben.

    • Meiner Ansicht nach wird Verfügbarkeit heute eher überschätzt.
      Vor 10 bis 20 Jahren hätte ich zugestimmt. Das Internet war neu, und wenn eine Website ausfiel, gaben die Leute der Website die Schuld; die Lage wurde schnell unangenehm. Heute schieben sie es eher zuerst auf ihren Internetanbieter oder versuchen es später noch einmal.
      Nicht jeder ist Google, und einfachere Systeme fallen von vornherein seltener aus. Man hält Backups vor und repliziert, wenn man wirklich besorgt ist, die DB auf eine kalte Disaster-Recovery-Site. Für die meisten Unternehmen und Situationen außerhalb von FAANG reicht das.
      Solange keine Daten verloren gehen, ist es für viele Unternehmen nur ein kurzes Flackern. Mit guter PR und wenn es ein sehr seltenes Ereignis ist, kann man sogar mehrere Tage Downtime überstehen; je nach Fall sogar Datenverlust.
      Es gab einmal die Aussage, dass jede zusätzliche Neun bei der Zuverlässigkeit die Kosten verdoppelt; das muss man bei der ROI-Betrachtung unbedingt einbeziehen. Wie viel Zuverlässigkeit ein Business tatsächlich braucht, hängt vom Zielmarkt ab, und die Standardantwort der IT, automatisch 100%, halte ich für falsch.
    • Wenn man direkt auf physischen Servern betreibt, kann man die Latenz gegenüber den verlinkten Produkten stark senken und die I/O-Bandbreite erhöhen.
      Ein Einzelserver- oder Doppelserver-Modell hat auch deutlich weniger Komplexität. Deshalb wählen sogar Betriebsteams wie LetsEncrypt eine solche Doppel-Physical-Server-Architektur, um globale Dienste im Webscale-Betrieb zu betreiben: https://letsencrypt.org/2021/01/21/next-gen-database-servers...
      Dank der sehr niedrigen internen Latenz einer DB im Server selbst oder direkt daneben kann Software DB-Abfragen um Größenordnungen schneller ausführen, pro Nutzer weniger Ressourcen verbrauchen und eine reaktionsschnellere User Experience bieten als tatsächliche Managed-DB-Dienste.
    • Auch Dienste, die auf AWS oder ähnlichen Plattformen laufen, haben Downtime.
      Komplexität schafft ihre eigenen Fallen, und ich glaube nicht, dass es einen Webservice gibt, der dabei noch nie etwas verbockt hat. Auch AWS selbst verursacht mitunter Incidents.
    • Auch bei AWS gibt es große Verfügbarkeitsprobleme.
      Man kann nicht sagen, dass ein VPS hier schlechter wäre.