Implementa la herramienta de escalamiento automático en Cloud Run Functions

La herramienta de escalamiento automático está diseñada para permitir la flexibilidad y puede adaptarse a la separación existente de responsabilidades entre tus equipos de operaciones y aplicaciones. La responsabilidad de configurar el ajuste de escala automático de las instancias de Spanner se puede centralizar con un solo equipo de operaciones o se puede distribuir a los equipos más cercanos a las aplicaciones que entregan esas instancias de Spanner.

Este documento forma parte de una serie que también incluye lo siguiente:

Esta serie está dirigida a equipos de TI, ingeniería de confiabilidad de sitios (SRE) y operaciones que desean reducir la sobrecarga operativa y optimizar el costo de las implementaciones de Spanner.

En esta página, se presentan tres formas en las que puedes implementar el Autoscaler en las funciones de Cloud Run según tus requisitos:

  • Una topología de implementación por proyecto. La infraestructura del escalador automático se implementa en el mismo proyecto que Spanner y necesita ajuste de escala automático. Recomendamos esta topología para equipos independientes que desean administrar su propia infraestructura y configuración del escalador automático. Una topología de implementación por proyecto también es un buen punto de partida para probar las capacidades del escalador automático.
  • Una topología de implementación centralizada. La herramienta de escalador automático se implementa en un proyecto y administra una o más instancias de Spanner en diferentes proyectos. Recomendamos esta topología para los equipos que administran la configuración y la infraestructura de una o más instancias de Spanner, a la vez que mantienen los componentes y la configuración para el escalador automático en un lugar central. En la topología centralizada, además de un proyecto de escalador automático, debes configurar un segundo proyecto, que en este instructivo se denomina proyecto de aplicación. El proyecto de aplicación contiene los recursos de la aplicación, incluido Spanner.
  • Una topología de implementación distribuida. La mayor parte de la infraestructura del escalador automático se implementa en un proyecto, pero algunos componentes de la infraestructura se implementan con instancias de Spanner con ajuste de escala automático en proyectos diferentes. Recomendamos esta topología para organizaciones con varios equipos, en los que los equipos que poseen las instancias de Spanner desean administrar solo los parámetros de configuración del escalador automático para sus instancias, pero un equipo central administra el resto de la infraestructura del escalador automático.

Plataforma sin servidores para facilitar la implementación y la administración

En este modelo, la herramienta de escalamiento automático se compila solo con herramientas Google Cloud sin servidores y de administración baja, como las funciones de Cloud Run, Pub/Sub, Cloud Scheduler y Firestore. Este enfoque minimiza el costo y la sobrecarga operativa de ejecutar la herramienta de escalamiento automático.

Mediante el uso de herramientas Google Cloud integradas, el escalador automático puede aprovechar al máximo Identity and Access Management (IAM) para la autenticación y autorización.

Configuración

La herramienta Autoscaler administra las instancias de Spanner a través de la configuración definida en Cloud Scheduler. Si se deben consultar varias instancias de Spanner con el mismo intervalo, te recomendamos que las configures en el mismo trabajo de Cloud Scheduler. La configuración de cada instancia se representa como un objeto JSON. El siguiente es un ejemplo de una configuración en la que se administran dos instancias de Spanner con un trabajo de Cloud Scheduler:

[
  {
    "projectId": "my-spanner-project",
    "instanceId": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "PROCESSING_UNITS",
    "minSize": 500,
    "maxSize": 3000,
    "scalingMethod": "DIRECT"
  }
]

Las instancias de Spanner pueden tener varias configuraciones en diferentes trabajos de Cloud Scheduler. Por ejemplo, una instancia puede tener una configuración de escalador automático con el método lineal para operaciones normales, pero también tiene otra configuración de escalador automático con el método directo para cargas de trabajo por lotes planificadas.

Cuando se ejecuta el trabajo de Cloud Scheduler, se envía un mensaje de Pub/Sub al tema de sondeo de Pub/Sub. La carga útil de este mensaje es el arreglo JSON de los objetos de configuración para todas las instancias configuradas en el mismo trabajo. Consulta la lista completa de opciones de configuración en el archivo README de sondeo.

Topología por proyecto

En una implementación de topología por proyecto, cada proyecto con una instancia de Spanner que necesita ajuste de escala automático también tiene su propia implementación independiente de los componentes del escalador automático. Recomendamos esta topología para equipos independientes que desean administrar su propia infraestructura y configuración del escalador automático. También es un buen punto de partida para probar las capacidades de la herramienta de escalamiento automático.

En el siguiente diagrama, se muestra una vista conceptual de alto nivel de una implementación por proyecto.

Implementación conceptual por proyecto

Las implementaciones por proyecto que se muestran en el diagrama anterior tienen las siguientes características:

  • Dos aplicaciones, aplicación 1 y aplicación 2, usan sus propias instancias de Spanner.
  • Las instancias de Spanner (A) se encuentran en proyectos respectivos a la aplicación 1 y la aplicación 2.
  • Se implementa un escalador automático independiente (B) en cada proyecto para controlar el ajuste de escala automático de las instancias dentro de un proyecto.

Una implementación por proyecto tiene las siguientes ventajas y desventajas.

Ventajas:

  • Diseño más simple: La topología por proyecto es el diseño más simple de las tres topologías, ya que todos los componentes del escalador automático se implementan junto con las instancias de Spanner para el ajuste de escala automático.
  • Configuración: El control de los parámetros del programador pertenece al equipo que posee la instancia de Spanner, lo que le brinda al equipo más libertad para adaptar la herramienta de escalador automático a sus necesidades que una topología centralizada o distribuida.
  • Límite claro de la responsabilidad de la infraestructura: el diseño de una topología por proyecto establece un límite claro de responsabilidad y seguridad en la infraestructura del escalador automático, debido a que el propietario del equipo de las instancias de Spanner también es el propietario de la infraestructura del escalador automático.

Desventajas:

  • Más mantenimiento general: Cada equipo es responsable de la configuración y la infraestructura del escalador automático, por lo que puede ser difícil asegurarse de que todas las herramientas del escalador automático de la empresa sigan los mismos lineamientos de actualización.
  • Auditoría más compleja: debido a que cada equipo tiene un alto nivel de control, una auditoría centralizada puede volverse más compleja.

Si deseas obtener información para configurar el escalador automático con una topología por proyecto, consulta la guía paso a paso para la implementación por proyecto.

Topología centralizada

Al igual que en la topología por proyecto, en una implementación de topología centralizada, todos los componentes de la herramienta de escalador automático residen en el mismo proyecto. Sin embargo, las instancias de Spanner se encuentran en proyectos diferentes. Esta implementación es adecuada para un equipo que administra la configuración y la infraestructura de varias instancias de Spanner desde una sola implementación de la herramienta del escalador automático en un lugar central.

En el siguiente diagrama, se muestra una vista conceptual de alto nivel de una implementación de proyecto centralizado:

Implementación conceptual de proyecto centralizado

La implementación centralizada que se muestra en el diagrama anterior tiene las siguientes características:

  • Dos aplicaciones, aplicación 1 y aplicación 2, usan sus propias instancias de Spanner.
  • Las instancias de Spanner (A) están en los proyectos respectivos a la aplicación 1 y la aplicación 2.
  • El escalador automático (B) se implementa en un proyecto independiente para controlar el ajuste de escala automático de las instancias de Spanner en los proyectos de la Aplicación 1 y la Aplicación 2.

Una implementación centralizada tiene las siguientes ventajas y desventajas.

Ventajas:

  • Infraestructura y configuración centralizada: Un solo equipo controla los parámetros del programador y la infraestructura del escalador automático. Este enfoque puede ser útil en industrias muy reguladas.
  • Menos mantenimiento general: el mantenimiento y la configuración suelen requerir menos esfuerzo en comparación con una implementación por proyecto.
  • Políticas y auditoría centralizadas: las prácticas recomendadas entre los equipos pueden ser más fáciles de especificar y aplicar. Es posible que las auditorías sean más fáciles de ejecutar.

Desventajas:

  • Configuración centralizada: Cualquier cambio en los parámetros del escalador automático debe pasar por el equipo centralizado, aunque el equipo que solicita el cambio sea propietario de la instancia de Spanner.
  • Posible riesgo adicional: El equipo centralizado puede convertirse en un punto único de fallo, incluso si la infraestructura del escalador automático está diseñada para ofrecer una alta disponibilidad.

Si deseas obtener información para configurar el escalador automático con una topología centralizada, consulta la guía paso a paso para la implementación centralizada.

Topología distribuida

En una implementación de topología distribuida, las instancias de Cloud Scheduler y Spanner que necesitan ajuste de escala automático residen en el mismo proyecto. Los componentes restantes de la herramienta de escalamiento automático residen en un proyecto administrado de forma central. Esta implementación es híbrida. Los equipos que poseen las instancias de Spanner solo administran los parámetros de configuración del escalador automático para sus instancias, y un equipo central administra la infraestructura restante del escalador automático.

En el siguiente diagrama, se muestra una vista conceptual de alto nivel de una implementación de proyecto distribuido.

Implementación conceptual de proyecto distribuido.

La implementación híbrida que se muestra en el diagrama anterior tiene las siguientes características:

  • Dos aplicaciones, aplicación 1 y aplicación 2, usan sus propias instancias de Spanner.
  • Las instancias de Spanner (A) están en los proyectos de aplicación 1 y aplicación 2.
  • Se implementa un componente independiente de Cloud Scheduler (C) en cada proyecto: aplicación 1 y aplicación 2.
  • Los componentes restantes del escalador automático (B) se implementan en un proyecto independiente.
  • La herramienta de escalador automático escala de forma automática las instancias de Spanner en los proyectos de aplicación 1 y aplicación 2 mediante las configuraciones enviadas por los componentes independientes de Cloud Scheduler en cada proyecto.

Función de reenvío

Cloud Scheduler solo puede publicar mensajes en temas del mismo proyecto, por lo que, para la topología distribuida, se requiere un componente intermedio llamado función de reenvío.

La función de reenvío reenvía los mensajes publicados en Pub/Sub desde Cloud Scheduler, verifica su sintaxis JSON y los reenvía al tema de sondeo de Pub/Sub. El tema puede pertenecer a un proyecto diferente al de Cloud Scheduler.

En el siguiente diagrama, se muestran los componentes que se usaron para el mecanismo de reenvío:

Mecanismo de reenvío.

Como se muestra en el diagrama anterior, las instancias de Spanner se encuentran en proyectos llamados Aplicación 1 y Aplicación 2:

  1. Cloud Scheduler es el mismo proyecto que las instancias de Spanner.

  2. (2a) Cloud Scheduler publica sus mensajes en el tema de reenvío en los proyectos de la Aplicación 1 y la Aplicación 2.

    (2b) La función de reenvío lee los mensajes del tema reenvío.

    (2c) La función de reenvío reenvía los mensajes al tema de sondeo que reside en el proyecto del escalador automático.

  3. La función de Poller lee los mensajes del tema de sondeo y continúa el proceso, como se describe en la sección Poller.

Una implementación distribuida tiene las siguientes ventajas y desventajas.

Ventajas:

  • Los equipos de aplicaciones controlan la configuración y los programas: Cloud Scheduler se implementa junto con las instancias de Spanner que se escalan de forma automática, lo que brinda a los equipos de aplicaciones un mayor control sobre la configuración y la programación.
  • El equipo de operaciones controla la infraestructura: Los componentes principales de la herramienta de escalamiento automático se implementan de forma centralizada, lo que permite que los equipos de operaciones controlen la infraestructura del escalador automático.
  • Mantenimiento centralizado: La infraestructura de escalador automático está centralizada, lo que reduce la sobrecarga.

Desventajas:

  • Configuración más compleja: Los equipos de aplicaciones deben proporcionar cuentas de servicio para escribir en el tema de sondeo.
  • Posible riesgo adicional: La infraestructura compartida puede convertirse en un punto único de fallo, incluso si la infraestructura está diseñada para ofrecer una alta disponibilidad.

Si quieres obtener información para configurar el escalador automático con una topología distribuida, consulta la guía paso a paso para la implementación distribuida.

¿Qué sigue?