Entorno de App Engine Flexible para usuarios del entorno estándar de App Engine

En esta guía, se proporciona una introducción al entorno flexible a quienes están familiarizados con el entorno estándar. Se explican las similitudes y diferencias clave y se proporcionan recomendaciones generales sobre arquitectura para las aplicaciones que usan ambos entornos.

Para una asignación de servicios disponible en el entorno estándar a sus equivalentes en el entorno flexible, consulta Servicios de migración del entorno estándar al flexible.

Similitudes y diferencias clave

Ambos entornos te proporcionan la infraestructura de implementación, entrega y escalamiento de App Engine. Las diferencias clave se basan en cómo el entorno ejecuta la aplicación, cómo esta accede a servicios externos, cómo la ejecutas de manera local y cómo se escala. También puedes consultar Elige un entorno para obtener un resumen de alto nivel de estas diferencias.

Ejecución de la app

En el entorno estándar, la aplicación se ejecuta en una instancia liviana dentro de una zona de pruebas, Esta zona de pruebas restringe lo que puede hacer tu aplicación. Por ejemplo, tu aplicación no puede escribir en el disco ni usar bibliotecas binarias no incluidas en la lista blanca. El entorno estándar también limita la cantidad de opciones de CPU y memoria disponibles para la aplicación. Debido a estas restricciones, la mayoría de las aplicaciones estándar de App Engine tienden a ser aplicaciones web sin estado que responden rápidamente a las solicitudes HTTP.

Por el contrario, el entorno flexible ejecuta la aplicación en contenedores de Docker en máquinas virtuales (VM) de Google Compute Engine, las cuales tienen menos restricciones. Por ejemplo, te permiten usar el lenguaje de programación y la biblioteca que desees, guardar en el disco y hasta ejecutar varios procesos. El entorno flexible también te permite seleccionar cualquier tipo de máquina de Compute Engine para las instancias a fin de que la aplicación tenga acceso a más memoria y CPU.

Accede a servicios externos

En el entorno estándar, tu aplicación suele acceder a servicios como Datastore a través de las API integradas de google.appengine. Sin embargo, en el entorno flexible, estas API ya no están disponibles. En su lugar, usa las bibliotecas cliente de Google Cloud. Estas funcionan donde sea, lo que significa que la aplicación es más portátil. Si es necesario, las aplicaciones que se ejecutan en el entorno flexible normalmente pueden ejecutarse en Google Kubernetes Engine o en Compute Engine sin cambiar demasiado.

Desarrollo local

En el entorno estándar, normalmente ejecutas la aplicación de forma local con el SDK de App Engine. El SDK controla la ejecución de tu aplicación y emula los servicios de App Engine. En el entorno flexible, ya no se usa el SDK para ejecutar la aplicación. En vez de esto, las aplicaciones para el entorno flexible deben escribirse como aplicaciones web estándar que pueden ejecutarse donde sea. Como se mencionó anteriormente, el entorno flexible solo ejecuta la aplicación en un contenedor de Docker. Esto significa que, para probarla de manera local, solo tienes que ejecutarla de manera directa. Por ejemplo, para ejecutar una aplicación de Python con Django, solo debes ejecutar python manage.py runserver.

Otra diferencia clave es que las aplicaciones de entorno flexible que se ejecutan de forma local usan servicios de Cloud Platform reales, como Datastore. Usa un proyecto aparte para probarlo de manera local y, cuando estén disponibles, usa los emuladores.

Características del escalamiento

Si bien ambos entornos usan la infraestructura de escalamiento automático de App Engine, la manera en que escalan es muy distinta. El entorno estándar puede escalar de cero a miles de instancias con rapidez. Por el contrario, el entorno flexible debe tener al menos una instancia en ejecución para cada versión activa y puede tardar más en escalar verticalmente en respuesta al tráfico.

El entorno estándar usa un algoritmo de ajuste de escala automático personalizado. El entorno flexible usa el escalador automático de Compute Engine. Ten en cuenta que el entorno flexible no es compatible con todas las opciones de ajuste de escala automático disponibles en Compute Engine. Los desarrolladores deben probar el comportamiento de su aplicación bajo ciertas condiciones. Por ejemplo, deberías verificar la respuesta del ajuste de escala automático cuando una aplicación ligada a la CPU se convierte en una ligada a la E/S durante los períodos en que las llamadas a servicios remotos tienen latencia elevada.

Verificaciones de estado

El entorno estándar no usa verificaciones de estado para determinar si debe enviar tráfico a una instancia. El entorno flexible permite que los desarrolladores de aplicaciones escriban los controladores de verificación de estado que usará el balanceador de cargas para determinar si debe enviar tráfico a una instancia o repararse automáticamente. Los desarrolladores deber tener cuidado cuando agreguen lógica a las verificaciones de estado. Por ejemplo, si una de estas llama a un servicio externo, entonces una falla temporal en este podría provocar que todas las instancias estén en mal estado, lo que conllevaría a un error en cascada.

Quitar las solicitudes cuando hay sobrecarga

Las aplicaciones pueden quitar las solicitudes cuando se sobrecargan como estrategia para evitar errores en cascada. Esta capacidad está incorporada en la capa de enrutamiento de tráfico en el entorno estándar. Si desarrollas aplicaciones que tienen QPS muy altas en el entorno flexible, te recomendamos compilar esta función en tus aplicaciones y limitar la cantidad de solicitudes simultáneas para reducir la sobrecarga de tráfico.

Puedes verificar que tu aplicación de entorno flexible no sea susceptible a este tipo de errores mediante la creación de una versión con un límite en el número máximo de instancias. Luego, aumenta el tráfico de manera constante hasta que las solicitudes empiecen a quitarse. Debes asegurarte de que tu aplicación no presente fallas en las verificaciones de estado durante una sobrecarga.

Tamaños de las instancias

Las instancias del entorno flexible pueden tener límites de CPU y memoria mayores que las del entorno estándar. Esto permite que las instancias flexibles puedan ejecutar aplicaciones intensivas de memoria y CPU. Sin embargo, esto puede aumentar la posibilidad de que ocurran errores debido al aumento de hilos en una única instancia.

Los desarrolladores pueden usar conexiones SSH en una instancia del entorno flexible y conseguir reducir los procesos para solucionar este tipo de problemas.

Tiempo de espera máximo de una solicitud

Si bien el entorno estándar impone un tiempo de espera de solicitud, el entorno flexible no impone ese plazo. Para evitar que las solicitudes queden en espera de forma indefinida y eventualmente y se consuman todos los subprocesos en el servidor web:

  • Cuando realices llamadas a servicios externos, especifica un tiempo de espera.

  • Implementa un filtro de servlet para eliminar las solicitudes que tarden un tiempo inaceptablemente largo, como 60 segundos. Asegúrate de que tu app pueda volver a un estado coherente después de que tu filtro elimine una solicitud.

Migración de tráfico

El entorno estándar otorga una característica de migración de tráfico que mueve el tráfico de manera gradual a una versión nueva para minimizar los picos de latencia. Consulta la documentación sobre la migración de tráfico para ver de qué forma puedes asegurarte de evitar picos de latencia cuando cambias el tráfico a una nueva versión.

Fallas en una zona única

Las aplicaciones del entorno estándar tienen un solo host, lo que significa que todas las instancias de la aplicación residen en una zona de disponibilidad única. Si se produce una falla en esa zona, la aplicación comienza nuevas instancias en una zona diferente dentro de la misma región y el balanceador de cargas enruta el tráfico hacia estas nuevas instancias. Verás un pico de latencia debido a la carga de solicitudes y también una limpieza de Memcache.

Las aplicaciones del entorno flexible usan grupos de instancias administrados regionales, lo que significa que las instancias están distribuidas entre múltiples zonas de disponibilidad dentro de una región. Si se produce una falla en una zona única, el balanceador de cargas detiene el envío de tráfico hacia esa zona. Si tienes configurado el ajuste de escala automático para que ejecute tus instancias tan rápido como sea posible, verás un período breve de sobrecarga antes de que el ajuste de escala automático cree más instancias.

Comparaciones de costo

Hay muchos factores involucrados en una comparación de costos entre las cargas de trabajo en ejecución del entorno estándar y las del flexible. Estos incluyen los siguientes:

  • El precio que paga MCycle.
  • Las capacidades de la plataforma de CPU, que afectan el trabajo que MCycle puede realizar.
  • La rapidez con la que puedes ejecutar instancias en cada plataforma.
  • El costo de las implementaciones, que puede variar en cada plataforma, puede ser significativo si usas la implementación continua para tu aplicación.
  • La sobrecarga del entorno de ejecución.

Deberás ejecutar experimentos para determinar el costo de la carga de trabajo en cada plataforma. En el entorno flexible, puedes utilizar QPS por núcleo como proxy y mejorar el costo-beneficio de tu aplicación cuando ejecutas los experimentos para determinar si un cambio tiene algún impacto en los costos. El entorno estándar no proporciona estos mecanismos que te permiten obtener en tiempo real las métricas del costo-beneficio de tu aplicación. Debes hacer un cambio y esperar a que se complete el ciclo de facturación diario.

Microservicios

El entorno estándar permite la autenticación segura entre aplicaciones mediante el encabezado de solicitud X-Appengine-Inbound-Appid. El entorno flexible no posee esta característica. El enfoque que se recomienda para la autenticación segura entre aplicaciones es usar OAuth.

Implementación

Por lo general, las implementaciones en el entorno estándar son más rápidas que en el entorno flexible. Es más rápido escalar una versión existente en el entorno flexible que implementar una versión nueva, ya que la red de programación de versiones nuevas es normalmente la parte más difícil de implementación en el entorno flexible. Una estrategia para realizar una reversión rápida en el entorno flexible es mantener una versión buena reducida a una única instancia. Luego, puedes escalar esta versión y enviar todo el tráfico hacia ella con una división del tráfico.

Cuándo usar el entorno flexible

El entorno flexible está pensado para que sea complementario al entorno estándar. Si ya tienes una aplicación en ejecución en el entorno estándar, por lo general, no se necesita migrar la aplicación entera al entorno flexible. En cambio, identifica las partes de tu aplicación que requieren más CPU, más RAM, una biblioteca o un programa especializado de terceros, o que necesitan realizar acciones que no son posibles en el entorno estándar. Después de identificar estas partes de tu aplicación, crea servicios de App Engine pequeños que utilicen el entorno flexible para controlarlas. Tu servicio existente que se ejecuta en el entorno estándar puede llamar a los otros servicios mediante HTTP, Cloud Tasks o Cloud Pub/Sub.

Por ejemplo, si tienes una aplicación web existente que se ejecuta en el entorno estándar y deseas agregar una función nueva para convertir archivos a PDF, puedes escribir un microservicio independiente que se ejecute en el entorno flexible que solo controla la conversión a PDF. Este microservicio puede ser un programa simple que consta de uno o dos controladores de solicitudes. Asimismo, puede instalar y utilizar cualquier programa de Linux disponible para ayudar en la conversión, como unoconv.

Tu aplicación principal permanece en el entorno estándar y puede llamar a este microservicio de forma directa mediante HTTP. Si prevés que la conversión tardará mucho tiempo, la aplicación puede crear colas de solicitudes con Cloud Tasks o Cloud Pub/Sub.

Qué sigue

Asigna los servicios que usa la aplicación en el entorno estándar a sus equivalentes en el entorno flexible.