Patrones para aplicaciones escalables y resilientes

En este documento se presentan algunos patrones y prácticas para crear aplicaciones que sean robustas y escalables, dos objetivos esenciales de muchos ejercicios de arquitectura modernos. Una aplicación bien diseñada se adapta a los aumentos y las disminuciones de la demanda, y es lo suficientemente resistente como para soportar interrupciones del servicio. Para crear y gestionar aplicaciones que cumplan estos requisitos, es necesario planificar y diseñar cuidadosamente.

Escalabilidad: ajustar la capacidad para satisfacer la demanda

La escalabilidad es la capacidad de un sistema para gestionar cantidades de trabajo variables añadiendo o quitando recursos del sistema. Por ejemplo, una aplicación web escalable es aquella que funciona bien con uno o muchos usuarios y que gestiona correctamente los picos y los descensos de tráfico.

La flexibilidad para ajustar los recursos que consume una aplicación es un factor empresarial clave para migrar a la nube. Si diseñas bien tu aplicación, puedes reducir los costes eliminando los recursos infrautilizados sin comprometer el rendimiento ni la experiencia de usuario. Del mismo modo, puedes mantener una buena experiencia de usuario durante los periodos de mucho tráfico añadiendo más recursos. De esta forma, tu aplicación solo puede consumir los recursos necesarios para satisfacer la demanda.

Google Cloud proporciona productos y funciones para ayudarte a crear aplicaciones escalables y eficientes:

• Las máquinas virtuales de Compute Engine y los clústeres de Google Kubernetes Engine (GKE) se integran con escaladores automáticos que te permiten aumentar o reducir el consumo de recursos en función de las métricas que definas.
• La plataforma sin servidor deGoogle Cloudproporciona servicios gestionados de computación, bases de datos y otros que se escalan rápidamente de cero a volúmenes de solicitudes altos, y solo pagas por lo que usas.
• Los productos de bases de datos, como BigQuery, Spanner y Bigtable, pueden ofrecer un rendimiento constante en conjuntos de datos de gran tamaño.
• Cloud Monitoring proporciona métricas de tus aplicaciones e infraestructura, lo que te ayuda a tomar decisiones de escalado basadas en datos.

Resiliencia: diseñar para resistir fallos

Una aplicación resistente es aquella que sigue funcionando a pesar de los fallos de los componentes del sistema. La resiliencia requiere planificación en todos los niveles de tu arquitectura. Influye en la forma en que diseñas tu infraestructura y tu red, así como en el diseño de tu aplicación y el almacenamiento de datos. La resiliencia también se aplica a las personas y a la cultura.

Crear y operar aplicaciones resilientes es difícil. Esto es especialmente cierto en el caso de las aplicaciones distribuidas, que pueden contener varias capas de infraestructura, redes y servicios. Los errores y las interrupciones son inevitables, por lo que mejorar la resiliencia de tu aplicación es un proceso continuo. Si planificas bien el proceso, puedes mejorar la capacidad de tu aplicación para resistir fallos. Con los procesos y la cultura organizativa adecuados, también puedes aprender de los errores para aumentar aún más la resiliencia de tu aplicación.

Google Cloud proporciona herramientas y servicios que te ayudan a crear aplicaciones de alta disponibilidad y resilientes:

• Los servicios deGoogle Cloud están disponibles en regiones y zonas de todo el mundo, lo que te permite desplegar tu aplicación para alcanzar tus objetivos de disponibilidad.
• Los grupos de instancias de Compute Engine y los clústeres de GKE se pueden distribuir y gestionar en las zonas disponibles de una región.
• Los discos persistentes regionales de Compute Engine se replican de forma síncrona en las zonas de una región.
• Google Cloud ofrece una serie de opciones de balanceo de carga para gestionar el tráfico de tu aplicación, incluido el balanceo de carga global, que puede dirigir el tráfico a la región en buen estado más cercana a tus usuarios.
• La plataforma sin servidor deGoogle Cloudincluye productos de computación y de bases de datos gestionados que ofrecen redundancia y equilibrio de carga integrados.
• Cloud Build ejecuta tus compilaciones en Google Cloud y te permite desplegar en plataformas como App Engine, Compute Engine, Cloud Run y GKE.
• Cloud Monitoring proporciona métricas de tus aplicaciones e infraestructura, lo que te ayuda a tomar decisiones basadas en datos sobre el rendimiento y el estado de tus aplicaciones.

Factores y restricciones

Los requisitos y las motivaciones para mejorar la escalabilidad y la resiliencia de tu aplicación varían. También puede haber limitaciones que te impidan alcanzar tus objetivos de escalabilidad y resiliencia. La importancia relativa de estos requisitos y limitaciones varía en función del tipo de aplicación, el perfil de tus usuarios y la escala y la madurez de tu organización.

Controladores

Para priorizar tus requisitos, ten en cuenta los factores de las diferentes partes de tu organización.

Factores empresariales

Entre los factores habituales del lado de la empresa se incluyen los siguientes:

• Optimizar los costes y el consumo de recursos.
• Minimizar el tiempo de inactividad de las aplicaciones.
• Asegúrate de que se pueda satisfacer la demanda de los usuarios durante los periodos de uso elevado.
• Mejorar la calidad y la disponibilidad del servicio.
• Asegúrate de que la experiencia de usuario y la confianza se mantengan durante las interrupciones.
• Aumentar la flexibilidad y la agilidad para hacer frente a los cambios en las demandas del mercado.

Controladores de desarrollo

Entre los factores habituales del lado del desarrollo se incluyen los siguientes:

• Minimizar el tiempo dedicado a investigar los fallos.
• Aumentar el tiempo dedicado al desarrollo de nuevas funciones.
• Minimiza el trabajo repetitivo mediante la automatización.
• Crea aplicaciones con los patrones y las prácticas más recientes del sector.

Factores operativos

Estos son algunos de los requisitos que se deben tener en cuenta desde el punto de vista de las operaciones:

• Reducir la frecuencia de los fallos que requieren la intervención humana.
• Aumenta la capacidad de recuperación automática ante fallos.
• Minimiza el trabajo repetitivo mediante la automatización.
• Minimizar el impacto del fallo de cualquier componente concreto.

Restricciones

Las restricciones pueden limitar tu capacidad para aumentar la escalabilidad y la resiliencia de tu aplicación. Asegúrate de que tus decisiones de diseño no introduzcan ni contribuyan a estas restricciones:

• Dependencias de hardware o software difíciles de escalar.
• Dependencias de hardware o software que son difíciles de operar en una configuración de alta disponibilidad.
• Dependencias entre aplicaciones.
• Restricciones de licencias.
• Falta de habilidades o experiencia en tus equipos de desarrollo y operaciones.
• Resistencia de la organización a la automatización.

Patrones y prácticas

En el resto de este documento se definen patrones y prácticas para ayudarte a crear aplicaciones resilientes y escalables. Estos patrones afectan a todas las partes del ciclo de vida de tu aplicación, incluido el diseño de la infraestructura, la arquitectura de la aplicación, las opciones de almacenamiento, los procesos de implementación y la cultura de la organización.

En los patrones se observan tres temas:

• Automatización Para crear aplicaciones escalables y resilientes, es necesario automatizar los procesos. Automatizar el aprovisionamiento, las pruebas y los despliegues de aplicaciones de tu infraestructura aumenta la coherencia y la velocidad, y minimiza los errores humanos.
• Bajo acoplamiento: Si tratas tu sistema como una colección de componentes independientes y poco acoplados, podrás disfrutar de flexibilidad y resiliencia. La independencia abarca cómo distribuyes físicamente tus recursos, cómo diseñas tu aplicación y cómo diseñas tu almacenamiento.
• Diseño basado en datos. Recopilar métricas para entender el comportamiento de tu aplicación es fundamental. Las decisiones sobre cuándo escalar tu aplicación o si un servicio concreto no funciona correctamente deben basarse en datos. Las métricas y los registros deben ser funciones principales.

Automatizar el aprovisionamiento de la infraestructura

Crea una infraestructura inmutable mediante la automatización para mejorar la coherencia de tus entornos y aumentar el éxito de tus implementaciones.

Trata la infraestructura como código

La infraestructura como código (IaC) es una técnica que te anima a tratar el aprovisionamiento y la configuración de tu infraestructura de la misma forma que gestionas el código de la aplicación. Tu lógica de aprovisionamiento y configuración se almacena en el control de origen para que se pueda descubrir, versionar y auditar. Como está en un repositorio de código, puedes aprovechar las ventajas de los flujos de procesamiento de integración y despliegue continuos (CI/CD), de forma que cualquier cambio en tu configuración se pueda probar y desplegar automáticamente.

Al eliminar los pasos manuales de tu aprovisionamiento de infraestructura, IaC minimiza los errores humanos y mejora la coherencia y la reproducibilidad de tus aplicaciones y entornos. De esta forma, adoptar IaC aumenta la resiliencia de tus aplicaciones.

Infrastructure Manager te permite automatizar la creación y la gestión de recursos de Google Cloud . También puedes usar Config Connector para gestionar tus recursos con técnicas y flujos de trabajo de Kubernetes. Google Cloud También tiene compatibilidad integrada con herramientas de IaC de terceros populares, como Terraform, Chef y Puppet.

Crear una infraestructura inmutable

La infraestructura inmutable es una filosofía que se basa en las ventajas de la infraestructura como código. La infraestructura inmutable exige que los recursos no se modifiquen nunca después de su implementación. Si es necesario actualizar una máquina virtual, un clúster de Kubernetes o una regla de firewall, puedes actualizar la configuración del recurso en el repositorio de origen. Una vez que hayas probado y validado los cambios, vuelve a desplegar el recurso por completo con la nueva configuración. Es decir, en lugar de modificar los recursos, los vuelves a crear.

Crear una infraestructura inmutable conlleva despliegues y restauraciones más predecibles. También mitiga los problemas habituales en las infraestructuras mutables, como la deriva de la configuración y los servidores snowflake. De esta forma, la adopción de una infraestructura inmutable mejora aún más la coherencia y la fiabilidad de tus entornos.

Diseñar un sistema de alta disponibilidad

La disponibilidad es una medida de la fracción de tiempo que un servicio está disponible. La disponibilidad se suele usar como indicador clave del estado general del servicio. Las arquitecturas de alta disponibilidad tienen como objetivo maximizar la disponibilidad de los servicios, normalmente mediante el despliegue redundante de componentes. En términos sencillos, conseguir una alta disponibilidad suele implicar distribuir recursos de computación, equilibrar la carga y replicar datos.

Distribuir recursos físicamente

Los servicios deGoogle Cloud están disponibles en ubicaciones de todo el mundo. Estas ubicaciones se dividen en regiones y zonas. La forma en que despliegues tu aplicación en estas regiones y zonas afectará a la disponibilidad, la latencia y otras propiedades de tu aplicación. Para obtener más información, consulta las prácticas recomendadas para seleccionar la región de Compute Engine.

La redundancia es la duplicación de los componentes de un sistema para aumentar la disponibilidad general de ese sistema. En Google Cloud, la redundancia se consigue normalmente desplegando tu aplicación o servicio en varias zonas o incluso en varias regiones. Si un servicio está disponible en varias zonas o regiones, puede resistir mejor las interrupciones del servicio en una zona o región concreta. Aunque Google Cloud hace todo lo posible para evitar estas interrupciones, ciertos eventos son impredecibles y es mejor estar preparado.

Con los grupos de instancias gestionados de Compute Engine, puedes distribuir instancias de máquina virtual en varias zonas de una región y gestionar las instancias como una unidad lógica. Google Cloud también ofrece discos persistentes regionales para replicar automáticamente tus datos en dos zonas de una región.

Del mismo modo, puedes mejorar la disponibilidad y la resiliencia de tus aplicaciones desplegadas en GKE creando clústeres regionales. Un clúster regional distribuye los componentes del plano de control, los nodos y los pods de GKE en varias zonas de una región. Como los componentes del plano de control están distribuidos, puedes seguir accediendo al plano de control del clúster incluso durante una interrupción que afecte a una o varias zonas (pero no a todas).

Favorecer los servicios gestionados

En lugar de instalar, mantener y operar de forma independiente todas las partes de tu pila de aplicaciones, puedes usar servicios gestionados para consumir partes de tu pila de aplicaciones como servicios. Por ejemplo, en lugar de instalar y gestionar una base de datos MySQL en máquinas virtuales, puedes usar una base de datos MySQL proporcionada por Cloud SQL. De esta forma, obtendrás un acuerdo de nivel de servicio (SLA) de disponibilidad y podrás confiar en Google Cloud para gestionar la replicación de datos, las copias de seguridad y la infraestructura subyacente. Si usas servicios gestionados, puedes dedicar menos tiempo a gestionar la infraestructura y más a mejorar la fiabilidad de tu aplicación.

Muchos de los servicios de computación, bases de datos y almacenamiento gestionados de Google Cloudofrecen redundancia integrada, lo que puede ayudarte a alcanzar tus objetivos de disponibilidad. Muchos de estos servicios ofrecen un modelo regional, lo que significa que la infraestructura que ejecuta tu aplicación se encuentra en una región específica y Google la gestiona para que esté disponible de forma redundante en todas las zonas de esa región. Si una zona deja de estar disponible, tu aplicación o tus datos se servirán automáticamente desde otra zona de la región.

Algunos servicios de bases de datos y de almacenamiento también ofrecen disponibilidad multirregional, lo que significa que la infraestructura que ejecuta tu aplicación se encuentra en varias regiones. Los servicios multirregionales pueden resistir la pérdida de una región completa, pero normalmente a costa de una mayor latencia.

Equilibrio de carga en cada nivel

El balanceo de carga le permite distribuir el tráfico entre grupos de recursos. Al distribuir el tráfico, te aseguras de que los recursos individuales no se sobrecarguen mientras otros permanecen inactivos. La mayoría de los balanceadores de carga también ofrecen funciones de comprobación del estado para asegurarse de que el tráfico no se dirige a recursos que no están en buen estado o que no están disponibles.

Google Cloud ofrece varias opciones de balanceo de carga. Si tu aplicación se ejecuta en Compute Engine o GKE, puedes elegir el tipo de balanceador de carga más adecuado en función del tipo, la fuente y otros aspectos del tráfico. Para obtener más información, consulta la descripción general del balanceo de carga y la descripción general de la red de GKE.

También puedes usar algunos servicios gestionados por Google Cloud, como App Engine y Cloud Run, que equilibran la carga del tráfico automáticamente.

Es una práctica habitual balancear la carga de las solicitudes recibidas de fuentes externas, como clientes web o móviles. Sin embargo, usar balanceadores de carga entre diferentes servicios o niveles de tu aplicación también puede aumentar la resiliencia y la flexibilidad. Google Cloud proporciona balanceo de carga interno de capa 4 y de capa 7 para este fin.

En el siguiente diagrama se muestra un balanceador de carga externo que distribuye el tráfico global entre dos regiones, us-central1 y asia-east1. También se muestra el balanceo de carga interno que distribuye el tráfico de la capa web a la capa interna de cada región.

Monitorizar la infraestructura y las aplicaciones

Antes de decidir cómo mejorar la resiliencia y la escalabilidad de tu aplicación, debes entender su comportamiento. Tener acceso a un conjunto completo de métricas y series temporales relevantes sobre el rendimiento y el estado de tu aplicación puede ayudarte a detectar posibles problemas antes de que provoquen una interrupción. También pueden ayudarte a diagnosticar y resolver una interrupción si se produce. El capítulo sobre monitorización de sistemas distribuidos del libro de SRE de Google ofrece una buena descripción general de algunos enfoques de la monitorización.

Además de ofrecer información valiosa sobre el estado de tu aplicación, las métricas también se pueden usar para controlar el comportamiento del escalado automático de tus servicios.

Cloud Monitoring es la herramienta de monitorización integrada de Google Cloud. Cloud Monitoring ingiere eventos, métricas y metadatos, y proporciona información valiosa a través de paneles de control y alertas. La mayoría de los Google Cloud servicios envían automáticamentemétricas a Cloud Monitoring y Google Cloud también admiten muchas fuentes de terceros. Cloud Monitoring también se puede usar como backend para herramientas de monitorización de código abierto populares, lo que te ofrece un panel centralizado para observar tu aplicación.

Monitorización en todos los niveles

Recoger métricas en varios niveles o capas de tu arquitectura te proporciona una visión global del estado y el comportamiento de tu aplicación.

Monitorización de infraestructuras

La monitorización a nivel de infraestructura proporciona el estado y el rendimiento de referencia de tu aplicación. Este enfoque de monitorización recoge información como la carga de la CPU, el uso de la memoria y el número de bytes escritos en el disco. Estas métricas pueden indicar que una máquina está sobrecargada o que no funciona como se espera.

Además de las métricas que se recogen automáticamente, Cloud Monitoring proporciona un agente que se puede instalar para recoger información más detallada de las VMs de Compute Engine, incluidas las aplicaciones de terceros que se ejecutan en esas máquinas.

Monitorización de aplicaciones

Te recomendamos que registres métricas a nivel de aplicación. Por ejemplo, puede medir cuánto tiempo se tarda en ejecutar una consulta concreta o en realizar una secuencia relacionada de llamadas de servicio. Usted define estas métricas a nivel de aplicación. Recogen información que las métricas integradas de Cloud Monitoring no pueden. Las métricas a nivel de aplicación pueden registrar condiciones agregadas que reflejan mejor los flujos de trabajo clave y pueden revelar problemas que las métricas de infraestructura de bajo nivel no detectan.

También te recomendamos que uses OpenTelemetry para capturar las métricas a nivel de aplicación. OpenTelemetry proporciona un solo estándar abierto para los datos de telemetría. Usa OpenTelemetry para recoger y exportar datos de tus aplicaciones e infraestructura de la nube. Después, puede monitorizar y analizar los datos de telemetría exportados.

Service Monitoring

En las aplicaciones distribuidas y basadas en microservicios, es importante monitorizar las interacciones entre los diferentes servicios y componentes de las aplicaciones. Estas métricas pueden ayudarte a diagnosticar problemas como el aumento del número de errores o la latencia entre servicios.

Cloud Service Mesh es una malla de servicios disponible en Google Cloud que te permite gestionar, observar, medir y proteger tus microservicios en la infraestructura que elijas, tanto on-premise como fuera de ella. Google Cloud

Monitorización integral

La monitorización integral, también llamada monitorización de usuarios finales, prueba el comportamiento visible externamente de la misma forma que lo ve un usuario. Este tipo de monitorización comprueba si un usuario puede completar acciones críticas dentro de los umbrales definidos. Esta monitorización general puede detectar errores o latencias que la monitorización más detallada no detectaría, y revela la disponibilidad tal como la percibe el usuario.

Exponer el estado de tus aplicaciones

Un sistema de alta disponibilidad debe tener alguna forma de determinar qué partes del sistema están en buen estado y funcionan correctamente. Si determinados recursos no funcionan correctamente, el sistema puede enviar solicitudes a otro lugar. Normalmente, las comprobaciones de estado implican extraer datos de un endpoint para determinar el estado o el buen funcionamiento de un servicio.

La comprobación del estado es una tarea fundamental de los balanceadores de carga. Cuando creas un balanceador de carga asociado a un grupo de instancias de máquina virtual, también defines una comprobación del estado. La comprobación del estado define cómo se comunica el balanceador de carga con las máquinas virtuales para evaluar si determinadas instancias deben seguir recibiendo tráfico. Las comprobaciones del estado de los balanceadores de carga también se pueden usar para reparar automáticamente grupos de instancias de forma que se vuelvan a crear las máquinas en mal estado. Si usas GKE y balanceas la carga del tráfico externo a través de un recurso de entrada, GKE crea automáticamente las comprobaciones de estado adecuadas para el balanceador de carga.

Kubernetes tiene compatibilidad integrada con las comprobaciones de vivacidad y preparación. Estas sondas ayudan al orquestador de Kubernetes a decidir cómo gestionar los pods y las solicitudes de tu clúster. Si tu aplicación se ha desplegado en Kubernetes, es recomendable exponer el estado de la aplicación a estas sondas a través de los endpoints adecuados.

Establecer métricas clave

La monitorización y las comprobaciones de estado te proporcionan métricas sobre el comportamiento y el estado de tu aplicación. El siguiente paso es analizar esas métricas para determinar cuáles son las más descriptivas o las que tienen más impacto. Las métricas clave varían en función de la plataforma en la que se implemente la aplicación y del trabajo que realice.

Es poco probable que encuentres una sola métrica que indique si debes escalar tu aplicación o si un servicio concreto no funciona correctamente. A menudo, se trata de una combinación de factores que, en conjunto, indican un conjunto de condiciones. Con Cloud Monitoring, puedes crear métricas personalizadas para registrar estas condiciones. El libro de SRE de Google recomienda cuatro señales de oro para monitorizar un sistema orientado al usuario: latencia, tráfico, errores y saturación.

También debes tener en cuenta tu tolerancia a los valores atípicos. Usar un valor medio o mediano para medir el estado o el rendimiento puede no ser la mejor opción, ya que estas medidas pueden ocultar grandes desequilibrios. Por lo tanto, es importante tener en cuenta la distribución de la métrica. El percentil 99 puede ser una medida más informativa que la media.

Definir objetivos de nivel de servicio

Puede usar las métricas que recoge su sistema de monitorización para definir objetivos de nivel de servicio. Los SLOs especifican un nivel de rendimiento o fiabilidad objetivo para tu servicio. Los OLS son un pilar fundamental de las prácticas de SRE y se describen en detalle en el capítulo Objetivos de nivel de servicio del libro de SRE, así como en el capítulo Implementación de OLS del libro de trabajo de SRE.

Puedes usar la monitorización de servicios para definir SLOs basados en las métricas de Cloud Monitoring. Puedes crear políticas de alertas para objetivos de nivel de servicio (SLOs) para saber si corres el riesgo de infringir alguno de ellos.

Almacenar las métricas

Las métricas de tu sistema de monitorización son útiles a corto plazo para ayudarte con las comprobaciones del estado en tiempo real o para investigar problemas recientes. Cloud Monitoring conserva tus métricas durante varias semanas para adaptarse mejor a esos casos prácticos.

Sin embargo, también es útil almacenar las métricas de monitorización para realizar análisis a largo plazo. Tener acceso a un registro histórico puede ayudarte a adoptar un enfoque basado en datos para perfeccionar la arquitectura de tu aplicación. Puedes usar los datos recogidos durante y después de una interrupción para identificar cuellos de botella e interdependencias en tus aplicaciones. También puede usar los datos para crear y validar pruebas significativas.

El historial de datos también puede ayudarte a validar que tu aplicación cumple los objetivos empresariales durante periodos clave. Por ejemplo, los datos pueden ayudarte a analizar cómo se ha escalado tu aplicación durante eventos promocionales con mucho tráfico a lo largo de los últimos trimestres o incluso años.

Para obtener información sobre cómo exportar y almacenar tus métricas, consulta la solución Exporta métricas con Cloud Monitoring.

Determinar el perfil de escalado

Quieres que tu aplicación cumpla sus objetivos de experiencia de usuario y rendimiento sin aprovisionar recursos en exceso.

En el siguiente diagrama se muestra una representación simplificada del perfil de escalado de una aplicación. La aplicación mantiene un nivel de recursos de referencia y usa el autoescalado para responder a los cambios en la demanda.

Equilibrar el coste y la experiencia de usuario

Decidir si quieres escalar tu aplicación se basa fundamentalmente en equilibrar el coste y la experiencia de usuario. Decide cuál es el nivel mínimo de rendimiento aceptable y, si quieres, también el máximo. Estos umbrales varían de una aplicación a otra y también pueden variar entre los diferentes componentes o servicios de una misma aplicación.

Por ejemplo, una aplicación web o móvil orientada al consumidor puede tener objetivos de latencia estrictos. Las investigaciones demuestran que incluso los pequeños retrasos pueden afectar negativamente a la forma en que los usuarios perciben tu aplicación, lo que se traduce en menos conversiones y registros. Por lo tanto, es importante asegurarse de que su aplicación tenga suficiente capacidad de servicio para responder rápidamente a las solicitudes de los usuarios. En este caso, los costes más elevados de ejecutar más servidores web podrían estar justificados.

La relación coste-rendimiento puede ser diferente en una aplicación interna no crítica para la empresa, donde los usuarios probablemente toleren mejor los pequeños retrasos. Por lo tanto, tu perfil de escalado puede ser menos agresivo. En este caso, mantener los costes bajos puede ser más importante que optimizar la experiencia de usuario.

Definir recursos de referencia

Otro componente clave de tu perfil de escalado es decidir un conjunto mínimo de recursos adecuado.

Las máquinas virtuales de Compute Engine o los clústeres de GKE suelen tardar en escalarse verticalmente, ya que es necesario crear e inicializar nodos nuevos. Por lo tanto, puede que sea necesario mantener un conjunto mínimo de recursos, aunque no haya tráfico. Una vez más, el alcance de los recursos de referencia se ve influido por el tipo de aplicación y el perfil de tráfico.

Por el contrario, las tecnologías sin servidor, como App Engine, Cloud Run functions y Cloud Run, se han diseñado para reducirse a cero y para iniciarse y escalarse rápidamente, incluso en el caso de un inicio en frío. En función del tipo de aplicación y del perfil de tráfico, estas tecnologías pueden mejorar la eficiencia de algunas partes de tu aplicación.

Configurar autoescalado

La escalabilidad automática te ayuda a escalar automáticamente los recursos informáticos que consume tu aplicación. Normalmente, la escalabilidad automática se produce cuando se superan determinadas métricas o se cumplen determinadas condiciones. Por ejemplo, si las latencias de las solicitudes a su nivel web empiezan a superar un valor determinado, puede que le interese añadir más máquinas automáticamente para aumentar la capacidad de servicio.

Muchos Google Cloud productos de computación tienen funciones de escalado automático. Los servicios gestionados sin servidor, como Cloud Run, Cloud Run functions y App Engine, se han diseñado para escalarse rápidamente. Estos servicios suelen ofrecer opciones de configuración para limitar o influir en el comportamiento del escalado automático, pero, en general, gran parte de este comportamiento está oculto al operador.

Compute Engine y GKE ofrecen más opciones para controlar el comportamiento de escalado. Con Compute Engine, puedes escalar en función de varias entradas, como las métricas personalizadas de Cloud Monitoring y la capacidad de servicio del balanceador de carga. Puedes definir límites mínimos y máximos en el comportamiento del escalado, así como una política de autoescalado con varias señales para gestionar diferentes situaciones. Al igual que en GKE, puedes configurar el escalador automático de clústeres para añadir o quitar nodos en función de las métricas de la carga de trabajo o del pod, o bien en función de las métricas externas al clúster.

Te recomendamos que configures el comportamiento del autoescalado en función de las métricas clave de la aplicación, tu perfil de costes y el nivel mínimo de recursos que hayas definido.

Minimizar el tiempo de inicio

Para que el escalado sea eficaz, debe producirse con la suficiente rapidez como para gestionar el aumento de la carga. Esto es especialmente cierto cuando se añade capacidad de computación o de servicio.

Usar imágenes precompiladas

Si tu aplicación se ejecuta en VMs de Compute Engine, es probable que tengas que instalar software y configurar las instancias para que ejecuten tu aplicación. Aunque puedes usar secuencias de comandos de inicio para configurar nuevas instancias, una forma más eficiente es crear una imagen personalizada. Una imagen personalizada es un disco de arranque que configuras con el software y la configuración específicos de tu aplicación.

Para obtener más información sobre cómo gestionar imágenes, consulta el artículo sobre prácticas recomendadas para la gestión de imágenes.

Cuando hayas creado la imagen, podrás definir una plantilla de instancia. Las plantillas de instancia combinan la imagen de disco de arranque, el tipo de máquina y otras propiedades de la instancia. Después, puedes usar una plantilla de instancia para crear instancias de VM individuales o un grupo de instancias gestionadas. Las plantillas de instancia son una forma útil de guardar la configuración de una instancia de VM para poder usarla más tarde y crear nuevas instancias de VM idénticas.

Aunque la creación de imágenes e instancias personalizadas puede aumentar la velocidad de implementación, también puede incrementar los costes de mantenimiento, ya que es posible que las imágenes deban actualizarse con más frecuencia. Para obtener más información, consulta los documentos sobre la configuración de la imagen de equilibrio y la velocidad de implementación.

Contenerizar tu aplicación

Una alternativa a la creación de instancias de VM personalizadas es contenerizar tu aplicación. Un contenedor es un paquete de software ligero, independiente y ejecutable que incluye todo lo necesario para ejecutar una aplicación: código, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema y ajustes. Estas características hacen que las aplicaciones en contenedores sean más portátiles, fáciles de implementar y de mantener a gran escala que las máquinas virtuales. Los contenedores también suelen iniciarse rápidamente, lo que los hace adecuados para aplicaciones escalables y resilientes.

Google Cloud ofrece varios servicios para ejecutar los contenedores de tu aplicación. Cloud Run proporciona una plataforma de computación gestionada y sin servidor para alojar tus contenedores sin reconocimiento del estado. El entorno flexible de App Engine aloja tus contenedores en una plataforma como servicio (PaaS) gestionada. GKE proporciona un entorno de Kubernetes gestionado para alojar y orquestar tus aplicaciones en contenedores. También puedes ejecutar los contenedores de tu aplicación en Compute Engine cuando necesites tener un control total sobre tu entorno de contenedores.

Optimizar tu aplicación para que se inicie rápidamente

Además de asegurarte de que tu infraestructura y tu aplicación se puedan implementar de la forma más eficiente posible, también es importante que tu aplicación se ponga online rápidamente.

Las optimizaciones adecuadas para tu aplicación varían en función de las características de la aplicación y de la plataforma de ejecución. Es importante que hagas lo siguiente:

• Busca y elimina los cuellos de botella creando perfiles de las secciones críticas de tu aplicación que se invocan al inicio.
• Reduce el tiempo de inicio inicial implementando técnicas como la inicialización diferida, sobre todo de recursos caros.
• Minimiza las dependencias de la aplicación que puedan necesitarse cargar durante el inicio.

Favorecer las arquitecturas modulares

Puedes aumentar la flexibilidad de tu aplicación eligiendo arquitecturas que permitan que los componentes se implementen, gestionen y escalen de forma independiente. Este patrón también puede mejorar la resiliencia al eliminar los puntos únicos de fallo.

Dividir tu aplicación en servicios independientes

Si diseñas tu aplicación como un conjunto de servicios independientes con bajo acoplamiento, puedes aumentar su flexibilidad. Si adoptas un diseño con bajo acoplamiento, tus servicios se pueden lanzar y desplegar de forma independiente. Además de muchas otras ventajas, este enfoque permite que esos servicios usen diferentes pila tecnológica y que los gestionen distintos equipos. Este enfoque de acoplamiento flexible es el tema principal de los patrones de arquitectura, como los microservicios y la SOA.

Cuando pienses en cómo definir los límites de tus servicios, los requisitos de disponibilidad y escalabilidad serán dimensiones clave. Por ejemplo, si un componente tiene un requisito de disponibilidad o un perfil de escalado diferente al de los demás componentes, puede ser un buen candidato para un servicio independiente.

Utiliza sistemas sin reconocimiento del estado

Una aplicación o un servicio sin estado no conserva ningún dato ni estado local persistente. Un modelo sin estado asegura que puedas gestionar cada solicitud o interacción con el servicio independientemente de las solicitudes anteriores. Este modelo facilita la escalabilidad y la recuperación, ya que permite que el servicio crezca, se reduzca o se reinicie sin perder los datos necesarios para gestionar los procesos o las solicitudes en curso. La ausencia de estado es especialmente importante cuando se usa un escalador automático, ya que las instancias, los nodos o los pods que alojan el servicio se pueden crear y destruir de forma inesperada.

Es posible que no todos tus servicios puedan ser sin estado. En ese caso, indica explícitamente los servicios que requieren un estado. Si te aseguras de que los servicios con y sin estado estén bien separados, podrás escalar fácilmente los servicios sin estado y adoptar un enfoque más meditado para los servicios con estado.

Gestionar la comunicación entre servicios

Uno de los retos de las arquitecturas de microservicios distribuidas es gestionar la comunicación entre los servicios. A medida que crezca tu red de servicios, es probable que también lo hagan las interdependencias entre servicios. No quieres que el fallo de un servicio provoque el fallo de otros servicios, lo que a veces se denomina fallo en cascada.

Puedes reducir el tráfico a un servicio sobrecargado o que no funciona adoptando técnicas como el patrón interruptor automático, retrocesos exponenciales y degradación gradual. Estos patrones aumentan la resiliencia de tu aplicación, ya sea dando a los servicios sobrecargados la oportunidad de recuperarse o gestionando correctamente los estados de error. Para obtener más información, consulta el capítulo Solución de errores en cascada del libro de SRE de Google.

Usar una malla de servicios puede ayudarte a gestionar el tráfico de tus servicios distribuidos. Una malla de servicios es un software que vincula servicios y ayuda a desacoplar la lógica empresarial de la red. Una malla de servicios suele proporcionar funciones de resiliencia, como reintentos de solicitudes, conmutaciones por error y disyuntores.

Usar la tecnología de almacenamiento y base de datos adecuada

Es difícil escalar y hacer que determinadas bases de datos y tipos de almacenamiento sean resilientes. Asegúrate de que las bases de datos que elijas no limiten la disponibilidad ni la escalabilidad de tu aplicación.

Evalúa tus necesidades de base de datos

El patrón de diseño de tu aplicación como un conjunto de servicios independientes también se aplica a tus bases de datos y almacenamiento. Puede que sea adecuado elegir diferentes tipos de almacenamiento para distintas partes de tu aplicación, lo que da como resultado un almacenamiento heterogéneo.

Las aplicaciones convencionales suelen funcionar exclusivamente con bases de datos relacionales. Las bases de datos relacionales ofrecen funciones útiles, como transacciones, coherencia sólida, integridad referencial y consultas sofisticadas en varias tablas. Estas funciones hacen que las bases de datos relacionales sean una buena opción para muchas funciones comunes de aplicaciones. Sin embargo, las bases de datos relacionales también tienen algunas restricciones. Normalmente, son difíciles de escalar y requieren una gestión cuidadosa en una configuración de alta disponibilidad. Una base de datos relacional puede no ser la mejor opción para todas tus necesidades.

Las bases de datos no relacionales, a menudo denominadas bases de datos NoSQL, adoptan un enfoque diferente. Aunque los detalles varían de un producto a otro, las bases de datos NoSQL suelen sacrificar algunas funciones de las bases de datos relacionales para aumentar la disponibilidad y facilitar la escalabilidad. En cuanto al teorema CAP, las bases de datos NoSQL suelen priorizar la disponibilidad sobre la coherencia.

La idoneidad de una base de datos NoSQL suele depender del grado de coherencia necesario. Si tu modelo de datos de un servicio concreto no requiere todas las funciones de un SGBDR y se puede diseñar para que sea coherente en última instancia, elegir una base de datos NoSQL puede ofrecerte una mayor disponibilidad y escalabilidad.

En el ámbito de la gestión de datos, las bases de datos relacionales y no relacionales se consideran tecnologías complementarias en lugar de competitivas. Si las organizaciones usan ambos tipos de bases de datos de forma estratégica, pueden aprovechar las ventajas de cada una para obtener resultados óptimos en el almacenamiento, la recuperación y el análisis de datos.

Además de una amplia gama de bases de datos relacionales y NoSQL, Google Cloud también ofrece Spanner, una base de datos distribuida a nivel mundial, muy coherente y con alta disponibilidad, que admite SQL. Para obtener información sobre cómo elegir una base de datos adecuada enGoogle Cloud, consulta las bases de datos deGoogle Cloud .

Implementar el almacenamiento en caché

El objetivo principal de una caché es aumentar el rendimiento de la recuperación de datos al reducir la necesidad de acceder a la capa de almacenamiento subyacente, que es más lenta.

El almacenamiento en caché mejora la escalabilidad, ya que reduce la dependencia del almacenamiento basado en disco. Como las solicitudes se pueden servir desde la memoria, se reducen las latencias de las solicitudes a la capa de almacenamiento, lo que suele permitir que su servicio gestione más solicitudes. Además, el almacenamiento en caché puede reducir la carga de los servicios que están en la parte inferior de tu aplicación, especialmente las bases de datos, lo que permite que otros componentes que interactúan con ese servicio de la parte inferior también se escalen más o no se escalen.

El almacenamiento en caché también puede aumentar la resiliencia al admitir técnicas como la degradación controlada. Si la capa de almacenamiento subyacente está sobrecargada o no está disponible, la caché puede seguir gestionando las solicitudes. Aunque los datos devueltos de la caché estén incompletos o no estén actualizados, puede que sea aceptable en algunos casos.

Memorystore para Redis ofrece un servicio totalmente gestionado que se basa en el almacén de datos en memoria de Redis. Memorystore para Redis ofrece acceso con baja latencia y alto rendimiento para los datos a los que se accede con frecuencia. Se puede implementar en una configuración de alta disponibilidad que proporcione replicación entre zonas y conmutación por error automática.

Moderniza tus procesos y tu cultura de desarrollo

DevOps se puede considerar una amplia colección de procesos, cultura y herramientas que promueven la agilidad y reducen el tiempo de lanzamiento de aplicaciones y funciones al eliminar los silos entre los equipos de desarrollo, operaciones y otros relacionados. Las técnicas de DevOps tienen como objetivo mejorar la calidad y la fiabilidad del software.

En este documento no se explica en detalle qué es DevOps, pero en las siguientes secciones se abordan algunos aspectos clave relacionados con la mejora de la fiabilidad y la resiliencia de tu aplicación. Para obtener más información, consulta la página DevOps. Google Cloud

Diseño para la comprobación

Las pruebas automatizadas son un componente clave de las prácticas de entrega de software modernas. La capacidad de ejecutar un conjunto completo de pruebas unitarias, de integración y del sistema es esencial para verificar que tu aplicación se comporta como se espera y que puede pasar a la siguiente fase del ciclo de implementación. La capacidad de prueba es un criterio de diseño clave para tu aplicación.

Te recomendamos que uses pruebas unitarias para la mayor parte de tus pruebas, ya que se ejecutan rápidamente y suelen ser fáciles de mantener. También te recomendamos que automatices las pruebas de integración y del sistema de nivel superior. Estas pruebas se simplifican mucho si adoptas técnicas de infraestructura como código, ya que se pueden crear entornos y recursos de prueba específicos bajo demanda y, después, se pueden eliminar una vez que se hayan completado las pruebas.

A medida que aumenta el porcentaje de tu base de código cubierto por las pruebas, se reduce la incertidumbre y la posible disminución de la fiabilidad de cada cambio de código. Una cobertura de pruebas adecuada significa que puedes hacer más cambios antes de que la fiabilidad descienda por debajo de un nivel aceptable.

Las pruebas automatizadas son un componente esencial de la integración continua. Ejecutar un conjunto sólido de pruebas automatizadas en cada confirmación de código proporciona información rápida sobre los cambios, lo que mejora la calidad y la fiabilidad de tu software. Google CloudLas herramientas nativas, como Cloud Build, y las herramientas de terceros, como Jenkins, pueden ayudarte a implementar la integración continua.

Automatiza los despliegues

La integración continua y la automatización de pruebas exhaustivas te dan confianza en la estabilidad de tu software. Una vez que lo hayas hecho, el siguiente paso es automatizar el despliegue de tu aplicación. El nivel de automatización del despliegue varía en función de la madurez de tu organización.

Elegir una estrategia de implementación adecuada es esencial para minimizar los riesgos asociados a la implementación de software nuevo. Con la estrategia adecuada, puedes aumentar gradualmente la visibilidad de las nuevas versiones para llegar a audiencias más amplias y, al mismo tiempo, verificar el comportamiento. También puedes establecer disposiciones claras para la reversión si se producen problemas.

Adopta prácticas de SRE para gestionar los fallos

En las aplicaciones distribuidas que operan a gran escala, es habitual que se produzcan fallos en uno o varios componentes. Si adoptas los patrones que se describen en este documento, tu aplicación podrá gestionar mejor las interrupciones causadas por una versión de software defectuosa, la finalización inesperada de máquinas virtuales o incluso un fallo de la infraestructura que afecte a toda una zona.

Sin embargo, incluso con un diseño de aplicaciones cuidadoso, inevitablemente se producen eventos inesperados que requieren intervención humana. Si implementas procesos estructurados para gestionar estos eventos, puedes reducir considerablemente su impacto y resolverlos más rápidamente. Además, si examinas las causas y las respuestas al evento, puedes proteger tu aplicación frente a eventos similares en el futuro.

Los procesos sólidos para gestionar incidentes y realizar análisis post mortem son principios fundamentales de SRE. Aunque implementar todas las prácticas de SRE de Google puede no ser práctico para tu organización, si adoptas al menos un conjunto mínimo de directrices, puedes mejorar la resiliencia de tu aplicación. Los apéndices del libro de SRE contienen algunas plantillas que pueden ayudarte a dar forma a tus procesos.

Validar y revisar tu arquitectura

A medida que tu aplicación evoluciona, pueden cambiar el comportamiento de los usuarios, los perfiles de tráfico e incluso las prioridades de tu empresa. Del mismo modo, otros servicios o infraestructuras de los que dependa tu aplicación pueden evolucionar. Por lo tanto, es importante que pruebes y valides periódicamente la resiliencia y la escalabilidad de tu aplicación.

Pon a prueba tu capacidad de recuperación

Es fundamental probar que tu aplicación responde a los fallos de la forma que esperas. El tema principal es que la mejor forma de evitar el fracaso es introducirlo y aprender de él.

Simular e introducir fallos es complejo. Además de verificar el comportamiento de tu aplicación o servicio, también debes asegurarte de que se generen las alertas esperadas y las métricas adecuadas. Te recomendamos que sigas un enfoque estructurado, en el que primero introduzcas fallos básicos y, después, los aumentes.

Por ejemplo, puede proceder de la siguiente manera, validando y documentando el comportamiento en cada fase:

• Introduce fallos intermitentes.
• Bloquear el acceso a las dependencias del servicio.
• Bloquear toda la comunicación de red.
• Finalizar hosts.

Para obtener más información, consulta el vídeo Breaking your systems to make them unbreakable (Romper tus sistemas para que sean irrompibles) de Google Cloud Next 2019.

Si usas una malla de servicios como Istio para gestionar los servicios de tu aplicación, puedes inyectar fallos en la capa de aplicación en lugar de eliminar pods o máquinas, o bien puedes inyectar paquetes dañados en la capa TCP. Puedes introducir retrasos para simular la latencia de la red o un sistema upstream sobrecargado. También puedes introducir cancelaciones, que simulan fallos en los sistemas upstream.

Probar el comportamiento de escalado

Te recomendamos que uses pruebas no funcionales automatizadas para verificar que tu aplicación se adapta a las necesidades según lo previsto. A menudo, esta verificación se combina con pruebas de rendimiento o de carga. Puedes usar herramientas como hey para enviar carga a una aplicación web. Para ver un ejemplo más detallado de cómo hacer pruebas de carga en un endpoint REST, consulta Pruebas de carga distribuidas con Google Kubernetes Engine.

Una práctica habitual es asegurarse de que las métricas clave se mantengan dentro de los niveles esperados en diferentes cargas. Por ejemplo, si estás probando la escalabilidad de tu nivel web, puedes medir las latencias medias de las solicitudes de volúmenes irregulares de solicitudes de usuarios. Del mismo modo, en el caso de una función de procesamiento de backend, puedes medir el tiempo medio de procesamiento de tareas cuando el volumen de tareas aumenta de repente.

También debe comprobar que el número de recursos que se han creado para gestionar la carga de la prueba se encuentra dentro del intervalo esperado. Por ejemplo, tus pruebas pueden verificar que el número de VMs que se han creado para gestionar algunas tareas de backend no supera un valor determinado.

También es importante probar los casos límite. ¿Cómo se comporta tu aplicación o servicio cuando se alcanzan los límites máximos de escalado? ¿Qué ocurre si tu servicio se reduce y, de repente, la carga vuelve a aumentar?

Diseña siempre

El mundo de la tecnología avanza muy rápido, sobre todo en el caso de la nube. Se lanzan nuevos productos y funciones con frecuencia, surgen nuevos patrones y las demandas de tus usuarios y partes interesadas internas siguen aumentando.

Tal como se define en la entrada de blog sobre los principios de la arquitectura nativa de la nube, siempre debes buscar formas de perfeccionar, simplificar y mejorar la arquitectura de tus aplicaciones. Los sistemas de software son elementos vivos y deben adaptarse para reflejar tus prioridades cambiantes.

Siguientes pasos

• Lee la entrada de blog sobre los principios de la arquitectura nativa de la nube.
• Consulta los libros de SRE para obtener información sobre cómo se gestiona el entorno de producción de Google.
• Consulta más información sobre cómo DevOps en Google Cloud puede mejorar la calidad y la fiabilidad de tu software.
• Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.