Rede para entrega de aplicativos voltados à Internet: arquiteturas de referência
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Last reviewed 2023-11-13 UTC
Este documento faz parte de uma série que descreve arquiteturas de rede e segurança para empresas que estão migrando cargas de trabalho de data center para o Google Cloud.
O Google oferece um conjunto de produtos e recursos que facilitam a proteção
e o escalonamento dos aplicativos mais importantes para a Internet. A Figura 1 mostra uma arquitetura que usa os serviços do Google Cloud para implantar um aplicativo da Web com vários níveis.
Figura 1. Aplicativo da Web típico com várias camadas implantado no Google Cloud.
Arquitetura de migração lift-and-shift
À medida que aplicativos voltados à Internet migram para a nuvem, eles precisam ser capazes de escalonar e ter controles de segurança e visibilidade equivalentes aos usados no ambiente local. É possível fornecer esses controles usando dispositivos virtuais de rede disponíveis no mercado.
Figura 2. Aplicativo implantado com um balanceador de carga externo baseado em dispositivo.
Esses dispositivos virtuais oferecem funcionalidade e visibilidade consistentes com os ambientes locais. Ao usar um dispositivo virtual de rede, você implanta a imagem do dispositivo de software usando grupos de instâncias gerenciadas com escalonamento automático. Você é responsável por monitorar e gerenciar a integridade das instâncias de VM que executam o dispositivo, além de manter as atualizações de software dele.
Depois da mudança inicial, é recomendável fazer a transição
de dispositivos virtuais de rede autogerenciados para serviços gerenciados.
O Google Cloud oferece vários serviços gerenciados que facilitam
o fornecimento de aplicativos em escala.
A Figura 2 mostra um dispositivo virtual de rede configurado como front-end
de um aplicativo da Web. Para ver uma lista de soluções de ecossistema de parceiros, consulte a página do
Google Cloud Marketplace
no console do Google Cloud.
Arquitetura de serviços híbridos
O Google Cloud oferece as abordagens a seguir para facilitar o gerenciamento
de aplicativos voltados à Internet em escala:
Use a rede global do Google de servidores de nomes DNS Anycast que oferecem
alta disponibilidade e baixa latência para converter solicitações de nomes de domínios
em endereços IP.
Use a frota global de balanceadores de carga de aplicativos externos do Google para encaminhar o tráfego a um aplicativo hospedado no Google Cloud, no local ou em outra nuvem pública. Esses balanceadores de carga são escalonados automaticamente
com o tráfego e garantem que cada solicitação seja direcionada para um back-end
íntegro. Ao configurar grupos de endpoints de rede de conectividade híbrida, é possível trazer os benefícios dos recursos de balanceadores de carga de aplicativos externos para os serviços em execução na infraestrutura atual fora do Google Cloud. A rede local ou outras redes de nuvem pública
são conectadas de modo particular à rede do Google Cloud
por meio de um túnel VPN ou pelo Cloud Interconnect.
Use outros serviços de borda de rede, como o Cloud CDN, para distribuir
conteúdo, o Google Cloud Armor para proteger seu conteúdo e o
Identity-Aware Proxy (IAP) para controlar o acesso aos seus serviços.
A Figura 3 mostra a conectividade híbrida que usa o balanceador de carga de aplicativo externo.
Figura 3. Configuração de conectividade híbrida usando o balanceador de carga de aplicativo externo e
os serviços de borda de rede.
A Figura 4 mostra uma opção de conectividade diferente usando grupos
de endpoints de rede de conectividade híbrida.
Figura 4. Configuração do balanceador de carga de aplicativo externo usando
grupos de endpoints de rede de conectividade híbrida.
Use um balanceador de carga de aplicativo (HTTP/HTTPS) para encaminhar solicitações com base nos
atributos delas, como o identificador uniforme de recursos (URI) HTTP.
Use um balanceador de carga de rede de proxy para implementar o descarregamento de TLS, o proxy TCP ou o suporte para
balanceador de carga externo para back-ends em várias regiões.
Use um balanceador de carga de rede de passagem quando quiser preservar os endereços IP de origem do cliente, evitar a sobrecarga de proxies e oferecer suporte a protocolos adicionais, como UDP, ESP e ICMP.
Proteja seu serviço com o
Google Cloud Armor,
que é uma defesa de DDoS de borda e um produto de segurança WAF
disponível para todos os serviços acessados com um balanceador de carga de aplicativo externo global.
Use
certificados SSL gerenciados pelo Google.
É possível reutilizar certificados e chaves privadas que você já usa para outros produtos do Google Cloud. Isso elimina a necessidade de gerenciar certificados separados.
Ative o armazenamento em cache do aplicativo para aproveitar o espaço
distribuído do Cloud CDN.
Use dispositivos virtuais de rede para inspecionar e filtrar o norte-sul
(para e da Internet) e o leste-oeste (para e da rede local
ou redes VPC), como mostrado na figura 5.
Figura 5. Configuração de um dispositivo virtual de rede
altamente disponível usando um balanceador de carga de rede de passagem interna e um peering de rede VPC para
inspecionar o tráfego.
Use o Cloud IDS para detectar ameaças no tráfego norte-sul, como
mostrado na figura 6.
Figura 6. Configuração do Cloud IDS para espelhar e inspecionar todo o tráfego interno e da Internet.
Arquitetura distribuída de confiança zero
É possível expandir a arquitetura distribuída de confiança zero para incluir a entrega
de aplicativos da Internet. Nesse modelo, o balanceador de carga de aplicativo externo do Google fornece
balanceador de carga global entre clusters do GKE que têm
malha do Cloud Service Mesh em clusters distintos. Nesse cenário, você adota um
modelo de entrada composto. O balanceador de carga de primeiro nível faz a seleção
do cluster e, em seguida, um gateway do Ingress gerenciado pelo Cloud Service Mesh fornece o
balanceamento de carga e a segurança do Ingress específicos desse cluster. Um exemplo desse
Ingress de vários clusters é a
arquitetura de referência do Cymbal Bank,
conforme descrito no blueprint do aplicativo corporativo. Para mais informações sobre
a entrada de borda do Cloud Service Mesh, consulte
De borda para malha: como expor aplicativos da malha de serviço usando o Ingress do GKE.
A Figura 7 mostra uma configuração em que um balanceador de carga de aplicativo externo direciona
o tráfego da
Internet para a malha de serviço
usando um
gateway de entrada.
O gateway é um proxy dedicado na malha de serviço.
Figura 7. Entrega de aplicativos em um ambiente de microsserviços com confiança zero.
A migração para o Google Cloud pode ajudar você a planejar, projetar e implementar o processo de migração das suas cargas de trabalho para o Google Cloud.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2023-11-13 UTC."],[[["\u003cp\u003eThis document focuses on networking architectures for delivering internet-facing applications in Google Cloud, covering migration from on-premises environments.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Cloud offers managed services like external Application Load Balancers, Cloud CDN, and Cloud Armor to scale and secure internet-facing applications, replacing self-managed network virtual appliances.\u003c/p\u003e\n"],["\u003cp\u003eHybrid services architectures can be implemented, allowing the use of Google's global network for DNS and load balancing while connecting to services hosted on-premises or in other clouds.\u003c/p\u003e\n"],["\u003cp\u003eThe document covers various approaches to load balancing, including HTTP/HTTPS Application Load Balancers, proxy Network Load Balancers, and passthrough Network Load Balancers, each with specific use cases.\u003c/p\u003e\n"],["\u003cp\u003eZero Trust Distributed Architecture is discussed, detailing how external Application Load Balancers can integrate with Cloud Service Mesh for secure, multi-cluster application delivery.\u003c/p\u003e\n"]]],[],null,["# Networking for internet-facing application delivery: Reference architectures\n\nThis document is part of a series that describes networking and security\narchitectures for enterprises that are migrating data center workloads to\nGoogle Cloud.\n\nThe series consists of the following documents:\n\n- [Designing networks for migrating enterprise workloads: Architectural approaches](/architecture/network-architecture)\n- [Networking for secure intra-cloud access: Reference architectures](/architecture/network-secure-intra-cloud-access)\n- Networking for internet-facing application delivery: Reference architectures (this document)\n- [Networking for hybrid and multi-cloud workloads: Reference architectures](/architecture/network-hybrid-multicloud)\n\nGoogle offers a set of products and capabilities that help secure\nand scale your most critical internet-facing applications. Figure 1 shows an\narchitecture that uses Google Cloud services to deploy a web application\nwith multiple tiers.\n\n**Figure 1**. Typical multi-tier web application deployed on Google Cloud.\n| **Note:** You need to consider limitations of using Application Load Balancers. For more information, see the [Limitations](/load-balancing/docs/https#limitations) section in the \"External Application Load Balancer overview\" documentation.\n\nLift-and-shift architecture\n---------------------------\n\nAs internet-facing applications move to the cloud, they must be able to scale,\nand they must have security controls and visibility that are equivalent to those\ncontrols in the on-premises environment. You can provide these controls by using\nnetwork virtual appliances that are available in the marketplace.\n\n**Figure 2**. Application deployed with an appliance-based external load\nbalancer.\n\nThese virtual appliances provide functionality and visibility that is\nconsistent with your on-premises environments. When you use a network virtual\nappliance, you deploy the software appliance image by using autoscaled managed\ninstance groups. It's up to you to monitor and manage the health of the VM\ninstances that run the appliance, and you also maintain software updates for the\nappliance.\n\nAfter you perform your initial shift, you might want to\ntransition from self-managed network virtual appliances to managed services.\nGoogle Cloud offers a number of managed services to\ndeliver applications at scale.\n\nFigure 2 shows a network virtual appliance configured as the frontend\nof a web tier application. For a list of partner ecosystem solutions, see the\n[Google Cloud Marketplace](https://console.cloud.google.com/marketplace/browse?filter=category:networking)\npage in the Google Cloud console.\n\nHybrid services architecture\n----------------------------\n\nGoogle Cloud offers the following approaches to manage\ninternet-facing applications at scale:\n\n- Use Google's global network of anycast DNS name servers that provide high availability and low latency to translate requests for domain names into IP addresses.\n- Use Google's global fleet of external Application Load Balancers to route traffic to an application that's hosted inside Google Cloud, hosted on-premises, or hosted on another public cloud. These load balancers scale automatically with your traffic and ensure that each request is directed to a healthy backend. By setting up [hybrid connectivity network endpoint groups](/load-balancing/docs/negs/hybrid-neg-concepts), you can bring the benefits of external Application Load Balancer networking capabilities to services that are running on your existing infrastructure outside of Google Cloud. The on-premises network or the other public cloud networks are privately connected to your Google Cloud network through a VPN tunnel or through Cloud Interconnect.\n- Use other network edge services such as Cloud CDN to distribute\n content, Google Cloud Armor to protect your content, and\n Identity-Aware Proxy (IAP) to control access to your services.\n\n Figure 3 shows hybrid connectivity that uses external Application Load Balancer.\n\n **Figure 3**. Hybrid connectivity configuration using external Application Load Balancer and\n network edge services.\n\n Figure 4 shows a different connectivity option---using hybrid\n connectivity network endpoint groups.\n\n **Figure 4**. External Application Load Balancer configuration using hybrid\n connectivity network endpoint groups.\n- Use a Application Load Balancer (HTTP/HTTPS) to route requests based on\n their attributes, such as the HTTP uniform resource identifier (URI).\n Use a proxy Network Load Balancer to implement TLS offload, TCP proxy, or support for\n external load balancing to backends in multiple [regions](/docs/geography-and-regions#regions_and_zones).\n Use a passthrough Network Load Balancer to preserve client source IP addresses, avoid the\n overhead of proxies, and to support additional protocols like UDP, ESP, and\n ICMP.\n\n- Protect your service with\n [Cloud Armor](/armor).\n This product is an edge DDoS defense and WAF security product that's\n available to all services that are accessed through load balancers.\n\n- Use\n [Google-managed SSL certificates](/load-balancing/docs/ssl-certificates/google-managed-certs).\n You can reuse certificates and private keys that you already use for other\n Google Cloud products. This eliminates the need to manage separate\n certificates.\n\n- Enable caching on your application to take advantage of the distributed\n application delivery footprint of Cloud CDN.\n\n- Use [Cloud Next Generation Firewall](/vpc/docs/firewalls) to inspect and filter traffic in your VPC networks.\n\n- Use Cloud IDS to detect threats in north-south traffic, as\n shown in figure 6.\n\n **Figure 6**. Cloud IDS configuration to mirror and inspect\n all internet and internal traffic.\n\nZero Trust Distributed Architecture\n-----------------------------------\n\nYou can expand Zero Trust Distributed Architecture to include application\ndelivery from the internet. In this model, the Google external Application Load Balancer provides\nglobal load balancing across GKE clusters that have\nCloud Service Mesh meshes in distinct clusters. For this scenario, you adopt a\ncomposite ingress model. The first-tier load balancer provides cluster\nselection, and then a Cloud Service Mesh-managed ingress gateway provides\ncluster-specific load balancing and ingress security. An example of this\nmulti-cluster ingress is the\n[Cymbal Bank reference architecture](/architecture/blueprints/enterprise-application-blueprint/cymbal-bank)\nas described in the enterprise application blueprint. For more information about\nCloud Service Mesh edge ingress, see\n[From edge to mesh: Exposing service mesh applications through GKE Ingress](/architecture/exposing-service-mesh-apps-through-gke-ingress).\n\nFigure 7 shows a configuration in which a external Application Load Balancer directs\ntraffic from\nthe [internet to the service mesh](/architecture/exposing-service-mesh-apps-through-gke-ingress)\nthrough an\n[ingress gateway](/architecture/exposing-service-mesh-apps-through-gke-ingress).\nThe gateway is a dedicated proxy in the service mesh.\n\n**Figure 7**. Application delivery in a zero-trust microservices environment.\n\nWhat's next\n-----------\n\n- [Networking for secure intra-cloud access: Reference architectures](/architecture/network-secure-intra-cloud-access).\n- [Networking for hybrid and multi-cloud workloads: Reference architectures](/architecture/network-hybrid-multicloud).\n- [Use Cloud Armor, load balancing, and Cloud CDN to deploy programmable global front ends](/architecture/deploy-programmable-gfe-cloud-armor-lb-cdn)\n- [Migration to Google Cloud](/solutions/migration-to-gcp-getting-started) can help you to plan, design, and implement the process of migrating your workloads to Google Cloud.\n- [Landing zone design in Google Cloud](/architecture/landing-zones) has guidance for creating a landing zone network.\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture)."]]
