Aterrissagem na nuvem: como integramos a nuvem pública com um CDN e o que resultou disso

Quando você tem simultaneamente uma nuvem poderosa com infraestrutura nos EUA, União Europeia, CIS, Ásia e Austrália e CDN com 100 pontos de presença em mais de 70 cidades em cinco continentes, a solução surge naturalmente - você precisa integrá-los! Essa sinergia obviamente aumentará as capacidades da infraestrutura. Claro que não podíamos perder essa oportunidade, mas ao mesmo tempo enfrentamos vários desafios.



A integração foi acompanhada por uma luta com literalmente cada milissegundo de latência, uma atualização de infraestrutura e o desenvolvimento de tecnologias de entrega de conteúdo, que tivemos que criar nomes nós mesmos. Contamos o que encontramos no decorrer do trabalho, o que aconteceu no final e por que os usuários precisam disso.



imagem



Por que integrar a nuvem com o CDN?



Em primeiro lugar, uma nuvem pública é uma capacidade escalonável. Eles podem ser usados ​​de qualquer forma: para desenvolver e testar serviços, bem como armazenar e processar dados. Nós da G-Core Labs lançamos a nuvem no ano passado e já conseguimos usá-la em projetos de alta carga. Por exemplo, nosso cliente de longa data - Wargaming - usa esta solução para várias tarefas ao mesmo tempo:



  • Testar novos recursos e serviços de diferentes projetos;
  • Preparar protótipos de teste com desenvolvedores externos que precisam de acesso a recursos personalizados e controlados isolados;
  • Operação do jogo online "Calibre" em máquinas virtuais.


A nuvem lida com tudo isso com um estrondo, mas o trabalho não termina aí. Não importa para que essas ou aquelas capacidades sejam utilizadas, o resultado de seu trabalho ainda precisa ser entregue no ponto de destino. Independentemente de estarmos falando de um jogo online ou de formações militares reais, é aqui que surge o problema: que é extremamente difícil entregar dados pesados ​​rapidamente para regiões remotas com equipamentos militares de várias toneladas. Esta tarefa pode ser simplificada integrando a nuvem com a rede de distribuição de conteúdo. Com a ajuda do CDN, a parte transportável - dados estáticos - pode ser jogada "pelo ar" diretamente para o destino, e tudo o que resta é enviar os dados dinâmicos "superdimensionados" da nuvem. Com essa abordagem, você pode começar a trabalhar com segurança até mesmo em outros continentes, já que a integração permite que concorrentes mais rápidos entreguem conteúdo pesado em todo o mundo.



imagem



, , : CDN



Vamos aos detalhes. Sabemos em primeira mão que leva muito tempo para entregar conteúdo pesado para regiões remotas diretamente da nuvem e pode ser caro aumentar constantemente a capacidade da infraestrutura de acordo com o aumento na carga. Felizmente, além da nuvem pública, acabamos com nosso próprio CDN, que até entrou no Guinness Book of Records, proporcionando uma experiência ininterrupta de jogar World of Tanks nos períodos de pico.



Para matar dois coelhos com uma cajadada só, precisamos integrá-la à nuvem. Assim, poderíamos oferecer aos usuários uma solução que custaria menos do que uma atualização de infraestrutura e permitiria a entrega de dados mais rápida para regiões remotas. Então, começamos a primeira fase de trabalho e resolvemos os principais problemas:



1. Os serviços em nuvem estavam sob carga constante.Usuários de projetos de alta carga regularmente solicitam conteúdo de nuvens de nossos clientes. Isso resultou em uma alta carga e um longo retorno de dados. Era necessária uma solução que pudesse reduzir facilmente o número de referências à fonte. Para isso, integramos servidores de nuvem pública e servidores de cache CDN, e também criamos uma interface única para gerenciar esses serviços. Com sua ajuda, os usuários podem mover dados estáticos para os pontos de presença desejados na rede. Isso garante que a nuvem seja acessada apenas nas primeiras solicitações de conteúdo. Funciona de maneira padrão: o CDN pega os dados da fonte e os envia ao usuário, bem como ao servidor de cache mais próximo, de onde o conteúdo é distribuído nas solicitações subsequentes;



2. Os dados foram transferidos por um longo tempo entre a nuvem e o CDN.Ao combinar a nuvem com uma rede de entrega de conteúdo, percebemos que a latência de entrega de dados pode ser reduzida. Para economizar tantos milissegundos preciosos quanto possível, tivemos que implementar a troca de tráfego entre os servidores de cache e a nuvem dentro do backbone;



imagem



3. A carga na fonte era irregular. Mesmo depois de conectar o CDN, as chamadas restantes para a nuvem foram distribuídas de forma ineficiente. Corrigimos isso com balanceadores HTTP (S). Agora, no momento da solicitação de conteúdo, eles determinam de qual fonte (máquina virtual ou depósito de armazenamento em nuvem) os dados devem ser retirados para armazenamento em cache;



4. O conteúdo pesado demorava muito para chegar aos usuários.Para reduzir o tempo de espera, aumentamos constantemente a capacidade e a geografia da presença do CDN. Agora os usuários não precisam mais esperar que o conteúdo chegue até eles do outro lado do mundo - no momento do contato, a rede de distribuição de conteúdo seleciona o mais próximo de 100 pontos de presença em cinco continentes. Como resultado, o tempo médio de resposta em todo o mundo é de 30ms.



Tendo lidado com esses problemas, já consideramos o trabalho concluído. Mas a nuvem com CDN tinha outros planos para nós.



Foi assim que o aço foi temperado: estamos modernizando a infraestrutura



Em um ponto, ficou claro que o efeito de todos os nossos esforços não poderia se manifestar totalmente enquanto estávamos usando a configuração de hardware antigo. Para fazer os servidores e os aplicativos hospedados neles funcionarem melhor e o conteúdo transferido mais rápido, uma atualização de infraestrutura foi necessária. As estrelas no céu convergiram no início deste ano: começamos a atualização assim que a linha de processadores escaláveis ​​Intel Xeon de segunda geração foi lançada.



Agora, a configuração padrão do servidor se parece com esta:



  • Os serviços em nuvem rodam em processadores Intel Xeon Gold 6152, 6252 e 5220, têm até 1 TB de RAM, bem como SSD e HDD com replicação tripla;
  • Os servidores de cache CDN são equipados com Intel Xeon Platinum, RAID virtual na CPU e SSD D3-S4610.


Como resultado da atualização, o desempenho aumentou tanto que abandonamos alguns dos servidores e reduzimos o custo de operação. Parecia que tudo isso seria mais do que suficiente para o trabalho de qualquer projeto. Mas um dia isso não foi suficiente.



Blindagem, fragmentação e distribuição geográfica: acelerando a entrega de conteúdo em condições extremas



O infortúnio nunca vem sozinho. Isso é especialmente verdadeiro quando se trata de projetos globais. Falta de infraestrutura distribuída geograficamente, cargas elevadas devido a muitos usuários de todo o mundo e um mar de dados heterogêneos que eles precisam entregar rapidamente - um de nossos clientes, um grande recurso de mídia, precisava lidar com todas essas complexidades de uma vez. Poucos detalhes:



  • O conteúdo demorava muito para chegar aos usuários e às vezes nem chegava devido a atrasos e problemas de rede. A dificuldade era que todo o grande pool de servidores com dados estava localizado em um ponto geográfico;
  • A fonte de conteúdo era acessada por usuários de todo o mundo, o que aumentava a carga da infraestrutura e gerava um alto custo de manutenção, além de lentidão na entrega de dados;
  • Os usuários precisavam fornecer uma grande quantidade de conteúdo constantemente atualizado e exclusivo para cada região.


Os recursos básicos de integração em nuvem com CDN eram indispensáveis ​​aqui. Começamos a desenvolver soluções adicionais.



Como criamos a blindagem regional



Introduzimos este conceito, e agora um serviço existente, especificamente para resolver o problema com o afastamento da fonte de conteúdo. Devido ao fato de todos os servidores do cliente estarem localizados em um ponto geográfico, os dados deles demoravam muito para chegar a usuários de diferentes partes do mundo. A situação era complicada pelo fato de ser necessário entregar conteúdos diferentes e constantemente atualizados para diferentes regiões. O armazenamento em cache de dados simples em servidores de borda não resolveria o problema - eles ainda costumavam acessar a fonte em outro lugar do mundo.



Resolvemos o problema implantando um grande pool de servidores de cache em pontos populares de troca de tráfego em diferentes continentes. As “blindagens regionais” tornaram-se uma espécie de camadas entre os servidores de origem e de ponta nos países do usuário. Agora, todo o conteúdo exigido nas partes correspondentes do mundo caiu sobre eles primeiro e depois foi transmitido aos servidores de cache. Assim, a blindagem reduziu a carga na origem do cliente de uma vez e reduziu os atrasos para os usuários finais. O cliente, por sua vez, economizou na colocação de vários pools de servidores com o mesmo conteúdo em diferentes partes do mundo, pois com esse princípio de trabalho bastava uma fonte de dados.



imagem



Por que você precisou de fragmentação de conteúdo



As blindagens regionais resolveram totalmente o problema da entrega de conteúdo a longo prazo para diferentes partes do mundo. Porém, agora surgiu uma nova complexidade: como o cliente possuía muitos dados e estes eram constantemente atualizados, eles não iam parar no cache dos servidores de ponta que os usuários acessavam. Isso levou ao fato de que uma massa de solicitações de servidores de cache constantemente derramada em pools regionais, o número dos quais em um grupo chegou a 20-30 peças. Para remover parte dessa carga dos escudos e entregar conteúdo aos usuários ainda mais rápido, adicionamos a capacidade de obter os dados necessários do servidor de borda mais próximo no pool.



Agora, os servidores de cache nas regiões de presença começaram a acessar os escudos apenas quando os dados não estavam disponíveis para todo o grupo. Além disso, mesmo nesses casos, o conteúdo foi solicitado imediatamente do servidor que o continha - graças ao sharding, os servidores de borda “sabiam” com antecedência onde um arquivo específico estava, e não pesquisaram todo o pool de escudos regionais para isso. Esse princípio de operação reduziu o número de solicitações para o pool e tornou possível distribuir o conteúdo de forma eficiente por ele, em vez de armazenar cópias dos dados em cada servidor. Como resultado, os escudos continham mais conteúdo e, como resultado, colocavam menos pressão sobre a fonte do cliente.



imagem



A criação de tal infraestrutura não poderia deixar de acarretar mais uma dificuldade. Dado o número de servidores de cache nos grupos, seria tolice supor que nenhum deles pode falhar. Em tal situação, como no caso de adicionar um novo servidor ao pool, o cache nos grupos teve que ser redistribuído de maneira ideal. Para fazer isso, implementamos a organização de um cache fragmentado com um algoritmo de hash consistente no bloco upstream no nginx:



upstream cache_servers {
   hash $cache_key consistent;
   server edge1.dc1.gcorelabs.com;
   server edge2.dc1.gcorelabs.com;
   server edge3.dc1.gcorelabs.com;
}

      
      





O aparecimento de servidores indisponíveis no pool também gerou outro problema: outros servidores continuaram a enviar solicitações a eles e aguardaram por uma resposta. Para eliminar esse atraso, escrevemos um algoritmo para detectar esses servidores no pool. Agora, devido ao fato de que eles são transferidos automaticamente para o estado inativo no grupo upstream, não acessamos mais servidores inativos e não esperamos dados deles.



Como resultado destas obras, reduzimos o custo dos serviços para o cliente, poupamos-lhe os graves custos de organização da sua própria infraestrutura e acelerámos significativamente a entrega de dados aos utilizadores, apesar de todas as dificuldades.



Quem precisa de uma nuvem com CDN



O trabalho de integração acabou e nossos clientes já estão usando o produto. Compartilhamos qual deles tira o máximo proveito disso.



Digamos desde já que a solução não foi útil para todos. Não esperávamos mais nada: para alguns, apenas armazenamento e máquinas virtuais são suficientes, e para outros - redes de entrega de conteúdo. Por exemplo, quando todo o público de um projeto está na mesma região, praticamente não há necessidade de conectar o CDN à nuvem. Para minimizar atrasos, neste caso, um servidor localizado não muito longe dos usuários será suficiente.



A integração é revelada em todo o seu esplendor quando você precisa de forma rápida e distante fornecer conteúdo pesado a um grande número de usuários. Aqui estão alguns exemplos de como uma nuvem com CDN ajuda projetos diferentes:



  • Os serviços de streaming que são essenciais para a latência e o buffer garantem uma operação estável e transmissões de alta qualidade;
  • Os serviços de entretenimento online fornecem jogos pesados ​​para diferentes partes do mundo com mais rapidez e reduzem a carga nos servidores, inclusive em picos de carga;
  • Projetos de mídia aceleram os tempos de carregamento de anúncios e permanecem acessíveis quando o tráfego aumenta;
  • As lojas online carregam mais rápido em diferentes países, inclusive durante promoções e vendas.


Continuamos a ver exatamente como eles estão usando a nuvem com o CDN. Nós, como você, estamos interessados ​​nos números: quanto a carga da infraestrutura é reduzida, quanto mais rápido os usuários recebem conteúdo em regiões específicas e quanto a integração ajuda a economizar dinheiro. Compartilharemos tudo isso em casos futuros.



All Articles