Implemente a ferramenta de redimensionamento automático nas funções do Cloud Run

A ferramenta de dimensionamento automático foi concebida para permitir flexibilidade e pode acomodar a separação de responsabilidades existente entre as suas equipas de operações e de aplicações. A responsabilidade de configurar o dimensionamento automático das instâncias do Spanner pode ser centralizada numa única equipa de operações ou pode ser distribuída pelas equipas mais próximas das aplicações fornecidas por essas instâncias do Spanner.

Este documento faz parte de uma série que também inclui:

Esta série destina-se a equipas de TI, operações e engenharia de fiabilidade do site (SRE) que querem reduzir as despesas gerais operacionais e otimizar o custo das implementações do Spanner.

Esta página apresenta três formas de implementar o Autoscaler em funções do Cloud Run, de acordo com os seus requisitos:

  • Uma topologia de implementação por projeto. A infraestrutura do redimensionador automático é implementada no mesmo projeto que o Spanner que precisa de ser redimensionado automaticamente. Recomendamos esta topologia para equipas independentes que queiram gerir a sua própria configuração e infraestrutura do escalador automático. Uma topologia de implementação por projeto também é um bom ponto de partida para testar as capacidades do escalador automático.
  • Uma topologia de implementação centralizada. A ferramenta de dimensionamento automático é implementada num projeto e gere uma ou mais instâncias do Spanner em projetos diferentes. Recomendamos esta topologia para equipas que gerem a configuração e a infraestrutura de uma ou mais instâncias do Spanner, mantendo os componentes e a configuração do escalador automático num local central. Na topologia centralizada, além de um projeto do Autoscaler, configura um segundo projeto, que neste tutorial é denominado projeto de aplicação. O projeto da aplicação contém os recursos da aplicação, incluindo o Spanner.
  • Uma topologia de implementação distribuída. A maioria da infraestrutura do escalador automático é implementada num projeto, mas alguns componentes da infraestrutura são implementados com as instâncias do Spanner a serem dimensionadas automaticamente em projetos diferentes. Recomendamos esta topologia para organizações com várias equipas, em que as equipas que são proprietárias das instâncias do Spanner querem gerir apenas os parâmetros de configuração do escalador automático para as respetivas instâncias, mas o resto da infraestrutura do escalador automático é gerido por uma equipa central.

Sem servidor para facilitar a implementação e a gestão

Neste modelo, a ferramenta de escala automática é criada usando apenas ferramentas sem servidor e de gestão reduzida, como as funções do Cloud Run, o Pub/Sub, o Cloud Scheduler e o Firestore. Google Cloud Esta abordagem minimiza o custo e a sobrecarga operacional da execução da ferramenta de ajuste automático de escala.

Ao usar Google Cloud ferramentas incorporadas, a ferramenta de dimensionamento automático pode tirar total partido da gestão de identidade e de acesso (IAM) para autenticação e autorização.

Configuração

A ferramenta de dimensionamento automático gere instâncias do Spanner através da configuração definida no Cloud Scheduler. Se forem necessárias várias instâncias do Spanner para serem consultadas com o mesmo intervalo, recomendamos que as configure no mesmo trabalho do Cloud Scheduler. A configuração de cada instância é representada como um objeto JSON. Segue-se um exemplo de uma configuração em que duas instâncias do Spanner são geridas com uma tarefa do Cloud Scheduler:

[
  {
    "projectId": "my-spanner-project",
    "instanceId": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "PROCESSING_UNITS",
    "minSize": 500,
    "maxSize": 3000,
    "scalingMethod": "DIRECT"
  }
]

As instâncias do Spanner podem ter várias configurações em diferentes tarefas do Cloud Scheduler. Por exemplo, uma instância pode ter uma configuração do escalador automático com o método linear para operações normais, mas também ter outra configuração do escalador automático com o método direto para cargas de trabalho em lote planeadas.

Quando a tarefa do Cloud Scheduler é executada, envia uma mensagem do Pub/Sub para o tópico do Pub/Sub de sondagem. A carga útil desta mensagem é a matriz JSON dos objetos de configuração para todas as instâncias configuradas na mesma tarefa. Veja a lista completa de opções de configuração no ficheiro Poller README.

Topologia por projeto

Numa implementação de topologia por projeto, cada projeto com uma instância do Spanner que precisa de ser dimensionada automaticamente também tem a sua própria implementação independente dos componentes do dimensionador automático. Recomendamos esta topologia para equipas independentes que queiram gerir a sua própria configuração e infraestrutura do escalador automático. Também é um bom ponto de partida para testar as capacidades da ferramenta de dimensionamento automático.

O diagrama seguinte mostra uma vista conceptual de alto nível de uma implementação por projeto.

Implementação conceptual por projeto.

As implementações por projeto representadas no diagrama anterior têm as seguintes características:

  • Duas aplicações, a Aplicação 1 e a Aplicação 2, usam as suas próprias instâncias do Spanner.
  • As instâncias do Spanner (A) estão nos respetivos projetos da Aplicação 1 e da Aplicação 2.
  • Um escalador automático independente (B) é implementado em cada projeto para controlar o escalamento automático das instâncias num projeto.

Uma implementação por projeto tem as seguintes vantagens e desvantagens.

Vantagens:

  • Design mais simples: a topologia por projeto é o design mais simples das três topologias, uma vez que todos os componentes do escalamento automático são implementados juntamente com as instâncias do Spanner que estão a ser escaladas automaticamente.
  • Configuração: o controlo sobre os parâmetros do programador pertence à equipa proprietária da instância do Spanner, o que dá à equipa mais liberdade para adaptar a ferramenta de escalamento automático às suas necessidades do que uma topologia centralizada ou distribuída.
  • Limite claro da responsabilidade da infraestrutura: a conceção de uma topologia por projeto estabelece um limite claro de responsabilidade e segurança sobre a infraestrutura do escalador automático, porque o proprietário da equipa das instâncias do Spanner também é o proprietário da infraestrutura do escalador automático.

Desvantagens:

  • Manutenção mais geral: cada equipa é responsável pela configuração e infraestrutura do escalador automático, pelo que pode ser difícil garantir que todas as ferramentas do escalador automático da empresa seguem as mesmas diretrizes de atualização.
  • Auditoria mais complexa: uma vez que cada equipa tem um elevado nível de controlo, uma auditoria centralizada pode tornar-se mais complexa.

Para saber como configurar o Autoscaler através de uma topologia por projeto, consulte o guia passo a passo para a implementação por projeto.

Topologia centralizada

Tal como na topologia por projeto, numa implementação de topologia centralizada, todos os componentes da ferramenta de escalamento automático residem no mesmo projeto. No entanto, as instâncias do Spanner estão localizadas em projetos diferentes. Esta implementação é adequada para uma equipa que gere a configuração e a infraestrutura de várias instâncias do Spanner a partir de uma única implementação da ferramenta de escalamento automático num local central.

O diagrama seguinte mostra uma vista conceptual de alto nível de uma implementação de projeto centralizado:

Implementação de projetos centralizada conceptual.

A implementação centralizada apresentada no diagrama anterior tem as seguintes características:

  • Duas aplicações, a Aplicação 1 e a Aplicação 2, usam as suas próprias instâncias do Spanner.
  • As instâncias do Spanner (A) estão nos respetivos projetos da Aplicação 1 e da Aplicação 2.
  • O escalador automático (B) é implementado num projeto separado para controlar o escalamento automático das instâncias do Spanner nos projetos Application 1 e Application 2.

Uma implementação centralizada tem as seguintes vantagens e desvantagens.

Vantagens:

  • Configuração e infraestrutura centralizadas: uma única equipa controla os parâmetros do programador e a infraestrutura do dimensionamento automático. Esta abordagem pode ser útil em setores fortemente regulamentados.
  • Menos manutenção geral: geralmente, a manutenção e a configuração exigem menos esforço em comparação com uma implementação por projeto.
  • Políticas e auditoria centralizadas: as práticas recomendadas entre equipas podem ser mais fáceis de especificar e implementar. As auditorias podem ser mais fáceis de executar.

Desvantagens:

  • Configuração centralizada: qualquer alteração aos parâmetros do dimensionamento automático tem de passar pela equipa centralizada, mesmo que a equipa que solicita a alteração seja proprietária da instância do Spanner.
  • Potencial de risco adicional: a própria equipa centralizada pode tornar-se um ponto único de falha, mesmo que a infraestrutura do escalador automático seja concebida tendo em conta a elevada disponibilidade.

Para saber como configurar o dimensionador automático através de uma topologia centralizada, consulte o guia passo a passo para a implementação centralizada.

Topologia distribuída

Numa implementação de topologia distribuída, as instâncias do Cloud Scheduler e do Spanner que precisam de ser dimensionadas automaticamente residem no mesmo projeto. Os restantes componentes da ferramenta de escalamento automático residem num projeto gerido centralmente. Esta implementação é uma implementação híbrida. As equipas proprietárias das instâncias do Spanner gerem apenas os parâmetros de configuração do escalador automático para as respetivas instâncias, e uma equipa central gere a infraestrutura do escalador automático restante.

O diagrama seguinte mostra uma vista conceptual de alto nível de uma implementação de projeto distribuído.

Implementação conceptual de projetos distribuídos.

A implementação híbrida representada no diagrama anterior tem as seguintes características:

  • Duas aplicações, a Aplicação 1 e a Aplicação 2, usam as suas próprias instâncias do Spanner.
  • As instâncias do Spanner (A) estão nos projetos Application 1 e Application 2.
  • Um componente do Cloud Scheduler independente (C) é implementado em cada projeto: Application 1 e Application 2.
  • Os restantes componentes do Autoscaler (B) são implementados num projeto separado.
  • A ferramenta de dimensionamento automático dimensiona automaticamente as instâncias do Spanner nos projetos Application 1 e Application 2 usando as configurações enviadas pelos componentes independentes do Cloud Scheduler em cada projeto.

Função de encaminhamento

O Cloud Scheduler só pode publicar mensagens em tópicos no mesmo projeto. Por isso, para a topologia distribuída, é necessário um componente intermédio denominado função de encaminhamento.

A função Forwarder recebe mensagens publicadas no Pub/Sub a partir do Cloud Scheduler, verifica a respetiva sintaxe JSON e encaminha-as para o tópico Pub/Sub do Poller. O tópico pode pertencer a um projeto separado do Cloud Scheduler.

O diagrama seguinte mostra os componentes usados para o mecanismo de encaminhamento:

Mecanismo de encaminhamento.

Conforme mostrado no diagrama anterior, as instâncias do Spanner estão em projetos com os nomes Application 1 e Application 2:

  1. O Cloud Scheduler é o mesmo projeto que as instâncias do Spanner.

  2. (2a) O Cloud Scheduler publica as respetivas mensagens no tópico Forwarder nos projetos Application 1 e Application 2.

    (2b) A função Forwarder lê mensagens do tópico Forwarder.

    (2c) A função Forwarder encaminha mensagens para o tópico de sondagem residente no projeto do escalador automático.

  3. A função Poller lê as mensagens do tópico de sondagem e o processo continua, conforme descrito na secção Poller.

Uma implementação distribuída tem as seguintes vantagens e desvantagens.

Vantagens:

  • As equipas de aplicações controlam a configuração e os agendamentos: o Cloud Scheduler é implementado juntamente com as instâncias do Spanner que estão a ser dimensionadas automaticamente, o que dá às equipas de aplicações mais controlo sobre a configuração e o agendamento.
  • A equipa de operações controla a infraestrutura: os componentes principais da ferramenta de escalamento automático são implementados centralmente, o que dá às equipas de operações o controlo sobre a infraestrutura de escalamento automático.
  • Manutenção centralizada: a infraestrutura do Scaler é centralizada, o que reduz a sobrecarga.

Desvantagens:

  • Configuração mais complexa: as equipas de aplicações têm de fornecer contas de serviço para escrever no tópico de sondagem.
  • Potencial de risco adicional: a infraestrutura partilhada pode tornar-se um ponto único de falha, mesmo que a infraestrutura seja concebida com alta disponibilidade em mente.

Para saber como configurar o Autoscaler através de uma topologia distribuída, consulte o guia passo a passo para a implementação distribuída.

O que se segue?