En esta página, se proporcionan prácticas recomendadas para crear una arquitectura de múltiples usuarios que aloje código no confiable con Cloud Run. Como cliente de Google Cloud , un "usuario" se define como uno de tus propios clientes y el "código no confiable" es el código que proporcionan estos usuarios para que se ejecute en tu plataforma.
Casos de uso
Los casos de uso de estas arquitecturas incluyen los siguientes:
- Plataformas de hosting de apps: Proporcionas una plataforma en la que tus clientes implementan su código. Por ejemplo, una plataforma de hosting web (los clientes proporcionan un servidor web) o una plataforma de funciones como servicio (los clientes proporcionan una función).
- Plataformas de hosting de agentes: Tus clientes usan SDKs para compilar agentes de IA, y tu plataforma los ejecuta en segundo plano.
- Plataformas de modelos ajustados: Ofreces la capacidad de personalizar modelos de IA para cada cliente. Luego, tu plataforma los ejecuta a pedido con GPU.
- Funciones definidas por el usuario: Tu software permite que sus clientes definan una lógica personalizada con código. Por ejemplo, proporcionas un motor de análisis y quieres permitir que los clientes escriban funciones personalizadas, o proporcionas una puerta de enlace de API y quieres permitir que los clientes filtren o muten las solicitudes según su propia lógica personalizada.
- Extensibilidad de software como servicio (SaaS): Es posible que ofrezcas un SaaS y quieras permitir que los clientes amplíen sus capacidades con extensiones. Es posible que los clientes o socios escriban estas extensiones.
Los clientes deGoogle Cloud usan Cloud Run de forma correcta en producción para estos casos de uso.
Desafíos de las plataformas multiusuario
Los desafíos típicos de crear una arquitectura de este tipo incluyen los siguientes:
- Seguridad: Es imposible analizar o limpiar el código proporcionado. El código no confiable puede incluir acciones maliciosas o dependencias vulnerables. Si no se aísla correctamente, el código no confiable podría acceder a datos sensibles que pertenecen a otros usuarios. Empaquetar el código en un contenedor no es un límite de seguridad lo suficientemente sólido. También se debe restringir lo que puede hacer el código aplicando el principio de privilegio mínimo.
- Eficiencia de costos: Esta arquitectura puede ser costosa si cada usuario genera costos fijos para tu plataforma.
- Administración de usuarios: Administrar cientos de miles de usuarios puede ser difícil, en especial cuando se trata de borrar datos.
Beneficios de Cloud Run
Una arquitectura basada en Cloud Run ofrece una solución para los desafíos comunes con muchos beneficios, como la seguridad, la rentabilidad y la administración de usuarios.
Seguridad
Cloud Run proporciona las funciones de seguridad listas para usar que son relevantes para esta arquitectura:
- Aislamiento de procesamiento: Cloud Run garantiza un aislamiento estricto entre las instancias de contenedor, ya sea del mismo servicio o de diferentes servicios de distintos proyectos. Para obtener más información sobre la seguridad de los contenedores y los entornos de ejecución, consulta Descripción general del diseño de seguridad.
- Actualizaciones de seguridad: Las actualizaciones de seguridad automáticas de las imágenes base se pueden habilitar para mantener el sistema operativo y el entorno de ejecución de las cargas de trabajo implementadas actualizados y con parches sin necesidad de volver a realizar implementaciones a gran escala.
- Aislamiento de red: Cloud Run no solo coloca los contenedores en una zona de pruebas, sino que también proporciona una pila de red multiusuario.
- Identidad de servicio: Las cargas de trabajo de Cloud Run se pueden configurar para tener identidades dedicadas con permisos restringidos.
Rentabilidad
- Reducción de escala a cero y pago por uso: Las instancias de Cloud Run se escalan automáticamente a cero cuando no están en uso, lo que garantiza que las cargas de trabajo alojadas solo se cobren cuando necesiten ejecutarse. Esto genera un uso muy eficiente de los recursos en comparación con las arquitecturas que aprovechan las máquinas virtuales "siempre activas".
- Facturación por solicitud: Además de la reducción de escala a cero, puedes beneficiarte de un modelo de facturación aún más detallado que solo cobra cuando se procesan las solicitudes, lo que proporciona una rentabilidad aún mayor.
- Inicio rápido y bajo demanda: Cuando se reduce la escala, los servicios de Cloud Run pueden volver a escalar verticalmente con rapidez, lo que genera poca latencia percibida por el usuario final de la aplicación implementada.
- Etiquetado de costos automatizado: Todos los costos que informa Cloud Run se etiquetan, lo que te permite automatizar la atribución de costos y el seguimiento de tus usuarios.
- Compromisos para reducir los costos agregados: A nivel de la cuenta de facturación, puedes usar descuentos por compromiso de uso flexibles para optimizar los gastos de cualquier uso de referencia de Cloud Run.
Administración de usuarios
Debido a su naturaleza a pedido, los costos de Cloud Run no son más altos cuando se usan varios proyectos de Google Cloud , lo que habilita la administración de usuarios como se describe en Organiza tus proyectos de Google Cloud .
Arquitectura de destino para plataformas multiusuario
A grandes rasgos, esta es la arquitectura recomendada:
Organiza tus proyectos de Google Cloud
Debes configurar una organización de Google Cloud , la facturación sin conexión y comunicarte con tu equipo de cuentas para informarle que actúas como una cuenta de revendedor. Es posible queGoogle Cloud trabaje contigo para garantizar que se establezcan los canales de comunicación adecuados para mitigar el abuso.
Debes usar carpetas para organizar tus proyectos de Google Cloud . En particular, es esencial que coloques en carpetas diferentes los proyectos que ejecutan tu código propio de los proyectos que ejecutan código no confiable de tus usuarios. Debes automatizar la incorporación de los usuarios para que la creación de los proyectos y recursos de un usuario no requiera intervención humana.
Google recomienda usar un proyecto de Google Cloud por usuario. También es posible alojar varios usuarios en el mismo proyecto, pero esto conlleva limitaciones adicionales:
Un solo usuario por Google Cloud proyecto (recomendado)
En esta arquitectura, cada usuario de tu plataforma se aloja en un proyecto deGoogle Cloud dedicado, lo que tiene muchos beneficios:
- Seguridad más simple: El proyecto de Google Cloud es un límite estricto para todos los recursos que contiene. Esto significa que, si un usuario necesita acceso a varios recursos deGoogle Cloud , como varios servicios de Cloud Run o un bucket de Cloud Storage, puedes usar el proyecto como un perímetro seguro.
- Menos limitado:
- La cantidad de recursos en un proyecto determinado es limitada. Por ejemplo, Cloud Run solo permite crear 1,000 servicios por región en un proyecto. Existen límites similares en la cantidad de cuentas de servicio y otros recursos relacionados.
- La cantidad de proyectos es una cuota en sí misma y se puede aumentar. No hay límites para esta cantidad en una organización de Google Cloud . Hay un límite flexible de 100,000 proyectos por cuenta de facturación, que se puede multiplicar si te comunicas con Google. Tu organización también puede crear muchas cuentas de facturación y agruparlas en un "grupo de cuentas" (actualmente en versión preliminar privada).
- Supervisión y administración más sencillas:
- Usar un proyecto por usuario genera procesos de eliminación de datos más sencillos, en los que borrar los datos de un usuario se reduce a borrar el proyecto correspondiente.
- Google Cloud Monitoring y Logging funcionan en todos los proyectos y pueden permitirte supervisar toda tu flota.
- Las cuotas a nivel de proyecto te permiten limitar el uso de recursos de Cloud Run para un usuario determinado, lo que podría alinear los límites con tus propios niveles de precios.
- Las políticas de la organización personalizadas te permiten aplicar restricciones específicas, como las regiones disponibles o la asignación máxima de CPU o memoria, a todos los proyectos de una carpeta.
La creación de un proyecto de Google Cloud y la inicialización de las APIs y los recursos pueden tener latencia. Google recomienda que uses un grupo de proyectos creados previamente que asignes a tus usuarios cuando sea necesario.
Varios usuarios por proyecto de Google Cloud (no recomendado)
Es posible alojar varios de tus usuarios en el mismo proyecto de Google Cloud, pero Google no recomienda esta arquitectura.
Muchos servicios de Google Cloud tienen límites de recursos por proyecto. Por ejemplo, Cloud Run tiene un límite no ajustable de 1,000 servicios de Cloud Run por región en un proyecto. Por lo tanto, alojar varios usuarios por proyecto seguirá requiriendo que administres una flota de proyectos de Google Cloud , lo que aumentará la complejidad de la administración de usuarios. Desde una perspectiva de seguridad, los proyectos deGoogle Cloud se diseñan como un límite de seguridad, por lo que alojar dos usuarios distintos en los mismos proyectos requiere que tengas más cuidado en lo que respecta a la seguridad. Por ejemplo, garantizando cuentas de servicio dedicadas y permisos detallados.
Implementa en muchas regiones
Para la confiabilidad y la escalabilidad, Google recomienda distribuir las implementaciones de los usuarios en varias Google Cloud regiones. Cada aplicación de usuario se implementa en una sola región, pero puedes usar regiones diferentes para usuarios distintos. La selección de la región puede ser aleatoria o puede tener en cuenta la ubicación del usuario para optimizar la latencia.
Enrutamiento de solicitudes y dominios personalizados
Si quieres exponer los servicios de Cloud Run de tu usuario tipo a los usuarios finales, deberás agregar tu propio dominio y usar tu propia lógica de enrutamiento. Por ejemplo, para asignar un subdominio al proyecto de Google Cloud que aloja el servicio del usuario.
Puedes implementar tu servicio de enrutamiento personalizado, pero Google recomienda usar un balanceador de cargas de aplicaciones externo global con Service Extensions para la lógica de enrutamiento. Las extensiones de servicio se pueden implementar como complementos (en los que la lógica se ejecuta de forma intercalada con el procesamiento de solicitudes) o como textos destacados (la lógica de enrutamiento se delega a un servicio de Cloud Run independiente que puede llamar a una de las bases de datos multirregionales escalables deGoogle Cloud, como Spanner).
El uso de un balanceador de cargas de aplicaciones también te permitirá agregar una capa de almacenamiento en caché aprovechando Cloud CDN y protección adicional contra ataques de denegación de servicio distribuido (DSD) a tu plataforma con Cloud Armor.
Reputación y abuso
Cualquier plataforma de hosting que permita ejecutar código no confiable estará sujeta a abusos.
Te recomendamos que uses una cuenta de Facturación de Cloud diferente para cada uno de los niveles de reputación que ofreces. Por ejemplo, tus usuarios de nivel gratuito no deben estar vinculados a la misma cuenta de facturación que tus clientes que pagan mucho. Google puede considerar estas cuentas de facturación en diferentes niveles de reputación.
Como se describe en Organiza tus proyectos de Google Cloud , además de separar por cuentas de facturación, debes usar carpetas para organizar los proyectos. Google puede ayudarte a establecer cuotas a nivel de la carpeta para garantizar que todos los recursos dentro de una carpeta nunca consuman más de un máximo establecido, lo que te permite administrar mejor el costo de tu plataforma.
De forma predeterminada, Google quita automáticamente las cargas de trabajo abusivas de acuerdo con las condiciones del servicio deGoogle Cloud . Google también puede registrar eventos de detección de abusos en Cloud Logging, sobre los que puedes tomar medidas.