Transloadit skaliert auf 1500 Maschinen für schnelleres Encoding

Encoding ist harte Arbeit für Server. Als wir dieses Unternehmen gründeten, war uns von Anfang an klar, dass es für Kunden viel einfacher sein würde, uns Jobs zu schicken, als es für uns wäre, sie zu verarbeiten. Angesichts stark schwankender Lastspitzen bei Encoding-Jobs und eines begrenzten Budgets sind Queues in diesem Geschäft unvermeidlich.

Wer Ihnen etwas anderes erzählt, arbeitet entweder nicht in großem Maßstab oder macht Verluste.

Lastspitzen & Queues

Manche Menschen nutzen die Upload-Funktionen von Transloadit, damit ihre Endnutzer Avatare auf ihre Websites hochladen können. Natürlich ist es nicht akzeptabel, wenn diese Menschen vier Stunden warten müssen, bis ihr Avatar in der Größe geändert wurde, nur weil wir gerade die 500 Videos umfassende Bibliothek eines anderen Kunden für die Anzeige auf dem iPad optimieren.

Aus diesem Grund müssen Queues und ihre Auswirkungen auf verschiedene Anwendungsfälle minimiert werden:

Um die Auswirkungen anzugehen, haben wir Algorithmen geschrieben, die zwischen Jobs unterscheiden können, die sich in Echtzeit anfühlen sollen – etwa das Hochladen und die Größenänderung von Avataren –, und Jobs, die etwas länger dauern dürfen – etwa das Konvertieren großer Stapel vorhandener Medien.

Vier Stunden zusätzliche Wartezeit sind verheerend für den Drei-Sekunden-Anwendungsfall, während drei Sekunden zusätzliche Wartezeit für den Vier-Stunden-Anwendungsfall unproblematisch sind. Prioritäten sind wichtig.

Natürlich wäre es noch besser, wenn sich die 4 Stunden auf zehn Minuten reduzieren ließen.

Um die Queues selbst anzugehen, war uns klar, dass wir Skalierung brauchten. Wie erwähnt, kann der Encoding-Traffic sehr unregelmäßig sein. Um lange Queues zügig abzuarbeiten, bräuchten wir eine sehr große Grundkapazität.

Leider bräuchten wir diese Kapazität nur für die Spitzen. In 90 % der übrigen Zeit würde sie in Rechenzentren vor sich hin rotten und dabei ihren Wert verlieren. Es wäre äußerst schwierig, aus diesem Modell ein profitables Geschäft zu machen.

Dann kam Amazon.

Amazon-Cloud

Amazon hatte ein ähnliches Problem mit extrem großen Traffic-Spitzen während des Weihnachtsgeschäfts. Natürlich konnte das Unternehmen niemanden abweisen und musste in so viele Server investieren, wie zur Bewältigung dieser Spitzen nötig waren.

Doch im Rest des Jahres brachte diese teure Ausrüstung kein Geld ein.

Etwa zu dieser Zeit prüfte Amazons IT-Abteilung Möglichkeiten, Virtualisierung zu nutzen, um die eigene Plattform wartungsfreundlicher zu machen. Allein die Möglichkeit, die meisten Server neu aufzusetzen, ohne ins Rechenzentrum fahren zu müssen, war bereits ein großer Gewinn. Jeff Bezos hatte zuvor ein Memo herausgegeben, wonach jeder intern bei Amazon entwickelte Dienst so gestaltet sein sollte, dass auch andere Unternehmen ihn leicht nutzen könnten.

In der Folge öffnete Amazon seine Verwaltungswerkzeuge für die Virtualisierung für die ganze Welt und konnte seine Überkapazitäten vermieten, womit sich außerhalb der Weihnachtszeit mit diesen ungenutzten Servern Geld verdienen ließ.

Und so wurde die Cloud geboren 🐣. Oder zumindest ist das meine vereinfachte Sicht der Dinge 😄 - wenn Sie das hier lesen und denken, dass ich Unsinn erzähle, sagen Sie es mir auf twitter⁠, und ich verfeinere diese glorreiche Geschichte.

Transloadit ❤️ Amazon

Wie erwähnt, könnten wir uns die Art von Kapazität, die für Lastspitzen nötig ist, nicht leisten. Vielleicht hätten wir einen Investor überzeugen können, das Geld lockerzumachen, aber wie gesagt: Es ist äußerst schwierig, Gewinn zu machen, wenn die Maschinen die meiste Zeit nichts tun.

Als wir jedoch die Idee für Transloadit hatten, hatte Amazon gerade das Beta-Label von seinem Cloud-Angebot entfernt: AWS⁠, und wir konnten Serverkapazität stundenweise mieten. Und dank der API konnten wir Software schreiben, die das bei steigendem Traffic automatisch erledigt.

Wie Sie sehen, verdanken wir Amazon unsere Existenz.

Gläserne Decken

Mit dem Versprechen von Amazons Cloud dachten wir, alles sei möglich. „Unbegrenzte Kapazität!“ „Nur dann, wenn wir sie wirklich brauchen!“. Und ich erinnere mich, wie glücklich wir waren, als wir auf unserer ersten dicken Maschine liefen:

Doch es gab einige gläserne Decken. Als wir versuchten, sechs Maschinen zu starten, erhielten wir Fehlermeldungen. Wie sich herausstellte:

Wenn Sie Ihr AWS-Konto erstellen, legt AWS Limits für Instanzen pro Region fest.

Unser Limit lag bei fünf Maschinen, und eine Queue, die wir damals hatten, brauchte ewig, bis sie abgearbeitet war.

Wir haben mit Amazon immer gute Erfahrungen gemacht; sie haben uns in der Anfangszeit sogar zu etwas Aufmerksamkeit verholfen⁠. Wir haben uns schnell gemeldet, und sie haben uns schnell eine neue „Instanz-Obergrenze“ von maximal 20 Maschinen gewährt.

Wir waren begeistert 😄, denn es bestätigte, was wir vorhatten, und wir hatten gerade eine gläserne Decke durchbrochen.

Seitdem mussten wir uns noch einige Male an Amazon wenden, um unsere Instanz-Obergrenze zu erhöhen. Das letzte Mal war am 5. November 2013, als Amazon uns ein Limit von 500 Maschinen in unserem primären Rechenzentrum gewährte.

Skalierungsmuster

In letzter Zeit beobachten wir, wie der Traffic nach diesem Muster wieder anzieht:

Die Grafik zeigt, dass Maschinen hochskaliert werden, sobald Encoding-Jobs in die Queue geworfen werden. Doch sobald wir auf 500 Maschinen hochskalieren, flacht die Linie ab und die 5 TB große Queue wird langsamer verarbeitet, als uns lieb ist.

Normalerweise würden wir Amazon kurz eine E-Mail schreiben, doch diesmal hieß es:

Für eine Limiterhöhung dieser Größenordnung muss ich mich mit unserem Service-Team abstimmen, um eine Freigabe zu erhalten. So stellen wir sicher, dass wir Ihre Anforderungen erfüllen und gleichzeitig die bestehende Infrastruktur schützen können.

Ich weiß, dass Amazon schätzungsweise rund 450.000 (Hardware-)Server betreibt⁠, auf dieser Skala sind wir also immer noch ein kleiner Fisch. Dennoch war es aufregend, dass sie für diese Anfrage zusätzliche Ressourcenplanung betreiben mussten.

Sie können sich vorstellen, dass ich mich heute umso mehr darüber freue, dass wir gerade eine E-Mail erhalten haben, in der steht:

Ich freue mich, Ihnen mitteilen zu können, dass wir Ihre Anfrage zur Erhöhung des EC2-Instances-Limits für die Regionen EU (Irland) und US East (Northern Virginia) genehmigt und bearbeitet haben. Es kann manchmal bis zu 15 Minuten dauern, bis dies übernommen wird und zur Nutzung bereitsteht.

Dank dieser neuen Instanz-Obergrenze können wir jetzt eine Flotte von 1000 Maschinen in den USA und 500 in der EU hochfahren - das bedeutet, dass wir unsere Kapazität mehr als verdoppelt haben:

Das heißt nicht, dass wir bereits auf 1500 Maschinen laufen, aber ab heute über diesen Spielraum zu verfügen, ist ein Durchbruch für uns. Ihn nutzen zu können, wird eine große Hilfe sein, um mehrere Terabyte große Encoding-Queues zügig abzuarbeiten, wie wir sie in letzter Zeit häufiger sehen.

Für Sie als Kunde bedeutet das schnellere Encoding-Zeiten und dass wir riesige HD-Video-Importe so bewältigen können, als wären sie nur ein kleiner Avatar! 😉