Este documento é o segundo de três documentos de um conjunto. Ele discute padrões comuns de arquitetura híbrida e multicloud. Ele também descreve os cenários para os quais esses padrões são mais adequados. Por fim, ele fornece as práticas recomendadas que você pode seguir ao implantar essas arquiteturas no Google Cloud.
O conjunto de documentos para padrões de arquitetura híbrida e multicloud consiste nestas partes:
- Criar arquiteturas híbridas e multicloud: discute o planejamento de uma estratégia para arquitetar uma configuração híbrida e multicloud com o Google Cloud.
- Padrões de arquitetura híbrida e multicloud: discute padrões comuns de arquitetura a serem adotados como parte de uma estratégia híbrida e multicloud (este documento).
- Padrões de arquitetura de rede segura híbrida e multicloud: discute padrões de arquitetura de rede híbrida e multicloud de uma perspectiva da rede.
Cada empresa tem um portfólio exclusivo de cargas de trabalho de aplicativos, que estabelecem requisitos e restrições na arquitetura de uma configuração híbrida ou multicloud. Embora você precise projetar e adaptar sua arquitetura para atender a essas restrições e requisitos, é possível contar com alguns padrões comuns para definir a arquitetura fundamental.
Um padrão de arquitetura é uma maneira replicável de estruturar vários componentes funcionais de uma solução de tecnologia, aplicativo ou serviço para criar uma solução reutilizável que atenda a determinados requisitos ou casos de uso. Em geral, uma solução de tecnologia baseada em nuvem é composta de vários serviços de nuvem distintos e distribuídos. Esses serviços colaboram para fornecer a funcionalidade necessária. Nesse contexto, cada serviço é considerado um componente funcional da solução de tecnologia. Da mesma forma, um aplicativo pode consistir em várias camadas funcionais, módulos ou serviços, e cada um pode representar um componente funcional da arquitetura do aplicativo. Essa arquitetura pode ser padronizada para abordar casos de uso de negócios específicos e atuar como um padrão fundamental e reutilizável.
Para definir de modo geral um padrão de arquitetura para um aplicativo ou solução, identifique e defina o seguinte:
- Os componentes da solução ou aplicativo.
- As funções esperadas para cada componente, como funções de front-end para fornecer uma interface gráfica do usuário ou funções de back-end para fornecer acesso a dados.
- Como os componentes se comunicam entre si e com sistemas ou usuários externos. Em aplicativos modernos, esses componentes interagem por meio de interfaces ou APIs bem definidas. Há uma ampla variedade de modelos de comunicação, como os assíncronos e síncronos, os de solicitação-resposta ou os baseados em fila.
Estas são as duas principais categorias de padrões de arquitetura híbrida e multicloud:
- Padrões de arquitetura distribuída: esses padrões dependem de uma implantação distribuída de cargas de trabalho ou componentes de aplicativos. Isso significa que eles executam um aplicativo (ou componentes específicos desse aplicativo) no ambiente de computação que melhor se adapta ao padrão. Isso permite que o padrão capitalize as diferentes propriedades e características de ambientes de computação distribuídos e interconectados.
- Padrões de arquitetura redundantes: esses padrões são baseados em implantações redundantes de cargas de trabalho. Neles, você implanta os mesmos aplicativos e componentes associados em vários ambientes de computação. O objetivo é aumentar a capacidade de desempenho ou a resiliência de um aplicativo ou replicar um ambiente atual para desenvolvimento e teste.
Ao implementar o padrão de arquitetura selecionado, você deve usar um arquétipo de implantação adequado. Os arquétipos de implantação são zonais, regionais, multirregionais ou globais. Essa seleção forma a base para a criação de arquiteturas de implantação específicas do aplicativo. Cada arquétipo de implantação define uma combinação de domínios de falha em que um aplicativo pode operar. Esses domínios de falha podem abranger uma ou mais zonas ou regiões doGoogle Cloud , e podem ser expandidos para incluir os data centers locais ou domínios de falha em outros provedores de nuvem.
Esta série contém as seguintes páginas:
Padrões de arquitetura redundantes
Colaboradores
Autor: Marwan Al Shawi | Engenheiro de clientes parceiro
Outros colaboradores:
- Saud Albazei | Engenheiro de clientes, modernização de aplicativos
- Anna Berenberg | Pesquisadora de engenharia
- Marco Ferrari | Arquiteto de soluções do Cloud
- Victor Moreno | Gerente de produtos, Cloud Networking
- Johannes Passing | Arquiteto de soluções na nuvem
- Mark Schlagenhauf | Redator técnico, Rede
- Daniel Strebel | Líder de soluções na EMEA, modernização de aplicativos
- Ammett Williams | Engenheiro de relações com desenvolvedores
Padrões de arquitetura distribuída
Ao migrar de um ambiente de computação não híbrido ou não multicloud para uma arquitetura híbrida ou multicloud, primeiro considere as restrições dos aplicativos atuais e como elas podem levar a falhas no aplicativo. Essa consideração se torna mais importante quando os aplicativos ou componentes operam de maneira distribuída em diferentes ambientes. Depois de considerar suas restrições, desenvolva um plano para evitá-las ou superá-las. Considere os recursos exclusivos de cada ambiente de computação em uma arquitetura distribuída.
Considerações sobre o design
As considerações de design a seguir se aplicam a padrões de implantação distribuídos. Dependendo da solução de destino e dos objetivos de negócios, a prioridade e o efeito de cada consideração podem variar.
Latência
Em qualquer padrão de arquitetura que distribua componentes de aplicativos (frontends, backends ou microsserviços) em diferentes ambientes de computação, a latência de comunicação pode ocorrer. Essa latência é influenciada pela conectividade de rede híbrida (Cloud VPN e Cloud Interconnect) e pela distância geográfica entre o site local e as regiões de nuvem ou entre regiões de nuvem em uma configuração multi-nuvem. Portanto, é crucial avaliar os requisitos de latência dos seus aplicativos e a sensibilidade deles a atrasos de rede. Os aplicativos que toleram a latência são candidatos mais adequados para a implantação distribuída inicial em um ambiente híbrido ou de várias nuvens.
Arquitetura de estado temporário x final
Para especificar as expectativas e as possíveis implicações para custo, escala e desempenho, é importante analisar o tipo de arquitetura necessário e a duração pretendida como parte do estágio de planejamento. Por exemplo, se você planeja usar uma arquitetura híbrida ou multicloud por um longo período ou permanentemente, considere usar o Cloud Interconnect. Para reduzir os custos de transferência de dados de saída e otimizar o desempenho da rede de conectividade híbrida, o Cloud Interconnect oferece descontos nas cobranças de transferência de dados de saída que atendem às condições de taxa de transferência de dados com desconto.
Confiabilidade
A confiabilidade é um fator importante na arquitetura de sistemas de TI. A disponibilidade de tempo de atividade é um aspecto essencial da confiabilidade do sistema. No Google Cloud, é possível aumentar a resiliência de um aplicativo implantando componentes redundantes dele em várias zonas em uma única região1 ou em várias regiões com recursos de transferência. A redundância é um dos principais elementos para melhorar a disponibilidade geral de um aplicativo. Para aplicativos com uma configuração distribuída em ambientes híbridos e multicloud, é importante manter um nível consistente de disponibilidade.
Para aumentar a disponibilidade de um sistema em um ambiente local ou em outros ambientes de nuvem, considere qual redundância de hardware ou software, com mecanismos de failover, você precisa para seus aplicativos e componentes. O ideal é considerar a disponibilidade de um serviço ou aplicativo em vários componentes e infraestrutura de suporte (incluindo disponibilidade de conectividade híbrida) em todos os ambientes. Esse conceito também é conhecido como a disponibilidade composta de um aplicativo ou serviço.
Com base nas dependências entre os componentes ou serviços, a disponibilidade composta de um aplicativo pode ser maior ou menor do que a de um serviço ou componente individual. Para mais informações, consulte Disponibilidade composta: como calcular a disponibilidade geral da infraestrutura de nuvem.
Para alcançar o nível de confiabilidade do sistema que você quer, defina métricas de confiabilidade claras e projete aplicativos para se autocorrigir e suportar interrupções de maneira eficaz nos diferentes ambientes. Para ajudar a definir maneiras adequadas de medir a experiência do cliente com seus serviços, consulte Definir confiabilidade com base nas metas de experiência do usuário.
Conectividade híbrida e de várias nuvens
Os requisitos da comunicação entre os componentes de aplicativos distribuídos devem influenciar a seleção de uma opção de conectividade de rede híbrida. Cada opção de conectividade tem vantagens e desvantagens, além de fatores específicos a serem considerados, como custo, volume de tráfego, segurança e assim por diante. Para mais informações, consulte a seção considerações sobre o design de conectividade.
Gerenciamento
Ferramentas de gerenciamento e monitoramento consistentes e unificadas são essenciais para configurações híbridas e multicloud bem-sucedidas (com ou sem portabilidade de carga de trabalho). No curto prazo, essas ferramentas podem aumentar os custos de desenvolvimento, teste e operações. Tecnicamente, quanto mais provedores de nuvem você usar, mais complexo será o gerenciamento dos seus ambientes. A maioria dos fornecedores de nuvem pública não tem apenas recursos diferentes, mas também ferramentas, SLAs e APIs variadas para gerenciar serviços em nuvem. Portanto, avalie as vantagens estratégicas da arquitetura selecionada em relação à possível complexidade de curto prazo e aos benefícios de longo prazo.
Custo
Cada provedor de serviços em nuvem em um ambiente multicloud tem as próprias métricas e ferramentas de faturamento. Para ter uma visibilidade melhor e painéis unificados, use ferramentas de otimização e gestão de custos multicloud. Por exemplo, ao criar soluções de prioridade à nuvem em vários ambientes de nuvem, os produtos, os preços, os descontos e as ferramentas de gerenciamento de cada provedor podem criar inconsistências de custo entre esses ambientes.
Recomendamos ter um método único e bem definido para calcular os custos totais dos recursos da nuvem e fornecer visibilidade de custos. A visibilidade de custos é essencial para a otimização de custos. Por exemplo, ao combinar dados de faturamento dos provedores de nuvem que você usa e usar o Google Cloud Looker Cloud Cost Management Block, é possível criar uma visualização centralizada dos custos de várias nuvens. Essa visualização pode ajudar a fornecer uma visualização consolidada de relatórios dos seus gastos em várias nuvens. Para mais informações, consulte A estratégia para otimizar de forma eficaz o gerenciamento de custos do Cloud Billing.
Também recomendamos usar a prática de FinOps para tornar os custos visíveis. Como parte de uma prática sólida de FinOps, uma equipe central pode delegar a tomada de decisão para a otimização de recursos a qualquer outra equipe envolvida em um projeto para incentivar a responsabilidade individual. Nesse modelo, a equipe central precisa padronizar o processo, os relatórios e as ferramentas para otimização de custos. Para mais informações sobre os diferentes aspectos e recomendações de otimização de custos que você deve considerar, consulte Google Cloud Framework de arquitetura: otimização de custos.
Movimentação de dados
A movimentação de dados é uma consideração importante para estratégias híbridas e multicloud e para o planejamento de arquitetura, especialmente para sistemas distribuídos. As empresas precisam identificar os diferentes casos de uso de negócios, os dados que os alimentam e como os dados são classificados (para setores regulamentados). Eles também precisam considerar como o armazenamento, o compartilhamento e o acesso de dados para sistemas distribuídos em vários ambientes podem afetar o desempenho do aplicativo e a consistência dos dados. Esses fatores podem influenciar o aplicativo e a arquitetura do pipeline de dados. O conjunto abrangente de opções de movimentação de dados doGoogle Cloud permite que as empresas atendam às necessidades específicas e adotem arquiteturas híbridas e multinuvem sem comprometer a simplicidade, a eficiência ou o desempenho.
Segurança
Ao migrar aplicativos para a nuvem, é importante considerar os recursos de segurança com foco em nuvem, como consistência, observabilidade e visibilidade de segurança unificada. Cada provedor de nuvem pública tem sua própria abordagem, práticas recomendadas e recursos de segurança. É importante analisar e alinhar esses recursos para criar uma arquitetura de segurança funcional padrão. Controles fortes de IAM, criptografia de dados, verificação de vulnerabilidade e conformidade com regulamentações do setor também são aspectos importantes da segurança na nuvem.
Ao planejar uma estratégia de migração, recomendamos que você analise as considerações mencionadas anteriormente. Elas podem ajudar a minimizar as chances de introduzir complexidades na arquitetura à medida que os volumes de aplicativos ou tráfego aumentam. Além disso, projetar e criar uma zona de destino é quase sempre um pré-requisito para implantar cargas de trabalho empresariais em um ambiente de nuvem. Uma zona de destino ajuda sua empresa a implantar, usar e dimensionar serviços de nuvem com mais segurança em várias áreas e inclui diferentes elementos, como identidades, gerenciamento de recursos, segurança e rede. Para mais informações, consulte Design da zona de destino no Google Cloud.
Os documentos a seguir desta série descrevem outros padrões de arquitetura distribuída:
- Padrão híbrido em camadas
- Padrão de multicloud particionada
- Padrão analítico de nuvem híbrida e multicloud
- Padrão híbrido de borda
Padrão híbrido em camadas
Os componentes de arquitetura de um aplicativo podem ser categorizados como front-end ou back-end. Em alguns cenários, esses componentes podem ser hospedados para operar em diferentes ambientes de computação. Como parte do padrão de arquitetura híbrido em camadas, os ambientes de computação estão localizados em um ambiente de computação particular local e em Google Cloud.
Os componentes do aplicativo de front-end são expostos diretamente a usuários finais ou dispositivos. Como resultado, esses aplicativos geralmente são sensíveis ao desempenho. Para desenvolver novos recursos e melhorias, as atualizações de software podem ser frequentes. Como os aplicativos de front-end geralmente dependem de aplicativos de back-end para armazenar e gerenciar dados, além de lógica de negócios e processamento de entrada do usuário, eles geralmente são sem estado ou gerenciam apenas volumes limitados de dados.
Para que sejam acessíveis e utilizáveis, crie seus aplicativos de front-end com vários frameworks e tecnologias. Alguns fatores importantes para um aplicativo de front-end bem-sucedido incluem a performance do aplicativo, a velocidade de resposta e a compatibilidade do navegador.
Os componentes de aplicativos de back-end geralmente se concentram no armazenamento e no gerenciamento de dados. Em algumas arquiteturas, a lógica de negócios pode ser incorporada ao componente de back-end. Novas versões de aplicativos de back-end tendem a ser menos frequentes do que versões para aplicativos de front-end. Os aplicativos de back-end têm os seguintes desafios a serem gerenciados:
- Como processar um grande volume de solicitações
- Como lidar com um grande volume de dados
- Como proteger dados
- Manter dados atuais e atualizados em todas as réplicas do sistema
A arquitetura de aplicativos de três camadas é uma das implementações mais usadas para criar aplicativos da Web de negócios, como sites de e-commerce que contêm diferentes componentes de aplicativos. Essa arquitetura contém os seguintes níveis. Cada nível opera de forma independente, mas eles estão intimamente vinculados e funcionam juntos.
- Front-end da Web e camada de apresentação
- Nível do aplicativo
- Camada de back-end ou de acesso a dados
Colocar essas camadas em contêineres separa as necessidades técnicas, como requisitos de escalonamento, e ajuda a migrar em etapas. Além disso, é possível implantá-los em serviços de nuvem independentes de plataforma que podem ser portáteis em vários ambientes, usar gerenciamento automatizado e dimensionar com plataformas gerenciadas por nuvem, como o Cloud Run ou o Google Kubernetes Engine (GKE) Enterprise Edition. Além disso, bancos de dados gerenciados porGoogle Cloud, como o Cloud SQL, ajudam a fornecer o back-end como a camada de banco de dados.
O padrão de arquitetura híbrida em camadas se concentra na implantação de componentes de aplicativos de front-end na nuvem pública. Nesse padrão, você mantém todos os componentes de aplicativos de back-end no ambiente de computação particular. Dependendo da escala e do design específico do aplicativo, é possível migrar componentes de aplicativos front-end caso a caso. Para mais informações, consulte Migrar para Google Cloud.
Se você já tem um aplicativo com componentes de back-end e front-end hospedados no ambiente local, considere os limites da sua arquitetura atual. Por exemplo, à medida que o aplicativo é dimensionado e as demandas de desempenho e confiabilidade aumentam, é necessário avaliar se partes do aplicativo precisam ser refatoradas ou movidas para uma arquitetura diferente e otimizada. O padrão de arquitetura híbrido em camadas permite transferir algumas cargas de trabalho e componentes de aplicativos para a nuvem antes de fazer uma transição completa. Também é essencial considerar o custo, o tempo e o risco envolvidos nessa migração.
O diagrama a seguir mostra um padrão de arquitetura híbrido em camadas típico.
No diagrama anterior, as solicitações do cliente são enviadas para o front-end do aplicativo hospedado em Google Cloud. Por sua vez, o front-end do aplicativo envia dados de volta ao ambiente local em que o back-end do aplicativo está hospedado (de preferência por um gateway de API).
Com o padrão de arquitetura híbrido em camadas, é possível aproveitar a infraestruturaGoogle Cloud e os serviços globais, conforme mostrado no exemplo de arquitetura no diagrama a seguir. O front-end do aplicativo pode ser acessado por Google Cloud. Ele também pode adicionar elasticidade ao front-end usando o escalonamento automático para responder de forma dinâmica e eficiente à demanda de escalonamento sem sobrecarregar a infraestrutura. Existem diferentes arquiteturas que podem ser usadas para criar e executar apps da Web escalonáveis no Google Cloud. Cada arquitetura tem vantagens e desvantagens para requisitos diferentes.
Para mais informações, assista o vídeo Três formas de executar apps da Web escalonáveis no Google Cloud no YouTube. Para saber mais sobre as diferentes maneiras de modernizar sua plataforma de e-commerce no Google Cloud, consulte Como criar uma plataforma de comércio digital no Google Cloud.
No diagrama anterior, o front-end do aplicativo é hospedado em Google Cloud para fornecer uma experiência do usuário multirregional e otimizada globalmente que usa o balanceamento de carga global, o dimensionamento automático e a proteção contra DDoS pelo Google Cloud Armor.
Com o tempo, o número de aplicativos implantados na nuvem pública pode aumentar a ponto de você considerar mover componentes de aplicativos de back-end para a nuvem pública. Se você espera oferecer tráfego intenso, optar por serviços gerenciados em nuvem pode ajudar a economizar esforços de engenharia ao gerenciar sua própria infraestrutura. Considere essa opção, a menos que restrições ou requisitos exijam a hospedagem de componentes de aplicativos de back-end no local. Por exemplo, se os dados do back-end estiverem sujeitos a restrições regulamentares, provavelmente será necessário mantê-los no local. No entanto, quando aplicável e em conformidade, o uso de recursos de Proteção de dados sensíveis, como técnicas de desidentificação, pode ajudar a transferir esses dados quando necessário.
No padrão de arquitetura híbrida em camadas, também é possível usar o Google Distributed Cloud em alguns cenários. Com o Distributed Cloud, você pode executar clusters do Google Kubernetes Engine em hardware dedicado fornecido e mantido pelo Google, que é separado do data center Google Cloud . Para garantir que a Distributed Cloud atenda aos seus requisitos atuais e futuros, conheça as limitações da Distributed Cloud em comparação com uma zona GKE convencional baseada na nuvem.
Vantagens
Concentrar-se em aplicativos de front-end primeiro tem várias vantagens, incluindo as seguintes:
- Os componentes de front-end dependem de recursos de back-end e, às vezes, de outros componentes de front-end.
- Os componentes de back-end não dependem dos componentes de front-end. Portanto, isolar e migrar aplicativos de front-end tende a ser menos complexo do que migrar aplicativos de back-end.
- Como os aplicativos de front-end geralmente são sem estado ou não gerenciam dados
por si, eles tendem a ser menos difíceis de migrar do que os back-ends.
- Os componentes de front-end podem ser otimizados como parte da migração para usar arquitetura sem estado. Para mais informações, assista ao vídeo Como portar apps da Web com estado para o Cloud Run no YouTube.
A implantação na nuvem de aplicativos de front-end atuais ou recém-desenvolvidos tem várias vantagens:
- Muitas aplicações de front-end estão sujeitas a alterações frequentes. A execução desses aplicativos na nuvem pública simplifica a configuração de um processo de integração contínua/implantação contínua (CI/CD). Você pode usar a CI/CD para enviar atualizações de maneira eficiente e automatizada. Para mais informações, consulte CI/CD no Google Cloud.
- Front-ends sensíveis ao desempenho com carga de tráfego variável podem se beneficiar substancialmente do balanceamento de carga, das implantações multirregionais, do armazenamento em cache do Cloud CDN, sem servidor e dos recursos de escalonamento automático que uma implantação baseada na nuvem permite (de preferência com uma arquitetura sem estado).
A adoção de microsserviços com contêineres usando uma plataforma gerenciada pela nuvem, como o GKE, permite usar arquiteturas modernas, como o microfront-end, que estendem microsserviços para os componentes de front-end.
A extensão de microsserviços é comumente usada com front-ends que envolvem várias equipes colaborando no mesmo aplicativo. Esse tipo de estrutura de equipe exige uma abordagem iterativa e manutenção contínua. Confira a seguir algumas das vantagens do uso de microfront-ends:
- Ele pode ser transformado em módulos de microsserviços independentes para desenvolvimento, teste e implantação.
- Ele oferece separação em que equipes de desenvolvimento individuais podem selecionar as tecnologias e o código preferidos.
- Ele pode estimular ciclos rápidos de desenvolvimento e implantação sem afetar o restante dos componentes de front-end que podem ser gerenciados por outras equipes.
Seja implementando interfaces de usuário ou APIs ou lidando com o processamento de dados da Internet das Coisas (IoT), os aplicativos de front-end podem se beneficiar dos recursos oferecidos por serviços em nuvem, como o Firebase, o Pub/Sub, o Apigee, o Cloud CDN, o App Engine ou o Cloud Run.
Os proxies de API gerenciados pela nuvem ajudam a:
- Desvincule a API voltada para o app dos seus serviços de back-end, como microsserviços.
- Protege apps contra mudanças no código de back-end.
- Ofereça suporte a arquiteturas de front-end orientadas a API, como back-end para front-end (BFF), microfront-end e outras.
- Exponha suas APIs no Google Cloud ou em outros ambientes implementando proxies de API no Apigee.
Também é possível aplicar o padrão híbrido em camadas ao contrário, implantando back-ends na nuvem e mantendo front-ends em ambientes de computação particulares. Embora seja menos comum, essa abordagem é melhor aplicada quando você está lidando com um front-end pesado e monolítico. Nesses casos, pode ser mais fácil extrair iterativamente a funcionalidade de back-end e implantar esses novos back-ends na nuvem.
A terceira parte desta série discute possíveis padrões de rede para permitir essa arquitetura. A Apigee híbrida ajuda como uma plataforma para criar e gerenciar proxies de API em um modelo de implantação híbrida. Para mais informações, consulte Arquitetura com acoplamento frouxo, incluindo arquiteturas monolíticas e de microsserviços em camadas.
Práticas recomendadas
Use as informações desta seção ao planejar sua arquitetura híbrida em camadas.
Práticas recomendadas para reduzir a complexidade
Ao aplicar o padrão de arquitetura híbrida em camadas, considere as práticas recomendadas a seguir, que podem ajudar a reduzir a complexidade operacional e de implantação geral:
- Com base na avaliação dos modelos de comunicação dos aplicativos identificados, selecione a solução de comunicação mais eficiente e eficaz para esses aplicativos.
Como a maior parte da interação do usuário envolve sistemas que se conectam a vários ambientes de computação, é importante ter conectividade rápida e de baixa latência entre esses sistemas. Para atender às expectativas de disponibilidade e desempenho, projete para alta disponibilidade, baixa latência e níveis de capacidade de processamento adequados. Do ponto de vista da segurança, a comunicação precisa ser refinada e controlada. O ideal é expor componentes do aplicativo usando APIs seguras. Para mais informações, consulte Saída controlada.
- Para minimizar a latência de comunicação entre os ambientes, selecione uma regiãoGoogle Cloud que esteja geograficamente próxima ao ambiente de computação particular em que os componentes de back-end do aplicativo são hospedados. Saiba mais em Práticas recomendadas para a seleção de regiões do Compute Engine.
- Minimize dependências altas entre sistemas que estão sendo executados em diferentes ambientes, principalmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem diminuir o desempenho, diminuir a disponibilidade geral e possivelmente gerar cobranças adicionais de transferência de dados de saída.
- Com o padrão de arquitetura híbrido em camadas, é possível ter volumes maiores de tráfego de entrada de ambientes locais para aGoogle Cloud em comparação com o tráfego de saída que sai da Google Cloud. No entanto, você precisa saber o volume esperado de transferência de dados de saída que sai do Google Cloud. Se você planeja usar essa arquitetura a longo prazo com grandes volumes de transferência de dados de saída, 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 para o tráfego que atenda a determinadas condições. Para saber mais, consulte Preços do Cloud Interconnect.
- Para proteger informações sensíveis, recomendamos criptografar todas as comunicações em trânsito. Se a criptografia for necessária na camada de conectividade, você poderá usar túneis de VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para Cloud Interconnect.
Para superar inconsistências em protocolos, APIs e mecanismos de autenticação em vários serviços de back-end, recomendamos, quando aplicável, implantar um gateway de API ou proxy como uma fachada unificadora. Esse gateway ou proxy atua como um ponto de controle centralizado e faz o seguinte:
- Implementa medidas de segurança adicionais.
- Protege apps clientes e outros serviços contra mudanças no código de back-end.
- Facilita trilhas de auditoria para comunicação entre todos aplicativos entre ambientes e seus componentes dissociados.
- Atua como
camada de comunicação intermediária
entre serviços legados e modernizados.
- A Apigee e a Apigee híbrida permitem hospedar e gerenciar gateways híbridos e corporativos em ambientes locais, de borda, em outras nuvens e Google Cloud .
Para facilitar o estabelecimento de configurações híbridas, use o Cloud Load Balancing com conectividade híbrida. Isso significa que você pode estender os benefícios do balanceamento de carga da nuvem para serviços hospedados no seu ambiente de computação local. Essa abordagem permite migrações de carga de trabalho em fases para Google Cloud com interrupção mínima ou nenhuma interrupção do serviço, garantindo uma transição tranquila para os serviços distribuídos. Para mais informações, consulte Visão geral dos grupos de endpoints da rede de conectividade híbrida.
Às vezes, usar um gateway de API ou um proxy e um Application Load Balancer juntos pode oferecer uma solução mais robusta para gerenciar, proteger e distribuir o tráfego de API em grande escala. Usar o Cloud Load Balancing com gateways de API permite realizar o seguinte:
- Ofereça APIs de alto desempenho com a Apigee e o Cloud CDN, para reduzir a latência, hospedar APIs globalmente e aumentar a disponibilidade para tempos de pico de tráfego. Para mais informações, assista Como entregar APIs de alto desempenho com a Apigee e o Cloud CDN no YouTube.
- Implementar o gerenciamento de tráfego avançado.
- Use o Google Cloud Armor como um serviço de proteção contra DDoS e segurança de rede para proteger suas APIs.
- Gerenciar eficientemente o balanceamento de carga entre gateways em várias regiões. Para mais informações, assista Como proteger as APIs e implementar o failover multirregional com o Private Service Connect e a Apigee no YouTube.
Use o gerenciamento de API e a malha de serviço para proteger e controlar a comunicação e a exposição do serviço com a arquitetura de microsserviços.
- Use o Cloud Service Mesh para permitir a comunicação entre serviços que mantém a qualidade em um sistema composto de serviços distribuídos, em que é possível gerenciar a autenticação, a autorização e a criptografia entre serviços.
- Use uma plataforma de gerenciamento de APIs como a Apigee, que permite que sua organização e entidades externas consumam esses serviços exibindo-os como APIs.
Estabeleça uma identidade comum entre os ambientes, para que a autenticação dos sistemas possa ser feita com segurança nos limites do ambiente.
Implante sistemas de CI/CD e gerenciamento de configuração na nuvem pública. Para mais informações, consulte Padrão de arquitetura de rede espelhada.
Para aumentar a eficiência operacional, use ferramentas consistentes e pipelines de CI/CD em todos os ambientes.
Práticas recomendadas para arquiteturas de aplicativos e cargas de trabalho individuais
- Embora o foco esteja nos aplicativos de front-end nesse padrão, fique atento à necessidade de modernizar os aplicativos de back-end. Se o ritmo de desenvolvimento de aplicativos de back-end for substancialmente mais lento do que para aplicativos de front-end, a diferença pode causar complexidade extra.
- Tratar as APIs como interfaces de back-end simplifica as integrações, o desenvolvimento do front-end, as interações de serviço e oculta as complexidades do sistema de back-end. Para resolver esses desafios, a Apigee facilita o desenvolvimento e o gerenciamento de gateway/proxy de API para implantações híbridas e multicloud.
- Escolha a abordagem de renderização para seu aplicativo da Web de front-end com base no conteúdo (estático ou dinâmico), no desempenho de otimização de mecanismos de pesquisa e nas expectativas sobre as velocidades de carregamento da página.
- Ao selecionar uma arquitetura para aplicativos da Web orientados a conteúdo, várias opções estão disponíveis, incluindo arquiteturas monolíticas, sem servidor, orientadas a eventos e de microsserviços. Para selecionar a arquitetura mais adequada, avalie essas opções em relação aos requisitos atuais e futuros do aplicativo. Para ajudar você a tomar uma decisão arquitetônica que esteja alinhada aos seus objetivos comerciais e técnicos, consulte Comparação de diferentes arquiteturas para back-ends de aplicativos da Web orientados a conteúdo e Considerações importantes para back-ends da Web.
Com uma arquitetura de microsserviços, é possível usar aplicativos conteinerizados com o Kubernetes como a camada de execução comum. Com o padrão de arquitetura híbrida em camadas, é possível executá-lo em um dos seguintes cenários:
Em ambos os ambientes (Google Cloud e seus ambientes locais).
- Ao usar contêineres e o Kubernetes em ambientes, você tem a flexibilidade de modernizar cargas de trabalho e migrar para Google Cloud em momentos diferentes. Isso ajuda quando uma carga de trabalho depende muito de outra e não pode ser migrada individualmente ou para usar a portabilidade híbrida de carga de trabalho e aproveitar os melhores recursos disponíveis em cada ambiente. Em todos os casos, o GKE Enterprise pode ser uma tecnologia capacitadora fundamental. Para mais informações, consulte Ambiente híbrido do GKE Enterprise.
Em um ambiente Google Cloud para os componentes do aplicativo migrados e modernizados.
- Use essa abordagem quando você tiver back-ends legados no local que não têm suporte para contêineres ou que exigem tempo e recursos significativos para serem modernizados em curto prazo.
Para mais informações sobre como projetar e refatorar um app monolítico para uma arquitetura de microsserviços para modernizar a arquitetura do seu aplicativo da Web, consulte Introdução aos microsserviços.
É possível combinar tecnologias de armazenamento de dados de acordo com as necessidades dos aplicativos da Web. O uso do Cloud SQL para dados estruturados e do Cloud Storage para arquivos de mídia é uma abordagem comum para atender a diversas necessidades de armazenamento de dados. No entanto, a escolha depende muito do seu caso de uso. Para mais informações sobre as opções de armazenamento de dados para back-ends de aplicativos orientados a conteúdo e modalidades eficazes, consulte Opções de armazenamento de dados para apps da Web orientados a conteúdo. Consulte também Suas opções de banco de dados Google Cloud , explicadas.
Padrão de várias nuvens particionadas
O padrão de arquitetura de multicloud particionado combina vários ambientes de nuvem operados por diferentes provedores de serviços de nuvem. Essa arquitetura oferece a flexibilidade de implantar um aplicativo em um ambiente computacional otimizador que é responsável por drivers multicloud e considerações discutidas na primeira parte desta série.
O diagrama a seguir mostra uma arquitetura multicloud particionada padrão.
Esse padrão de arquitetura pode ser criado de duas maneiras diferentes. A primeira abordagem é baseada na implantação dos componentes do aplicativo em diferentes nuvens públicas do Google Cloud. Essa abordagem também é conhecida como arquitetura composta e é a mesma abordagem da arquitetura padrão híbrida em camadas. Em vez de usar um ambiente no local com uma rede pública, ela usa no mínimo dois ambientes de nuvem. Em uma arquitetura de composição, uma única carga de trabalho ou aplicativo usa componentes de mais de uma nuvem. A segunda abordagem implanta aplicativos diferentes em ambientes de nuvem pública. Esta lista com alguns exemplos descreve alguns dos motivadores de negócios para a segunda abordagem:
- Integrar totalmente aplicativos hospedados em ambientes de nuvem diferentes durante um cenário de fusão e aquisição entre duas empresas.
- Promover a flexibilidade e atender a diversas preferências da nuvem em toda a organização. Essa abordagem incentiva as unidades organizacionais a escolher o provedor de nuvem mais adequado às suas necessidades e preferências específicas.
- Operar em uma implantação multirregional ou de nuvem global. Se uma empresa precisar cumprir os regulamentos de residência de dados em determinadas regiões ou países, ela precisa escolher entre os provedores de nuvem disponíveis no local, caso o provedor de nuvem principal não tenha uma região de nuvem nesse local.
Com o padrão de arquitetura multicloud particionada, opcionalmente, é possível manter a capacidade de transferir cargas de trabalho conforme necessário de um ambiente de nuvem pública para outro. Nesse caso, a portabilidade das cargas de trabalho se torna um requisito importante. Quando você implanta cargas de trabalho em vários ambientes computacionais e quer manter a capacidade de mover as cargas de trabalho entre esses ambientes, é preciso deixar de lado as diferenças entre eles. Com o GKE Enterprise, é possível projetar e criar uma solução para resolver a complexidade multicloud com governança, operações e segurança na postura de segurança. Para mais informações, consulte GKE Multi-Cloud-Cloud.
Conforme mencionado anteriormente, existem algumas situações em que pode haver motivos comerciais e técnicos para combinar o Google Cloud com outro provedor de nuvem e particionar as cargas de trabalho nesses ambientes de nuvem. As soluções multicloud oferecem a flexibilidade de migrar, criar e otimizar a portabilidade de aplicativos entre ambientes multicloud, minimizando a dependência e ajudando você a atender aos requisitos regulatórios. Por exemplo, você pode conectar Google Cloud à Oracle Cloud Infrastructure (OCI) para criar uma solução multicloud que aproveite os recursos de cada plataforma usando uma interconexão privada do Cloud Interconnect para combinar componentes em execução no OCI com recursos em execução no Google Cloud. Para mais informações, consulte Google Cloud e Oracle Cloud Infrastructure: como aproveitar ao máximo o recurso multicloud. Além disso, o Cross-Cloud Interconnect facilita a conectividade dedicada de alta largura de banda entre o Google Cloud e outros provedores de serviços em nuvem compatíveis, permitindo que você projete e crie soluções multicloud para lidar com o volume de tráfego entre nuvens. Google Cloud
Vantagens
A arquitetura multicloud oferece vários benefícios, de negócios e técnicos, conforme discutido em Impulsionadores, considerações, estratégias e abordagens. Ela é essencial para realizar uma avaliação de viabilidade detalhada de cada benefício potencial. Sua avaliação deve considerar cuidadosamente qualquer associação direta, desafios indiretos ou potenciais obstáculos e a capacidade de enfrentá-los de maneira eficaz. Além disso, ela considera que o crescimento a longo prazo dos aplicativos ou serviços pode introduzir complexidades que talvez superem os benefícios iniciais.
Essas são algumas das principais vantagens do padrão de arquitetura multicloud particionada:
Em cenários em que é necessário minimizar a compromisso com um único provedor de nuvem, é possível distribuir aplicativos em diferentes provedores de serviços. Como resultado, você pode reduzir relativamente a dependência de fornecedores com a capacidade de alterar planos (até certo ponto) nos provedores de nuvem. A nuvem aberta ajuda a oferecer recursos do Google Cloud , como o GKE Enterprise, para diferentes locais físicos. Ao estender os recursos do Google Cloud no local, em várias nuvens públicas e na borda, ela oferece flexibilidade, agilidade e promove a transformação.
Por motivos regulamentares, você veicula um determinado segmento da sua base de usuários e dados de um país onde o Google Cloud não tem uma região de nuvem.
O padrão de arquitetura multicloud particionada pode ajudar a reduzir a latência e melhorar a qualidade geral da experiência do usuário em locais em que o provedor de nuvem principal não tem um ponto de presença na região. Esse padrão é útil principalmente ao usar a conectividade multicloud de alta capacidade e baixa latência, como o Cross-Cloud Interconnect e o CDN Interconnect com uma CDN distribuída.
É possível implantar aplicativos em vários provedores de nuvem para escolher entre os melhores serviços oferecidos por outros provedores de nuvem.
O padrão de arquitetura multicloud particionada pode facilitar e acelerar cenários de fusão e aquisição, em que os aplicativos e os serviços de duas empresas podem estar hospedados em ambientes de nuvem pública diferentes.
Práticas recomendadas
- Comece implantando uma carga de trabalho não essencial. Essa implantação inicial na nuvem secundária poderá servir como padrão para futuras implantações ou migrações. No entanto, essa abordagem provavelmente não é aplicável em situações em que a carga de trabalho específica é legal ou regulatória e deve estar localizada em uma região de nuvem específica, e o provedor de nuvem principal não tem uma região no território necessário.
- Minimize dependências entre sistemas que estão sendo executados em diferentes ambientes de nuvem pública, especialmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem retardar o desempenho, diminuir a disponibilidade e, possivelmente, ter cobranças adicionais de transferência de dados de saída.
- Para se abstrair das diferenças entre os ambientes, avalie o uso de contêineres e Kubernetes quando possível e se for compatível com os aplicativos.
- Verifique se os pipelines e as ferramentas de CI/CD para implantação e monitoramento são consistentes em todos os ambientes de nuvem.
- Selecione um padrão de arquitetura de rede ideal que ofereça uma
comunicação mais eficiente e eficaz para os aplicativos
que estiver usando.
- A comunicação precisa ser refinada e controlada. Use APIs seguras para expor componentes de aplicativos.
- Considere usar uma arquitetura padrão em malha ou um dos padrões de rede controlados, com base nos requisitos técnicos e comerciais específicos.
- Para atender às suas expectativas de disponibilidade e desempenho, crie um projeto com alta disponibilidade de ponta a ponta, baixa latência e níveis de capacidade de processamento apropriados.
Para proteger informações sensíveis, recomendamos criptografar todas as comunicações em trânsito.
- 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 selecionada. Essas opções incluem túneis VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para o Cross-Cloud Interconnect.
Se você estiver usando várias CDNs como parte do padrão de arquitetura particionada de várias nuvens e estiver preenchendo a outra CDN com arquivos de dados grandes de Google Cloud, considere usar links do CDN Interconnect entre Google Cloud e provedores com suporte para otimizar esse tráfego e, possivelmente, o custo.
Estenda a solução de gerenciamento de identidade entre os ambientes para que a autenticação dos sistemas possa ser feita com segurança nos limites do ambiente.
Para equilibrar de forma eficaz as solicitações no Google Cloud e em outra plataforma de nuvem, use o Cloud Load Balancing. Para mais informações, consulte Como rotear o tráfego para um local físico ou outra nuvem.
- Se o volume de transferência de dados de saída do Google Cloud para outros ambientes for alto, use o Cross-Cloud Interconnect.
Para superar inconsistências em protocolos, APIs e mecanismos de autenticação em vários serviços de back-end, recomendamos, quando aplicável, implantar um gateway de API ou proxy como uma fachada unificadora. Esse gateway ou proxy atua como um ponto de controle centralizado e faz o seguinte:
- Implementa medidas de segurança adicionais.
- Protege apps clientes e outros serviços contra mudanças no código de back-end.
- Facilita trilhas de auditoria para comunicação entre todos aplicativos entre ambientes e seus componentes dissociados.
- Atua como
camada de comunicação intermediária
entre serviços legados e modernizados.
- A Apigee e a Apigee híbrida permitem hospedar e gerenciar gateways híbridos e corporativos em ambientes locais, de borda, em outras nuvens e Google Cloud .
Em alguns dos casos a seguir, o uso do Cloud Load Balancing com um gateway de API pode fornecer uma solução robusta e segura para gerenciar, proteger e distribuir o tráfego da API em grande escala em várias regiões:
- Como implantar o failover multirregional para a execução da API Apigee em diferentes regiões.
Como melhorar a performance com o Cloud CDN.
Proteção de WAF e DDoS com o Google Cloud Armor.
Use ferramentas consistentes para geração de registros e monitoramento em ambientes na nuvem sempre que possível. Considere usar o código aberto e o monitoramento de sistemas. Para mais informações, consulte Padrões de geração de registros e monitoramento híbrido e multicloud.
Se estiver implantando componentes de aplicativo de maneira distribuída, os componentes de um único aplicativo serão implantados em mais de um ambiente. Consulte as práticas recomendadas para o padrão de arquitetura híbrida em camadas.
Padrão analítico de nuvem híbrida e multicloud
Este documento discute que o objetivo do padrão analítico híbrido e multicloud é aproveitar a divisão entre cargas de trabalho transacionais e analíticas.
Nos sistemas corporativos, a maioria das cargas de trabalho se enquadra nestas categorias:
- Cargas de trabalho transacionais incluem aplicativos interativos como vendas, processamento financeiro, planejamento de recursos corporativos ou comunicação.
- Cargas de trabalho analíticas incluem aplicativos para transformação, análise, refino ou visualização de dados, com o objetivo de ajudar nos processos de tomada de decisão.
Os sistemas de análise recebem dados de sistemas transacionais, consultando APIs ou acessando bancos de dados. Na maioria das empresas, os sistemas analíticos e transacionais tendem a ser separados e fracamente acoplados. O objetivo do padrão analítico híbrido e de várias nuvens é aproveitar essa divisão preexistente ao executar cargas de trabalho transacionais e de análise em dois ambientes de computação diferentes. Os dados brutos são extraídos primeiro das cargas de trabalho em execução no ambiente de computação particular e, em seguida, carregados no Google Cloud, onde são usados para processamento analítico. Alguns dos resultados podem, então, ser retornados aos sistemas transacionais.
O diagrama a seguir ilustra conceitualmente as arquiteturas possíveis mostrando possíveis pipelines de dados. Cada caminho/seta representa uma possível opção de pipeline de movimentação e transformação de dados que pode ser baseada em ETL ou ELT, dependendo da qualidade de dados disponível e do caso de uso desejado.
Para mover seus dados para o Google Cloud e aproveitar o valor deles, use os serviços de movimentação de dados, um pacote completo de serviços de ingestão, integração e replicação de dados.
Como mostrado no diagrama anterior, conectar Google Cloud a ambientes locais e outros ambientes de nuvem pode ativar vários casos de uso de análise de dados, como streaming de dados e backups de banco de dados. Para oferecer o transporte básico de um padrão de análise híbrida e multicloud que exige um grande volume de transferência de dados, o Cloud Interconnect e o Cross-Cloud Interconnect oferecem conectividade dedicada a provedores de nuvem e locais.
Vantagens
A execução de cargas de trabalho analíticas na nuvem tem muitas vantagens importantes:
- O tráfego de entrada (mover dados do ambiente de computação particular ou de outras nuvens para oGoogle Cloud) pode ser sem custo financeiro.
- As cargas de trabalho analíticas geralmente precisam processar quantidades substanciais de dados, o que pode ser feito em bursts. Portanto, elas são especialmente adequadas para serem implantadas em um ambiente de nuvem pública. Ao dimensionar recursos de computação dinamicamente, é possível processar rapidamente grandes conjuntos de dados, sem a necessidade de investimentos iniciais ou do provisionamento de equipamentos de computação em excesso.
- OGoogle Cloud oferece um conjunto avançado de serviços para gerenciar dados
em todo o ciclo de vida, desde a aquisição inicial até o processamento e a análise até a visualização final.
- Os serviços de movimentação de dados no Google Cloud oferecem um pacote completo de produtos para mover, integrar e transformar dados de diferentes maneiras.
- O Cloud Storage é adequado para criar um data lake.
OGoogle Cloud ajuda a modernizar e otimizar sua plataforma de dados para quebrar silos de dados. O uso de um lakehouse de dados ajuda a padronizar diferentes formatos de armazenamento. Ele também pode fornecer a flexibilidade, a escalonabilidade e a agilidade necessárias para garantir que seus dados gerem valor para sua empresa, e não ineficiências. Para mais informações, consulte BigLake.
O BigQuery Omni oferece capacidade de computação executada localmente no armazenamento da AWS ou do Azure. Ele também ajuda a consultar seus próprios dados armazenados no Amazon Simple Storage Service (Amazon S3) ou no Armazenamento de Blobs do Azure. Esse recurso de análise multicloud permite que as equipes de dados eliminem os silos de dados. Para mais informações sobre como consultar dados armazenados fora do BigQuery, consulte Introdução a fontes de dados externas.
Práticas recomendadas
Para implementar o padrão de arquitetura analítica híbrida e multicloud, considere as seguintes práticas recomendadas gerais:
- Use o padrão de rede de transferência para permitir a ingestão de dados. Se os resultados analíticos precisarem ser retornados aos sistemas transacionais, combine a entrega e o padrão de saída controlada.
- Use as filas do Pub/Sub ou os buckets do Cloud Storage para transmitir dados a Google Cloud sistemas transacionais em execução no ambiente de computação particular. Essas filas ou buckets poderão disponibilizar fontes para canais de processamento de dados e cargas de trabalho.
- Para implantar pipelines de dados ETL e ELT, use o Cloud Data Fusion ou o Dataflow, dependendo dos requisitos específicos do caso de uso. Ambos são serviços de processamento de dados totalmente gerenciados e com foco na nuvem para criar e gerenciar pipelines de dados.
- Para descobrir, classificar e proteger seus recursos de dados valiosos, use os recursos de Google Cloud Proteção de Dados Sensíveis, como técnicas de desidentificação. Essas técnicas permitem mascarar, criptografar e substituir dados sensíveis, como informações de identificação pessoal (PII), usando uma chave pré-determinada ou gerada aleatoriamente, quando aplicável e em conformidade.
- Quando você tiver cargas de trabalho Hadoop ou Spark, considere migrar jobs para o Dataproc e migrar dados atuais do HDFS para o Cloud Storage.
Ao realizar uma transferência de dados inicial do seu ambiente de computação particular para o Google Cloud, escolha a abordagem de transferência mais adequada ao tamanho do conjunto de dados e à largura de banda disponível. Para mais informações, consulte Migração para o Google Cloud: como transferir grandes conjuntos de dados.
Se a transferência ou troca de dados entre Google Cloud e outras nuvens for necessária por um longo período com alto volume de tráfego, avalie o uso do Google Cloud Cross-Cloud Interconnect para estabelecer uma conectividade dedicada de alta largura de banda entre Google Cloud e outros provedores de serviços de nuvem (disponível em determinados locais).
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 o Cross-Cloud Interconnect.
Use ferramentas e processos que sejam consistentes em vários ambientes. Em um cenário híbrido de análise, essa prática pode ajudar a aumentar a eficiência operacional, mas não é um pré-requisito.
Padrão híbrido de borda
A execução de cargas de trabalho na nuvem exige que os clientes, em alguns cenários, tenham uma conexão de Internet rápida e confiável. Considerando as redes atuais, esse requisito raramente representa um desafio para a adoção da nuvem. No entanto, há cenários em que não é possível confiar na conectividade contínua, como:
- Navios e outros veículos podem estar conectados apenas intermitentemente ou ter acesso somente a links de satélite de alta latência.
- Fábricas ou usinas elétricas podem estar conectadas à Internet. Essas instalações podem ter requisitos de confiabilidade que excedem as declarações de disponibilidade do provedor de Internet.
- Lojas de varejo e supermercados podem estar conectados apenas ocasionalmente ou usar links que não oferecem a confiabilidade ou a capacidade de processamento necessárias para lidar com transações críticas para os negócios.
O padrão de arquitetura híbrido de borda soluciona esses desafios executando cargas de trabalho urgentes em termos de prazos e negócios localmente, na borda da rede, enquanto usa a nuvem para todos os outros tipos de cargas de trabalho. Em uma arquitetura híbrida de borda, o link da Internet é um componente não crítico usado para gerenciar e sincronizar ou fazer upload de dados, muitas vezes de forma assíncrona, mas não interfere em transações críticas em termos de prazos ou de negócios.
Vantagens
A execução de determinadas cargas de trabalho na borda e de outras cargas de trabalho na nuvem oferece diversas vantagens:
- O tráfego de entrada (mover dados da borda para o Google Cloud) pode ser sem custo financeiro.
- A execução na borda de cargas de trabalho urgentes e essenciais para o negócio ajuda a garantir baixa latência e autossuficiência. Se a conectividade com a Internet falhar ou estiver temporariamente indisponível, ainda será possível executar todas as transações importantes. Ao mesmo tempo, é possível se beneficiar do uso da nuvem em uma parte significativa da sua carga de trabalho geral.
- É possível reutilizar os investimentos atuais em equipamentos de computação e armazenamento.
- Com o tempo, é possível reduzir gradativamente a fração de cargas de trabalho que são executadas na borda e movê-las para a nuvem, seja reformulando determinados aplicativos ou equipando alguns locais de borda com links da Internet que são mais confiáveis.
- Projetos relacionados à Internet das Coisas (IoT) podem se tornar mais econômicos ao realizar o processamento de dados localmente. Isso permite que as empresas executem e processem alguns serviços localmente na borda, mais perto das fontes de dados. Também permite que as empresas enviem dados seletivamente para a nuvem, o que pode ajudar a reduzir o consumo da capacidade, da transferência de dados, do processamento e os custos gerais da solução de IoT.
- A computação de borda pode agir como uma camada de comunicação intermediária entre serviços legados e modernizados. Por exemplo, serviços que podem estar executando um gateway de API conteinerizado, como a Apigee híbrida. Isso permite a integração de aplicativos e sistemas legados com serviços modernos, como soluções de IoT.
Práticas recomendadas
Considere as seguintes recomendações ao implementar o padrão de arquitetura de híbrido de borda:
- Se a comunicação for unidirecional, use o padrão de entrada controlada.
- Se a comunicação for bidirecional, considere o padrão de entrada e saída controladas.
- Se a solução consistir em muitos sites remotos de borda se conectando aoGoogle Cloud pela Internet pública, é possível usar uma solução WAN definida por software (SD-WAN). Você também pode usar o Network Connectivity Center com um roteador SD-WAN de terceiros aceito pelo Google Cloud parceiro para simplificar o provisionamento e o gerenciamento de conectividade segura em grande escala.
- Minimize as dependências entre os sistemas que estão sendo executados na borda e os sistemas em execução no ambiente de nuvem. Cada dependência pode minar as vantagens de confiabilidade e latência de uma configuração híbrida de borda.
- Para gerenciar e operar vários locais de borda com eficiência, você deve ter um plano de gerenciamento centralizado e uma solução de monitoramento na nuvem.
- Garanta que os pipelines de CI/CD com as ferramentas para implantação e monitoramento sejam consistentes em todos os ambientes de nuvem e borda.
- Considere usar contêineres e o Kubernetes quando aplicável e viável
para abstrair as diferenças entre vários locais de borda e também entre
locais de borda e a nuvem. Como o Kubernetes oferece uma camada de ambiente de execução comum,
é possível desenvolver, executar e operar cargas de trabalho de forma consistente
em ambientes de computação. Também é possível mover cargas de trabalho entre a borda
e a nuvem.
- Para simplificar a configuração híbrida e a operação, use o GKE Enterprise para essa arquitetura, se contêineres forem usados nos ambientes. Considere as possíveis opções de conectividade necessárias para conectar um cluster do GKE Enterprise em execução no seu ambiente local ou de borda ao Google Cloud.
- Como parte desse padrão, embora alguns componentes do GKE Enterprise possam se sustentar durante uma interrupção temporária de conectividade no Google Cloud, não use o GKE Enterprises quando ele estiver desconectado do Google Cloud como um modo de trabalho nominal. Para mais informações, consulte Impacto da desconexão temporária do Google Cloud.
- Para superar inconsistências em protocolos, APIs e mecanismos
de autenticação em vários serviços de back-end e borda, recomendamos, quando
aplicável, implantar um gateway de API ou proxy como uma fachada
unificadora.
Esse gateway ou proxy atua como um ponto de controle centralizado e faz o
seguinte:
- Implementa medidas de segurança adicionais.
- Protege apps clientes e outros serviços contra mudanças no código de back-end.
- Facilita trilhas de auditoria para comunicação entre todos aplicativos entre ambientes e seus componentes dissociados.
- Atua como
camada de comunicação intermediária
entre serviços legados e modernizados.
- A Apigee e a Apigee híbrida permitem hospedar e gerenciar gateways híbridos e corporativos em ambientes locais, de borda, em outras nuvens e Google Cloud .
- Estabeleça uma identidade comum entre os ambientes, para que a autenticação dos sistemas possa ser feita com segurança nos limites do ambiente.
- Como os dados trocados entre os ambientes podem ser sensíveis, garanta que qualquer comunicação seja criptografada em trânsito usando túneis VPN, TLS ou ambos.
Padrão híbrido de ambiente
Com o padrão de arquitetura híbrido de ambiente, você mantém o ambiente de produção de carga de trabalho no data center atual. Depois, você usa a rede nuvem para seus ambientes de desenvolvimento e teste ou outros. Esse padrão depende da implantação redundante dos mesmos aplicativos em vários ambientes de computação. O objetivo da implantação é ajudar a aumentar a capacidade, a agilidade e a resiliência.
Ao avaliar quais cargas de trabalho migrar, talvez você perceba casos em que a execução de um aplicativo específico na nuvem pública apresenta desafios:
- Restrições relativas a uma jurisdição ou regulatórias podem exigir que você mantenha dados em um país específico.
- Termos de licenciamento de terceiros podem impedir que você opere determinados softwares em um ambiente de nuvem.
- Um aplicativo pode exigir acesso a dispositivos de hardware disponíveis apenas localmente.
Nesses casos, considere não só o ambiente de produção, mas todos ambientes que estão envolvidos no ciclo de vida de um aplicativo, incluindo desenvolvimento, teste e preparo. Essas restrições geralmente se aplicam à o ambiente de produção e os dados dele. Talvez elas não se apliquem a outras ambientes que não usam dados reais. Verifique a conformidade departamento de sua organização ou a equipe equivalente.
O diagrama a seguir mostra um típico padrão híbrido de ambiente.
Executar sistemas de desenvolvimento e teste em ambientes diferentes sistemas de produção podem parecer arriscados e podem se desviar do seu melhor práticas ou de suas tentativas de minimizar diferenças entre suas do Google Cloud. Essas preocupações se justificam, mas não se aplicam se você distinguir entre os cenários dos processos de desenvolvimento e teste:
Os processos de desenvolvimento, teste e implantação são diferentes para cada aplicativo, mas eles geralmente envolvem variações dos seguintes cenários:
- Desenvolvimento: criar um candidato de versão.
- Teste funcional ou teste de aceitação do usuário: verificar se o candidato de versão atende aos requisitos funcionais.
- Teste de desempenho e confiabilidade: verificar se o candidato de versão atende aos requisitos não funcionais. Também é conhecido como teste de carga.
- Teste de implantação ou preparo: verificar se o procedimento de implantação funciona.
- Produção: lançar aplicativos novos ou atualizados.
Raramente vale a pena realizar mais de um desses cenários em um único ambiente. Portanto, cada um deles normalmente requer um ou mais ambientes dedicados.
O objetivo principal de um ambiente de teste é executar testes funcionais. O a finalidade principal de um ambiente de preparação é testar se o aplicativo de implantação funcionam conforme o esperado. No momento em que uma versão chega ao estágio de preparo ambiente, seu teste funcional deve estar concluído. O preparo é o último antes de implantar o software na implantação de produção.
Para garantir que os resultados do teste sejam significativos e se apliquem à implementação de produção, é preciso que o conjunto de ambientes, usado durante o ciclo de vida de um aplicativo, atenda às seguintes regras, na medida do possível
- Todos os ambientes são funcionalmente equivalentes. Ou seja, a arquitetura, as APIs e as versões de sistemas operacionais e bibliotecas são equivalentes e os sistemas se comportam da mesma forma em todos os ambientes. Esta a equivalência evita situações em que os aplicativos funcionam em um só ambiente mas falham em outra ou quando os defeitos não são reproduzíveis.
- Ambientes que são usados para teste de desempenho e confiabilidade, preparação e produção são equivalentes de maneira não funcional. Ou seja, o desempenho, a escala, a configuração e a maneira como são operados e mantidos são iguais ou diferem apenas de maneiras insignificantes. Caso contrário, os testes de desempenho e preparo perderão o sentido.
Em geral, tudo bem se os ambientes usados para desenvolvimento e os testes funcionais diferem não funcionalmente dos outros ambientes.
Conforme ilustrado no diagrama a seguir, os ambientes de teste e desenvolvimento são criados em Google Cloud. Um banco de dados gerenciado, como o Cloud SQL, pode ser usado como uma opção para desenvolvimento e teste em Google Cloud. Desenvolvimento e testes podem usar o mesmo mecanismo de banco de dados e versão no ambiente local de rede, um que é funcionalmente equivalente ou uma nova versão lançada para o ambiente de produção após a etapa de teste. No entanto, como o na infraestrutura dos dois ambientes não são iguais, abordagem aos testes de carga de desempenho não é válida.
Os cenários a seguir podem se encaixar bem com o padrão de ambiente híbrido:
- Alcance a equivalência funcional em todos os ambientes usando
Kubernetes como uma camada de ambiente de execução comum, quando aplicável e viável.
A edição Google Kubernetes Engine (GKE) Enterprise pode ser uma tecnologia fundamental para esse
abordagem humilde.
- Garanta a portabilidade da carga de trabalho e abstraia as diferenças entre de computação em nuvem. Com um malha de serviço de confiança zero, é possível controlar e manter a separação de comunicações entre os diferentes ambientes.
- Execute ambientes de desenvolvimento e testes funcionais na nuvem pública. Esses ambientes podem ser funcionalmente equivalentes aos ambientes, mas podem diferir em aspectos não funcionais, como desempenho. Esse conceito é ilustrado no diagrama anterior.
- Execute ambientes para produção, teste e desempenho (teste de carregamento) e testes de confiabilidade no ambiente de computação particular e garanta as equivalências funcional e não funcional.
Considerações sobre o design
- Necessidades comerciais: cada estratégia de implantação e lançamento para aplicativos tem vantagens e desvantagens próprias. Para garantir que a abordagem selecionada se alinha com seus requisitos específicos, base suas seleções em uma avaliação completa das necessidades e restrições do seu negócio.
- Diferenças de ambiente: como parte desse padrão, o objetivo principal de usar esse ambiente de nuvem é para desenvolvimento e teste. O último é hospedar o aplicativo testado no ambiente privado de produção. Para evitar o desenvolvimento e o teste de um recurso que podem funcionar como esperado no ambiente de nuvem e falhar de produção (no local), a equipe técnica deve conhecer entender as arquiteturas e os recursos dos dois ambientes. Esta inclui dependências de outros aplicativos e do hardware infraestrutura, por exemplo, sistemas de segurança que realizam inspeção de tráfego.
- Governança: controlar o que a empresa pode desenvolver em nuvem e quais dados podem ser usados para testes, uma análise de e governança do processo. Esse processo também pode ajudar sua empresa a garantir ele não usa nenhum recurso de nuvem no desenvolvimento e nos testes ambientes que não existem no ambiente de produção local.
- Critérios de sucesso: precisam ser claros, predefinidos e mensuráveis. os critérios de sucesso do teste que se alinham com o software garantia de qualidade de qualidade para sua organização. Aplique esses padrões a qualquer aplicativo que você desenvolve e testa.
- Redundância: embora os ambientes de desenvolvimento e teste possam não com tanta confiabilidade quanto o ambiente de produção, eles ainda precisam redundantes e redundantes e na capacidade de testar diferentes cenários de falha. Seus requisitos do cenário de falha podem fazer com que o design inclua redundância como parte de seu ambiente de desenvolvimento e teste.
Vantagens
A execução de cargas de trabalho de desenvolvimento e de testes funcionais na nuvem pública tem muitas vantagens:
- É possível iniciar e interromper ambientes automaticamente conforme a necessidade.
Por exemplo, é possível provisionar um ambiente inteiro para cada solicitação de confirmação ou recepção, permitir que os testes sejam executados e, em seguida, desligá-lo novamente. Essa abordagem
também oferece as seguintes vantagens:
- É possível reduzir custos interrompendo instâncias de máquina virtual (VM) quando estão inativos ou provisionando ambientes apenas sob demanda.
- Você pode acelerar o desenvolvimento e os testes iniciando ambientes temporários para cada solicitação de envio. Isso também reduz a sobrecarga de manutenção reduz inconsistências no ambiente de build.
- A execução desses ambientes na nuvem pública ajuda a criar familiaridade e confiança na nuvem e nas ferramentas relacionadas, o que pode ajudar na migração de outras cargas de trabalho. Essa abordagem é particularmente útil se você decidir explorar Portabilidade de cargas de trabalho com contêineres e Kubernetes, por exemplo, usando GKE Enterprise entre ambientes.
Práticas recomendadas
Para implementar o padrão de arquitetura híbrida de ambiente, Considere as seguintes recomendações:
- Defina os requisitos de comunicação do aplicativo, incluindo o rede e segurança ideais para você. Em seguida, use o padrão de rede espelhada para ajudar você a projetar sua arquitetura de rede para evitar comunicações diretas entre sistemas de diferentes ambientes. Se comunicação é necessária entre ambientes, ela tem que ser em um ambiente semelhante.
A estratégia de implantação e teste do aplicativo escolhida deve estar alinhada com seus objetivos e requisitos de negócios. Isso pode envolver fazer implementar alterações sem inatividade ou implementar recursos gradualmente para um ambiente ou grupo de usuários específico antes do lançamento mais abrangente.
Para tornar as cargas de trabalho portáteis e abstrair as diferenças entre ambientes, é possível usar contêineres com o Kubernetes. Para mais informações, consulte Arquitetura de referência do ambiente híbrido do GKE Enterprise.
Estabelecer uma cadeia de ferramentas comum que funcione em ambientes de computação para implantação, configuração e operação de cargas de trabalho. O uso do Kubernetes oferece essa consistência.
Garantir que os pipelines de CI/CD sejam consistentes em toda a computação ambientes e o mesmo conjunto de binários, pacotes ou os contêineres são implantados nesses ambientes.
Ao usar o Kubernetes, use um sistema de CI, como o Tekton, para implementar um canal de implantação que implante em clusters e funcione em vários ambientes. Para mais informações, consulte Soluções de DevOps no Google Cloud.
Para ajudar você com a liberação contínua de aplicativos seguros e confiáveis aplicativos, incorporam a segurança como parte integrante do de segurança (DevSecOps). Para mais informações, consulte Entregue e proteja seu aplicativo voltado para a Internet em menos de uma hora usando o kit de ferramentas Dev(Sec)Ops.
Use as mesmas ferramentas para geração de registros e monitoramento em Google Cloud e em ambientes de nuvem atuais. Considere usar o monitoramento de código aberto sistemas. Para mais informações, consulte Padrões de geração de registros e monitoramento híbridos e multicloud.
Quando equipes diferentes gerenciam cargas de trabalho de teste e produção, ferramentas podem ser aceitáveis. No entanto, usar as mesmas ferramentas com diferentes permissões de leitura podem ajudar a reduzir o esforço e a complexidade do treinamento.
Ao escolher serviços de banco de dados, armazenamento e mensagens para testes funcionais, use produtos que tenham um equivalente gerenciado no Google Cloud. Confiar em serviços gerenciados ajuda a diminuir o esforço administrativo de manter ambientes de desenvolvimento e teste.
Para proteger informações sensíveis, recomendamos criptografar todas comunicações em trânsito. Se a criptografia for necessária no nível de conectividade há várias opções disponíveis, baseadas na estrutura híbrida e conectividade de rede. Essas opções incluem túneis VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para Cloud Interconnect.
A tabela a seguir mostra quais produtos Google Cloud são compatíveis com produtos OSS comuns.
Produto OSS | Compatível com o produto Google Cloud |
---|---|
Apache HBase | Bigtable |
Apache Beam | Dataflow |
CDAP | Cloud Data Fusion |
Apache Hadoop | Dataproc |
MySQL, PostgreSQL | Cloud SQL |
Cluster do Redis, Redis, Memcached | Memorystore |
Sistema de arquivos de rede (NFS, na sigla em inglês) | Filestore |
JMS, Kafka | Pub/Sub |
Kubernetes | GKE Enterprise |
Padrões híbridos e de várias nuvens de continuidade de negócios
O principal fator para considerar a continuidade de negócios em sistemas de missão crítica é ajudar uma organização a ser resiliente e continuar as operações de negócios durante e após eventos de falha. Ao replicar sistemas e dados em várias regiões geográficas e evitar pontos únicos de falha, é possível minimizar os riscos de um desastre natural que afeta a infraestrutura local. Outros cenários de falha incluem falha grave no sistema, um ataque de segurança cibernética ou até mesmo um erro de configuração do sistema.
Otimizar um sistema para resistir a falhas é essencial para estabelecer uma continuidade de negócios eficaz. A confiabilidade do sistema pode ser influenciada por vários fatores, incluindo, mas não se limitando a, desempenho, resiliência, disponibilidade, segurança e experiência do usuário. Para mais informações sobre como arquitetar e operar serviços confiáveis no Google Cloud, consulte o pilar de confiabilidade do Google Cloud Framework de arquitetura e os elementos básicos de confiabilidade em Google Cloud.
Esse padrão de arquitetura depende de uma implantação redundante de aplicativos em vários ambientes de computação. Nesse padrão, você implanta os mesmos aplicativos em vários ambientes de computação com o objetivo de aumentar a confiabilidade. A continuidade de negócios pode ser definida como a capacidade de uma organização de continuar as principais funções ou serviços de negócios em níveis aceitáveis predefinidos após um evento disruptivo.
A recuperação de desastres (DR) é considerada um subconjunto da continuidade de negócios, com foco explícito em garantir que os sistemas de TI que auxiliam as funções críticas da empresa estejam operacionais o mais rápido possível após uma interrupção. Em geral, as estratégias e os planos de DR geralmente ajudam a formar uma estratégia de continuidade de negócios mais ampla. Do ponto de vista tecnológico, quando você começa a criar estratégias de recuperação de desastres, a análise de impacto nos negócios precisa definir duas métricas principais: o objetivo de ponto de recuperação (RPO, na sigla em inglês) e o objetivo de tempo de recuperação (RTO, na sigla em inglês). Para mais orientações sobre como usar o Google Cloud para lidar com a recuperação de desastres, consulte o Guia de planejamento de recuperação de desastres.
Quanto menores forem os valores de RPO e RTO, mais rápido os serviços poderão se recuperar de uma interrupção com perda mínima de dados. No entanto, isso implica um custo maior, porque significa criar sistemas redundantes. Sistemas redundantes capazes de realizar a replicação de dados quase em tempo real e que operam na mesma escala após um evento de falha aumentam a complexidade, a sobrecarga administrativa e o custo.
A decisão de selecionar uma estratégia de DR ou padrão precisa ser orientada por uma análise de impacto nos negócios. Por exemplo, os perdas financeiras causadas por alguns minutos de inatividade de uma organização de serviços financeiros podem exceder em muito o custo da implementação de um sistema de DR. No entanto, empresas de outros setores podem suportar horas de inatividade sem um efeito significativo nos negócios.
Quando você executa sistemas essenciais em um data center local, uma abordagem de DR é manter os sistemas de reserva em um segundo data center em uma região diferente. Uma abordagem mais econômica, entretanto, é usar um ambiente de computação baseado em nuvem pública para fins de failover. Essa abordagem é o principal fator do padrão híbrido de continuidade de negócios. A nuvem pode ser especialmente atraente do ponto de vista de custo, porque permite desativar parte da infraestrutura de DR quando ela não está em uso. Para alcançar uma solução de DR de custo mais baixo, uma solução em nuvem permite que uma empresa aceite o possível aumento nos valores de RPO e RTO.
O diagrama anterior ilustra o uso da nuvem como um ambiente de failover ou de recuperação de desastres para um ambiente local.
Uma variante menos comum (e raramente necessária) desse padrão é o padrão de continuidade de negócios de várias nuvens. Nesse padrão, o ambiente de produção usa um provedor de nuvem e o ambiente de DR usa outro provedor de nuvem. Ao implantar cópias de cargas de trabalho em vários provedores de nuvem, é possível aumentar a disponibilidade além do que uma implantação de várias regiões oferece.
Avaliar um DR em várias nuvens em vez de usar um provedor de nuvem com regiões diferentes exige uma análise completa de várias considerações, incluindo as seguintes:
- Gerenciamento
- Segurança
- Viabilidade geral.
- Custo
- As possíveis cobranças de transferência de dados de saída de mais de um provedor de nuvem podem ser caras com a comunicação contínua entre nuvens.
- Pode haver um grande volume de tráfego ao replicar bancos de dados.
- TCO e o custo de gerenciamento da infraestrutura de rede entre nuvens.
Se os dados precisarem ficar no seu país para atender aos requisitos regulatórios, usar um segundo provedor de nuvem que também esteja no seu país como DR pode ser uma opção. O uso de um segundo provedor de nuvem pressupõe que não há opção de usar um ambiente local para criar uma configuração híbrida. Para evitar a reengenharia da solução de nuvem, o segundo provedor de nuvem idealmente precisa oferecer todos os recursos e serviços necessários na região.
Considerações sobre o design
- Expectativa de DR: os objetivos de RPO e RTO que sua empresa quer alcançar devem orientar sua arquitetura de DR e o planejamento de construção.
- Arquitetura da solução: com esse padrão, é necessário replicar as funções e os recursos atuais do ambiente local para atender às expectativas de DR. Portanto, é necessário avaliar a viabilidade e a viabilidade de rehosting, refatoração ou reengenharia de seus aplicativos para fornecer as mesmas funções e desempenho (ou mais otimizados) no ambiente de nuvem.
- Projeto e criação: criar uma zona de destino é quase sempre um pré-requisito para implantar cargas de trabalho empresariais em um ambiente de nuvem. Para mais informações, consulte Design da zona de destino em Google Cloud.
Invocação de DR: é importante que o design e o processo de DR considerem as seguintes perguntas:
- O que aciona um cenário de DR? Por exemplo, uma DR pode ser acionada pela falha de funções ou sistemas específicos no site principal.
- Como o failover para o ambiente de DR é invocado? É um processo de aprovação manual ou pode ser automatizado para atingir uma meta de RTO baixa?
- Como os mecanismos de detecção e notificação de falha do sistema devem ser projetados para invocar o failover em conformidade com o RTO esperado?
- Como o tráfego é redirecionado para o ambiente de DR depois que a falha é detectada?
Valide suas respostas a essas perguntas com testes.
Testes: teste e avalie completamente o failover para DR. Verifique se ele atende às suas expectativas de RPO e RTO. Isso pode dar mais confiança para invocar o DR quando necessário. Sempre que uma nova mudança ou atualização for feita no processo ou na solução de tecnologia, realize os testes novamente.
Habilidades da equipe: uma ou mais equipes técnicas precisam ter as habilidades e a experiência necessárias para criar, operar e resolver problemas da carga de trabalho de produção no ambiente de nuvem, a menos que o ambiente seja gerenciado por terceiros.
Vantagens
O uso de Google Cloud para a continuidade dos negócios oferece várias vantagens:
- Como o Google Cloud tem muitas regiões no mundo para você escolher, é possível usá-lo para fazer backup ou replicar dados para um site diferente no mesmo continente. Também é possível fazer backup ou replicar dados para um site em um continente diferente.
- OGoogle Cloud oferece a capacidade de armazenar dados no Cloud Storage
em um bucket
bi ou multirregional. Os dados são armazenados de maneira redundante em pelo menos duas regiões geográficas diferentes. Os dados armazenados em buckets birregionais e multirregionais são replicados
em regiões geográficas usando a replicação padrão.
- Os buckets birregionais oferecem redundância geográfica para oferecer suporte à continuidade dos negócios e aos planos de DR. Além disso, para replicar mais rápido, com um RPO menor, os objetos armazenados em regiões duplas podem usar opcionalmente a replicação turbo entre essas regiões.
- Da mesma forma, a replicação multirregional oferece redundância em várias regiões, armazenando seus dados dentro do limite geográfico da multirregião.
- Oferece uma ou mais das seguintes opções para reduzir as despesas de capital
e operacionais para criar uma DR:
- As instâncias de VM interrompidas geram apenas custos de armazenamento e são substancialmente mais baratas do que as instâncias de VM em execução. Isso significa que você pode minimizar o custo de manutenção de sistemas em espera frios.
- O modelo de pagamento por uso do Google Cloud significa que você paga apenas pela capacidade de armazenamento e computação que realmente usa.
- Os recursos de elasticidade, como o escalonamento automático, permitem que você aumente ou diminua o ambiente de DR automaticamente, conforme necessário.
Por exemplo, o diagrama a seguir mostra um aplicativo em execução em um ambiente local (produção) que usa componentes de recuperação noGoogle Cloud com o Compute Engine, o Cloud SQL e o Cloud Load Balancing. Nesse cenário, o banco de dados é provisionado previamente usando um banco de dados baseado em VM ou um banco de dados gerenciado por Google Cloud , como o Cloud SQL, para uma recuperação mais rápida com a replicação contínua de dados. É possível iniciar VMs do Compute Engine usando snapshots pré-criados para reduzir custos durante operações normais. Com essa configuração, e após um evento de falha, o DNS precisa apontar para o endereço IP externo do Cloud Load Balancing.
Para que o aplicativo funcione na nuvem, provisione as VMs da Web e do aplicativo. Dependendo do nível de RTO e das políticas da empresa, todo o processo de invocar uma DR, provisionar a carga de trabalho na nuvem e redirecionar o tráfego pode ser concluído manualmente ou automaticamente.
Para acelerar e automatizar o provisionamento da infraestrutura, considere gerenciar a infraestrutura como código. É possível usar o Cloud Build, que é um serviço de integração contínua, para aplicar automaticamente os manifestos do Terraform ao seu ambiente. Para mais informações, consulte Como gerenciar a infraestrutura como código com o Terraform, o Cloud Build e o GitOps.
Práticas recomendadas
Ao usar o padrão de continuidade de negócios, considere as seguintes práticas recomendadas:
- Crie um plano de recuperação de desastres que documente sua infraestrutura, juntamente com os procedimentos de failover e recuperação.
- Considere as seguintes ações com base na sua análise de impacto nos negócios e
nas metas de RPO e RTO identificadas:
- Decida se o backup de dados para Google Cloud é suficiente ou se você precisa considerar outra estratégia de DR (sistemas em espera frios, mornos ou quentes).
- Defina os serviços e produtos que podem ser usados como elementos básicos para seu plano de DR.
- Defina os cenários de DR aplicáveis para seus aplicativos e dados como parte da estratégia de DR selecionada.
- Considere usar o padrão de handover quando você estiver fazendo apenas o backup de dados. Caso contrário, o padrão meshed pode ser uma boa opção para replicar a arquitetura de rede do ambiente atual.
- Minimize dependências entre sistemas que estão sendo executados em ambientes distintos, especialmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem diminuir o desempenho e a disponibilidade geral.
Evite o problema de "dupla personalidade". Se você replicar dados bidirecionalmente entre ambientes, poderá ficar exposto ao problema do cérebro dividido. O problema do cérebro dividido ocorre quando dois ambientes que replicam dados bidirecionalmente perdem a comunicação um com o outro. Essa divisão pode fazer com que os sistemas nos dois ambientes concluam que o outro ambiente está indisponível e que eles têm acesso exclusivo aos dados. Isso pode levar a modificações conflitantes dos dados. Há duas maneiras comuns de evitar o problema de cérebro dividido:
- Use um terceiro ambiente de computação. Esse ambiente permite que os sistemas verifiquem se há quorum antes de modificar dados.
Permitir que as modificações de dados conflitantes sejam reconciliadas após a restauração da conectividade.
Com os bancos de dados SQL, é possível evitar o problema de "dupla personalidade" tornando a instância principal original inacessível antes que os clientes comecem a usar a nova instância principal. Para mais informações, consulte Recuperação de desastres do banco de dados do Cloud SQL.
Garanta que os sistemas de CI/CD e os repositórios de artefatos não se tornem um ponto único de falha. Quando um ambiente não está disponível, é preciso que você possa implantar novas versões ou aplicar alterações de configuração.
Torne todas as cargas de trabalho portáteis ao usar sistemas de espera. Todas as cargas de trabalho precisam ser portáveis (quando possível e com suporte dos aplicativos) para que os sistemas permaneçam consistentes em todos os ambientes. Você pode alcançar essa abordagem considerando contêineres e Kubernetes. Ao usar o Google Kubernetes Engine (GKE) Enterprise, você pode simplificar o build e as operações.
Integre a implantação de sistemas de reserva ao seu pipeline de CI/CD. Essa integração ajuda a garantir que as versões e configurações do aplicativo sejam consistentes entre os ambientes.
Para garantir que as mudanças 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 ocorre um desastre.
Selecione a política de DNS e a política de roteamento que estão alinhadas com sua arquitetura e o comportamento da solução. Além disso, é possível combinar vários balanceadores de carga regionais com políticas de roteamento de DNS para criar arquiteturas de balanceamento de carga global para diferentes casos de uso, incluindo a configuração híbrida.
Use vários provedores de DNS. Ao usar vários provedores de DNS, você pode:
- Melhore a disponibilidade e a resiliência dos seus aplicativos e serviços.
Simplifique a implantação ou migração de aplicativos híbridos que têm dependências entre ambientes locais e de nuvem com uma configuração de DNS de vários provedores.
OGoogle Cloud oferece uma solução de código aberto baseada no octoDNS para ajudar você a configurar e operar um ambiente com vários provedores de DNS. Para mais informações, consulte DNS público de vários provedores usando o Cloud DNS.
Use balanceadores de carga ao usar sistemas de espera para criar um failover automático. O hardware do balanceador de carga pode falhar.
Use o Cloud Load Balancing em vez de balanceadores de carga de hardware para gerar alguns cenários que ocorrem ao usar esse padrão de arquitetura. As solicitações de clientes internas ou externas podem ser redirecionadas para o ambiente principal ou de DR com base em diferentes métricas, como divisão de tráfego com base em peso. Para mais informações, consulte Visão geral do gerenciamento de tráfego para o balanceador de carga de aplicativo externo global.
Considere usar o Cloud Interconnect ou o Cross-Cloud Interconnect se o volume de transferência de dados de saída de Google Cloud para o outro ambiente for alto. 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.
Considere usar a solução de parceiro preferida no Google Cloud Marketplace para facilitar os backups de dados, as replicações e outras tarefas que atendem aos seus requisitos, incluindo as metas de RPO e RTO.
Teste e avalie os cenários de invocação de DR para entender a rapidez com que o aplicativo pode se recuperar de um evento de desastre em comparação com o valor RTO desejado.
Criptografar as comunicações em trânsito. Para proteger informações sensíveis, recomendamos criptografar todas as comunicações em trânsito. Se a criptografia for necessária na camada de conectividade, várias opções estarão disponíveis com base na solução de conectividade híbrida selecionada. Essas opções incluem túneis VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para Cloud Interconnect.
Padrão de bursting de nuvem
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 ambienteGoogle 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 esse 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 em 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 Google Cloud recursos durante períodos de baixa demanda, usar principalmente políticas de roteamento de DNS para balanceamento de carga de tráfego nem sempre é a melhor opção. 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 em 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 os ambientes, escolha uma regiãoGoogle Cloud que esteja 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 à segurança mantendo a privacidade de todos os recursos Google Cloud . Proíba o acesso direto da Internet a esses recursos, mesmo que você use o balanceamento de carga externo 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 Google Cloud com uma implantação local onde há uma região 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.
Padrões de arquitetura híbrida e multicloud: próximas etapas
- Saiba como abordar a arquitetura híbrida e multicloud e como escolher cargas de trabalho adequadas.
- Saiba mais sobre os padrões de arquitetura de rede adequados para os padrões de arquitetura híbrida e de multicloud selecionados.
- Saiba mais sobre Arquétipos de implantação para aplicativos em nuvem.
- Aprenda a projetar e implantar um aplicativo da Web de e-commerce com diferentes arquiteturas, incluindo um aplicativo da Web de e-commerce baseado em microsserviços usando o GKE e um aplicativo da Web dinâmico baseado em API sem servidor.
-
Para mais informações sobre considerações específicas de cada região, consulte Geografia e regiões. ↩