As instâncias são os componentes fundamentais do App Engine, que fornecem todos os recursos necessários para alojar com êxito a sua aplicação. Em qualquer altura, a sua aplicação pode estar a ser executada numa ou várias instâncias com pedidos distribuídos por todas elas. Cada instância inclui uma camada de segurança para garantir que as instâncias não se afetam inadvertidamente entre si.
O App Engine pode criar e encerrar automaticamente instâncias à medida que o tráfego flutua, ou pode especificar um número de instâncias a executar independentemente da quantidade de tráfego. Para determinar como e quando são criadas novas instâncias, especifique um tipo de escalabilidade para a sua app. As definições de escalabilidade são aplicadas ao nível da versão do App Engine como parte do ficheiro app.yaml.
Tipos de dimensionamento
O App Engine suporta os seguintes tipos de escalabilidade, que controlam como e quando as instâncias são criadas:
- Automático (predefinição)
- Básico
- Manual
Especifica o tipo de dimensionamento no app.yaml da sua app.
Por predefinição, a sua app usa o escalamento automático, o que significa que o App Engine vai gerir o número de instâncias inativas.
- Escala automática
- A escalabilidade automática cria instâncias com base na taxa de pedidos, nas latências de resposta e noutras métricas da aplicação. Pode especificar limites para cada uma destas métricas, bem como um número mínimo de instâncias a manter em execução em todos os momentos, configurando o elemento
automatic_scaling.
- Dimensionamento básico
- O escalamento básico cria instâncias quando a sua aplicação recebe pedidos. Cada instância é encerrada quando a aplicação fica inativa. O dimensionamento básico é ideal para trabalho intermitente ou conduzido pela atividade do utilizador.
- Escala manual
- O dimensionamento manual especifica o número de instâncias que são executadas continuamente independentemente do nível de carga. Isto permite tarefas como inicializações complexas e aplicações que dependem do estado da memória ao longo do tempo.
| Funcionalidade | Escala automática | Dimensionamento básico | Escala manual |
|---|---|---|---|
| Limite de tempo do pedido |
10 minutos para pedidos HTTP e tarefas da fila de tarefas. Se a sua app não
devolver um pedido dentro deste limite de tempo, o App Engine interrompe
o controlador de pedidos e
emite
um erro para o seu código processar.
Para tempos de execução antigos (Java 8, PHP 5 e Python 2):
|
24 horas para pedidos HTTP e tarefas da fila de tarefas. Se a sua app não
devolver um pedido dentro deste limite de tempo, o App Engine interrompe o
processador de pedidos e
emite
um erro para o seu código processar.
Uma instância dimensionada básica pode optar por processar |
Igual ao dimensionamento básico. |
| Residência | As instâncias são encerradas com base nos padrões de utilização. |
As instâncias são encerradas com base no parâmetro idle_timeout. Se uma instância estiver inativa, por exemplo, não tiver recebido um pedido durante mais de idle_timeout, a instância é encerrada.
|
As instâncias permanecem na memória e o estado é preservado entre pedidos. Quando as instâncias são paradas, aparece um pedido /_ah/stop nos registos.
Se existir um controlador /_ah/stop, este tem 30 segundos para ser concluído antes de o encerramento ocorrer.
|
| Arranque e encerramento | As instâncias são criadas a pedido para processar solicitações e são automaticamente desativadas quando estão inativas. |
As instâncias são criadas a pedido para processar solicitações e são automaticamente
encerradas quando estão inativas, com base no parâmetro de configuração idle_timeout. Uma instância que é
parada manualmente
tem 30 segundos para terminar o processamento de pedidos antes de ser terminada
forçadamente.
|
O App Engine envia automaticamente às instâncias um pedido de início no formato de um pedido GET vazio para /_ah/start. Tal como no
dimensionamento básico, uma instância que é
parada manualmente
tem 30 segundos para terminar o processamento de pedidos antes de ser
terminada à força.
|
| Capacidade de endereçamento da instância | As instâncias são anónimas. |
A instância "i" da versão "v" do serviço "s" é endereçável no URL:
https://i-dot-v-dot-s-dot-app_id.REGION_ID.r.appspot.com.
Se tiver configurado um
mapeamento de subdomínio com caráter universal para um domínio personalizado, também pode aceder
a um serviço ou a qualquer uma das respetivas instâncias através de um URL do formulário
https://s.domain.com ou https://i.s.domain.com.
Pode armazenar em cache o estado de forma fiável em cada instância e recuperá-lo em
pedidos subsequentes.
|
Igual ao dimensionamento básico. |
| Dimensionar |
O App Engine dimensiona automaticamente o número de instâncias em resposta ao volume de processamento. Estes fatores de dimensionamento têm em conta as
definições fornecidas com base em cada versão no ficheiro de configuração.automatic_scaling
|
Um serviço com escalabilidade básica é configurado definindo o número máximo de instâncias no parâmetro max_instances da definição basic_scaling. O número de instâncias em direto é dimensionado
com o volume de processamento.
|
Configura o número de instâncias de cada versão no ficheiro de configuração desse serviço. O número de instâncias corresponde normalmente ao tamanho de um conjunto de dados armazenado na memória ou ao débito pretendido para o trabalho offline. |
Dimensionar instâncias dinâmicas
As aplicações do App Engine que usam o escalonamento básico ou automático são suportadas por qualquer número de instâncias dinâmicas num determinado momento, consoante o volume de pedidos recebidos. À medida que os pedidos da sua aplicação aumentam, o número de instâncias dinâmicas também pode aumentar.
Apps com dimensionamento básico
Se usar o dimensionamento básico, o App Engine tenta manter o custo baixo, mesmo que isso possa resultar numa latência mais elevada à medida que o volume de pedidos recebidos aumenta.
Quando nenhuma das instâncias existentes está disponível para publicar um pedido recebido, o App Engine inicia uma nova instância. Mesmo depois de iniciar uma nova instância, algumas solicitações podem ter de ser colocadas em fila de espera até que a nova instância conclua o respetivo processo de arranque. Se precisar da latência mais baixa possível, considere usar o escalamento automático, que cria novas instâncias antecipadamente para minimizar a latência.
Apps com escala automática
Se usar o dimensionamento automático, cada instância na sua app tem a sua própria fila para pedidos recebidos. Antes que as filas fiquem suficientemente longas para ter um efeito notório na latência da sua app, o App Engine cria automaticamente uma ou mais novas instâncias para processar o aumento da carga.
Pode configurar as definições para o ajuste de escala automático de modo a alcançar um compromisso entre o desempenho pretendido e o custo que pode incorrer. A tabela seguinte descreve estas definições.
| Definições de ajuste de escala automático | Descrição |
|---|---|
| Utilização da CPU alvo | Define o limite da taxa de utilização da CPU para especificar o limite de utilização da CPU no qual são iniciadas mais instâncias para processar o tráfego. |
| Utilização do débito alvo | Define o limite de débito para o número de pedidos simultâneos após o qual são iniciadas mais instâncias para processar o tráfego. |
| Pedidos simultâneos máximos | Define o número máximo de pedidos simultâneos que uma instância pode aceitar antes de o programador gerar uma nova instância. |
Veja o vídeo Definições do Scheduler do App Engine para ver os efeitos destas definições.
Reduzir a escala
Quando os volumes de pedidos diminuem, o App Engine reduz o número de instâncias. Este dimensionamento descendente ajuda a garantir que todas as instâncias atuais da sua aplicação estão a ser usadas para uma eficiência e uma rentabilidade ideais.
Quando uma aplicação não está a ser usada, o App Engine desativa as instâncias dinâmicas associadas, mas volta a carregá-las assim que forem necessárias. A recarga de instâncias pode resultar em pedidos de carregamento e latência adicional para os utilizadores.
Pode especificar um número mínimo de instâncias inativas. Definir um número adequado de instâncias inativas para a sua aplicação com base no volume de pedidos permite que a sua aplicação publique todos os pedidos com pouca latência, a menos que esteja a registar um volume de pedidos anormalmente elevado.
Redução da escala na escala automática
Se a sua app usar o dimensionamento automático, as instâncias inativas demoram aproximadamente 15 minutos de inatividade a começar a ser encerradas. Para manter uma ou mais instâncias inativas em execução, defina o valor de min_idle_instances para 1 ou superior.
Dimensionamento e lotes de pedidos
Se estiver a enviar lotes de pedidos aos seus serviços, por exemplo, para uma fila de tarefas para processamento, é criado rapidamente um grande número de instâncias. Recomendamos que controle esta situação limitando a taxa de pedidos enviados por segundo, se possível. Por exemplo, se usar o Google Tasks, pode controlar a taxa à qual as tarefas são enviadas.
Ciclo de vida da instância
Estados da instância
Uma instância de um serviço com escalabilidade automática está sempre em execução. No entanto, uma instância de um serviço dimensionado manual ou básico pode estar em execução ou parado. Todas as instâncias do mesmo serviço e versão partilham o mesmo estado. Altera o estado das instâncias gerindo as versões. Pode:
- Use a página Versões na Google Cloud consola
- Use os comandos
gcloud app versions startegcloud app versions stop
Arranque
Cada instância de serviço é criada em resposta a um pedido de início, que é um pedido HTTP GET vazio para /_ah/start. O App Engine envia este pedido para criar uma instância. Os utilizadores não podem enviar um pedido para /_ah/start. As instâncias de escalabilidade manual e básica têm de responder ao pedido de início antes de poderem processar outro pedido. O pedido de início pode ser usado para dois fins:
- Para iniciar um programa que é executado indefinidamente, sem aceitar mais pedidos.
- Para inicializar uma instância antes de receber tráfego adicional.
As instâncias de escalonamento manual, básico e automático são iniciadas de forma diferente. Quando inicia uma instância de escalamento manual, o App Engine envia imediatamente um pedido /_ah/start a cada instância. Quando inicia uma instância de um serviço de escalabilidade básica, o App Engine permite que aceite tráfego, mas o pedido /_ah/start não é enviado para uma instância até receber o primeiro pedido do utilizador. As várias instâncias de escalabilidade básica só são iniciadas conforme necessário para processar o aumento do tráfego. As instâncias de escalamento automático não recebem nenhum pedido /_ah/start.
Quando uma instância responde ao pedido /_ah/start com um código de estado HTTP de 200–299 ou 404, considera-se que foi iniciada com êxito e pode processar pedidos adicionais. Caso contrário, o App Engine termina a instância. As instâncias de escalamento manual são reiniciadas imediatamente, enquanto as instâncias de escalamento básico são reiniciadas apenas quando necessário para publicar tráfego.
Encerrar
O processo de encerramento pode ser acionado por vários eventos planeados e não planeados, como:
- Existem demasiadas instâncias e não existem pedidos de apps suficientes (tráfego).
- Para manualmente uma instância.
- Implementa uma versão atualizada no serviço.
- A instância excede a memória máxima para o respetivo
instance_classconfigurado. - A sua aplicação fica sem quota de horas de instância.
- A sua instância é movida para uma máquina diferente, quer porque a máquina atual que está a executar a instância é reiniciada, quer porque o App Engine moveu a sua instância para melhorar a distribuição de carga.
Uma das vantagens da plataforma "pague apenas o que precisa" do ambiente padrão do App Engine, conforme descrito anteriormente em Reduzir a escala, é que o sistema ajusta automaticamente a escala do número de instâncias para zero quando não existe tráfego. Isto ajuda a tornar o App Engine uma solução económica para pequenas aplicações que não recebem pedidos contínuos. Quando uma instância tem de ser encerrada, os novos pedidos recebidos são encaminhados para outras instâncias (se existirem) e os pedidos que estão a ser processados têm tempo para serem concluídos.
Normalmente, o App Engine envia um sinal STOP (SIGTERM) para o contentor da app.
A sua app não tem de responder a este evento, mas pode usá-lo para realizar quaisquer ações de limpeza necessárias antes de o contentor ser encerrado. Em condições normais, o sistema aguarda até 3 segundos para que a app pare e, em seguida, envia um sinal KILL (SIGKILL). Se a sua app não captar o sinal SIGTERM, a instância é imediatamente encerrada.
Algumas mensagens de registo de encerramento de instâncias que pode ver incluem:
[start] Quitting on terminated signal
[INFO] Handling signal: term
[INFO] Worker exiting (pid: 21)
[INFO] Worker exiting (pid: 24)
[INFO] Shutting down: Master
[start] Start program failed: termination triggered by nginx exit
Estas mensagens de registo não indicam nenhuma condição de erro, mas são indicações do processo normal de encerramento da instância. Tenha em atenção que [start] e Start nos registos referem-se a um processo de plataforma denominado start e não têm nada a ver com o início de uma instância ou uma app.
A carregar pedidos
Quando o App Engine cria uma nova instância para a sua aplicação, a instância tem primeiro de carregar todas as bibliotecas e recursos necessários para processar o pedido. Isto ocorre durante o primeiro pedido à instância, denominado pedido de carregamento. Durante um pedido de carregamento, a sua aplicação passa por uma inicialização que faz com que o pedido demore mais tempo.
As seguintes práticas recomendadas permitem-lhe reduzir a duração dos pedidos de carregamento:
- Carregue apenas o código necessário para o arranque.
- Aceda ao disco o mínimo possível.
- Em alguns casos, carregar código a partir de um ficheiro ZIP ou JAR é mais rápido do que carregar a partir de muitos ficheiros separados.
Pedidos de aquecimento
Os pedidos de preparação são um tipo específico de pedido de carregamento que carrega o código da aplicação numa instância antecipadamente, antes de serem feitos pedidos em direto.
As instâncias de dimensionamento manual ou básico não recebem um pedido /_ah/warmup.
Tempo de atividade da instância
O App Engine tenta manter as instâncias de escalabilidade manual e básica em execução indefinidamente. No entanto, neste momento, não existe um tempo de atividade garantido para instâncias de escalabilidade manual e básica.
NTP com o ambiente padrão do App Engine
O ambiente padrão do App Engine tem serviços de protocolo de tempo de rede (NTP) que usam servidores NTP da Google. No entanto, o serviço NTP não é editável.