En esta página, se proporcionan prácticas recomendadas para crear una arquitectura de múltiples arrendatarios que aloje código no confiable con Cloud Run. Como Google Cloud cliente, un "inquilino" se define como uno de tus propios clientes, y el "código no confiable" es el código que proporcionan estos inquilinos para que se ejecute en tu plataforma.
Casos de uso
Los casos de uso de estas arquitecturas incluyen los siguientes:
- Plataformas de alojamiento 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 alojamiento 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 GPUs.
- Funciones definidas por el usuario: Tu software permite que los clientes definan lógica personalizada con código. Por ejemplo, si proporcionas un motor de análisis y quieres permitir que los clientes escriban funciones personalizadas, o si proporcionas una puerta de enlace de API y quieres permitir que los clientes filtren o modifiquen solicitudes según su propia lógica personalizada.
- Extensibilidad del software como servicio (SaaS): Es posible que ofrezcas un SaaS y quieras permitir que los clientes extiendan sus capacidades con extensiones. Estas extensiones pueden ser escritas por clientes o socios.
Los clientes deGoogle Cloud usan Cloud Run de forma exitosa en producción para estos casos de uso.
Desafíos de las plataformas multiusuario
Entre los desafíos típicos de la creación de este tipo de arquitectura, se 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. El simple hecho de empaquetar el código en un contenedor no es un límite de seguridad lo suficientemente sólido. También se debe restringir el código en lo que puede hacer aplicando el principio de permisos de privilegio mínimo.
- Eficiencia en el costo: Este tipo de arquitectura puede resultar costosa si cada usuario incurre en costos fijos para tu plataforma.
- Administración de usuarios: Administrar cientos de miles de usuarios puede ser un desafío, sobre todo 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 eficiencia en los costos y la administración de inquilinos.
Seguridad
Cloud Run proporciona las funciones de seguridad listas para usar que son relevantes para esta arquitectura:
- Aislamiento de la instancia de procesamiento: Cloud Run garantiza un aislamiento estricto entre las instancias de contenedores, 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 implementar a gran escala.
- Aislamiento de red: Cloud Run no solo aísla los contenedores en una zona de pruebas, sino que también proporciona una pila de redes de múltiples inquilinos.
- Identidad de servicio: Las cargas de trabajo de Cloud Run se pueden configurar para que tengan identidades dedicadas con permisos restringidos.
Rentabilidad
- Reducción de escala a cero y pago por uso: Las instancias de Cloud Run se reducen automáticamente a cero cuando no están en uso, lo que garantiza que las cargas de trabajo alojadas solo se cobren cuando deben ejecutarse. Esto genera un uso de recursos muy eficiente en comparación con las arquitecturas que aprovechan las máquinas virtuales "siempre activas".
- Facturación por solicitud: Además de la reducción a cero, puedes aprovechar un modelo de facturación aún más detallado que solo cobra cuando se procesan las solicitudes, lo que proporciona una eficiencia de costos aún mayor.
- Inicio rápido y a pedido: Cuando se reduce la escala, los servicios de Cloud Run pueden volver a aumentar la escala rápidamente, 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 están etiquetados, lo que te permite automatizar la atribución de costos y el seguimiento de tus arrendatarios.
- Compromisos para reducir los costos agregados: A nivel de la cuenta de facturación, puedes usar los 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 bajo demanda, los costos de Cloud Run no son más altos cuando se usan varios proyectos Google Cloud , lo que permite la administración de usuarios como se describe en Organiza tus proyectos Google Cloud .
Arquitectura de destino para plataformas multiusuario
A continuación, se muestra la arquitectura recomendada a un nivel general:
Organiza tus proyectos de Google Cloud
Debes configurar una organización, la facturación sin conexión y comunicarte con tu equipo de cuentas para informarle que actúas como cuenta de revendedor.Google Cloud puede trabajar contigo para garantizar que se establezcan los canales de comunicación adecuados para la mitigación del abuso. Google Cloud
Debes usar carpetas para organizar tus proyectos de Google Cloud . En particular, es fundamental que coloques en carpetas diferentes los proyectos que ejecutan tu código de origen de los proyectos que ejecutan código no confiable de tus usuarios. Debes automatizar la incorporación de inquilinos para que la creación de los proyectos y los recursos de un inquilino no requiera la intervención humana.
Google recomienda usar un proyecto Google Cloud por usuario. También es posible alojar varios usuarios en el mismo proyecto, pero esto conlleva limitaciones adicionales:
Un solo usuario por proyecto Google Cloud (recomendado)
En esta arquitectura, cada usuario de la plataforma se aloja en unGoogle Cloud proyecto dedicado, lo que ofrece muchos beneficios:
- Seguridad más simple: El proyecto Google Cloud es un límite estricto para todos los recursos que contiene. Esto significa que, si un arrendatario 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í y se puede aumentar. No hay límites para esta cantidad en una organización de Google Cloud . Existe un límite flexible de 100,000 proyectos por cuenta de facturación, que se puede aumentar 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 facilita los procesos de eliminación de datos, ya que borrar los datos de un usuario se reduce a borrar el proyecto respectivo.
- Google Cloud Monitoring y Logging funcionan en todos los proyectos y te permiten supervisar toda tu flota.
- Las cuotas a nivel del proyecto te permiten limitar el uso de recursos de Cloud Run para un inquilino 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 de una carpeta, como las regiones disponibles o la asignación máxima de CPU o memoria, a todos los proyectos de esa carpeta.
Crear un proyecto e inicializar APIs y recursos puede generar latencia, por lo que Google recomienda que uses un grupo de proyectos creados previamente que asignes a tus usuarios cuando sea necesario. Google Cloud
Varias instancias por proyecto Google Cloud (no recomendado)
Es posible alojar varios de tus arrendatarios 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 general de la administración de usuarios. Desde una perspectiva de seguridad, los proyectos deGoogle Cloud se diseñan como un límite de seguridad. Alojar dos arrendatarios distintos en los mismos proyectos requiere que tengas más cuidado en lo que respecta a la seguridad. Por ejemplo, garantizar cuentas de servicio dedicadas y permisos detallados
Enrutamiento de solicitudes y dominios personalizados
Si deseas exponer los servicios de Cloud Run de tu arrendatario a los usuarios finales, te recomendamos que agregues tu propio dominio y utilices tu propia lógica de enrutamiento. Por ejemplo, para asignar un subdominio al proyecto Google Cloud que aloja el servicio del arrendatario.
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 texto destacado (la lógica de enrutamiento se delega en 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 pueda ejecutar código no confiable estará sujeta a abusos.
Te recomendamos que uses una cuenta de Facturación de Cloud diferente para cada nivel de reputación que ofrezcas. Por ejemplo, tus arrendatarios del nivel gratuito no deben estar asociados a la misma cuenta de facturación que tus clientes que pagan tarifas altas. Google puede considerar estas cuentas de facturación en diferentes niveles de reputación.
Como se describe en Cómo organizar tus proyectos, además de separarlos por cuentas de facturación, debes usar carpetas para organizar los proyectos. Google Cloud 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 permitirá administrar mejor el costo de tu plataforma.
De forma predeterminada, Google quita automáticamente las cargas de trabajo abusivas según las Google Cloud condiciones del servicio. Google también puede registrar los eventos de detección de abuso en Cloud Logging, para que puedas tomar medidas al respecto.