Notiz CDN-Ausfall bei Fastly: Reddit, New York Times und weitere große Seiten waren offline
Peacemaker1337 schrieb:
snaxilian schrieb:
@NJay @Weyoun @Gufur @snaxilianWeyoun schrieb:
Ich weiß es ist verlockend direkt Amazon / AWS zu kritisieren, aber dahinter steckt durchaus (sinnvolle) Methode und man muss die Hintergründe kennen:
1. AWS ist kein CDN. AWS ist Cloud-Infrastruktur, die teilweise für Amazon‘s CDN Cloudfront genutzt wird. Teilweise.
2. CDNs haben unterschiedliche Foci. Je nach content type (websites, downloads, images, live streaming, on-demand streaming, low latency real-time / gaming, ...) gibt es unterschiedliche Anbieter und Infrastrukturen.
3. Cloudfront, Amazon‘s CDN, ist spezialisiert auf On-Demand Videocontent
4. Fastly ist spezialisiert auf edge-cloud Lösungen im Bereich websites, images, ... d.h. sie liefern content möglichst nah vor Ort beim Kunden aus (viele Server, sehr stark verteilt über den Globus). Sie sind nicht spezialisiert auf z.B. sehr hohe Bandbreiten über On-Demand-Streaming.
5. AWS ist das genaue Gegenteile: riesige Cloud-Datacenter, die sehr viel „heavy-lifting“ in einzelnen Ländern/Standorten zentralisieren; kein edge-cloud wie Fastly
Deshalb liefert Fastly Amazon.com aus, weil es da um Webseitendaten, Bilder, ... geht und das geht am besten über edge-cloud, d.h. du musst z.B. aus Sachsen nicht erst zum AWS Frankfurt für Amazon.com, weil Fastly einfach auch in Sachsen Server vor Ort hat.
Umgekehrt ergibt es keinen Sinn für z.B. Prime Video (deshalb ging das auch noch), weil du dafür deutlich größere, zentralisierte Rechenzentren benötigst. Dafür ist der Backbone auch AWS.
Als typisches Unternehmen wirst du im Übrigen beides machen: dein Backend in einer Cloud wie AWS betreiben und ein CDN für die Auslieferung beauftragen. Im Fall von Websites eben Fastly. Das hat auch Amazon gemacht, weil die intern nur Cloudfront haben und das eben nur auf On-Demand-Streaming spezialisiert ist.
Je nach Anwendungscase verknüpfst du deine Services / Backend also mit einem CDN, dass zu deinem Content-Type passt.
NJay
Rear Admiral
- Registriert
- Aug. 2013
- Beiträge
- 5.762
Ich hab hierzu gar nichts gesagt, da hast du den falschen erwischtascer schrieb:
Zum Thema:
Das Ist halt das problem wenn alle zu grossen CDNs rennen. 99% der Zeit laeuft alles super, aber wenn der Down geht, sind alle Down. Klassischer SPOF, auch wenn die Server verteilt sind.
Cdn's gibt es seit 20+ Jahren allerdings werden sie immer wichtiger weil immer mehr traffic da ist.Fritzler schrieb:
Mit Cloud hat es erstmal nichts zu tun. Für die Daten in meinem Dropbox Account nutzt ein CDN mal gar nichts.
Wenn ich meine Webseite selbst hoste ist ein CDN möglicherweise sogar wichtiger als beim hosting in cloud mit mehreren Standorten.
Im Normalfall sorgen CDNs für mehr Geschwindigkeit und Stabilität.
Ja schon richtig nur muß ein CDN Anbieter eine gewisse Größe haben um genügend verteilte Standorte und Bandbreite zu haben damit er sites wie twitch beschleunigt und nicht selbst zum bottleneck wirdNJay schrieb:
@NJay True
Bzgl. zu große CDNs würde ich aber auch sagen, dass das Risiko gar nicht so groß ist. Die Infrastruktur ist ja verteilt und genau für diesen Zweck optimiert. Totalausfälle wie heute sind ja extrem selten.
Abgesehen davon kann man für kritische Infrastruktur ja durchaus mehr als nur ein CDN beauftragen oder eben direkte Routen (so wie stackoverflow das gemacht hat; hätte nur einen Automatismus benötigt, der das schneller realisiert, wenn man die Downtime noch weiter reduzieren will) parat halten.
Solange man Backups für den „Ernstfall“ plant und testet sehe ich in CDNs ehrlich gesagt nur Vorteile.
Bzgl. zu große CDNs würde ich aber auch sagen, dass das Risiko gar nicht so groß ist. Die Infrastruktur ist ja verteilt und genau für diesen Zweck optimiert. Totalausfälle wie heute sind ja extrem selten.
Abgesehen davon kann man für kritische Infrastruktur ja durchaus mehr als nur ein CDN beauftragen oder eben direkte Routen (so wie stackoverflow das gemacht hat; hätte nur einen Automatismus benötigt, der das schneller realisiert, wenn man die Downtime noch weiter reduzieren will) parat halten.
Solange man Backups für den „Ernstfall“ plant und testet sehe ich in CDNs ehrlich gesagt nur Vorteile.
Der Lord
Lt. Commander
- Registriert
- Aug. 2018
- Beiträge
- 1.766
bitte was? ich verstehe nicht ein Wort... nun gehöre ich offenbar auch zum alten Eisen. xDEngelsen schrieb:
ontopic:
ich staune, dass selbst AWS betroffen war, die ja selbst ein CDN stellen.
schon beeindruckend und leicht beängstigend die Reichweite einzelner Firmen mittlerweile.
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 38.252
was genau wird denn bei fastly gehostet?
hätte man das problem mit https://decentraleyes.org umgehen können?
hätte man das problem mit https://decentraleyes.org umgehen können?
Überwiegend statischer Content (plain html) sowie Bilder, da fastly.com ggü. CloudFront oder anderen CDNs eine recht gute Bildoptimierung hat.sadofia schrieb:
Betreibe ich also einen weltweiten Webshop mit vielen Produktbildern pro Artikel kann ich so die Ladezeiten für die Kunden verringern ohne das ich selbst dutzende oder hunderte von Servern selbst betreiben muss um die Daten nah zu den Kunden zu bringen. CDNs sind vereinfacht gesagt nix anderes als "Webserver as a Service nah beim Kunden".
Nein, das hat nix mit dem Aussetzer von fastly zu tun. Ist einfach nur ein Ergebnis von den Nachteilen der Zentralisierung im Interwebs. Gibt noch ein paar andere größere CDNs neben fastly, z.B. Akamai, CloudFront (AWS) oder Cloudflare.sadofia schrieb:
Alle von denen hatten schon mehr als einen Ausfall und wenn so ein Ausfall passiert, reißt es halt alle Kunden mit in den Abgrund. Ist halt immer ne Abwägung ob man sowas selbst betreiben will mit Aufwand oder eben an $Dienstleister abgibt.
Dein Link macht etwas anderes und hat damit nix zu tun.
Nero_XY
Lieutenant
- Registriert
- Okt. 2020
- Beiträge
- 522
Ich hab auch nur GitHub mitbekommen, so ca. um 12 Uhr. Dachte zuerst der Firefox, von dem PC den ich dort gerade genutzt habe, wäre komplett veraltet GitHub bestand nämlich nur noch aus Plain-Text aber war eben noch erreichbar. Scheint als würden die so Sachen wie ihr Style-Sheet und natürlich Bilder und Downloads per CDN machen. Als ich dann in der Mittagspause die ersten Meldungen davon gelesen habe, war es mir dann auch gleich klar wo das Problem lag^^
GitHub bestand nämlich nur noch aus Plain-Text aber war eben noch erreichbar. Scheint als würden die so Sachen wie ihr Style-Sheet und natürlich Bilder und Downloads per CDN machen. Als ich dann in der Mittagspause die ersten Meldungen davon gelesen habe, war es mir dann auch gleich klar wo das Problem lag^^Soweit ich weiß war AWS nicht betroffen sondern die amazon Shopping sitesDer Lord schrieb:
Warum Amazon fastly verwendet:
https://www.streamingmediablog.com/2020/05/fastly-amazon-homepage.html
(Falls die Info korrekt ist)
@snaxilan - du hast Recht nur selbst betreiben ist eben sehr aufwendig und mit massiven Investitionen verbunden.
Amazon hat sich bestimmt gut überlegt warum sie fastly und nicht ihr eigenes cloudfront nehmen.
Kettensäge CH
Lt. Commander
- Registriert
- Juni 2020
- Beiträge
- 1.046
Ähm... was?Engelsen schrieb:
Edit: Oh, schon beantwortet, okay. Sorry, aber das war jetzt echtmal ne verdammt dämliche Aneinanderreihung von Abkürzungen...
Wenn ich ein weltweit agierender Shop bin der mit tausenden von parallelen weltweit verweilten Anfragen "bombardiert" werde dann ist das in der Tat aufwendig. Ob man dann selbst Datacenter und Blech kauft und hohen Capex hat oder bei einem IaaS Anbieter für kontinuierliche Opex etwas miete, muss man kalkulieren.cloudman schrieb:
Wenn ich nur irgendeine Hipster-Startup-Bude bin aber unfähig bin meine kaum bis nicht optimierte Webseite zu optimieren und zu verschlanken dann kann man das auch mit einem CDN kaschieren und bezahlt Unfähigkeit mit Geld aber gut, das ist fast überall im Leben so.
Wenn man vergleichsweise viele aber kleine Dateien hat und die gesamte Datenmenge überschaubar ist, könnte man auch den (statischen) Dateninhalt weltweit auf eigene Server replizieren und per Anycast-Netzwerk-Magie dem Kunden den Content vom nächsten eigenen Server ausliefern. Selbstbau-CDN-für-Nerds quasi aber erfordert eben Know-How. Wenn man dies nicht hat oder aufbauen will nimmt man eben eine fertige Lösung, ist ja nix verwerfliches dabei.
Der von dir verlinkte Artikel erklärt ja ganz gut warum Amazon mit fastly besser beraten ist als mit dem "hauseigenen" Cloudfront
wolve666
Vice Admiral
- Registriert
- März 2009
- Beiträge
- 6.295
Ja danke, dafür das ich keinen neuen thread erstellt hatte für diese Meldung sondern bei einem bestehenden Thema etwas sarkastisch geschrieben hab, bekomm ich ne Verwarnung...manchmal muß man sich echt fragen ^^
funzt übrigens alles wieder
funzt übrigens alles wieder
M-X
Vice Admiral
- Registriert
- März 2007
- Beiträge
- 6.867
Sehr gut erklärt. Es zeigt sogar das Amazon ziemlich schlau ist und sich nicht stumpf auf die eignen Produkte verlässt, die im zweifel nicht für den Use Case geeignet sind sondern das Optimum im Ziel hat.ascer schrieb:
@snaxilian so wie du das Beschreibst könnte ja Dieter der ITler selber das CDN bauen, sind ja nur ein paar Server die verteilt werden. Sowas sind enorme Investitionen.
Wenn "Dieter der ITler" gute Kenntnisse im Bereich Linux, Netzwerk und Webserver hat: Ja. Die höchsten Investitionen sind dabei aber eher der fachliche Aufbau des Knowhows bei den Mitarbeitern.
Eine Firma, die aber nur einen(!) Admin haben für diese drei nicht unbedingt gerade kleinen und simplen Bereiche, braucht in der Regel aber auch kein CDN
Ein vollständiges CDN braucht noch ein paar viele Extras, damit es vernünftig funktioniert für den Endanwender. Im Engineering Blog von LinkedIn gibt's einiges dazu zum nachlesen (https://engineering.linkedin.com/blog).
Aber der übliche Weg ist eher: Kleine Bude ohne "scale-out" --> Wachstum --> CDN wird eingekauft.
Eine Firma, die aber nur einen(!) Admin haben für diese drei nicht unbedingt gerade kleinen und simplen Bereiche, braucht in der Regel aber auch kein CDN
Ein vollständiges CDN braucht noch ein paar viele Extras, damit es vernünftig funktioniert für den Endanwender. Im Engineering Blog von LinkedIn gibt's einiges dazu zum nachlesen (https://engineering.linkedin.com/blog).
Aber der übliche Weg ist eher: Kleine Bude ohne "scale-out" --> Wachstum --> CDN wird eingekauft.
