Este guia apresenta o ambiente flexível para quem está familiarizado com o ambiente padrão. Explica as semelhanças e as principais diferenças entre os ambientes, e também fornece recomendações arquitetónicas gerais para aplicações que usam ambos os ambientes.
Para um mapeamento dos serviços disponíveis no ambiente padrão para os respetivos análogos no ambiente flexível, consulte o artigo Migrar serviços do ambiente padrão para o ambiente flexível.
Semelhanças e principais diferenças
Ambos os ambientes oferecem a implementação, a publicação e a infraestrutura de escalabilidade do App Engine. As principais diferenças residem na forma como o ambiente executa a sua aplicação, como a sua aplicação acede a serviços externos, como executa a sua aplicação localmente e como a sua aplicação é dimensionada. Também pode consultar o artigo sobre como escolher um ambiente para ver um resumo geral destas diferenças.
Execução de aplicações
No ambiente padrão, a sua aplicação é executada numa instância simples dentro de um isolamento de processos (sandbox). Esta sandbox restringe o que a sua aplicação pode fazer. Por exemplo, a sandbox só permite que a sua app use um conjunto limitado de bibliotecas binárias e a sua app não pode escrever no disco. O ambiente padrão também limita as opções de CPU e memória disponíveis para a sua aplicação. Devido a estas restrições, a maioria das aplicações padrão do App Engine tende a ser aplicações Web sem estado que respondem rapidamente a pedidos HTTP.
Por outro lado, o ambiente flexível executa a sua aplicação em contentores Docker em máquinas virtuais (VMs) do Google Compute Engine, que têm menos restrições. Por exemplo, pode usar qualquer linguagem de programação à sua escolha, escrever no disco, usar qualquer biblioteca que quiser e até executar vários processos. O ambiente flexível também lhe permite escolher qualquer tipo de máquina do Compute Engine para as suas instâncias, para que a sua aplicação tenha acesso a mais memória e CPU.
Aceder a serviços externos
No ambiente padrão, a sua aplicação acede normalmente a serviços como o Datastore através das APIs google.appengine incorporadas. No entanto, no ambiente flexível, estas APIs já não estão disponíveis. Em alternativa, use as bibliotecas de cliente do Google Cloud. Estas bibliotecas cliente funcionam em qualquer lugar, o que significa que a sua aplicação é mais portátil. Se necessário, as aplicações executadas no ambiente flexível podem normalmente ser executadas no Google Kubernetes Engine ou no Compute Engine sem grandes modificações.
Desenvolvimento local
No ambiente padrão, normalmente, executa a aplicação localmente através do SDK do App Engine. O SDK processa a execução da sua aplicação e emula os serviços do App Engine. No ambiente flexível, o SDK deixa de ser usado para executar a sua aplicação. Em alternativa, as aplicações escritas para o ambiente flexível devem ser escritas como aplicações Web padrão que podem ser executadas em qualquer lugar. Conforme
mencionado, o ambiente flexível executa apenas a sua aplicação num contentor
Docker. Isto significa que, para testar a aplicação localmente, basta executar a aplicação diretamente. Por exemplo, para executar uma aplicação Python com o Django, basta executar python manage.py runserver.
Outra diferença fundamental é que as aplicações do ambiente flexível executadas localmente usam serviços reais da Cloud Platform, como o Datastore. Use um projeto separado para testar localmente e, quando disponíveis, use emuladores.
Caraterísticas de dimensionamento
Embora ambos os ambientes usem a infraestrutura de escalabilidade automática do App Engine, a forma como escalam é diferente. O ambiente padrão pode ser dimensionado de zero instâncias até milhares muito rapidamente. Por outro lado, o ambiente flexível tem de ter, pelo menos, uma instância em execução para cada versão ativa e pode demorar mais tempo a ser expandido em resposta ao tráfego.
O ambiente padrão usa um algoritmo de escala automática concebido à medida. O ambiente flexível usa o escalador automático do Compute Engine. Tenha em atenção que o ambiente flexível não suporta todas as opções de escalabilidade automática disponíveis para o Compute Engine. O App Engine respeita todas as reservas de VMs do Compute Engine que já tenha numa região que corresponda à sua configuração. Ter uma reserva de VM aumenta a probabilidade de receber uma atribuição de recursos durante uma escassez temporária de recursos.
Os programadores devem testar o comportamento da respetiva aplicação sob várias condições. Por exemplo, deve verificar como o dimensionamento automático responde quando uma aplicação limitada pela CPU se torna limitada pela E/S durante os períodos em que as chamadas para serviços remotos têm uma latência elevada.
Verificações de funcionamento
O ambiente padrão não usa verificações de funcionamento para determinar se deve ou não enviar tráfego para uma instância. O ambiente flexível permite que os programadores de aplicações escrevam os seus próprios controladores de verificação de estado que serão usados pelo equilibrador de carga para determinar se deve ou não enviar tráfego para uma instância e se deve ou não ser reparada automaticamente. Os programadores devem ter cuidado ao adicionar lógica às verificações de estado. Por exemplo, se a verificação de estado fizer uma chamada para um serviço externo, uma falha temporária nesse serviço pode fazer com que todas as instâncias fiquem em mau estado, o que pode levar a uma falha em cascata.
Rejeitar pedidos quando estiver sobrecarregado
As aplicações podem rejeitar pedidos quando estão sobrecarregadas como parte de uma estratégia para evitar falhas em cascata. Esta capacidade está integrada na camada de encaminhamento de tráfego no ambiente padrão. Recomendamos que os programadores de aplicações com um QPS muito elevado no ambiente flexível criem esta capacidade para rejeitar tráfego sobrecarregado nas respetivas aplicações, limitando o número de pedidos simultâneos.
Pode verificar se a sua aplicação de ambiente flexível não é suscetível a este tipo de falha criando uma versão com um limite para o número máximo de instâncias. Em seguida, aumente o tráfego de forma constante até que os pedidos sejam ignorados. Deve garantir que a sua aplicação não falha nas verificações de estado durante a sobrecarga.
Para Java, as apps Java que usam o tempo de execução do Jetty podem configurar o filtro de qualidade de serviço para implementar a sobrecarga de eliminação. Pode definir o número máximo de pedidos simultâneos processados pelas apps e o período durante o qual os pedidos vão ser colocados em fila de espera através desta funcionalidade.
Tamanhos das instâncias
As instâncias do ambiente Flexible podem ter limites de CPU e memória superiores aos possíveis com as instâncias do ambiente padrão. Isto permite que as instâncias flexíveis executem aplicações que consomem mais memória e CPU. No entanto, pode aumentar a probabilidade de erros de concorrência devido ao aumento de threads numa única instância.
Os programadores podem usar SSH numa instância do ambiente flexível e obter um despejo de threads para resolver este tipo de problema.
Por exemplo, se estiver a usar o tempo de execução Java, pode executar o seguinte:
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Limite de tempo máximo do pedido
Embora o limite de tempo do pedido do ambiente padrão varie com o tipo de escalabilidade selecionado, o ambiente flexível impõe sempre um limite de tempo de 60 minutos. Para evitar deixar pedidos abertos durante os 60 minutos completos e, potencialmente, usar todos os threads no servidor Web:
Ao fazer chamadas para serviços externos, especifique um limite de tempo.
Implemente um filtro de servlet para parar pedidos que demorem um período inaceitavelmente longo, como 60 segundos. Certifique-se de que a sua app pode regressar a um estado consistente depois de o filtro parar um pedido.
Gestão de discussões
Os tempos de execução Java do ambiente padrão anteriores ao Java 8 só podiam usar threads criados com o SDK do ambiente padrão do App Engine. Os programadores que portam uma aplicação de um tempo de execução do ambiente padrão Java de primeira geração para o ambiente flexível têm de mudar para a utilização de bibliotecas de threads nativas. As aplicações que requerem um número muito grande de threads podem ser executadas de forma mais eficiente com pools de threads do que com a criação explícita de threads.
Migração de tráfego
O ambiente padrão oferece uma funcionalidade de migração de tráfego que move gradualmente o tráfego para uma nova versão para minimizar os picos de latência. Consulte os documentos de migração de tráfego para saber como garantir que evita um pico de latência quando muda o tráfego para uma nova versão.
Falhas de zona única
As aplicações de ambiente padrão têm um único alojamento, o que significa que todas as instâncias da aplicação residem numa única zona de disponibilidade. Em caso de falha nessa zona, a aplicação inicia novas instâncias numa zona diferente na mesma região, e o balanceador de carga encaminha o tráfego para as novas instâncias. Vai ver um pico de latência devido a pedidos de carregamento e também a uma descarga da Memcache.
As aplicações do ambiente Flexible usam grupos de instâncias geridas regionais, o que significa que as instâncias são distribuídas por várias zonas de disponibilidade numa região. Em caso de falha de uma única zona, o balanceador de carga deixa de encaminhar tráfego para essa zona. Se tiver definido o ajuste de escala automático para executar as suas instâncias o mais rapidamente possível, vai ver um breve período de sobrecarga antes de o ajuste de escala automático criar mais instâncias.
Comparações de custos
Existem muitos fatores envolvidos na comparação de custos entre cargas de trabalho executadas em ambientes padrão e flexíveis. Por exemplo:
- Preço pago por ciclo de faturação.
- Capacidades da plataforma da CPU, que afetam o trabalho que pode ser feito por MCycle
- O quão rapidamente pode executar instâncias em cada plataforma.
- Custo das implementações, que pode diferir em cada plataforma e pode ser significativo se estiver a usar a implementação contínua para a sua aplicação.
- Sobrecarga de tempo de execução.
Tem de executar experiências para determinar o custo da sua carga de trabalho em cada plataforma. No ambiente flexível, pode usar as QPS por núcleo como um proxy para a eficiência de custos da sua aplicação quando executa experiências para determinar se uma alteração tem um impacto nos custos. O ambiente padrão não oferece um mecanismo deste tipo para obter métricas em tempo real sobre a eficiência de custos da sua aplicação. Tem de fazer uma alteração e aguardar que o ciclo de faturação diário seja concluído.
Microsserviços
O ambiente padrão permite a autenticação segura entre aplicações através do cabeçalho do pedido X-Appengine-Inbound-Appid. O ambiente flexível não tem essa funcionalidade. A abordagem recomendada para a autenticação segura entre aplicações é usar o OAuth.
Implementação
As implementações no ambiente padrão são geralmente mais rápidas do que as implementações no ambiente flexível. É mais rápido aumentar a escala de uma versão existente num ambiente flexível do que implementar uma nova versão, porque a programação de rede de uma nova versão é normalmente o fator mais demorado numa implementação de ambiente flexível. Uma estratégia para fazer reversões rápidas no ambiente flexível é manter uma versão conhecida que funcione bem reduzida a uma única instância. Em seguida, pode dimensionar essa versão e encaminhar todo o tráfego para ela através da divisão de tráfego.
Quando usar o ambiente flexível
O ambiente flexível destina-se a complementar o ambiente padrão. Se tiver uma aplicação existente em execução no ambiente padrão, normalmente, não é necessário migrar toda a aplicação para o ambiente flexível. Em vez disso, identifique as partes da sua aplicação que requerem mais CPU, mais RAM, uma biblioteca ou um programa de terceiros especializado, ou que precisam de realizar ações que não são possíveis no ambiente padrão. Depois de identificar estas partes da sua aplicação, crie pequenos serviços do App Engine que usem o ambiente flexível para processar apenas essas partes. O seu serviço existente em execução no ambiente padrão pode chamar os outros serviços através de HTTP, Cloud Tasks ou Cloud Pub/Sub.
Por exemplo, se tiver uma aplicação Web existente em execução no ambiente padrão e quiser adicionar uma nova funcionalidade para converter ficheiros em PDFs, pode escrever um microsserviço separado que seja executado no ambiente flexível e que apenas processe a conversão para PDF. Este microsserviço pode ser um programa simples composto apenas por um ou dois processadores de pedidos. Este microsserviço pode instalar e usar qualquer programa Linux disponível para ajudar na conversão, como o unoconv.
A sua aplicação principal permanece no ambiente padrão e pode chamar este microsserviço diretamente através de HTTP ou, se prevê que a conversão demore muito tempo, a aplicação pode usar o Cloud Tasks ou o Pub/Sub para colocar os pedidos em fila.