Conforme as empresas modernizam suas stacks de tecnologia para se tornarem mais cloud-native, uma tendência que estamos observando são as migrações parciais ou configurações de nuvem híbrida, muitas vezes como etapas intermediárias rumo à migração completa.
Migração para a nuvem
Recentemente, uma empresa de e-commerce estava movendo suas aplicações em containers da AWS para o GCP para aproveitar o serviço gerenciado de Kubernetes do Google, o GKE.
Os arquivos do catálogo de produtos e as fotos ficavam armazenados no serviço de object storage da Amazon, o S3; o DNS era gerenciado pelo AWS Route 53; e a empresa usava o serviço de CDN da Cloudflare. Como primeiro passo, migraram os bancos de dados e implantaram seus apps em paralelo nos clusters Kubernetes.
Em seguida, queriam fazer a transição da CDN da Cloudflare para a do Google, mas mantendo, por enquanto, os arquivos estáticos no S3. Outro requisito era continuar usando o DNS gerenciado pelo AWS Route 53.
Exemplo de jornada de migração para a nuvem em múltiplas fases para uma empresa de e-commerce
Este artigo traz um exemplo passo a passo de como fazer cache do conteúdo de um bucket do AWS S3 a partir do Cloud CDN do GCP, usando um load balancer e um network endpoint group (NEG). Para simplificar, neste exemplo não vou gerar um certificado SSL nem adicionar um frontend HTTP(S), mas esse seria um passo adicional típico.
Configuração da demonstração
- Crie o bucket S3 inicial com arquivos para teste
Crie o bucket S3 (anote o nome do bucket para usar depois na configuração de Host no LB)
2. Faça upload dos arquivos de teste e edite os metadados para adicionar o cabeçalho Cache-control
Arquivos de exemplo enviados
Cabeçalho Cache-control adicionado (obrigatório para o CDN)
3. Verifique se o conteúdo está retornando os cabeçalhos corretos
Configurar o load balancer e o NEG no GCP
- Adicione/edite o tipo de backend para "Internet network endpoint group"
2. Selecione um network endpoint group (NEG) ou "criar novo"
Observação: talvez seja preciso criar antes o Network Endpoint Group (NEG) para que ele apareça no menu suspenso da configuração de backend do Load Balancer. Caso não apareça, você pode usar a opção "Create Internet network endpoint group", mas será necessário atualizar a tela do load balancer para que ele apareça.
Selecione "Fully qualified domain name" e informe o FQDN do seu bucket S3 (em alguns casos, você pode ter uma entrada de DNS própria apontando para esse endereço, e isso também funciona).
3. Habilite o Cloud CDN e adicione um cabeçalho personalizado (correspondente ao hostname do bucket S3)
Depois de selecionar o "Backend type" do NEG externo, marque a opção "Enable Cloud CDN" e expanda as opções na parte inferior para criar um cabeçalho personalizado.
O segredo para fazer isso funcionar é adicionar o cabeçalho host personalizado correspondente ao hostname do S3, conforme mostrado abaixo.
4. Adicione/edite o frontend
5. Salve o load balancer e confirme que ele foi configurado com o NEG
6. Confirme se o conteúdo está retornando e batendo no cache
Confirme o acesso ao conteúdo (também dá para testar pelo navegador)
Faça alguns testes pelo navegador e depois consulte os logs (a forma mais rápida é pelos logs do Stackdriver); expanda uma entrada e confirme se ela está vindo do cache.
Confirme que o cache está funcionando para o tráfego do load balancer
Atualize as entradas de DNS para redirecionar o tráfego para o Cloud CDN
Depois de confirmar que tudo está funcionando como esperado e que o conteúdo está vindo do cache, é só editar suas entradas de DNS quando estiver pronto.
Neste caso, a CDN era fornecida pela Cloudflare e havia uma entrada DNS cdn-environment-location.myco.com apontando para o CNAME something.cloudflare.com. Basta criar um novo registro A apontando para o IP externo do load balancer do Google (por exemplo, gcp-lb-development-cdn.myco.com) e, em seguida, alterar o CNAME para apontar para essa nova entrada.
Por precaução, recomendo reduzir o TTL na sua entrada de CDN ativa no dia anterior, se necessário, para que, caso algo dê errado ao editar o CNAME, seja possível reverter rapidamente — e o cache de DNS dos clientes não fique desatualizado por muito tempo.
Resumo dos passos:
- Reduza o TTL no domínio de CDN existente
- Adicione um registro A apontando para o IP do load balancer no GCP
- Edite o registro CNAME do domínio de CDN existente (substituindo o FQDN da Cloudflare)
- Confirme se o conteúdo está sendo roteado pelo Cloud CDN
Parabéns, funcionou! Agora é só proteger tudo com um frontend HTTP(S) ;-)
Atenção aos custos das soluções em nuvem
Apesar de ser possível fazer proxy de requisições do Cloud CDN para buckets S3, para que isso funcione é preciso adicionar cabeçalhos personalizados — e isso tem um custo. Hoje, fica em torno de US$ 0,75 por 1 milhão de requisições, com teto de US$ 500 por mês. Em um site grande, com bastante tráfego, esse valor pode pesar.
Pode até parecer pouco perto do que se paga à Cloudflare (não temos certeza dos preços), mas ainda assim vale a atenção. No longo prazo, o plano é migrar os arquivos estáticos para buckets do Google Cloud Storage e, como eles oferecem suporte à mesma API do S3, pouca ou nenhuma alteração de código será necessária.
Conclusão
Como você pode ver, migrar entre provedores de tecnologia não é tão assustador quanto parece. Uma abordagem mais segura, porém, é dividir o trabalho em fases menores, para que você possa reverter com facilidade em caso de problemas e reduzir a interrupção do negócio.