Transloadit passe à 1500 machines pour un encodage plus rapide

L’encodage est un travail exigeant pour les serveurs. Quand nous avons lancé cette activité, nous savions dès le départ qu’il serait bien plus facile pour les clients de nous envoyer des Jobs que pour nous de les traiter. Avec des pics de Jobs d’encodage très variables et un budget limité, les files d’attente sont inhérentes à ce métier.

Quiconque vous affirme le contraire soit ne fonctionne pas à grande échelle, soit perd de l’argent.

Pics et files d’attente

Certaines personnes intègrent les fonctionnalités d’envoi de fichiers de Transloadit pour que leurs utilisateurs finaux puissent envoyer des avatars sur leurs sites web. Évidemment, il est inacceptable que ces personnes doivent attendre quatre heures le redimensionnement de leur avatar, simplement parce que nous optimisons la bibliothèque de 500 vidéos de quelqu’un d’autre pour un affichage sur iPad.

C’est pourquoi les files d’attente, et leur impact sur les différents cas d’usage, doivent être réduits au minimum :

Pour limiter l’impact, nous avons écrit des algorithmes capables de distinguer les Jobs qui doivent donner une impression de temps réel, comme l’envoi et le redimensionnement d’avatars, de ceux qui peuvent prendre un peu plus de temps, comme la conversion de grands lots de médias existants.

Attendre quatre heures de plus est désastreux pour le cas d’usage de trois secondes, alors qu’attendre trois secondes de plus ne pose aucun problème pour le cas d’usage de quatre heures. Les priorités comptent.

Bien sûr, ce serait encore mieux si les 4 heures pouvaient être ramenées à dix minutes.

Pour nous attaquer aux files d’attente elles-mêmes, nous savions qu’il nous fallait monter en charge. Comme nous l’avons dit, le trafic d’encodage peut être très irrégulier. Pour vider rapidement de longues files d’attente, il nous aurait fallu une capacité de base très importante.

Malheureusement, cette capacité n’aurait servi qu’à absorber les pics. Pendant 90 % du reste du temps, elle aurait pourri dans des centres de données, sa valeur partant en fumée. Il aurait été extrêmement difficile de faire de ce modèle une activité rentable.

C’est alors qu’Amazon est arrivé.

Le cloud d’Amazon

Amazon avait un problème similaire, avec des pics de trafic extrêmement importants pendant les soldes de Noël. Évidemment, l’entreprise ne pouvait refuser personne et devait investir dans autant de serveurs que nécessaire pour absorber ces pics.

Mais le reste de l’année, ce matériel coûteux ne lui rapportait pas un centime.

À peu près à la même époque, le service informatique d’Amazon cherchait des moyens d’exploiter la virtualisation pour rendre sa plateforme plus facile à maintenir. Le simple fait de pouvoir réinstaller la plupart des serveurs sans se rendre au centre de données représentait déjà un grand progrès. Jeff Bezos avait auparavant publié une note interne exigeant que tout service développé chez Amazon soit conçu de façon à pouvoir être facilement utilisé par d’autres entreprises.

Amazon a ensuite ouvert ses outils d’administration de la virtualisation au monde entier et a pu louer sa surcapacité, ce qui lui a permis de gagner un peu d’argent avec ces serveurs inactifs en dehors de la période de Noël.

Et c’est ainsi qu’est né le cloud 🐣. Ou du moins, c’est ma version simplifiée de l’histoire 😄. Si, en lisant ceci, vous pensez que je raconte n’importe quoi, dites-le-moi sur Twitter⁠ et j’affinerai ce glorieux récit.

Transloadit ❤️ Amazon

Comme nous l’avons dit, nous n’aurions pas pu nous offrir la capacité nécessaire pour absorber les pics. Nous aurions peut-être pu convaincre un investisseur de mettre la main au portefeuille, mais encore une fois : il est extrêmement difficile d’être rentable quand les machines ne font rien la plupart du temps.

Cependant, lorsque nous avons eu l’idée de Transloadit, Amazon venait de retirer la mention bêta de son offre cloud, AWS⁠, et nous pouvions louer de la capacité serveur à l’heure. Et grâce à son API, nous pouvions écrire un logiciel qui le faisait automatiquement, à mesure que le trafic augmentait.

Vous l’aurez compris, nous lui devons notre existence.

Plafonds de verre

Avec la promesse du cloud d’Amazon, nous pensions que le ciel était la seule limite. « Capacité illimitée ! » « Uniquement quand nous en avons vraiment besoin ! » Et je me souviens de notre joie lorsque nous tournions sur notre première machine musclée :

Mais il y avait des plafonds de verre. Quand nous avons essayé de lancer six machines, nous avons rencontré des erreurs. Il s’est avéré que :

Lorsque vous créez votre compte AWS, AWS définit des limites d’instances par région.

Notre limite était fixée à cinq machines, et une file d’attente que nous avions à l’époque a mis une éternité à se vider.

Nos échanges avec Amazon ont toujours été bons ; l’entreprise nous a même aidés à gagner en visibilité⁠ à nos débuts. Nous l’avons rapidement contactée, et elle nous a rapidement accordé un nouveau « plafond d’instances » de 20 machines maximum.

Ce fut une grande joie 😄, car cela validait ce que nous essayions de faire, et nous venions de briser un plafond de verre.

Depuis, nous avons dû contacter Amazon à quelques reprises pour relever notre plafond d’instances. La dernière fois, c’était le 5 novembre 2013, lorsqu’Amazon nous a accordé une limite de 500 machines dans notre centre de données principal.

Schémas de montée en charge

Récemment, nous avons vu le trafic repartir à la hausse selon ce schéma :

Le graphique montre que des machines sont ajoutées à mesure que des Jobs d’encodage arrivent dans la file d’attente, mais qu’une fois les 500 machines atteintes, la courbe s’aplatit et la file d’attente de 5 TB est traitée plus lentement que nous le souhaiterions.

Normalement, nous aurions envoyé un rapide e-mail à Amazon, mais il s’avère que :

Pour une augmentation de limite de cette ampleur, je dois collaborer avec notre équipe de service pour obtenir une approbation. Il s’agit de garantir que nous pouvons répondre à vos besoins tout en préservant la sécurité de l’infrastructure existante.

Je sais que, selon les estimations, Amazon dispose d’environ 450 000 serveurs (physiques)⁠, nous restons donc un petit poisson à son échelle. Néanmoins, le fait que l’entreprise ait dû planifier des ressources supplémentaires pour cette demande avait quelque chose d’enthousiasmant.

Vous comprendrez donc pourquoi mon enthousiasme est d’autant plus grand aujourd’hui, alors que nous venons de recevoir un e-mail indiquant :

J’ai le plaisir de vous informer que nous avons approuvé et traité votre demande d’augmentation de la limite d’instances EC2 pour les régions UE (Irlande) et Est des États-Unis (Virginie du Nord). La propagation et la mise à disposition peuvent parfois prendre jusqu’à 15 minutes.

Grâce à ce nouveau plafond d’instances, nous pouvons désormais déployer une flotte de 1000 machines aux États-Unis et de 500 dans l’UE, ce qui signifie que nous aurons plus que doublé notre capacité :

Cela ne veut pas dire que nous tournons déjà sur 1500 machines, mais disposer d’une telle marge dès aujourd’hui est une avancée majeure pour nous, et pouvoir l’exploiter nous aidera grandement à vider rapidement les files d’attente d’encodage de plusieurs téraoctets que nous voyons de plus en plus souvent ces derniers temps.

Pour vous, nos clients, cela signifie des temps d’encodage plus rapides, et nous pouvons traiter des imports massifs de vidéos HD comme s’il s’agissait d’un simple petit avatar ! 😉