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

Last reviewed 2024-05-12 UTC

Neste documento, apresentamos uma arquitetura de referência para um aplicativo multinível executado nas VMs do Compute Engine e no Spanner em uma topologia global no Google Cloud. O documento também fornece orientações para ajudar você a criar uma arquitetura que usa outros serviços de infraestrutura do Google Cloud. Aqui, descrevemos os fatores de design que você precisa considerar ao criar uma arquitetura global para seus aplicativos de nuvem. Os arquitetos de nuvem são o público-alvo deste documento.

Essa arquitetura está alinhada ao arquétipo de implantação global. Recomendamos esse arquétipo para aplicativos que atendem a usuários em todo o mundo e precisam de alta disponibilidade e robustez contra interrupções dos serviços em várias regiões. Essa arquitetura permite escalonamento elástico nos níveis da rede, do aplicativo e do banco de dados. Ela permite alinhar os custos com o uso sem comprometer o desempenho, a disponibilidade ou a escalonabilidade.

Arquitetura

No diagrama a seguir, mostramos a arquitetura de um aplicativo executado em uma infraestrutura distribuída globalmente em várias regiões do Google Cloud.

Arquitetura de implantação global usando o Compute Engine e o Spanner.

Nesta arquitetura, um balanceador de carga global distribui solicitações de entrada para servidores da Web em regiões apropriadas com base na disponibilidade, capacidade e proximidade da origem do tráfego. Uma camada de balanceamento de carga interno entre regiões lida com a distribuição do tráfego dos servidores da Web para os servidores de aplicativos apropriados com base na disponibilidade e capacidade deles. Os servidores de aplicativos gravam e leem dados em um banco de dados replicado de maneira síncrona, disponível em todas as regiões.

A arquitetura contém os seguintes recursos do Google Cloud:

Componente Finalidade
Balanceador de carga externo global

O balanceador de carga externo global recebe e distribui solicitações de usuários para o aplicativo. O balanceador de carga externo global divulga um único endereço IP anycast, mas ele é implementado como um grande número de proxies em Google Front Ends (GFEs). As solicitações são direcionadas para o GFE mais próximo do cliente.

Dependendo dos seus requisitos, é possível usar um balanceador de carga de aplicativo externo global ou um balanceador de carga de rede de proxy externo global. Para mais informações, consulte Escolher um balanceador de carga.

Para proteger o aplicativo contra ameaças como ataques distribuídos de negação de serviço (DDoS) e scripting em vários sites (XSS), use as políticas de segurança do Google Cloud Armor.
Grupos gerenciados de instâncias (MIGs) regionais para o nível da Web

O nível da Web do aplicativo é implantado nas VMs do Compute Engine que fazem parte de MIGs regionais. Esses 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 dessas VMs hospeda uma instância independente do nível da Web do aplicativo.

Camada de balanceamento de carga interno entre regiões

Os balanceadores de carga internos com back-ends entre regiões lidam com a distribuição do tráfego das VMs de nível da Web em qualquer região para as VMs de nível do aplicativo em todas as regiões.

Dependendo dos seus requisitos, é possível usar um balanceador de carga de aplicativo interno entre regiões ou um balanceador de carga de rede de proxy interno entre regiões. Para mais informações, consulte Escolher um balanceador de carga.

MIGs regionais para o nível do aplicativo

O nível do aplicativo é implantado nas VMs do Compute Engine que fazem parte de MIGs regionais. Esses 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 VM hospeda uma instância independente do nível do aplicativo.

Instância multirregional do Spanner

O aplicativo grava dados e lê em uma instância multirregional do Spanner. A configuração multirregional nesta arquitetura inclui as seguintes réplicas:

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

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

  • Uma sub-rede em cada região para as VMs do servidor da Web.
  • Uma sub-rede em cada região para as VMs do servidor de aplicativos.
  • (Não mostrada no diagrama da arquitetura) Uma sub-rede somente proxy em cada região do balanceador de carga interno entre regiões.

Em vez de usar uma única rede VPC, é possível criar uma rede VPC separada em cada região e conectar as redes usando o Network Connectivity Center.

Produtos usados

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

  • Compute Engine: um serviço de computação seguro e personalizável que permite criar e executar VMs na infraestrutura do Google.
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • Spanner: um serviço de banco de dados relacional altamente escalonável e globalmente consistente.

Considerações sobre o design

Nesta seção, você encontra orientações sobre como usar essa arquitetura de referência para desenvolver uma arquitetura que atenda aos seus requisitos específicos de design, segurança e conformidade, confiabilidade, eficiência operacional, custo e desempenho do sistema.

.

Design do sistema

Nesta seção, fornecemos orientações para ajudar você a escolher regiões do Google Cloud para sua implantação global e selecionar os serviços apropriados do Google Cloud.

Seleção da região

Ao escolher as regiões do Google Cloud em que seus aplicativos precisam ser implantados, considere os seguintes fatores e requisitos:

  • Disponibilidade dos serviços do Google Cloud em cada região. Para mais informações, consulte Produtos disponíveis por local.
  • Disponibilidade de tipos de máquina do Compute Engine em cada região. Para mais informações, consulte Regiões e zonas.
  • Requisitos de latência do usuário final.
  • Custo dos recursos do Google Cloud.
  • Custos da transferência de dados entre regiões.
  • Requisitos regulatórios.

Alguns desses fatores e requisitos podem envolver compensações. Por exemplo, a região mais econômica pode não ter a menor pegada de carbono.

Serviços do Compute

A arquitetura de referência neste documento usa VMs do Compute Engine para os níveis da Web e do aplicativo. Dependendo dos requisitos do aplicativo, é possível escolher outros serviços de computação do Google Cloud:

  • É possível executar aplicativos conteinerizados nos clusters do Google Kubernetes Engine (GKE). O GKE é um mecanismo de orquestração de contêineres que automatiza a implantação, o escalonamento e o gerenciamento de aplicativos em contêineres.
  • Se você preferir concentrar as iniciativas de TI nos dados e aplicativos em vez de configurar e operar recursos de infraestrutura, use serviços sem servidor, como o Cloud Run e o Cloud Functions.

A decisão de usar VMs, contêineres ou serviços sem servidor envolve uma troca entre flexibilidade de configuração e esforço de gerenciamento. As VMs e os contêineres oferecem mais flexibilidade de configuração, mas você é responsável por gerenciar os recursos. Em uma arquitetura sem servidor, as cargas de trabalho são implantadas em uma plataforma pré-configurada que requer esforço mínimo de gerenciamento. Para mais informações sobre como escolher serviços de computação adequados para suas cargas de trabalho no Google Cloud, consulte Hospedagem de aplicativos no Google Cloud no Framework de arquitetura do Google Cloud.

Serviços de armazenamento

A arquitetura mostrada neste documento usa volumes regionais do Persistent Disk para as VMs. Os volumes do Persistent Disk regionais oferecem replicação síncrona de dados em duas zonas de uma região. Os dados nos volumes do Persistent Disk não são replicados entre regiões.

Outras opções de armazenamento para implantações multirregionais incluem buckets birregionais ou multirregionais do Cloud Storage. Os objetos armazenados em um bucket birregional ou multirregional são armazenados de maneira redundante em pelo menos dois locais geográficos diferentes. Os metadados são gravados de modo síncrono entre regiões e replicados de maneira assíncrona. Em buckets birregionais, use a replicação turbo, que garante uma replicação mais rápida entre regiões. Para mais informações, consulte Disponibilidade e durabilidade dos dados.

Para armazenar arquivos compartilhados entre várias VMs em uma região, como em todas as VMs no nível da Web ou do aplicativo, use uma instância do Filestore Enterprise. Os arquivos que você armazena em uma instância do Filestore Enterprise são replicados de maneira síncrona em três zonas na região. Essa replicação garante alta disponibilidade e robustez contra interrupções dos serviços da zona. É possível armazenar arquivos de configuração compartilhados, ferramentas e utilitários comuns e registros centralizados na instância do Filestore e ativá-la em várias VMs.

Ao projetar o armazenamento para suas cargas de trabalho multirregionais, considere as características funcionais das cargas de trabalho, requisitos de resiliência, expectativas de desempenho e metas de custo. Para mais informações, consulte Criar uma estratégia de armazenamento ideal para sua carga de trabalho na nuvem.

Serviços de banco de dados

A arquitetura de referência neste documento usa o Spanner, um banco de dados totalmente gerenciado, escalonável horizontalmente, distribuído globalmente e replicado de maneira síncrona. Recomendamos uma configuração multirregional do Spanner para implantações essenciais que exigem consistência forte entre regiões. O Spanner é compatível com replicação síncrona entre regiões sem inatividade para failover, manutenção ou redimensionamento.

Para informações sobre outros serviços de banco de dados gerenciado que podem ser escolhidos com base nos seus requisitos, consulte Bancos de dados do Google Cloud. Ao escolher e configurar o banco de dados para uma implantação multirregional, considere os requisitos do aplicativo quanto à consistência de dados entre regiões e esteja ciente das vantagens e desvantagens em termos de desempenho e custo.

Opções de balanceamento de carga externo

Uma arquitetura que usa um balanceador de carga externo global, como a arquitetura neste documento, permite determinados recursos que ajudam a melhorar a confiabilidade das suas implantações. Por exemplo, se você usar o balanceador de carga de aplicativo externo global, será possível implementar o armazenamento em cache de borda usando o Cloud CDN.

Se o aplicativo exigir que o Transport Layer Security (TLS) seja encerrado em uma região específica ou se você precisar disponibilizar conteúdo de regiões específicas, use balanceadores de carga regionais com o Cloud DNS para rotear o tráfego para regiões diferentes. Para informações sobre as diferenças entre balanceadores de carga regionais e globais, consulte a seguinte documentação:

Segurança e compliance

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia global no Google Cloud que atenda aos requisitos de segurança e conformidade das suas cargas de trabalho.

Proteção contra ameaças

Para proteger seu aplicativo contra ameaças como ataques DDoS e XSS, use as políticas de segurança do Google Cloud Armor. Cada política é um conjunto de regras que especifica determinadas condições que precisam ser avaliadas e ações a serem tomadas quando as condições são atendidas. 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 ou intervalo CIDR específico, o tráfego precisará ser negado. Também é possível aplicar regras pré-configuradas de firewall de aplicativos da Web (WAF, na sigla em inglês). Para mais informações, consulte Visão geral da política de segurança.

Acesso externo para VMs

Na arquitetura de referência descrita neste documento, as VMs que hospedam os níveis do aplicativo e da Web não precisam de acesso de entrada da Internet. Não atribua endereços IP externos a essas VMs. Os recursos do Google Cloud que têm apenas um endereço IP interno particular ainda podem acessar determinadas APIs e serviços do Google usando o Private Service Connect ou o Acesso privado do Google. Para mais informações, consulte Opções de acesso privado para serviços.

Para ativar conexões de saída seguras de recursos do Google Cloud que têm apenas endereços IP privados, como as VMs do Compute Engine nessa arquitetura de referência, use o Secure Web Proxy ou o Cloud NAT.

Segurança de imagens de VM

Para garantir que suas VMs usem apenas imagens aprovadas (ou seja, imagens com software que atenda aos requisitos de política ou segurança), defina uma política da organização que restrinja o uso de imagens em projetos de imagens públicas específicos. Para mais informações, consulte Como configurar políticas de imagem confiáveis.

Privilégios da conta de serviço

Nos projetos do Google Cloud em que a API Compute Engine está ativada, uma conta de serviço padrão é criada automaticamente. Para organizações do Google Cloud criadas antes de 3 de maio de 2024, essa conta de serviço padrão recebe o papel de Editor do IAM (roles/editor), a menos que esse comportamento esteja desativado.

Por padrão, a conta de serviço padrão é anexada a todas as VMs criadas usando a CLI do Google Cloud ou o console do Google Cloud. O papel Editor inclui uma ampla variedade de permissões. Portanto, anexar a conta de serviço padrão às VMs cria um risco de segurança. Para evitar esse risco, é possível criar e usar contas de serviço dedicadas para cada aplicativo. Para especificar os recursos que a conta de serviço pode acessar, use políticas detalhadas. Para mais informações, consulte Limitar os privilégios da conta de serviço em "Práticas recomendadas para usar contas de serviço".

Mais considerações sobre a segurança

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas de segurança no nível da plataforma e as recomendações fornecidas no Blueprint de bases empresariais.

Confiabilidade

Nesta seção, descrevemos os fatores de design que você precisa considerar ao usar essa arquitetura de referência para criar e operar uma infraestrutura confiável para uma implantação global no Google Cloud.

Escalonamento automático de MIG

Quando você executa seu aplicativo em vários MIGs regionais, ele permanece disponível durante interrupções isoladas dos serviços da zona ou da região. O recurso de escalonamento automático de MIGs sem estado permite manter a disponibilidade e o desempenho do aplicativo em níveis previsíveis. Para controlar o comportamento de escalonamento automático dos seus MIGs sem estado, é possível especificar métricas de utilização de destino, como a utilização média da CPU. Também é possível configurar o escalonamento automático baseado em programação para MIGs sem estado. MIGs com estado não podem ser escalonados automaticamente. Para mais informações, consulte Escalonamento automático de grupos de instâncias.

Recuperação automática de VM

Às vezes, as VMs que hospedam o aplicativo podem estar em execução e disponíveis, mas pode haver problemas com o próprio aplicativo. Os seguintes problemas podem ocorrer: congelamento, falha ou memória insuficiente. Para verificar se um aplicativo está respondendo conforme o esperado, configure verificações de integridade baseadas em aplicativo como parte da política de recuperação automática dos seus MIGs. Se o aplicativo em uma VM específica não estiver respondendo, o MIG vai recuperar (reparar) automaticamente a VM. Para mais informações sobre como configurar a recuperação automática, consulte Configurar uma verificação de integridade e recuperação automática de aplicativo.

Posicionamento da VM

Na arquitetura descrita neste documento, a camada do aplicativo e da Web são executadas nas VMs do Compute Engine distribuídas por várias zonas. Essa distribuição garante que o aplicativo seja robusto contra interrupções de zona. Para melhorar ainda mais essa robustez, crie uma política de posicionamento distribuído e aplique-a ao modelo do MIG. Quando o MIG cria VMs, ele as coloca dentro de cada zona em diferentes servidores físicos (chamados de hosts), de modo que suas VMs sejam resistentes contra falhas de hosts individuais. Para mais informações, consulte Aplicar políticas de posicionamento distribuído às VMs.

Planejamento de capacidade de VM

Para garantir que a capacidade de VMs do Compute Engine esteja disponível quando necessário para o escalonamento automático de MIGs, crie reservas. Uma reserva oferece capacidade garantida em uma zona específica para um número específico de VMs de um tipo de máquina escolhido por você. Uma reserva pode ser específica para um projeto ou compartilhada entre vários projetos. Para mais informações sobre reservas, incluindo considerações sobre faturamento, consulte Reservas de recursos zonais do Compute Engine.

Estado do Persistent Disk

Uma prática recomendada ao projetar aplicativos é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, é possível configurar os discos permanentes com estado para garantir que os dados sejam preservados quando as VMs forem reparadas ou recriadas. No entanto, recomendamos que você mantenha os discos de inicialização sem estado para atualizá-los facilmente para as imagens mais recentes com novas versões e patches de segurança. Para mais informações, consulte Como configurar discos permanentes com estado em MIGs.

Durabilidade dos dados

É possível usar o Serviço de Backup e DR para criar, armazenar e gerenciar backups das VMs do Compute Engine. O backup e a DR armazenam os dados de backup no formato original legível pelo aplicativo. Quando necessário, é possível restaurar as cargas de trabalho para produção usando diretamente os dados do armazenamento de backup de longo prazo sem atividades demoradas de movimentação ou preparação de dados.

O Compute Engine oferece as opções a seguir para ajudar a garantir a durabilidade dos dados armazenados nos volumes do Persistent Disk:

  • Os snapshots padrão permitem capturar o estado pontual dos volumes do Persistent Disk. Os snapshots são armazenados de maneira redundante em várias regiões, com somas de verificação automáticas para garantir a integridade dos dados. Por padrão, os snapshots são incrementais e usam menos espaço de armazenamento, e você economiza dinheiro. Os snapshots são armazenados em um local do Cloud Storage configurável. Para mais recomendações sobre como usar e gerenciar snapshots, consulte Práticas recomendadas para snapshots de disco do Compute Engine.
  • Os volumes regionais do Persistent Disk permitem executar aplicativos altamente disponíveis que não são afetados por falhas em discos permanentes. Quando você cria um volume regional do Persistent Disk, o Compute Engine mantém uma réplica do disco em uma zona diferente na mesma região. Os dados são replicados de maneira síncrona para os discos nas duas zonas. Se alguma das duas zonas tiver uma interrupção, os dados permanecerão disponíveis.

Use o recurso de backup e restauração no Spanner para ajudar a se proteger contra corrupção de dados causada por erros de operador e problemas no aplicativo. Para mais informações, consulte a Visão geral de backup e restauração do Spanner.

Confiabilidade do banco de dados

Os dados armazenados em uma instância multirregional do Spanner são replicados de maneira síncrona em várias regiões. A configuração do Spanner mostrada no diagrama de arquitetura anterior inclui as seguintes replicas:

  • Quatro réplicas de leitura/gravação em zonas separadas em duas regiões.
  • Uma réplica testemunha em uma terceira região.

Uma operação de gravação em uma instância multirregional do Spanner é confirmada depois que pelo menos três réplicas (em zonas diferentes entre duas regiões) fizeram commit da operação. Se ocorrer uma falha em uma zona ou região, o Spanner terá acesso a todos os dados, incluindo aqueles das operações de gravação mais recentes, e continuará atendendo às solicitações de leitura e gravação.

O Spanner usa o armazenamento desagregado, em que os recursos de computação e armazenamento são separados. Não é necessário mover os dados quando você adiciona capacidade de computação para alta disponibilidade ou escalonamento. Os novos recursos de computação recebem os dados do nó mais próximo do Colossus quando precisam deles. Isso torna o failover e o escalonamento mais rápidos e menos arriscados.

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

Mais considerações sobre confiabilidade

Ao criar a arquitetura de nuvem para sua carga de trabalho, analise as práticas recomendadas e as recomendações relacionadas à confiabilidade fornecidas na documentação a seguir:

Otimização de custos

Nesta seção, você encontra orientações para otimizar o custo de configuração e operação de uma topologia global do Google Cloud criada usando essa arquitetura de referência.

Tipos de máquina de VM

Para ajudar você a otimizar a utilização dos recursos de VM, o Compute Engine fornece recomendações de tipo de máquina. Use as recomendações para escolher os tipos de máquina que atendem aos requisitos de computação da carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, é possível personalizar o tipo de máquina de acordo com suas necessidades e economizar dinheiro usando tipos de máquinas personalizados.

Modelo de provisionamento de VM

Se o aplicativo for tolerante a falhas, as VMs spot podem ajudar a reduzir os custos do Compute Engine para as VMs nos níveis do aplicativo e da Web. O custo das VMs spot é significativamente menor do que as VMs regulares. No entanto, o Compute Engine pode interromper ou excluir antecipadamente as VMs spot para recuperar a capacidade. As VMs spot são adequadas para jobs em lote que toleram preempção e não têm requisitos de alta disponibilidade. As VMs spot oferecem os mesmos tipos de máquina, opções e desempenho que as VMs regulares. No entanto, quando a capacidade de recursos em uma zona é limitada, os MIGs podem não conseguir fazer o escalonamento horizontal (ou seja, criar VMs) automaticamente para o tamanho de destino especificado até que a capacidade necessária fique disponível novamente.

Utilização de recursos da VM

O recurso de escalonamento automático dos MIGs sem estado permite que seu aplicativo processe aumentos no tráfego de maneira eficiente, além de ajudar a reduzir o custo quando a necessidade de recursos for baixa. MIGs com estado não podem ser escalonados automaticamente.

Custo do banco de dados

O Spanner ajuda a garantir que os custos do banco de dados sejam previsíveis. A capacidade de computação especificada (número de nós ou unidades de processamento) determina a capacidade de armazenamento. As capacidades de leitura e gravação são escalonadas linearmente com capacidade de computação. Você paga apenas pelo que usa. Quando for necessário alinhar os custos com as necessidades da carga de trabalho, ajuste o tamanho da instância do Spanner.

Licenciamento de terceiros

Ao migrar cargas de trabalho de terceiros para o Google Cloud, você pode reduzir os custos trazendo suas próprias licenças (BYOL, na sigla em inglês). Por exemplo, para implantar VMs do Microsoft Windows Server, em vez de usar uma imagem Premium que gera mais custos com a licença de terceiros, é possível criar e usar uma imagem personalizada BYOL do Windows. Você paga apenas pela infraestrutura de VM usada no Google Cloud. Essa estratégia ajuda você a manter o valor dos seus investimentos em licenças de terceiros. Se você decidir usar a abordagem BYOL, recomendamos o seguinte:

Mais considerações sobre custo

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

Eficiência operacional

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia global do Google Cloud para operar de maneira eficiente.

Atualizações de configuração da VM

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

Imagens de VM

Para seus modelos de instância do MIG, em vez de usar imagens públicas fornecidas pelo Google, recomendamos que você crie e use imagens personalizadas que contenham as configurações e o software que seus aplicativos exigem. É possível agrupar suas imagens personalizadas em uma família de imagens personalizadas. Uma família de imagens sempre indica a imagem mais recente que ela contém, permitindo que seus modelos e scripts de instâncias usem essa imagem sem precisar atualizar as referências para uma versão específica de imagem.

Modelos deterministas de instâncias

Se os modelos de instância que você usa para seus MIGs incluírem scripts de inicialização para instalar software de terceiros, verifique se os scripts especificam explicitamente os parâmetros de instalação do software, como a versão do software. Caso contrário, quando o MIG criar as VMs, o software instalado nelas poderá não ser consistente. Por exemplo, se o modelo de instância incluir um script de inicialização para instalar o Servidor HTTP Apache 2.0 (o pacote apache2), verifique se o script especifica a versão exata do apache2 que precisa ser instalada como a versão 2.4.53. Para mais informações, consulte Modelos deterministas de instâncias.

Migração para o Spanner

É possível migrar os dados de outros bancos de dados para o Spanner, como o MySQL, SQL Server e Oracle Database. O processo de migração depende de fatores como o banco de dados de origem, o tamanho dos dados, as restrições de inatividade e a complexidade do código do aplicativo. Para ajudar você a planejar e implementar a migração para o Spanner de maneira eficiente, fornecemos uma variedade de ferramentas do Google Cloud e de terceiros. Para mais informações, consulte Visão geral da migração.

Administração de banco de dados

Com o Spanner, você não precisa configurar ou monitorar a replicação ou o failover. A replicação síncrona e o failover automático são integrados. Seu aplicativo sofre inatividade zero para manutenção do banco de dados e failover. Para reduzir ainda mais a complexidade operacional, configure o escalonamento automático. Com o escalonamento automático ativado, não é preciso monitorar e escalonar o tamanho da instância manualmente.

Mais considerações operacionais

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas gerais para eficiência operacional descritas em Framework de arquitetura do Google Cloud: excelência operacional.

Otimização de desempenho

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia global no Google Cloud que atenda aos requisitos de desempenho das suas cargas de trabalho.

Posicionamento da VM

Para cargas de trabalho que exigem baixa latência de rede entre VMs, crie uma política de posicionamento compacto e aplique-a ao modelo do MIG. Quando o MIG cria VMs, ele as coloca em servidores físicos próximos uns dos outros. Para mais informações, consulte Reduzir a latência usando políticas de posicionamento compactas.

Tipos de máquina de VM

O Compute Engine oferece uma ampla variedade de tipos de máquinas predefinidos e personalizáveis que podem ser escolhidos de acordo com seus requisitos de custo e desempenho. Os tipos de máquina são agrupados em séries e famílias. A tabela a seguir fornece um resumo das famílias de máquinas recomendadas para diferentes tipos de carga de trabalho:

Requisito Família de máquinas recomendada
Melhor custo-benefício para diversas cargas de trabalho Família de máquinas de uso geral
Maior desempenho por núcleo e otimizado para cargas de trabalho de computação intensiva Família de máquinas com otimização para computação
Proporção alta de memória para vCPU para cargas de trabalho com uso intensivo de memória Família de máquinas com otimização de memória
GPUs para cargas de trabalho em paralelo Família de máquinas com otimização de acelerador
Pouco uso de núcleos e alta densidade de armazenamento Família de máquinas com otimização de armazenamento

Para mais informações, consulte o Guia de comparação e recursos para famílias de máquinas.

Várias linhas de execução de VM

Cada CPU virtual (vCPU) alocada para uma VM do Compute Engine é implementada como um multithread de hardware único. Por padrão, duas vCPUs compartilham um núcleo físico da CPU. Para cargas de trabalho altamente paralelas ou que realizam cálculos de ponto flutuante, como análise de sequência genética e modelagem de risco financeiro, é possível melhorar o desempenho reduzindo o número de linhas de execução executadas em cada núcleo de CPU física. Para ver mais informações, consulte Definir número de linhas de execução por núcleo.

Níveis de serviço de rede

Os Níveis de serviço de rede permitem otimizar o custo de rede e o desempenho das suas cargas de trabalho. Dependendo dos seus requisitos, é possível escolher o nível Premium ou Standard.

A arquitetura neste documento usa um balanceador de carga externo global com um endereço IP externo e back-ends em várias regiões. Essa arquitetura exige o nível Premium, que usa o backbone global altamente confiável do Google para ajudar você a ter o mínimo de perda de pacotes e latência.

Se você usa balanceadores de carga externos regionais e roteia o tráfego para regiões usando o Cloud DNS, é possível escolher o nível Premium ou Standard, dependendo dos seus requisitos. O preço do nível Standard é menor que o do nível Premium. O nível Standard é adequado para tráfego que não é sensível à perda de pacotes e que não tem requisitos de baixa latência.

Desempenho do Spanner

Ao provisionar uma instância do Spanner, você especifica a capacidade de computação da instância em termos de número de nós ou unidades de processamento. Monitore a utilização de recursos da instância do Spanner e escalone a capacidade com base na carga esperada e nos requisitos de desempenho do aplicativo. É possível escalonar a capacidade de uma instância do Spanner de maneira manual ou automática. Para mais informações, consulte Visão geral do escalonamento automático.

Com uma configuração multirregional, o Spanner replica os dados de maneira síncrona entre várias regiões. Essa replicação permite operações de leitura de baixa latência a partir de vários locais. A desvantagem é que há maior latência nas operações de write, porque as réplicas de quórum estão espalhadas por várias regiões. Para minimizar a latência de transações de leitura e gravação em uma configuração multirregional, o Spanner usa o roteamento com reconhecimento de líder (ativado por padrão).

Para recomendações sobre como otimizar o desempenho da instância e dos bancos de dados do Spanner, consulte a seguinte documentação:

Armazenamento em cache

Se o aplicativo disponibilizar recursos estáticos de site e a arquitetura incluir um balanceador de carga de aplicativo externo global, use o Cloud CDN para armazenar em cache o conteúdo estático acessado com frequência mais próximo dos seus usuários. O Cloud CDN pode ajudar a melhorar o desempenho para os usuários, reduzir o uso de recursos de infraestrutura no back-end e reduzir os custos de entrega de rede. Para mais informações, consulte Desempenho da Web mais rápido e proteção aprimorada para balanceamento de carga.

Mais considerações de desempenho

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas gerais e as recomendações fornecidas em Framework de arquitetura do Google Cloud: otimização de desempenho.

A seguir

Colaboradores

Autor: Kumar Dhanagopal | Desenvolvedor de soluções de vários produtos

Outros colaboradores: