Expansão para Singapura por um serviço melhor na Ásia-Pacífico

Inauguração em Singapura

Atualmente, a Transloadit opera a partir de dois data centers principais, um nos EUA (Norte da Virgínia) e outro na UE (Irlanda). A maioria dos nossos usuários é bem atendida por eles, mas para quem está no Japão ou na Austrália, ainda poderíamos fazer melhor. Por isso, estamos abrindo um terceiro data center em Singapura (também chamado de Ásia-Pacífico, AP ou ap-southeast-1) para oferecer latências muito menores para toda a região.

Estamos quase terminando a instalação e aproveitamos a oportunidade para fazer também outras grandes mudanças na nossa configuração de rede. A AP já contará com elas desde o início, e a UE e os EUA também as receberão em breve.

Em resumo, faremos a transição para VPCs (Virtual Private Clouds) e NLBs (Network Load Balancers) da Amazon. Vamos mergulhar a fundo em um pouco de tecnologia de rede da AWS 👩‍💻

Virtual Private Clouds

Como muitas outras empresas, a Transloadit é construída sobre a AWS. Quando começamos, em 2009, a AWS tinha apenas três anos e muitos recursos que hoje são de uso óbvio ainda não existiam. Uma dessas escolhas óbvias é implantar uma VPC.

Uma VPC oferece segurança reforçada e controles organizacionais. Por exemplo, ela permite isolar máquinas completamente da internet e usar ACLs de rede⁠ para controlar qual tráfego é permitido entre diferentes segmentos da sua rede.

Além disso, muitos dos novos recursos e tipos de máquina que a AWS oferece só estão disponíveis dentro de VPCs. Estamos de olho em vários novos tipos de máquina que entregam mais desempenho a custos menores, e finalmente poderemos utilizá-los quando tivermos migrado totalmente para VPCs em todos os data centers. Como mencionado, Singapura já está equipada com uma VPC. Isso traz algumas mudanças nos nossos firewalls que podem prejudicar clientes com configurações que exigem conexões de saída para portas não padrão. Um exemplo seria alguém usando o Robot /html/convert para tirar uma captura de tela de um url, como https://example.com:1234/.

Entre em contato caso isso seja um problema para você, pois, por padrão, não permitimos mais conexões de saída para portas arbitrárias.

Network Load Balancers

Até agora, nossos data centers nos EUA e na UE usavam o Elastic Load Balancer (ELB) da AWS para distribuir o tráfego de entrada entre muitas máquinas diferentes. Recentemente, a Amazon lançou dois novos tipos de balanceadores de carga e renomeou o existente para “Classic”:

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

O ALB pode ser visto como uma evolução do ELB. Ambos são balanceadores de carga de camada 7⁠, o que significa que conseguem “entender” o tráfego HTTP e, por exemplo, fazer a terminação SSL, para que seus servidores de backend não precisem se preocupar com SSL. O ALB oferece vantagens adicionais, como a capacidade de rotear o tráfego para servidores diferentes dependendo da URL.

O recém-lançado Network Load Balancer é algo completamente diferente. Ele opera na camada 4⁠, o que significa que ignora alegremente coisas como HTTP e roteia o tráfego para as máquinas de backend no nível dos pacotes IP. Isso os torna menos ricos em recursos (sem terminação SSL nem roteamento baseado em URL), mas muito mais poderosos. É possível lidar com milhões de requisições por segundo com latências muito menores, por vários motivos⁠.

Quanto a não podermos mais lidar com SSL no balanceador de carga, concluímos que isso é algo bom. Afinal, com a terminação, o tráfego seria descriptografado pela AWS e seguiria sem criptografia até nossos servidores de backend de qualquer forma. É apenas o último salto, mas ainda assim: cuidar nós mesmos da descriptografia na última estação reduz a superfície de ataque.

Outro motivo para abandonar o ELB clássico é que, se você esperasse um pico de tráfego, precisava entrar em contato com o suporte da AWS para pré-aquecer os balanceadores de carga para você⁠ ou corria o risco de sofrer uma limitação severa por algum tempo. Nada bom! Fica claro por que a AWS agora recomenda deixá-los de lado, e é exatamente isso que estamos fazendo, começando pelo nosso novo data center em Singapura.

Estamos ansiosos pelas latências menores e pela segurança reforçada que essas mudanças vão proporcionar aos seus usuários finais, mas também é sempre bom ter cautela.

Testes

Achamos improvável que esses NLBs causem algum problema, mas também não queremos fazer suposições. Há diferenças na forma como o tráfego flui e no modo como a terminação SSL é feita, o que significa que sempre existe o risco de algo quebrar. Então, se isso for importante para você, já é possível testar nosso endpoint https://api2-ap-southeast-1.transloadit.com no seu ambiente de staging para verificar se as conexões são estabelecidas corretamente.

Observe que alguns problemas são esperados, já que Singapura:

• ainda está passando por mudanças e não está operando com capacidade total, então o desempenho de codificação será pior
• terá latências maiores se você testar a partir dos EUA ou da UE. Normalmente, ao acessar https://api2.transloadit.com, o tráfego dos EUA seria simplesmente roteado para nosso data center nos EUA, enquanto pessoas em, por exemplo, Tóquio seriam roteadas para Singapura. Mas, durante os testes, você pode estar nos pedindo explicitamente para processar o tráfego em um data center mais distante de você

Apesar dessas limitações, Singapura já pode ser usada para testar se seu app e sua integração são compatíveis com nossa nova configuração de rede. Entre em contato caso seus testes falhem, para que possamos descartar problemas juntos.

Conclusão

Essas são as maiores mudanças que achamos que podem afetar nossos clientes, mas recriamos toda a nossa infraestrutura do zero, então pode haver outras diferenças sutis. Por isso, primeiro vamos testar Singapura com rigor antes de levar essas mudanças aos nossos data centers existentes, e pedimos que você faça o mesmo.

Pretendemos lançar Singapura em 7 de janeiro de 2019 (ou seja, daqui a cerca de duas semanas), e isso afetará apenas os usuários finais da região Ásia-Pacífico (melhorando as latências para eles). Observe que podemos facilmente parar de enviar tráfego para lá ao primeiro sinal de problema, fazendo com que a UE e os EUA voltem a dividir essa carga, como se nada tivesse acontecido.

Se tudo correr bem, nosso objetivo é levar essas mudanças aos data centers existentes nos EUA e na UE antes do fim de janeiro de 2019.

Ao criar Singapura, padronizamos a forma como os data centers são provisionados, então ficou muito simples para nós abrir um data center além de Singapura. Estou de olho em você, São Paulo! 👀😄

Se você tiver dúvidas ou preocupações, entre em contato.