Práticas recomendadas para redes do App Engine

Nesta página, descrevemos as práticas recomendadas para configurar opções de rede em recursos do App Engine. Recomendamos que você analise todas as seções desta página para entender as opções de rede compatíveis com o App Engine e as implicações delas.

Práticas recomendadas:

Gerenciamento de endereços IP.
Monitorar o uso de endereços IP.
Use endereços IP não RFC 1918.
Use sub-redes IPv4 e IPv6 (pilha dupla).
Use o pool de conexões e reutilize as conexões.
Use ambientes de execução compatíveis.
Capacidade de processamento externa mais rápida para a Internet.
Capacidade de processamento interna mais rápida para uma API do Google.

Gerenciamento de IP

É preciso gerenciar os endereços IP porque cada instância do serviço do App Engine consome endereços IP da sub-rede. Use as seguintes estratégias para gerenciar seus endereços IP:

  • Alocação de IP alternativa: aloque intervalos particulares padrão ou intervalos de IP alternativos para reduzir o esgotamento de endereços IP. Consulte Estratégias de esgotamento de endereços IP.

  • Dimensionamento da sub-rede: verifique se o intervalo de endereços IPv4 da sub-rede é /26 ou maior para fornecer endereços IP suficientes para o escalonamento.

  • Superprovisionar endereços IP: recomendamos superprovisionar o número de endereços IP disponíveis na sub-rede para evitar o esgotamento. Assim como em outros serviços do App Engine, geralmente é necessário usar quatro vezes mais endereços IP (duas vezes para o estado estável e mais duas vezes durante a implantação) do que o número de instâncias em execução para facilitar o escalonamento e as atualizações.

Monitorar o uso de endereços IP

Se você estiver usando a saída de VPC direta, verifique se há endereços IP suficientes alocados para sua sub-rede. O número de endereços IP usados depende do número de instâncias em que as cargas de trabalho são executadas. Por isso, recomendamos monitorar o uso de endereços IP. Verifique se o uso de IP ao longo do tempo permanece dentro dos limites aceitos pela sub-rede.

Para estimar o uso de endereços IP:

  1. No console do Google Cloud , acesse a página do Metrics Explorer:

    Acessar o Metrics Explorer

  2. Procure o número de instâncias no projeto usando o tipo de métrica appengine.googleapis.com/system/instance_count. Essa métrica conta todas as instâncias do App Engine no projeto. Para versões configuradas com saída de VPC direta, filtre pelo rótulo module_id, que identifica o serviço, ou pelo rótulo version_id. O Cloud Monitoring permite visualizar o valor dessa métrica ao longo do tempo.

  3. Multiplique o valor da métrica de contagem de instâncias por 2 para estimar o número de endereços IP em uso.

Estratégias de esgotamento de endereços IP

Ter um grande número de cargas de trabalho do App Engine pode causar desafios de esgotamento de IP ao usar o espaço de endereço IP privado RFC 1918 com saída de VPC direta. As estratégias a seguir podem ajudar você a gerenciar o esgotamento de endereços IP usando intervalos de endereços IP alternativos.

Usar endereços IPv4 não RFC 1918

Além dos intervalos de endereços IPv4 RFC 1918, o App Engine também é compatível com os intervalos RFC 6598 e Classe E/RFC 5735. Todos os serviços e recursos doGoogle Cloud funcionam com esses intervalos que não são RFC 1918, incluindo redes VPC, Cloud Load Balancing e Private Service Connect.

Para melhor compatibilidade, recomendamos começar com o intervalo RFC 6598 (100.64.0.0/10). Se você já usa esse intervalo em outro lugar, considere a classe E/RFC 5735 (240.0.0.0/4). A classe E é um espaço enorme com mais de 268 milhões de endereços IP disponíveis, então ela vai dar suporte ao seu crescimento por muito tempo. No entanto, a classe E tem algumas limitações. Por exemplo, ele não é compatível com o Windows e com alguns hardwares locais. Leia sobre como usar o espaço de endereços IPv4 de classe E para mitigar problemas de esgotamento de IPv4 no GKE.

Usar o Cloud NAT ou o Private Service Connect

Se a carga de trabalho do App Engine estiver em um intervalo não RFC 1918 e precisar alcançar um destino local que aceite apenas RFC 1918, escolha uma das seguintes soluções:

  • Use o Hybrid NAT para realizar a conversão de endereços e a saída por um pequeno intervalo RFC 1918.
  • Exponha o serviço local como um serviço híbrido do Private Service Connect.

Usar sub-redes IPv4 e IPv6 (pilha dupla)

Embora isso não reduza o esgotamento do IPv4, considere mover seus apps para o IPv6. Para evitar problemas de esgotamento de IPv4 no futuro, configure recursos de pilha dupla.

Estratégias de redução de esgotamento de portas

A seção a seguir descreve estratégias para reduzir o esgotamento de portas com o App Engine.

Usar o pool de conexões e reutilizar conexões

Ao enviar um grande número de solicitações do seu aplicativo do App Engine para um único endereço IP de destino, use o pool de conexões para manter e reutilizar conexões com o destino. Altas taxas de conexão com um único endereço IP podem esgotar as portas de saída e causar erros de conexão recusada.

Estratégias de desempenho e capacidade de processamento

Nesta seção, abordamos opções escalonáveis para melhorar o desempenho e a capacidade de processamento da rede em relação à Internet e aos Serviços do Google.

Usar ambientes de execução compatíveis

A saída de VPC direta só é compatível com ambientes de execução padrão de segunda geração. Os ambientes de execução compatíveis executam implementações de linguagem padrão, oferecem suporte a integrações de bibliotecas modernas e têm um desempenho de rede mais rápido e robusto.

Usar a saída de VPC direta para aumentar a capacidade de processamento da saída de rede

Para ter uma capacidade de processamento mais rápida nas conexões de saída de rede, use a saída de VPC direta a fim de rotear o tráfego pela rede VPC.

Exemplo 1: tráfego externo para a Internet

Ao enviar tráfego externo para a Internet pública, defina o campo vpc_egress como all-traffic no arquivo app.yaml para rotear todo o tráfego pela rede VPC. Com essa abordagem, você precisa configurar o Cloud NAT para acessar a Internet pública.

Para configurar o Cloud NAT para o serviço do App Engine, consulte Configurar um endereço IP de saída estático. Para as configurações do gateway do Cloud NAT a serem usadas com a saída de VPC direta para Public NAT ou Private NAT, consulte Interações de saída de VPC direta do Cloud NAT.

Exemplo 2: tráfego interno para uma API do Google

Ao usar a saída direta de VPC para enviar tráfego a uma API do Google, como a API Cloud Storage, escolha uma das seguintes opções:

  • Especifique private-ranges-only (padrão) com Acesso privado do Google:
    1. Defina vpc_egress: private-ranges-only no arquivo app.yaml.
    2. Ative o Acesso privado do Google.
    3. Configure o DNS para o Acesso privado do Google. Verifique se o domínio de destino, como storage.googleapis.com, está mapeado para um dos seguintes intervalos de endereços IP internos:
      • 199.36.153.8/30
      • 199.36.153.4/30
  • Especifique all-traffic com o Acesso privado do Google:
    1. Defina vpc_egress: all-traffic no arquivo app.yaml.
    2. Ative o Acesso privado do Google.

Usar a configuração de MTU padrão para o App Engine

Não mude a configuração da unidade máxima de transmissão (MTU) de uma rede VPC ao usá-la com o App Engine. Use a MTU padrão de 1.460 bytes.

Considerações sobre o custo

Ao configurar as opções de rede para seus recursos, considere o seguinte:

  • Coloque seus recursos no mesmo local: tente implantar os recursos do App Engine na mesma região dos bancos de dados de back-end, como Cloud SQL, Firestore e buckets do Cloud Storage. A transferência de dados entre recursos do Google Cloud na mesma região não tem custo financeiro.
  • Mudar para a saída VPC direta: se você estiver roteando o tráfego com segurança para recursos internos da rede VPC, considere mudar para a saída VPC direta dos conectores de acesso VPC sem servidor. A saída de VPC direta não gera cobranças de computação de referência, eliminando a sobrecarga de computação de referência e os custos de inatividade associados às instâncias do conector.
  • Use o Cloud CDN: descarregue recursos estáticos e conteúdo armazenável em cache colocando o Cloud CDN na frente dos recursos do App Engine. A exibição de dados da borda é significativamente mais barata do que pagar pela saída de dados para a internet padrão diretamente do App Engine. Não é possível ativar o Cloud CDN diretamente no URL appspot.com padrão. Em vez disso, encaminhe as solicitações por um balanceador de carga de aplicativo externo que tenha um back-end de grupo de endpoints de rede (NEG) sem servidor. Para mais informações, consulte Configurar um balanceador de carga de aplicativo externo global com o App Engine.
  • Monitorar a saída de dados para a Internet: o tráfego de saída que cruza os limites da região ou vai para a Internet pública gera cobranças padrão. Concentre seus esforços de monitoramento no tráfego de saída que cruza os limites da região.

Consulte os preços do App Engine ou estime os custos com a calculadora de preços para mais informações.

A seguir