Transloadit escala para 1500 máquinas e acelera a codificação

Codificar é um trabalho pesado para servidores. Quando começamos este negócio, sabíamos desde o início que seria muito mais fácil para os clientes nos enviar Jobs do que para nós processá-los. Com picos altamente variáveis de Jobs de codificação e um orçamento finito, filas são inerentes a este negócio.

Quem disser o contrário ou não está operando em escala ou está perdendo dinheiro.

Picos e filas

Algumas pessoas integram os recursos de upload da Transloadit para que seus usuários finais possam enviar avatares para seus sites. Obviamente, não é aceitável que essas pessoas tenham que esperar quatro horas para que o avatar seja redimensionado só porque estamos otimizando a biblioteca de 500 vídeos de outra pessoa para exibição no iPad.

Por esse motivo, as filas e o impacto delas em diversos casos de uso precisam ser minimizados:

Para lidar com o impacto, escrevemos algoritmos capazes de distinguir Jobs que devem ter uma sensação de tempo real, como o upload e o redimensionamento de avatares, de Jobs que podem levar um pouco mais de tempo, como a conversão de grandes lotes de mídia já existente.

Esperar quatro horas a mais é desastroso para o caso de uso de três segundos, enquanto esperar três segundos a mais não é problema para o caso de uso de quatro horas. Prioridades importam.

Claro que seria ainda melhor se as 4 horas pudessem ser reduzidas para dez minutos.

Para lidar com as filas em si, sabíamos que precisávamos escalar. Como mencionado, o tráfego de codificação pode ser altamente irregular. Para esvaziar filas longas rapidamente, precisaríamos de uma capacidade base muito grande.

Infelizmente, precisaríamos dessa capacidade só para lidar com os picos. Nos outros 90% do tempo, ela ficaria apodrecendo em data centers, evaporando seu valor. Seria extremamente difícil transformar esse modelo em um negócio lucrativo.

Foi aí que surgiu a Amazon.

A nuvem da Amazon

A Amazon tinha um problema parecido, com picos de tráfego extremamente grandes durante as vendas de Natal. Obviamente, ela não podia recusar ninguém e precisava investir em quantos servidores fossem necessários para lidar com esses picos.

Mas, no resto do ano, esse equipamento caro não gerava dinheiro nenhum.

Nessa época, o departamento de TI da Amazon estava buscando formas de usar a virtualização para tornar a plataforma mais fácil de manter. Só poder reinstalar a maioria dos servidores sem precisar ir ao data center já era uma grande vitória. Jeff Bezos havia emitido um memorando antes, determinando que todo serviço construído dentro da Amazon deveria ser projetado de forma que outras empresas também pudessem usá-lo com facilidade.

Em seguida, a Amazon abriu suas ferramentas de administração de virtualização para o mundo e passou a alugar sua capacidade excedente, o que permitiu ganhar algum dinheiro com esses servidores ociosos fora da época de Natal.

E foi assim que a nuvem nasceu 🐣. Ou, pelo menos, essa é a minha versão simplificada 😄 - se você está lendo isto e achando que estou falando bobagem, me avise no Twitter⁠ e eu vou aprimorar esta gloriosa história.

Transloadit ❤️ Amazon

Como mencionado, não teríamos condições de bancar o tipo de capacidade necessária para lidar com os picos. Talvez conseguíssemos convencer um investidor a desembolsar esse valor, mas, como dito, é extremamente difícil ter lucro quando as máquinas ficam sem fazer nada na maior parte do tempo.

Porém, quando tivemos a ideia da Transloadit, a Amazon tinha acabado de tirar o rótulo beta da sua oferta de nuvem, a AWS⁠, e pudemos alugar capacidade de servidor por hora. E, graças à API deles, conseguimos escrever um software que fazia isso automaticamente conforme o tráfego aumentava.

Como você pode ver, devemos nossa existência a eles.

Tetos de vidro

Com a promessa da nuvem da Amazon, achamos que o céu era o limite. “Capacidade ilimitada!” “Só quando realmente precisarmos!”. E eu me lembro de como ficamos felizes rodando na nossa primeira máquina robusta:

Mas havia alguns tetos de vidro. Quando tentamos iniciar seis máquinas, encontramos erros. No fim, descobrimos que:

Quando você cria sua conta da AWS, a AWS define limites de instâncias por região.

Nosso limite era de cinco máquinas, e uma fila que tínhamos na época levou uma eternidade para esvaziar.

Sempre tivemos boas experiências com a Amazon, que até nos ajudou a ganhar alguma visibilidade⁠ no início. Entramos em contato rapidamente, e eles foram rápidos em nos conceder um novo “teto de instâncias” máximo de 20 máquinas.

Ficamos empolgados 😄, porque isso validava o que estávamos tentando fazer, e tínhamos acabado de romper um teto de vidro.

Desde então, precisamos entrar em contato com a Amazon mais algumas vezes para aumentar nosso teto de instâncias. A última vez foi em 5 de novembro de 2013, quando a Amazon nos concedeu um limite de 500 máquinas no nosso data center principal.

Padrões de escalonamento

Recentemente, temos visto o tráfego voltar a crescer seguindo este padrão:

O gráfico mostra que as máquinas são escaladas conforme Jobs de codificação chegam à fila, mas, ao chegarmos a 500 máquinas, a linha fica estável e a fila de 5 TB é processada mais lentamente do que gostaríamos.

Normalmente, mandaríamos um e-mail rápido para a Amazon, mas acontece que:

Para um aumento de limite desse tamanho, precisarei colaborar com nossa equipe de serviço para obter aprovação. Isso serve para garantir que possamos atender às suas necessidades mantendo a infraestrutura existente segura.

Sei que a Amazon tem, segundo estimativas, cerca de 450.000 servidores (de hardware)⁠, então, na escala deles, ainda somos peixe pequeno. Mesmo assim, o fato de terem precisado fazer um planejamento extra de recursos para esse pedido foi empolgante.

Você deve entender por que hoje estou ainda mais empolgado por termos acabado de receber um e-mail dizendo:

Tenho o prazer de informar que aprovamos e processamos sua solicitação de aumento de limite de instâncias EC2 para as regiões UE (Irlanda) e Leste dos EUA (Norte da Virgínia). Às vezes, pode levar até 15 minutos para que isso se propague e fique disponível para uso.

Graças a esse novo teto de instâncias, agora podemos escalar uma frota de 1000 máquinas nos EUA e 500 na UE - o que significa que teremos mais que dobrado nossa capacidade:

Isso não quer dizer que já estejamos rodando em 1500 máquinas, mas ter essa margem a partir de hoje é um avanço para nós, e poder usá-la vai ajudar muito a esvaziar rapidamente as filas de codificação de vários terabytes que temos visto com mais frequência ultimamente.

Para você, como cliente, isso significa tempos de codificação mais rápidos e que conseguimos lidar com importações massivas de vídeo HD como se fossem só um pequeno avatar! 😉