Probando Cloud Run

Llevamos algún tiempo explorando el traslado de algunas de nuestras cargas de trabajo a una infraestructura sin servidor; al principio consideramos AWS Lambda como la solución de referencia, pero la compatibilidad con contenedores lista para usar de Cloud Run resultaba una opción atractiva, ya que reducía el coste de trasladar los contenedores existentes.

Al principio consideramos trasladar primero nuestros sitios web no estáticos; esto es lo que aprendimos al usarlo y por qué decidimos que todavía no está listo para producción.

Traslado de las cargas de trabajo

Si sus contenedores ya están almacenados en GCR, configurar Cloud Run es muy sencillo. Hubo que adaptar el código para escuchar en el $PORT establecido por Cloud Run. Esto resultó más complicado de lo previsto porque usamos Nginx y su configuración no admite variables de entorno en los archivos de configuración.

Las opciones eran usar un lenguaje de scripting como LUA o PERL para crear una variable de Nginx a partir de la variable de entorno, o usar envsubst para transformar una plantilla de configuración sustituyendo los valores de las variables de entorno.

Tráfico cifrado

Una clara ventaja de Cloud Run es que ya no es necesario configurar su endpoint TLS/SSL, ya que Cloud Run se encarga de ello.

Esto ofrece una mayor seguridad, ya que no hace falta mantenerse al día con las prácticas recomendadas de configuración de TLS, qué protocolos admitir, etc. Sin embargo, también reduce su margen de maniobra, ya que puede que desee tener una política estricta o dar soporte a navegadores antiguos.

En esos casos, una configuración de TLS gestionada sin posibilidad de configurarla es un gran problema.

Conexión con servicios externos

Cuando el servicio estuvo en marcha, no dejaba de quejarse de la conexión con la base de datos SQL. Para nuestra sorpresa, Cloud Run solo admite la conexión con servicios internos de Google. No se admite una base de datos que no se ejecute en GCP.

Esto también limita la utilidad de Cloud Run para varios casos de uso que requieren conexiones salientes. Si realmente lo necesita, es posible ejecutar Cloud Run en un GKE dedicado, pero la configuración era tan compleja y la documentación tan poco clara que simplemente desistimos.

Para seguir con las pruebas, acabamos montando una base de datos en GCP con Cloud SQL. Sin embargo, la conexión SQL se realiza mediante archivos de socket montados en el contenedor en /cloudsql/.

Configurar esto también requirió cambios en el código, pero fue muy directo; lo realmente divertido llegó cuando tuvimos que lidiar con el error de la política de IAM y las API que faltaban. No fue agradable pasar por ello, pero una vez que funciona, reutilizar la misma cuenta de servicio para conectarse a la base de datos no supone ninguna operación y es claramente más seguro.

Escalado

Una vez que la configuración de Cloud Run y la conexión a la base de datos funcionaron, llegó el momento de la verdad: ¿qué tal escala y rinde?

Lanzar miles de conexiones sobre el servicio funcionó de maravilla, alcanzando 1k QPS y con picos de 1.6k QPS.

El escalado fue una grata sorpresa y funcionó desde el primer momento; puede que se produzca un cuello de botella en la base de datos si está infradimensionada.

Latencia

Lamentablemente, la latencia fue el factor decisivo. Mantener una latencia relativamente baja en nuestros sitios web era importante para ofrecer una buena experiencia de usuario.

La latencia actual variaba entre 40 ms y 2000ms de media, con 3000 ms en el percentil 95.

La latencia de Cloud Run fue sencillamente horrible, de 4000ms a 8000ms. Pudimos ver que la latencia bajaba tras un arranque en frío, pero incluso entonces los valores alcanzados eran altos, entre 600ms y 4000ms, con picos de nuevo hasta 8000ms muy a menudo.

Veredicto

Cloud Run parecía muy prometedor y claramente tiene un gran potencial por su compatibilidad con contenedores lista para usar. Su integración con Cloud Build también parece una gran ventaja para automatizar los despliegues.

La falta de compatibilidad con conexiones salientes limita su utilidad y sus escenarios de integración; supongo que se hace así para evitar que se abuse del servicio para ejecutar ataques DDoS.

Aunque las cifras de escalado son impresionantes, la latencia es muy problemática, lo que limita su utilidad para ejecutar sitios web o incluso API.

Usar el servicio para trabajos que no sean sensibles a la latencia sigue siendo una opción, siempre que no requieran conexiones salientes.