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 as ações do aplicativo. Por exemplo, o sandbox só permite que seu app use um conjunto limitado de bibliotecas binárias e não permite que ele grave em disco. O ambiente padrão também limita as 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 app em contêineres Docker nas máquinas virtuais (VMs) 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, o app geralmente acessa serviços como o Datastore por meio das APIs integradas do google.appengine. 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 em execução no ambiente flexível, em geral, podem ser executados no Google Kubernetes Engine ou no Compute Engine, quando necessário, sem grandes modificações.
Desenvolvimento local
No ambiente padrão, normalmente se executa o aplicativo localmente usando o SDK do App Engine. O SDK manipula a 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 precisam 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 app Python usando o Django, basta executar python manage.py runserver.
Outra diferença fundamental é que os apps do ambiente flexível em execução localmente usam os serviços reais do Cloud Platform, como o Datastore. Use um projeto diferente para testar localmente. Quando disponível, 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 para cada versão ativa. 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. Verifique se o aplicativo não apresenta falhas nas verificações de integridade durante a sobrecarga.
Os apps Java que usam o ambiente de execução do Jetty podem configurar o Filtro de qualidade de serviço (em inglês) para implementar a sobrecarga de queda. Com esse recurso, é possível configurar o número máximo de solicitações simultâneas atendidas pelos aplicativos e o período de tempo em que elas serão enfileiradas.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.
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Tempo limite máximo da solicitação
Embora o tempo limite da solicitação do ambiente padrão varie de acordo com o tipo de escalonamento selecionado, o ambiente flexível sempre impõe um tempo limite de 60 minutos. Para evitar que as solicitações fiquem pendentes durante os 60 minutos e acabem usando todas as linhas de execução no servidor da Web:
Ao fazer chamadas para serviços externos, especifique um tempo limite.
Implemente um filtro de servlet para interromper solicitações que levam um tempo muito longo, como 60 segundos. Verifique se o app pode retornar a um estado consistente depois que o filtro interromper uma solicitação.
Gerenciamento de threads
Antes do Java 8, os ambientes de execução em Java do ambiente padrão usavam apenas linhas de execução criadas utilizando o SDK do ambiente padrão do App Engine. Os desenvolvedores que transportam um app de um ambiente de execução padrão em Java de primeira geração para um ambiente flexível precisam alternar para o uso de bibliotecas de linhas de execução nativas. A execução de apps que exigem um número muito grande de threads é mais eficiente com os pools de threads do que com a criação explícita de threads.
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 pode diferir em cada plataforma e ser significativo se você estiver usando a Implantação Contínua para seu 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
O ambiente padrão permite autenticação segura entre aplicativos usando o 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 atual em execução no ambiente padrão e quiser adicionar um novo recurso para converter arquivos em PDFs, poderá criar um microsserviço separado que seja executado no ambiente flexível para manipular a conversão para PDF. Este microsserviço pode ser um programa simples que consiste em apenas um ou dois manipuladores de solicitação. Ele poderá instalar e usar qualquer programa Linux disponível para ajudar na conversão, como o unoconv.
O app 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 app usará como alternativa o Cloud Tasks ou o Cloud Pub/Sub para enfileirar as solicitações.