Os aplicativos da Internet podem passar por flutuações extremas no uso. Embora a maioria dos aplicativos corporativos não enfrentam esse desafio, muitas empresas precisam lidar com um tipo diferente de carga de trabalho com bursts: jobs em lote ou de CI/CD.
Esse padrão de arquitetura depende de uma implantação redundante de aplicativos em vários ambientes de computação. A meta é aumentar a capacidade, resiliência ou ambos.
É possível acomodar cargas de trabalho com bursts em um ambiente de computação baseado em data center ao provisionar recursos em excesso, mas essa abordagem talvez não seja econômica. Com jobs em lote, é possível otimizar o uso estendendo a execução deles em períodos mais longos, embora atrasar jobs não seja prático se eles forem urgentes.
A ideia do padrão de bursting de nuvem é usar um ambiente de computação particular para a carga de valor de referência e usar bursts na nuvem temporariamente quando precisar de capacidade extra.
No diagrama anterior, quando a capacidade de dados atingir o limite em uma rede local em um ambiente particular, o sistema poderá ganhar capacidade extra de um ambiente do Google Cloud quando necessário.
Os principais fatores que impulsionam esse padrão são economizar dinheiro e reduzir o tempo e esforço necessários para responder às mudanças nos requisitos da escala. Com essa abordagem, você paga apenas pelos recursos usados ao lidar com cargas extras. Isso significa que você não precisará aumentar o provisionamento da infraestrutura. Você pode utilizar recursos de nuvem sob demanda e escaloná-los de acordo com a demanda e as métricas predefinidas. Como resultado, sua empresa pode evitar interrupções de serviço durante os períodos de pico de demanda.
Um requisito possível para cenários de bursting de nuvem é a portabilidade da carga de trabalho. Ao permitir que as cargas de trabalho sejam implantadas em vários ambientes, é preciso que você se abstraia das diferenças entre os ambientes. Por exemplo, o Kubernetes permite alcançar consistência no nível da carga de trabalho em ambientes diversos que usam infraestruturas diferentes. Para mais informações, consulte Arquitetura de referência do ambiente híbrido do GKE Enterprise.
Considerações sobre o design
O padrão de bursting de nuvem se aplica a cargas de trabalho interativas e em lote. Porém, ao lidar com cargas de trabalho interativas, é preciso determinar como distribuir solicitações entre ambientes:
É possível encaminhar as solicitações de usuário recebidas para um balanceador de carga que é executado no data center atual e, depois, fazer com que o balanceador de carga distribua as solicitações nos recursos locais e na nuvem.
Essa abordagem requer que o balanceador de carga ou outro sistema que esteja em execução no data center atual também rastreie os recursos que estão alocados na nuvem. O balanceador de carga ou outro sistema também precisa iniciar o aumento ou redução automáticos do escalonamento dos recursos. Utilizando essa abordagem, é possível desativar todos os recursos de nuvem durante períodos de baixa atividade. No entanto, a implementação de mecanismos para rastrear recursos pode exceder as funcionalidades das suas soluções de balanceador de carga e, portanto, aumentar a complexidade geral.
Em vez de implementar mecanismos para rastrear recursos, é possível usar o Cloud Load Balancing com um back-end do grupo de endpoints de rede (NEG, na sigla em inglês) de conectividade híbrida. Você usa este balanceador de carga para encaminhar solicitações de clientes internos ou Solicitações de clientes externos para back-ends localizados no local e no Google Cloud e que são baseados em diferentes métricas, como divisão de tráfego com base em peso. Além disso, é possível escalonar back-ends com base na capacidade de serviço de balanceamento de carga para cargas de trabalho no Google Cloud. Para mais informações, consulte Visão geral do gerenciamento de tráfego para o balanceador de carga de aplicativo externo global.
Essa abordagem tem vários benefícios adicionais, como a utilização das funcionalidades de proteção contra DDoS do Google Cloud Armor, WAF e armazenamento em cache de conteúdo na borda da nuvem utilizando o Cloud CDN: No entanto, é preciso dimensionar a conectividade de rede híbrida para processar o tráfego adicional.
Como destacado em Portabilidade de cargas de trabalho, um aplicativo pode ser portátil para um ambiente diferente com alterações mínimas para obter consistência entre as cargas de trabalho, mas isso não significa que o aplicativo têm o mesmo desempenho nos dois ambientes. Diferenças na computação subjacente, nos recursos de segurança de infraestrutura ou na infraestrutura de rede, além da proximidade de serviços dependentes, normalmente determinam o desempenho. Com os testes, você pode ter uma visibilidade mais precisa e entender expectativas de desempenho.
É possível usar os serviços de infraestrutura em nuvem para criar um ambiente para hospedar seus aplicativos sem portabilidade. Utilize as seguintes abordagens para processar solicitações de clientes quando o tráfego for redirecionado durante os períodos de pico de demanda:
- Utilize ferramentas consistentes para monitorar e gerenciar esses dois ambientes.
- Tenha um controle de versões consistente das cargas de trabalho e garanta que suas fontes de dados sejam atuais.
- Pode ser necessário adicionar automação para provisionar o ambiente de nuvem e redirecionar o tráfego quando a demanda aumentar for esperado que a carga de trabalho em nuvem aceite solicitações de clientes para seu aplicativo.
Se você pretende encerrar todos os recursos do Google Cloud durante períodos de baixa demanda, utilizar principalmente políticas de roteamento de DNS para balanceamento de carga de tráfego nem sempre é o ideal. Isso se deve principalmente porque:
- Os recursos podem levar algum tempo para serem inicializados antes de poderem atender aos usuários.
- As atualizações de DNS tendem a se propagar lentamente pela Internet.
O resultado disso é o seguinte:
- Os usuários podem ser encaminhados para o ambiente do Cloud, mesmo quando não há recursos disponíveis para processar essas solicitações.
- Os usuários podem continuar sendo encaminhados para o ambiente local temporariamente, mesmo que as atualizações de DNS se propaguem pela Internet.
Com o Cloud DNS, é possível escolher a política de DNS e a política de roteamento que se alinham à arquitetura e ao comportamento da solução, como políticas de roteamento de DNS de geolocalização. O Cloud DNS também aceita verificações de integridade do balanceador de carga de rede de passagem interna do balanceador de carga de aplicativo interno. Nesse caso, é possível incorporá-las à configuração geral de DNS híbrida baseada nesse padrão.
Em alguns cenários, é possível usar o Cloud DNS para distribuir solicitações de clientes com verificações de integridade no Google Cloud, como ao usar balanceadores de carga de aplicativo internos ou balanceadores de carga de aplicativo internos entre regiões. Nesse cenário, o Cloud DNS verifica a integridade geral do Balanceador de carga de aplicativo interno, que verifica a integridade das instâncias de back-end. Para mais informações, consulte Gerenciar políticas de roteamento de DNS e verificações de integridade.
Você também pode usar o Split horizon do Cloud DNS. O split horizon do Cloud DNS é uma abordagem para configurar as respostas ou registros do DNS como o local ou a rede específicos do criador da consulta de DNS para o mesmo nome de domínio. Essa abordagem é comumente usada para atender a requisitos em que o aplicativo é desenvolvido para oferecer uma experiência particular e pública, cada uma com características únicas. A abordagem também ajuda a distribuir a carga de tráfego entre os ambientes.
Dadas essas considerações, o bursting de nuvem geralmente é melhor em cargas de trabalho em lote do que em cargas de trabalho interativas.
Vantagens
As principais vantagens do padrão de arquitetura de bursting de nuvem incluem:
- O bursting de nuvem permite reutilizar investimentos em data centers e em ambientes computacionais particulares. Essa reutilização pode ser permanente ou estar em vigor até que o equipamento atual seja substituído. Nesse ponto, talvez você deva pensar em uma migração completa.
- Como não é mais necessário manter capacidade excedente para satisfazer as demandas de pico, você pode aumentar o uso e a relação custo-benefício de ambientes computacionais particulares.
- O bursting de nuvem permite executar jobs em lote em tempo hábil sem a necessidade de provisionamento excessivo de recursos de computação.
Práticas recomendadas
Ao implementar o bursting de nuvem, tenha em mente as seguintes práticas recomendadas:
- Para garantir que as cargas de trabalho em execução na nuvem possam acessar os recursos da mesma forma que as cargas de trabalho em execução em um ambiente local, utilize o padrão em malha com o princípio de privilégio mínimo do acesso de segurança. Se o design da carga de trabalho permitir, você poderá autorizar acesso a partir da nuvem para o ambiente de computação no local, e não o contrário.
- Para minimizar a latência de comunicação entre ambientes, escolha uma Região do Google Cloud geograficamente próxima ao seu ambiente de computação particular. Saiba mais em Práticas recomendadas para a seleção de regiões do Compute Engine.
- Ao usar o bursting de nuvem apenas para cargas de trabalho em lote, reduza a superfície de ataque de segurança mantendo a privacidade de todos os recursos do Google Cloud. Desabilite o acesso direto da Internet a esses recursos, mesmo que você usa o balanceamento de carga externo do Google Cloud para fornecer o ponto de entrada para a carga de trabalho.
Selecione a Política de DNS e a política de roteamento que esteja de acordo com seu padrão de arquitetura e o comportamento da solução.
- Como parte desse padrão, é possível aplicar o design as políticas de DNS ou se você precisar de capacidade extra usando outro ambiente durante os períodos de pico de demanda.
- As políticas de roteamento de DNS de geolocalização podem ser usadas para ter um endpoint de DNS para seus balanceadores de carga regionais. Essa tática abarca muitos casos de uso de políticas de roteamento de DNS de geolocalização, incluindo aplicativos híbridos que usam o Google Cloud com uma implantação local onde há uma região do Google Cloud.
Se for necessário fornecer registros diferentes para as mesmas consultas DNA, é possível usar o DNS split horizon, por exemplo, consultas de clientes internos e externos.
Para mais informações, consulte arquiteturas de referência para DNS híbrido
Para garantir que as alterações de DNS sejam propagadas rapidamente, configure o DNS com um valor de time to live consideravelmente curto. Assim, você pode redirecionar os usuários para os sistemas em espera quando precisar de capacidade extra usando os ambientes de nuvem.
Para jobs que não são muito urgentes e não armazenam dados localmente, considere usar Instâncias de VM spot, que são substancialmente mais baratas do que as instâncias de VM comuns. Um pré-requisito: no entanto, se o job da VM for interrompido, o sistema precisará conseguir reiniciar o job automaticamente.
Utilize contêineres para conseguir portabilidade de cargas de trabalho quando aplicável. Além disso, O GKE Enterprise pode ser uma tecnologia capacitadora fundamental para esse design. Para mais informações, consulte Arquitetura de referência do ambiente híbrido do GKE Enterprise.
Monitore qualquer tráfego enviado do Google Cloud para um ambiente de computação diferente. Esse tráfego está sujeito a cobranças de transferência de dados de saída.
Se você planeja usar essa arquitetura a longo prazo com muitos dados de saída no volume de transferências, considere usar o Cloud Interconnect. O Cloud Interconnect ajuda a otimizar o desempenho da conectividade e pode reduzir as cobranças da transferência de dados de saída do tráfego que atender a determinadas condições. Para saber mais, consulte preços do Cloud Interconnect.
Quando o Cloud Load Balancing é usado, é preciso usar as habilidades de otimização da capacidade de aplicativo do produto quando aplicável. Isso pode ajudar você a enfrentar alguns dos desafios de capacidade que podem ocorrer em aplicativos distribuídos globalmente.
Autentique as pessoas que usam seus sistemas estabelecendo uma identidade comum entre os ambientes para que os sistemas possam se autenticar com segurança nos limites do ambiente.
Para proteger informações sensíveis, criptografar todas as comunicações o transporte público é altamente recomendado. Se a criptografia for necessária na camada de conectividade, várias opções estão disponíveis com base na solução de conectividade híbrida escolhida. Essas opções incluem túneis VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para Cloud Interconnect.