Implementação global com o Compute Engine e o Spanner

Last reviewed 2025-08-12 UTC

Este documento fornece uma arquitetura de referência para uma aplicação de vários níveis que é executada em VMs do Compute Engine e no Spanner numa topologia global no Google Cloud. O documento também fornece orientações para ajudar a criar uma arquitetura que use outros serviços de infraestrutura Google Cloud . Descreve os fatores de design que deve considerar quando cria uma arquitetura global para as suas aplicações na nuvem. O público-alvo pretendido para este documento são arquitetos de nuvem.

Esta arquitetura está alinhada com o arquétipo de implementação global. Recomendamos este arquétipo para aplicações que atendem utilizadores em todo o mundo e precisam de elevada disponibilidade e robustez contra indisponibilidades em várias regiões. Esta arquitetura suporta o escalonamento elástico ao nível da rede, da aplicação e da base de dados. Permite-lhe alinhar os custos com a utilização sem ter de comprometer o desempenho, a disponibilidade ou a escalabilidade.

Arquitetura

O diagrama seguinte mostra uma arquitetura para uma aplicação que é executada numa infraestrutura distribuída globalmente em várias Google Cloud regiões.

Arquitetura de implementação global com o Compute Engine e o Spanner.

Nesta arquitetura, um balanceador de carga global distribui os pedidos recebidos para servidores Web nas regiões adequadas com base na respetiva disponibilidade, capacidade e proximidade da origem do tráfego. Uma camada de balanceamento de carga interno entre regiões processa a distribuição do tráfego dos servidores Web para os servidores de aplicações adequados com base na respetiva disponibilidade e capacidade. Os servidores de aplicações escrevem dados e leem dados de uma base de dados replicada de forma síncrona que está disponível em todas as regiões.

A arquitetura inclui os seguintes Google Cloud recursos:

Componente Finalidade
Balanceador de carga externo global

O balanceador de carga externo global recebe e distribui pedidos de utilizadores para a aplicação. O balanceador de carga externo global anuncia um endereço IP de anycast único, mas o balanceador de carga é implementado como um grande número de proxies nos Google Front Ends (GFEs). Os pedidos do cliente são direcionados para o GFE mais próximo do cliente.

Consoante os seus requisitos, pode usar um Application Load Balancer externo global ou um Network Load Balancer de proxy externo global. Para mais informações, consulte o artigo Escolha um balanceador de carga.

Para proteger a sua aplicação contra ameaças como ataques de negação de serviço distribuída (DDoS) e scripting entre sites (XSS), pode usar as políticas de segurança do Google Cloud Armor.

Grupos de instâncias geridas (GIGs) regionais para a camada Web

A camada Web da aplicação é implementada em VMs do Compute Engine que fazem parte de GIGs regionais. Estes MIGs são os back-ends do balanceador de carga global.

Cada MIG contém VMs do Compute Engine em três zonas diferentes. Cada uma destas VMs aloja uma instância independente da camada Web da aplicação.

Camada de balanceamento de carga interno entre regiões

Os balanceadores de carga internos com back-ends inter-regionais processam a distribuição de tráfego dos VMs da camada Web em qualquer região para os VMs da camada de aplicação em todas as regiões.

Consoante os seus requisitos, pode usar um Application Load Balancer interno entre regiões ou um Network Load Balancer de proxy interno entre regiões. Para mais informações, consulte o artigo Escolha um balanceador de carga.

Grupos de instâncias geridos regionais para o nível da aplicação

A camada de aplicação é implementada em VMs do Compute Engine que fazem parte de GIGs regionais. Estes MIGs são os back-ends da camada de balanceamento de carga interno.

Cada MIG contém VMs do Compute Engine em três zonas diferentes. Cada MV aloja uma instância independente da camada de aplicação.

Instância multirregião do Spanner

A aplicação escreve dados e lê dados de uma instância do Spanner de várias regiões. A configuração multirregião nesta arquitetura inclui as seguintes réplicas:

  • Quatro réplicas de leitura/escrita em zonas separadas em duas regiões.
  • Uma réplica de testemunho numa terceira região.
Rede da nuvem virtual privada (VPC) e sub-redes

Todos os recursos na arquitetura usam uma única rede VPC. A rede de VPC tem as seguintes sub-redes:

  • Uma sub-rede em cada região para as VMs do servidor Web.
  • Uma sub-rede em cada região para as VMs do servidor de aplicações.
  • (Não apresentado no diagrama de arquitetura) Uma sub-rede apenas de proxy em cada região para o balanceador de carga interno entre regiões.

Em vez de usar uma única rede VPC, pode criar uma rede VPC separada em cada região e ligar as redes através do Network Connectivity Center.

Produtos usados

Esta arquitetura de referência usa os seguintes produtos Google Cloud :

  • Compute Engine: um serviço de computação seguro e personalizável que lhe permite criar e executar VMs na infraestrutura da Google.
  • Cloud Load Balancing: um portefólio de balanceadores de carga globais, escaláveis e de elevado desempenho, bem como balanceadores de carga regionais.
  • Spanner: um serviço de base de dados relacional altamente escalável e globalmente consistente.

Considerações de design

Esta secção fornece orientações para ajudar a usar esta arquitetura de referência para desenvolver uma arquitetura que cumpra os seus requisitos específicos de design do sistema, segurança e conformidade, fiabilidade, custo, eficiência operacional e desempenho.

Design do sistema

Esta secção fornece orientações para ajudar a escolher as Google Cloud regiões para a sua implementação global e a selecionar os Google Cloud serviços adequados.

Seleção de região

Quando escolher as Google Cloud regiões onde as suas aplicações têm de ser implementadas, considere os seguintes fatores e requisitos:

  • Disponibilidade de Google Cloud serviços em cada região. Para mais informações, consulte Produtos disponíveis por localização.
  • Disponibilidade dos tipos de máquinas do Compute Engine em cada região. Para mais informações, consulte o artigo Regiões e zonas.
  • Requisitos de latência do utilizador final.
  • Custo dos Google Cloud recursos.
  • Custos de transferência de dados entre regiões.
  • Requisitos regulamentares.

Alguns destes fatores e requisitos podem envolver compromissos. Por exemplo, a região mais rentável pode não ter a menor pegada de carbono. Para mais informações, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine.

Infraestrutura de computação

A arquitetura de referência neste documento usa VMs do Compute Engine para determinados níveis da aplicação. Consoante os requisitos da sua aplicação, pode escolher entre outros Google Cloud serviços de computação:

  • Contentores: pode executar aplicações em contentores em clusters do Google Kubernetes Engine (GKE). O GKE é um motor de orquestração de contentores que automatiza a implementação, o dimensionamento e a gestão de aplicações contentorizadas.
  • Sem servidor: se preferir concentrar os seus esforços de TI nos dados e nas aplicações em vez de configurar e operar recursos de infraestrutura, pode usar serviços sem servidor, como o Cloud Run.

A decisão de usar VMs, contentores ou serviços sem servidor envolve uma troca entre a flexibilidade da configuração e o esforço de gestão. As VMs e os contentores oferecem mais flexibilidade de configuração, mas é responsável pela gestão dos recursos. Numa arquitetura sem servidor, implementa cargas de trabalho numa plataforma pré-configurada que requer um esforço de gestão mínimo. Para mais informações sobre a escolha de serviços de computação adequados para as suas cargas de trabalho no Google Cloud, consulte Alojamento de aplicações no Google Cloud.

Serviços de armazenamento

A arquitetura apresentada neste documento usa volumes de discos persistentes regionais para as VMs. Os volumes de discos persistentes regionais oferecem replicação síncrona de dados em duas zonas numa região. Os dados nos volumes de discos persistentes não são replicados entre regiões.

O Hyperdisk do Google Cloud oferece melhor desempenho, flexibilidade e eficiência do que o disco persistente. Com o Hyperdisk Balanced, pode aprovisionar IOPS e débito separadamente e de forma dinâmica, o que lhe permite ajustar o volume a uma grande variedade de cargas de trabalho.

Para armazenamento de baixo custo replicado em várias localizações, pode usar contentores regionais, de duas regiões ou multirregionais do Cloud Storage.

  • Os dados em contentores regionais são replicados de forma síncrona nas zonas da região.
  • Os dados em contentores de duas regiões ou multirregiões são armazenados de forma redundante em, pelo menos, duas localizações geográficas separadas. Os metadados são escritos de forma síncrona em todas as regiões, e os dados são replicados de forma assíncrona. Para contentores de dupla região, pode usar a replicação turbo, que garante que os objetos são replicados em pares de regiões, com um objetivo de ponto de recuperação (RPO) de 15 minutos. Para mais informações, consulte o artigo Disponibilidade e durabilidade dos dados.

Para armazenar dados partilhados por várias VMs numa região, como todas as VMs na camada Web ou na camada de aplicação, pode usar uma instância regional do Filestore. Os dados que armazena numa instância regional do Filestore são replicados de forma síncrona em três zonas na região. Esta replicação garante a alta disponibilidade e a robustez contra falhas de zonas. Pode armazenar ficheiros de configuração partilhados, ferramentas e utilitários comuns, e registos centralizados na instância do Filestore e montar a instância em várias VMs. Para garantir a robustez contra interrupções regionais, pode replicar uma instância do Filestore para uma região diferente. Para mais informações, consulte o artigo Replicação de instâncias.

Se a sua base de dados for o Microsoft SQL Server, recomendamos que use o Cloud SQL para SQL Server. Em cenários em que o Cloud SQL não suporta os seus requisitos de configuração ou se precisar de acesso ao sistema operativo, pode implementar uma instância de cluster de failover (FCI) do Microsoft SQL Server. Neste cenário, pode usar os volumes do Google Cloud NetApp totalmente geridos para fornecer armazenamento SMB de disponibilidade contínua (CA) para a base de dados.

Quando cria armazenamento para as suas cargas de trabalho, tenha em conta as características funcionais, os requisitos de resiliência, as expetativas de desempenho e os objetivos de custo. Para mais informações, consulte o artigo Crie uma estratégia de armazenamento ideal para a sua carga de trabalho na nuvem.

Serviços de bases de dados

A arquitetura de referência neste documento usa o Spanner, uma base de dados totalmente gerida, horizontalmente escalável, distribuída globalmente e replicada de forma síncrona. Recomendamos uma configuração do Spanner multirregional para implementações críticas que requerem uma forte consistência entre regiões. O Spanner suporta a replicação síncrona entre regiões sem inatividade para comutação por falha, manutenção ou redimensionamento.

Para obter informações sobre outros serviços de bases de dados geridos que pode escolher com base nos seus requisitos, consulte Google Cloud bases de dados. Quando escolher e configurar a base de dados para uma implementação multirregional, tenha em atenção os requisitos da sua aplicação para a consistência de dados entre regiões e tenha em atenção as soluções de compromisso ao nível do desempenho e dos custos.

Design de rede

Escolha um design de rede que cumpra os seus requisitos empresariais e técnicos. Pode usar uma única rede VPC ou várias redes VPC. Para mais informações, consulte a seguinte documentação:

Opções de balanceamento de carga externo

Uma arquitetura que usa um equilibrador de carga externo global, como a arquitetura neste documento, suporta determinadas funcionalidades que ajudam a melhorar a fiabilidade das suas implementações. Por exemplo, se usar o balanceador de carga de aplicações externo global, pode implementar o armazenamento em cache na extremidade usando o Cloud CDN.

Se a sua aplicação exigir que a Transport Layer Security (TLS) seja terminada numa região específica ou se precisar da capacidade de publicar conteúdo a partir de regiões específicas, pode usar equilibradores de carga regionais com o Cloud DNS para encaminhar o tráfego para diferentes regiões. Para ver informações sobre as diferenças entre os balanceadores de carga regionais e globais, consulte a seguinte documentação:

Segurança, privacidade e conformidade

Esta secção descreve os fatores que deve considerar quando usa esta arquitetura de referência para conceber e criar uma topologia global que cumpra os requisitos de segurança, privacidade e conformidade das suas cargas de trabalho.Google Cloud

Proteção contra ameaças externas

Para proteger a sua aplicação contra ameaças como ataques de negação de serviço distribuída (DDoS) e scripting entre sites (XSS), pode usar as políticas de segurança do Google Cloud Armor. Cada política é um conjunto de regras que especifica determinadas condições que devem ser avaliadas e ações a tomar quando as condições são cumpridas. Por exemplo, uma regra pode especificar que, se o endereço IP de origem do tráfego de entrada corresponder a um endereço IP específico ou a um intervalo CIDR, o tráfego tem de ser recusado. Também pode aplicar regras de firewall de app Web (WAF) pré-configuradas. Para mais informações, consulte a Vista geral da política de segurança.

Acesso externo para VMs

Na arquitetura de referência descrita neste documento, as VMs do Compute Engine não precisam de acesso de entrada a partir da Internet. Não atribua endereços IP externos às VMs. Google Cloud Os recursos que têm apenas um endereço IP interno e privado podem continuar a aceder a determinadas APIs e serviços Google através do Private Service Connect ou do acesso privado à Google. Para mais informações, consulte Opções de acesso privado para serviços.

Para ativar ligações de saída seguras a partir de Google Cloud recursos que têm apenas endereços IP privados, como as VMs do Compute Engine nesta arquitetura de referência, pode usar o proxy Web seguro ou o Cloud NAT.

Privilégios da conta de serviço

Para as VMs do Compute Engine na arquitetura, em vez de usar as contas de serviço predefinidas, recomendamos que crie contas de serviço dedicadas e especifique os recursos aos quais a conta de serviço pode aceder. A conta de serviço predefinida tem uma vasta gama de autorizações, incluindo algumas que podem não ser necessárias. Pode personalizar contas de serviço dedicadas para terem apenas as autorizações essenciais. Para mais informações, consulte o artigo Limite os privilégios da conta de serviço.

Segurança SSH

Para melhorar a segurança das ligações SSH às VMs do Compute Engine na sua arquitetura, implemente o Identity-Aware Proxy (IAP) e a API Cloud OS Login. O IAP permite-lhe controlar o acesso à rede com base na identidade do utilizador e nas políticas de gestão de identidade e de acesso (IAM). A API Cloud OS Login permite-lhe controlar o acesso SSH do Linux com base na identidade do utilizador e nas políticas de IAM. Para mais informações sobre a gestão do acesso à rede, consulte as Práticas recomendadas para controlar o acesso ao início de sessão SSH.

Mais considerações de segurança

Quando criar a arquitetura para a sua carga de trabalho, considere as práticas recomendadas e as recomendações de segurança ao nível da plataforma fornecidas no projeto de base empresarial e na Google Cloud estrutura bem arquitetada: segurança, privacidade e conformidade.

Fiabilidade

Esta secção descreve os fatores de design que deve considerar quando usa esta arquitetura de referência para criar e operar uma infraestrutura fiável para uma implementação global no Google Cloud.

Escala automática do MIG

Quando executa a sua aplicação em vários GIGs regionais, a aplicação permanece disponível durante interrupções isoladas de zonas ou interrupções de regiões. A capacidade de criação de uma escala automática dos GIGs sem estado permite-lhe manter a disponibilidade e o desempenho da aplicação a níveis previsíveis.

Para controlar o comportamento de escalamento automático dos MIGs sem estado, pode especificar métricas de utilização alvo, como a utilização média da CPU. Também pode configurar o ajuste de escala automático baseado em programação para MIGs sem estado. Não é possível ajustar automaticamente a escala dos MIGs com estado. Para mais informações, consulte o artigo Grupos de escalamento automático de instâncias.

Limite de tamanho do MIG

Quando decidir o tamanho dos seus MIGs, considere os limites predefinidos e máximos no número de VMs que podem ser criadas num MIG. Para mais informações, consulte o artigo Adicione e remova VMs de um MIG.

Autorreparação de VMs

Por vezes, as VMs que alojam a sua aplicação podem estar em execução e disponíveis, mas podem existir problemas com a própria aplicação. A aplicação pode ficar bloqueada, falhar ou não ter memória suficiente. Para verificar se uma aplicação está a responder conforme esperado, pode configurar verificações de funcionamento baseadas em aplicações como parte da política de autocorreção dos seus MIGs. Se a aplicação numa determinada VM não estiver a responder, o GIG faz a autorrecuperação (repara) da VM. Para mais informações sobre a configuração da autocorreção, consulte Acerca da reparação de VMs para alta disponibilidade.

Posicionamento de VMs

Na arquitetura descrita neste documento, a camada de aplicação e a camada Web são executadas em VMs do Compute Engine distribuídas por várias zonas. Esta distribuição garante que a sua aplicação é robusta contra interrupções de zonas.

Para melhorar a robustez da arquitetura, pode criar uma política de posicionamento disperso e aplicá-la ao modelo MIG. Quando o MIG cria VMs, coloca-as em diferentes servidores físicos (denominados anfitriões) em cada zona, para que as VMs sejam robustas contra falhas de anfitriões individuais. Para mais informações, consulte o artigo Crie e aplique políticas de posicionamento disperso a VMs.

Planeamento de capacidade de VMs

Para garantir que a capacidade das VMs do Compute Engine está disponível quando as VMs precisam de ser aprovisionadas, pode criar reservas. Uma reserva oferece capacidade garantida numa zona específica para um número especificado de VMs de um tipo de máquina à sua escolha. Uma reserva pode ser específica de um projeto ou partilhada em vários projetos. Para mais informações sobre reservas, consulte o artigo Escolha um tipo de reserva.

Armazenamento com estado

Uma prática recomendada no design de aplicações é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, pode configurar os discos persistentes para serem com estado, de modo a garantir que os dados são preservados quando as VMs são reparadas ou recriadas. No entanto, recomendamos que mantenha os discos de arranque sem estado para que os possa atualizar para as imagens mais recentes com novas versões e patches de segurança. Para mais informações, consulte o artigo Configurar discos persistentes com estado em MIGs.

Durabilidade dos dados

Pode usar o Backup and DR para criar, armazenar e gerir cópias de segurança das VMs do Compute Engine. A cópia de segurança e a RD armazenam dados de cópia de segurança no formato original legível pela aplicação. Quando necessário, pode restaurar as suas cargas de trabalho para produção usando diretamente dados do armazenamento de cópias de segurança a longo prazo e evitar a necessidade de preparar ou mover dados.

O Compute Engine oferece as seguintes opções para ajudar a garantir a durabilidade dos dados armazenados em volumes de discos persistentes:

Fiabilidade da base de dados

Os dados armazenados numa instância do Spanner multirregional são replicados de forma síncrona em várias regiões. A configuração do Spanner apresentada no diagrama de arquitetura anterior inclui as seguintes réplicas:

  • Quatro réplicas de leitura/escrita em zonas separadas em duas regiões.
  • Uma réplica de testemunho numa terceira região.

Uma operação de escrita numa instância do Spanner de várias regiões é confirmada depois de, pelo menos, três réplicas (em zonas separadas em duas regiões) terem confirmado a operação. Se ocorrer uma falha de zona ou região, o Spanner tem acesso a todos os dados, incluindo os dados das operações de escrita mais recentes, e continua a processar pedidos de leitura e escrita.

O Spanner usa armazenamento desagregado onde os recursos de computação e armazenamento estão separados. Não tem de mover dados quando adiciona capacidade de computação para HA ou escalabilidade. Os novos recursos de computação recebem dados quando precisam do nó Colossus mais próximo. Isto torna a comutação por falha e o escalamento mais rápidos e menos arriscados.

O Spanner oferece consistência externa, que é uma propriedade mais rigorosa do que a serialização para sistemas de processamento de transações. Para mais informações, consulte o seguinte:

Mais considerações de fiabilidade

Quando criar a arquitetura de nuvem para a sua carga de trabalho, reveja as práticas recomendadas e as recomendações relacionadas com a fiabilidade que são fornecidas na seguinte documentação:

Otimização de custos

Esta secção fornece orientações para otimizar o custo de configuração e funcionamento de uma topologia global Google Cloud que cria através desta arquitetura de referência.

Tipos de máquinas de VMs

Para ajudar a otimizar a utilização de recursos das suas instâncias de VM, o Compute Engine oferece recomendações de tipo de máquina. Use as recomendações para escolher tipos de máquinas que correspondam aos requisitos de computação da sua carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, pode personalizar o tipo de máquina de acordo com as suas necessidades e poupar dinheiro usando tipos de máquinas personalizados.

Modelo de aprovisionamento de VMs

Se a sua aplicação for tolerante a falhas, as VMs do Spot podem ajudar a reduzir os custos do Compute Engine para as VMs nas camadas de aplicação e Web. O custo das VMs do Spot é significativamente inferior ao das VMs normais. No entanto, o Compute Engine pode parar ou eliminar preventivamente VMs do Spot para reaver capacidade.

As VMs do Spot são adequadas para tarefas de lotes que podem tolerar a preempção e não têm requisitos de alta disponibilidade. As VMs do Spot oferecem os mesmos tipos de máquinas, opções e desempenho que as VMs normais. No entanto, quando a capacidade de recursos numa zona é limitada, os GIGs podem não conseguir ser expandidos (ou seja, criar VMs) automaticamente para o tamanho alvo especificado até que a capacidade necessária fique novamente disponível.

Utilização de recursos da VM

A capacidade de escala automática dos GIGs sem estado permite que a sua aplicação lide facilmente com aumentos no tráfego e ajuda a reduzir os custos quando a necessidade de recursos é baixa. Não é possível ajustar automaticamente a escala dos MIGs com estado.

Custo da base de dados

O Spanner ajuda a garantir que os custos da base de dados são previsíveis. A capacidade de computação que especificar (número de nós ou unidades de processamento) determina a capacidade de armazenamento. As taxas de transferência de leitura e escrita são dimensionadas linearmente com a capacidade de computação. Paga apenas o que usa. Quando precisa de alinhar os custos com as necessidades da sua carga de trabalho, pode ajustar o tamanho da sua instância do Spanner.

Licenciamento de terceiros

Quando migra cargas de trabalho de terceiros para o Google Cloud, pode reduzir os custos usando as suas próprias licenças (BYOL). Por exemplo, para implementar VMs com o Microsoft Windows Server, em vez de usar uma imagem premium que incorre em custos adicionais para a licença de terceiros, pode criar e usar uma imagem BYOL do Windows personalizada. Depois, paga apenas pela infraestrutura de VM que usa no Google Cloud. Esta estratégia ajuda a continuar a obter valor dos seus investimentos existentes em licenças de terceiros. Se decidir usar a abordagem BYOL, as seguintes recomendações podem ajudar a reduzir o custo:

  • Aprovisione o número necessário de núcleos da CPU de computação independentemente da memória através de tipos de máquinas personalizados. Ao fazê-lo, limita o custo de licenciamento de terceiros ao número de núcleos do CPU de que precisa.
  • Reduza o número de vCPUs por núcleo de 2 para 1 desativando o multithreading simultâneo (SMT).

Se implementar uma base de dados de terceiros, como o Microsoft SQL Server, em VMs do Compute Engine, tem de considerar os custos de licença do software de terceiros. Quando usa um serviço de base de dados gerido, como o Cloud SQL, os custos da licença da base de dados estão incluídos nos encargos do serviço.

Mais considerações sobre o custo

Quando criar a arquitetura para a sua carga de trabalho, considere também as práticas recomendadas gerais e as recomendações fornecidas no Google Cloud Well-Architected Framework: otimização de custos.

Eficiência operacional

Esta secção descreve os fatores que deve ter em consideração quando usa esta arquitetura de referência para conceber e criar uma Google Cloud topologia global que possa operar de forma eficiente.

Atualizações da configuração de VMs

Para atualizar a configuração das VMs num GIG (como o tipo de máquina ou a imagem do disco de arranque), crie um novo modelo de instância com a configuração necessária e, em seguida, aplique o novo modelo ao GIG. O MIG atualiza as VMs através do método de atualização que escolher: automático ou seletivo. Escolha um método adequado com base nos seus requisitos de disponibilidade e eficiência operacional. Para mais informações sobre estes métodos de atualização do MIG, consulte o artigo Aplique novas configurações de VMs num MIG.

Imagens de VMs

Para as suas VMs, em vez de usar imagens públicas fornecidas pela Google, recomendamos que crie e use imagens de SO personalizadas que contenham as configurações e o software que as suas aplicações requerem. Pode agrupar as suas imagens personalizadas numa família de imagens personalizadas. Uma família de imagens aponta sempre para a imagem mais recente nessa família, para que os seus modelos de instâncias e scripts possam usar essa imagem sem ter de atualizar as referências a uma versão de imagem específica. Tem de atualizar regularmente as suas imagens personalizadas para incluir as atualizações e os patches de segurança fornecidos pelo fornecedor do SO.

Modelos de instância determinísticos

Se os modelos de instância que usa para os seus MIGs incluírem scripts de arranque para instalar software de terceiros, certifique-se de que os scripts especificam explicitamente parâmetros de instalação de software, como a versão do software. Caso contrário, quando o MIG cria as VMs, o software instalado nas VMs pode não ser consistente. Por exemplo, se o modelo de instância incluir um script de arranque para instalar o Apache HTTP Server 2.0 (o pacote apache2), certifique-se de que o script especifica a versão exata do apache2 que deve ser instalada, como a versão 2.4.53. Para mais informações, consulte o artigo Modelos de instâncias determinísticos.

Migração para o Spanner

Pode migrar os seus dados para o Spanner a partir de outras bases de dados, como o MySQL, o SQL Server e a Oracle Database. O processo de migração depende de fatores como a base de dados de origem, o tamanho dos seus dados, restrições de tempo de inatividade e a complexidade do código da aplicação. Para ajudar a planear e implementar a migração para o Spanner de forma eficiente, disponibilizamos uma variedade de Google Cloud e ferramentas de terceiros. Para mais informações, consulte o artigo Vista geral da migração.

Administração de bases de dados

Com o Spanner, não precisa de configurar nem monitorizar a replicação nem a comutação por falha. A replicação síncrona e a comutação por falha automática estão integradas. A sua aplicação não sofre interrupções durante a manutenção da base de dados e a comutação por falha. Para reduzir ainda mais a complexidade operacional, pode configurar o ajuste de escala automático. Com a escala automática ativada, não precisa de monitorizar e dimensionar o tamanho da instância manualmente.

Mais considerações operacionais

Quando cria a arquitetura para a sua carga de trabalho, considere as práticas recomendadas gerais e as recomendações para a eficiência operacional descritas no Google Cloud Well-Architected Framework: excelência operacional.

Otimização do desempenho

Esta secção descreve os fatores que deve ter em conta quando usa esta arquitetura de referência para conceber e criar uma topologia global que cumpra os requisitos de desempenho das suas cargas de trabalho.Google Cloud

Desempenho da rede

Para cargas de trabalho que precisam de baixa latência de rede entre VMs nas camadas da aplicação e Web, pode criar uma política de posicionamento compacta e aplicá-la ao modelo de MIG usado para essas camadas. Quando o MIG cria VMs, coloca-as em servidores físicos próximos uns dos outros. Embora uma política de posicionamento compacta ajude a melhorar o desempenho da rede entre VMs, uma política de posicionamento dispersa pode ajudar a melhorar a disponibilidade das VMs, conforme descrito anteriormente. Para alcançar um equilíbrio ideal entre o desempenho da rede e a disponibilidade, quando cria uma política de posicionamento compacta, pode especificar a distância entre as VMs. Para mais informações, consulte a vista geral das políticas de posicionamento.

O Compute Engine tem um limite por VM para a largura de banda da rede de saída. Este limite depende do tipo de máquina da VM e se o tráfego é encaminhado através da mesma rede VPC que a VM de origem. Para VMs com determinados tipos de máquinas, para melhorar o desempenho da rede, pode obter uma largura de banda de saída máxima mais elevada ativando a rede de nível 1.

Desempenho de computação

O Compute Engine oferece uma ampla gama de tipos de máquinas predefinidos e personalizáveis para as cargas de trabalho que executa em VMs. Escolha um tipo de máquina adequado com base nos seus requisitos de desempenho. Para mais informações, consulte o recurso de famílias de máquinas e o guia de comparação.

Vários threads da VM

Cada CPU virtual (vCPU) que atribui a uma VM do Compute Engine é implementada como um único multithread de hardware. Por predefinição, duas vCPUs partilham um núcleo da CPU físico. Para aplicações que envolvem operações altamente paralelas ou que realizam cálculos de vírgula flutuante (como a análise de sequências genéticas e a modelagem de risco financeiro), pode melhorar o desempenho reduzindo o número de threads que são executados em cada núcleo da CPU física. Para mais informações, consulte o artigo Defina o número de threads por núcleo.

A multithreading de VMs pode ter implicações de licenciamento para algum software de terceiros, como bases de dados. Para mais informações, leia a documentação de licenciamento do software de terceiros.

Níveis de serviço de rede

Os níveis de serviço de rede permitem otimizar o custo e o desempenho da rede das suas cargas de trabalho. Pode escolher o nível Premium ou o nível Standard. O nível Premium fornece tráfego na infraestrutura global da Google para alcançar uma perda de pacotes mínima e uma latência baixa. O nível padrão fornece tráfego através de intercâmbio de tráfego, fornecedores de serviços de Internet (ISP) ou redes de trânsito num ponto de presença (PoP) periférico mais próximo da região onde a sua Google Cloud carga de trabalho é executada. Para otimizar o desempenho, recomendamos que use o nível Premium. Para otimizar os custos, recomendamos que use o nível padrão.

A arquitetura neste documento usa um equilibrador de carga externo global com um endereço IP externo e back-ends em várias regiões. Esta arquitetura requer que use o nível Premium, que usa a infraestrutura global altamente fiável da Google para ajudar a alcançar uma perda de pacotes e uma latência mínimas.

Se usar equilibradores de carga externos regionais e encaminhar tráfego para regiões através do Cloud DNS, pode escolher o Nível Premium ou o Nível Standard, consoante os seus requisitos. O preço do nível padrão é inferior ao do nível premium. O nível padrão é adequado para tráfego que não seja sensível à perda de pacotes e que não tenha requisitos de latência baixa.

Desempenho do Spanner

Quando aprovisiona uma instância do Spanner, especifica a capacidade de computação da instância em termos do número de nós ou unidades de processamento. Monitorize a utilização de recursos da sua instância do Spanner e dimensione a capacidade com base na carga esperada e nos requisitos de desempenho da sua aplicação. Pode dimensionar a capacidade de uma instância do Spanner manual ou automaticamente. Para mais informações, consulte o artigo Vista geral do ajuste de escala automático.

Com uma configuração multirregional, o Spanner replica os dados de forma síncrona em várias regiões. Esta replicação permite operações de leitura de baixa latência a partir de várias localizações. A desvantagem é uma latência mais elevada para as operações de escrita, porque as réplicas de quorum estão distribuídas por várias regiões. Para minimizar a latência das transações de leitura/escrita numa configuração de várias regiões, o Spanner usa o encaminhamento com reconhecimento do líder (ativado por predefinição).

Para ver recomendações que otimizam o desempenho da sua instância e bases de dados do Spanner, consulte a seguinte documentação:

A colocar em cache

Se a sua aplicação publicar recursos de Websites estáticos e a sua arquitetura incluir um Application Load Balancer externo global, pode usar o Cloud CDN para colocar em cache conteúdo estático acedido regularmente mais perto dos seus utilizadores. A RFC pode ajudar a melhorar o desempenho para os seus utilizadores, reduzir a utilização de recursos de infraestrutura no back-end e reduzir os custos de entrega de rede. Para mais informações, consulte o artigo Desempenho Web mais rápido e proteção Web melhorada para o equilíbrio de carga.

Mais considerações sobre o desempenho

Quando criar a arquitetura da sua carga de trabalho, considere as práticas recomendadas gerais e as recomendações fornecidas no Google Cloud Well-Architected Framework: otimização do desempenho.

O que se segue?

Colaboradores

Autores:

Outros colaboradores: