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, la zona de pruebas solo permite que la app use un conjunto limitado de bibliotecas binarias y no puede escribir en el disco. El entorno estándar también limita las opciones de CPU y memoria disponibles para tu aplicación. Debido a estas restricciones, la mayoría de las aplicaciones para el entorno estándar de App Engine tienden a ser aplicaciones web sin estado que responden con rapidez 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 para que la aplicación tenga acceso a más memoria y CPU.
Accede a servicios externos
La aplicación, por lo general, accede a servicios como Datastore en el entorno estándar a través de las API de google.appengine integradas. 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 suelen poder ejecutarse en Google Kubernetes Engine o en Compute Engine sin cambiar demasiado.
Desarrollo local
Por lo general, ejecutas la aplicación de manera local en el entorno estándar a través del 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ó con anterioridad, el entorno flexible solo ejecuta la aplicación en un contenedor de Docker. Esto significa que, para probarla de manera local, ejecuta la aplicación de forma directa. Por ejemplo, para ejecutar una aplicación de Python a través de Django, solo debes ejecutar python manage.py runserver.
Otra diferencia clave es que las aplicaciones del entorno flexible que se ejecutan de manera local usan servicios de Cloud Platform reales, como Datastore. Usa un proyecto independiente para realizar pruebas locales y, cuando estén disponibles, usa emuladores.
Características del escalamiento
Si bien ambos entornos usan la infraestructura de ajuste de escala 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 tomarle más tiempo escalar horizontalmente 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 comprobar 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 comprobar que tu aplicación de entorno flexible no sea susceptible a este tipo de errores a través de 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.
Para Java, las apps de Java que usan el entorno de ejecución de Jetty pueden establecer el Filtro de Calidad de servicio para implementar la reducción de sobrecarga. Puedes establecer el número máximo de solicitudes simultáneas que entregan las aplicaciones y el período en el que las solicitudes estarán en cola con esta característica.
Tamaños de la instancia
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 simultáneos 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.
Por ejemplo, si usas el entorno de ejecución de Java, puedes ejecutar lo siguiente:
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Tiempo de espera máximo de una solicitud
Mientras que el tiempo de espera de la solicitud del entorno estándar varía según el tipo de escalamiento seleccionado, el entorno flexible siempre impone un tiempo de espera de 60 minutos. Para evitar que las solicitudes estén en espera durante los 60 minutos completos, con la posibilidad de que usen todos los subprocesos en el servidor web, haz lo siguiente:
Cuando realices llamadas a servicios externos, especifica un tiempo de espera.
Implementa un filtro de servlet para detener las solicitudes que demoran una cantidad de tiempo inaceptable, como 60 segundos. Asegúrate de que tu app pueda volver a un estado coherente después de que el filtro detenga una solicitud.
Administración de subprocesos
Los entornos de ejecución estándar de Java anteriores a Java 8 solo podían usar subprocesos creados con el SDK del entorno estándar de App Engine. Los desarrolladores que transfieren una aplicación desde un entorno de ejecución estándar de Java de primera generación a un entorno flexible deben empzar a usar bibliotecas de subprocesos nativas. Puede que las aplicaciones que requieren una gran cantidad de subprocesos se ejecuten de forma más eficiente con grupos de subprocesos que con la creación explícita de subprocesos.
Migración del 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 empieza 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 la 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 usar 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 a través del encabezado de la solicitud X-Appengine-Inbound-Appid. El entorno flexible no posee esta característica. Se recomienda usar OAuth para la autenticación segura entre aplicaciones.
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 verticalmente 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 en general 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 verticalmente 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 usen el entorno flexible para controlarlas. Tu servicio existente que se ejecuta en el entorno estándar puede llamar a los otros servicios a través de HTTP, Cloud Tasks o Cloud Pub/Sub.
Por ejemplo, si ya tienes una aplicación web existente que se ejecuta en el entorno estándar y quieres agregar una función nueva que convierta archivos en PDF, puedes escribir un microservicio independiente que se ejecute en el entorno flexible y que solo controle la conversión a PDF. Este microservicio puede ser un programa simple que consista en solo uno o dos controladores de solicitudes. Este microservicio puede instalar y usar 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 a través de HTTP. Si prevés que la conversión llevará mucho tiempo, la aplicación puede crear colas de solicitudes con Cloud Tasks o Pub/Sub.
¿Qué sigue?
Mapea los servicios que usa la app en el entorno estándar a sus equivalentes en el entorno flexible.