Patrón de aumentos de actividad de nube.

Last reviewed 2023-12-14 UTC

Las aplicaciones de Internet pueden experimentar fluctuaciones extremas en relación con el uso. Si bien la mayoría de las aplicaciones empresariales no enfrentan este desafío, muchas empresas deben lidiar con un tipo diferente de carga de trabajo inestable: los trabajos por lotes o de CI/CD.

Este patrón de arquitectura se basa en una implementación redundante de aplicaciones en varios entornos de computación. El objetivo es aumentar la capacidad, la resiliencia o ambas.

Si bien puedes acomodar las cargas de trabajo inestables en un entorno de computación basado en centros de datos mediante el aprovisionamiento excesivo de recursos, este enfoque podría no ser rentable. En los trabajos por lotes, puedes optimizar el uso con una ejecución extendida durante períodos más largos. Sin embargo, retrasar los trabajos no es práctico si son urgentes.

La idea del patrón de aumentos de actividad de nube es usar de forma temporal un entorno de computación privado para la carga y el aumento de actividad del modelo de referencia en la nube cuando necesites capacidad adicional.

Datos que fluyen de un entorno local a Google Cloud en modo de aumento de actividad.

En el diagrama anterior, cuando la capacidad de datos está al límite en un entorno privado local, el sistema puede obtener capacidad adicional de un entorno de Google Cloud cuando sea necesario.

Los factores clave de este patrón son ahorrar dinero y reducir el tiempo y el esfuerzo necesarios para responder a los cambios de los requisitos de escalamiento. Con este enfoque, solo pagas por los recursos que se usan cuando se manejan cargas adicionales. Esto significa que no necesitas aprovisionar en exceso tu infraestructura. En su lugar, puedes aprovechar los recursos de la nube a pedido y escalarlos para que se ajusten a la demanda y a cualquier métrica predefinida. Como resultado, tu empresa puede evitar interrupciones del servicio durante los momentos de mayor demanda.

Un requisito potencial para las situaciones de aumentos de actividad en la nube es la portabilidad de la carga de trabajo. Cuando permitas que las cargas de trabajo se implementen en múltiples entornos, debes abstraer las diferencias entre los entornos. Por ejemplo, Kubernetes te permite lograr la coherencia a nivel de la carga de trabajo en diversos entornos que usan diferentes infraestructuras. Para obtener más información, consulta Arquitectura de referencia del entorno híbrido de GKE Enterprise.

Consideraciones del diseño

El patrón de picos de actividad de nube se aplica a cargas de trabajo interactivas y por lotes. Sin embargo, cuando se trata de cargas de trabajo interactivas, debes determinar cómo distribuir las solicitudes entre los entornos:

  • Puedes enrutar las solicitudes entrantes de los usuarios a un balanceador de cargas que se ejecuta en el centro de datos existente y, luego, hacer que este distribuya las solicitudes a través de los recursos locales y de nube.

    Este enfoque requiere que el balanceador de cargas o algún otro sistema que se ejecute en el centro de datos existente también realice un seguimiento de los recursos asignados en la nube. El balanceador de cargas o algún otro sistema también deben iniciar el aumento o la reducción de escala automáticos de los recursos. Con este enfoque, puedes retirar todos los recursos de nube en momentos de baja actividad. Sin embargo, la implementación de mecanismos para realizar un seguimiento de los recursos podría superar las capacidades de las soluciones del balanceador de cargas y, por lo tanto, aumentar la complejidad general.

  • En lugar de implementar mecanismos para realizar seguimientos de los recursos, puedes usar Cloud Load Balancing con un backend de grupo de extremos de red (NEG) de conectividad híbrida. Usa este balanceador de cargas para enrutar las solicitudes de clientes internas o las solicitudes de clientes externos a los backends que se encuentran en entornos locales y en Google Cloud y que se basan en diferentes métricas, como la división del tráfico basada en el peso. También puedes escalar backends según la capacidad de entrega de balanceo de cargas para cargas de trabajo en Google Cloud. Para obtener más información, consulta Descripción general de la administración del tráfico en el balanceador de cargas de aplicaciones externo global.

    Este enfoque tiene varios beneficios adicionales, como el uso de las capacidades de protección contra DSD de Google Cloud Armor, WAF y el contenido del almacenamiento en caché en el perímetro de la nube mediante Cloud CDN. Sin embargo, debes ajustar el tamaño de la conectividad de red híbrida para manejar el tráfico adicional.

  • Como se destaca en Portabilidad de la carga de trabajo, una aplicación puede ser portátil a un entorno diferente con cambios mínimos para lograr la coherencia de la carga de trabajo, pero eso no significa que la aplicación funciona de la misma manera en ambos entornos. Por lo general, las diferencias en la computación subyacente, las capacidades de seguridad de la infraestructura o la infraestructura de herramientas de redes, junto con la proximidad a servicios dependientes, determinan el rendimiento. A través de las pruebas, puedes tener una visibilidad más precisa y comprender las expectativas de rendimiento.

  • Puedes usar los servicios de infraestructura de nube para crear un entorno para alojar tus aplicaciones sin portabilidad. Usa los siguientes enfoques para controlar las solicitudes de los clientes cuando se redirecciona el tráfico durante los momentos de mayor demanda:

    • Usa herramientas coherentes para supervisar y administrar estos dos entornos.
    • Garantiza que el control de versiones de las cargas de trabajo sea coherente y que tus fuentes de datos estén actualizadas.
    • Es posible que debas agregar automatización para aprovisionar el entorno de nube y redirigir el tráfico cuando la demanda aumente y se espera que la carga de trabajo en la nube acepte solicitudes de clientes para tu aplicación.
  • Si quieres cerrar todos los recursos de Google Cloud en momentos de baja demanda, es posible que el uso de políticas de enrutamiento de DNS principalmente para el balanceo de cargas de tráfico no siempre sea óptimo. Esto se debe principalmente a los siguientes motivos:

    • Los recursos pueden requerir un tiempo para inicializarse antes de que puedan entregar a los usuarios.
    • Las actualizaciones de DNS tienden a propagarse con lentitud en Internet.

    Estos fueron algunos de los resultados:

    • Es posible que los usuarios se enruten al entorno de Cloud incluso cuando no haya recursos disponibles para procesar sus solicitudes.
    • Es posible que los usuarios se sigan enrutando al entorno local de forma temporal mientras se propagan las actualizaciones de DNS en Internet.

Con Cloud DNS, puedes elegir la política de DNS y de enrutamiento que se alinee con la arquitectura y el comportamiento de tu solución, como las políticas de enrutamiento de DNS de ubicación geográfica. Cloud DNS también admite verificaciones de estado para el balanceador de cargas de red de transferencia interno y el balanceador de cargas de aplicaciones interno. En cuyo caso, puedes incorporarlo con tu configuración general de DNS híbrido a partir de este patrón.

En algunas situaciones, puedes usar Cloud DNS para distribuir solicitudes de clientes con verificaciones de estado en Google Cloud, como cuando usas balanceadores de cargas de aplicaciones internos o balanceadores de cargas de aplicaciones internos entre regiones. En esta situación, Cloud DNS verifica el estado general del balanceador de cargas de aplicaciones interno, que verifica el estado de las instancias de backend. Para obtener más información, consulta Administra las políticas de enrutamiento de DNS y las verificaciones de estado.

También puedes usar el horizonte dividido de Cloud DNS. El horizonte dividido de Cloud DNS es un enfoque para configurar respuestas o registros DNS a la ubicación o red específica del creador de consultas de DNS para el mismo nombre de dominio. Por lo general, este enfoque se usa para abordar los requisitos en los que una aplicación está diseñada para ofrecer una experiencia privada y pública, cada una con características únicas. El enfoque también ayuda a distribuir la carga de tráfico entre los entornos.

Dadas estas configuraciones, el patrón de aumentos de actividad en la nube se suele prestar mejor para cargas de trabajo por lotes que cargas de trabajo interactivas.

Ventajas

Estas son algunas de las ventajas clave del patrón de arquitectura de aumentos de actividad en la nube:

  • El patrón de aumentos de actividad en la nube te permite volver a usar las inversiones existentes en centros de datos y entornos de computación privados. Esta acción puede ser permanente o durar hasta que se deba reemplazar el equipo existente. En ese momento, podrías considerar una migración total.
  • Debido a que ya no tienes que mantener un exceso de capacidad para satisfacer las demandas máximas, es posible que puedas aumentar el uso y la rentabilidad de tus entornos de computación privados.
  • El patrón de picos de actividad de nube te permite ejecutar trabajos por lotes de manera oportuna sin la necesidad de aprovisionar recursos de procesamiento en exceso.

Prácticas recomendadas

Cuando implementes el patrón de picos de actividad de nube, ten en cuenta las siguientes recomendaciones:

  • Para garantizar que las cargas de trabajo que se ejecutan en la nube puedan acceder a los recursos de la misma manera que las cargas de trabajo que se ejecutan en un entorno local, usa el patrón de malla con el principio de acceso de seguridad con menos privilegios. Si el diseño de la carga de trabajo lo permite, solo puedes permitir el acceso desde la nube al entorno de computación local, no al revés.
  • Para minimizar la latencia para la comunicación entre entornos, elige una región de Google Cloud que esté geográficamente cerca de tu entorno de computación privado. Si deseas obtener más información, consulta Prácticas recomendadas para la selección de regiones de Compute Engine.
  • Cuando usas los aumentos de actividad en la nube solo para cargas de trabajo por lotes, mantén todos los recursos de Google Cloud en privado para reducir la superficie de ataque de seguridad. No permitas el acceso directo desde Internet a estos recursos, incluso si usas el balanceo de cargas externo de Google Cloud para proporcionar el punto de entrada a la carga de trabajo.
  • Selecciona la política de DNS y de enrutamiento que se alinee con tu patrón de arquitectura y el comportamiento de la solución objetivo.

    • Como parte de este patrón, puedes aplicar el diseño de tus políticas de DNS de forma permanente o cuando necesites capacidad adicional con otro entorno durante los momentos de mayor demanda.
    • Puedes usar políticas de enrutamiento de DNS de ubicación geográfica para tener un extremo de DNS global para tus balanceadores de cargas regionales. Esta táctica tiene muchos casos de uso para las políticas de enrutamiento de DNS de ubicación geográfica, incluidas las aplicaciones híbridas que usan Google Cloud junto con una implementación local en la que existe la región de Google Cloud.
    • Si necesitas proporcionar diferentes registros para las mismas consultas de DNS, puedes usar el DNS de horizonte dividido, por ejemplo, consultas de clientes internos y externos.

      Si deseas obtener más información, consulta arquitecturas de referencia para DNS híbrido.

  • Para garantizar que los cambios de DNS se propaguen con rapidez, configura tu DNS con un valor de tiempo de actividad razonablemente corto para poder redirigir a los usuarios a sistemas en modo de espera cuando necesites capacidad adicional con entornos de nube.

  • Para trabajos que no son fundamentales para el tiempo y no almacenan datos de forma local, considera usar instancias de VM Spot, que son mucho más económicas que las instancias de VM normales. Sin embargo, un requisito es que si el trabajo de VM se interrumpe, el sistema debe poder reiniciar el trabajo de forma automática.

  • Usa contenedores para lograr la portabilidad de la carga de trabajo cuando corresponda. Además, GKE Enterprise puede ser una tecnología clave para habilitar ese diseño. Para obtener más información, consulta Arquitectura de referencia del entorno híbrido de GKE Enterprise.

  • Supervisa el tráfico enviado desde Google Cloud a un entorno de computación diferente. Este tráfico está sujeto a los cargos de transferencia de datos salientes.

  • Si planeas usar esta arquitectura a largo plazo con un alto volumen de transferencia de datos salientes, considera usar Cloud Interconnect. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y puede reducir los cargos por transferencia de datos salientes para el tráfico que cumple con ciertas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.

  • Cuando se use Cloud Load Balancing, debes usar sus capacidades de optimización de la capacidad de la aplicación cuando corresponda. Esto puede ayudarte a abordar algunos de los desafíos de capacidad que pueden ocurrir en las aplicaciones distribuidas a nivel global.

  • Autentica a las personas que usan tus sistemas mediante el establecimiento de una identidad común entre los entornos para que los sistemas puedan autenticarse de manera segura a través de los límites del entorno.

  • Para proteger la información sensible, se recomienda encriptar todas las comunicaciones en tránsito. Si se requiere encriptación en la capa de conectividad, hay varias opciones disponibles según la solución de conectividad híbrida seleccionada. Estas opciones incluyen túneles VPN, VPN con alta disponibilidad en Cloud Interconnect y MACsec para Cloud Interconnect.