Prácticas recomendadas para las herramientas de redes de App Engine

En esta página, se describen las prácticas recomendadas para configurar las opciones de herramientas de redes de los recursos de App Engine. Te recomendamos que revises todas las secciones de esta página para comprender las opciones de herramientas de redes que admite App Engine y sus implicaciones.

Recomendaciones:

Administración de direcciones IP.
Supervisa el uso de direcciones IP.
Usar direcciones IP que no sean RFC 1918.
Usa subredes IPv4 e IPv6 (pila doble).
Usa la agrupación de conexiones y reutiliza las conexiones.
Usa entornos de ejecución compatibles.
Capacidad de procesamiento externa más rápida a Internet.
Capacidad de procesamiento interno más rápida para una API de Google.

Administración de IP

Debes administrar tus direcciones IP porque cada instancia de tu servicio de App Engine consume direcciones IP de tu subred. Usa las siguientes estrategias para administrar tus direcciones IP:

  • Asignación de IP alternativa: Asigna rangos privados estándar o rangos de IP alternativos para mitigar el agotamiento de direcciones IP. Consulta Estrategias para el agotamiento de direcciones IP.

  • Tamaño de la subred: Asegúrate de que el rango de direcciones IPv4 de tu subred sea /26 o más grande para proporcionar suficientes direcciones IP para el escalamiento.

  • Aprovisiona direcciones IP en exceso: Te recomendamos que aprovisiones en exceso la cantidad de direcciones IP disponibles en tu subred para evitar que se agoten. Al igual que con otros servicios de App Engine, por lo general, debes usar cuatro veces más direcciones IP (2 veces para el estado estable y 2 veces más durante la implementación) que la cantidad de instancias en ejecución para facilitar el escalamiento y las actualizaciones sin problemas.

Supervisa el uso de direcciones IP

Si usas la salida de VPC directa, asegúrate de tener suficientes direcciones IP asignadas para tu subred. La cantidad de direcciones IP que usas depende de la cantidad de instancias que ejecutan tus cargas de trabajo, por lo que te recomendamos que supervises el uso de direcciones IP. Asegúrate de que el uso de IP a lo largo del tiempo se mantenga dentro de los límites que admite la subred.

Para estimar el uso de direcciones IP, sigue estos pasos:

  1. En la consola de Google Cloud , accede a la página Explorador de métricas:

    Ir al Explorador de métricas

  2. Busca la cantidad de instancias en tu proyecto con el tipo de métrica appengine.googleapis.com/system/instance_count. Esta métrica cuenta todas las instancias de App Engine en todo el proyecto. Para las versiones configuradas con la salida de VPC directa, filtra por la etiqueta module_id, que identifica el servicio, o por la etiqueta version_id. Cloud Monitoring te permite ver el valor de esta métrica a lo largo del tiempo.

  3. Multiplica el valor de la métrica de recuento de instancias por 2 para obtener una estimación de la cantidad de direcciones IP en uso.

Estrategias para el agotamiento de direcciones IP

Tener una gran cantidad de cargas de trabajo de App Engine puede causar problemas de agotamiento de IP cuando se usa el espacio de direcciones IP privadas RFC 1918 con la salida de VPC directa. Las siguientes estrategias pueden ayudarte a administrar el agotamiento de direcciones IP con rangos de direcciones IP alternativos.

Usa direcciones IPv4 que no sean RFC 1918

Además de los rangos de direcciones IPv4 RFC 1918, App Engine también admite los rangos RFC 6598 y clase E/RFC 5735. Todos los servicios y las funciones deGoogle Cloud funcionan con estos rangos que no son RFC 1918, incluidas las redes de VPC, Cloud Load Balancing y Private Service Connect.

Para obtener la mejor compatibilidad, te recomendamos que comiences con el rango RFC 6598 (100.64.0.0/10). Si ya usas este rango en otro lugar, considera usar la clase E/RFC 5735 (240.0.0.0/4). La clase E es un espacio enorme con más de 268 millones de direcciones IP disponibles, por lo que admitirá tu crecimiento durante mucho tiempo. Sin embargo, la clase E tiene algunas limitaciones. Por ejemplo, no es compatible con Windows ni con algunos tipos de hardware local. Lee sobre cómo aprovechar el espacio de direcciones IPv4 de clase E para mitigar los problemas de agotamiento de IPv4 en GKE.

Usa Cloud NAT o Private Service Connect

Si tu carga de trabajo de App Engine está en un rango que no es RFC 1918 y necesita llegar a un destino local que solo acepte RFC 1918, elige una de las siguientes soluciones:

  • Usa Hybrid NAT para realizar la traducción de direcciones y la salida a través de un rango pequeño de RFC 1918.
  • Expón el servicio local como un servicio híbrido de Private Service Connect.

Usa subredes IPv4 e IPv6 (pila doble)

Aunque no reducirá el agotamiento de IPv4, considera mover tus apps a IPv6. Para evitar problemas de agotamiento de IPv4 en el futuro, configura recursos de pila doble.

Estrategias de reducción del agotamiento de puertos

En la siguiente sección, se describen las estrategias para reducir el agotamiento de puertos con App Engine.

Usa la agrupación de conexiones y reutilízalas

Cuando envíes una gran cantidad de solicitudes desde tu app de App Engine a una sola dirección IP de destino, usa la agrupación de conexiones para mantener y reutilizar las conexiones al destino. Las tasas de conexión altas a una sola dirección IP pueden agotar los puertos de salida y provocar errores de conexión rechazada.

Estrategias de rendimiento y capacidad de procesamiento

En esta sección, se abordan las opciones escalables para mejorar el rendimiento y la capacidad de procesamiento de la red hacia Internet y los servicios de Google.

Usa entornos de ejecución compatibles

La salida de VPC directa solo se admite en los entornos de ejecución de segunda generación estándar. Los entornos de ejecución compatibles ejecutan implementaciones de lenguaje estándar, admiten integraciones de bibliotecas modernas y ofrecen un rendimiento de red más rápido y sólido.

Usa la salida de VPC directa para lograr una capacidad de procesamiento de salida de red más rápida

Para lograr una capacidad de procesamiento más rápida en las conexiones de salida de red, usa la salida de VPC directa para enrutar el tráfico a través de tu red de VPC.

Ejemplo 1: Tráfico externo a Internet

Si envías tráfico externo a la Internet pública, configura el campo vpc_egress como all-traffic en tu archivo app.yaml para enrutar todo el tráfico a través de la red de VPC. Con este enfoque, debes configurar Cloud NAT para llegar a la Internet pública.

Para configurar Cloud NAT para tu servicio de App Engine, consulta Configura una dirección IP saliente estática. Para conocer la configuración de la puerta de enlace de Cloud NAT que se usará con la salida de VPC directa para NAT pública o NAT privada, consulta Interacciones de salida de VPC directa de Cloud NAT.

Ejemplo 2: Tráfico interno a una API de Google

Si usas la salida de VPC directa para enviar tráfico a una API de Google, como Cloud Storage, elige una de las siguientes opciones:

  • Especifica private-ranges-only (predeterminado) con el Acceso privado a Google:
    1. Establece vpc_egress: private-ranges-only en tu archivo app.yaml.
    2. Habilita el Acceso privado a Google.
    3. Configura DNS para el Acceso privado a Google. Asegúrate de que tu dominio de destino (como storage.googleapis.com) se asigne a uno de los siguientes rangos de direcciones IP internas:
      • 199.36.153.8/30
      • 199.36.153.4/30
  • Especifica all-traffic con el Acceso privado a Google:
    1. Establece vpc_egress: all-traffic en tu archivo app.yaml.
    2. Habilita el Acceso privado a Google.

Usa el parámetro de configuración de MTU predeterminado para App Engine

No cambies la configuración de la unidad de transmisión máxima (MTU) de una red de VPC cuando la uses con App Engine. En su lugar, usa la MTU predeterminada de 1,460 bytes.

Consideraciones de costo

Cuando configures las opciones de red para tus recursos, ten en cuenta lo siguiente:

  • Coloca tus recursos en la misma ubicación: Intenta implementar tus recursos de App Engine en la misma región que tus bases de datos de backend, como Cloud SQL, Firestore y los buckets de Cloud Storage. La transferencia de datos entre recursos de Google Cloud dentro de la misma región es gratuita.
  • Cambia a la salida de VPC directa: Si enrutas el tráfico de forma segura a recursos internos de la red de VPC, considera cambiar a la salida de VPC directa desde los conectores de Acceso a VPC sin servidores. La salida de VPC directa no genera cargos de procesamiento de referencia, lo que elimina la sobrecarga de procesamiento de referencia y los costos de inactividad asociados con las instancias de conector.
  • Usa Cloud CDN: Descarga recursos estáticos y contenido que se puede almacenar en caché colocando Cloud CDN frente a tus recursos de App Engine. La entrega de datos desde el perímetro es mucho más económica que pagar por la salida estándar de Internet directamente desde App Engine. No puedes habilitar Cloud CDN directamente en la URL predeterminada de appspot.com. En su lugar, enruta las solicitudes a través de un balanceador de cargas de aplicaciones externo que tenga un backend de grupo de extremos de red (NEG) sin servidores. Para obtener más información, consulta Configura un balanceador de cargas de aplicaciones externo global con App Engine.
  • Supervisa la salida de Internet: El tráfico saliente que cruza los límites de la región o va a la Internet pública genera cargos estándar. Enfoca tus esfuerzos de supervisión en el tráfico saliente que cruza los límites de la región.

Revisa los precios de App Engine o estima los costos con la calculadora de precios para obtener más información.

¿Qué sigue?