2.03.2010 / Timo Hetzel

uCDN

Heute basteln wir uns ein Content Delivery Network.

Eine Folge Bits und so ist im Schnitt etwa 50-70MB groß. Für den Hörer mit Breitbandanschluss keine besonders große Datei, für mich als Anbieter allerdings ein immer größer werdendes Problem.

Viele Hörer von Bits und so laden die Folge sofort nach Erscheinen herunter, der Peak in der Bandbreite und den Requests hält meist einige Stunden an. Genug, um einen einzelnen (wenn auch etwas schwachbrüstigen) Server in die Knie zu zwingen. Den Webserver, der jetzt nur noch das Blog und den Feed hostet, haben wir schon vor einigen Monaten durch ein leistungsstärkeres Modell ersetzt, nachdem der Vorgänger zuverlässig jedes Wochenende überlastet war.

Die Mediendateien waren bisher für bezahlte Inhalte aus der Undsoversity bei Amazon S3 gehostet, die kostenlosen Downloads für die Audio-Podcasts bei Dreamhost in den USA, und die Downloads für Plus-Mitglieder auf einem dedizierten physikalischen Server bei einem deutschen Hoster.

Die Aufgabenstellung ist also, die Mediendateien vorzuhalten, die Bandbreitenspitze kurz nach der Veröffentlichung abzufangen, und in der Summe den Traffic günstig einzukaufen.

Ich behaupte ab und an gerne, dass Content Delivery ein gelöstes Problem sei. Das ist vor allem dann richtig, wenn man von bezahltem Content spricht. Dienste wie iTunes oder die Undsoversity können leicht einige Cent pro Gigabyte Traffic in den Preis des Angebots einkalkulieren. Bei kostenlosen oder unregelmäßig werbefinanzierten Angeboten fällt das schon deutlich schwerer.

Eine großzügige Schätzung des Trafficbedarfs für das Undsoversum liegt momentan bei etwa 20TB pro Monat. Eingekauft bei CDN-Anbietern wie CacheFly oder Amazon Cloudfront kostet dieses Volumen rund 2000€ pro Monat. Der Vorteil bei dieser Lösung: Die Dienste skalieren automagisch in der Wolke, sichern die Daten redundant ab, und man hat kaum Setup-Aufwand. Der Nachteil ist der exorbitante Preis.

Die verlockende Alternative scheinen Hostingangebote mit unlimitiertem Datentransfer zu sein, die man bei den großen deutschen Hostern finden kann. Aus persönlicher Erfahrung scheitern diese Angebote an mindestens einem von zwei Haken: Entweder ist das Angebot nur so lange unlimitiert, wie man eine nicht näher spezifizierte Grenze nicht überschreitet, oder die Hardware/Netzwerkanbindung ist dem wöchentlichen Peak nicht gewachsen und liefert im Ernstfall keinen oder unbefriedigenden Durchsatz pro User.

Unser Lösungsansatz: Wir mieten günstige Server mit weichem Trafficlimit und jeweils 100MBit-Anbindung. Je nach Anbieter sind z.B. pro Server 5TB Traffic pro Monat inklusive. Sollte dieses Limit überschritten werden, halten sich die Kosten auch noch in Grenzen. Sollte sich abzeichnen, dass regelmäßig mehr Bedarf entsteht, lassen sich leicht weitere Server anmieten. Nach unten skaliert diese Lösung aufgrund von Vertragslaufzeiten und/oder Setup-Gebühren nicht ohne weiteres.

Pro Server stehen damit also 100MBit Bandbreite zur Verfügung. Genug, um auch einem Ansturm von tausenden gleichzeitigen Clients gewachsen zu sein. Die Downloads sind dann ja auch innerhalb weniger Sekunden abgeschlossen und der Server ist wieder frei.

Die Verteilung der Mediendateien auf die Medienserver erledigt lsyncd, der ab Linux Kernel 2.6 funktioniert und bei Veränderungen in definierten Verzeichnissen die Dateien zwischen den Maschinen synchronisiert.

In der Summe stehen jetzt also über 500MBit Bandbreite und über 20TB an Traffic zur Verfügung, für einen Bruchteil der Kosten, die bei einem “richtigen” CDN-Dienstleister anfallen würden. Der Nachteil ist natürlich der relativ hohe Setup-Aufwand und eine relativ schlechtere Flexibilität bei extremen Bandbreiten- oder Trafficspitzen.