Ambiente flexível do App Engine para usuários do ambiente padrão

Este guia é uma introdução ao ambiente flexível para os usuários que já estão familiarizados com o ambiente padrão. Aqui, você encontra explicações sobre as semelhanças e as diferenças fundamentais entre os ambientes, além de recomendações em geral sobre a arquitetura para aplicativos que usam ambos os ambientes.

Para mais informações sobre o mapeamento entre os serviços disponíveis no ambiente padrão e os equivalentes no ambiente flexível, consulte Como migrar serviços do ambiente padrão para o flexível.

Semelhanças e diferenças fundamentais

Ambos os ambientes fornecem a infraestrutura de implantação, serviço e escalonamento do App Engine. As diferenças fundamentais estão na forma como o aplicativo é executado pelo ambiente e localmente, acessa serviços externos e é escalonado. Consulte também a página sobre como escolher um ambiente para um resumo geral das diferenças.

Execução do aplicativo

No ambiente padrão, o aplicativo é executado em uma instância leve dentro de um sandbox. Esse sandbox restringe o que o aplicativo pode fazer. Por exemplo, o aplicativo não consegue gravar em disco ou usar bibliotecas binárias que não estão incluídas na lista de permissões. O ambiente padrão também limita a quantidade de opções de CPU e memória disponíveis para o aplicativo. Devido a essas restrições, a maioria dos aplicativos padrão do App Engine tendem a ser aplicativos da Web sem estado, que respondem rapidamente às solicitações HTTP.

Por outro lado, o ambiente flexível executa o aplicativo em contêineres Docker nas máquinas virtuais (VMs, na sigla em inglês) do Google Compute Engine, que têm menos restrições. Por exemplo, use qualquer linguagem de programação que preferir, grave em disco, use qualquer biblioteca que desejar e, até mesmo, execute vários processos. O ambiente flexível também permite escolher qualquer tipo de máquina do Compute Engine para as instâncias, a fim de que o aplicativo tenha acesso a mais recursos de memória e CPU.

Como acessar serviços externos

No ambiente padrão, normalmente, o aplicativo acessa serviços, como o Cloud Datastore, por meio das google.appengine APIs integradas. No entanto, no ambiente flexível, essas APIs não estão mais disponíveis. Em vez disso, use as bibliotecas de cliente do Google Cloud. Essas bibliotecas funcionam em todos os tipos de ambiente, o que significa que o aplicativo será mais portátil. Os aplicativos executados no ambiente flexível, em geral, também são executáveis no Google Kubernetes Engine ou no Compute Engine se necessário, sem grandes modificações.

Desenvolvimento local

No ambiente padrão, normalmente o aplicativo é executado localmente usando o SDK do App Engine. Esse SDK é responsável pela execução do aplicativo e emula os serviços do App Engine. No ambiente flexível, o SDK não é usado para executar aplicativos. Em vez disso, os aplicativos criados para o ambiente flexível devem ser escritos como aplicativos da Web padrão que podem ser executados em qualquer lugar. Como mencionado, o ambiente flexível apenas executa o aplicativo em um contêiner Docker. Isso significa que, para testar o aplicativo localmente, basta executá-lo diretamente. Por exemplo, para executar um aplicativo Python usando o Django, basta executar python manage.py runserver.

Outra diferença fundamental é que os aplicativos do ambiente flexível em execução localmente usam os serviços reais do Cloud Platform, como o Cloud Datastore. Use um projeto diferente para testar localmente. Quando houver disponibilidade, use emuladores.

Características do escalonamento

Ambos os ambientes usam a infraestrutura de escalonamento automático do App Engine. No entanto, a maneira como cada um deles realiza esse escalonamento é diferente. O ambiente padrão pode escalonar de zero a milhares de instâncias muito rapidamente. Em contrapartida, é necessário que o ambiente flexível tenha pelo menos uma instância do aplicativo em execução. Além disso, ele pode levar mais tempo para ser escalonado verticalmente em resposta ao tráfego.

No ambiente padrão, é usado um algoritmo de escalonamento automático personalizado. Já o ambiente flexível usa o autoescalador do Compute Engine. O ambiente flexível não é compatível com todas as opções de escalonamento automático disponíveis para o Compute Engine. Os desenvolvedores precisam testar o funcionamento do aplicativo sob uma série de condições. Por exemplo, verifique a resposta do escalonamento automático quando um aplicativo vinculado à CPU se tornar vinculado à E/S durante períodos em que as chamadas para serviços remotos tiverem latência elevada.

Verificações de integridade

No ambiente padrão, não usamos verificações de integridade para determinar se é necessário ou não enviar tráfego para uma instância. Já no ambiente flexível, os desenvolvedores de aplicativos programam os próprios gerenciadores de verificação de integridade que serão usados pelo balanceador de carga. Isso é para determinar o envio ou não do tráfego para uma instância, e se é preciso ou não ter recuperação automática. Os desenvolvedores precisam ter cuidado ao adicionar lógica às verificações de integridade. Por exemplo, se a verificação de integridade fizer uma chamada para um serviço externo, uma falha temporária nesse serviço transformará todas as instâncias em não íntegras, possivelmente levando a uma falha em cascata.

Como descartar solicitações em caso de sobrecarga

Os aplicativos eliminam solicitações quando estão sobrecarregados, como parte de uma estratégia para evitar falhas em cascata. Esse recurso é incorporado à camada de roteamento de tráfego no ambiente padrão. Recomendamos que os desenvolvedores de aplicativos QPS com picos muito altos no ambiente flexível criem esse recurso para reduzir o tráfego de sobrecarga nos aplicativos, limitando o número de solicitações simultâneas.

Verifique se o aplicativo do ambiente flexível não é suscetível a esse tipo de falha. Basta criar uma versão que limite o número máximo de instâncias. Depois, aumente constantemente o tráfego até que as solicitações sejam descartadas. Garanta que seu aplicativo não esteja com falhas nas verificações de integridade durante a sobrecarga.

Tamanhos de instâncias

As instâncias de ambiente flexíveis têm limites de CPU e memória mais altos do que é possível com instâncias de ambiente padrão. Com isso, as instâncias flexíveis executam aplicativos com mais memória e uso intensivo da CPU. No entanto, isso aumenta a probabilidade de bugs de simultaneidade, devido ao aumento de threads em uma única instância.

Os desenvolvedores podem usar o SSH em uma instância de ambiente flexível e receber um despejo de thread para solucionar esse tipo de problema.

Tempo limite máximo da solicitação

O ambiente padrão aplica um prazo final de 60 segundos para solicitação em versões que usam o escalonamento automático. Como o ambiente flexível não impõe esse prazo, os programadores de aplicativos precisam ter o cuidado de garantir que todas as chamadas para serviços externos especifiquem um tempo limite. Isso evitará solicitações pendentes indefinidamente e, no final, o uso de todos os threads no servidor da Web.

Os desenvolvedores de aplicativos podem implementar o próprio filtro de servlet para eliminar solicitações que demoram mais de 60 segundos no ambiente flexível. É importante processar a limpeza corretamente ao eliminar um thread de solicitação para não deixar o aplicativo em um estado inconsistente.

Migração de tráfego

O ambiente padrão fornece um recurso de migração de tráfego que move gradualmente o tráfego a uma nova versão para minimizar os picos de latência. Consulte os documentos sobre migração de tráfego para saber como evitar um pico de latência ao mudar o tráfego para uma nova versão.

Falhas de zona única

Os aplicativos de ambiente padrão são de hospedagem única. Isso significa que todas as instâncias do aplicativo residem em uma única zona de disponibilidade. No caso de uma falha nessa zona, novas instâncias serão iniciadas pelo aplicativo em uma zona diferente na mesma região, e o balanceador de carga direcionará o tráfego para as novas instâncias. Você verá um pico de latência devido a solicitações de carregamento, bem como um flush do Memcache.

Os aplicativos de ambiente flexível usam Grupos de instâncias regionais gerenciadas. Isso significa que as instâncias são distribuídas entre várias zonas de disponibilidade dentro de uma região. Em caso de falha de uma zona, o balanceador de carga interrompe o tráfego de roteamento para essa zona. Se tiver configurado o escalonamento automático para executar suas instâncias da maneira mais intensa possível, você verá um breve período de sobrecarga antes que o escalonamento automático crie mais instâncias.

Comparações de custo

Muitos fatores estão incluídos em uma comparação de custos entre cargas de trabalho executadas em ambientes padrão e flexíveis. São eles:

  • o preço pago por MCycle;
  • os recursos da plataforma de CPU, que afetam o trabalho a ser realizado por MCycle;
  • a intensidade com que você executa instâncias em cada plataforma;
  • o custo das implantações, que variam em cada plataforma e são importantes quando você usa implantação contínua no aplicativo;
  • a sobrecarga do ambiente de execução.

É preciso realizar testes para determinar o custo da carga de trabalho em cada plataforma. Em um ambiente flexível, use o QPS por núcleo como proxy para garantir a eficiência dos custos do seu aplicativo na execução de testes e determinar se uma alteração tem impacto no preço. No ambiente padrão, não há um mecanismo para receber métricas em tempo real sobre a eficiência de custos do aplicativo. É preciso fazer uma alteração e aguardar a conclusão do ciclo de faturamento diário.

Microsserviços

A autenticação segura entre aplicativos é permitida no ambiente padrão com o uso do cabeçalho de solicitação X-Appengine-Inbound-Appid. Já o ambiente flexível não tem esse recurso. A abordagem recomendada para realizar a autenticação segura entre aplicativos é usar o OAuth.

Implantação

As implantações no ambiente padrão geralmente são mais rápidas que no ambiente flexível. É mais rápido escalonar verticalmente uma versão atual em um ambiente flexível do que implantar uma nova versão. Isso acontece porque a programação de rede de uma nova versão geralmente é a parte mais importante da implantação de um ambiente flexível. Uma estratégia para realizar reversões rápidas em ambientes flexíveis é manter uma versão válida reduzida a uma única instância. Faça o escalonamento vertical dessa versão e roteie todo o tráfego usando a divisão de tráfego.

Quando usar o ambiente flexível

O ambiente flexível foi criado como um complemento do ambiente padrão. Se você já tem um aplicativo em execução no ambiente padrão, em geral não é necessário migrá-lo totalmente para o ambiente flexível. Em vez disso, identifique os componentes do aplicativo que exigem mais recursos de CPU e RAM, bibliotecas ou programas especializados de terceiros ou, ainda, que precisam executar ações não permitidas no ambiente padrão. Em seguida, crie pequenos serviços do App Engine que usam o ambiente flexível para processar esses componentes. O serviço atual em execução no ambiente padrão pode chamar outros serviços usando HTTP, Cloud Tasks ou Cloud Pub/Sub.

Por exemplo, se você tiver um aplicativo da Web em execução no ambiente padrão e quiser adicionar um novo recurso para converter arquivos em PDF, poderá escrever um microsserviço separado que será executado no ambiente flexível para apenas processar a conversão em PDF. Esse microsserviço pode ser um programa simples que consiste em apenas um ou dois gerenciadores de solicitações. Ele poderá instalar e usar qualquer programa Linux disponível para ajudar na conversão, como o unoconv.

O aplicativo principal permanece no ambiente padrão e chama esse microsserviço diretamente por HTTP. Caso você perceba que a conversão levará muito tempo, o aplicativo usará como alternativa o Cloud Tasks (Beta) ou o Cloud Pub/Sub para enfileirar as solicitações.

A seguir

Faça a correlação dos serviços usados pelo aplicativo no ambiente padrão com os serviços análogos no ambiente flexível.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Ambiente flexível do App Engine para Go