Desplegar la herramienta de escalado automático en funciones de Cloud Run

La herramienta de escalado automático se ha diseñado para ofrecer flexibilidad y puede adaptarse a la separación de responsabilidades entre tus equipos de operaciones y de aplicaciones. La responsabilidad de configurar el escalado automático de las instancias de Spanner se puede centralizar en un solo equipo de operaciones o se puede distribuir entre los equipos que estén más cerca de las aplicaciones a las que dan servicio 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, operaciones y Site Reliability Engineering (SRE) que quieran reducir la sobrecarga operativa y optimizar el coste de las implementaciones de Spanner.

En esta página se describen tres formas de desplegar el escalador automático en funciones de Cloud Run, según tus requisitos:

  • Una topología de despliegue por proyecto. La infraestructura de la herramienta de adaptación dinámica se implementa en el mismo proyecto que Spanner, que es el que necesita la adaptación dinámica. Recomendamos esta topología a los equipos independientes que quieran gestionar su propia configuración de Autoscaler e infraestructura. Una topología de implementación por proyecto también es un buen punto de partida para probar las funciones del escalador automático.
  • Una topología de implementación centralizada. La herramienta de escalado automático se implementa en un proyecto y gestiona una o varias instancias de Spanner en diferentes proyectos. Recomendamos esta topología a los equipos que gestionan la configuración y la infraestructura de una o varias instancias de Spanner, al tiempo que mantienen los componentes y la configuración de Autoscaler en un lugar centralizado. En la topología centralizada, además de un proyecto de escalador automático, debes configurar un segundo proyecto, al que en este tutorial se hace referencia como 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 de Autoscaler se despliega en un proyecto, pero algunos componentes de la infraestructura se despliegan con las instancias de Spanner que se autoescalan en diferentes proyectos. Recomendamos esta topología a las organizaciones con varios equipos, en las que los equipos que son propietarios de las instancias de Spanner solo quieren gestionar los parámetros de configuración de la herramienta de escalado automático de sus instancias, pero el resto de la infraestructura de la herramienta de escalado automático está gestionada por un equipo central.

Sin servidor para facilitar la implementación y la gestión

En este modelo, la herramienta de autoescalado se crea usando solo herramientas sin servidor y de bajo mantenimiento, Google Cloud como Cloud Run functions, Pub/Sub, Cloud Scheduler y Firestore. Este enfoque minimiza el coste y la sobrecarga operativa de ejecutar la herramienta Autoscaler.

Gracias a las Google Cloud herramientas integradas, la herramienta de escalado automático puede aprovechar al máximo Gestión de Identidades y Accesos (IAM) para la autenticación y la autorización.

Configuración

La herramienta de escalado automático gestiona las instancias de Spanner mediante la configuración definida en Cloud Scheduler. Si es necesario sondear varias instancias de Spanner con el mismo intervalo, le recomendamos que las configure en el mismo trabajo de Cloud Scheduler. La configuración de cada instancia se representa como un objeto JSON. A continuación, se muestra un ejemplo de una configuración en la que se gestionan 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 tareas de Cloud Scheduler. Por ejemplo, una instancia puede tener una configuración de escalador automático con el método lineal para las operaciones normales, pero también puede tener otra configuración de escalador automático con el método directo para las cargas de trabajo por lotes planificadas.

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

Topología por proyecto

En una implementación de topología por proyecto, cada proyecto con una instancia de Spanner que necesite escalarse automáticamente también tiene su propia implementación independiente de los componentes de Autoscaler. Recomendamos esta topología a los equipos independientes que quieran gestionar su propia configuración de Autoscaler e infraestructura. También es un buen punto de partida para probar las funciones de la herramienta Autoscaler.

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

Implementación conceptual por proyecto.

Los despliegues por proyecto que se muestran en el diagrama anterior tienen estas características:

  • Dos aplicaciones, Aplicación 1 y Aplicación 2, cada una de las cuales usa sus propias instancias de Spanner.
  • Las instancias de Spanner (A) se encuentran en los proyectos Aplicación 1 y Aplicación 2, respectivamente.
  • Se implementa un escalador automático independiente (B) en cada proyecto para controlar el escalado automático de las instancias de un proyecto.

Una implementación por proyecto tiene las siguientes ventajas e inconvenientes.

Ventajas:

  • Diseño más sencillo: la topología por proyecto es la más sencilla de las tres, ya que todos los componentes de la herramienta de ajuste automático de escala se implementan junto con las instancias de Spanner cuya escala se ajusta automáticamente.
  • Configuración: el equipo propietario de la instancia de Spanner controla los parámetros del programador, lo que le da más libertad para adaptar la herramienta de escalado 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 sobre la infraestructura de Escalado automático, ya que el propietario del equipo de las instancias de Spanner también es el propietario de la infraestructura de Escalado automático.

Inconvenientes:

  • Más mantenimiento general: cada equipo es responsable de la configuración y la infraestructura de Autoscaler, por lo que puede resultar difícil asegurarse de que todas las herramientas de Autoscaler de la empresa sigan las mismas directrices de actualización.
  • Auditoría más compleja: como cada equipo tiene un alto nivel de control, una auditoría centralizada puede volverse más compleja.

Para saber cómo 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 Autoscaler se encuentran en el mismo proyecto. Sin embargo, las instancias de Spanner se encuentran en proyectos diferentes. Esta implementación es adecuada para un equipo que gestiona la configuración y la infraestructura de varias instancias de Spanner desde una única implementación de la herramienta de escalado automático en un lugar central.

En el siguiente diagrama se muestra una vista conceptual general de una implementación de proyecto centralizada:

Implementación de proyectos centralizada conceptual.

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, cada una de las cuales usa sus propias instancias de Spanner.
  • Las instancias de Spanner (A) están en los proyectos Aplicación 1 y Aplicación 2, respectivamente.
  • El escalador automático (B) se implementa en un proyecto independiente para controlar el escalado automático de las instancias de Spanner en los proyectos Aplicación 1 y Aplicación 2.

Una implementación centralizada tiene las siguientes ventajas e inconvenientes.

Ventajas:

  • Configuración e infraestructura centralizadas: un solo equipo controla los parámetros del programador y la infraestructura del escalador automático. Este enfoque puede ser útil en sectores muy regulados.
  • Menos mantenimiento general: el mantenimiento y la configuración suelen requerir menos esfuerzo que una implementación por proyecto.
  • Políticas y auditorías centralizadas: puede que sea más fácil especificar y aplicar las prácticas recomendadas en todos los equipos. Las auditorías pueden ser más fáciles de llevar a cabo.

Inconvenientes:

  • Configuración centralizada: cualquier cambio en los parámetros de Escalador automático debe pasar por el equipo centralizado, aunque el equipo que solicita el cambio sea el propietario de la instancia de Spanner.
  • Riesgo adicional: el propio equipo centralizado puede convertirse en un único punto de fallo, aunque la infraestructura de Escalador automático se haya diseñado teniendo en cuenta la alta disponibilidad.

Para saber cómo 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 se deben autoescalar se encuentran en el mismo proyecto. Los componentes restantes de la herramienta Autoscaler se encuentran en un proyecto gestionado de forma centralizada. Esta implementación es una implementación híbrida. Los equipos propietarios de las instancias de Spanner solo gestionan los parámetros de configuración de la herramienta de escalado automático de sus instancias, mientras que un equipo central gestiona el resto de la infraestructura de la herramienta de escalado automático.

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

Implementación conceptual de proyectos distribuidos.

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 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 de Escalador automático (B) se implementan en otro proyecto.
  • La herramienta de escalado automático escala automáticamente las instancias de Spanner en los proyectos Aplicación 1 y Aplicación 2 mediante las configuraciones enviadas por los componentes independientes de Cloud Scheduler de cada proyecto.

Función de reenvío

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

La función Forwarder toma los mensajes publicados en Pub/Sub desde Cloud Scheduler, comprueba su sintaxis JSON y los reenvía al tema de Pub/Sub Poller. El tema puede pertenecer a un proyecto independiente de Cloud Scheduler.

En el siguiente diagrama se muestran los componentes que se usan en 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 Forwarder de los proyectos Aplicación 1 y Aplicación 2.

    (2b) La función Forwarder lee los mensajes del tema Forwarder.

    (2c) La función Forwarder reenvía mensajes al tema Polling, que se encuentra en el proyecto Autoscaler.

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

Una implementación distribuida tiene las siguientes ventajas e inconvenientes.

Ventajas:

  • Los equipos de aplicaciones controlan la configuración y las programaciones: Cloud Scheduler se implementa junto con las instancias de Spanner que se escalan automáticamente, lo que ofrece a los equipos de aplicaciones más control sobre la configuración y la programación.
  • El equipo de Operaciones controla la infraestructura: los componentes principales de la herramienta de escalado automático se implementan de forma centralizada, lo que permite a los equipos de Operaciones controlar la infraestructura de escalado automático.
  • Mantenimiento centralizado: la infraestructura de Scaler está centralizada, lo que reduce los costes indirectos.

Inconvenientes:

  • Configuración más compleja: los equipos de aplicaciones deben proporcionar cuentas de servicio para escribir en el tema de sondeo.
  • Posibilidad de que se produzcan riesgos adicionales: la infraestructura compartida puede convertirse en un punto único de fallo, aunque se haya diseñado con una alta disponibilidad.

Para saber cómo configurar el escalador automático con una topología distribuida, consulta la guía paso a paso para la implementación distribuida.

Siguientes pasos