Ampliamos a Singapur para un mejor servicio en Asia-Pacífico
Apertura en Singapur
Transloadit opera actualmente desde dos centros de datos principales, uno en EE. UU. (Virginia del
Norte) y otro en la UE (Irlanda). La mayoría de nuestros usuarios reciben un buen servicio con
ellos, pero para las personas en Japón o Australia todavía podíamos hacerlo mejor. Por eso abriremos
un tercer centro de datos en Singapur (también llamado: Asia-Pacífico, AP, o: ap-southeast-1) para
ofrecer latencias mucho más bajas en toda la región.
Ya casi terminamos de montarlo todo y hemos aprovechado la ocasión para hacer también otros cambios importantes en nuestra configuración de red. AP ya contará con ellos desde el principio, y la UE y EE. UU. los recibirán pronto también.
En resumen, migraremos a las VPC (Virtual Private Clouds) y los NLB (Network Load Balancers) de Amazon. Pongámonos técnicos con algo de tecnología de redes de AWS 👩💻
Virtual Private Clouds
Como muchas otras empresas, Transloadit se apoya en AWS. Cuando empezamos en 2009, AWS tenía apenas tres años y muchas funciones que hoy resulta obvio usar todavía no existían. Una de esas decisiones evidentes es desplegar una VPC.
Una VPC ofrece seguridad mejorada y controles organizativos. Por ejemplo, te permite aislar máquinas por completo de internet y usar ACL de red para controlar qué tráfico se permite entre los distintos segmentos de tu red.
Además, muchas de las nuevas funciones y tipos de máquina que ofrece AWS solo están disponibles
dentro de las VPC. Le hemos echado el ojo a varios tipos de máquina nuevos que ofrecen mayor
rendimiento a menor costo, y que por fin podremos aprovechar una vez que hayamos migrado del todo
a VPC en todos los centros de datos. Como mencionamos, Singapur ya cuenta con una VPC. Esto
introduce algunos cambios en nuestros firewalls que podrían llegar a perjudicar a clientes con
configuraciones que requieren conexiones salientes a puertos no estándar. Un ejemplo sería alguien
que usa nuestro Robot /html/convert para hacer una captura de pantalla de un url,
como https://example.com:1234/.
Ponte en contacto con nosotros si esto te supone un problema, ya que, de forma predeterminada, ya no permitimos conexiones salientes a puertos arbitrarios.
Network Load Balancers
Hasta ahora, tanto nuestro centro de datos de EE. UU. como el de la UE usaban el Elastic Load Balancer (ELB) de AWS para distribuir el tráfico entrante entre muchas máquinas distintas. Hace poco, Amazon presentó dos nuevos tipos de balanceadores de carga y renombró el existente como «Classic»:
- Classic Load Balancer (ELB)
- Application Load Balancer (ALB)
- Network Load Balancer (NLB)
El ALB puede verse como una evolución del ELB. Ambos son balanceadores de carga de capa 7, lo que significa que pueden «entender» el tráfico HTTP y, por ejemplo, encargarse de la terminación SSL, para que tus servidores backend no tengan que preocuparse por SSL. El ALB ofrece ventajas adicionales, como poder enrutar el tráfico a distintos servidores según la URL.
El recién presentado Network Load Balancer es otra cosa por completo. Opera en la capa 4, lo que significa que ignora felizmente cosas como HTTP y enruta el tráfico a las máquinas backend a nivel de paquetes IP. Esto los hace menos ricos en funciones (sin terminación SSL ni enrutamiento basado en la URL), pero mucho más potentes. Es posible gestionar millones de peticiones por segundo con latencias mucho más bajas, por varias razones.
En cuanto a que el balanceador de carga ya no pueda encargarse de SSL, hemos decidido que es algo bueno. Al fin y al cabo, con la terminación, AWS descifraría el tráfico y este llegaría sin cifrar a nuestros servidores backend de todos modos. Es solo el último salto, pero aun así: encargarnos nosotros mismos del descifrado en la última estación reduce la superficie de ataque.
Otra razón para abandonar el ELB clásico es que, si esperabas un pico de tráfico, tenías que contactar con el soporte de AWS para que precalentaran los balanceadores de carga por ti o arriesgarte a sufrir una limitación severa durante un tiempo. ¡No es nada ideal! Está claro por qué AWS recomienda ahora dejar de usarlos, y eso es exactamente lo que estamos haciendo, empezando por nuestro nuevo centro de datos de Singapur.
Estamos deseando ver las latencias más bajas y la seguridad mejorada que estos cambios aportarán a tus usuarios finales, pero también es bueno ser siempre cautelosos.
Pruebas
Creemos que es poco probable que estos NLB causen algún problema, pero tampoco queremos dar nada por
sentado. Hay diferencias en cómo fluye el tráfico y en la forma en que se termina SSL, lo que
significa que siempre existe riesgo de que algo se rompa. Así que, si te interesa, ya puedes probar
nuestro endpoint https://api2-ap-southeast-1.transloadit.com en tu entorno de staging para ver si las
conexiones se establecen correctamente.
Ten en cuenta que es de esperar que surjan algunos problemas, ya que Singapur:
- sigue en proceso de cambios y no funciona a plena capacidad, por lo que el rendimiento del encoding será peor
- tendrá latencias más altas si lo pruebas desde EE. UU. o la UE. Normalmente, al llamar a
https://api2.transloadit.com, el tráfico de EE. UU. simplemente se enrutaría a nuestro DC de EE. UU., mientras que las personas en, por ejemplo, Tokio se enrutarían a Singapur. Pero durante las pruebas, es posible que ahora nos estés pidiendo explícitamente que gestionemos el tráfico en un DC más alejado de ti
A pesar de estas limitaciones, Singapur ya se puede usar para comprobar si tu aplicación e integración son compatibles con nuestra nueva configuración de red. Ponte en contacto con nosotros si tus pruebas fallan, así podremos descartar problemas juntos.
Para concluir
Estos son los cambios más grandes que creemos que podrían afectar a nuestros clientes, pero hemos recreado toda nuestra infraestructura desde cero, así que podría haber otras diferencias sutiles. Por eso primero probaremos Singapur a fondo antes de desplegar estos cambios en nuestros centros de datos existentes, y te pedimos que hagas lo mismo.
Tenemos previsto lanzar Singapur el 7 de enero de 2019 (es decir, dentro de unas dos semanas); esto afectará solo a los usuarios finales de la región de Asia-Pacífico (mejorando sus latencias). Ten en cuenta que podemos dejar de enviarle tráfico fácilmente a la primera señal de problemas, haciendo que la UE y EE. UU. vuelvan a repartirse esa carga, como si nada hubiera pasado.
Si todo va bien, nuestro objetivo es desplegar estos cambios en los centros de datos existentes de EE. UU. y la UE antes de que termine enero de 2019.
Al crear Singapur, hemos estandarizado la forma en que se aprovisionan los centros de datos, así que abrir un centro de datos más allá de Singapur nos resulta ahora muy sencillo. ¡Te tengo echado el ojo, São Paulo! 👀😄
Si tienes preguntas o dudas, no dudes en ponerte en contacto con nosotros.