Expansion à Singapour pour un meilleur service en Asie-Pacifique

Ouverture à Singapour

Transloadit opère actuellement depuis deux centres de données principaux, l’un aux États-Unis (Virginie du Nord) et l’autre dans l’UE (Irlande). La plupart de nos utilisateurs sont bien servis par ceux-ci, mais pour les personnes situées au Japon ou en Australie, nous pouvions encore mieux faire. Nous ouvrons donc un troisième centre de données à Singapour (également appelé Asie-Pacifique, AP, ou ap-southeast-1) afin d’offrir des latences bien plus faibles à toute la région.

Nous avons presque fini de nous installer et en avons profité pour apporter d’autres changements importants à notre configuration réseau. AP en sera équipé dès le départ, et l’UE et les États-Unis en bénéficieront bientôt aussi.

En bref, nous allons passer aux VPC Amazon (Virtual Private Clouds) et aux NLB (Network Load Balancers). Plongeons un peu dans la technique réseau d’AWS 👩‍💻

Clouds privés virtuels

Comme beaucoup d’autres entreprises, Transloadit s’appuie sur AWS. Quand nous avons commencé en 2009, AWS n’avait que trois ans et de nombreuses fonctionnalités qui semblent évidentes aujourd’hui n’existaient pas encore. Le déploiement d’un VPC fait partie de ces évidences.

Un VPC offre une sécurité renforcée et des contrôles organisationnels. Par exemple, il permet d’isoler complètement des machines d’internet et d’utiliser des ACL réseau⁠ pour contrôler le trafic autorisé entre les différents segments de votre réseau.

De plus, de nombreuses nouvelles fonctionnalités et de nombreux types de machines proposés par AWS ne sont disponibles qu’au sein de VPC. Nous surveillions plusieurs nouveaux types de machines qui offrent de meilleures performances à moindre coût, et que nous pourrons enfin utiliser une fois que nous serons entièrement passés aux VPC dans tous nos centres de données. Comme indiqué, Singapour est déjà équipé d’un VPC. Cela entraîne quelques changements dans nos pare-feu, qui pourraient éventuellement poser problème aux clients dont la configuration nécessite des connexions sortantes vers des ports non standard. Ce pourrait être le cas, par exemple, de quelqu’un qui utilise notre Robot /html/convert pour faire une capture d’écran d’un url, comme https://example.com:1234/.

N’hésitez pas à nous contacter si cela vous pose problème, car par défaut, nous n’autorisons plus les connexions sortantes vers des ports arbitraires.

Répartiteurs de charge réseau

Jusqu’à présent, nos centres de données américain et européen utilisaient tous deux l’Elastic Load Balancer (ELB) d’AWS pour répartir le trafic entrant entre de nombreuses machines. Récemment, Amazon a lancé deux nouveaux types de répartiteurs de charge et a renommé celui qui existait déjà en « Classic » :

• Classic Load Balancer (ELB)
• Application Load Balancer (ALB)
• Network Load Balancer (NLB)

L’ALB peut être vu comme une évolution de l’ELB. Tous deux sont des répartiteurs de charge de couche 7⁠, ce qui signifie qu’ils peuvent « comprendre » le trafic HTTP et, par exemple, gérer la terminaison SSL, afin que vos serveurs backend n’aient pas à se soucier du SSL. L’ALB offre des avantages supplémentaires, comme la possibilité d’acheminer le trafic vers différents serveurs en fonction de l’URL.

Le Network Load Balancer, nouvellement introduit, est d’une tout autre nature. Il opère sur la couche 4⁠, ce qui signifie qu’il ignore tout de choses comme HTTP et achemine le trafic vers les machines backend au niveau des paquets IP. Il offre donc moins de fonctionnalités (pas de terminaison SSL ni de routage basé sur l’URL), mais il est beaucoup plus puissant. Il permet de traiter des millions de requêtes par seconde avec des latences bien plus faibles, pour plusieurs raisons⁠.

Quant au fait de ne plus pouvoir gérer le SSL sur le répartiteur de charge, nous avons décidé que c’était une bonne chose. Après tout, avec la terminaison, le trafic serait de toute façon déchiffré par AWS et circulerait non chiffré jusqu’à nos serveurs backend. Ce n’est que le dernier saut, mais tout de même : gérer nous-mêmes le déchiffrement à la toute dernière étape réduit la surface d’attaque.

Une autre raison d’abandonner l’ELB classique : si vous anticipiez un pic de trafic, vous deviez contacter le support AWS pour qu’il préchauffe les répartiteurs de charge pour vous⁠, sous peine de subir un bridage sévère pendant un certain temps. Pas génial ! On comprend pourquoi AWS recommande désormais de les abandonner, et c’est exactement ce que nous faisons, en commençant par notre nouveau centre de données de Singapour.

Nous nous réjouissons des latences plus faibles et de la sécurité renforcée que ces changements apporteront à vos utilisateurs finaux, mais il est toujours bon de rester prudent.

Tests

Nous pensons qu’il est peu probable que ces NLB causent des problèmes, mais nous ne voulons pas non plus faire de suppositions. Il existe des différences dans la manière dont le trafic circule et dont le SSL est terminé, ce qui implique toujours un risque de dysfonctionnement. Donc, si cela vous importe, vous pouvez déjà essayer notre point de terminaison https://api2-ap-southeast-1.transloadit.com dans votre environnement de préproduction pour vérifier que les connexions s’établissent correctement.

Notez que certains problèmes sont à prévoir, car Singapour :

• est encore en cours de modification et ne fonctionne pas à pleine capacité, donc les performances d’encodage seront moins bonnes
• aura des latences plus élevées si vous testez depuis les États-Unis ou l’UE. Normalement, lorsque vous appelez https://api2.transloadit.com, le trafic américain est simplement acheminé vers notre centre de données américain, tandis que les personnes situées, par exemple, à Tokyo sont acheminées vers Singapour. Mais pendant vos tests, il se peut que vous nous demandiez explicitement de traiter le trafic dans un centre de données plus éloigné de vous

Malgré ces inconvénients, Singapour peut déjà être utilisé pour tester si votre application et votre intégration sont compatibles avec notre nouvelle configuration réseau. N’hésitez surtout pas à nous contacter si vos tests échouent, afin que nous puissions écarter les problèmes ensemble.

Conclusion

Ce sont les changements les plus importants qui, selon nous, pourraient affecter nos clients, mais nous avons recréé toute notre infrastructure de zéro, il pourrait donc y avoir d’autres différences subtiles. C’est pourquoi nous allons d’abord tester Singapour de manière rigoureuse avant de déployer ces changements dans nos centres de données existants, et nous vous demandons de faire de même.

Nous prévoyons de lancer Singapour le 7 janvier 2019 (soit dans environ deux semaines). Cela n’affectera que les utilisateurs finaux de la région Asie-Pacifique (en améliorant leurs latences). Notez que nous pouvons facilement cesser d’y envoyer du trafic au premier signe de problème, et laisser l’UE et les États-Unis se partager à nouveau cette charge, comme si de rien n’était.

Si tout se passe bien, notre objectif est de déployer ces changements dans les centres de données existants des États-Unis et de l’UE avant la fin janvier 2019.

En créant Singapour, nous avons standardisé le provisionnement des centres de données, si bien qu’il est devenu très simple pour nous d’ouvrir un centre de données ailleurs qu’à Singapour. São Paulo, je t’ai à l’œil ! 👀😄

Si vous avez des questions ou des préoccupations, n’hésitez pas à nous contacter.