Esta guía ofrece una introducción al entorno flexible para los usuarios que ya conocen el entorno estándar. En él se explican las similitudes y las diferencias clave entre los entornos, y también se ofrecen recomendaciones generales de arquitectura para las aplicaciones que usan ambos entornos.
Para ver una asignación de los servicios disponibles en el entorno estándar a sus equivalentes en el entorno flexible, consulta Migrar servicios del entorno estándar al entorno flexible.
Similitudes y diferencias principales
Ambos entornos te proporcionan la infraestructura de implementación, servicio y escalado de App Engine. Las principales diferencias son la forma en que el entorno ejecuta tu aplicación, cómo accede tu aplicación a servicios externos, cómo ejecutas tu aplicación de forma local y cómo se escala tu aplicación. También puedes consultar la sección sobre elegir un entorno para ver un resumen general de estas diferencias.
Ejecución de aplicaciones
En el entorno estándar, tu aplicación se ejecuta en una instancia ligera dentro de un sandbox. Este entorno aislado restringe lo que puede hacer tu aplicación. Por ejemplo, el entorno aislado solo permite que tu aplicación use un conjunto limitado de bibliotecas binarias y tu aplicación 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 estándar de App Engine suelen ser aplicaciones web sin estado que responden rápidamente a las solicitudes HTTP.
Por el contrario, el entorno flexible ejecuta tu aplicación en contenedores Docker en máquinas virtuales (VMs) de Google Compute Engine, que tienen menos restricciones. Por ejemplo, puedes usar el lenguaje de programación que prefieras, escribir en el disco, usar cualquier biblioteca que quieras e incluso ejecutar varios procesos. El entorno flexible también te permite elegir cualquier tipo de máquina de Compute Engine para tus instancias, de modo que tu aplicación tenga acceso a más memoria y CPU.
Acceder a servicios externos
En el entorno estándar, tu aplicación suele acceder a servicios como Datastore a través de las APIs de google.appengine integradas. Sin embargo, en el entorno flexible, estas APIs ya no están disponibles. En su lugar, usa las bibliotecas de cliente de Google Cloud. Estas bibliotecas de cliente funcionan en cualquier lugar, lo que significa que tu 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 Compute Engine sin grandes modificaciones.
Desarrollo local
En el entorno estándar, normalmente ejecutas tu aplicación de forma local con el SDK de App Engine. El SDK se encarga de ejecutar tu aplicación y emula los servicios de App Engine. En el entorno flexible, el SDK ya no se usa para ejecutar tu aplicación. En su lugar, las aplicaciones escritas para el entorno flexible deben escribirse como aplicaciones web estándar que se puedan ejecutar en cualquier lugar. Como se ha mencionado, el entorno flexible solo ejecuta tu aplicación en un contenedor Docker. Esto significa que, para probar la aplicación de forma local, solo tienes que ejecutarla directamente. Por ejemplo, para ejecutar una aplicación de Python con Django, solo tendrías que ejecutar python manage.py runserver.
Otra diferencia clave es que las aplicaciones del entorno flexible que se ejecutan localmente usan servicios reales de Cloud Platform, como Datastore. Usa un proyecto independiente para hacer pruebas de forma local y, cuando sea posible, utiliza emuladores.
Características de escalado
Aunque ambos entornos usan la infraestructura de escalado automático de App Engine, la forma en que se escalan es diferente. El entorno estándar puede pasar de cero instancias a miles muy rápidamente. Por el contrario, el entorno flexible debe tener al menos una instancia en ejecución por cada versión activa y puede tardar más en ampliar la escala en respuesta al tráfico.
El entorno estándar usa un algoritmo de escalado automático diseñado específicamente. El entorno flexible usa el escalador automático de Compute Engine. Ten en cuenta que el entorno flexible no admite todas las opciones de escalado automático que están disponibles en Compute Engine. App Engine respeta las reservas de VMs de Compute Engine que ya tengas en una región que coincida con tu configuración. Si tienes una reserva de VM, es más probable que se te asignen recursos durante una escasez temporal de recursos.
Los desarrolladores deben probar el comportamiento de sus aplicaciones en diferentes condiciones. Por ejemplo, debes verificar cómo responde el escalado automático cuando una aplicación vinculada a la CPU se vincula a las operaciones de E/S durante los periodos en los que las llamadas a servicios remotos tienen una latencia elevada.
Comprobaciones del estado
El entorno estándar no usa comprobaciones del estado para determinar si debe enviar tráfico a una instancia. El entorno flexible permite a los desarrolladores de aplicaciones escribir sus propios controladores de comprobación del estado, que el balanceador de carga usará para determinar si debe enviar tráfico a una instancia y si esta debe repararse automáticamente. Los desarrolladores deben tener cuidado al añadir lógica a las comprobaciones de estado. Por ejemplo, si la comprobación del estado hace una llamada a un servicio externo, un fallo temporal en ese servicio puede provocar que todas las instancias pasen a un estado incorrecto, lo que podría provocar un fallo en cascada.
Rechazar solicitudes cuando se sobrecarga
Las aplicaciones pueden rechazar solicitudes cuando están sobrecargadas como parte de una estrategia para evitar fallos en cascada. Esta función está integrada en la capa de enrutamiento del tráfico del entorno estándar. Recomendamos que los desarrolladores de aplicaciones con un QPS muy alto en el entorno flexible creen esta función para reducir el tráfico de sobrecarga en sus aplicaciones limitando el número de solicitudes simultáneas.
Para comprobar que tu aplicación de entorno flexible no es susceptible a este tipo de fallo, crea una versión con un límite en el número máximo de instancias. A continuación, aumenta el tráfico de forma constante hasta que se rechacen las solicitudes. Debes asegurarte de que tu aplicación no falle en las comprobaciones del estado durante la sobrecarga.
En Java, las aplicaciones Java que usan el entorno de ejecución de Jetty pueden configurar el filtro de calidad del servicio para implementar la sobrecarga de abandono. Con esta función, puedes definir el número máximo de solicitudes simultáneas que atienden las aplicaciones y el tiempo que se pondrán en cola las solicitudes.
Tamaños de instancia
Las instancias del entorno flexible pueden tener límites de CPU y memoria más altos que las instancias del entorno estándar. Esto permite que las instancias flexibles ejecuten aplicaciones que consuman más memoria y CPU. Sin embargo, puede aumentar la probabilidad de que se produzcan errores de simultaneidad debido al aumento de los subprocesos en una sola instancia.
Los desarrolladores pueden conectarse por SSH a una instancia de entorno flexible y obtener un volcado de pila para solucionar este tipo de problema.
Por ejemplo, si usas el tiempo 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 las solicitudes
Aunque el tiempo de espera de las solicitudes del entorno estándar varía en función del tipo de escalado seleccionado, el entorno flexible siempre impone un tiempo de espera de 60 minutos. Para evitar que las solicitudes permanezcan abiertas durante los 60 minutos y que se agoten todos los subprocesos del servidor web, haz lo siguiente:
Cuando hagas llamadas a servicios externos, especifica un tiempo de espera.
Implementa un filtro de servlet para detener las solicitudes que tardan demasiado tiempo, como 60 segundos. Asegúrate de que tu aplicación pueda volver a un estado coherente después de que tu filtro detenga una solicitud.
Gestión de conversaciones
Los entornos de ejecución de Java del entorno estándar anteriores a Java 8 solo podían usar hilos creados con el SDK del entorno estándar de App Engine. Los desarrolladores que porten una aplicación de un entorno de ejecución estándar de Java de primera generación a un entorno flexible deben cambiar a bibliotecas de subprocesos nativas. Las aplicaciones que requieren un número muy elevado de hilos pueden ejecutarse de forma más eficiente con grupos de hilos que con la creación explícita de hilos.
Migración de tráfico
El entorno estándar ofrece una función de migración de tráfico que transfiere gradualmente el tráfico a una nueva versión para minimizar los picos de latencia. Consulta los documentos sobre migración de tráfico para saber cómo evitar un pico de latencia al cambiar el tráfico a una nueva versión.
Fallos en una sola zona
Las aplicaciones del entorno estándar tienen un solo alojamiento, lo que significa que todas las instancias de la aplicación se encuentran en una única zona de disponibilidad. Si se produce un fallo en esa zona, la aplicación inicia nuevas instancias en otra zona de la misma región y el balanceador de carga dirige el tráfico a las nuevas instancias. Verás un pico de latencia debido a las solicitudes de carga y también un vaciado de Memcache.
Las aplicaciones del entorno flexible usan grupos de instancias gestionadas regionales, lo que significa que las instancias se distribuyen entre varias zonas de disponibilidad de una región. En caso de que falle una sola zona, el balanceador de carga dejará de enrutar el tráfico a esa zona. Si has configurado el autoescalado para que tus instancias se ejecuten lo más rápido posible, verás un breve periodo de sobrecarga antes de que el autoescalado cree más instancias.
Comparativas de costes
Hay muchos factores que influyen en la comparación de costes entre cargas de trabajo que se ejecutan en entornos estándar y flexibles. Por ejemplo:
- Precio pagado por MCycle.
- Las funciones de la plataforma de CPU, que influyen en el trabajo que se puede hacer por MCycle
- La temperatura a la que puedes ejecutar instancias en cada plataforma.
- Coste de las implementaciones, que puede variar en cada plataforma y ser significativo si usas la implementación continua en tu aplicación.
- Sobrecarga del tiempo de ejecución.
Deberá realizar experimentos para determinar el coste de su carga de trabajo en cada plataforma. En el entorno flexible, puedes usar las consultas por segundo por núcleo como proxy de la eficiencia de costes de tu aplicación al realizar experimentos para determinar si un cambio tiene un impacto en los costes. El entorno estándar no proporciona ningún mecanismo para obtener métricas en tiempo real sobre la eficiencia de costes 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 tiene esta función. El enfoque recomendado para la autenticación segura entre aplicaciones es usar OAuth.
Implementación
Las implementaciones en el entorno estándar suelen ser más rápidas que las implementaciones en el entorno flexible. Es más rápido aumentar la escala de una versión en un entorno flexible que implementar una nueva, ya que la programación de red de una versión nueva suele ser el factor que más tiempo requiere en una implementación de entorno flexible. Una estrategia para hacer rollbacks rápidos en un entorno flexible es mantener una versión que se sabe que funciona correctamente a una sola instancia. Después, puedes ampliar esa versión y enrutar todo el tráfico a ella mediante la división del tráfico.
Cuándo usar el entorno flexible
El entorno flexible está pensado para complementar el entorno estándar. Si tienes una aplicación que se ejecuta en el entorno estándar, no suele ser necesario migrar toda la aplicación al entorno flexible. En su lugar, identifica las partes de tu aplicación que requieran más CPU, más RAM, una biblioteca o un programa de terceros especializados, o que necesiten realizar acciones que no sean posibles en el entorno estándar. Una vez que hayas identificado estas partes de tu aplicación, crea pequeños servicios de App Engine que usen el entorno flexible para gestionar solo esas partes. Tu servicio actual que se ejecuta en el entorno estándar puede llamar a los demás servicios mediante HTTP, Cloud Tasks o Cloud Pub/Sub.
Por ejemplo, si tiene una aplicación web que se ejecuta en el entorno estándar y quiere añadir una nueva función para convertir archivos a PDF, puede escribir un microservicio independiente que se ejecute en el entorno flexible y que solo gestione la conversión a PDF. Este microservicio puede ser un programa sencillo que conste de 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 directamente a través de HTTP. Si prevés que la conversión tardará mucho tiempo, la aplicación puede usar Cloud Tasks o Pub/Sub para poner en cola las solicitudes.