Como escolher a arquitetura certa para distribuição de dados globais

Esta solução apresenta três arquiteturas de exemplo que podem ser usadas para distribuir dados entre regiões do Google Cloud.

Muitas empresas trabalham com os dados de locais geograficamente dispersos enquanto respondem, em tempo quase real, aos pedidos de clientes. Por exemplo, uma plataforma de demanda (DSP, na sigla em inglês) para publicidade digital pode ter clientes que esperam que os tempos de resposta do banco de dados sejam inferiores a vinte milissegundos, independentemente da localização geográfica deles ou da carga atual da rede. A implementação desse tipo de solução DSP global não é possível se a arquitetura de rede for baseada em um único banco de dados centralizado, que é vulnerável a latências com base na distância física, além de ser muito afetado por picos de uso.

É possível atender a essas necessidades com uma arquitetura distribuída para armazenamento de dados. Nem todas as arquiteturas são apropriadas para todas as necessidades de negócios, e cada arquitetura tem diferentes pontos fortes e fracos. Portanto, esta solução oferece várias alternativas do Google Cloud que ajudam a implementar sua estratégia geral de negócios e orientar sua abordagem de implementação de rede.

Vantagens do Google Cloud

O Google Cloud oferece largura de banda de rede robusta e estável em todo o mundo. E o Google Cloud tem muito mais vantagens:

O Google Cloud é extremamente flexível, e é possível usá-lo para criar uma rede virtual global, permitindo que seus aplicativos se comuniquem com mais segurança entre regiões usando endereços IP particulares. Por exemplo, é possível configurar instâncias de máquina virtual (VM) do Compute Engine em duas regiões, como us-central1 e asia-east1. Você consegue fazer com que essas instâncias de VM usem endereços IP particulares para se comunicarem diretamente entre si ao criar uma rede de nuvem privada virtual. Assim, sua organização mantém comunicações seguras entre instâncias.

Com o IP Anycast do Google Cloud, um único endereço IP global é atribuído a um serviço gerenciado, como balanceamento de carga. Com o IP Anycast, é possível criar um único balanceador de carga global em vez de configurar balanceadores de carga em todas as regiões. O balanceador de carga global roteia solicitações de clientes para aplicativos executados nas regiões mais próximas e faz o escalonamento automático para atender à demanda crescente.

Três exemplos de arquiteturas de distribuição de dados

Nesta seção, são descritas três arquiteturas de implantação e é discutido quando a arquitetura é apropriada. As arquiteturas e os casos de uso são:

  • Implantação híbrida, baseando-se no Google Cloud e em serviços locais: Você quer manter alguns serviços locais, mas gostaria de aproveitar os recursos do Google Cloud. O Google Cloud está vinculado à sua rede atual e incorporado aos processos contínuos da sua empresa. Alguns ou todos os dados locais são copiados ou incorporados ao Google Cloud.

  • Implantação híbrida, baseando-se no Google Cloud e em outras plataformas de provedores de serviços de nuvem: Você quer manter as operações atuais do provedor de serviços de nuvem, mas gostaria de incluir alguns recursos do Google Cloud e configurar os dois sistemas para se comunicarem.

  • Google Cloud usando várias regiões: Você quer dar suporte a transferências de dados quase síncronas, possivelmente em escala global. Configurar o Google Cloud em várias regiões permite transferências de dados extremamente rápidas e quase simultâneas em todo o mundo.

Implantação híbrida: Google Cloud e serviços locais

Associar o Google Cloud a serviços locais é adequado para casos de uso relacionados a aplicativos que armazenam dados no local e que também propagam dados para o Google Cloud.

Por exemplo, no setor de varejo, os dados primários (também conhecidos como dados mestres) sobre novos produtos podem ser inseridos em bancos de dados no local para um gerenciamento de inventário legado. É possível que a empresa também precise propagar esses dados para um banco de dados do Google Cloud usado para lojas on-line. Com uma abordagem híbrida, você consegue criar um novo sistema que usa o Google Cloud sem afetar o sistema local atual. Nesta arquitetura, o Google Cloud funciona basicamente em paralelo com as estruturas de rede no local.

Considere os seguintes problemas ao decidir se implementará um Google Cloud híbrido e uma implantação no local:

  • Se os dados estiverem no local e no Google Cloud, você precisará decidir quais dados serão tratados como dados principais e onde eles residirão. Por exemplo, é possível definir os dados do Google Cloud como os dados principais. Nesse caso, o Google Cloud se comporta como um hub de dados que conecta um ou vários ambientes locais, trocando dados entre eles. Depois que os dados são adicionados ou atualizados no ambiente do Google Cloud, eles são transmitidos para sistemas locais. Como alternativa, os sistemas locais podem manter os dados principais e atualizar periodicamente o Google Cloud.
  • Se você estiver desenvolvendo um aplicativo para o ambiente híbrido em questão, lembre-se de que os serviços gerenciados estão disponíveis apenas para os recursos do Google Cloud. Aplicativos executados no local e no ambiente do Google Cloud talvez não possam contar com serviços gerenciados, como backup automatizado, redundância e escalonabilidade.
  • Para manter a portabilidade dos dados e garantir operações administrativas consistentes, talvez seja mais fácil hospedar armazenamentos de dados entre várias plataformas, como o MySQL, em máquinas virtuais na implantação local e no Google Cloud.

Exemplo de arquitetura híbrida

O diagrama a seguir ilustra um exemplo de uma arquitetura híbrida com o Google Cloud e sistemas locais.

Arquitetura de um sistema híbrido

No exemplo de arquitetura:

  • Os dados são trocados entre os servidores de arquivos locais e o Cloud Storage. Isso pode envolver o backup de arquivos locais para o Google Cloud, o processamento em lote de arquivos como entrada ou o download de arquivos do Google Cloud para redes locais.
  • As APIs REST são usadas por aplicativos personalizados nos data centers locais para acessar aplicativos no App Engine e recuperar ou enviar dados. As solicitações REST são tipicamente síncronas e bloqueiam clientes até que os resultados sejam retornados. Nessa arquitetura, o escalonamento automático é fornecido pelo App Engine para aumentar a capacidade, conforme a necessidade, o que ajuda a manter a latência baixa para essas chamadas síncronas.
  • Os aplicativos personalizados enviam mensagens diretamente ao Pub/Sub para armazená-las em uma fila replicada para processamento posterior. Quando as mensagens chegam ao Pub/Sub, esse canal retorna o status imediatamente e não bloqueia os clientes. As mensagens podem ser recuperadas e processadas de forma assíncrona usando o Cloud Functions, o Dataflow, aplicativos em execução no Compute Engine e outros métodos. Também é possível recuperar mensagens com aplicativos cliente em ambientes locais.
  • Os dados armazenados em bancos de dados locais são exportados (talvez como arquivos CSV) e enviados ao Google Cloud para carregamento em lote em bancos de dados gerenciados pelo Cloud SQL.
  • Um banco de dados do Firebase é usado para sincronizar dados entre sistemas locais e o Google Cloud. Os aplicativos são inscritos em chaves no banco de dados e, sempre que os valores são atualizados, esses apps são notificados em tempo real e recebem os valores atualizados. Os aplicativos que interagem com o Firebase podem ser locais, no Google Cloud ou ambos.

Implantação híbrida: Google Cloud e outros provedores de nuvem

É possível combinar o Google Cloud com outros provedores de nuvem para distribuir os dados com mais eficiência, aproveitar diversos mecanismos de segurança contra falhas ou usar recursos específicos do Google Cloud. Essa arquitetura é uma boa opção quando você já tem serviços de produção em execução em outros provedores de nuvem, mas quer aproveitar os recursos do Google Cloud. Por exemplo, talvez você queira usar o BigQuery para analisar os dados do aplicativo, assim como registros e métricas de monitoramento.

Essa arquitetura é semelhante à arquitetura híbrida local e do Google Cloud mencionada anteriormente. Considere os seguintes problemas ao implementar uma implantação híbrida do Google Cloud e de outros provedores de nuvem:

  • É possível usar bibliotecas de cliente de várias nuvens de código aberto, como jclouds e libcloud, para ajudar a integrar as APIs entre o Google Cloud e outros serviços de nuvem.
  • O Google Cloud oferece opções para transferir dados da Amazon Web Services (AWS), como o Serviço de transferência do Cloud Storage, Cloud Monitoring e Cloud Logging. É possível exportar os registros para o BigQuery e analisá-los posteriormente.
  • O Pub/Sub é um serviço global, e seus aplicativos não precisam saber em qual região as filas do Pub/Sub existem. É possível publicar mensagens ou se inscrever em tópicos disponíveis globalmente. Com o Google Cloud, os apps clientes precisam ter ciência de apenas um único conjunto de endereços IP e portas. Para outros provedores de nuvem, as filas podem ser específicas a uma região. Se for assim, quando você implanta aplicativos em várias regiões, os aplicativos cliente precisam conhecer pontos de extremidade de cada região. Manter um registro dos pontos de extremidade pode ser complicado, especialmente se você adicionar serviços de novas regiões.

Exemplo de arquitetura para o Google Cloud associado a outro provedor de nuvem

No diagrama a seguir é apresentada uma arquitetura híbrida que inclui o GCP e outros provedores de nuvem.

Arquitetura de um sistema que envolve o Google Cloud e outro provedor de nuvem.

No exemplo de arquitetura:

  • As mensagens são trocadas entre o Pub/Sub e outras nuvens públicas. O Pub/Sub fornece um endpoint global e pode atuar como um hub de mensagens entre as nuvens, porque os aplicativos não precisam saber em qual região as filas de mensagens realmente existem.
  • As instâncias do agente do Cloud Monitoring são instaladas em máquinas virtuais de outras nuvens públicas para coletar métricas sobre utilização da CPU, uso da memória, informações do processo etc. O Cloud Monitoring monitora o uso de recursos em ambientes de nuvem híbrida.
  • APIs REST são usadas por aplicativos personalizados executados em máquinas virtuais em outros ambientes em nuvem para chamar aplicativos hospedados no App Engine e enviar ou recuperar dados.
  • Os arquivos são transferidos diretamente pelo Serviço de transferência de armazenamento do Amazon S3 sob demanda ou periodicamente. É possível processar os arquivos transferidos no Compute Engine para serem carregados no Cloud SQL.

Implantação híbrida: Google Cloud com várias regiões

Uma arquitetura baseada no Google Cloud em várias regiões é uma boa opção quando seu aplicativo precisa atender aos usuários globalmente e sincronizar dados entre regiões com latência mínima. Um exemplo é um videogame habilitado para Internet que precisa funcionar em todo o mundo com sincronização quase em tempo real entre os jogadores.

Essa arquitetura aproveita o poder dos serviços gerenciados pelo Google Cloud para reduzir tarefas administrativas e facilitar o design do sistema. O Google Cloud permite que você se concentre nos aplicativos sem perder tempo com o design da infraestrutura. Considere os seguintes problemas ao implementar uma implantação híbrida do Google Cloud com várias regiões:

  • É possível implantar facilmente serviços multirregionais de processamento de dados porque os editores de mensagens e assinantes podem ser executados em qualquer região. O Pub/Sub consegue trocar mensagens entre aplicativos em execução em diferentes regiões sem que você precise especificar onde o aplicativo está sendo executado. Nesta arquitetura, as mensagens do Pub/Sub permanecem totalmente dentro do Google Cloud e não são enviadas pela Internet, resultando em menor latência.
  • Os aplicativos nas instâncias do Compute Engine podem se comunicar diretamente entre regiões usando endereços IP particulares em uma rede VPC do Google Cloud.
  • Use APIs REST para criar aplicativos personalizados vagamente acoplados. Como a arquitetura está totalmente dentro do ambiente do Google Cloud, é possível usar o App Engine para gerenciar aplicativos onde se espera tarefas administrativas mínimas.
  • Depois de distribuir dados pelas regiões, é possível usar o Dataflow ou o Dataproc para processar ETL ou cargas de trabalho de análise.

Exemplo de arquitetura multirregional do Google Cloud

O diagrama a seguir ilustra a arquitetura de uma implantação do Google Cloud com várias regiões.

Arquitetura de um sistema que envolve várias regiões do Google Cloud.

No exemplo de arquitetura:

  • Assim como na arquitetura de nuvem híbrida, o Cloud Monitoring monitora todos os recursos de computação e exibe uma visualização global consolidada do uso de recursos. Os registros e as métricas coletadas são exportados para o BigQuery para análise mais detalhada.
  • Assim como na arquitetura de nuvem híbrida, o Pub/Sub é usado como um hub de mensagens. Com o Pub/Sub, os serviços podem ser levemente acoplados e independentes de onde o aplicativo realmente é executado.
  • Aplicativos personalizados executados no App Engine ou no Compute Engine trocam mensagens diretamente com outros aplicativos personalizados usando as APIs REST. Essa é uma arquitetura acoplada com mais rigidez que a arquitetura híbrida e, portanto, com latência mais previsível.
  • O Serviço de transferência de armazenamento é usado para sincronizar buckets do Cloud Storage. Como alternativa, a ferramenta gsutil pode ser usada para transferências sob demanda entre buckets em regiões diferentes.

A seguir

Saiba mais sobre o gerenciamento de dados no Google Cloud acessando estes links: