tus in Produktion betreiben

Kevin van Zonneveld

Mitgründer · Amsterdam, Niederlande · Bio anzeigen

2013 sind wir angetreten, die Welt ein kleines Stück besser zu machen, indem wir das Hochladen von Dateien für alle reparieren. Dazu haben wir ein offenes Protokoll für zuverlässiges Hochladen entwickelt, genannt tus⁠. Der Weg war lang und es gab unterwegs viele Rückschläge und Meilensteine, doch heute feiern wir, dass Transloadits API tus nun vollständig unterstützt. Wir kommen auch bei der Aktualisierung all unserer SDKs gut voran, um ebenfalls Unterstützung für tus zu ergänzen. Wir freuen uns sehr, allen unseren Kunden die robusten Content-Ingestion-Funktionen anbieten zu können.

Nicht alle Menschen weltweit profitieren von schnellem und stabilem Internet. Selbst in Industrieländern leiden Menschen häufig unter schlechten Verbindungen, etwa während Zugfahrten, bei Gängen in den Keller oder wenn sie in ländlicheren Gegenden leben. Auch instabiles WLAN ist eine häufige Ursache für Ärger. Und wenn ein Nutzer Ihrer App ein 100 MB großes Video hochlädt und die Verbindung nach 90 MB abbricht, ist das vermutlich frustrierend genug, um den Upload nicht noch einmal von vorn beginnen zu wollen.

Schlechte Verbindungsqualität fällt auf Ihre App zurück, und möglicherweise bekommen Sie den Frust ab, der eigentlich Netzbetreibern oder Quellen von WLAN-Störungen gelten sollte.

Dieses Problem verschärft sich täglich, denn es erscheinen immer bessere Kameras, die zu einem dramatischen Anstieg der Dateigrößen führen, während die Zuverlässigkeit der Netzverbindungen unverändert bleibt.

Die Lösung für ein weit verbreitetes Problem

Mit tus gehört dieses Problem der Vergangenheit an. Zwar können wir schlechte Netzverbindungen nicht beheben, aber wir können dafür sorgen, dass Uploads automatisch genau dort fortgesetzt werden, wo sie abgebrochen sind. Wenn alles gut läuft, bemerkt der Endnutzer die Unterbrechung wahrscheinlich nicht einmal. Die Website oder App lädt die verbleibenden Bytes sofort hoch und der Nutzer bleibt in seinem Flow.

Fortsetzbares Hochladen von Dateien ist schon seit einiger Zeit möglich, aber es gab nie einen offenen Standard dafür, was zur Geburt von tausend inkompatiblen und kaum funktionierenden Ein-Wochen-Projekten führte. Als wir uns daranmachten, etwas an der Zuverlässigkeit des Hochladens zu ändern, wollten wir nicht zu einem dieser Projekte werden. Uns war klar, dass der Entwurf eines neuen Protokolls nicht einfach werden würde, doch wir hielten es für den einzig richtigen Weg – und so legten wir los.

Hürden auf dem Weg

Wir haben unser Herzblut in dieses Protokoll gesteckt und hart gearbeitet. Wir stießen an Grenzen, wurden demotiviert und stellten die Arbeit daran zeitweise sogar ganz ein. Doch wir sammelten uns immer wieder und probierten neue Ansätze aus. Besonders Marius gebührt großer Dank dafür, dass er uns aus einer schwierigen Lage geholfen hat. Als Projektleiter sichtete er das Feedback von Ingenieuren bei Vimeo, Google, Yahoo, ZeroMQ und Node.js und entschied größtenteils, was aufgenommen und was weggelassen werden sollte.

Nach all diesen Mühen war es eine enorme Erleichterung, als wir endlich bereit für die Veröffentlichung von tus 1.0⁠ waren. Wir sahen sofort einen Anstieg des Community-Engagements und Menschen, die tus in ihrer Lieblingsprogrammiersprache implementierten. Mit v1.0 konnten sie nun darauf vertrauen, dass ihre Komponente über Jahre hinweg zuverlässig mit anderen tus-Komponenten zusammenarbeitet. Die besten Community-Implementierungen sind inzwischen offiziell unterstützte Implementierungen geworden, die unter unserem gemeinsamen Dach auf https://github.com/tus/⁠ liegen. Das sind Bibliotheken, die Entwickler nun einfach in ihre App einbinden können, um Übertragungsgeschwindigkeit und Zuverlässigkeit zu erhöhen.

Es war eine wahre Freude, die tus-Community im Laufe der Zeit wachsen zu sehen, und dass Vimeo tus eingeführt hat⁠ war zum Beispiel ebenfalls ein großer Erfolg für das Projekt. Ihre Unterstützung war schlichtweg großartig, sowohl in Form von Ideen als auch von Code-Beiträgen.

Heute also feiern wir, dass wir auch unsere eigene API mit den Funktionen von tus für fortsetzbare Uploads ausgestattet haben. Tatsächlich haben wir uns für einen Soft Launch entschieden und nach und nach mehr Menschen auf tus umgestellt, wo es möglich war. Ein paar Monate und ein halbes Petabyte (oder 500 Millionen Bilder) später genießen Endnutzer weltweit zuverlässiges, von tus angetriebenes Hochladen, ohne es überhaupt zu bemerken. Die Dinge „funktionieren einfach“, selbst die größten Katzenvideo-Uploads überstehen Gänge in den Keller. Und so sollte es sein: Wenn Sie es bemerken, haben wir versagt.

Unterstützung auf der Client-Seite

Wenn Sie bereits Transloadit-Kunde sind, spricht Ihre Software wahrscheinlich nicht direkt mit unserer API, sondern Sie nutzen eines unserer SDKs. Mit einem SDK profitieren Sie sofort von unseren bewährten Verfahren und sparen sich Boilerplate-Code in Ihrer Programmiersprache. Die gute Nachricht: Viele unserer SDKs unterstützen tus. Hier ist eine Liste, die automatisch aktualisiert wird (schauen Sie also jederzeit gern wieder vorbei):

Wenn Sie eines der SDKs verwenden, die tus bereits unterstützen, haben Sie Glück! Sie müssen nur auf die neueste Hauptversion aktualisieren, dann sind fortsetzbare Uploads standardmäßig für Sie aktiviert. Was unsere übrigen SDKs betrifft, arbeiten wir daran, die Unterstützung für tus schrittweise auf ganzer Linie einzuführen, bleiben Sie also dran. Wenn Sie dies als Entwickler lesen und sich bei tus einbringen oder unsere SDKs verbessern möchten, freuen wir uns, wenn Sie sich bei uns melden, denn wir würden sehr gern über Ihre Verbesserungsideen sprechen.

Wenn es um die Client- bzw. Browser-Seite geht, verdient die solide Zuverlässigkeitsarbeit unseres Uppy⁠-Teams eine besondere Erwähnung. Neben der vollständigen Unterstützung von tus haben sie auch ein Plugin entwickelt, mit dem Sie Uploads nach Browser-Abstürzen fortsetzen⁠ können. Wir sind stolz, sagen zu können, dass beides Branchenpremieren sind!

Die technischen Details 🔩

Dieser Abschnitt beschreibt unsere Infrastruktur zum Zeitpunkt der Veröffentlichung im Jahr 2017, nicht unsere aktuelle Deployment-Architektur. Die SDK-Tabelle oben spiegelt die aktuelle Dokumentation wider.

Der größte Teil der Arbeit floss in das Protokoll⁠ selbst und in das Ausarbeiten seiner Implementierungen⁠ gemeinsam mit der Community. Sobald diese in gutem Zustand waren, war es recht unkompliziert, tus an unseren bestehenden Encoding- und Upload-Dienst anzubinden.

Wir betreiben auf allen Rechnern, die Uploads verarbeiten, einen unveränderten tusd⁠-Server neben unserer bestehenden Empfangssoftware. HAProxy⁠ leitet jede Anfrage, die an /resumable/* gerichtet ist, an die tusd-Instanz weiter, die auf einem solchen Rechner läuft.

Jedes tus-fähige SDK erstellt wie gewohnt eine Assembly, aber statt sofort hochzuladen, gibt die Assembly einen tus-Endpunkt /resumable/ zurück, der Uploads entgegennimmt. Beim Hochladen an diesen tus-Endpunkt hängt das SDK den eindeutigen Speicherort der Assembly als Metadaten an. Jedes Mal, wenn ein Upload abgeschlossen ist, wird ein tusd-Hook ausgelöst, der diese Metadaten auswertet, um die Assembly zu finden und sie über einen fertigen Upload zu informieren. Das Encoding dieser Datei kann dann bereits starten, obwohl noch weitere Uploads eintreffen. Das SDK gibt außerdem an, wie viele Uploads zu erwarten sind, sodass die Assembly weiß, wann sie fertig ist und Sie mit den Encoding-Ergebnissen benachrichtigen soll.

Damit alles reibungslos läuft, setzen wir auf das gute alte Upstart (kaum anders als damals im Jahr 2009⁠) sowie auf den Endpunkt /metrics, den tusd bereitstellt. Dieser Endpunkt enthält die Zahlen, die unser Autoscaler verwendet, um EC2-Instanzen zu starten oder zu beenden, wenn die Last steigt oder sinkt. Wir speisen diese Metriken außerdem in Librato⁠ ein, damit wir den Zustand unserer Prozesse genau im Blick behalten und über Probleme informiert werden:

Da wir vorhaben, gute Teile unserer Infrastruktur auf Kubernetes⁠ zu verlagern, ist es ermutigend zu wissen, dass der Endpunkt /metrics von tusd bereits mit deren bevorzugter Monitoring-Lösung kompatibel ist: Prometheus⁠. Wer hochmoderne Content-Ingestion-Netzwerke auf Kubernetes oder ähnlichen Docker-freundlichen Plattformen (wie Nomad, Swarm, Mesos usw.) ausrollen möchte, den wird außerdem freuen, dass wir daran arbeiten, ein offizielles Docker-Image für _/tusd⁠ zu veröffentlichen. Wir überlegen, ob ein Kubernetes Operator⁠ für den Betrieb eines Netzwerks zur Content-Distribution und Content-Ingestion nach tus und Uppy ein drittes großes, ergänzendes Open-Source-Projekt abgeben könnte. Kontaktieren Sie uns, wenn Sie sich darüber austauschen möchten.

Wenn Sie tus-Server selbst betreiben möchten, aber all das Gerede über Container und dedizierte Server nichts für Sie ist: Es gibt auch viele andere Implementierungen, etwa für Node.js, Ruby, PHP, Python usw., die Sie zusammen mit Ihrem bestehenden Webserver nutzen können. Es ist so einfach, wie Ihrer bestehenden App etwas Code hinzuzufügen. Alle Implementierungen sind MIT-lizenziert (d. h. in jeder denkbaren Hinsicht frei), es kostet Sie also nur ein paar Minuten Ihrer Zeit.

Fazit

Als wir 2013 zum ersten Mal über tus sprachen⁠, rechneten wir damit, entweder sofort krachend zu scheitern oder innerhalb eines Jahres erfolgreich zu sein. Wie sich herausstellt, ist der Versuch, Dinge richtig zu machen, nicht unbedingt der kürzeste Weg oder der des geringsten Widerstands.

„It's been a long time coming, but I know a change is gonna come“

— Sam Cooke

Sie können sich sicher vorstellen, wie begeistert wir sind, diese langfristigen Open-Source-Investitionen endlich zum Leben erwachen zu sehen, so weit gereift, dass sie produktionsreif und einsatzbereit sind, um nicht nur unseren Kunden zu nutzen, sondern auch ein Ökosystem neu zu definieren, von dem wir nur ein winziger Teil sind.

Danke, dass Sie bis zum Schluss durchgehalten haben. Wir hoffen, Sie finden, es hat sich gelohnt!

Wenn Sie mehr erfahren oder uns dabei helfen möchten, das Hochladen von Dateien für alle Menschen weltweit zu verbessern – schauen Sie bei tus.io⁠ und uppy.io⁠ vorbei. Wie immer sind Ihre Gedanken auch über unsere Support-Seite oder auf HN⁠/Reddit⁠ sehr willkommen.