Entrevista com Zsolt Varga, líder de tecnologia e gerente geral da Prerender

Esta semana entrevistamos Zsot Varga, o engenheiro e gerente principal do Prerender.io. Ele compartilha como a Prerender economizou US $ 800k removendo sua dependência da AWS e construindo infraestrutura interna para lidar com tráfego e armazenar dados em cache.

“O objetivo era reduzir custos, mantendo a mesma velocidade de renderização e qualidade de serviço. Migrações como essa precisam ser cuidadosamente planejadas e executadas, como configuração incorreta ou execução ruim, causariam tempo de inatividade para páginas da web de clientes e cliques nas mídias sociais e fariam seus rankings de pesquisa sofrerem e potencialmente aumentarem nossa taxa de rotatividade.

Você pode descrever Prerender e o problema técnico mais interessante que você está resolvendo

Prerender, em termos simples, caches e pré-renderenda suas páginas JavaScript para que os motores de busca possam ter um arquivo HTML puro para rastrear e indexar, e tudo o que ele precisa é ter o middleware adequado instalado no site, evitando os usuários a dor de soluções de soluções de JavaScript caros e longos.

No entanto, todos esses dados e processos precisam acontecer em um servidor e, é claro, usamos a AWS para isso. Alguns anos de crescimento depois, estamos lidando com mais de 70.000 páginas por minuto, armazenando cerca de 560 milhões de páginas e pagando bem mais de US $ 1.000.000 por ano.

Ou pelo menos estaríamos pagando muito se ficávamos com a AWS. Em vez disso, conseguimos reduzir os custos em 80% em pouco mais de três meses com algum pensamento fora da caixa e um plano claro. Aqui está como você poderia também.

Planejando uma migração: nosso guia passo a passo

Até recentemente, a Prerender armazenava as páginas em cache e renderiza para seus clientes usando servidores e serviços hospedados na Amazon Web Services (AWS) – sendo a AWS um dos maiores provedores de nuvem, oferecendo servidores virtuais e serviços gerenciados.

A pré-rrender até então usou a AWS para armazenar as páginas em cache até que estivessem prontas para serem captadas pelo Google, pelo Facebook ou por qualquer outro bot/derramista que procurasse conteúdo a ser indexado. Isso forneceu grande parte da funcionalidade da Prerender – entrega de HTML estático para o Google e outros mecanismos de pesquisa e JavaScript dinâmico e interativo para usuários humanos.

O problema? Armazenar vários terabytes de conteúdo de página da web pré-renderizada dessa maneira em um servidor de terceiros é extremamente caro. Armazenar as páginas em cache dessa maneira estava custando à Prerender quantias astronômicas de dinheiro apenas em taxas de manutenção e hospedagem.

Mas havia outro problema que muitas startups não levam em conta e não há muita conversa em torno disso: o custo do tráfego.

Obter dados para a AWS é tecnicamente gratuito, mas de bom que é dados estáticos para a maioria dos softwares? Ao mover os dados em torno dele se tornou um enorme custo para Prerender e começamos a notar o gargalo que estava nos segurando.

A solução? Migre as páginas em cache e o tráfego para os servidores internos da Prerender e reduza nossa dependência da AWS o mais rápido possível.

Quando fizemos uma projeção de custo, estimamos que poderíamos reduzir nossas taxas de hospedagem em 40% e decidimos que uma migração de servidor economizaria tanto a Prerender quanto o dinheiro de nosso cliente.

O objetivo era reduzir custos, mantendo a mesma velocidade de renderização e qualidade do serviço. Migrações como essa precisam ser cuidadosamente planejadas e executadas, como configuração incorreta ou má execução, causariam tempo de inatividade para páginas da web de clientes e cliques nas mídias sociais e fariam seus rankings de pesquisa sofrerem e potencialmente aumentarem nossa taxa de rotatividade.

Para mitigar as possíveis consequências, planejamos um processo de três fases pelo qual poderíamos facilmente reverter para a etapa anterior se algo der errado. Se, por qualquer motivo, os novos servidores não funcionassem, poderíamos facilmente reverter nossas alterações sem qualquer tempo de inatividade ou degradação do serviço perceptível para os clientes.

A ressalva com testes contínuos e sistemáticos é que ocorre ao longo de semanas e meses.

Movendo a Prerender A partir da AWS: uma visão geral semanal

Fase 1 — Testes (4 a 6 Semanas)

A Fase 1 envolveu principalmente a configuração dos servidores de metal nua e testar a migração em uma configuração pequena e mais gerenciável antes de escalar. Essa fase exigiu adaptação mínima do software, que decidimos rodar na virtualização do KVM no Linux.

No início de maio, o primeiro lote de servidores estava em execução e 1% do tráfego Prerender foi direcionado para os novos servidores. Duas semanas depois da migração, já estávamos economizando US $ 800 por dia. No final do mês, migramos a maioria das cargas de trabalho de tráfego para longe da AWS, reduzindo os custos diários de carga de carga de processamento de cromo em 45%.

No lado do servidor, nosso custo era atualmente de US $ 13 mil por mês. Combinado com a AWS, já tínhamos reduzido nossas despesas em 22%.

A fase de testes foi crucial para garantir que os seguintes processos funcionariam sem problemas. Trabalhamos para melhorar a robustez do sistema com mais monitoramento e melhor tratamento de erros. Além do painel de monitoramento do servidor que já tínhamos, também configuramos um novo painel de monitoramento de renderização para detectar qualquer problema de erro ou desempenho que ocorresse.

Graças ao nosso monitoramento constante e comunicação clara, os testes foram bem-sucedidos, nossas projeções de economia foram superadas e tudo estava em vigor para iniciar a fase 2 da migração.

Fase 2 — Configuração técnica (4 semanas)

O período de migração entre junho e início de julho foi principalmente técnico após a primeira fase da migração servir como prova de conceito. A implementação da segunda fase envolveu principalmente mover o armazenamento de cache para os servidores de metal nu.

Quando a migração chegou a meados de junho, tínhamos 300 servidores funcionando muito bem com um total de 200 milhões de páginas em cache. Usamos nós Apache Cassandra em cada um dos servidores compatíveis com o AWS S3.

Nós dividimos a migração online em quatro etapas, cada uma ou duas vezes. Depois de testar se as páginas Prerender poderiam ser armazenadas em cache no S3 e no minio, desviamos lentamente o tráfego do AWS S3 para o minio. Quando as gravações no S3 foram interrompidas completamente, a Prerender economizou US $ 200 por dia nos custos da API S3 e sinalizou que estávamos prontos para começar a excluir dados já armazenados em cache em nosso cluster Cassandra.

No entanto, a grande revelação veio no final desta fase por volta de 24 de junho. Nas últimas quatro semanas, transferimos a maior parte da carga de trabalho de cache do AWS S3 para o nosso próprio cluster Cassandra. O custo diário da AWS foi reduzido para US $ 1,1 mil por dia, projetado para 35K por mês, e o custo recorrente mensal dos novos servidores foi estimado em cerca de 14K.

Neste ponto, ainda havia algumas sobras no S3, que custavam cerca de US $ 60 por dia e morreriam completamente naturalmente em algumas semanas. Embora pudéssemos ter movido todos os dados para cortá-los para zero imediatamente, isso nos deixaria um “resíduo de dinheiro” único de US $ 5 mil para mover dados para fora da AWS.

Mover dados é onde você começará a correr em enormes gargalos. Nas palavras do nosso novo CTO (Zsolt Varga):

“O verdadeiro preço oculto para a AWS

Fase 3 — Implementação e Escala (4 a 6 semanas)

Nesta fase, a migração estava em andamento e já estava economizando Prerender uma quantia considerável de dinheiro. A única coisa que resta a fazer era migrar todos os outros dados para os servidores nativos.

Essa etapa envolveu mover todas as instâncias do Amazon RDS por fragmento. Esta foi a parte mais propensa a erros de todo o processo, mas como uma boa quantidade de dados já havia sido migrada, quaisquer soluços ou gargalos não teriam trazido toda a migração para baixo.

Aqui está uma visão geral desta última etapa do processo de migração:

• Nós espelhamos os cacos do PostgreSQL armazenando tabelas cached_urls em Cassandra
• Nós mudamos service.prerender.io para o balanceador de carga Cloudflare para permitir a distribuição dinâmica de tráfego
• Nós estabelecemos novos servidores de recache privado da UE
• Continuamos realizando testes de estresse para resolver quaisquer problemas de desempenho

A migração provou ser um sucesso retumbante no final. Nossas taxas mensais de servidor caíram abaixo de nossa estimativa inicial de 40% para 80% total no momento em que todas as páginas em cache foram redirecionadas.

O que aprendemos

Há muito em jogo em uma migração de servidor se as coisas derem errado ou ficarem atrasadas. É por isso que nos certificamos de implementar cofres de falhas em cada estágio da migração para garantir que pudéssemos recuar se algo desse errado. É também por isso que testamos em pequena escala antes de prosseguir com o resto da migração.

Evitamos os perigos planejando cuidadosamente cada estágio da migração, testando cada etapa da implementação antes de escalar e facilitando a correção de quaisquer erros caso algo dê errado. Dessa forma, poderíamos colher os benefícios de economizar em taxas de servidor, mantendo os riscos potenciais ao mínimo.

O que o motivou a trabalhar no problema que a Prerender resolve?

Fiquei animado com a ideia de trabalhar em uma plataforma que ajuda a mover a web para frente.

Você vê, com a Prerender, nossos clientes estão lançando sites focados na experiência do usuário e, em vez de se concentrar em SEO, eles fornecem o melhor para seus clientes. Nos últimos anos, sempre que construímos uma nova página de destino, sempre usamos o WordPress apenas para obter o melhor SEO e reservamos o poder do SPA apenas para as páginas não indexadas, como a seção de administração. Mas agora, eu trabalho com uma empresa que ajuda a resolver problemas que me seguravam no passado ?.

Que pilha de tecnologia você usa e por que escolheu essa pilha?

Usamos Javascript em todos os lugares, pois resolvemos os “problemas” causados pela renderização Javascript, queremos construir o máximo de experiência possível neste campo. Mas para as outras partes, estamos aproveitando o sistema distribuído da CloudFlare para resposta rápida e escalabilidade global. Embora nossas garantias de tempo de atividade sejam suportadas pela plataforma de nuvem da Digital Ocean. Também usamos uma infinidade de outros provedores de SaaS para maximizar nossa eficácia.

Como será o mundo quando sua empresa atingir sua visão?

Quando a pergunta surgir “Podemos usar o React para o nosso novo site?”, a resposta será “Com certeza!”, porque agora os departamentos de marketing estão sempre vetando qualquer coisa que possa reduzir o ranking de SEO. Eu diria, com razão. Quanto aos nossos clientes, mesmo que eles percam 1% de eficácia, eles precisariam bombear seu orçamento de anúncios com centenas de milhares de dólares.

Como é um dia típico para você?

Haha, muitas chamadas de clientes! Como pretendemos manter nossa equipe dedicada pequena e eficaz, estou mais frequentemente do que não nas chamadas de integração com eles. Mas é divertido para mim! Eu sempre gostei de conversar com os clientes, aprender sobre sua situação e falar sobre soluções. Isso torna meu trabalho muito mais fácil, já que não precisamos ter ideias, nossos clientes estão nos dizendo tudo o que precisamos saber. E eu acredito que este é o melhor tipo de situação, para ser orientado para o cliente e meu KPI é o número de clientes satisfeitos.

Descreva a configuração do hardware do seu computador

Meu Deus, valeria um artigo em si. Eu sou meio um geek, e tenho 8 servidores dedicados em casa, enquanto eu estou trabalhando principalmente no meu macbook para conveniência. Mas quando tenho tempo para a programação, eu giro minha “estação de trabalho” que executa o Manjaro. Mas raramente quando eu tenho um pouco de tempo de mim, eu secretamente ligo meu computador para jogos. E no momento da escrita, estou cercado por laptops, framboesas e comprimidos também.

Construir máquinas e executar testes de downscaled é o meu hobby de fim de noite.

Descreva a configuração do software do computador

VSCode é uma solução definitiva para mim, eu não gosto muito de qualquer linguagem de programação e me dá a liberdade de apenas instalar uma extensão e escrever código suportado IDE em segundos. Além disso, tive a sorte de estar no grupo beta do CoPilot e é um divisor de jogo definitivo.

Para controle de fonte GitHub é incrível, mas eu nunca iria descontar outras soluções também. O GitLab tornou-se uma ferramenta realmente incrível nos últimos anos.

Mensagens, acho que o Slack ainda é a escolha profissional mais difundida, e como faz o seu trabalho, não há razão para se afastar dela. Mas recentemente eu encontrei um software muito interessante chamado Spike e nos últimos 3 meses, eu tenho usado como meu cliente de e-mail de fato, pois torna as conversas por e-mail muito mais fáceis.

Ferramentas essenciais: Docker, não há outra maneira, mudou a indústria para o melhor. Eu ainda me lembro dos velhos tempos sombrios, quando tivemos que instalar dependências e resolver conflitos de pacotes…

Mas sim, Kubernetes está lentamente no mesmo nível de adaptação.

Você tem algum conselho para engenheiros de software que estão apenas começando?

Não tenha medo de conversar com os clientes. Ao longo da minha carreira, os melhores engenheiros de software foram os que trabalharam com o cliente para resolver seus problemas. Algumas vezes você pode demitir um meio ano de tempo de desenvolvimento apenas aprendendo que você pode resolver o problema do cliente com uma única linha de código. Acho que os melhores engenheiros estão criando soluções para problemas do mundo real.

Você está contratando e para quais papéis?

Sempre! Pretendemos sempre contratar apenas quando podemos garantir que nossos novos colegas tenham um papel significativo e que contribuam definitivamente. Mas, no momento, crescemos tanto que precisamos expandir nossa equipe em todos os departamentos. Então, em vez de lista basta verificar a nossa página de carreira 😀 https://saas.group/carreira

Onde podemos ir para aprender mais?

Confira nosso site em prerender.io e se você estiver interessado em ter uma ligação comigo sobre a pré-rrender e como ela muda a web, chegue a mim no e-mail em varga.prerender.io Estou sempre feliz em entrar em uma chamada e aprender sobre sua situação e casos de uso.

Zsolt Varga é o gerente geral da Prerender, uma ferramenta de software recomendada pelo Google usada por mais de 12.000 empresas que permite que os mecanismos de pesquisa rastreie e indexem melhor os sites Javascript.

está vindo do custo de tráfego, eles vendem um armazenamento com preços razoáveis e é até mesmo gratuito enviá-lo. Mas quando você sai, você paga um custo enorme.

Pequenas startups muitas vezes não calculam o custo do tráfego, mesmo que pode ser 90% de sua conta.

Por exemplo, se você estiver na região Oeste dos EUA (Oregon), você tem que desembolsar US $ 0,080 / GB, enquanto na região Ásia-Pacífico (Seul) ele vai até US $ 0,135 / GB.

No nosso caso, foi fácil em torno dos US $ 30k – US $ 50 mil por mês. No final da segunda fase, reduzimos os custos totais mensais do servidor em 41,2%.

Fonte: levelup.gitconnected.com

“Traduzido”.