Prerender.io é uma empresa que oferece um serviço de pré-renderização (como o próprio nome diz) de páginas dinâmicas geradas por JavaScript. O objetivo é entregar para robôs e, principalmente indexadores de busca, uma página HTML estática, enquanto usuários reais continuam navegando e experimentando o site em JavaScript.
Segundo a documentação oficial do Google, “em geral, o Googlebot não considera a renderização dinâmica como uma técnica de cloaking. Se a renderização dinâmica produzir conteúdo semelhante, o Googlebot não verá esse processo como uma técnica de cloaking”. O Google chega a recomendar nominalmente o Prerender.io como um dos serviços que oferecem esse recurso.
Diante dessa necessidade, Prerender.io tem gigantes como Spotify, Lyft e Comcast como clientes e já entregou 58 bilhões de páginas web para rastreadores de buscas. No momento atual, são manipuladas 70 mil páginas por minuto, com cerca de 560 milhões de páginas armazenadas. São números avassaladores. Toda essa demanda exige um nível de processamento e armazenamento astronômico.
Até recentemente, a empresa estava terceirizando suas necessidades para o Amazon Web Services e obtendo uma fatura de 800 mil dólares por ano. É uma reclamação de muitos desenvolvedores: a plataforma AWS é extremamente eficiente no que pretende fazer, mas seu custo é elevado. Em entrevista, Zsot Varga, chefe da engenharia e gerente da Prerender.io explicou como foi possível remover a Amazon Web Services de seu orçamento. Desta forma, o gasto anual das operações caiu de um milhão de dólares para 200 mil dólares.
A solução, é claro, foi cortar a dependência da nuvem e investir em infraestrutura nativa para tráfego e dados em cache. Toda essa migração foi realizada em apenas três meses.
O objetivo era reduzir custos, mantendo a mesma velocidade de prestação e qualidade de serviço. Migrações como essa precisam ser cuidadosamente planejadas e executadas, pois uma configuração incorreta ou má execução causaria tempo de inatividade para páginas da Web do cliente e cliques de mídia social e faria com que seus rankings de pesquisa fossem prejudicados e potencialmente aumentasse nossa taxa de abandono
Zsot Varga, chefe da engenharia e gerente da Prerender.io
Para executar essa migração com segurança, ela foi dividida em três fases. Cada fase poderia ser revertida para a anterior com facilidade em caso de falha, sem degradação de serviço ou downtime.
Fase 1 – Testes (de 4 a 6 semanas)
Nessa primeira fase, foram configurados os servidores que iriam receber o projeto, utilizando Linux KVM, com o mínimo de adaptação de software. A proposta era realizar uma migração em pequena escala para avaliar os resultados e ajustar as configurações. Inicialmente, apenas 1% do tráfego total da Prerender foi redirecionado para os servidores de teste.
Em apenas quinze dias, já foi possível obter uma economia de 800 dólares por dia nos custos de operação da empresa. No final do primeiro mês da transição, boa parte da carga de tráfego já havia sido redirecionada da AWS para os servidores internos da Prerender.
De acordo com Varga, “a fase de teste foi crucial para garantir que os processos a seguir fossem executados sem problemas”. O sucesso dessa fase foi possível graças à implementação de sistemas de monitoramento e tratamento de erros. Apesar dos servidores já apresentarem um painel de monitoramento também foi configurado um painel de monitoramento dedicado à renderização de páginas.
Fase 2 – Configuração Técnica (4 semanas)
A transição do tráfego funcionou como prova de conceito, como uma forma de constatar que era possível escapar da dependência da AWS com uma solução interna, reduzir custos no processo e ainda realizar essa mudança de forma ininterrupta, imperceptível para seus clientes. O desafio maior viria depois: migrar o cache armazenado na nuvem.
No final do processo, a Prerender tinha 300 servidores internos responsáveis por 200 milhões de páginas em cache. Foram utilizados nós do Apache Cassandra em cada um dos servidores que eram compatíveis com o AWS S3.
A grande sacada da migração foi não migrar a totalidade do que estava armazenado no S3, mas permitir que esse conteúdo expirasse naturalmente de forma progressiva. “O verdadeiro preço oculto da AWS vem do custo do tráfego, eles vendem um armazenamento com preços razoáveis e é até gratuito para fazer upload. Mas quando você move esse material, você paga um custo enorme”, explicou Varga. Custaria 5 mil dólares a mais para mover esse conteúdo, então a solução mais sensata foi deixar esse “restinho” de cache expirar no S3.
Fase 3 – Implementação e escalonamento (4 a 6 semanas)
Na terceira etapa, foi necessário migrar todas as instâncias do Amazon RDS, partição por partição. Felizmente, graças à eficiência das etapas anteriores, essa foi a menos afetada por erros ou gargalos, uma vez que boa parte dos dados já estava residindo nos servidores locais.
De acordo com Varga, foi obedecido o seguinte processo:
- Foram espelhadas as partições do PostgreSQL, armazenando tabelas de URLs cacheadas no Cassandra;
- Foi alterado o service.prerender.io para o balanceador de carga da Cloudflare, para permitir a distribuição dinâmica de tráfego;
- Foram configurados novos servidores de cache privado da União Europeia;
- Foram realizados testes de estresse para resolver quaisquer problemas de desempenho.
O sucesso da migração como um todo só foi possível graças ao planejamento meticuloso de cada etapa, com testes de implementação antes do dimensionamento.
