Google Cloud Architecture Framework

Last reviewed 2023-11-09 UTC

El framework de arquitectura de Google Cloud proporciona recomendaciones y describe las prácticas recomendadas para ayudar a los arquitectos, los desarrolladores, los administradores y otros profesionales de la nube a diseñar y operar una topología en la nube que sea segura, eficiente, resiliente, de alto rendimiento y rentable. El framework de arquitectura de Google Cloud es nuestra versión de un framework bien diseñado.

Un equipo multifuncional de expertos de Google valida las recomendaciones de diseño y las prácticas recomendadas que conforman el framework de arquitectura. El equipo selecciona el framework de arquitectura para reflejar las capacidades en constante crecimiento de Google Cloud, las prácticas recomendadas del sector, el conocimiento de la comunidad y tus comentarios. Para obtener un resumen de los cambios significativos, consulta Novedades.

La guía de diseño en el framework de arquitectura se aplica a las aplicaciones desarrolladas para la nube y a las cargas de trabajo migradas de forma local a Google Cloud, implementaciones de nube híbrida y entornos de múltiples nubes.

El framework de arquitectura de Google Cloud está organizado en seis categorías (también conocidas como pilares), como se muestra en el siguiente diagrama:

Google Cloud Architecture Framework

Diseño de sistemas
Esta categoría es la base del framework de arquitectura de Google Cloud. Define la arquitectura, los componentes, los módulos, las interfaces y los datos necesarios para satisfacer los requisitos del sistema de nube y obtener información sobre los productos y las funciones de Google Cloud que admiten el diseño de sistemas.
Excelencia operativa
Implementa, opera, supervisa y administra las cargas de trabajo en la nube de forma eficiente.
Seguridad, privacidad y cumplimiento
Maximiza la seguridad de tus datos y cargas de trabajo en la nube, diseña para la privacidad y se alínea con los requisitos y estándares normativos.
Confiabilidad
Diseña y opera cargas de trabajo resilientes y con alta disponibilidad en la nube.
Optimización de costos
Maximiza el valor empresarial de tu inversión en Google Cloud.
Optimización del rendimiento
Diseña y ajusta tus recursos en la nube para obtener un rendimiento óptimo.

Para ver resúmenes de los productos de Google Cloud y cómo se relacionan entre sí, consulta Productos, funciones y servicios de Google Cloud en cuatro palabras o menos.

Framework de arquitectura de Google Cloud: Diseño de sistemas

El diseño del sistema es la categoría fundamental del framework de arquitectura de Google Cloud. En esta categoría, se proporcionan recomendaciones de diseño y se describen las prácticas recomendadas y los principios para ayudarte a definir la arquitectura, los componentes, los módulos, las interfaces y los datos en una plataforma en la nube a fin de satisfacer los requisitos de sistema. También aprenderás sobre los productos y las funciones de Google Cloud que admiten el diseño de sistemas.

En los documentos de la categoría de diseño del sistema, se supone que comprendes los principios básicos del diseño de sistemas. En estos documentos, no se supone que estás familiarizado con los conceptos de la nube y los productos de Google Cloud.

En situaciones de implementación y migración a la nube complejas, te recomendamos usar los Servicios de asesoría de Google Cloud. Nuestros consultores proporcionan experiencia en prácticas recomendadas y principios básicos para ayudarte a tener éxito en tu recorrido hacia la nube. Google Cloud también tiene un ecosistema sólido de socios, que incluye desde integradores de sistemas globales a gran escala hasta socios especializados en un área particular, como el aprendizaje automático. Te recomendamos que interactúes con los socios de Google Cloud para acelerar la transformación digital y mejorar los resultados comerciales.

En la categoría de diseño de sistemas del Framework de arquitectura, aprenderás a hacer lo siguiente:

Principios básicos del diseño de sistemas

En este documento del framework de arquitectura de Google Cloud, se describen los principios básicos del diseño de sistemas. Un diseño de sistema sólido y seguro es confiable, escalable e independiente. Te permite realizar cambios iterativos y reversibles sin interrumpir el sistema, minimizar los posibles riesgos y mejorar la eficiencia operativa. Para lograr un diseño de sistema sólido, te recomendamos que sigas cuatro principios básicos.

Documenta todo

Cuando comienzas a mover las cargas de trabajo a la nube o a compilar las aplicaciones, un bloqueador importante para el éxito es la falta de documentación del sistema. La documentación es especialmente importante para visualizar de manera correcta la arquitectura de las implementaciones actuales.

Una arquitectura en la nube documentada de forma adecuada establece un lenguaje y estándares comunes, que permiten a los equipos multifuncionales comunicarse y colaborar de manera efectiva. También proporciona la información necesaria para identificar y guiar las decisiones de diseño futuras. La documentación debe escribirse con tus casos prácticos en mente, para proporcionar contexto a las decisiones de diseño.

Con el tiempo, tus decisiones de diseño evolucionarán y cambiarán. El historial de cambios proporciona el contexto que tus equipos necesitan para alinear las iniciativas, evitar la duplicación y medir los cambios de rendimiento de manera efectiva en el tiempo. Los registros de cambios son muy valiosos cuando incorporas un arquitecto de nube nuevo que aún no está familiarizado con el diseño, la estrategia o el historial de tu sistema actual.

Simplifica tu diseño y usa servicios completamente administrados

La simplicidad es fundamental para el diseño de sistemas. Si la arquitectura es demasiado compleja para comprender, será difícil implementar el diseño y administrarlo con el tiempo. Cuando sea posible, usa servicios completamente administrados para minimizar los riesgos, el tiempo y el esfuerzo asociados con la administración y el mantenimiento de los sistemas de referencia.

Si ya ejecutas las cargas de trabajo en producción, realiza pruebas con servicios administrados para ver cómo podrían ayudar a reducir las complejidades operativas. Si desarrollas cargas de trabajo nuevas, comienza de manera simple, establece un producto viable mínimo (MVP) y controla el impulso de realizar una ingeniería excesiva. Puedes identificar casos prácticos excepcionales, iterar y mejorar tus sistemas de forma incremental con el tiempo.

Separa tu arquitectura

La separación es una técnica que se usa para separar tus aplicaciones y componentes de servicio en componentes más pequeños que pueden operar de forma independiente. Por ejemplo, puedes dividir una pila de aplicaciones monolítica en componentes del servicio separados. En una arquitectura separada, una aplicación puede ejecutar sus funciones de forma independiente, sin importar las dependencias.

Una arquitectura separada te brinda mayor flexibilidad para hacer lo siguiente:

  • Aplicar actualizaciones independientes
  • Aplicar controles de seguridad específicos
  • Establecer objetivos de confiabilidad para cada subsistema.
  • Supervisar el estado
  • Controlar los parámetros de rendimiento y costos de forma detallada

Puedes comenzar a desacoplar antes en tu fase de diseño o incorporarla como parte de las actualizaciones del sistema a medida que escalas.

Usa una arquitectura sin estado

Una arquitectura sin estado puede aumentar tanto la confiabilidad como la escalabilidad de tus aplicaciones.

Las aplicaciones con estado dependen de varias dependencias para realizar tareas, como datos almacenados en caché de forma local. Las aplicaciones con estado a menudo requieren mecanismos adicionales para capturar el progreso y reiniciarse de forma correcta. Las aplicaciones sin estado pueden realizar tareas sin dependencias locales significativas mediante el uso de almacenamiento compartido o servicios almacenados en caché. Una arquitectura sin estado permite que tus aplicaciones escalen verticalmente con rapidez con dependencias de arranque mínimas. Las aplicaciones pueden resistir reinicios forzados, tener un tiempo de inactividad menor y proporcionar un mejor rendimiento a los usuarios finales.

En la categoría de diseño de sistemas, se describen las recomendaciones a fin de que las aplicaciones no tengan estado o a fin de usar funciones nativas de la nube para mejorar la captura del estado de la máquina en las aplicaciones con estado.

¿Qué sigue?

Elige arquetipos de implementación de Google Cloud

En este documento del framework de arquitectura de Google Cloud, se describen seis arquetipos de implementación1: zonales, regionales, multirregionales, globales, híbridos y múltiples que puedes usar para compilar arquitecturas en las cargas de trabajo en la nube según tus requisitos de disponibilidad, costo, rendimiento y eficiencia operativa.

¿Qué es un arquetipo de implementación?

Un arquetipo de implementación es un modelo abstracto independiente del proveedor que usas como base para compilar arquitecturas de implementación específicas de la aplicación que cumplen con tus requisitos comerciales y técnicos. Cada arquetipo de implementación especifica una combinación de dominios con fallas en los que se puede ejecutar una aplicación. Estos dominios con fallas pueden ser una o más zonas o regiones de Google Cloud y se pueden extender para incluir tus centros de datos locales o dominios con fallas en otros proveedores de servicios en la nube.

En el siguiente diagrama, se muestran seis aplicaciones implementadas en Google Cloud. Cada aplicación usa un arquetipo de implementación que cumple con sus requisitos específicos.

Las aplicaciones en Google Cloud se implementan mediante diferentes arquetipos de implementación.

Como se muestra en el diagrama anterior, en una arquitectura que usa el arquetipo de implementación híbrida o de múltiples nubes, la topología de la nube se basa en uno de los arquetipos básicos: zonal, regional, multirregional o global. En este sentido, los arquetipos de implementación híbrida y de múltiples nubes se pueden considerar como arquetipos de implementación compuestos que incluyen uno de los arquetipos básicos.

Elegir un arquetipo de implementación ayuda a simplificar las decisiones posteriores sobre los productos y las funciones de Google Cloud que debes usar. Por ejemplo, para una aplicación en contenedores con alta disponibilidad, si eliges el arquetipo de implementación regional, los clústeres regionales de Google Kubernetes Engine (GKE) son más apropiados que los zonales.

Cuando eliges un arquetipo de implementación para una aplicación, debes considerar las compensaciones entre factores como la disponibilidad, el costo y la complejidad operativa. Por ejemplo, si una aplicación se entrega a usuarios en varios países y necesita alta disponibilidad, puedes elegir el arquetipo de implementación multirregional. Sin embargo, para una aplicación interna que usan los empleados en una sola región geográfica, puedes priorizar el costo por sobre la disponibilidad y, por lo tanto, elegir el arquetipo de implementación regional.

Descripción general de los arquetipos de implementación

En las siguientes pestañas, se proporcionan definiciones para los arquetipos de implementación y un resumen de los casos de uso y las consideraciones de diseño para cada uno.

Zonal

Tu aplicación se ejecuta dentro de una sola zona de Google Cloud, como se muestra en el siguiente diagrama:

Arquetipo de implementación zonal
Casos de uso
  • Entornos de desarrollo y pruebas
  • Aplicaciones que no necesitan alta disponibilidad.
  • Herramientas de redes de baja latencia entre los componentes de la aplicación.
  • Migración de cargas de trabajo básicas.
  • Aplicaciones que usan software con restricción de licencia.
Consideraciones del diseño
  • Tiempo de inactividad durante las interrupciones zonales

    Para la continuidad empresarial, puedes aprovisionar una réplica pasiva de la aplicación en otra zona de la misma región. Si ocurre una interrupción zonal, puedes restablecer la aplicación a producción mediante la réplica pasiva.

Más información

Consulta las siguientes secciones:

Regional

La aplicación se ejecuta de forma independiente en dos o más zonas dentro de una sola región de Google Cloud, como se muestra en el siguiente diagrama:

Arquetipo de implementación regional
Casos de uso
  • Aplicaciones con alta disponibilidad que atienden a usuarios dentro de un área geográfica.
  • Cumplimiento de los requisitos de soberanía y residencia de datos
Consideraciones del diseño
  • Tiempo de inactividad durante las interrupciones regionales.

    Para la continuidad empresarial, puedes crear una copia de seguridad de la aplicación y los datos en otra región. Si se produce una interrupción regional, puedes usar las copias de seguridad en la otra región para restablecer la aplicación a producción.

  • Costo y esfuerzo para aprovisionar y administrar recursos redundantes.
Más información

Consulta las siguientes secciones:

Multirregional

La aplicación se ejecuta de forma independiente en varias zonas en dos o más regiones de Google Cloud. Puedes usar las políticas de enrutamiento de DNS para enrutar el tráfico entrante a los balanceadores de cargas regionales. Luego, los balanceadores de cargas regionales distribuyen el tráfico a las réplicas zonales de la aplicación, como se muestra en el siguiente diagrama:

Arquetipo de implementación multirregional
Casos de uso
  • Aplicación con alta disponibilidad con usuarios de distintas ubicaciones geográficas.
  • Aplicaciones que requieren experiencia de baja latencia del usuario final.
  • Cumplimiento de los requisitos de soberanía y residencia de datos mediante una política de enrutamiento de DNS geovallado.
Consideraciones del diseño
  • Costo por la transferencia de datos entre regiones y la replicación de datos.
  • Complejidad operativa.
Más información

Consulta las siguientes secciones:

Global

Tu aplicación se ejecuta en regiones de Google Cloud en todo el mundo, ya sea como una pila distribuida a nivel global (que no reconoce la ubicación) o como pilas aisladas por regiones. Un balanceador de cargas anycast global distribuye el tráfico a la región más cercana al usuario. Otros componentes de la pila de aplicaciones también pueden ser globales, como la base de datos, la caché y el depósito de objetos.

En el siguiente diagrama, se muestra la variante distribuida a nivel global del arquetipo de implementación global. Un balanceador de cargas Anycast global reenvía las solicitudes a una pila de aplicaciones que se distribuye en varias regiones y que usa una base de datos replicada de forma global.

Arquetipo de implementación global: Pila distribuida en todo el mundo

En el siguiente diagrama, se muestra una variante del arquetipo de implementación global con pilas de aplicaciones aisladas de forma regional. Un balanceador de cargas Anycast global reenvía las solicitudes a una pila de aplicaciones en una de las regiones. Todas las pilas de aplicaciones usan una sola base de datos replicada de forma global.

Arquetipo de implementación global: pilas aisladas de forma regional
Casos de uso
  • Aplicaciones con alta disponibilidad que entregan a usuarios en todo el mundo.
  • Oportunidad de optimizar los costos y simplificar las operaciones mediante el uso de recursos globales en lugar de varias instancias de recursos regionales.
Consideraciones del diseño Costos por la transferencia de datos entre regiones y la replicación de datos.
Más información

Consulta las siguientes secciones:

Híbrido

Ciertas partes de la aplicación se implementan en Google Cloud, mientras que otras se ejecutan de forma local, como se muestra en el siguiente diagrama. En la topología de Google Cloud, se puede usar el arquetipo de implementación zonal, regional, multirregional o global.

Arquetipo de implementación híbrida
Casos de uso
  • Sitio de recuperación ante desastres (DR) para cargas de trabajo locales.
  • Desarrollo local para aplicaciones en la nube.
  • Migración progresiva a la nube para aplicaciones heredadas.
  • Mejora las aplicaciones locales con las capacidades de la nube.
Consideraciones del diseño
  • Esfuerzo de configuración y complejidad operativa.
  • Costo de los recursos redundantes.
Más información

Consulta las siguientes secciones:

Múltiples nubes

Algunas partes de la aplicación se implementan en Google Cloud, y otras se implementan en otras plataformas en la nube, como se muestra en el siguiente diagrama. En la topología de cada plataforma en la nube, se puede usar el arquetipo de implementación zonal, regional, multirregional o global.

Arquetipo de implementación de múltiples nubes
Casos de uso
  • Google Cloud como el sitio principal y otra nube como el sitio de DR
  • Mejora las aplicaciones con capacidades avanzadas de Google Cloud.
Consideraciones del diseño
  • Esfuerzo de configuración y complejidad operativa.
  • Costo de recursos redundantes y tráfico de red entre nubes.
Más información

Consulta las siguientes secciones:

Selecciona zonas geográficas y regiones

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para implementar tu sistema en función de los requisitos geográficos. Aprenderás a seleccionar zonas y regiones geográficas óptimas en función de la disponibilidad y la proximidad a fin de respaldar el cumplimiento, optimizar los costos e implementar el balanceo de cargas.

Cuando seleccionas una región o varias regiones para tus aplicaciones empresariales, debes tener en cuenta criterios como la disponibilidad de los servicios, la latencia del usuario final, la latencia de la aplicación, el costo y los requisitos regulatorios o de sustentabilidad. Para respaldar las políticas y prioridades de tu empresa, equilibra estos requisitos y, además, identifica las mejores compensaciones. Por ejemplo, es posible que la región más compatible no sea la región más rentable o que no tenga la huella de carbono más baja.

Implementa en varias regiones

Las regiones son áreas geográficas independientes que constan de varias zonas. Una zona es un área de implementación para los recursos de Google Cloud dentro de una región. Cada zona representa un dominio de falla único dentro de una región.

Para ayudarte a evitar el tiempo de inactividad esperado (incluido el mantenimiento) y el tiempo de inactividad inesperado, como los incidentes, te recomendamos que implementes aplicaciones tolerantes a errores que tengan alta disponibilidad y, luego, implementes las aplicaciones en varias zonas en una sola o más regiones. Para obtener más información, consulta:Geografía y regiones, Consideraciones para implementar aplicaciones y Prácticas recomendadas para la selección de regiones de Compute Engine.

Las implementaciones de varias zonas ofrecen resiliencia en caso de que haya limitaciones en cuanto a las implementaciones multirregión debido al costo o a otros consideraciones. Este enfoque resulta especialmente útil para prevenir interrupciones zonales o regionales y para abordar inquietudes relacionadas con la recuperación ante desastres y la continuidad del negocio. Si quieres obtener más información, consulta Diseña para el escalamiento y la alta disponibilidad.

Selecciona las regiones según la proximidad geográfica

La latencia afecta la experiencia del usuario y el costo asociado con la entrega a los usuarios externos. Para minimizar la latencia en la entrega de tráfico a los usuarios externos, selecciona una región o un conjunto de regiones que estén geográficamente cerca de tus usuarios, donde los servicios puedan ejecutarse de conformidad con los requisitos. Para obtener más información, consulta Ubicaciones de Cloud y Centro de recursos de cumplimiento.

Selecciona las regiones en función de los servicios disponibles

Seleccione una región según los servicios disponibles que requiera su empresa. La mayoría de los servicios están disponibles en todas las regiones. Sin embargo, es posible que algunos servicios específicos de algunas empresas estén disponibles en un subconjunto de regiones en el momento de su lanzamiento inicial. Para verificar la selección de la región, consulta Ubicaciones de Cloud.

Ten en cuenta el cumplimiento cuando selecciones las regiones

Selecciona una región específica o un conjunto de regiones según las reglamentaciones de naturaleza normativa o geográfica que requieran de determinadas ubicaciones, como el Reglamento General de Protección de Datos (GDPR) o las leyes de residencia de datos. Para obtener más información sobre el diseño de sistemas seguros, consulta Ofertas de cumplimiento y Residencia de datos, transparencia operativa y privacidad para clientes de Europa en Google Cloud.

Compara los precios de los principales recursos

El precio de un mismo servicio puede variar según la región. Para identificar una región que resulte más económica, compara los precios de los principales recursos que tengas previsto usar. Las consideraciones de costos difieren según los requisitos de copias de seguridad y recursos, como el procesamiento, las herramientas de redes y el almacenamiento de datos. Para obtener más información, consulta la categoría de optimización de costos.

Usa Cloud Load Balancing para entregar contenido a usuarios de todo el mundo

Para mejorar la experiencia de los usuarios internacionales, usa Cloud Load Balancing como ayuda para ofrecer una sola dirección IP con enrutamiento a tu aplicación. Si deseas obtener más información sobre el diseño de sistemas confiables, consulta Framework de la arquitectura de Google Cloud.

Usa el selector de región de Cloud para apoyar la sustentabilidad

Google tiene una emisión neutra de carbono desde 2007, y ha asumido el compromiso de no tener emisiones de carbono para 2030. Para seleccionar una región según su huella de carbono, usa el selector de región de Google Cloud. Si deseas obtener más información sobre el diseño para la sustentabilidad, consulta Cloud sostenibilidad.

¿Qué sigue?

Obtén información para administrar los recursos en la nube mediante Resource Manager, la jerarquía de recursos de Google Cloud y el Servicio de políticas de la organización.

Explora otras categorías en el framework de arquitectura, como la confiabilidad, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Administra recursos de la nube

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para organizar y administrar los recursos en Google Cloud.

Jerarquía de recursos

Los recursos de Google Cloud se organizan de forma jerárquica en organizaciones, carpetas y proyectos. Esta jerarquía te permite administrar aspectos comunes de tus recursos, como los controles de acceso, los ajustes de configuración y las políticas. Si deseas obtener prácticas recomendadas a fin de diseñar la jerarquía de tus recursos de nube, consulta Elige una jerarquía de recursos para tu zona de destino de Google Cloud.

Etiquetas de recursos

En esta sección, se proporcionan prácticas recomendadas para usar etiquetas de recursos y etiquetas de políticas a fin de organizar tus recursos de Google Cloud.

Usa una estructura de carpetas sencilla

Las carpetas permiten agrupar cualquier combinación de proyectos y subcarpetas. Crea una estructura de carpetas sencilla para organizar sus recursos de Google Cloud. Puedes agregar más niveles según sea necesario para definir su jerarquía de recursos y responder a las necesidades de su empresa. La estructura de carpetas es flexible y extensible. Para obtener más información, consulta Crea y administra carpetas.

Usa carpetas y proyectos para reflejar las políticas de administración de datos

Usa carpetas, subcarpetas y proyectos para separar los recursos de una forma que refleje las políticas de administración de datos de la organización. Por ejemplo, puedes usar una combinación de carpetas y proyectos para separar las áreas de ingeniería, finanzas y recursos humanos.

Usa proyectos para agrupar recursos que compartan el mismo límite de confianza. Por ejemplo, los recursos para el mismo producto o microservicio pueden pertenecer al mismo proyecto. Para obtener más información, consulta Elige una jerarquía de recursos para la zona de destino de Google Cloud.

Usa marcas y etiquetas al comienzo del proyecto

Usa etiquetas cuando comiences a usar los productos de Google Cloud, incluso si no los necesitas de inmediato. Agregar etiquetas más adelante puede requerir un esfuerzo manual que puede ser propenso a errores y difícil de completarse.

Una etiqueta de política proporciona una forma de permitir o rechazar políticas de manera condicional en función de si un recurso tiene una etiqueta de política específica. Una etiqueta de recurso es un par clave-valor que te ayuda a organizar tus instancias de Google Cloud. Para obtener más información sobre las etiquetas de recursos, consulta los requisitos para las etiquetas de recursos, una lista de servicios que admiten etiquetas de recursos y formatos de etiquetas de recursos.

Resource Manager cuenta con etiquetas de recursos y etiquetas de políticas que ayudan a administrar los recursos, atribuir e informar costos y asignar políticas a diferentes recursos para lograr un control de acceso más detallado. Por ejemplo, puedes usar etiquetas de recursos y etiquetas de políticas para aplicar los principios de administración y acceso detallado a diferentes recursos y servicios de la instancia. Para obtener información sobre las etiquetas de recursos de VM y las etiquetas de políticas de red, consulta Relación entre etiquetas de recursos de VM y etiquetas de políticas de red.

Puedes usar etiquetas de recursos con varios fines, incluidos los siguientes:

  • Administrar la facturación de recursos: Las etiquetas están disponibles en el sistema de facturación, lo que te permite separar el costo por etiquetas. Por ejemplo, puedes etiquetar diferentes centros de costos o presupuestos.
  • Agrupar recursos por características similares o por relación: Puedes usar etiquetas para separar diferentes entornos o etapas del ciclo de vida de las aplicaciones. Por ejemplo, puedes etiquetar entornos de producción, desarrollo y prueba.

Asigna etiquetas para respaldar los informes de costos y de facturación

Para admitir informes detallados de costos y facturación según los atributos fuera de las estructuras de informes integradas (como por proyecto o tipo de producto), asigna etiquetas de recursos a los recursos. Las etiquetas de recursos te pueden ayudar a asignar el consumo a los centros de costos, departamentos, proyectos específicos o mecanismos de carga interna. Para obtener más información, consulta la categoría Optimización de costos.

Evita crear una gran cantidad de etiquetas de recursos

Evita crear una gran cantidad de etiquetas de recursos. Te recomendamos crear etiquetas de recursos principalmente a nivel de proyecto y evitar crear etiquetas de recursos a nivel de subequipo. Crear etiquetas de recursos demasiado detalladas puede agregar ruido a tus estadísticas. Para obtener información sobre los casos de uso comunes de las etiquetas de recursos, consulta Usos comunes de las etiquetas de recursos.

Evita agregar información sensible a las etiquetas de recursos

Las etiquetas de recursos no están diseñadas para contener información sensible. No incluyas información sensible en las etiquetas de recursos, incluida información que pueda identificarse de forma personal, como el nombre o el título de una persona.

Anonimiza la información en los nombres de los proyectos

Sigue un patrón de nomenclatura de proyecto, como COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME, en el que los marcadores de posición son únicos y no revelan nombres de empresas o aplicaciones. No incluyas atributos que puedan cambiar en el futuro, por ejemplo, el nombre o la tecnología de un equipo.

Aplica marcas para modelar las dimensiones del negocio

Puedes aplicar etiquetas de políticas para modelar otras dimensiones del negocio, como la estructura organizativa, las regiones, los tipos de cargas de trabajo o los centros de costos. Para obtener más información sobre las etiquetas de políticas, consulta estos artículos: Descripción general de las etiquetas de políticas, Herencia de las etiquetas de políticas y Crea y administra etiquetas de políticas. Para aprender a usar etiquetas de políticas con políticas, consulta Políticas y etiquetas de políticas. Si deseas obtener información sobre cómo usar las etiquetas de políticas para administrar el control de acceso, consulta Etiquetas de políticas y control de acceso.

Políticas de organización

En esta sección, se proporcionan prácticas recomendadas para configurar reglas de administración en los recursos de Google Cloud en toda la jerarquía de recursos de nube.

Establece convenciones de nombres de proyectos

Establece una convención de nombres estandarizada de proyectos, por ejemplo, SYSTEM_NAME-ENVIRONMENT (dev, test, uat, stage, prod).

Los nombres de proyectos tienen un límite de 30 caracteres.

Aunque puedes aplicar un prefijo como COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG, los nombres de los proyectos pueden quedar desactualizados cuando las empresas pasen por reorganizaciones. Considera mover nombres identificables de los nombres de los proyectos a las etiquetas de proyectos.

Automatiza la creación de proyectos

Para crear proyectos destinados a producción y negocios de gran escala, usa un proceso automatizado como Deployment Manager o el módulo de Terraform de fábrica de proyectos de Google Cloud. Estas herramientas hacen lo siguiente:

  • Crean de manera automática entornos o proyectos de desarrollo, prueba y producción que tengan los permisos adecuados
  • Configuran el registro y la supervisión

El módulo de Terraform de fábrica de proyectos de Google Cloud te ayuda a automatizar la creación de proyectos de Google Cloud. En empresas grandes, te recomendamos que revises y apruebes los proyectos antes de crearlos en Google Cloud. Este proceso ayuda a garantizar lo siguiente:

  • Que los costos se puedan atribuir. Para obtener más información, consulta la categoría Optimización de costos.
  • Que se establezcan aprobaciones para las cargas de datos.
  • Que se cumplan los requisitos normativos o de cumplimiento.

Cuando automatizas la creación y administración de proyectos y recursos de Google Cloud, obtienes el beneficio de la coherencia, la reproducibilidad y la capacidad de realizar pruebas. Si tratas a la configuración como código, podrás controlar las versiones y administrar el ciclo de vida de la configuración junto con los artefactos del software. Con la automatización, podrás aplicar las recomendaciones, como las convenciones de nombres coherentes y el etiquetado de los recursos. A medida que tus requisitos evolucionan, la automatización simplifica la refactorización de proyectos.

Audita tus sistemas con regularidad

Para garantizar que las solicitudes de proyectos nuevos se puedan auditar y aprobar, integra el sistema de tickets de tu empresa o un sistema independiente que proporcione auditorías.

Configura proyectos de manera coherente

Configura proyectos para satisfacer las necesidades de tu organización de forma coherente. Cuando configures proyectos, incluye lo siguiente:

  • ID del proyecto y convenciones de nombres
  • Vinculación de cuentas de facturación
  • Configuración de redes
  • API y servicios habilitados
  • Configuración de acceso de Compute Engine
  • Informes de uso y exportación de registros
  • Retención de eliminación de proyectos

Separa y aísla las cargas de trabajo o entornos

Las cuotas y los límites se aplican a nivel de proyecto. Para administrar las cuotas y los límites, separa y aísla las cargas de trabajo o los entornos a nivel de proyecto. Para obtener más información, consulta Trabaja con cuotas.

Los entornos de separación son diferentes de los requisitos de clasificación de datos. Separar los datos de la infraestructura puede ser costoso y complejo de implementar, por lo que recomendamos que implementes la clasificación de datos en función de los requisitos de cumplimiento y de sensibilidad de los datos.

Aplica el aislamiento de facturación

Aplica el aislamiento de facturación para admitir diferentes cuentas de facturación y visibilidad de costos por carga de trabajo y entorno. Para obtener más información, consulta Crea, modifica o cierra la cuenta de Facturación de Cloud de servicio automático y Habilita, inhabilita o cambia la facturación de un proyecto.

A fin de minimizar la complejidad administrativa, usa controles de administración de acceso detallados para entornos críticos a nivel de proyecto o para cargas de trabajo que se distribuyen en varios proyectos. Cuando seleccionas el control de acceso para aplicaciones de producción críticas, te aseguras de que las cargas de trabajo estén protegidas y administradas de manera eficaz.

Usa el Servicio de políticas de la organización para controlar recursos

El servicio de políticas de la organización les brinda a los administradores de políticas un control centralizado y programático de los recursos en la nube de la organización, de modo que puedan configurar restricciones en toda la jerarquía de recursos. Para obtener más información, consulta Agrega un administrador de políticas de la organización.

Usa el Servicio de políticas de la organización para cumplir con las políticas reglamentarias

A fin de satisfacer los requisitos de cumplimiento, usa el Servicio de políticas de la organización para controlar el acceso a los recursos y su uso compartido. Por ejemplo, puedes limitar el uso compartido con partes externas o determinar dónde implementar los recursos de la nube de manera geográfica. Otras situaciones de cumplimiento incluyen las siguientes:

  • Centralizar el control para configurar restricciones que definan cómo se pueden usar los recursos de tu organización.
  • Definir y establecer políticas para ayudar a los equipos de desarrollo a permanecer dentro de los límites de cumplimiento.
  • Ayudar a los propietarios de proyectos y sus equipos a realizar cambios en el sistema mientras se mantiene el cumplimiento normativo y se minimizan los problemas sobre la violación de las reglas de cumplimiento.

Limita el uso compartido de recursos según el dominio.

Una política de la organización de uso compartido restringido te ayuda a evitar que los recursos de Google Cloud se compartan con identidades fuera de tu organización. Para obtener más información, consulta Restringe identidades por dominio y Restricciones de la política de la organización.

Inhabilita la creación de claves y la cuenta de servicio

Para ayudar a mejorar la seguridad, limita el uso de las cuentas de servicio de Identity and Access Management (IAM) y las claves correspondientes. Para obtener más información, consulta Restringe el uso de las cuentas de servicio.

Restringe la ubicación física de recursos nuevos

Restringe la ubicación física de los recursos recién creados mediante la restricción de las ubicaciones de recursos. Para ver una lista de las restricciones que te permiten controlar los recursos de tu organización, consulta las restricciones del servicio de políticas de la organización.

¿Qué sigue?

Obtén más información sobre cómo elegir y administrar el procesamiento, lo que incluye lo siguiente:

Explora otras categorías en el framework de arquitectura, como la confiabilidad, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Elige y administra el procesamiento

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para implementar tu sistema en función de los requisitos de procesamiento. Aprenderás a elegir una plataforma de procesamiento y un enfoque de migración, diseñar y escalar cargas de trabajo, y administrar las operaciones y las migraciones de VM.

El procesamiento es la base de muchas cargas de trabajo, ya sea que se refieran a la ejecución de la lógica empresarial personalizada o a la aplicación de algoritmos complejos de procesamiento en los conjuntos de datos. La mayoría de las soluciones usan recursos de procesamiento de alguna forma, y es fundamental que selecciones los recursos de procesamiento adecuados para las necesidades de la aplicación.

Google Cloud ofrece varias opciones para usar el tiempo en una CPU. Las opciones se basan en los tipos de CPU, el rendimiento y la forma en que tu código está programado para ejecutarse, incluida la facturación por uso.

Entre las opciones de procesamiento de Google Cloud, se incluyen las siguientes:

  • Máquinas virtuales (VM) con beneficios específicos de la nube, como la migración en vivo
  • Compresión de contenedores en máquinas de clúster que pueden compartir CPU.
  • Funciones y enfoques sin servidores, en los que el uso del tiempo de CPU se puede medir según el trabajo realizado durante una sola solicitud HTTP.

Elige el procesamiento

En esta sección, se proporcionan prácticas recomendadas para elegir una plataforma de procesamiento y migrar a ella.

Elige una plataforma de procesamiento

Cuando elijas una plataforma de procesamiento para tu carga de trabajo, considera los requisitos técnicos de la carga de trabajo, los procesos de automatización del ciclo de vida, la regionalización y la seguridad.

Evalúa la naturaleza del uso de CPU por parte de tu app y todo el sistema que la respalda, incluida la forma en que tu código se empaqueta y se implementa, distribuye e invoca. Si bien algunas situaciones pueden ser compatibles con varias opciones de plataformas, una carga de trabajo portátil debe ser capaz de funcionar en una variedad de opciones de procesamiento.

En la siguiente tabla, se proporciona una descripción general de los servicios de procesamiento de Google Cloud recomendados para varios casos de uso:

Plataforma Compute Casos de uso Productos recomendados
Sin servidores
  • Implementa tu primera app
  • Enfócate en la lógica de procesamiento de datos y procesamiento en la app, en lugar de mantener las operaciones de infraestructura.
  • Cloud Run: Pon tu lógica empresarial en contenedores mediante esta opción completamente administrada y sin servidores. Cloud Run está diseñado para cargas de trabajo que requieren mucho procesamiento, pero no siempre están activas. Escala de forma rentable desde 0 (sin tráfico) y define la CPU y la RAM de tus tareas y servicios. Implementa con un solo comando y Google aprovisiona de forma automática la cantidad correcta de recursos.
  • Cloud Functions: Separa tu código en partes flexibles de lógica empresarial sin las preocupaciones de infraestructura del balanceo de cargas, las actualizaciones, la autenticación o el ajuste de escala.
Kubernetes Arquitecturas de microservicios complejas que necesitan servicios adicionales como Istio para administrar el control de la malla de servicios
  • Google Kubernetes Engine: Un motor de organización de contenedores de código abierto que automatiza la implementación, el escalamiento y la administración de apps en contenedores.
Máquinas virtuales (VMs) Crea y ejecuta VM a partir de familias de VM predefinidas y personalizables que admitan los requisitos de tu aplicación y carga de trabajo, así como software y servicios de terceros.
  • Compute Engine: Agrega unidades de procesamiento de gráficos (GPU) a tus instancias de VM. Puedes usar estas GPU para acelerar cargas de trabajo específicas en las instancias, como aprendizaje automático y procesamiento de datos.

A fin de seleccionar los tipos de máquina adecuados según tus requisitos, consulta Recomendaciones para las familias de máquinas.

Para obtener más información, consulta Elige las opciones de procesamiento.

Elige un enfoque de migración de procesamiento

Si migras tus aplicaciones existentes desde otra nube o desde entornos locales, usa uno de los siguientes productos de Google Cloud para optimizar el rendimiento, el escalamiento, el costo y la seguridad.

Objetivo de migración Caso práctico Producto recomendado
Lift-and-shift Migra o extiende tus cargas de trabajo de VMware a Google Cloud en minutos. Google Cloud VMware Engine
Lift-and-shift Traslada tus aplicaciones basadas en VM a Compute Engine. Migrate to Virtual Machines
Actualiza las VM a contenedores Moderniza las aplicaciones tradicionales en contenedores integrados en Google Kubernetes Engine. Migrate to Containers

Si deseas obtener información sobre cómo migrar tus cargas de trabajo mientras alineas equipos internos, consulta Ciclo de vida de la migración de VM y Compila un programa de migración a gran escala con Google Cloud.

Diseña cargas de trabajo

En esta sección, se proporcionan prácticas recomendadas para diseñar cargas de trabajo compatibles con tu sistema.

Evalúa las opciones sin servidores para obtener una lógica simple

La lógica simple es un tipo de procesamiento que no requiere hardware especializado ni tipos de máquinas como máquinas optimizadas para CPU. Antes de invertir en implementaciones de Google Kubernetes Engine (GKE) o Compute Engine para abstraer la sobrecarga operativa y optimizar el costo y el rendimiento, evalúa opciones sin servidores para obtener una lógica básica.

Separa las aplicaciones para que queden sin estado

Cuando sea posible, separa tus aplicaciones para que queden sin estado a fin de maximizar el uso de las opciones de computación sin servidores. Este enfoque te permite usar ofertas de procesamiento administradas, escalar aplicaciones según la demanda y optimizar el costo y el rendimiento. Si deseas obtener más información sobre cómo separar la aplicación a fin de diseñar para gran escala y alta disponibilidad, consulta Diseña para gran escala y alta disponibilidad.

Usa la lógica de almacenamiento en caché cuando separes las arquitecturas

Si la aplicación está diseñada para tener estado, usa la lógica de almacenamiento en caché a fin de desconectar y hacer que la carga de trabajo sea escalable. Si quieres obtener más información, consulta Prácticas recomendadas para bases de datos.

Usa las migraciones en vivo para facilitar las actualizaciones

Para facilitar las actualizaciones de mantenimiento de Google, usa la migración en vivo mediante la configuración de políticas de disponibilidad de instancia. Para obtener más información, consulta Configura la política de mantenimiento del host de VM.

Escala las cargas de trabajo

En esta sección, se proporcionan prácticas recomendadas para escalar cargas de trabajo a fin de que sean compatibles con tu sistema.

Usa secuencias de comandos de inicio y apagado

En el caso de las aplicaciones con estado, usa las secuencias de comandos de inicio y apagado cuando sea posible iniciar y detener el estado de la aplicación de manera ordenada. Un inicio ordenado ocurre cuando una función de software activa una computadora y el sistema operativo puede realizar sus tareas de iniciar procesos y abrir conexiones de forma segura.

Los inicios y los apagados ordenados son importantes porque las aplicaciones con estado dependen de la disponibilidad inmediata para los datos que se encuentran cerca del procesamiento, generalmente en discos locales o persistentes, o en la RAM. A fin de evitar la ejecución de datos de la aplicación desde el principio para cada inicio, usa una secuencia de comandos de inicio a fin de volver a cargar los últimos datos guardados y ejecutar el proceso desde donde se detuvo antes en el apagado. Para guardar el estado de la memoria de la aplicación y evitar perder progreso en el apagado, usa una secuencia de comandos de apagado. Por ejemplo, usa una secuencia de comandos de apagado cuando se programa el apagado de una VM debido a la reducción de la escala o a eventos de mantenimiento de Google.

Usa MIG para admitir la administración de VM

Cuando usas VM de Compute Engine, los grupos de instancias administrados (MIG) admiten funciones como la reparación automática, el balanceo de cargas, el ajuste de escala automático, las actualizaciones automáticas y las cargas de trabajo con estado. Puedes crear MIG regionales o zonales según los objetivos de disponibilidad. Puedes usar MIG en cargas de trabajo de entrega sin estado o cargas de trabajo por lotes y en aplicaciones con estado que necesitan conservar el estado único de cada VM.

Usa los escaladores automáticos de Pods para escalar tus cargas de trabajo de GKE

Usa los escaladores automáticos de pod verticales y horizontales para escalar tus cargas de trabajo y usa aprovisionamiento automático de nodos para escalar los recursos de procesamiento subyacentes.

Distribuye el tráfico de las aplicaciones

Si quieres escalar tus aplicaciones de forma global, usa Cloud Load Balancing para distribuir las instancias de tu aplicación en más de una región o zona. Los balanceadores de cargas optimizan el enrutamiento de paquetes de las redes perimetrales de Google Cloud a la zona más cercana, lo que aumenta la eficiencia del tráfico de entrega y minimiza los costos de entrega. Si deseas optimizar la latencia del usuario final, usa Cloud CDN para almacenar en caché el contenido estático cuando sea posible.

Automatiza la creación y la administración de procesamiento

Automatiza la creación y administración de procesamiento para minimizar los errores causados por las personas en tu entorno de producción.

Administra operaciones

En esta sección, se proporcionan prácticas recomendadas para administrar las operaciones a fin de que sean compatibles con tu sistema.

Usa imágenes públicas proporcionadas por Google

Usa imágenes públicas proporcionadas por Google Cloud. Las imágenes públicas de Google Cloud se actualizan con regularidad. Para obtener más información, consulta la Lista de imágenes públicas disponibles en Compute Engine.

También puedes crear tus propias imágenes con parámetros de configuración específicos. Cuando sea posible, automatiza y centraliza la creación de imágenes en un proyecto separado que puedas compartir con usuarios autorizados de tu organización. Crear y seleccionar una imagen personalizada en un proyecto distinto te permite actualizar, parchar y crear una VM con tus propias configuraciones. Luego, puedes compartir la imagen de VM seleccionada con proyectos relevantes.

Usa instantáneas para copias de seguridad de instancias

Las instantáneas te permiten crear copias de seguridad para tus instancias. Las instantáneas son especialmente útiles para las aplicaciones con estado, que no son lo suficientemente flexibles a fin de mantener el estado o guardar el progreso cuando experimentan cierres abruptos. Si usas instantáneas con frecuencia para crear instancias nuevas, puedes optimizar el proceso de copia de seguridad mediante la creación de una imagen base a partir de esa instantánea.

Usa una imagen de máquina para habilitar la creación de instancias de VM

Aunque una instantánea solo captura una imagen de los datos dentro de una máquina, una imagen de máquina captura la configuración de la máquina además de los datos. Usa una imagen de máquina para almacenar todas las opciones de configuración, metadatos, permisos y datos de uno o más discos necesarios a fin de crear una instancia de VM.

Cuando creas una máquina a partir de una instantánea, debes establecer la configuración de la instancia en las instancias de VM nuevas, lo que requiere mucho trabajo. El uso de imágenes de máquina te permite copiar esa configuración conocida en máquinas nuevas, lo que reduce la sobrecarga. Para obtener más información, consulta Cuándo usar una imagen de máquina.

Capacidad, reservas y aislamiento

En esta sección, se proporcionan prácticas recomendadas para administrar la capacidad, las reservas y el aislamiento a fin de que sean compatibles con tu sistema.

Usa descuentos por compromiso de uso para reducir los costos

Puedes reducir el costo de los gastos operativos (OPEX) para las cargas de trabajo que siempre están activas mediante los descuentos por compromiso de uso. Para obtener más información, consulta la categoría Optimización de costos.

Elige tipos de máquinas que sean compatibles con el costo y el rendimiento

Google Cloud ofrece tipos de máquinas que te permiten elegir procesamiento basado en los parámetros de costo y rendimiento. Puedes elegir una oferta de bajo rendimiento para optimizar el costo o elegir una opción de computación de alto rendimiento a un costo más alto. Para obtener más información, consulta la categoría Optimización de costos.

Usa nodos de usuario único para satisfacer las necesidades de cumplimiento

Los nodos de usuario único son servidores físicos de Compute Engine dedicados a alojar solo las VM de tu proyecto. Los nodos de usuario único pueden ayudarte a cumplir con los requisitos de cumplimiento del aislamiento físico, incluidos los siguientes:

  • Mantener tus VM separadas de forma física de las VM en otros proyectos.
  • Agrupar tus VM en el mismo hardware del host.
  • Aislar las cargas de trabajo de procesamiento de pagos.

Para obtener más información, consulta Nodos de usuario único.

Usa las reservas para garantizar la disponibilidad de los recursos

Google Cloud te permite definir reservas para tus cargas de trabajo a fin de garantizar que esos recursos estén siempre disponibles. No se generan cargos adicionales por crear reservas, pero pagas por los recursos reservados, incluso si no los usas. Para obtener más información, consulta Consume y administra reservas.

VM Migration

En esta sección, se proporcionan prácticas recomendadas para migrar VM a fin de que sean compatibles con tu sistema.

Evalúa las herramientas de migración integradas

Evalúa las herramientas de migración integradas para mover tus cargas de trabajo desde otra nube o desde las instalaciones locales. Para obtener más información, consulta Migración a Google Cloud. Google Cloud ofrece herramientas y servicios para ayudarte a migrar tus cargas de trabajo y optimizar el costo y el rendimiento. Para recibir una evaluación gratuita del costo de migración según tu panorama de TI actual, consulta el Programa de evaluación y migración rápidas de Google Cloud.

Usa la importación de discos virtuales para sistemas operativos personalizados

Para importar sistemas operativos compatibles personalizados, consulta Importa discos virtuales. Los nodos de usuario único pueden ayudarte a cumplir con los requisitos de hardware de licencia adquirida por el usuario para licencias por núcleo o por procesador. Para obtener más información, consulta Licencias adquiridas por el usuario.

Recomendaciones

Para aplicar la guía del framework de arquitectura a tu propio entorno, te recomendamos que hagas lo siguiente:

  • Revisa las ofertas de Google Cloud Marketplace para evaluar si tu aplicación aparece en la lista de un proveedor compatible. Google Cloud admite la ejecución de varios sistemas de código abierto y varios software de terceros.

  • Considera Migrate to Containers y GKE para extraer y empaquetar tu aplicación basada en VM como una aplicación en contenedores que se ejecuta en GKE.

  • Usa Compute Engine para ejecutar tus aplicaciones en Google Cloud. Si tienes dependencias heredadas que se ejecutan en una aplicación basada en VM, verifica si cumplen con los requisitos de tu proveedor.

  • Evalúa el uso de un balanceador de cargas de red de transferencia interno de Google Cloud para escalar la arquitectura separada. Para obtener más información, consulta Descripción general del balanceador de cargas de red de transferencia interno.

  • Evalúa tus opciones para cambiar desde casos de uso locales tradicionales, como el uso del proxy con alta disponibilidad. Si deseas obtener más información, consulta Prácticas recomendadas para la dirección IP flotante.

  • Usa VM Manager a fin de administrar sistemas operativos para tus grandes flotas de VM que ejecutan Windows o Linux en Compute Engine y aplica políticas de configuración coherentes.

  • Considera usar GKE Autopilot y permitir que Google SRE administre completamente tus clústeres.

  • Usa el Policy Controller y el Sincronizador de configuración para administrar las políticas y la configuración en tus clústeres de GKE.

  • Garantiza la disponibilidad y escalabilidad de las máquinas en regiones y zonas específicas. Google Cloud puede escalar para satisfacer tus necesidades de procesamiento. Sin embargo, si necesitas muchos tipos de máquinas específicos en una región o zona específica, trabaja con tus equipos de cuentas para garantizar la disponibilidad. Si deseas obtener más información, consulta Reservas para Compute Engine.

¿Qué sigue?

Obtén más información sobre los principios del diseño de herramientas de redes, incluido lo siguiente:

Explora otras categorías en el framework de arquitectura, como la confiabilidad, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Diseña la infraestructura de red

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para implementar el sistema en función del diseño de las herramientas de red. Aprenderás a elegir y, luego, implementar la nube privada virtual (VPC), y a probar y administrar la seguridad de la red.

Principios básicos

El diseño de la red es fundamental para lograr un diseño exitoso del sistema, ya que te ayudará a optimizar el rendimiento y proteger las comunicaciones de las aplicaciones con servicios internos y externos. Cuando eliges los servicios de la red, es importante evaluar las necesidades de tu aplicación y cómo las aplicaciones se comunicarán entre sí. Por ejemplo, aunque algunos componentes requieren servicios globales, otros componentes pueden ubicarse geográficamente en una región específica.

La red privada de Google conecta nuestras ubicaciones regionales con más de 100 puntos de presencia de redes globales. Google Cloud usa redes definidas por software y tecnologías de sistemas distribuidos para alojar y entregar tus servicios en todo el mundo. El elemento principal de Google para las herramientas de redes dentro de Google Cloud es la VPC global. VPC usa la red global de alta velocidad de Google para vincular las aplicaciones entre regiones al tiempo que se mantiene la privacidad y la confiabilidad. Google se asegura de que tu contenido se entregue con alta capacidad de procesamiento a través de tecnologías como el ancho de banda de botella y el tiempo de propagación de ida y vuelta (BBR).

Desarrollar su diseño de herramientas de redes en la nube incluye los siguientes pasos:

  1. Diseñe la arquitectura de cargas de trabajo de VPC. Comience por identificar cuántos proyectos de Google Cloud y redes de VPC necesita.
  2. Agregue conectividad entre las VPC. Diseñe la forma en que sus cargas de trabajo se conectan a otras cargas de trabajo en distintas redes de VPC.
  3. Diseñe la conectividad de red híbrida. Diseñe la forma en que las VPC de sus cargas de trabajo se conectan a los entornos locales y de otras nubes.

Cuando diseñe su red de Google Cloud, considere lo siguiente:

Si deseas ver una lista completa de las especificaciones de VPC, consulta Especificaciones.

Arquitectura de VPC de cargas de trabajo

En esta sección, se proporcionan prácticas recomendadas para diseñar arquitecturas de VPC de carga de trabajo compatibles con tu sistema.

Considera diseñar la red de VPC con anticipación

El diseño de la red de VPC debe ser una de las primeras consideraciones a la hora de diseñar la configuración de la organización en Google Cloud. Las elecciones de diseño de nivel de la organización no son fáciles de modificar en etapas posteriores del proceso. Si deseas obtener más información, consulta Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC y Decide el diseño de la red de tu zona de destino de Google Cloud.

Comienza con una sola red de VPC

Para muchos casos de uso que incluyen recursos con requisitos en común, una sola red de VPC ofrece las funciones necesarias. Las redes de VPC únicas son sencillas de crear, mantener y comprender. Para obtener más información, consulta Especificaciones de redes de VPC.

Mantén la topología de red de VPC simple

Para garantizar una arquitectura administrable, confiable y fácil de comprender, mantén el diseño de tu topología de red de VPC lo más simple posible.

Use las redes de VPC en el modo personalizado

Para garantizar que las herramientas de redes de Google Cloud se integren a la perfección en sus sistemas de redes existentes, recomendamos que use el modo personalizado cuando cree redes de VPC. El modo personalizado ayuda a integrar las herramientas de redes de Google Cloud en sus esquemas de administración de direcciones IP existentes y le permite controlar qué regiones de Cloud se incluyen en la VPC. Para obtener más información, consulta VPC.

Conectividad entre VPC:

En esta sección, se proporcionan prácticas recomendadas para diseñar la conectividad entre VPC para que sean compatibles con tu sistema.

Elige un método de conexión de VPC

Si decides implementar varias redes de VPC, necesita establecer conexiones con esas redes. Las redes de VPC son espacios de usuario aislados dentro de la red definida por software (SDN) Andromeda de Google. Existen varias formas en que las redes de VPC pueden comunicarse entre sí. Elige cómo conectar la red según los requisitos de ancho de banda, latencia y Acuerdo de Nivel de Servicio (ANS) de tu ancho de banda. Para obtener más información sobre las opciones de conexión, consulta Elige el método de conexión de VPC que cumpla con tus necesidades de costo, rendimiento y seguridad.

Use VPC compartida para administrar varios grupos de trabajo

En las organizaciones con varios equipos, la VPC compartida proporciona una herramienta eficaz para extender la simplicidad arquitectónica de una sola red de VPC en varios grupos de trabajo.

Use convenciones de nomenclatura sencillas

Elija convenciones de nomenclatura simples, intuitivas y coherentes. Esto ayuda a los administradores y usuarios a comprender el propósito de cada recurso, su ubicación y cómo difiere de otros recursos.

Use pruebas de conectividad para verificar la seguridad de la red

En el contexto de la seguridad de la red, puede usar pruebas de conectividad para verificar que el tráfico que se desea impedir entre dos extremos esté bloqueado. Para verificar que el tráfico está bloqueado y por qué, defina una prueba entre dos extremos y evalúe los resultados. Por ejemplo, puedes probar una función de VPC que te permite definir reglas que admitan el bloqueo del tráfico. Para obtener más información, consulta la descripción general de las pruebas de conectividad.

Use Private Service Connect para crear extremos privados

Para crear extremos privados que le permitan acceder a los servicios de Google con su propio esquema de direcciones IP, usa Private Service Connect. Puedes acceder a los extremos privados desde el interior de su VPC y a través de conectividad híbrida que finaliza en su VPC.

Protege y limita la conectividad externa

Limita el acceso a Internet solo a los recursos que lo necesitan. Los recursos que solo tengan una dirección IP interna privada pueden acceder a muchos servicios y API de Google a través del Acceso privado a Google.

Usa Network Intelligence Center para supervisar tus redes en la nube

Network Intelligence Center proporciona una vista integral de las redes de Google Cloud en todas las regiones. Te ayuda a identificar patrones de acceso y tráfico que pueden causar riesgos operativos o de seguridad.

¿Qué sigue?

Conoce las prácticas recomendadas para la administración del almacenamiento, que incluyen lo siguiente:

Explora otras categorías en el framework de arquitectura, como la confiabilidad, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Selecciona e implementa una estrategia de almacenamiento

En este documento de Google Cloud Architecture Framework , se proporcionan prácticas recomendadas para implementar un sistema en función de tu almacenamiento. Aprenderás a seleccionar una estrategia de almacenamiento y a administrar el almacenamiento, los patrones de acceso y las cargas de trabajo.

Para facilitar el intercambio de datos y crear copias de seguridad y almacenar datos de forma segura, las organizaciones deben elegir un plan de almacenamiento según la carga de trabajo, las operaciones de entrada y salida por segundo (IOPS), la latencia, la frecuencia de recuperación, la ubicación, la capacidad y el formato (bloque, archivo y objeto).

Cloud Storage proporciona servicios de almacenamiento de objetos confiables y seguros, que incluyen los siguientes:

En Google Cloud, la cantidad de IOPS se escala según el espacio de almacenamiento aprovisionado. Algunos tipos de almacenamiento, como Persistent Disk, requieren replicación manual y copia de seguridad porque son zonales o regionales. En contraposición, el almacenamiento de objetos tiene alta disponibilidad y replica datos automáticamente en una sola región o entre varias regiones.

Tipo de almacenamiento

En esta sección, se proporcionan prácticas recomendadas para elegir un tipo de almacenamiento compatible con tu sistema.

Evalúe las opciones para sus necesidades de almacenamiento de alto rendimiento

Considera los discos persistentes o las unidades de estado sólido (SSD) locales para las aplicaciones de procesamiento que requieran almacenamiento de alto rendimiento. Cloud Storage es un almacén de objetos inmutable con control de versiones. El uso de Cloud Storage con Cloud CDN ayuda a optimizar los costos, en especial para los objetos estáticos a los que se accede con frecuencia.

Filestore admite aplicaciones con múltiples operaciones de escritura que necesitan un espacio compartido de alto rendimiento. Filestore también admite aplicaciones heredadas y modernas que requieren operaciones de archivo similares a POSIX, a través de activaciones de Network File System (NFS).

Cloud Storage es útil para casos de uso como la creación de data lakes y el cumplimiento de requisitos de archivo. Es necesario evaluar las características y los costos de las distintas clases de almacenamiento de Cloud Storage, ya que los costos del acceso y de la recuperación varían. Esto es especialmente importante a la hora de configurar las políticas de retención. Si quieres obtener más información, consulta Diseña una estrategia de almacenamiento óptima para tu carga de trabajo en la nube.

De forma predeterminada, todas las opciones de almacenamiento se encriptan en reposo y en tránsito mediante claves administradas por Google. Para los tipos de almacenamiento como Persistent Disk y Cloud Storage, puedes proporcionar tu propia clave o administrarlos a través de Cloud Key Management Service (Cloud KMS). Define una estrategia para manejar esas claves antes de emplearlas en datos de producción.

Elige los servicios de Google Cloud para admitir el diseño de almacenamiento

Para obtener información sobre los servicios de Google Cloud que admiten el diseño de almacenamiento, usa la siguiente tabla:

Servicio de Google Cloud Descripción
Cloud Storage Ofrece almacenamiento y recuperación de cualquier cantidad de datos en todo el mundo y en cualquier momento. Cloud Storage puede usarse para diversos tipos de situaciones, como la entrega de contenido de sitios web, el almacenamiento de datos para el archivado y la recuperación ante desastres, o la distribución de objetos de datos grandes a los usuarios a través de descargas directas.

Para obtener más información, consulta lo siguiente:
Persistent Disk Almacenamiento en bloque de alto rendimiento para Google Cloud. Persistent Disk proporciona almacenamiento SSD y unidad de disco duro (HDD) que puedes adjuntar a las instancias que se ejecutan en Compute Engine o Google Kubernetes Engine (GKE).
  • Los discos regionales proporcionan almacenamiento duradero y replicación de datos entre dos zonas en la misma región. Si necesitas IOPS más altas y baja latencia, Google Cloud ofrece Filestore.
  • Las SSD locales están conectadas físicamente al servidor que aloja tu instancia de máquina virtual. Puedes usar las SSD locales como espacio temporal en el disco.
Filestore Un servicio de almacenamiento de archivos administrado para aplicaciones que requieren una interfaz de sistema de archivos y un sistema de archivos compartido para los datos. Filestore brinda a los usuarios una experiencia sin interrupciones para combinar el almacenamiento conectado a la red (NAS) administrado con sus instancias de Compute Engine y Google Kubernetes Engine.
Cloud Storage para Firebase Creado para desarrolladores de apps que necesitan almacenar y entregar contenido generado por los usuarios, como fotos o videos. Todos los archivos se almacenan en buckets de Cloud Storage, por lo que son accesibles tanto desde Firebase como desde Google Cloud.

Elige una estrategia de almacenamiento

Para seleccionar una estrategia de almacenamiento que cumpla con los requisitos de tu aplicación, usa la siguiente tabla:

Caso práctico Recomendaciones
Quieres almacenar datos a gran escala al menor costo y el rendimiento de acceso no es un problema. Cloud Storage
Ejecutas aplicaciones de procesamiento que necesitan almacenamiento inmediato.

Para obtener más información, consulta Optimiza el rendimiento de Persistent Disk y los SSD locales.
Persistent Disk o SSD local
Ejecutas cargas de trabajo de alto rendimiento que necesitan acceso de lectura y escritura al espacio compartido. Filestore
Tienes casos de uso de computación de alto rendimiento (HPC) o de computación de alta capacidad de procesamiento (HTC). Usa clústeres para computación técnica a gran escala en la nube

Elija entre almacenamiento activo o de archivos según sus necesidades de acceso al almacenamiento

Una clase de almacenamiento es una parte de los metadatos que usa cada objeto. Para los datos que se entregan a una velocidad alta con alta disponibilidad, usa la clase de almacenamiento Standard Storage. Para los datos a los que se accede con poca frecuencia y que pueden tolerar una disponibilidad un poco menor, usa la clase Nearline Storage, Coldline Storage o Archive Storage. Si deseas obtener más información sobre las consideraciones de costos para elegir una clase de almacenamiento, consulta Precios de Cloud Storage.

Evalúa las necesidades de protección de datos y ubicación de almacenamiento para Cloud Storage

En un bucket de Cloud Storage ubicado en una región, los datos que contiene se replican de forma automática en las zonas dentro de la región. La replicación de datos entre distintas zonas protege los datos si hay una falla zonal dentro de una región.

Cloud Storage también ofrece ubicaciones redundantes en todas las regiones, lo que significa que los datos se replican en varios centros de datos separados a nivel geográfico. Para obtener más información, consulte Ubicaciones de depósitos.

Use Cloud CDN para mejorar la entrega de objetos estáticos

Para optimizar el costo de recuperación de objetos y minimizar la latencia de acceso, usa Cloud CDN. Cloud CDN usa el balanceador de cargas de aplicaciones externo de Cloud Load Balancing para proporcionar enrutamiento, verificaciones de estado y asistencia de direcciones IP Anycast. Para obtener más información, consulte cómo configurar Cloud CDN con buckets.

Patrón de acceso al almacenamiento y tipo de carga de trabajo

En esta sección, se proporcionan prácticas recomendadas para elegir patrones de acceso de almacenamiento y tipos de cargas de trabajo a fin de que sean compatibles con tu sistema.

Usa Persistent Disk para admitir el acceso de almacenamiento de alto rendimiento

Los patrones de acceso a los datos dependen de cómo se diseñe el rendimiento del sistema. Cloud Storage proporciona almacenamiento escalable, pero no es una opción ideal cuando se ejecutan cargas de trabajo que requieren mucha capacidad de procesamiento necesitan acceso de alta capacidad a grandes cantidades de datos. Para el acceso a almacenamiento de alto rendimiento, usa Persistent Disk.

Use la retirada exponencial cuando implemente la lógica de reintentos

Use la retirada exponencial cuando implemente la lógica de reintento para manejar errores 5XX, 408 y 429. Cada bucket de Cloud Storage se aprovisiona con capacidad de E/S inicial. Para obtener más información, consulte los lineamientos de distribución de acceso y porcentaje de solicitudes. Planifique un incremento gradual para las solicitudes de reintento.

Administración de almacenamiento

En esta sección, se proporcionan prácticas recomendadas para que la administración del almacenamiento sea compatible con tu sistema.

Asigne un nombre único a cada bucket

Haga que cada nombre de bucket sea único en el espacio de nombres de Cloud Storage. No incluya información sensible en el nombre de un bucket. Elige nombres de buckets y objetos que sean difíciles de adivinar. Si deseas obtener más información, consulta los lineamientos para asignar nombres a buckets y los lineamientos a fin de asignar nombres a objetos.

Mantenga los buckets de Cloud Storage privados

A menos que haya un motivo relacionado con la empresa, asegúrate de que el bucket de Cloud Storage no sea accesible de forma anónima o pública. Para obtener más información, consulta Descripción general del control de acceso.

Asigne nombres aleatorios a los objetos a fin de distribuir la carga de manera pareja

Asigna nombres aleatorios a los objetos para facilitar el rendimiento y evitar la generación de hotspots. Use un prefijo aleatorizado para los objetos siempre que sea posible. Para obtener más información, consulta Usa una convención de nombres que distribuya las cargas de manera uniforme entre los rangos de claves.

Usa la prevención de acceso público

A fin de evitar accesos indeseados a nivel de la organización, las carpetas, los proyectos o los buckets, usa la prevención de acceso público. Para obtener más información, consulta Usa la prevención de acceso público.

¿Qué sigue?

Obtén información sobre los servicios de base de datos de Google Cloud y las prácticas recomendadas, incluidos los siguientes:

Explora otras categorías en el framework de arquitectura, como la confiabilidad, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Optimiza tu base de datos

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para implementar el sistema en función del diseño de la base de datos. Aprenderás a diseñar, migrar y escalar bases de datos, a encriptar información de la base de datos, a administrar las licencias y a supervisar la base de datos para eventos.

Servicios clave

En este documento de la categoría de diseño del sistema de framework de arquitectura, se proporcionan prácticas recomendadas que incluyen varios servicios de bases de datos de Google Cloud. En la siguiente tabla, se proporciona una descripción general de alto nivel de estos servicios:

Servicio de Google Cloud Descripción
Cloud SQL Un servicio de base de datos completamente administrado que te permite configurar, mantener, controlar y administrar tus bases de datos relacionales que usan Cloud SQL para PostgreSQL, Cloud SQL para MySQL y Cloud SQL para SQL Server. Cloud SQL ofrece alto rendimiento y escalabilidad. Alojado en Google Cloud, Cloud SQL proporciona una infraestructura de base de datos para aplicaciones que se ejecutan en cualquier lugar.
Bigtable Una tabla que puede escalar a miles de millones de filas y miles de columnas, lo que te permite almacenar hasta petabytes de datos. Se indexa solo un valor de cada fila; este es conocido como la clave de fila. Usa Bigtable para almacenar cantidades grandes de datos con una sola clave y una latencia muy baja. Admite una capacidad alta de procesamiento de lectura y escritura con baja latencia, y es la fuente de datos ideal para las operaciones de MapReduce.
Spanner Un servicio de base de datos empresarial, escalable y distribuido a nivel global creado para la nube que incluye una estructura de bases de datos relacionales y escalamiento horizontal no relacional. Esta combinación ofrece transacciones de alto rendimiento y coherencia en filas, regiones y continentes. Spanner proporciona un ANS de disponibilidad del 99.999%, sin tiempo de inactividad planificado y seguridad de nivel empresarial.
Memorystore Un servicio de Redis completamente administrado para Google Cloud. Las aplicaciones que se ejecutan en Google Cloud pueden aumentar el rendimiento mediante el servicio de Redis altamente escalable, disponible y con alta disponibilidad sin administrar implementaciones complejas de Redis.
Firestore Base de datos de documentos NoSQL creada a fin de proporcionar ajuste de escala automático, alto rendimiento y desarrollo de aplicaciones. Aunque la interfaz de Firestore comparte muchas de sus características con las bases de datos tradicionales, es una base de datos NoSQL que describe las relaciones entre los objetos de datos de manera diferente.
Firebase Realtime Database Una base de datos alojada en la nube. Firebase almacena datos como JSON y se sincroniza en tiempo real con cada cliente conectado. Cuando compilas apps multiplataforma con los SDK de JavaScript, Google, iOS y Android, todos los clientes comparten una instancia de base de datos en tiempo real y reciben actualizaciones automáticas con los datos más recientes.
Bases de datos de código abierto Los socios de Google ofrecen diferentes bases de datos de código abierto, como MongoDB, MariaDB y Redis.
AlloyDB para PostgreSQL Un servicio de base de datos completamente administrado y compatible con PostgreSQL para cargas de trabajo empresariales exigentes. Proporciona un rendimiento hasta 4 veces más rápido para las cargas de trabajo transaccionales y hasta 100 veces más rápidas para las consultas analíticas en comparación con PostgreSQL estándar. AlloyDB para PostgreSQL simplifica la administración con sistemas de piloto automático habilitados para el aprendizaje automático.

Selección de base de datos

En esta sección, se proporcionan prácticas recomendadas para elegir una base de datos que admita tu sistema.

Considere usar un servicio de base de datos administrado

Evalúa los servicios de bases de datos administrados de Google Cloud antes de instalar tu propia base de datos o clúster de base de datos. Instalar tu propia base de datos implica una sobrecarga de mantenimiento, incluida la instalación de parches y actualizaciones, y la administración de actividades operativas diarias, como la supervisión y la realización de copias de seguridad.

Usa requisitos de aplicación funcionales y no funcionales para elegir una base de datos. Considera el acceso de baja latencia, el procesamiento de datos en series temporales, la recuperación ante desastres y la sincronización de clientes móviles.

Para migrar bases de datos, usa uno de los productos que se describen en la siguiente tabla:

Producto de migración de bases de datos Descripción
Cloud SQL Un servicio regional que admite réplicas de lectura en regiones remotas, lecturas de baja latencia y recuperación ante desastres.
Spanner Una oferta multirregional que proporcione coherencia externa, replicación global y un Acuerdo de Nivel de Servicio (ANS) de cinco 9s.
Bigtable Un servicio de base de datos NoSQL escalable y completamente administrado para grandes cargas de trabajo de estadísticas y operaciones con una disponibilidad de hasta el 99.999%.
Memorystore Un servicio de bases de datos completamente administrado que proporciona una versión administrada de dos soluciones populares de almacenamiento en caché de código abierto: Redis y Memcached.
Firebase Realtime Database Firebase Realtime Database es una base de datos NoSQL alojada en la nube que te permite almacenar y sincronizar datos entre tus usuarios en tiempo real.
Firestore Base de datos de documentos NoSQL creada a fin de proporcionar ajuste de escala automático, alto rendimiento y facilidad para el desarrollo de aplicaciones.
Código abierto Opciones de base de datos alternativas, como MongoDB y MariaDB.

Migración de bases de datos

Para garantizar que los usuarios no experimenten tiempo de inactividad de las aplicaciones cuando migres cargas de trabajo existentes a Google Cloud, es importante elegir tecnologías de base de datos que sean compatibles con tus requisitos. A fin de obtener información sobre las opciones y prácticas recomendadas de migración de bases de datos, consulta Soluciones de migración de bases de datos y Prácticas recomendadas para migraciones de bases de datos homogéneas.

La planificación de una migración de bases de datos incluye lo siguiente:

  • Evaluación y descubrimiento de la base de datos actual.
  • Definiciones de los criterios de éxito de la migración.
  • Configuración del entorno para la migración y la base de datos de destino.
  • Creación del esquema en la base de datos de destino.
  • Migración de los datos a la base de datos de destino.
  • Validación de la migración para verificar que todos los datos se migren correctamente y estén presentes en la base de datos.
  • Creación de una estrategia de reversión.

Elija una estrategia de migración

Seleccionar una base de datos objetivo adecuada es una de las claves para una migración exitosa. En la siguiente tabla, se muestran las opciones de migración para algunos casos de uso:

Caso práctico Recomendación
Desarrollo nuevo en Google Cloud Seleccione una de las bases de datos administradas creadas para la nube (Cloud SQL, Spanner, Bigtable o Firestore) para satisfacer los requisitos de su casos de uso.
Migración lift-and-shift Selecciona un servicio de base de datos administrada compatible, como Cloud SQL, MySQL, PostgreSQL o SQLServer.
Una aplicación que requiere acceso detallado a una base de datos no compatible con Cloud SQL. Ejecuta tu base de datos en VM de Compute Engine.

Use Memorystore para respaldar la capa de almacenamiento en caché de la base de datos

Memorystore es una base de datos completamente administrada de Redis y Memcached que admite una latencia de submilisegundos. Memorystore es totalmente compatible con Redis y Memcached de código abierto. Si usas estas bases de datos de almacenamiento en caché en tus aplicaciones, puedes usar Memorystore sin hacer cambios de nivel de la aplicación en tu código.

Use servidores Bare Metal para ejecutar una base de datos de Oracle

Si tus cargas de trabajo requieren una base de datos de Oracle, usa servidores Bare Metal proporcionados por Google Cloud. Este enfoque se ajusta a una estrategia de migración de tipo lift-and-shift.

Si deseas mover tu carga de trabajo a Google Cloud y modernizarla después de que funcione, considera usar opciones de bases de datos administradas comoSpanner ,Bigtable y Firestore.

Las bases de datos compiladas para la nube son bases de datos administradas y modernas que se compilan desde cero con la infraestructura de nube. Estas bases de datos proporcionan capacidades predeterminadas únicas, como la escalabilidad y la alta disponibilidad, que son difíciles de lograr si ejecutas tu propia base de datos.

Modernice su base de datos

Planifica tu estrategia de bases de datos al inicio del proceso de diseño del sistema, ya sea que estés diseñando una nueva aplicación en la nube o que estés migrando una base de datos existente a la nube. Google Cloud ofrece opciones de bases de datos administradas para las bases de datos de código abierto, como Cloud SQL para MySQL y Cloud SQL para PostgreSQL. Te recomendamos usar la migración como una oportunidad para modernizar su base de datos y prepararla para admitir las necesidades futuras de la empresa.

Use bases de datos fijas con aplicaciones listas para usar

Las aplicaciones comerciales listas para usar (COTS) requieren un tipo de base de datos y una configuración fijos. La modalidad lift-and-shift suele ser el enfoque de migración más apropiado para las aplicaciones COTS.

Verifica el conjunto de habilidades de migración de la base de datos de tu equipo

Elige un enfoque de migración de bases de datos en la nube según las capacidades de migración de la base de datos de tu equipo y los conjuntos de habilidades. Usa Google Cloud Partner Advantage para encontrar un socio que te ayude en el proceso de migración.

Diseñe su base de datos para satisfacer los requisitos de HA y DR

Cuando diseñes tu base de datos para satisfacer tus requisitos de alta disponibilidad (HA) y recuperación ante desastres (DR), ten en cuenta el equilibrio entre la confiabilidad y el costo. Las bases de datos para la nube crean varias copias de tus datos dentro de una región o en varias regiones, según la base de datos y la configuración.

Algunos servicios de Google Cloud tienen variantes multirregionales, como BigQuery y Spanner. Para resistir ante fallas regionales, usa estos servicios multirregión en tu diseño cuando sea posible.

Si diseñas tu base de datos en las VM de Compute Engine en lugar de usar bases de datos administradas en Google Cloud, asegúrate de ejecutar varias copias de tus bases de datos. Para obtener más información, consulta Diseña para escala y alta disponibilidad en la categoría Confiabilidad.

Especifique las regiones de la nube en las que residirán los datos

El concepto de “residencia de los datos” hace referencia a la ubicación física de sus datos en reposo. Puedes elegir regiones de la nube específicas para implementar las bases de datos según tus requisitos de residencia.

Si implementas tus bases de datos en varias regiones, puede que los datos se repliquen entre ellas, según la configuración que elijas. Selecciona la configuración que mantenga los datos dentro de las regiones deseadas cuando estén en reposo. Algunas bases de datos, como Spanner, ofrecen replicación multirregional predeterminada. También puedes aplicar la residencia de datos mediante la configuración de una política de la organización que incluya las restricciones de las ubicaciones del recurso. Para obtener más información, consulta Restringe las ubicaciones de recursos.

Incluye la recuperación ante desastres en el diseño de residencia de datos

Incluye un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO) en tus planes de residencia de datos y considera el equilibrio entre el RTO/RPO y el costo de la solución de recuperación ante desastres. Cuanto menores sean los valores de RTO/RPO, mayores serán los costos. Si deseas una recuperación más rápida de las interrupciones, la ejecución del sistema será más costosa. Además, debes tomar en cuenta la satisfacción de los clientes en tu enfoque de recuperación ante desastres para tener la seguridad de que tus inversiones en confiabilidad sean adecuadas. Para obtener más información, consulta El 100% de la confiabilidad es el objetivo incorrecto y la Guía de planificación para la recuperación ante desastres.

Haz que tu base de datos cumpla con los requisitos de Google Cloud

A la hora de seleccionar una base de datos para tu carga de trabajo, asegúrate de que el servicio elegido satisfaga los requisitos de cumplimiento de la región geográfica en la que operará y en la que los datos se almacenarán físicamente. Para obtener más información sobre las certificaciones y los estándares de cumplimiento de Google, consulte Ofertas de cumplimiento.

Encriptación

En esta sección, se proporcionan prácticas recomendadas para identificar los requisitos de encriptación y elegir una estrategia de claves de encriptación que admita tu sistema.

Determine sus requisitos de encriptación

tus requisitos de encriptación dependen de varios factores, incluida las políticas de seguridad de la empresa y tus requisitos de cumplimiento. Todos los datos que se almacenan en Google Cloud están encriptados en reposo con AES256 de manera predeterminada, sin que se requiera ninguna acción de tu parte. Para obtener más información, consulta Encriptación en reposo en Google Cloud.

Elija una estrategia para las claves de encriptación

Decide si deseas administrar las claves de encriptación tú mismo o si deseas usar un servicio administrado. Google Cloud admite ambas opciones. Si desea usar un servicio completamente administrado para tus claves de encriptación en Google Cloud, selecciona Cloud Key Management Service (Cloud KMS). Si desea administrar tus claves de encriptación para tener más control sobre el ciclo de vida de una clave, usa claves de encriptación administradas por el cliente.

Para crear y administrar tus claves de encriptación fuera de Google Cloud, elige una de las siguientes opciones:

  • Si usas una solución de socios para administrar tus claves, usa Cloud External Key Manager.
  • Si administras tus claves de manera local y deseas usarlas para encriptar los datos en Google Cloud, importa esas claves a Cloud KMS, ya sea como claves de KMS o módulo de clave de hardware (HSM). Usa esas claves para encriptar tus datos en Google Cloud.

Diseño y escalamiento de bases de datos

En esta sección, se proporcionan prácticas recomendadas para diseñar y escalar una base de datos a fin de admitir tu sistema.

Use métricas de supervisión para evaluar sus necesidades de escalamiento

Usa métricas de entornos y herramientas de supervisión existentes a fin de establecer un modelo de referencia para comprender los requisitos de tamaño y escalamiento de la base de datos. Por ejemplo, determinar el tamaño adecuado y diseñar estrategias de escalamiento para tu instancia de base de datos.

Para los diseños de nuevas bases de datos, determina las cifras del escalamiento según los patrones de tráfico y carga previstos para la aplicación que entrega los datos. Para obtener más información, consulta Supervisa instancias de Cloud SQL, Supervisa con Cloud Monitoring y Supervisa una instancia.

Herramientas de redes y acceso

En esta sección, se proporcionan prácticas recomendadas para administrar las herramientas de redes y el acceso a tu sistema.

Ejecute las bases de datos dentro de una red privada

Ejecuta tus bases de datos dentro de tu red privada y otorga acceso restringido solo de los clientes que necesiten interactuar con la base de datos. Puedes crear instancias de Cloud SQL dentro de una VPC. Google Cloud también proporciona Controles del servicio de VPC para bases de datos de Cloud SQL, Spanner y Bigtable a fin de garantizar que el acceso a estos recursos se limite solo a los clientes que se encuentren dentro de las redes de VPC autorizadas.

Otorgue el mínimo de privilegios a los usuarios

Identity and Access Management (IAM) controla el acceso a los servicios de Google Cloud, incluidos los servicios de bases de datos. A fin de reducir al mínimo el riesgo de acceso no autorizado, otorga la menor cantidad posible de privilegios a tus usuarios. Para el acceso de nivel de aplicación a tus bases de datos, usa cuentas de servicio con el menor número de privilegios posible.

Automatización y dimensionamiento

En esta sección, se proporcionan prácticas recomendadas para definir la automatización y el redimensionamiento a fin de admitir tu sistema.

Defina las instancias de su base de datos como código

Uno de los beneficios de migrar a Google Cloud es la capacidad de automatizar la infraestructura y otros aspectos de la carga de trabajo, como las capas de procesamiento y de bases de datos. Google Deployment Manager y herramientas de terceros como Terraform Cloud te permiten definir las instancias de base de datos como código, lo que te permite aplicar un enfoque coherente y repetible para crear y actualizar tus bases de datos.

Usa Liquibase para controlar la versión de la base de datos

Los servicios de bases de datos de Google, como Cloud SQL y Spanner son compatibles con Liquibase, una herramienta de control de versiones de código abierto para bases de datos. Liquibase ayuda a hacer un seguimiento de los cambios de esquema de la base de datos, a revertir cambios de esquema y a realizar migraciones repetibles.

Prueba y ajusta tu base de datos para admitir el escalamiento

Realiza pruebas de carga de tu instancia de base de datos y ajústala en función de los resultados para que satisfaga los requisitos de tu aplicación. Determina la escala inicial de tu base de datos haciendo una prueba de carga de indicadores clave de rendimiento (KPI) o usando KPI de supervisión derivados de tu base de datos actual.

Cuando crees instancias de bases de datos, comienza con un tamaño basado en los resultados de las pruebas o en las métricas de supervisión históricas. Prueba tus instancias de base de datos con la carga esperada en la nube. Luego, ajusta las instancias hasta obtener los resultados que desees para la carga esperada en las instancias de base de datos.

Elige la base de datos adecuada para tus requisitos de escalamiento

El escalamiento de las bases de datos es diferente del escalamiento de los componentes de la capa de procesamiento. Las bases de datos tienen estado. Cuando una instancia de tu base de datos no pueda manejar la carga, considera la estrategia adecuada para escalar las instancias de la base de datos. Las estrategias de escalamiento varían según el tipo de base de datos.

Usa la siguiente tabla para obtener información sobre los productos de Google que abordan los casos de uso de escalamiento.

Caso práctico Producto recomendado Descripción
Escala de forma horizontal tu instancia de base de datos mediante la adición de nodos a tu base de datos cuando necesites escalar verticalmente la capacidad de entrega y el almacenamiento. Spanner Una base de datos relacional compilada para la nube.
Agrega nodos para escalar tu base de datos. Bigtable Servicio de base de datos de macrodatos NoSQL completamente administrado.
Controla automáticamente el escalamiento de la base de datos Firestore Base de datos flexible y escalable para el desarrollo móvil, web y de servidores.
Para entregar más consultas, escala verticalmente de forma vertical las instancias de base de datos de Cloud SQL a fin de darles más capacidad de procesamiento y memoria. En Cloud SQL, la capa de almacenamiento se separa de la instancia de la base de datos. Puedes optar por escalar la capa de almacenamiento de forma automática cada vez que se acerque a la capacidad. Cloud SQL Servicio de base de datos completamente administrado que te ayuda a configurar, mantener, controlar y administrar tus bases de datos relacionales en Google Cloud.

Operations

En esta sección, se proporcionan prácticas recomendadas para administrar las operaciones a fin de que sean compatibles con tu sistema.

Usa Cloud Monitoring para supervisar y configurar alertas para tu base de datos

Usa Cloud Monitoring para supervisar tus instancias de base de datos y configurar alertas que les avisen a los equipos correspondientes sobre cualquier evento. Para obtener más información sobre las prácticas recomendadas para generar alertas de forma eficiente, consulta Crea alertas eficientes.

Todas las bases de datos creadas para la nube proporcionan registros y métricas de supervisión. Cada servicio cuenta con un panel para visualizar los registros y las métricas de supervisión. Las métricas de supervisión de todos los servicios se integran en Google Cloud Observability. Spanner ofrece herramientas de introspección de consultas como Key Visualizer para realizar depuración y análisis de causa raíz. Key Visualizer cuenta con las siguientes funciones:

  • Ayuda a analizar los patrones de uso de Spanner generando informes visuales para las bases de datos. Los informes muestran los patrones de uso en rangos de filas a lo largo del tiempo.
  • Ofrece estadísticas de los patrones de uso a gran escala.

Bigtable también proporciona una herramienta de diagnóstico de Key Visualizer que te ayuda a analizar los patrones de uso de las instancias de Bigtable.

Licencias

En esta sección, se proporcionan prácticas recomendadas sobre las licencias para admitir tu sistema.

Elija entre licencias a pedido y licencias existentes

Si usas Cloud SQL para SQL Server, no se admiten las licencias adquiridas por el usuario; los costos de las licencias se basan en el uso por hora de núcleo.

Si deseas usar licencias existentes de Cloud SQL para SQL Server, considera ejecutar Cloud SQL para SQL Server en VMs de Compute. Para obtener más información, consulta licencias de Microsoft y Elige entre licencias a pedido y licencias existentes.

Si usas Oracle y estás migrando a la solución Bare Metal para Oracle, puedes usar licencias que hayas adquirido. Para obtener más información, consulta Planifica para la solución Bare Metal.

Cronogramas, metodología y conjuntos de herramientas de migración

En esta sección, se proporcionan prácticas recomendadas para planificar y admitir la migración de tu base de datos a fin de admitir tu sistema.

Determina la preparación de la modernización de la base de datos

Evalúa si tu organización está lista para modernizar las bases de datos y usarlas en la nube.

Considera la modernización de la base de datos cuando planifiques los cronogramas de migración de cargas de trabajo, ya que es probable que la modernización afecte la aplicación.

Involucra a las partes interesadas relevantes en la planificación de la migración

Para migrar una base de datos, completa las siguientes tareas:

  • Configura las bases de datos de destino.
  • Convierte el esquema.
  • Configura la replicación de datos entre la base de datos de origen y la de destino.
  • Depura los problemas a medida que se presenten durante la migración.
  • Establece la conectividad de red entre la capa de la aplicación y la base de datos.
  • Implementa la seguridad de la base de datos de destino.
  • Asegúrate de que las aplicaciones se conecten a las bases de datos de destino.

Estas tareas suelen requerir diferentes conjuntos de habilidades, y varios equipos colaboran en toda la organización para completar la migración. Cuando planifiques la migración, incluye a las partes interesadas de todos los equipos, como los desarrolladores de apps, los administradores de bases de datos y los equipos de infraestructura y seguridad.

Si tu equipo no tiene las habilidades necesarias para admitir este tipo de migración, los socios de Google pueden ayudarte a realizar las migraciones. Para obtener más información, consulta Google Cloud Partner Advantage.

Identifica conjuntos de herramientas para migraciones homogéneas y heterogéneas

Una migración homogénea es una migración de bases de datos entre las bases de datos de origen y de destino con la misma tecnología de base de datos. Una migración heterogénea es una migración cuya base de datos de destino es diferente de la de origen.

Las migraciones heterogéneas en general implican pasos adicionales de conversión de esquema desde la base de datos de origen al tipo de motor de base de datos de destino. Tus equipos de bases de datos deben evaluar los desafíos involucrados en la conversión del esquema, ya que dependen de la complejidad del esquema de la base de datos de origen.

Prueba y valida cada paso de la migración de datos

Las migraciones de datos implican varios pasos. Para minimizar los errores de la migración, prueba y valida cada paso antes de continuar con el siguiente. Los siguientes factores impulsan el proceso de migración:

  • Si la migración es homogénea o heterogénea.
  • El tipo de herramientas y conjuntos de habilidades que tienes para realizar la migración.
  • Para migraciones heterogéneas, tu experiencia con el motor de la base de datos de destino.

Determina los requisitos de replicación continua de datos

Crea un plan para migrar los datos inicialmente y, luego, replica de forma continua los datos de la fuente a la base de datos de destino. Continúa la replicación hasta que el destino se estabilice y la aplicación se migre completamente a la base de datos nueva. Este plan te ayuda a identificar el posible tiempo de inactividad durante el cambio de la base de datos y a planificar en consecuencia.

Si planeas migrar motores de base de datos de Cloud SQL, Cloud SQL para MySQL o Cloud SQL para PostgreSQL, usa el Servicio de migración de bases de datos para automatizar este proceso de forma completamente administrada. Para obtener información sobre herramientas de terceros que admiten otros tipos de migraciones, consulta Cloud Marketplace.

Recomendaciones

Para aplicar la guía del framework de arquitectura a tu propio entorno, te recomendamos que hagas lo siguiente:

  • El multiusuario para bases de datos implica el almacenamiento de datos de varios clientes en una infraestructura compartida, en este caso, una base de datos. Si brindas una oferta basada en software como servicio (SaaS) a tus clientes, asegúrate de comprender cómo puedes aislar de forma lógica los conjuntos de datos que pertenecen a diferentes clientes y admitir sus requisitos de acceso. Además, evalúa tus requisitos según los niveles de separación.

    Para las bases de datos relacionales, como Spanner y Cloud SQL, existen varios enfoques, como el aislamiento de los datos de usuarios en el nivel de instancia de base de datos, nivel de base de datos, nivel de esquema o de tabla de base de datos. Al igual que otras decisiones de diseño, existe una compensación entre el grado de aislamiento y otros factores como el costo y el rendimiento. Las políticas de IAM controlan el acceso a las instancias de base de datos.

  • Elige la base de datos adecuada para los requisitos del modelo de datos.

  • Seleccione valores de clave que permitan evitar la generación de hotspots. Un hotspot es una ubicación de una tabla que recibe muchas más solicitudes de acceso que las otras ubicaciones. Para obtener más información sobre los hotspots, consulta Recomendaciones sobre el diseño del esquema.

  • Fragmenta la instancia de base de datos siempre que sea posible.

  • Usa las prácticas recomendadas para la administración de conexiones, como la agrupación de conexiones y la retirada exponencial.

  • Evita las transacciones demasiado grandes.

  • Diseña y prueba la respuesta de la aplicación a las actualizaciones de mantenimiento en bases de datos.

  • Protege y aísla las conexiones a la base de datos.

  • Dimensiona la base de datos y evalúa el crecimiento previsible a fin de garantizar que sea adecuada para sus requisitos.

  • Prueba tus estrategias de conmutación por error de HA y DR.

  • Realiza copias de seguridad y restablecimiento, además de importaciones y exportaciones para que estés familiarizado con el proceso.

Recomendaciones de Cloud SQL

  • Usa redes con direcciones IP privadas (VPC). Para obtener seguridad adicional, considera lo siguiente:
  • Si necesitas herramientas de redes de dirección IP pública, considera lo siguiente:
    • Usa el firewall integrado con una lista limitada o estrecha de direcciones IP y asegúrate de que las instancias de Cloud SQL exijan que las conexiones usen SSL. Para obtener más información, consulta Configura certificados SSL/TLS.
  • Para obtener seguridad adicional, considera lo siguiente:
  • Usa privilegios limitados para los usuarios de la base de datos.

¿Qué sigue?

Conoce las prácticas recomendadas de análisis de datos, que incluyen lo siguiente:

Explora otras categorías en el framework de arquitectura, como la confiabilidad, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Analice sus datos

En este documento del framework de arquitectura de Google Cloud, se explican algunos de los principios básicos y las prácticas recomendadas para el análisis de datos en Google Cloud. Obtendrás información sobre algunos de los servicios de análisis de datos clave y cómo pueden ayudar en las diferentes etapas del ciclo de vida de los datos. Estas prácticas recomendadas te ayudan a satisfacer tus necesidades de análisis de datos y a crear el diseño de tu sistema.

Principios básicos

Las empresas quieren analizar datos y generar estadísticas prácticas a partir de ellos. Google Cloud te proporciona varios servicios que te ayudan durante todo el ciclo de vida de los datos, desde transferencia de datos hasta informes y visualización. La mayoría de estos servicios están completamente administrados y algunos no tienen servidores. También puedes compilar y administrar un entorno de análisis de datos en las VM de Compute Engine, como para alojar por cuenta propia Apache Hadoop. o Beam

Tu enfoque particular, perspectiva estratégica y la experiencia del equipo te ayudan a determinar qué servicios de Google Cloud debes adoptar para respaldar tus necesidades de análisis de datos. Por ejemplo, Dataflow te permite escribir transformaciones complejas en un enfoque sin servidores, pero debes depender de una versión bien definida de los parámetros de configuración para las necesidades de procesamiento. Como alternativa, Dataproc te permite ejecutar las mismas transformaciones, pero puedes administrar los clústeres y ajustar los trabajos por tu cuenta.

Para el diseño de tu sistema, piensa en la estrategia de procesamiento que usan tus equipos, como extracción, transformación y carga (ETL) o extracción, carga y transformación (ELT). Para el diseño de tu sistema, también debes considerar si necesitas procesar análisis por lotes o análisis de transmisiones. Google Cloud proporciona una plataforma de datos unificada y te permite compilar un data lake o un almacén de datos para satisfacer tus necesidades comerciales.

Servicios clave

En la siguiente tabla, se proporciona una descripción general de alto nivel de los servicios de análisis de Google Cloud:

Servicio de Google Cloud Descripción
Pub/Sub Base sencilla, confiable y escalable para el análisis de transmisiones y los sistemas de procesamiento basados en eventos.
Dataflow Un servicio completamente administrado para transformar y enriquecer datos en modos de transmisión (en tiempo real) y por lotes (históricos).
Dataprep de Trifacta Servicio de datos inteligente que permite limpiar, preparar y explorar de manera visual los datos estructurados y no estructurados para su análisis.
Dataproc Es un servicio en la nube rápido, fácil de usar y completamente administrado que permite ejecutar clústeres de Apache Spark y Apache Hadoop.
Cloud Data Fusion Servicio de integración de datos completamente administrado y compilado para la nube que te permite compilar y administrar canalizaciones de datos de ETL/ELT. Cloud Data Fusion proporciona una interfaz gráfica y una amplia biblioteca de código abierto de conectores y transformaciones preconfigurados.
BigQuery Almacén de datos sin servidores, completamente administrado y de bajo costo que se escala según tus necesidades de almacenamiento y potencia de procesamiento. BigQuery es una base de datos en columnas de ANSI SQL que puede analizar terabytes o petabytes de datos.
Cloud Composer Es un servicio de organización de flujos de trabajo completamente administrado que te permite crear, programar y supervisar canalizaciones que abarcan nubes y centros de datos locales.
Data Catalog Servicio de administración de metadatos completamente administrado y escalable que te ayuda a descubrir, administrar y comprender todos tus datos.
Looker Studio Servicio de análisis visual completamente administrado que puede ayudarte a obtener estadísticas de los datos a través de paneles interactivos.
Looker Plataforma empresarial que conecta, analiza y visualiza datos en entornos de múltiples nubes.
DataForm Producto completamente administrado que te ayuda a colaborar, crear e implementar canalizaciones de datos, y garantizar su calidad.
Dataplex Servicio de data lake administrado que administra, supervisa y rige datos en data lakes, almacenes de datos y data marts con controles coherentes.
AnalyticsHub Plataforma que intercambia de manera eficiente y segura los recursos de análisis de datos en toda tu organización para abordar los desafíos de confiabilidad y costo de los datos.

Ciclo de vida de los datos

Cuando creas el diseño de tu sistema, puedes agrupar los servicios de análisis de datos de Google Cloud en torno al movimiento de datos general en cualquier sistema o en torno al ciclo de vida de los datos.

El ciclo de vida de los datos incluye las siguientes etapas y servicios de ejemplo:

Las siguientes etapas y servicios se ejecutan durante todo el ciclo de vida de los datos:

  • La integración de datos incluye servicios como Data Fusion.
  • La administración de metadatos incluyen servicios como Data Catalog.
  • La administración de flujos de trabajo incluye servicios como Cloud Composer.

Transferencia de datos

Aplica las siguientes prácticas recomendadas de transferencia de datos en tu propio entorno.

Determina la fuente de datos para la transferencia

Por lo general, los datos provienen de otro proveedor o servicio en la nube, o de una ubicación local:

Ten en cuenta cómo deseas procesar tus datos después de transferirlos. Por ejemplo, el Servicio de transferencia de almacenamiento solo escribe datos en un bucket de Cloud Storage, y el Servicio de transferencia de datos de BigQuery solo escribe datos en un conjunto de datos de BigQuery. Cloud Data Fusion admite varios destinos.

Identifica las fuentes de datos por lotes o de transmisión

Ten en cuenta cómo necesitas usar tus datos y, además, identifica dónde tienes casos de uso de transmisión o por lotes. Por ejemplo, si ejecutas un servicio de transmisión global que tiene requisitos de latencia baja, puedes usar Pub/Sub. Si necesitas los datos para usarlos en informes y análisis, puedes transmitir datos a BigQuery.

Si necesitas transmitir datos desde un sistema como Apache Kafka en un entorno local o en otro entorno de nube, usa la plantilla de Dataflow de Kafka a BigQuery. En el caso de las cargas de trabajo por lotes, el primer paso suele ser transferir datos a Cloud Storage. Usa la herramienta de gsutil o el Servicio de transferencia de almacenamiento para transferir datos.

Transfiere datos con herramientas automatizadas

La transferencia manual de datos desde otros sistemas a la nube puede ser un desafío. Si es posible, usa herramientas que te permitan automatizar los procesos de transferencia de datos. Por ejemplo, Cloud Data Fusion proporciona conectores y complementos para llevar datos de fuentes externas con una GUI de arrastrar y soltar. Si los equipos quieren escribir algún código, Data Flow o BigQuery pueden ayudar a automatizar la transferencia de datos. Pub/Sub puede ayudar en un enfoque de bajo nivel de codificación o con prioridad en el código. Para transferir datos a buckets de almacenamiento, usa gsutil para tamaños de datos de hasta 1 TB. Para transferir cantidades de datos superiores a 1 TB, usa el Servicio de transferencia de almacenamiento.

Usa herramientas de migración para transferir datos desde otro almacén de datos

Si necesitas migrar desde otro sistema de almacén de datos, como Teradata, Netezza o Redshift, puedes usar la asistencia para la migración del Servicio de transferencia de datos de BigQuery. El Servicio de transferencia de datos de BigQuery también proporciona transferencias de terceros que te ayudan a transferir datos según un programa desde fuentes externas. Para obtener más información, consulta los enfoques de migración detallados de cada almacén de datos.

Estima tus necesidades de transferencia de datos

El volumen de datos que necesitas transferir te ayuda a determinar qué servicio usar en el diseño de tu sistema. Para la transferencia de datos de transmisión, Pub/Sub escala a decenas de gigabytes por segundo. Los requisitos regionales, de almacenamiento y de capacidad de tus datos te ayudan a determinar si Pub/Sub Lite es una mejor opción para el diseño de tu sistema. Para obtener más información, consulta Elige Pub/Sub o Pub/Sub Lite.

Para la transferencia por lotes de los datos, calcula cuántos datos deseas transferir en total y qué tan rápido deseas hacerlo. Revisa las opciones de migración disponibles, incluidas una estimación del tiempo y la comparación entre las transferencias en línea y las transferencias sin conexión.

Usa las herramientas adecuadas para transferir datos con regularidad y según un programa

El Servicio de transferencia de almacenamiento y el Servicio de transferencia de datos de BigQuery te permiten programar trabajos de transferencia. Para obtener un control detallado del tiempo de la transferencia o el sistema de origen y destino, usa un sistema de administración de flujos de trabajo como Cloud Composer. Si deseas un enfoque más manual, puedes usar Cloud Scheduler y Pub/Sub para activar una Cloud Function.
Si deseas administrar la infraestructura de procesamiento, puedes usar el comando de gsutil con cron para transferir hasta 1 TB de datos. Si usas este enfoque manual en lugar de Cloud Composer, sigue las prácticas recomendadas para crear secuencia de comandos de transferencias de producción.

Revise las necesidades de transferencia de datos de servidor FTP/SFTP

Si necesitas un entorno sin código para transferir datos de un servidor FTP/SFTP, puedes usar los complementos de copia de FTP. Si deseas modernizar y crear una solución de flujo de trabajo a largo plazo, Cloud Composer es un servicio completamente administrado que te permite leer y escribir desde varias fuentes y receptores.

Usa conectores de Apache Kafka para transferir datos

Si usas Pub/Sub, Dataflow o BigQuery, puedes transferir datos mediante uno de los conectores de Apache Kafka. Por ejemplo, el conector de Pub/Sub Kafka de código abierto te permite transferir datos desde Pub/Sub o Pub/Sub Lite.

Recursos adicionales

Almacenamiento de datos

Aplica las siguientes prácticas recomendadas de almacenamiento de datos en tu propio entorno.

Elige el almacén de datos adecuado para tus necesidades

Para ayudarte a elegir qué tipo de solución de almacenamiento usar, revisa y comprende el uso posterior de tus datos. Los siguientes casos de uso comunes de los datos ofrecen recomendaciones sobre qué producto de Google Cloud usar:

Caso de uso de datos Recomendación de producto
Basada en archivo Filestore
Servidores basados en objetos Cloud Storage
Latencia baja Bigtable
Series temporales Bigtable
Caché en línea Memorystore
Procesamiento de transacciones Cloud SQL
Inteligencia empresarial (IE) y estadísticas BigQuery
Procesamiento por lotes Cloud Storage

Bigtable si los datos entrantes son series temporales y necesitas acceso de baja latencia a ellos.

BigQuery si usas SQL.

Revisa las necesidades de estructura de los datos

Para la mayoría de los datos no estructurados, como archivos de texto y documentos, archivos de audio y video, o registros, un almacén basado en objetos es la opción más adecuada. Luego, puedes cargar y procesar los datos del almacenamiento de objetos cuando los necesites.

En el caso de los datos semiestructurados, como XML o JSON, los casos de uso y patrones de acceso a los datos ayudan a guiar tu elección. Puedes cargar esos conjuntos de datos en BigQuery para la detección automática de esquemas. Si tienes requisitos de latencia baja, puedes cargar tus datos JSON en Bigtable. Si tienes requisitos heredados o tus aplicaciones funcionan con bases de datos relacionales, también puedes cargar conjuntos de datos en un almacén de relación.

En el caso de los datos estructurados, como CSV, Parquet, Avro o ORC, puedes usar BigQuery si tienes requisitos de IE y estadísticas que usan SQL. Si deseas obtener más información, consulta cómo cargar datos por lotes. Si deseas crear un data lake en estándares y tecnologías abiertos, puedes usar Cloud Storage.

Migra datos y reduce los costos de HDFS

Busca formas de migrar datos del sistema de archivos distribuido de Hadoop (HDFS) de un entorno local o de otro proveedor de servicios en la nube a un sistema de almacenamiento de objetos más económico. Cloud Storage es la opción más frecuente de almacén de datos alternativo que eligen las empresas. Para obtener información sobre las ventajas y desventajas de esta opción, consulta Comparación entre HDFS y Cloud Storage.

Puedes migrar datos con un método de envío o extracción. Ambos métodos usan el comando hadoop distcp. Para obtener más información, consulta Migra datos de HDFS de un entorno local a Google Cloud.

También puedes utilizar el conector de Cloud Storage de código abierto para permitir que los trabajos de Hadoop y Spark accedan a los datos en Cloud Storage. El conector se instala de forma predeterminada en los clústeres de Dataproc y se puede instalar de forma manual en otros clústeres.

Usa el almacenamiento de objetos para compilar un data lake cohesivo

Un data lake es un repositorio centralizado diseñado para almacenar, procesar y proteger grandes cantidades de datos estructurados, semiestructurados o sin estructurar. Puedes usar Cloud Composer y Cloud Data Fusion para compilar un data lake.

Para compilar una plataforma de datos moderna, puedes usar BigQuery como tu fuente de datos central en lugar de Cloud Storage. BigQuery es un almacén de datos moderno con separación de almacenamiento y procesamiento. Un data lake compilado en BigQuery te permite realizar análisis tradicional de BigQuery en la consola de Cloud. También te permite acceder a los datos almacenados desde otros frameworks, como Apache Spark.

Recursos adicionales

Procesa y transforma datos

Aplica las siguientes prácticas recomendadas de análisis de datos a tu propio entorno cuando proceses y transformes datos.

Explora el software de código abierto que puedes usar en Google Cloud

Muchos servicios de Google Cloud usan software de código abierto para ayudarte a realizar la transición sin problemas. Google Cloud ofrece soluciones administradas y sin servidores que tienen API abiertas y son compatibles con frameworks de código abierto para reducir la dependencia de un proveedor.

Dataproc es un servicio administrado compatible con Hadoop que te permite alojar software de código abierto con poca carga operativa. Dataproc incluye compatibilidad con Spark, Hive, Pig, Presto y Zookeeper. También proporciona Hive Metastore como un servicio administrado para quitarse como un punto único de fallo en el ecosistema de Hadoop.

Puedes migrar a Dataflow si actualmente usas Apache Beam como motor de procesamiento por lotes y de transmisión. Dataflow es un servicio completamente administrado y sin servidores que usa Apache Beam. Usa Dataflow para escribir trabajos en Beam, pero deja que Google Cloud administre el entorno de ejecución.

Si usas CDAP como tu plataforma de integración de datos, puedes migrar a Cloud Data Fusion para obtener una experiencia completamente administrada.

Determina tus necesidades de procesamiento de datos de ETL o ELT

La experiencia y las preferencias de tu equipo ayudan a determinar el diseño del sistema sobre cómo procesar los datos. Google Cloud te permite usar sistemas de procesamiento de datos de ETL tradicionales o ELT más modernos.

Usa el framework adecuado para tu caso de uso de datos

Tus casos de uso de datos determinan qué herramientas y frameworks usar. Algunos productos de Google Cloud están compilados para manejar todos los siguientes casos de uso de datos, mientras que otros admiten mejor solo un caso de uso en particular.

  • Para un sistema de procesamiento de datos por lotes, puedes procesar y transformar datos en BigQuery con una interfaz de SQL que conoces. Si tienes una canalización existente que se ejecuta en Apache Hadoop o Spark de forma local o en otra nube pública, puedes usar Dataproc.
    • También puedes usar Dataflow si deseas una interfaz de programación unificada para casos de uso por lotes y de transmisión. Te recomendamos que modernices y uses Dataflow para ETL y BigQuery para ELT.
  • Para las canalizaciones de datos de transmisión, usa un servicio administrado y sin servidores como Dataflow, que proporciona sistema de ventanas, ajuste de escala automático y plantillas. Si deseas obtener más información, consulta Compila canalizaciones de datos listas para la producción mediante Dataflow.

  • Para casos de uso en tiempo real, como el análisis de series temporales o el análisis de videos en streaming, usa Dataflow.

Mantenga el control futuro de su motor de ejecución

Para minimizar la dependencia de un proveedor y poder usar una plataforma diferente en el futuro, usa el modelo de programación de Apache Beam y Dataflow como una solución administrada sin servidores. El modelo de programación de Beam te permite cambiar el motor de ejecución subyacente, como cambiar de Dataflow a Apache Flink o Apache Spark.

Usa Dataflow para transferir datos desde varias fuentes

Para transferir datos de varias fuentes, como Pub/Sub, Cloud Storage, HDFS, S3 o Kafka, usa Dataflow. Dataflow es un servicio administrado sin servidores que admite plantillas de Dataflow, lo que permite a tus equipos ejecutar plantillas desde diferentes herramientas.

Dataflow Prime proporciona ajuste de escala automático horizontal y vertical de máquinas que se utilizan en el proceso de ejecución de una canalización. También proporciona diagnósticos y recomendaciones inteligentes que identifican problemas y sugieren cómo solucionarlos.

Descubra, identifique y proteja datos sensibles

Usa la Sensitive Data Protection para inspeccionar y transformar datos estructurados y no estructurados. Sensitive Data Protection funciona con datos ubicados en cualquier parte de Google Cloud, como Cloud Storage o bases de datos. Puedes clasificar y enmascarar tus datos sensibles y asignarles tokens a fin de seguir usándolos de forma segura para el procesamiento posterior. Usa Sensitive Data Protection para realizar acciones como analizar datos de BigQuery o desidentificar y reidentificar PII en conjuntos de datos a gran escala.

Modernice los procesos de transformación de datos

Usa Dataform para escribir las transformaciones de datos como código y comenzar a usar el control de versión de forma predeterminada. También puedes adoptar prácticas recomendadas de desarrollo de software, como CI/CD, pruebas de unidades y control de versión para el código SQL. Dataform admite todos los productos y bases de datos principales de almacenes de datos en la nube, como PostgreSQL.

Recursos adicionales

Almacenes y análisis de datos

Aplica las siguientes prácticas recomendadas de análisis de datos y almacenes en tu propio entorno.

Revisa tus necesidades de almacenamiento de datos

Los data lakes y los almacenes de datos no son mutuamente exclusivos. Los data lakes son útiles para el almacenamiento y el procesamiento de datos no estructurados y semiestructurados. Los almacenes de datos son mejores para el análisis y la IE.

Revisa tus necesidades de datos a fin de determinar dónde almacenarlos y qué producto de Google Cloud es el más adecuado para procesar y analizar los datos. Los productos como BigQuery pueden procesar petabytes de datos y crecer con tus demandas.

Identifica oportunidades para migrar de un almacén de datos tradicional a BigQuery

Revisa los almacenes de datos tradicionales que se encuentran en uso en el entorno. A fin de reducir la complejidad y reducir los costos, identifica las oportunidades para migrar los almacenes de datos tradicionales a un servicio de Google Cloud, como BigQuery. Para obtener más información y ejemplos de situaciones, consulta Migra almacenes de datos a BigQuery.

Planifica el acceso federado a los datos

Revisa los requisitos de los datos y cómo quizás debas interactuar con otros productos y servicios. Identifica tus necesidades de federación de datos y crea un diseño de sistema adecuado.

Por ejemplo, BigQuery te permite definir tablas externas que pueden leer datos de otras fuentes, como Bigtable, Cloud SQL, Cloud Storage o Google Drive. Puedes unir estas fuentes externas con tablas que almacenes en BigQuery.

Usa ranuras flexibles de BigQuery para proporcionar capacidad de aumentos de actividad a pedido

A veces necesitas capacidad adicional para realizar análisis experimentales o exploratorios que necesitan muchos recursos de procesamiento. BigQuery te permite obtener capacidad de procesamiento adicional en forma de ranuras flexibles. Estas ranuras flexibles te ayudan cuando hay un período de alta demanda o cuando deseas completar un análisis importante.

Comprende las diferencias de esquema si migras a BigQuery

BigQuery es compatible con esquemas de estrella y copo de nieve, pero, de forma predeterminada, usa campos anidados y repetidos. Los campos anidados y repetidos pueden ser más fáciles de leer y correlacionar en comparación con otros esquemas. Si tus datos están representados en un esquema de estrella o copo de nieve, y si deseas migrar a BigQuery, revisa el diseño del sistema para detectar si se necesitan hacer cambios en los procesos o los análisis.

Recursos adicionales

Informes y visualización

Aplica las siguientes prácticas recomendadas de informes y visualización a tu propio entorno.

Usa BigQuery BI Engine para visualizar tus datos

BigQuery BI Engine es un servicio de análisis rápido y en la memoria. Puedes usar BI Engine para analizar los datos almacenados en BigQuery con un tiempo de respuesta de fracciones de segundo a las consultas y con alta simultaneidad. BI Engine está integrado en la API de BigQuery. Usa la capacidad de BI Engine reservada para administrar los precios según demanda o de tarifa plana según tus necesidades. BI Engine también puede funcionar con otras aplicaciones de IE o de paneles personalizados que requieren tiempos de respuesta de fracciones de segundo.

Moderniza tus procesos de BI con Looker

Looker es una plataforma empresarial moderna para IE, aplicaciones de datos y análisis incorporados. Puedes crear modelos de datos coherentes sobre tus datos con rapidez y precisión, y acceder a los datos dentro de los almacenes de datos analíticos y transaccionales. Looker también puede analizar tus datos en varias bases de datos y nubes. Si tienes procesos y herramientas de IE existentes, te recomendamos que te modernices y uses una plataforma central como Looker.

Recursos adicionales

Usa herramientas de administración de flujos de trabajo

El análisis de datos incluye varios procesos y servicios. Se transfieren datos entre diferentes herramientas y canalizaciones de procesamiento durante el ciclo de vida del análisis de datos. Para administrar y mantener las canalizaciones de datos de extremo a extremo, usa las herramientas de administración de flujos de trabajo adecuadas. Cloud Composer es una herramienta de administración de flujos de trabajo completamente administrada basada en el proyecto de Apache Airflow de código abierto.

Puedes usar Cloud Composer para iniciar canalizaciones de Dataflow y usar plantillas de flujo de trabajo de Dataproc. Cloud Composer también puede ayudarte a crear una canalización de CI/CD a fin de probar, sincronizar e implementar DAG o usar una canalización de CI/CD para el procesamiento de datos flujos de trabajo. Para obtener más información, consulta Cloud Composer: prácticas recomendadas de desarrollo.

Recursos de migración

Si ya ejecutas una plataforma de análisis de datos y deseas migrar algunas o todas las cargas de trabajo a Google Cloud, revisa los siguientes recursos de migración para obtener prácticas recomendadas y orientación:

¿Qué sigue?

Obtén información sobre las prácticas recomendadas del diseño de sistemas para la IA y el aprendizaje automático de Google Cloud, incluido lo siguiente:

Explora otras categorías en el framework de arquitectura, como la confiabilidad, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Implementa el aprendizaje automático

En este documento del framework de arquitectura de Google Cloud, se explican algunos de los principios básicos y las prácticas recomendadas para el análisis de datos en Google Cloud. Obtén información sobre algunos de los servicios clave de IA y aprendizaje automático (AA), y cómo pueden ayudar durante las diversas etapas del ciclo de vida de la IA y el AA. Estas prácticas recomendadas te ayudarán a satisfacer tus necesidades de IA y AA, y a crear el diseño del sistema. En este documento, se supone que estás familiarizado con los conceptos básicos de IA y AA.

Para simplificar el proceso de desarrollo y minimizar la sobrecarga cuando compilas modelos de AA en Google Cloud, debes considerar el nivel de abstracción más alto que tenga sentido para tu caso práctico. El nivel de abstracción se define como la cantidad de complejidad mediante la cual se ve o programa un sistema. Cuanto más alto sea el nivel de abstracción, menos detalles estarán disponibles para el usuario.

Para seleccionar los servicios de IA y AA de Google según las necesidades de tu empresa, usa la siguiente tabla:

Persona Servicios de Google
Usuarios empresariales Soluciones estándar como las siguientes:Contact Center AI Insights ,Document AI ,Discovery AI y la API de Cloud Healthcare.
Desarrolladores con experiencia mínima en AA Las API previamente entrenadas abordan tareas perceptivas comunes, como visión, video y lenguaje natural. Estas API son compatibles con modelos previamente entrenados y proporcionan detectores predeterminados. Están listas para usarse sin experiencia en AA ni esfuerzo de desarrollo de modelos. Las API previamente entrenadas incluyen: API de Vision, API de video, API de Natural Language, API de Speech-to-Text, API de Text-to-Speech y la API de Cloud Translation.
IA generativa para desarrolladores Vertex AI Search and Conversation permite a los desarrolladores usar sus capacidades listas para usar para compilar e implementar chatbots en minutos y los motores de búsqueda en cuestión de horas. Los desarrolladores que deseen combinar varias funcionalidades en flujos de trabajo empresariales pueden usar la API de Gen App Builder para una integración directa.
Desarrolladores y científicos de datos AutoML permite el desarrollo de modelos personalizados con tu propia imagen, video, texto o datos tabulares. AutoML acelera el desarrollo de modelos con búsqueda automática a través del catálogo de modelos de Google para la arquitectura de modelo más eficaz, por lo que no necesitas compilar el modelo. AutoML controla las tareas comunes por ti, como elegir una arquitectura de modelos, ajustar los hiperparámetros, aprovisionar máquinas para el entrenamiento y la entrega.
Ingenieros de AA y científicos de datos Las herramientas de modelos personalizados de Vertex AI te permiten entrenar y entregar modelos personalizados, y poner en funcionamiento el flujo de trabajo del AA. También puedes ejecutar tu carga de trabajo del AA en procesamientos autoadministrados, como las VM de Compute Engine.
Ingenieros de aprendizaje automático y científicos de datos La compatibilidad de la IA generativa en Vertex AI (también conocida como genai) proporciona acceso a los grandes modelos de IA generativa de Google para que puedas probar, ajustar e implementar los modelos en tus aplicaciones con tecnología de IA.
Ingenieros de datos, científicos de datos y analistas de datos familiarizados con las interfaces de SQL BigQuery ML te permite desarrollar modelos basados en SQL sobre los datos almacenados en BigQuery.

Servicios clave

En la siguiente tabla, se proporciona una descripción general de alto nivel de los servicios de IA y AA:

Google service (Servicio de Google) Descripción
Cloud Storage y BigQuery Proporciona opciones de almacenamiento flexible para artefactos y datos de aprendizaje automático.
BigQuery ML Te permite compilar modelos de aprendizaje automático directamente a partir de datos alojados en BigQuery.
Pub/Sub, Dataflow,
Cloud Data Fusion y Dataproc
Admite la transferencia y el procesamiento de datos por lotes y en tiempo real. Para obtener más información, consulta Análisis de datos.
Vertex AI Ofrece a los científicos de datos y a los ingenieros de aprendizaje automático una plataforma única para crear, entrenar, probar, supervisar, ajustar e implementar modelos de AA para todo tipo de objetivos, desde la IA generativa hasta las MLOps.

Las herramientas incluyen lo siguiente:
Vertex AI Search and Conversation Te permite compilar chatbots y motores de búsqueda para sitios web y usarlos en datos empresariales.
  • La IA conversacional en Vertex AI Search and Conversation puede ayudar a reinventar las interacciones de los clientes y los empleados con chatbots con tecnología de IA generativa y asistentes digitales. Por ejemplo, con estas herramientas, puedes ofrecer más que solo información si habilitas las transacciones en la experiencia de chat.
  • Enterprise Search en Vertex AI Search and Conversation: Permite que las empresas compilen experiencias de búsqueda para clientes y empleados en sus sitios web públicos o privados. Además de brindar resultados de búsqueda multimodales de alta calidad, Enterprise Search puede resumir los resultados y proporcionar las citas correspondientes con IA generativa.
IA generativa en Vertex AI Te da acceso a los grandes modelos de IA generativa de Google para que puedas probarlos, ajustarlos e implementarlos para su uso en tus aplicaciones con tecnología de IA. La IA generativa en Vertex AI también se conoce como genai.
  • Los modelos de IA generativa, también conocidos como modelos de base, se clasifican según el tipo de contenido que pueden generar. Este contenido incluye texto y chat, imágenes, código e incorporaciones de texto.
  • Generative AI Studio te permite crear prototipos y probar modelos de IA generativa con rapidez en la consola de Google Cloud. Puedes probar mensajes de muestra, diseñar tus propios mensajes y personalizar los modelos de base para administrar tareas que satisfagan las necesidades de tu aplicación.
  • El ajuste de modelos te permite personalizar los modelos de base para casos de uso específicos con un conjunto de datos de ejemplos de entrada y salida.
  • Model Garden proporciona modelos de base de nivel empresarial, modelos para tareas específicas y APIs.
API previamente entrenadas
AutoML Proporciona herramientas de modelos personalizados para compilar, implementar y escalar modelos de AA. Los desarrolladores pueden subir sus propios datos y usar el servicio de AutoML aplicable para compilar un modelo personalizado.
  • AutoML Image realiza la clasificación de imágenes y la detección de objetos en datos de imágenes.
  • AutoML Video: realiza la detección de objetos, la clasificación y el reconocimiento de acciones en los datos de video.
  • AutoML Text realiza la clasificación de idiomas, la extracción de entidades y el análisis de opiniones en datos de texto.
  • AutoML Translation: detecta y traduce entre pares de idiomas.
  • AutoML Tabular te permite compilar un modelo de regresión, clasificación o previsión. Orientado a datos estructurados.
Infraestructura de IA Te permite usar aceleradores de IA para procesar cargas de trabajo de AA a gran escala. Estos aceleradores te permiten entrenar y obtener inferencias de modelos de aprendizaje profundo y de modelos de aprendizaje automático de una manera rentable.

Las GPU pueden ayudar con la inferencia rentable y el entrenamiento de escalamiento vertical u horizontal para los modelos de aprendizaje profundo. Las unidades de procesamiento tensorial (TPU) son ASIC personalizados para entrenar y ejecutar redes neuronales profundas.
Dialogflow Entrega agentes virtuales que proporcionan una experiencia de conversación.
Contact Center AI Brinda una experiencia automatizada y con un centro de contactos rico en estadísticas con la funcionalidad Agent Assist para los agentes humanos.
Document AI Proporciona comprensión de los documentos a gran escala para documentos en general y documentos específicos, como documentos relacionados con la realización de préstamos.
Lending DocAI Automatiza el procesamiento de documentos hipotecarios. Reduce el tiempo de procesamiento y optimiza la captura de datos, a la vez que te ayuda con los requisitos regulatorios y de cumplimiento.
Procurement DocAI Convierte documentos no estructurados, como facturas y recibos, en datos estructurados para automatizar la captura de datos de adquisición a gran escala, aumentar la eficiencia operativa, mejorar la experiencia del cliente y fundamentar la toma de decisiones.
Recomendaciones Ofrece recomendaciones personalizadas de productos.
IA de Healthcare Natural Language Te permite revisar y analizar documentos médicos.
API de traducción de medios Habilita la traducción de voz en tiempo real de los datos de audio.

Procesamiento de datos

Aplica las siguientes prácticas recomendadas de procesamiento de datos en tu propio entorno.

Asegúrate de que tus datos cumplan con los requisitos del AA

Los datos que usas para el AA deben cumplir con ciertos requisitos básicos, sin importar el tipo de datos. Estos requisitos incluyen la capacidad de los datos para predecir el objetivo, la coherencia en el nivel de detalle entre los datos utilizados para el entrenamiento y los datos utilizados para la predicción, y los datos etiquetados con precisión para el entrenamiento. Tus datos también deberían ser suficientes en el volumen. Para obtener más información, consulta Procesamiento de datos.

Almacena datos tabulares en BigQuery

Si usas datos tabulares, considera almacenar todos los datos en BigQuery y usar la API de BigQuery Storage para leer datos desde allí. Para simplificar la interacción con la API, usa una de las siguientes opciones de herramientas adicionales, según dónde desees leer los datos:

El tipo de datos de entrada también determina las herramientas de desarrollo disponibles del modelo. Las API previamente entrenadas, AutoML y BigQuery ML pueden proporcionar entornos de desarrollo más rentables y eficientes para ciertos casos de uso de imágenes, videos, texto y datos estructurados.

Asegúrate de tener datos suficientes para desarrollar un modelo de AA

Para desarrollar un modelo de AA útil, debes tener suficientes datos. Para predecir una categoría, la cantidad recomendada de ejemplos de cada categoría es 10 veces la cantidad de atributos. Cuantas más categorías desees predecir, más datos necesitarás. Los conjuntos de datos desequilibrados requieren aún más datos. Si no tienes suficientes datos etiquetados disponibles, considera usar el aprendizaje semisupervisado.

El tamaño del conjunto de datos también tiene implicaciones de entrenamiento y entrega: si tienes un conjunto de datos pequeño, puedes entrenarlo directamente en una instancia de Notebooks; si tienes conjuntos de datos más grandes que requieren entrenamiento distribuido, usa el servicio de entrenamiento personalizado de Vertex AI. Si deseas que Google entrene el modelo para tus datos, usa AutoML.

Prepara datos para consumo

Los datos bien preparados pueden acelerar el desarrollo de modelos. Cuando configures tu canalización de datos, asegúrate de que esta pueda procesar datos por lotes y de transmisión a fin de obtener resultados coherentes de ambos tipos de datos.

Desarrollo y entrenamiento de modelos

Aplica las siguientes prácticas recomendadas de desarrollo y entrenamiento de modelos a tu propio entorno.

Elige el desarrollo de modelos administrados o con entrenamiento personalizado

Cuando compiles tu modelo, considera el nivel más alto de abstracción posible. Usa AutoML cuando sea posible para que las tareas de desarrollo y entrenamiento se manejen por ti. En el caso de los modelos con entrenamiento personalizado, elige opciones administradas para escalabilidad y flexibilidad, en lugar de opciones autoadministradas. Para obtener más información sobre las opciones de desarrollo de modelos, consulta Usa herramientas y productos recomendados.

Considera el servicio de entrenamiento de Vertex AI en lugar del entrenamiento autoadministrado en las VM de Compute Engine o los contenedores de VM de aprendizaje profundo. Para un entorno de JupyterLab, considera usar Vertex AI Workbench, que proporciona entornos de JupyterLab administrados y administrados por el usuario. Para obtener más información, consulta Desarrollo de aprendizaje automático y Entrenamiento para poner en funcionamiento.

Usa contenedores previamente compilados o personalizados para modelos con entrenamiento personalizado

Para los modelos con entrenamiento personalizado en Vertex AI, puedes usar contenedores previamente compilados o personalizados según el framework de aprendizaje automático y la versión del framework. Hay contenedores previamente compilados disponibles para aplicaciones de entrenamiento de Python que se crean para versiones específicas de TensorFlow, scikit-learn, PyTorch y XGBoost.

De lo contrario, puedes optar por compilar un contenedor personalizado para tu trabajo de entrenamiento. Por ejemplo, usa un contenedor personalizado si deseas entrenar tu modelo con un framework de AA de Python que no está disponible en un contenedor previamente compilado, o si deseas entrenar con un lenguaje de programación que no sea de Python. En el contenedor personalizado, instala previamente la aplicación de entrenamiento y todas sus dependencias en una imagen que ejecute el trabajo de entrenamiento.

Considera los requisitos de entrenamiento distribuido

Considera tus requisitos de entrenamiento distribuido. Algunos frameworks de AA, como TensorFlow y PyTorch, te permiten ejecutar un código de entrenamiento idéntico en varias máquinas. Estos frameworks coordinan de forma automática la división del trabajo en función de las variables de entorno que se establecen en cada máquina. Otros frameworks pueden requerir una personalización adicional.

¿Qué sigue?

Para obtener más información sobre la IA y el aprendizaje automático, consulta los siguientes vínculos:

Explora otras categorías en el framework de arquitectura, como la confiabilidad, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Diseño para la sustentabilidad ambiental

En este documento del framework de arquitectura de Google Cloud, se resume cómo puedes abordar la sustentabilidad ambiental de tus cargas de trabajo en Google Cloud. Se incluye información sobre cómo minimizar tu huella de carbono en Google Cloud.

Obtén información sobre tu huella de carbono

Para comprender la huella de carbono de tu uso de Google Cloud, usa el panel Huella del carbono. El panel Huella de carbono atribuye los emisiones a los proyectos de Google Cloud que posees y a los servicios en la nube que usas.

Para obtener más información, consulta Comprende tu huella de carbono en “Reduce tu huella de carbono de Google Cloud”.

Elige las regiones más adecuadas en la nube

Una forma sencilla y eficaz de reducir las emisiones de carbono es elegir regiones en la nube con menos emisiones de carbono. Para ayudarte a elegir, Google publica datos sobre el carbono de todas las regiones de Google Cloud.

Cuando eliges una región, es posible que debas equilibrar la reducción de las emisiones con otros requisitos, como los precios y la latencia de la red. Para ayudar a seleccionar una región, usa el Selector de región de Google Cloud.

Para obtener más información, consulta Elige las regiones de la nube más adecuadas en “Reduce tu huella de carbono de Google Cloud”.

Elige los servicios más adecuados en la nube

Para ayudar a reducir tu huella de carbono existente, considera migrar tus cargas de trabajo de VM locales a Compute Engine.

También considera que muchas cargas de trabajo no requieren VM. A menudo, puedes usar una alternativa sin servidores. Estos servicios administrados pueden optimizar el uso de los recursos de nube, a menudo automáticamente, lo que reduce la huella de carbono y los costos de la nube de forma simultánea.

Para obtener más información, consulta Elige los servicios en la nube más adecuados en “Reduce tu huella de carbono de Google Cloud”.

Minimiza los recursos inactivos en la nube

Los recursos inactivos generan costos y emisiones innecesarios. Algunas causas comunes de recursos inactivos son las siguientes:

Las siguientes son algunas estrategias generales para ayudar a minimizar el desperdicio de recursos de nube:

  • Identifica los recursos inactivos o aprovisionados en exceso y bórralos o ajusta su tamaño.
  • Refactoriza tu arquitectura para incorporar un diseño óptimo.
  • Migra cargas de trabajo a servicios administrados.

Para obtener más información, consulta Minimiza los recursos de la nube inactivos en “Reduce tu huella de carbono de Google Cloud”.

Reduce las emisiones de las cargas de trabajo por lotes

Ejecuta cargas de trabajo por lotes en regiones con menos emisiones de carbono. Para obtener más reducciones, ejecuta las cargas de trabajo en momentos que coincidan con una menor intensidad de carbono de la red cuando sea posible.

Para obtener más información, consulta Reduce las emisiones de las cargas de trabajo por lotes en “Reduce tu huella de carbono de Google Cloud”.

¿Qué sigue?

Framework de arquitectura de Google Cloud: Excelencia operativa

En esta categoría del Framework de arquitectura de Google Cloud, se muestra cómo operar los servicios de manera eficiente en Google Cloud. Se analiza cómo ejecutar, administrar y supervisar los sistemas que entregan valor empresarial. También se analizan productos y funciones de Google Cloud que admiten la excelencia operativa. Usar los principios de excelencia operativa te ayuda a sentar las bases para la confiabilidad. Para ello, configura elementos fundamentales, como la observabilidad, la automatización y la escalabilidad.

En este Framework de arquitectura, se describen las prácticas recomendadas, se proporcionan recomendaciones de implementación y se explican algunos productos y servicios disponibles que te ayudan a alcanzar la excelencia operativa. Este framework busca ayudarte a diseñar la implementación de Google Cloud que mejor se adapte a las necesidades de tu empresa.

En la categoría de excelencia operativa del Framework de arquitectura, aprenderás a hacer lo siguiente:

Automatizar sus implementaciones

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para automatizar tus compilaciones, implementaciones y pruebas.

La automatización te ayuda a estandarizar tus implementaciones, pruebas y compilaciones con la eliminación de los errores causados por las personas en procesos repetidos, como las actualizaciones de código. En esta sección, se describe cómo usar varias verificaciones y protecciones a medida que automatizas. Un proceso estandarizado controlado por máquinas ayuda a garantizar que tus implementaciones se apliquen de forma segura. También proporciona un mecanismo para restablecer las implementaciones anteriores según sea necesario sin afectar de manera significativa la experiencia del usuario.

Almacena tu código en repositorios de código central

Almacena tu código en repositorios de código central que incluyan un sistema de control de versión con etiquetado y la capacidad de revertir cambios de código. El control de versiones te permite organizar archivos y controlar el acceso, las actualizaciones y la eliminación en equipos y organizaciones.

Para diferentes etapas del desarrollo, etiqueta los repositorios y controla su versión según sea necesario. Por ejemplo, las etiquetas podrían ser test, dev y prod.

En Google Cloud, puedes almacenar tu código en Cloud Source Repositories y, además, controlar su versión e integrarlos en otros productos de Google Cloud. Si compilas aplicaciones alojadas en contenedores, usa Artifact Registry, un registro administrado para contenedores.

Para obtener más detalles sobre el control de versión, consulta Control de versión. Para obtener detalles sobre la implementación del desarrollo basado en troncales con tus repositorios, consulta Desarrollo basado en troncales.

Use la integración y la implementación continuas (CI/CD)

Automatiza tus implementaciones con un enfoque de integración continua e implementación continua (CI/CD). Un enfoque de CI/CD es una combinación de canalizaciones que configuras y procesos que tu equipo de desarrollo sigue.

Un enfoque de CI/CD aumenta la velocidad de implementación, ya que hace que el equipo de desarrollo de software sea más productivo. Este enfoque permite que los desarrolladores realicen cambios más pequeños y más frecuentes que se prueban de forma exhaustiva mientras reducen el tiempo necesario para implementar esos cambios.

Como parte de tu enfoque de CI/CD, automatiza todos los pasos que forman parte de la compilación, la prueba y la implementación de tu código. Por ejemplo:

  • Siempre que se confirme un código nuevo en el repositorio, haz que la confirmación invoque de forma automática la canalización de compilación y prueba.
  • Automatiza las pruebas de integración
  • Automatiza tu implementación para que los cambios se implementen después de que la compilación cumpla con los criterios de prueba específicos.

En Google Cloud, puedes usar Cloud Build y Cloud Deploy para las canalizaciones de CI/CD.

Usa Cloud Build para ayudar a definir las dependencias y versiones que puedes usar para el empaquetado y la compilación de un paquete de aplicación. Crea una versión de tu configuración de compilación para asegurarte de que todas las compilaciones sean coherentes de que puedas revertir a una configuración anterior si es necesario.

Usa Cloud Deploy para implementar las aplicaciones en entornos específicos en Google Cloud y administrar las canalizaciones de implementación.

Para obtener más detalles sobre la implementación de CI/CD, consulta Integración continua y Automatización de la implementación.

Aprovisiona y administra tu infraestructura con infraestructura como código

La infraestructura como código es el uso de un modelo descriptivo para administrar la infraestructura, como las VM, y las configuraciones, como las reglas de firewall. La infraestructura como código te permite hacer lo siguiente:

  • Crea tus recursos de nube automáticamente, incluidos los entornos de implementación o de prueba para tu canalización de CI/CD.
  • Tratar los cambios en la infraestructura como tratas los cambios en las aplicaciones. Por ejemplo, asegurarte de que los cambios en la configuración se revisen, se prueben y se puedan auditar.
  • Tener una sola versión de la verdad para tu infraestructura de nube.
  • Replicar tus entornos de nube según sea necesario.
  • Si es necesario, revertir a una configuración anterior.

Este concepto de infraestructura como código también se aplica a los proyectos en Google Cloud. Puedes usar este enfoque para definir recursos como la conectividad de VPC compartida o el acceso a Identity and Access Management (IAM) en tus proyectos. Para ver un ejemplo de este enfoque, consulta el módulo de Terraform de fábrica de proyectos de Google Cloud.

Las herramientas de terceros, como Terraform, te ayudan a crear automáticamente tu infraestructura en Google Cloud. Para obtener más información, consulta Administra la infraestructura como código con Terraform, Cloud Build y GitOps.

Considera usar las funciones de Google Cloud, como retenciones del proyecto, Políticas de retención de Cloud Storage y bloqueos de buckets de Cloud Storage para proteger los recursos críticos y evitar que se borren de forma accidental o maliciosa.

Incorpora pruebas durante el ciclo de vida de la entrega de software

Las pruebas son fundamentales para iniciar el software de forma correcta. Las pruebas continuas ayudan a los equipos a crear software de alta calidad más rápido y mejorar la estabilidad del software.

Tipos de pruebas:

  • Pruebas de unidades. Las pruebas de unidades son breves y te ayudan a realizar implementaciones rápidas. Trata las pruebas de unidades como parte de la base de código e inclúyelas como parte del proceso de compilación.
  • Pruebas de integración. Las pruebas de integración son importantes, en especial para las cargas de trabajo diseñadas para el escalamiento y que dependen de más de un servicio. Estas pruebas pueden volverse complejas cuando pruebas la integración con servicios interconectados.
  • Pruebas del sistema. Las pruebas del sistema consumen mucho tiempo y son complejas, pero te ayudan a identificar casos extremos y solucionar problemas antes de la implementación.
  • Otras pruebas. Hay otras pruebas que debes ejecutar, incluidas las pruebas estáticas, de carga, de seguridad, de validación de políticas y otras. Ejecuta estas pruebas antes de implementar tu aplicación en producción.

Para incorporar pruebas, haz lo siguiente:

  • Realizar todos los tipos de pruebas de forma continua durante todo el ciclo de vida de la entrega de software.
  • Automatiza estas pruebas y, luego, inclúyelas en la canalización de CI/CD. Haz que la canalización falle si falla alguna de las pruebas.
  • Actualiza y agrega pruebas nuevas de forma continua para mejorar y mantener el estado operativo de tu implementación.

Para los entornos de prueba:

  • Usa proyectos de Google Cloud separados para cada entorno de prueba que tengas. Para cada aplicación, usa un entorno de proyecto separado. Esta separación proporciona una demarcación clara entre los recursos del entorno de producción y los de tus entornos inferiores. Esta separación ayuda a garantizar que cualquier cambio en un entorno no afecte de forma accidental a otros entornos.
  • Automatiza la creación de entornos de prueba. Una forma de hacerlo es usar la infraestructura como código.
  • Usa un entorno de producción sintético para probar cambios. Este proporciona un entorno similar al de producción para probar la aplicación y realizar varios tipos de pruebas en las cargas de trabajo, incluidas las pruebas de extremo a extremo y las de rendimiento.

Para obtener más información de la implementación de pruebas continuas, consulta Automatización de pruebas.

Lanza las implementaciones de forma gradual

Elige tu estrategia de implementación en función de parámetros importantes, como la interrupción mínima para los usuarios finales, las actualizaciones progresivas, las estrategias de reversión y las estrategias de prueba A/B. Para cada carga de trabajo, evalúa estos requisitos y elige una estrategia de implementación a partir de técnicas comprobadas, como actualizaciones progresivas, implementaciones azul-verde e implementaciones de versiones canary.

Solo permite que los procesos de CI/CD realicen y envíen cambios en tu entorno de producción.

Considera usar una infraestructura inmutable. Una infraestructura inmutable es una infraestructura que no se modifica ni se actualiza. Cuando necesites implementar un código nuevo o cambiar cualquier otra configuración en tu entorno, reemplaza todo el entorno (por ejemplo, una colección de VM o Pods) por el entorno nuevo. Las implementaciones azul-verde son un ejemplo de una infraestructura inmutable.

Te recomendamos que realices pruebas de versiones canary y observes si hay errores en tu sistema a medida que implementas cambios. Este tipo de observación es más fácil si tienes un sistema de supervisión y alertas sólido. Para realizar pruebas A/B o pruebas canary, puedes usar los grupos de instancias administrados de Google Cloud. Luego, puedes realizar un lanzamiento lento o un restablecimiento si es necesario.

Considera usar Cloud Deploy para automatizar las implementaciones y administrar la canalización de estas. También puedes usar muchas herramientas de terceros, como Spinnaker y Tekton, en Google Cloud para implementaciones automatizadas y crear canalizaciones de implementación.

Restablece las versiones anteriores sin problemas

Define tu estrategia de restablecimiento como parte de tu estrategia de implementación. Asegúrate de poder revertir una implementación o una configuración de infraestructura a una versión anterior del código fuente. Restablecer una implementación anterior estable es un paso importante en la administración de los incidentes de confiabilidad y seguridad.

También asegúrate de poder restablecer el entorno al estado que tenía antes de que comenzara el proceso de implementación. Esto puede incluir lo siguiente:

  • La capacidad de revertir cualquier cambio en el código en tu aplicación.
  • La capacidad de revertir cualquier cambio de configuración realizado en el entorno.
  • Usar una infraestructura inmutable y garantizar que las implementaciones no cambien el entorno. Estas prácticas facilitan la reversión de cambios de configuración.

Supervisa tus canalizaciones de CI/CD

Para que tu proceso automatizado de compilación, prueba e implementación siga ejecutándose sin problemas, supervisa las canalizaciones de CI/CD. Configura alertas que indiquen cuando falle cualquier elemento en cualquier canalización. Cada paso de tu canalización debe escribir instrucciones de registro adecuadas para que tu equipo pueda realizar un análisis de causa raíz si una canalización falla.

En Google Cloud, todos los servicios de CI/CD se integran en Google Cloud Observability. Por ejemplo:

Para obtener detalles sobre la supervisión y el registro, consulta Configura la supervisión, las alertas y los registros.

Implementa aplicaciones de manera segura

Revisa la sección Implementa aplicaciones de manera segura en la categoría seguridad, cumplimiento y privacidad del framework de arquitectura.

Establece lineamientos de administración para los lanzamientos de versiones

Para ayudar a tus ingenieros a evitar cometer errores y habilitar la entrega de software de alta velocidad, asegúrate de que tus lineamientos de administración para lanzar nuevas versiones de software estén documentados con claridad.

Los ingenieros de actualización supervisan cómo se compila y se entrega el software. El sistema de ingeniería de versiones se rige por cuatro prácticas:

  • Modo de autoservicio. Establece lineamientos para ayudar a los ingenieros de software a evitar errores comunes. En general, estos lineamientos se codifican en procesos automatizados.

  • Actualizaciones frecuentes. Una velocidad alta facilita la solución de problemas. Las actualizaciones frecuentes se basan en pruebas de unidades automatizadas.

  • Compilaciones herméticas. Garantiza la coherencia con tus herramientas de compilación. Crea versiones de los compiladores que usaste para compilar versiones ahora y hace un mes.

  • Aplicación de la política. Todos los cambios necesitan revisión de código, lo que incluye un conjunto de lineamientos y políticas para aplicar la seguridad. Cuando se aplican políticas, se mejora la revisión de código, la solución de problemas y las pruebas de un nuevo lanzamiento.

¿Qué sigue?

Configurar la supervisión, las alertas y los registros

En este documento del framework de arquitectura de Google Cloud, se muestra cómo configurar la supervisión, las alertas y el registro para que puedas actuar según el comportamiento del sistema. Esto incluye identificar métricas significativas para hacer un seguimiento y crear paneles a fin de facilitar la visualización de la información sobre tus sistemas.

El programa de investigación de Recursos y evaluación de DevOps (DORA) define la supervisión de la siguiente manera:

"La supervisión es el proceso de recopilar, analizar y usar la información para hacer un seguimiento de las aplicaciones y la infraestructura a fin de poder orientarse en el momento de tomar decisiones empresariales. La supervisión es una función clave porque te brinda estadísticas sobre tus sistemas y tu trabajo".

La supervisión permite a los propietarios del servicio realizar las siguientes acciones:

  • Tomar decisiones fundamentadas cuando los cambios en el servicio afecten el rendimiento
  • Aplicar un enfoque científico a la respuesta ante incidentes
  • Medir la alineación del servicio con los objetivos comerciales

Con la supervisión, el registro y las alertas implementadas, puedes hacer lo siguiente:

  • Analizar las tendencias a largo plazo
  • Comparar tus experimentos en el tiempo
  • Definir alertas sobre métricas críticas
  • Crear paneles relevantes en tiempo real
  • Realizar un análisis retrospectivo
  • Supervisar las métricas basadas en negocios y las métricas de estado del sistema.
    • Las métricas basadas en negocios te ayudan a comprender cómo los sistemas respaldan tu negocio. Por ejemplo, usa las métricas para supervisar lo siguiente:
      • El costo de una aplicación que se entregará a un usuario
      • El cambio de volumen en el tráfico del sitio después de un nuevo diseño
      • Cuánto tiempo le toma a un cliente comprar un producto en tu sitio
    • Las métricas de estado del sistema te ayudan a comprender si los sistemas funcionan de forma correcta y dentro de niveles de rendimiento aceptables.

Usa los siguientes cuatro indicadores de oro para supervisar tu sistema:

  • Latencia. Es el tiempo que toma realizar una solicitud.
  • Tráfico. Cuánta demanda se coloca en su sistema.
  • Errores. La tasa de solicitudes que fallan. El error puede ser explícito (por ejemplo, HTTP 500), implícito (por ejemplo, una respuesta HTTP 200 exitosa con el contenido incorrecto) o por política (por ejemplo, si confirmaste tiempos de respuesta de un segundo, las solicitudes de más de un segundo son un error).
  • Saturación. Qué tan completo es tu servicio. La saturación es una medida de la fracción de sistema, que destaca los recursos más restringidos (es decir, en un sistema con restricción de memoria, muestra la memoria; en un sistema con restricción de E/S, muestra E/S).

Crea un plan de supervisión

Crea un plan de supervisión que se alinee con la misión y la estrategia de operaciones de la organización. Incluye la planificación de la supervisión y la observabilidad durante el desarrollo de la aplicación. Incluir un plan de supervisión al principio del desarrollo de la aplicación puede llevar a una organización hacia la excelencia operativa.

Incluye los siguientes detalles en tu plan de supervisión:

  • Incluye todos tus sistemas, como los recursos locales y los recursos en la nube.
  • Incluye la supervisión de los costos de la nube para asegurarte de que los eventos de escalamiento no hagan que el uso supere los límites del presupuesto.
  • Crea diferentes estrategias de supervisión para medir el rendimiento de la infraestructura, la experiencia del usuario y los indicadores clave de rendimiento de la empresa (KPI). Por ejemplo, los umbrales estáticos pueden funcionar bien para medir el rendimiento de la infraestructura, pero no reflejan la experiencia del usuario.

Actualiza el plan a medida que crezcan las estrategias de supervisión. Itera en el plan para mejorar el estado de tus sistemas

Define métricas que midan todos los aspectos de tu organización

Define las métricas necesarias para medir el comportamiento de tu implementación. Para ello, deberás hacer lo siguiente:

  • Define tus objetivos comerciales.
  • Identifica las métricas y los KPI que pueden brindarte información cuantificable para medir el rendimiento. Asegúrate de que las definiciones de métricas se traduzcan en todos los aspectos de tu organización, desde las necesidades comerciales, incluidos los costos de la nube, hasta los componentes técnicos.
  • Usa estas métricas a fin de crear indicadores de nivel de servicio (SLIs) para tus aplicaciones. Para obtener más información, consulta Elige los SLIs adecuados.

Métricas comunes para diversos componentes

Las métricas se generan en todos los niveles de tu servicio, desde la infraestructura y las herramientas de redes hasta la lógica empresarial. Por ejemplo:

  • Métricas de infraestructura:
    • Estadísticas de máquinas virtuales, incluidas las instancias, la CPU, la memoria, el uso y los recuentos
    • Estadísticas basadas en el contenedor: utilización de clúster, capacidad de clúster, utilización del nivel de pods y recuentos.
    • Estadísticas de las Herramientas de redes, incluidas la entrada/salida, el ancho de banda entre los componentes, la latencia y la capacidad de procesamiento
    • Solicitudes por segundo, según lo que mida el balanceador de cargas
    • Total de bloques de disco leídos, por disco
    • Paquetes enviados a través de una interfaz de red determinada
    • Tamaño del montón de memoria para un proceso determinado
    • Distribución de las latencias de respuesta
    • Cantidad de consultas no válidas que rechazó una instancia de base de datos
  • Las métricas de la aplicación:
    • Comportamiento específico de la aplicación, que incluye consultas por segundo, escrituras por segundo y mensajes enviados por segundo
  • Métricas de estadísticas de servicios administrados:
    • Las QPS, la capacidad de procesamiento, la latencia y el uso de los servicios administrados por Google (API o productos como BigQuery, App Engine y Bigtable)
  • Métricas de estadísticas de conectividad de red:
    • Estadísticas relacionadas con la VPN o la interconexión sobre cómo conectarse a sistemas locales o externos a Google Cloud.
  • SLI
    • Las métricas asociadas con el estado general del sistema.

Configura la supervisión

Configura la supervisión para supervisar los recursos locales y los recursos en la nube.

Elige una solución de supervisión que cumpla con las siguientes características:

  • Sea independiente de la plataforma
  • Proporcione capacidades uniformes para supervisar entornos locales, híbridos y de múltiples nubes.

Use una sola plataforma para consolidar los datos de supervisión que provienen de diferentes fuentes te permite compilar métricas uniformes y paneles de visualización.

A medida que configures la supervisión, automatiza las tareas de supervisión cuando sea posible.

Supervisión con Google Cloud

Usar un servicio de supervisión, como Cloud Monitoring, es más fácil que crear un servicio de supervisión. La supervisión de una aplicación compleja es una tarea de ingeniería importante por sí sola. Incluso con la infraestructura existente de instrumentación, recopilación y visualización de datos, y alertas implementadas, es un trabajo de tiempo completo para alguien que realice la compilación y el mantenimiento.

Considera usar Cloud Monitoring a fin de obtener visibilidad en el rendimiento, la disponibilidad y el estado de las aplicaciones y la infraestructura para los recursos locales y en la nube.

Cloud Monitoring es un servicio administrado que forma parte de Google Cloud Observability. Puedes usar Cloud Monitoring para supervisar los servicios de Google Cloud y las métricas personalizadas. Cloud Monitoring proporciona una API para la integración en herramientas de supervisión de terceros.

Cloud Monitoring agrupa métricas, registros y eventos de la infraestructura basada en la nube de tu sistema. Los datos les brindan a los desarrolladores y operadores un conjunto abundante de indicadores visibles que pueden acelerar el análisis de las causas de origen y reducir el tiempo promedio de resolución. Puedes usar Cloud Monitoring para definir alertas y métricas personalizadas que cumplan con tus objetivos comerciales y te ayuden a agregar, visualizar y supervisar el estado del sistema.

Cloud Monitoring proporciona paneles predeterminados para servicios de aplicaciones de código abierto y en la nube. Mediante el modelo de métricas, puedes definir paneles personalizados con herramientas de visualización potentes y configurar gráficos en el Explorador de métricas.

Configurar las alertas

Un buen sistema de alertas mejora tu capacidad de lanzar funciones. Ayuda a comparar el rendimiento en el tiempo para determinar la velocidad de los lanzamientos de funciones o la necesidad de revertirlos. Si deseas obtener información sobre las reversiones, consulta Restablece versiones anteriores sin problemas.

A medida que configuras las alertas, asigna las alertas directamente a las métricas críticas. Entre estas métricas críticas, se incluyen las siguientes:

  • Los cuatro indicadores clave:
    • Latencia
    • Tráfico
    • Errores
    • Saturación
  • Estado del sistema
  • Uso del servicio
  • Eventos de seguridad
  • Experiencia del usuario

Haz que las alertas sean prácticas a fin de minimizar el tiempo de resolución. Para ello, haz lo siguiente en cada alerta:

  • Incluye una descripción clara, como qué se supervisa y el impacto en la empresa.
  • Proporciona toda la información necesaria para actuar de inmediato. Si se necesitan algunos clics y navegación para comprender las alertas, es difícil que la persona de turno actúe.
  • Define los niveles de prioridad para varias alertas.
  • Identifica con claridad a la persona o el equipo responsable de responder a la alerta.

Para aplicaciones y servicios críticos, compila acciones de autorreparación en las alertas activadas debido a condiciones de falla comunes, como falla de estado del servicio, cambio de configuración o aumentos de la capacidad de procesamiento.

A medida que configures las alertas, intenta eliminar el trabajo repetitivo. Por ejemplo, elimina el trabajo repetitivo mediante la eliminación de los errores frecuentes o la automatización de las correcciones de estos errores, lo que posiblemente evita que se active una alerta. Quitar el trabajo repetitivo permite que quienes estén en las llamadas se enfoquen en hacer que los componentes operativos de tu aplicación sean confiables. Para obtener más información, consulta Crea una cultura de automatización.

Crea paneles de supervisión y alertas

Una vez implementada la supervisión, compila paneles relevantes y sin complicaciones que incluyan información de tus sistemas de supervisión y alertas.

Elegir una forma adecuada de visualizar tu panel puede ser difícil de relacionar con tus objetivos de confiabilidad. Crea paneles para visualizar ambos:

  • Análisis a corto plazo y en tiempo real
  • Análisis a largo plazo

Para obtener más información sobre la implementación de la administración visual, consulta el artículo de capacidad Administración visual.

Habilita el registro para aplicaciones críticas

Los servicios de registro son fundamentales para supervisar tus sistemas. Si bien las métricas forman la base de los elementos específicos que se supervisan, los registros contienen información valiosa que necesitas para la depuración, el análisis relacionado con la seguridad y los requisitos de cumplimiento.

El registro de los datos que generan tus sistemas te ayuda a garantizar una postura de seguridad eficaz. Para obtener más información sobre el registro y la seguridad, consulta Implementa controles de registro y de detección en la categoría de seguridad del framework de arquitectura.

Cloud Logging es un servicio de registro integrado que puedes usar para almacenar, buscar, analizar, supervisar y generar alertas sobre eventos y datos de registro. Logging recopila de forma automática los registros de los servicios de Google Cloud y otros proveedores de servicios en la nube. Puedes usar estos registros a fin de compilar métricas para supervisar y crear exportaciones de registros a servicios externos, como Cloud Storage, BigQueryPub/Sub.

Configura un registro de auditoría

Para responder preguntas como “quién hizo qué, dónde y cuándo” en los proyectos de Google Cloud, usa los Registros de auditoría de Cloud.

Los Registros de auditoría de Cloud capturan varios tipos de actividad, como las siguientes:

  • Los registros de actividad del administrador contienen entradas de registro de las llamadas a la API o las otras acciones administrativas que modifican la configuración o los metadatos de los recursos. Los registros de actividad del administrador siempre están habilitados.
  • Los registros de auditoría de acceso a los datos registran las llamadas a la API que crean, modifican o leen los datos proporcionados por el usuario. Estos registros están inhabilitados de forma predeterminada, ya que pueden ser extensos. Puedes configurar qué servicios de Google Cloud producen registros de acceso a los datos.

Para obtener una lista de los servicios de Google Cloud que escriben registros de auditoría, consulta Servicios de Google con registros de auditoría. Usa Identity and Access Management (IAM) para limitar quién tiene acceso a fin de ver los registros de auditoría.

¿Qué sigue?

Establecer procesos de derivación y asistencia en la nube

En este documento del Framework de arquitectura de Google Cloud, se muestra cómo definir un proceso de derivación eficaz. Establecer asistencia de tu proveedor de servicios en la nube o de otros proveedores de servicios de terceros es una parte clave de una administración de derivación eficaz.

Google Cloud te proporciona varios canales de asistencia, incluida la asistencia en vivo o a través de orientación publicada, como comunidades de desarrolladores o documentación del producto Una oferta de Atención al cliente de Cloud garantiza que puedas trabajar con Google Cloud para ejecutar tus cargas de trabajo de manera eficiente.

Establece la asistencia de tus proveedores

Compra un contrato de asistencia de tu proveedor de servicios en la nube o de otros proveedores de servicios externos. La asistencia es fundamental para garantizar la respuesta y la resolución rápidas de varios problemas operativos.

Para trabajar con Atención al cliente de Google Cloud, considera comprar una oferta de atención al cliente que incluya asistencia Estándar, Enhanced o Premium. Considera usar la Asistencia Enhanced o Premium para tus entornos de producción principales.

Define tu proceso de derivación

Un proceso de derivación bien definido es clave si deseas reducir el esfuerzo y el tiempo que lleva identificar y abordar cualquier problema en tus sistemas. Esto incluye problemas que requieren asistencia para productos de Google Cloud o de otros productores de servicios en la nube o servicios de terceros.

Para crear tu ruta de derivación, sigue estos pasos:

  • Define cuándo y cómo derivar problemas de forma interna.
  • Define cuándo y cómo crear casos de asistencia con tu proveedor de servicios en la nube o con otro proveedor de servicios externo.
  • Aprende a trabajar con los equipos que te brindan asistencia. Para Google Cloud, tú y tus equipos de operaciones deben revisar las Prácticas recomendadas para trabajar con Atención al cliente. Incorpora estas prácticas a tu ruta de derivación.
  • Encuentra o crea documentos que describan tu arquitectura. Asegúrate de que estos documentos incluyan información útil para los ingenieros de asistencia.
  • Define cómo se comunican tus equipos durante una interrupción.
  • Asegúrate de que las personas que necesitan asistencia tengan niveles adecuados de permisos de asistencia para acceder a Google Cloud Support Center o para comunicarse con otros proveedores de asistencia. Si deseas obtener información sobre cómo usar Google Cloud Support Center, visita la página sobre procedimientos de asistencia.
  • Configura la supervisión, las alertas y los registros para que tengas la información necesaria a fin de tomar medidas cuando surjan problemas.
  • Crea plantillas para los informes de incidentes. A fin de conocer qué información incluir en tus informes de incidentes, consulta Prácticas recomendadas para trabajar con Atención al cliente.
  • Documenta el proceso de derivación de tu organización. Asegúrate de tener acciones claras y bien definidas para abordar las derivaciones.
  • Incluye un plan para enseñarles a los miembros nuevos del equipo a interactuar con la asistencia.

Prueba tu proceso de derivación de forma periódica. Prueba tu proceso de derivación antes de que ocurran eventos importantes, como migraciones, lanzamientos de productos nuevos y eventos de tráfico máximo. Si tienes Asistencia premium de Atención al cliente de Google Cloud, tu Administrador técnico de cuentas puede ayudarte a revisar el proceso de derivación y coordinar las pruebas con Atención al cliente de Google Cloud.

Asegúrate de recibir comunicaciones de la asistencia

Asegúrate de que los administradores reciban comunicaciones de tus proveedores de servicios en la nube y servicios de terceros. Esta información permite a los administradores tomar decisiones fundamentadas y solucionar problemas antes de que causen problemas más grandes. Asegúrate de que se cumplan las siguientes condiciones:

  • Los administradores de seguridad, red y sistema están configurados para recibir correos electrónicos críticos de Google Cloud y tus otros proveedores o servicios.
  • Los administradores de seguridad, red y sistema están configurados para recibir alertas del sistema generadas por herramientas de supervisión, como Cloud Monitoring.
  • Los propietarios del proyecto tienen nombres de usuario enrutables por correo electrónico para que puedan recibir correos electrónicos críticos.

Si deseas obtener más información a fin de administrar las notificaciones de Google Cloud, consulta Administra los contactos para las notificaciones.

Establece procesos de revisión

Establece procesos de revisión o a posteriori. Sigue estos procesos después de generar un ticket de asistencia nuevo o derivar un ticket de asistencia existente. Como parte del proceso a posteriori, documenta las lecciones aprendidas y realiza un seguimiento de las mitigaciones. A medida que haces esta revisión, fomenta una cultura libre de responsabilidades a posteriori.

Para obtener más información sobre los procesos a posteriori, consulta Cultura a posteriori: Aprender de los fracasos.

Crea centros de excelencia

Registrar la información, la experiencia y los patrones de la organización en una base de conocimiento interna, como una wiki, un sitio de Google o de intranet, puede ser muy valioso. A medida que se lanzan productos y funciones nuevos de forma continua en Google Cloud, este conocimiento puede ayudar a hacer un seguimiento de por qué elegiste un diseño particular para las aplicaciones y los servicios. Para obtener más información, consulta Registros de decisión de la arquitectura.

También se recomienda nominar a expertos y profesionales de Google Cloud en la organización. Para que los profesionales designados sigan creciendo en sus áreas de especialidad, se ofrece una variedad de opciones de capacitación y certificación. Si se suscriben al blog de Google Cloud, los equipos podrán estar al día sobre las últimas noticias, historias de clientes y anuncios.

¿Qué sigue?

Administrar la capacidad y la cuota

En este documento del framework de arquitectura de Google Cloud, se muestra cómo evaluar y planificar la capacidad y la cuota en la nube.

En los centros de datos convencionales, por lo general, dedicas ciclos trimestrales para revisar los requisitos de los recursos actuales y prever los requisitos futuros. Debes tener en cuenta aspectos físicos, logísticos y de recursos humanos. Se deben tener en cuenta aspectos como el espacio de bastidores, el enfriamiento, la electricidad, el ancho de banda, el cableado, los tiempos de adquisición y de envío, y la cantidad de ingenieros disponibles para montar nuevos equipos. También debes administrar de forma activa la capacidad y las distribuciones de la carga de trabajo para que los trabajos que requieren un uso intensivo de recursos, como las canalizaciones de Hadoop, no interfieran en los servicios, como los servidores web, que deben tener alta disponibilidad.

En cambio, cuando usas Google Cloud, otorgas la mayor parte de la planificación de capacidad a Google. El uso de la nube significa que no tienes que aprovisionar y mantener recursos inactivos cuando no son necesarios. Por ejemplo, puedes crear, escalar verticalmente y reducir la escala verticalmente de las instancias de VM según sea necesario. Debido a que pagas por lo que usas, puedes optimizar tus gastos, incluido el exceso de capacidad que solo necesitas en los momentos de mayor tráfico. Para ayudarte a ahorrar, Compute Engine proporciona recomendaciones de tipo de máquina si detecta que tienes instancias de VM con poco uso que se pueden borrar o cuyo tamaño se puede cambiar.

Evalúa los requisitos de capacidad de la nube

Para administrar la capacidad de manera efectiva, debes conocer los requisitos de capacidad de la organización.

Para evaluar los requisitos de capacidad, comienza por identificar las cargas de trabajo principales en la nube. Evalúa el uso promedio y máximo de estas cargas de trabajo y sus necesidades de capacidad actuales y futuras.

Identifica los equipos que usan estas cargas de trabajo principales. Trabaja con ellos para establecer un proceso interno de planificación de demanda. Usa este proceso para comprender sus necesidades de recursos de nube actuales y previstas.

Analiza el patrón de carga y la distribución de llamadas. Usa factores como el máximo de los últimos 30 días, el máximo por hora y el máximo por minuto en tu análisis.

Considera usar Cloud Monitoring para obtener visibilidad del rendimiento, el tiempo de actividad y el estado general de las aplicaciones y la infraestructura.

Visualiza las métricas de uso de infraestructura

Para facilitar la planificación de capacidad, recopila y almacena datos históricos sobre el uso de los recursos de nube de tu organización.

Asegúrate de tener visibilidad de las métricas de uso de la infraestructura. Por ejemplo, para las cargas de trabajo principales, evalúa lo siguiente:

  • Uso promedio y máximo
  • Aumentos repentinos de los patrones de uso
  • Aumentos estacionales según los requisitos comerciales, como los períodos de vacaciones para los minoristas
  • La cantidad de exceso de aprovisionamiento que se necesita para prepararse para los eventos de tráfico máximo y controlar con rapidez los posibles aumentos de tráfico

Asegúrate de que tu organización haya configurado alertas para recibir notificaciones automáticamente cuando te acerques a los límites de cuota y capacidad.

Usa las herramientas de supervisión de Google para obtener estadísticas sobre el uso y la capacidad de las aplicaciones. Por ejemplo, puedes definir métricas personalizadas con Monitoring. Usa estas métricas personalizadas para definir tendencias de alertas. Monitoring también proporciona paneles flexibles y herramientas de visualización avanzadas para identificar los problemas emergentes.

Crea un proceso para la planificación de la capacidad

Establece un proceso para la planificación de la capacidad y documentarlo.

Cuando crees este plan, haz lo siguiente:

  1. Ejecuta pruebas de carga para determinar cuánta carga puede manejar el sistema mientras cumple con sus objetivos de latencia, de acuerdo con una cantidad fija de recursos. Las pruebas de carga deben usar una combinación de tipos de solicitud que coincida con los perfiles de tráfico de producción de los usuarios activos. No uses una combinación de operaciones uniforme o aleatoria. Incluye los aumentos repentinos del uso en tu perfil de tráfico.
  2. Crea un modelo de capacidad. Un modelo de capacidad es un conjunto de fórmulas para calcular los recursos incrementales necesarios por aumento de unidad en la carga del servicio, que se determina a partir de las pruebas de carga.
  3. Prevé el tráfico futuro y considera el crecimiento. Consulta el artículo Mide las cargas futuras para obtener un resumen de cómo Google compila las previsiones del tráfico.
  4. Aplica el modelo de capacidad a la previsión para determinar las necesidades de recursos futuras
  5. Calcula el costo de los recursos que necesita tu organización. Luego, obtén la aprobación del presupuesto de tu organización de finanzas. Este paso es esencial porque la empresa puede optar por realizar compensaciones entre costo y riesgo en una variedad de productos. Esas compensaciones pueden significar la adquisición de capacidad que es inferior o superior a la necesidad prevista para un producto determinado según las prioridades empresariales.
  6. Trabaja con tu proveedor de servicios en la nube para obtener la cantidad correcta de recursos en el momento correcto con cuotas y reservas. Involucra a los equipos de infraestructura para la planificación de capacidad y haz que el equipo de operaciones cree planes de capacidad con intervalos de confianza.
  7. Repite los pasos anteriores cada uno o dos trimestres.

Para obtener orientación más detallada sobre el proceso de planificación de la capacidad y, a la vez, optimizar el uso de los recursos, consulta Planificación de la capacidad.

Asegúrate de que las cuotas coincidan con los requisitos de capacidad

Google Cloud usa cuotas para restringir cuánto de un recurso compartido particular de Google Cloud puedes usar. Cada cuota representa un recurso contable específico, como las llamadas a la API para un servicio en particular, la cantidad de balanceadores de cargas que se usan en simultáneo en tu proyecto o la cantidad de proyectos que puedes crear. Por ejemplo, las cuotas evitan que algunos clientes o proyectos monopolicen los núcleos de CPU en una región o zona específicas.

Cuando revises tu cuota, considera estos detalles:

  • Planifica los requisitos de capacidad de los proyectos con antelación para evitar limitaciones inesperadas del consumo de los recursos.
  • Configura tu cuota y tu capacidad para controlar fallas completas de la región.
  • Usa cuotas para limitar el consumo de un recurso en particular. Por ejemplo, puedes configurar una cuota máxima de uso de consultas por día en la API de BigQuery para garantizar que un proyecto no exceda el gasto en este servicio.
  • Planifica los aumentos repentinos de uso e incluye estos aumentos como parte de la planificación de la cuota. Los aumentos repentinos de uso se pueden esperar durante el día, los eventos de tráfico máximo inesperados o los eventos conocidos de lanzamiento y tráfico máximos. Para obtener detalles sobre cómo planificar el tráfico máximo y los eventos de lanzamiento, lee la siguiente sección en Excelencia operativa: Planifica para el tráfico máximo y los eventos de lanzamiento.

Si tus cuotas actuales no son suficientes, puedes administrar tu cuota desde la consola de Google Cloud. Si necesitas una capacidad mayor, comunícate con el equipo de ventas de Google Cloud. Sin embargo, debes tener en cuenta que muchos servicios también tienen límites que no están relacionados con el sistema de cuota, consulta Trabaja con cuotas para obtener más información.

Revisa las cuotas con regularidad. Envía las solicitudes de cuota antes de que sean necesarias. Consulta Trabaja con cuotas para obtener detalles sobre cómo se evalúan las solicitudes de cuota y cómo se aprueban o rechazan las solicitudes en general.

Existen varias formas de ver y administrar tu cuota de Google Cloud:

¿Qué sigue?

Planificar los eventos de tráfico máximo y de lanzamiento

En este documento del framework de arquitectura de Google Cloud, se muestra cómo planificar eventos de tráfico máximo y de lanzamiento para evitar interrupciones en el negocio.

Los eventos de tráfico máximo son eventos importantes relacionados con el negocio que causan un aumento repentino del tráfico más allá del modelo de referencia estándar de la aplicación. Estos eventos de tráfico máximo requieren escalamiento planificado.

Por ejemplo, los negocios minoristas con presencia en línea pueden esperar eventos de tráfico máximo durante las festividades. El Black Friday, un día después del Día de Acción de Gracias en Estados Unidos, es uno de los días de compras con más actividad del año. Para el sector de la atención médica en Estados Unidos, los meses de octubre y noviembre pueden tener eventos de tráfico máximo debido a los aumentos repentinos del tráfico en línea para la inscripción de beneficios.

Los eventos de lanzamiento son cualquier lanzamiento importante o migración de capacidades nuevas en producción. Por ejemplo, una migración local a la nube o el lanzamiento de una función nueva o un servicio nuevo de un producto.

Si lanzas un producto nuevo, debes esperar una mayor carga en tus sistemas durante el anuncio y, posiblemente, después. Estos eventos con frecuencia pueden causar aumentos de carga de 5 a 20 veces (o más) en los sistemas de frontend. Ese aumento de carga también aumenta la carga en los sistemas de backend. A menudo, estas cargas de frontend y backend se caracterizan por contar con escalamiento rápido durante un período breve a medida que el evento se abre para el tráfico web. Los eventos de lanzamiento implican una disminución final del tráfico hacia niveles normales. Esta disminución suele ser más lenta que el escalamiento hasta el máximo.

Los eventos de tráfico máximo y lanzamiento incluyen tres etapas:

  • Planificación y preparación para el evento de lanzamiento o de tráfico máximo
  • Lanzamiento del evento
  • Revisión del rendimiento y el análisis posterior de los eventos

Las prácticas descritas en este documento pueden ayudar a que cada una de estas etapas se ejecute sin problemas.

Crea una guía general para los eventos de lanzamiento y de tráfico máximo

Crea una guía general con una visión a largo plazo de los eventos de tráfico máximo actual y futuro. Sigue agregando lecciones aprendidas en el documento a fin de que pueda ser una referencia para eventos de tráfico máximo futuros.

Planifica tu lanzamiento y los eventos de tráfico máximo

Planifica con anticipación. Crea proyecciones de negocios para los próximos lanzamientos y eventos de tráfico máximo esperados (y también inesperados). Preparar tu sistema para aumentos de escalamiento depende de comprender las proyecciones de tu negocio. Cuanto más sepas sobre las previsiones anteriores, más precisas serán las previsiones nuevas de tu empresa. Esas previsiones nuevas son entradas críticas para proyectar la demanda esperada en tu sistema.

Establecer la administración del programa y la planificación coordinada, en toda tu organización y con proveedores externos, también es clave para el éxito. Se deben crear estos equipos pronto para que el equipo de administración del programa pueda definir cronogramas, presupuestos seguros y recopilar recursos para infraestructura adicional, asistencia de pruebas y entrenamiento.

Es importante configurar canales de comunicación claros. La comunicación es fundamental para todas las etapas de un lanzamiento o un evento de tráfico máximo. Analiza los riesgos y las áreas de preocupación de forma anticipada y resuelve los problemas antes de que se conviertan en bloqueadores. Crea la documentación de planificación de eventos. Resume la información más crítica sobre el evento de tráfico máximo y distribúyela. Esto ayuda a las personas a adquirir información sobre la planificación y resuelve preguntas básicas. El documento ayuda a que nuevas personas participen en la planificación de eventos de tráfico máximo.

Documenta tu plan para cada evento. Cuando documentes tu plan, asegúrate de hacer lo siguiente:

  • Identifica cualquier suposición, riesgos y factores desconocidos.
  • Revisa los eventos anteriores a fin de determinar la información relevante para el próximo evento de lanzamiento o de tráfico máximo. Determina qué datos están disponibles y qué valor proporcionaron en el pasado.
  • Detalla el plan de reversión para los eventos de lanzamiento y migración.
  • Realiza una revisión de la arquitectura:
    • Documenta los recursos clave y los componentes de la arquitectura.
    • Usa el framework de arquitectura para revisar todos los aspectos del entorno en busca de riesgos y problemas de escalamiento.
    • Crea un diagrama que muestre cómo se conectan los componentes principales de la arquitectura. Una revisión del diagrama puede ayudarte a aislar problemas y acelerar su resolución.
  • Si corresponde, configura el servicio para que use acciones de alerta a fin de reiniciarse automáticamente si hay una falla. Cuando uses Compute Engine, considera usar el ajuste de escala automático para controlar los aumentos de la capacidad de procesamiento.
  • Para asegurarte de que los recursos de Compute Engine estén disponibles cuando los necesites, usa reservas. Las reservas proporcionan un nivel de seguridad muy alto a fin de obtener capacidad para los recursos zonales de Compute Engine. Puedes usar las reservas para asegurarte de que tu proyecto tenga recursos disponibles.
  • Identifica las métricas y alertas para realizar un seguimiento de ellas:
    • Identifica las métricas del sistema y de la empresa para supervisar el evento. Si no se recopilan métricas o indicadores de nivel de servicio (SLI), modifica el sistema para recopilar estos datos.
    • Asegúrate de tener suficientes funciones de supervisión y alertas, y de haber revisado los patrones de tráfico máximos normales y anteriores. Asegúrate de que las alertas estén configuradas de forma correcta. Usa las herramientas de Google Cloud Monitoring para ver el uso de la aplicación, la capacidad y el estado general de las aplicaciones y la infraestructura.
    • Asegúrate de que las métricas del sistema se capturen con niveles de supervisión y alerta de interés.
  • Revisa los requisitos de mayor capacidad con tu equipo de cuentas de Google Cloud y planifica la administración de cuotas requerida. Para obtener más detalles, revisa Asegúrate de que las cuotas coincidan con los requisitos de capacidad.
  • Asegúrate de tener niveles de asistencia de nube adecuados, de que tu equipo comprenda cómo abrir casos de asistencia y que tengas establecida una ruta de derivación. Para obtener más detalles, revisa la sección sobre cómo establecer los procesos de derivación y asistencia de la nube.
  • Define un plan de comunicación, un cronograma y las responsabilidades:
    • Interactúa con las partes interesadas multifuncionales para coordinar la comunicación y la planificación del programa. Estas partes interesadas pueden incluir personas adecuadas de equipos técnicos, operativos y de liderazgo, y proveedores externos.
    • Establece un cronograma claro que contenga las tareas críticas y los equipos responsables de ellas.
    • Establece una matriz de asignación de responsabilidades (RACI) para comunicar la propiedad a los equipos, los líderes de equipos, las partes interesadas y las partes responsables.
    • Puedes usar el Servicio de administración de eventos de la Asistencia premium para eventos planificados de tráfico máximo. Con este servicio, la Atención al cliente se asocia con tu equipo para crear un plan y proporcionar orientación durante el evento.

Establecer procesos de revisión

Cuando finalice el evento de tráfico máximo o de lanzamiento, revísalo para documentar las lecciones que aprendiste. Luego, actualiza tu guía con esas lecciones. Por último, aplica lo que aprendiste en el próximo evento mayor. Es importante aprender de los eventos anteriores, en especial, cuando se destacan restricciones del sistema bajo estrés.

Las revisiones retrospectivas, también llamadas post mortem, para eventos de tráfico máximo o eventos de lanzamiento son una técnica útil a fin de capturar datos y comprender los incidentes que ocurrieron. Realiza esta revisión para el tráfico máximo y los eventos de lanzamiento que se ejecutaron como se esperaba y para cualquier incidente que haya causado problemas. A medida que hagas esta revisión, fomenta una cultura libre de culpas.

Para obtener más información sobre los procesos a posteriori, consulta Cultura a posteriori: Aprender de los fracasos.

¿Qué sigue?

Crear una cultura de automatización

En este documento del framework de arquitectura de Google Cloud, se muestra cómo evaluar el trabajo repetitivo y la reducción de su impacto en los sistemas y los equipos.

El trabajo manual es repetitivo, sin valor permanente y aumenta a medida que un servicio crece. Intenta reducir o eliminar el trabajo manual de forma continua. De lo contrario, el trabajo operativo puede sobrecargar a los operadores, y cualquier aumento en el uso o la complejidad del producto puede requerir personal adicional.

La automatización es una forma clave de minimizar el trabajo manual. La automatización también mejora la velocidad de lanzamiento y ayuda a minimizar los errores causados por los humanos.

Si deseas obtener más información, consulta Cómo borrar el trabajo repetitivo.

Crea un inventario y evalúa el costo del trabajo repetitivo

Comienza por crear un inventario y evaluar el costo del trabajo de los equipos que administran tus sistemas. Haz que este sea un proceso continuo, seguido de invertir en la automatización personalizada para extender lo que ya ofrecen los socios y servicios de Google Cloud. A menudo, puedes modificar la automatización de Google Cloud, por ejemplo, el escalador automático de Compute Engine.

Prioriza la eliminación del trabajo repetitivo

La automatización es útil, pero no es una solución a todos los problemas operativos. Como primer paso para abordar el trabajo repetitivo conocido, te recomendamos revisar tu inventario de trabajo existente y priorizar la eliminación de tanto trabajo repetitivo como puedas. Luego, puedes enfocarte en la automatización.

Automatiza el trabajo repetitivo necesario

Algunos trabajos repetitivos en sus sistemas no pueden ser eliminados. Como segundo paso para abordar el trabajo repetitivo conocido, automatiza este trabajo mediante las soluciones que proporciona Google Cloud a través de la automatización configurable.

Las siguientes son algunas áreas en las que la automatización configurable o personalizada puede ayudar a tu organización a eliminar el trabajo repetitivo:

  • Administración de identidades, por ejemplo, Cloud Identity and Access Management
  • Soluciones alojadas en Google Cloud, a diferencia de las soluciones autodiseñadas, por ejemplo, la administración de clústeres (Google Kubernetes Engine [GKE]), la administración de bases de datos relacionales (Cloud SQL), la administración de almacenes de datos (BigQuery), y la administración de API (Apigee).
  • Servicios de Google Cloud y aprovisionamiento de usuarios, por ejemplo, Terraform y Cloud Foundation Toolkit
  • Organización automatizada de flujos de trabajo para operaciones de varios pasos, por ejemplo, Cloud Composer.
  • El aprovisionamiento de capacidad adicional, por ejemplo, varios productos de Google Cloud, como Compute Engine y GKE, ofrecen un ajuste de escala automático configurable. Evalúa los servicios de Google Cloud que usas para determinar si incluyen ajuste de escala automático configurable.
  • Canalizaciones de CI/CD con implementación automatizada, por ejemplo, Cloud Build
  • Análisis de versiones canary para validar implementaciones.
  • Entrenamiento de modelos automatizado (para aprendizaje automático), por ejemplo, AutoML

Si un producto o servicio de Google Cloud solo satisface de forma parcial tus necesidades técnicas cuando automatizas o borras flujos de trabajo manuales, considera enviar una solicitud de función a través de tu representante de cuenta de Google Cloud. Es posible que tu problema sea una prioridad para otros clientes o que ya sea parte de nuestro mapa de ruta. Si es así, conocer la prioridad y el cronograma de la función te ayuda a evaluar mejor las compensaciones de compilar tu propia solución en comparación con esperar para usar una función de Google Cloud.

Crea o compra soluciones para el trabajo repetitivo de alto costo

El tercer paso, que se puede completar en paralelo con el primer y segundo paso, implica evaluar la compilación o la compra de otras soluciones si el costo del trabajo repetitivo es alto, por ejemplo, si el trabajo repetitivo lleva mucho tiempo para cualquier equipo que administre tus sistemas de producción.

Cuando compiles o compres soluciones, ten en cuenta los costos de integración, seguridad, privacidad y cumplimiento. Diseñar y, además, implementar tu propia automatización conlleva costos de mantenimiento y riesgos de confiabilidad más allá de los costos iniciales de desarrollo y configuración, por lo que debes considerar esta opción como último recurso.

¿Qué sigue?

Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la seguridad, la privacidad y el cumplimiento, la confiabilidad, la optimización de costos y la optimización del rendimiento.

Framework de la arquitectura de Google Cloud: Seguridad, privacidad y cumplimiento

En esta sección del framework de arquitectura de Google Cloud, se muestra cómo diseñar y operar servicios seguros en Google Cloud. También puedes obtener información sobre los productos y las funciones de Google Cloud que admiten la seguridad y el cumplimiento.

El framework de arquitectura describe las prácticas recomendadas, proporciona recomendaciones de implementación y explica algunos de los productos y servicios disponibles. El framework te ayuda a diseñar tu implementación de Google Cloud para que se adapte a las necesidades de tu empresa.

Para trasladar tus cargas de trabajo a Google Cloud, debes evaluar los requisitos empresariales, los riesgos, las obligaciones de cumplimiento y los controles de seguridad. En este documento, se proporciona información sobre las prácticas recomendadas clave relacionadas con el diseño de una solución segura en Google Cloud.

Los principios básicos de Google incluyen la defensa en profundidad, a gran escala y de forma predeterminada. En Google Cloud, los datos y los sistemas están protegidos a través de varias defensas en capas mediante políticas y controles configurados en IAM, la encriptación, las Herramientas de redes, la detección, el registro y la supervisión.

Google Cloud incluye diversos controles de seguridad como los siguientes:

  • Opciones seguras para los datos en tránsito y encriptación predeterminada para los datos en reposo.
  • Funciones de seguridad integradas para los productos y servicios de Google Cloud.
  • Una infraestructura global diseñada para la redundancia geográfica, con controles de seguridad durante todo el ciclo de vida del procesamiento de la información
  • Capacidades de automatización que usan infraestructura como código (IaC) y barreras de seguridad de configuración

Para obtener más información sobre la posición de seguridad de Google Cloud, consulta el informe de seguridad de Google y la descripción general del diseño de seguridad de la infraestructura de Google. Para obtener un ejemplo de entorno seguro de forma predeterminada, consulta el plano de bases empresariales de Google Cloud.

En la sección de seguridad del framework de arquitectura, aprenderás a hacer lo siguiente:

Responsabilidades compartidas y destino compartido en Google Cloud

En este documento, se describen las diferencias entre el modelo de responsabilidad compartida y el destino compartido en Google Cloud. Se analizan los desafíos y matices del modelo de responsabilidad compartida. En este documento, se describe qué es el destino compartido y cómo nos asociamos con los clientes para abordar las comprobaciones de seguridad en la nube.

Comprender el modelo de responsabilidad compartida es importante para determinar cómo proteger mejor tus datos y cargas de trabajo en Google Cloud. En el modelo de responsabilidad compartida, se describen las tareas que tienes cuando se trata de seguridad en la nube y cómo estas tareas son diferentes para los proveedores de servicios en la nube.

Sin embargo, comprender la responsabilidad compartida puede ser un desafío. El modelo requiere una mejor comprensión de cada servicio que usas, las opciones de configuración que proporciona cada servicio y lo que Google Cloud hace para proteger el servicio. Cada servicio tiene un perfil de configuración diferente y puede ser difícil determinar la mejor configuración de seguridad. Google considera que el modelo de responsabilidad compartida deja de ayudar a los clientes de Cloud a lograr mejores resultados de seguridad. En lugar de la responsabilidad compartida, creemos en el destino compartido.

El destino compartido incluye la creación y la operación de una plataforma de nube confiable para tus cargas de trabajo. Proporcionamos asesoramiento de prácticas recomendadas, código de infraestructura certificado y seguro que puedes usar para implementar tus cargas de trabajo de manera segura. Lanzamos soluciones que combinan varios servicios de Google Cloud a fin de resolver problemas de seguridad complejos y ofrecemos opciones de seguros innovadoras que te ayudarán a medir y mitigar los riesgos que debes aceptar. El destino compartido nos hace interactuar de forma más estrecha contigo a medida que proteges tus recursos en Google Cloud.

Responsabilidad compartida

Eres el experto en conocer los requisitos normativos y de seguridad de tu empresa, y conocer los requisitos de protección de tus datos y recursos confidenciales. Cuando ejecutas las cargas de trabajo en Google Cloud, debes identificar los controles de seguridad que necesitas configurar en Google Cloud para proteger tus datos confidenciales y cada carga de trabajo. Para decidir qué controles de seguridad implementar, debes tener en cuenta los siguientes factores:

  • Tus obligaciones de cumplimiento de la reglamentación
  • Los estándares de seguridad y el plan de administración de riesgos de tu organización
  • Los requisitos de seguridad de tus clientes y proveedores

Definido por las cargas de trabajo

Por lo general, las responsabilidades se definen según el tipo de carga de trabajo que ejecutas y los servicios en la nube que necesitas. Los servicios en la nube incluyen las siguientes categorías:

Servicio de Cloud Descripción
Infraestructura como servicio (IaaS) Los servicios de IaaS incluyen los siguientes:Compute Engine, Cloud Storage y servicios de Herramientas de redes, comoCloud VPN, Cloud Load Balancing y Cloud DNS.

IaaS ofrece servicios de procesamiento, almacenamiento y redes a pedido de pago por uso. Puedes usar IaaS si planeas migrar una carga de trabajo local existente a la nube mediante lift-and-shift, o si deseas ejecutar la aplicación en VMs específicas, mediante bases de datos específicas o las configuraciones de red.

En IaaS, la mayor parte de las responsabilidades de seguridad son tuyas, y nuestras responsabilidades se enfocan en la infraestructura subyacente y la seguridad física.

Plataforma como servicio (PaaS) Los servicios de PaaS incluyen App Engine, Google Kubernetes Engine (GKE) y BigQuery.

PaaS proporciona el entorno de ejecución en el que puedes desarrollar y ejecutar tus aplicaciones. Puedes usar PaaS si compilas una aplicación (como un sitio web) y deseas enfocarte en el desarrollo y no en la infraestructura subyacente.

En PaaS, nos encargamos de más controles que en IaaS, incluidos los controles de red. Compartes la responsabilidad con nosotros para la administración de IAM y los controles a nivel de la aplicación. Eres responsable de la seguridad de tus datos y la protección del cliente.

Software como servicio (SaaS) Las aplicaciones de SaaS incluyen aplicaciones de Google Workspace, Chronicle y de SaaS de terceros disponibles en Google Cloud Marketplace.

SaaS proporciona aplicaciones en línea a las que puedes suscribirte o de alguna manera pagar. Puedes usar aplicaciones de SaaS cuando tu empresa no tiene la experiencia interna o el requisito empresarial de compilar la aplicación, pero requiere la capacidad de procesar cargas de trabajo.

En SaaS, somos propietarios de la mayor parte de las responsabilidades de seguridad. Eres responsable de los controles de acceso y de los datos que eliges almacenar en la aplicación.

Función como servicio (FaaS) o sin servidores

FaaS es la plataforma que permite a los desarrolladores ejecutar código pequeño de un solo propósito (llamado funciones) que se ejecuta en respuesta a eventos específicos. Debes usar FaaS cuando deseas que ocurran acciones concretas en función de un evento determinado. Por ejemplo, puedes crear una función que se ejecute cada vez que los datos se suban a Cloud Storage para que se puedan clasificar.

FaaS tiene una lista de responsabilidades similares a las de SaaS. Cloud Functions es una aplicación de FaaS.

En el siguiente diagrama, se muestran los servicios en la nube y se define cómo se comparten las responsabilidades entre el proveedor de servicios en la nube y el cliente.

Responsabilidades de seguridad compartida

Como se muestra en el diagrama, el proveedor de servicios en la nube siempre es responsable de la infraestructura y la red subyacentes, y los clientes siempre siguen siendo responsables de sus datos y políticas de acceso.

Definido por el sector y el marco regulatorio

Varias industrias tienen frameworks regulatorios que definen los controles de seguridad que se deben implementar. Cuando muevas tus cargas de trabajo a la nube, debes comprender lo siguiente:

  • Qué controles de seguridad son tu responsabilidad
  • Qué controles de seguridad están disponibles como parte de la oferta en la nube
  • Qué controles de seguridad predeterminados se heredan

Los controles de seguridad heredados (como nuestros controles de infraestructura predeterminados y de infraestructura) son controles que puedes proporcionar como parte de la evidencia de tu posición de seguridad a los auditores y los reguladores. Por ejemplo, las Normas de seguridad de los datos de la industria de tarjetas de pago (PCI DSS) definen las reglamentaciones para los procesadores de pagos. Cuando trasladas tu negocio a la nube, estas reglamentaciones se comparten entre tú y el CSP. Para comprender cómo se comparten las responsabilidades de PCI DSS entre tú y Google Cloud, consulta Matriz de responsabilidad compartida de PCI DSS.

Como otro ejemplo, en los Estados Unidos, la Ley de Responsabilidad y Portabilidad de Seguros Médicos (HIPAA) estableció estándares para manejar la información de salud personal (PHI) electrónica. Estas responsabilidades también se comparten entre el CSP y tú. Para obtener más información sobre cómo Google Cloud cumple con nuestras responsabilidades en virtud de la HIPAA, consulta HIPAA: cumplimiento.

Otras industrias (por ejemplo, finanzas o fabricación) también tienen reglamentaciones que definen cómo se pueden recopilar, procesar y almacenar los datos. Para obtener más información sobre la responsabilidad compartida relacionada con estos y cómo Google Cloud cumple con nuestras responsabilidades, consulta Centro de recursos de cumplimiento.

Definido por ubicación

Según la situación de tu empresa, es posible que debas considerar tus responsabilidades según la ubicación de las oficinas comerciales, los clientes y los datos. Los diferentes países y regiones crearon reglamentaciones que informan cómo puedes procesar y almacenar los datos de tus clientes. Por ejemplo, si tu empresa tiene clientes que residen en la Unión Europea, es posible que tu empresa deba cumplir con los requisitos que se describen en el Reglamento General de Protección de Datos (RGPD) y es posible que debas mantener los datos de tus clientes en la UE. En este caso, eres responsable de garantizar que los datos que recopiles permanezcan en las regiones de Google Cloud en la UE. Para obtener más información sobre cómo cumplimos nuestras obligaciones del RGPD, consulta RGPD y Google Cloud.

Para obtener información sobre los requisitos relacionados con tu región, consulta Ofertas de cumplimiento. Si tu situación es particularmente complicada, te recomendamos que hables con nuestro equipo de ventas o uno de nuestros socios para ayudarte a evaluar tus responsabilidades de seguridad.

Desafíos para la responsabilidad compartida

Aunque la responsabilidad compartida ayuda a definir los roles de seguridad que tú o el proveedor de servicios en la nube tienen, confiar en la responsabilidad compartida aún puede crear desafíos. Considere estas situaciones:

  • La mayoría de las violaciones de la seguridad de la nube son el resultado directo de una configuración incorrecta (que se muestra como número 3 en el informe Pandemic 11 de Cloud Security Alliance), y se espera que esta tendencia aumente. Los productos de Cloud cambian de forma constante, y se lanzan nuevos con regularidad. Mantenerse al día con cambios constantes puede parecer abrumador. Los clientes necesitan proveedores de servicios en la nube para proporcionarles prácticas recomendadas para mantenerse al día con el cambio, comenzando con las prácticas recomendadas de forma predeterminada y con una configuración segura de referencia.
  • Aunque dividir los elementos por servicios en la nube es útil, muchas empresas tienen cargas de trabajo que requieren varios tipos de servicios en la nube. En esta circunstancia, debes considerar cómo interactúan varios controles de seguridad para estos servicios, incluso si se superponen entre los servicios. Por ejemplo, es posible que tengas una aplicación local que migres a Compute Engine, uses Google Workspace para el correo electrónico corporativo y también ejecutes BigQuery a fin de analizar datos a fin de mejorar tus productos.
  • Tu negocio y tus mercados cambian constantemente; a medida que cambian las normativas, a medida que ingresas a nuevos mercados o cuando adquieres otras empresas. Es posible que tus mercados nuevos tengan requisitos diferentes y que la adquisición nueva aloje sus cargas de trabajo en otra nube. Si deseas administrar los cambios frecuentes, debes volver a evaluar de forma constante el perfil de riesgo y poder implementar controles nuevos con rapidez.
  • Cómo y dónde administrar tus claves de encriptación de datos es una decisión importante que se relaciona con tus responsabilidades para proteger tus datos. La opción que elijas depende de tus requisitos normativos, ya sea que ejecutes un entorno de nube híbrida o aún tengas un entorno local, y la sensibilidad de los datos que procesas y el almacenamiento.
  • La administración de incidentes es un área importante que, a menudo, no se tiene en cuenta, y donde tus responsabilidades y las del proveedor de servicios en la nube no se definen con facilidad. Muchos incidentes requieren colaboración estrecha y asistencia del proveedor de servicios en la nube para ayudar a investigarlos y mitigarlos. Otros incidentes pueden ser el resultado de recursos en la nube mal configurados o de credenciales robadas, y puede ser muy difícil garantizar que cumplas con las prácticas recomendadas para proteger los recursos y las cuentas.
  • Las amenazas persistentes avanzadas (APT) y las vulnerabilidades nuevas pueden afectar tus cargas de trabajo de formas que podrías no tener en cuenta cuando inicias la transformación en la nube. Es difícil garantizar que estés al tanto del panorama cambiante y quién es responsable de la mitigación de amenazas, en especial si tu empresa no tiene un equipo de seguridad grande.

Destino compartido

Desarrollamos el destino compartido en Google Cloud para comenzar a abordar los desafíos que el modelo de responsabilidad compartida no aborda. El destino compartido se centra en cómo todas las partes pueden interactuar mejor para mejorar la seguridad de forma continua. El destino compartido se basa en el modelo de responsabilidad compartida porque considera la relación entre el proveedor de servicios en la nube y el cliente como una asociación continua para mejorar la seguridad.

El destino compartido consiste en que asumamos la responsabilidad de hacer que Google Cloud sea más seguro. El destino compartido incluye ayudarte a comenzar a usar una zona de destino segura y ser claro y transparente sobre los controles de seguridad, la configuración y las prácticas recomendadas asociadas. Te ayuda a cuantificar y administrar mejor los riesgos con el seguro cibernético mediante nuestro Programa de protección contra riesgos. Con el destino compartido, queremos evolucionar del framework de responsabilidad compartida estándar a un mejor modelo que te ayude a proteger tu empresa y generar confianza en Google Cloud.

En las siguientes secciones, se describen varios componentes del destino compartido.

Obtén ayuda para comenzar

Un componente clave del destino compartido son los recursos que proporcionamos para ayudarte a comenzar, en una configuración segura en Google Cloud. Comenzar con una configuración segura reduce el problema de los parámetros de configuración incorrectos, que es la causa raíz de la mayoría de las violaciones de seguridad.

Nuestros recursos incluyen lo siguiente:

  • Plano de bases empresariales que analiza las principales inquietudes de seguridad y nuestras recomendaciones principales.
  • Planos seguros que te permiten implementar y mantener soluciones seguras mediante la infraestructura como código (IaC). Los planos tienen nuestras recomendaciones de seguridad habilitadas de forma predeterminada. Los equipos de seguridad de Google crean muchos planos y estos se administran como productos. Esta asistencia significa que se actualizan con regularidad, se someten a un proceso de prueba riguroso y reciben certificaciones de grupos de prueba externos. Los planos incluyen el plano de las bases empresariales, el plano del almacén de datos seguro y el plano de notebooks de Vertex AI Workbench.

  • Prácticas recomendadas del framework de arquitectura que abordan las recomendaciones principales para incorporar la seguridad en tus diseños. El framework de arquitectura incluye una sección de seguridad y una zona de la comunidad que puedes usar para conectarte con expertos y pares.

  • Guías de navegación de la zona de destino que te guiarán a través de las decisiones principales que necesitas tomar para crear una base segura en tus cargas de trabajo, incluida la jerarquía de recursos, la integración de identidades, la seguridad y la administración de claves y la estructura de red.

Programa de Protección Contra Riesgos

El destino compartido también incluye el Programa de protección contra riesgos (actualmente en vista previa), que te ayuda a usar la potencia de Google Cloud como una plataforma para administrar el riesgo, en lugar de solo ver cargas de trabajo en la nube como otra fuente de riesgo que necesitas administrar. El Programa de protección contra riesgos es una colaboración entre Google Cloud y dos empresas líderes de seguros cibernéticos, Munich Re y Allianz Global & Corporate Speciality.

El Programa de protección contra riesgos incluye el administrador de riesgos, que proporciona estadísticas basadas en datos que puedes usar para comprender mejor tu posición de seguridad en la nube. Si buscas cobertura de seguros cibernéticos, puedes compartir estas estadísticas del administrador de riesgos directamente con nuestros socios de seguros para obtener una cotización. Si deseas obtener más información, consulta Programa de protección contra riesgos de Google Cloud ahora en versión preliminar.

Ayuda con la implementación y la administración

El destino compartido también te ayuda con la administración continua de tu entorno. Por ejemplo, nos enfocamos en productos como los siguientes:

Aplicación de la responsabilidad compartida y el destino compartido

Como parte de tu proceso de planificación, considera las siguientes acciones para ayudarte a comprender e implementar los controles de seguridad adecuados:

  • Crea una lista de los tipos de cargas de trabajo que alojarás en Google Cloud y si requieren servicios IaaS, PaaS y SaaS. Puedes usar el diagrama de responsabilidad compartida como una lista de tareas para asegurarte de conocer los controles de seguridad que debes tener en cuenta.
  • Crea una lista de requisitos normativos que debes cumplir y accede a recursos en el Centro de recursos de cumplimiento relacionados con esos requisitos.
  • Revisa la lista de planos y arquitecturas disponibles en el Centro de arquitectura a fin de ver los controles de seguridad que necesitas para las cargas de trabajo determinadas. Los planos proporcionan una lista de los controles recomendados y el código de IaC que necesitas para implementar esa arquitectura.
  • Usa la documentación de la zona de destino y las recomendaciones de la guía de bases empresariales para diseñar una jerarquía de recursos y una arquitectura de red que cumpla con tus requisitos. Puedes usar los planos de carga de trabajo bien definidos, como el de almacén de datos seguro, para acelerar el proceso de desarrollo.
  • Después de implementar tus cargas de trabajo, verifica que cumplas con tus responsabilidades de seguridad mediante servicios como Risk Manager, Assured Workloads, las herramientas de Policy Intelligence y Security Command Center Premium.

Para obtener más información, consulta el informe "CISO's Guide to Cloud Transformation" (Guía de CISO para la transformación a la nube).

¿Qué sigue?

Principios de seguridad

En este documento del framework de arquitectura de Google Cloud, se explican los principios básicos para ejecutar servicios seguros y compatibles en Google Cloud. Muchos de los principios de seguridad con los que estás familiarizado en tu entorno local se aplican a los entornos de nube.

Compila un enfoque de seguridad en capas

Implementa seguridad en cada nivel de la aplicación y la infraestructura mediante un enfoque de defensa en profundidad. Usa las funciones de cada producto para limitar el acceso y configurar la encriptación cuando corresponda.

Diseño para sistemas separados y seguros

Simplifica el diseño del sistema para adaptarse a la flexibilidad cuando sea posible y documenta los requisitos de seguridad de cada componente. Incorpora un mecanismo seguro y sólido para dar cuenta de la resiliencia y la recuperación.

Automatiza la implementación de tareas sensibles.

Automatiza la implementación y otras tareas de administrador para quitar a las personas del flujo de trabajo.

Automatiza la supervisión de seguridad

Usa herramientas automatizadas para supervisar la aplicación y la infraestructura. Usa el análisis automatizado en las canalizaciones de integración continua y de implementación continua (CI/CD) para analizar tu infraestructura en busca de vulnerabilidades y detectar incidentes de seguridad.

Cumple con los requisitos de cumplimiento de tus regiones

Ten en cuenta que es posible que debas ofuscar, o bien ocultar información de identificación personal (PII) para cumplir con los requisitos reglamentarios. Siempre que sea posible, automatiza tus esfuerzos de cumplimiento. Por ejemplo, usa la Protección de datos sensibles y Dataflow para automatizar el trabajo de ocultamiento de PII antes de que se almacenen datos nuevos en el sistema.

Cumpla con los requisitos de soberanía y residencia de datos

Es posible que tengas requisitos internos (o externos) que requieran que controles las ubicaciones de almacenamiento y procesamiento de datos. Estos requisitos varían según los objetivos de diseño de los sistemas, las preocupaciones normativas de la industria, las leyes nacionales, las implicaciones fiscales y la cultura. La residencia de datos describe dónde se almacenan tus datos. Para cumplir con los requisitos de residencia de datos, Google Cloud te permite controlar dónde se almacenan los datos, cómo se accede a ellos y cómo se procesan.

Aumenta las medidas de seguridad

La automatización de implementaciones y DevOps permite que tu organización aumente la velocidad de entrega de productos. Para ayudar a garantizar que tus productos permanezcan seguros, incorpora procesos de seguridad desde el inicio del proceso de desarrollo. Por ejemplo, puedes hacer lo siguiente:

  • Realiza pruebas para buscar problemas de seguridad en el código al principio de la canalización de implementación.
  • Analiza las imágenes de contenedor y la infraestructura de nube de forma continua.
  • Automatiza la detección de configuración incorrecta y antipatrones de seguridad. Por ejemplo, usa la automatización para buscar secretos codificados en las aplicaciones o en la configuración.

¿Qué sigue?

Obtén más información sobre los principios de seguridad principales con los siguientes recursos:

Administra los riesgos mediante los controles

En este documento del framework de arquitectura de Google Cloud, se describen las prácticas recomendadas para administrar los riesgos en una implementación en la nube. Realizar un análisis detallado de los riesgos que se aplican a tu organización te permite determinar los controles de seguridad que necesitas. Debes completar un análisis de riesgos antes de implementar las cargas de trabajo en Google Cloud y, luego, de manera periódica cuando las necesidades de tu empresa, los requisitos normativos y las amenazas relevantes para tu organización cambien.

Identifica los riesgos para tu organización

Antes de crear e implementar recursos en Google Cloud, completa una evaluación de riesgo para determinar qué funciones de seguridad necesitas a fin de cumplir con los requisitos de seguridad internos y los requisitos regulatorios externos. La evaluación de riesgos te proporciona un catálogo de riesgos que son relevantes para ti y te indica la capacidad de tu organización de detectar y contrarrestar las amenazas de seguridad.

Los riesgos en un entorno de nube difieren de los riesgos en un entorno local debido al acuerdo de responsabilidad compartida que estableces con tu proveedor de servicios en la nube. Por ejemplo, en un entorno local, debes mitigar las vulnerabilidades de la pila de hardware. En cambio, en un entorno de nube, el proveedor de servicios en la nube genera estos riesgos.

Además, los riesgos varían según la forma en que planeas usar Google Cloud. ¿Transfieres algunas de tus cargas de trabajo a Google Cloud o todas? ¿Usas Google Cloud solo para fines de recuperación ante desastres? ¿Estás configurando un entorno de nube híbrida?

Te recomendamos que uses un marco de trabajo de evaluación de riesgos estándar de la industria que se aplique a los entornos de nube y a tus requisitos normativos. Por ejemplo, Cloud Security Alliance (CSA) proporciona Cloud Controls Matrix (CCM). Además, existen modelos de amenazas, como el modelo de amenaza de aplicaciones de OWASP, que te proporcionan una lista de posibles brechas y que sugieren acciones para solucionar aquellas que se detecten. Puedes consultar nuestro directorio de socios para obtener una lista de expertos a fin de realizar evaluaciones de riesgos para Google Cloud.

Para catalogar los riesgos, considera usar el Administrador de riesgos, que forma parte del Programa de protección contra riesgos. (Actualmente, este programa se encuentra en vista previa). El administrador de riesgos analiza tus cargas de trabajo para ayudarte a comprender los riesgos de tu empresa. Sus informes detallados te proporcionan un modelo de referencia de seguridad. Además, puedes usar los informes de administrador de riesgos para comparar tus riesgos con los que se describen en la comparativa de Center for Internet Security (CIS).

Después de catalogar los riesgos, debes determinar cómo abordarlos, es decir, si deseas aceptarlos, evitarlos, transferirlos o mitigarlos. En la siguiente sección, se describen los controles de mitigación.

Reduce los riesgos

Puedes mitigar riesgos mediante controles técnicos, protecciones contractuales y verificaciones o certificaciones de terceros. En la siguiente tabla, se indica cómo puedes usar estas mitigaciones cuando adoptas nuevos servicios de nube pública.

MitigaciónDescripción
Controles técnicos Los controles técnicos hacen referencia a las funciones y tecnologías que usas para proteger tu entorno. Estos incluyen controles de seguridad integrados en la nube, como firewalls y registros. Los controles técnicos también pueden incluir el uso de herramientas de terceros para reforzar o respaldar tu estrategia de seguridad.

Existen dos categorías de controles técnicos:
  • Google Cloud incluye varios controles de seguridad para que puedas mitigar los riesgos que se aplican a tu caso. Por ejemplo, si tienes un entorno local, puedes usar Cloud VPN y Cloud Interconnect para proteger la conexión entre el entorno local y tus recursos de nube.
  • Google tiene controles internos sólidos y realiza auditorías para proteger los datos de clientes del acceso de usuarios con información privilegiada. Nuestros registros de auditoría proporcionan a nuestros clientes registros casi en tiempo real del acceso de los administradores de Google en Google Cloud.
Protecciones contractuales Las protecciones contractuales hacen referencia a los compromisos legales realizados por nosotros en relación con los servicios de Google Cloud.

Google se compromete a mantener y expandir la cartera de cumplimiento. En el documento Anexo de Procesamiento de Datos de Cloud (CDPA), se define nuestro compromiso de mantener las certificaciones ISO 27001, 27017 y 27018, y actualizar nuestros informes SOC 2 y SOC 3 cada 12 meses.

En el documento de DPST, también se describen los controles de acceso que se aplican para limitar el acceso de los ingenieros de asistencia de Google a los entornos de los clientes y se describe nuestro riguroso proceso de registro y aprobación.

Te recomendamos que revises los controles contractuales de Google Cloud con tus expertos legales y normativos y verifiques que cumplan con tus requisitos. Si necesitas más información, comunícate con tu representante técnico de cuenta.
Verificaciones o certificaciones de terceros Las verificaciones o certificaciones de terceros hacen referencia a que un proveedor externo audite al proveedor de servicios en la nube para asegurarse de que cumpla con los requisitos de cumplimiento. Por ejemplo, un tercero auditó a Google para verificar el cumplimiento de la norma ISO 27017.

Puedes ver las certificaciones y las cartas de certificación actuales de Google Cloud en el Centro de recursos de cumplimiento.

¿Qué sigue?

Obtén más información sobre la administración de riesgos con los siguientes recursos:

Administre sus recursos

En este documento del Framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para administrar elementos.

La administración de recursos es una parte importante de tu análisis de requisitos empresariales. Debes saber qué recursos tienes y conocerlos bien, su valor y cualquier ruta o proceso fundamental relacionado con ellos. Debes tener un inventario de recursos preciso antes de que puedas diseñar cualquier tipo de controles de seguridad para protegerlos.

A fin de administrar los incidentes de seguridad y cumplir con los requisitos reglamentarios de tu organización, necesitas un inventario de recursos preciso y actualizado que incluya una forma de analizar los datos históricos. Debes poder realizar un seguimiento de los recursos, incluida la forma en que su exposición a riesgos puede cambiar con el tiempo.

Migrar a Google Cloud significa que debes modificar los procesos de administración de elementos para adaptarlos a un entorno de nube. Por ejemplo, uno de los beneficios de migrar a la nube es que aumentas la capacidad de la organización para escalar con rapidez. Sin embargo, la capacidad de escalar con rapidez puede causar problemas de shadow IT, en los que tus empleados crean recursos de nube que no están administrados y protegidos de forma adecuada. Por lo tanto, los procesos de administración de recursos deben proporcionar suficiente flexibilidad para que los empleados hagan su trabajo y, al mismo tiempo, proporcionar controles de seguridad adecuados.

Usa herramientas de administración de recursos en la nube

Las herramientas de administración de recursos de Google Cloud se adaptaron específicamente a nuestro entorno y a los casos de uso principales de los clientes.

Una de estas herramientas es Cloud Asset Inventory, que proporciona información en tiempo real sobre el estado actual de los recursos y un historial de cinco semanas. Si usas este servicio, puedes obtener una instantánea de tu inventario en toda la organización para una amplia variedad de recursos y políticas de Google Cloud. Las herramientas de automatización pueden usar la instantánea a fin de supervisar o aplicar las políticas, o las herramientas pueden archivar la instantánea para la auditoría de cumplimiento. Si quieres analizar los cambios en los elementos, el inventario de recursos también te permite exportar el historial de metadatos.

Consulta Solución personalizada para responder a los cambios en los recursos y Controles de detección para obtener más información sobre Cloud Asset Inventory.

Automatiza la administración de recursos

La automatización te permite crear y administrar recursos con rapidez según los requisitos de seguridad que especifiques. Puedes automatizar aspectos del ciclo de vida de los recursos de las siguientes maneras:

  • Implementa la infraestructura de nube mediante herramientas de automatización, como Terraform. Google Cloud proporciona el plano de bases empresariales, que te ayuda a configurar los recursos de la infraestructura que cumplen con las prácticas recomendadas de seguridad. Además, configura cambios de recursos y notificaciones de cumplimiento de políticas en Cloud Asset Inventory.
  • Implementa tus aplicaciones mediante herramientas de automatización como Cloud Run y Artifact Registry.

Supervisa las desviaciones de las políticas de cumplimiento

Se pueden producir desviaciones de las políticas durante todas las fases del ciclo de vida del recurso. Por ejemplo, los recursos se pueden crear sin los controles de seguridad adecuados o se pueden escalar sus privilegios. Del mismo modo, los recursos se pueden abandonar sin que se sigan los procedimientos adecuados de final del ciclo de vida.

Para evitar estas situaciones, te recomendamos que supervises los recursos a fin de detectar desviaciones del cumplimiento. El conjunto de recursos que supervisas depende de los resultados de la evaluación de riesgos y los requisitos empresariales. Para obtener más información sobre la supervisión de recursos, consulta Supervisar cambios en los recursos.

Intégrate con tus sistemas existentes de supervisión de administración de recursos

Si ya usas un sistema SIEM o algún otro sistema de supervisión, integra tus recursos de Google Cloud a ese sistema. La integración garantiza que tu organización tenga una única vista integral de todos los recursos, sin importar el entorno. Para obtener más información, consulta Exporta datos de seguridad de Google Cloud a tu sistema SIEM y Casos de exportación de datos de Cloud Logging: Splunk.

Usa los análisis de datos para enriquecer la supervisión

Puedes exportar tu inventario a una tabla de BigQuery o a un bucket de Cloud Storage para realizar un análisis adicional.

¿Qué sigue?

Obtén más información para administrar tus elementos con los siguientes recursos:

Administrar la identidad y el acceso

En este documento del Framework de la arquitectura de Google Cloud, se proporcionan prácticas recomendadas para administrar identidades y accesos.

La práctica de la administración de identidades y accesos (generalmente denominada IAM) te ayuda a garantizar que las personas correctas puedan acceder a los recursos adecuados. IAM aborda los siguientes aspectos de autenticación y autorización:

  • Administración de cuentas, incluido el aprovisionamiento
  • Administración de identidades
  • Authentication
  • Control de acceso (autorización)
  • Federación de identidades

Administrar IAM puede ser un desafío cuando tienes diferentes entornos o usas varios proveedores de identidad. Sin embargo, es fundamental que configures un sistema que pueda satisfacer los requisitos de tu negocio a la vez que mitiga los riesgos.

Las recomendaciones de este documento te ayudan a revisar tus políticas y procedimientos de IAM actuales y a determinar cuáles podrías modificar para tus cargas de trabajo en Google Cloud. Por ejemplo, debes revisar lo siguiente:

  • Si puedes usar grupos existentes para administrar accesos o si necesitas crear otros nuevos.
  • Tus requisitos de autenticación (como la autenticación de varios factores (MFA) con un token).
  • El impacto de las cuentas de servicio en las políticas actuales
  • Si usas Google Cloud para la recuperación ante desastres, manteniendo la separación de obligaciones adecuada.

En Google Cloud, usas Cloud Identity para autenticar a tus usuarios y recursos, y el producto Identity and Access Management (IAM) de Google para determinar el acceso a los recursos. Los administradores pueden restringir el acceso a nivel de organización, carpeta, proyecto y recurso. Las políticas de Google IAM determinan quién puede hacer qué en qué recursos. Las políticas de IAM configuradas de forma correcta ayudan a proteger tu entorno, ya que evitan el acceso no autorizado a los recursos.

Si quieres obtener más información, consulta la Descripción general de la administración de identidades y accesos.

Usa un solo proveedor de identidad

Muchos de nuestros clientes tienen cuentas de usuario administradas y aprovisionadas por proveedores de identidad fuera de Google Cloud. Google Cloud admite la federación con la mayoría de los proveedores de identidad y con directorios locales, como Active Directory.

La mayoría de los proveedores de identidad te permite habilitar el inicio de sesión único (SSO) para tus usuarios y grupos. Para las aplicaciones que implementas en Google Cloud y que usan tu proveedor de identidad externo, puedes extender tu proveedor de identidad a Google Cloud. Si deseas obtener más información, consulta Arquitecturas de referencia y Patrones para autenticar usuarios corporativos en un entorno híbrido.

Si no tienes un proveedor de identidad existente, puedes usar Cloud Identity Premium o Google Workspace para administrar identidades para los empleados.

Protege la cuenta de administrador avanzado

La cuenta de administrador avanzado (administrada por Google Workspace o Cloud Identity) te permite crear tu organización de Google Cloud. Por lo tanto, esta cuenta de administrador tiene muchos privilegios. Estas son algunas de las prácticas recomendadas para esta cuenta:

  • Crear una cuenta nueva para este fin, no uses una cuenta de usuario existente.
  • Crear y proteger cuentas de copia de seguridad.
  • Habilitar la MFA.

Para obtener más información, consulta las Prácticas recomendadas para cuentas de administrador avanzado.

Planifica el uso de las cuentas de servicio

Una cuenta de servicio es una Cuenta de Google que las aplicaciones pueden usar para llamar a la API de Google de un servicio.

A diferencia de las cuentas de usuario, las cuentas de servicio se crean y administran en Google Cloud. Las cuentas de servicio también se autentican de manera diferente que las cuentas de usuario:

  • Para permitir que una aplicación que se ejecuta en Google Cloud se autentique con una cuenta de servicio, puedes conectar una cuenta de servicio al recurso de procesamiento en el que se ejecuta la aplicación.
  • Para permitir que una aplicación que se ejecuta en GKE se autentique con una cuenta de servicio, puedes usar Workload Identity.
  • Para permitir que las aplicaciones que se ejecutan fuera de Google Cloud se autentiquen con una cuenta de servicio, puedes usar la Federación de Workload Identity.

Cuando usas cuentas de servicio, debes considerar una división de tareas adecuada durante el proceso de diseño. Ten en cuenta las llamadas a la API que debes realizar y determina las cuentas de servicio y los roles asociados que requieren estas llamadas. Por ejemplo, si configuras un almacén de datos de BigQuery, es probable que necesites identidades para al menos los siguientes procesos y servicios:

  • Cloud Storage o Pub/Sub, según si proporcionas un archivo por lotes o creas un servicio de transmisión.
  • Dataflow y Sensitive Data Protection para desidentificar datos sensibles.

Si deseas obtener más información, consulta Prácticas recomendadas para trabajar con cuentas de servicio.

Actualiza los procesos de identidad para la nube

La administración de identidades te permite hacer un seguimiento del acceso, los riesgos y los incumplimientos de políticas para que puedas cumplir con tus requisitos normativos. Esta administración requiere que tengas procesos y políticas implementados para que puedas otorgar roles y permisos de control de acceso a los usuarios y auditarlos. Los procesos y las políticas deben reflejar los requisitos de tus entornos, por ejemplo, pruebas, desarrollo y producción.

Antes de implementar cargas de trabajo en Google Cloud, revisa tus procesos de identidad actuales y actualízalos si corresponde. Asegúrate de planificar de forma adecuada los tipos de cuentas que tu organización necesita y comprender los roles y accesos necesarios.

Para ayudarte a auditar las actividades de Google IAM, Google Cloud crea registros de auditoría que incluyen lo siguiente:

  • Actividad del administrador. No se puede inhabilitar este registro.
  • Actividad de acceso a los datos. Debes habilitar este registro.

Si es necesario para fines de cumplimiento o si deseas configurar el análisis de registros (por ejemplo, con tu sistema SIEM), puedes exportar los registros. Debido a que los registros pueden aumentar tus requisitos de almacenamiento, pueden afectar tus costos. Asegúrate de registrar solo las acciones que necesitas y establece los programas de retención adecuados.

Configura el SSO y la MFA

Tu proveedor de identidad administra la autenticación de la cuenta de usuario. Las identidades federadas pueden autenticarse en Google Cloud mediante el SSO. Para las cuentas con privilegios, como los administradores avanzados, debes configurar la MFA. Las llaves de seguridad Titan son tokens físicos que puedes usar para la autenticación de dos factores (2FA) a fin de evitar ataques de suplantación de identidad (phishing).

Cloud Identity admite la MFA mediante varios métodos. Si deseas obtener más información, consulta Aplica MFA uniforme a recursos de empresas.

Google Cloud admite la autenticación para identidades de carga de trabajo mediante el protocolo OAuth 2.0 o tokens web JSON (JWT) firmados. Para obtener más información sobre la autenticación de la carga de trabajo, consulta Descripción general de la autenticación.

Implementa los privilegios mínimos y la separación de obligaciones

Debes asegurarte de que las personas correctas obtengan acceso solo a los recursos y servicios que necesitan para ejecutar sus trabajos. Es decir, debes seguir el principio de privilegio mínimo. Además, debes asegurarte de que haya una separación de obligaciones adecuada.

El aprovisionamiento excesivo de acceso a los usuarios puede aumentar el riesgo de amenazas de usuarios con información privilegiada, recursos mal configurados e incumplimiento de las auditorías. El aprovisionamiento de permisos insuficientes pueden impedir que los usuarios accedan a los recursos que necesitan para completar sus tareas.

Una forma de evitar el aprovisionamiento excesivo es implementar acceso privilegiado justo a tiempo, es decir, proporcionar acceso privilegiado solo cuando sea necesario y solo otorgarle acceso de forma temporal.

Ten en cuenta que, cuando se crea una organización de Google Cloud, a todos los usuarios de tu dominio se les otorgan los roles de creador de cuentas de facturación y creador de proyectos de forma predeterminada. Identifica a los usuarios que realizarán estas tareas y revoca estos roles para otros usuarios. Para obtener más información, consulta Crea y administra organizaciones.

Para obtener más información sobre cómo funcionan las funciones y los permisos en Google Cloud, consulta Descripción general y Información sobre las funciones en la documentación de IAM. Para obtener más información sobre la aplicación del privilegio mínimo, consulta Aplica el privilegio mínimo con recomendaciones de roles .

Audita el acceso

Para supervisar las actividades de las cuentas privilegiadas a fin de detectar desviaciones de las condiciones aprobadas, usa los Registros de auditoría de Cloud. Los Registros de auditoría de Cloud registran las acciones que los miembros de tu organización de Google Cloud realizaron en los recursos de Google Cloud. Puedes trabajar con varios tipos de registro de auditoría en los servicios de Google. Si quieres obtener más información, consulta Usa los Registros de auditoría de Cloud para ayudar a administrar el riesgo de que existan usuarios con información privilegiada (video).

Usa el recomendador de IAM para realizar un seguimiento del uso y ajustar los permisos cuando corresponda. Los roles que recomienda el recomendador de IAM pueden ayudarte a determinar qué roles otorgar a un usuario según su comportamiento anterior y otros criterios. Si deseas obtener más información, consulta Prácticas recomendadas para las recomendaciones de roles.

Para auditar y controlar el acceso a tus recursos por parte del personal de ingeniería y de Atención al cliente de Google, puedes usar Transparencia de acceso. Transparencia de acceso registra las acciones que realizan los empleados de Google. Usa la aprobación de acceso, que forma parte de Transparencia de acceso, para otorgar aprobación explícita cada vez que se accede al contenido del cliente. Para obtener más información, consulta Controla el acceso de los administradores de la nube a tus datos.

Automatiza tus controles de políticas

Establece permisos de acceso de manera programática siempre que puedas. Para obtener prácticas recomendadas, consulta Restricciones de políticas de la organización. Las secuencias de comandos de Terraform para el plano de bases empresariales se encuentran en el repositorio de bases de ejemplo.

Google Cloud incluye Policy Intelligence, que te permite revisar y actualizar automáticamente tus permisos de acceso. Policy Intelligence incluye las herramientas Recomendador, Solucionador de problemas de políticas y Analizador de políticas, que hacen lo siguiente:

  • Proporcionan recomendaciones para la asignación de roles de IAM.
  • Supervisan y ayudan a evitar políticas de IAM demasiado permisivas.
  • Ayudan a solucionar problemas relacionados con el control de acceso.

Configura restricciones en los recursos

IAM de Google se enfoca en quién y te permite autorizar quién puede actuar sobre recursos específicos en función de los permisos. El Servicio de políticas de la organización se enfoca en qué y te permite establecer restricciones en los recursos para especificar cómo se pueden configurar. Por ejemplo, puedes usar una política de la organización para hacer lo siguiente:

Además de usar políticas de la organización para estas tareas, puedes restringir el acceso a los recursos mediante uno de los siguientes métodos:

  • Usa etiquetas para administrar el acceso a tus recursos sin definir los permisos de acceso en cada recurso. En su lugar, debes agregar la etiqueta y, luego, configurar la definición de acceso para la etiqueta.
  • Usa las condiciones de IAM para el control condicional basado en atributos del acceso a los recursos.
  • Implementa una defensa en profundidad mediante los Controles del servicio de VPC para restringir aún más el acceso a los recursos.

Para obtener más información sobre la administración de recursos, consulta Administración de recursos.

¿Qué sigue?

Obtén más información sobre IAM con los siguientes recursos:

Implementa la seguridad de procesamiento y contenedores

Google Cloud incluye controles para proteger tus recursos de procesamiento y los recursos de contenedor de Google Kubernetes Engine (GKE). En este documento del framework de arquitectura de Google Cloud, se describen los controles clave y las prácticas recomendadas para usarlos.

Usa imágenes de VM endurecidas y seleccionadas

Google Cloud incluye VM protegida, que te permite endurecer las instancias de VM. La VM protegida está diseñada para evitar que se cargue código malicioso durante el ciclo de inicio. Proporciona seguridad de inicio, supervisa la integridad y usa el Módulo de plataforma segura virtual (vTPM). Usa la VM protegida para cargas de trabajo sensibles.

Además de usar VM protegida, puedes usar las soluciones de socios de Google Cloud para proteger aún más tus VM. Muchas soluciones de socios que se ofrecen en Google Cloud se integran a Security Command Center, que proporciona supervisión de estado y detección de amenazas de eventos. Puedes usar socios para obtener un análisis de amenazas avanzado o seguridad adicional en el entorno de ejecución.

Use Confidential Computing para procesar datos sensibles.

De forma predeterminada, Google Cloud encripta los datos en reposo y en tránsito en la red, pero no se encriptan mientras están en uso en la memoria. Si tu organización maneja datos confidenciales, debes mitigar las amenazas que comprometen la confidencialidad y la integridad de la aplicación o los datos en la memoria del sistema. Los datos confidenciales incluyen información de identificación personal (PII), datos financieros e información de salud.

Confidential Computing se basa en la VM protegida. Protege los datos en uso mediante el procesamiento en un entorno de ejecución confiable basado en hardware. Este tipo de entorno seguro y aislado ayuda a evitar el acceso no autorizado o la modificación de las aplicaciones y los datos mientras estos se usan. Un entorno de ejecución confiable también aumenta las garantías de seguridad para las organizaciones que administran datos sensibles y regulados.

En Google Cloud, puedes habilitar Confidential Computing mediante la ejecución de Confidential VMs o Confidential GKE Node. Activa Confidential Computing cuando se procesen cargas de trabajo confidenciales o cuando tengas datos confidenciales (por ejemplo, secretos) que se deben exponer mientras se procesan. Para obtener más información, consulta el Consorcio de Confidential Computing.

Protege VM y contenedores

El Acceso al SO permite que tus empleados se conecten a tus VM mediante permisos de Identity and Access Management (IAM) como fuente de información, en lugar de depender de las claves SSH. Por lo tanto, no es necesario que administres claves SSH en toda la organización. El Acceso al SO vincula el acceso de un administrador a su ciclo de vida de empleado, lo que significa que si los empleados se cambian a otro rol o abandonan tu organización, su acceso se revoca con su cuenta. El Acceso al SO también admite la autenticación de dos factores, que agrega una capa de seguridad adicional a los ataques de apropiación de cuentas.

En GKE, App Engine ejecuta instancias de aplicaciones dentro de contenedores de Docker. Para habilitar un perfil de riesgo definido y evitar que los empleados realicen cambios en los contenedores, asegúrate de que tus contenedores sean inmutables y sin estado. El principio de inmutabilidad significa que tus empleados no modifican el contenedor ni acceden a él de forma interactiva. Si se debe cambiar, debes compilar una imagen nueva y volver a implementarla. Habilita el acceso SSH a los contenedores subyacentes solo en situaciones de depuración específicas.

Inhabilita las direcciones IP externas, a menos que sean necesarias

Para inhabilitar la asignación de direcciones IP externas (video) en tus VM de producción y evitar el uso de balanceadores de cargas externos, puedes usar políticas de la organización. Si necesitas que tus VM lleguen a Internet o a tu centro de datos local, puedes habilitar una puerta de enlace de Cloud NAT.

Puedes implementar clústeres privados en GKE. En un clúster privado, los nodos solo tienen direcciones IP internas, lo que significa que los nodos y los Pods están aislados de la Internet de forma predeterminada. También puedes definir una política de red para administrar la comunicación de Pod a Pod en el clúster. Si deseas obtener más información, consulta Opciones de acceso privado a los servicios.

Supervisa tu instancia de procesamiento y el uso de GKE

Los Registros de auditoría de Cloud se habilitan de forma automática para Compute Engine y GKE. Los registros de auditoría te permiten capturar de forma automática todas las actividades con tu clúster y supervisar cualquier actividad sospechosa.

Puedes integrar GKE a los productos de socios para obtener seguridad en el entorno de ejecución. Puedes integrar estas soluciones en Security Command Center a fin de proporcionarte una sola interfaz para supervisar tus aplicaciones.

Mantén actualizadas las imágenes y los clústeres

Google Cloud proporciona imágenes de SO seleccionadas a las que se les aplican parches con regularidad. Puedes usar imágenes personalizadas y ejecutarlas en Compute Engine, pero, si lo haces, debes aplicarles parches. Google Cloud actualiza las imágenes de SO con regularidad para mitigar las vulnerabilidades nuevas como se describe en los boletines de seguridad y proporciona soluciones a fin de corregir las vulnerabilidades de las implementaciones existentes.

Si usas GKE, te recomendamos que habilites la actualización automática de nodos para que Google actualice los nodos del clúster con los últimos parches. Google administra los planos de control de GKE, que se actualizan y se parchan automáticamente. Además, usa imágenes optimizadas para contenedores que selecciona Google para la implementación. Google aplica parches a estas imágenes y las actualiza con regularidad.

Controla el acceso a tus imágenes y clústeres

Es importante saber quién puede crear e iniciar instancias. Puedes controlar este acceso mediante IAM. Para obtener información sobre cómo determinar qué acceso necesitan las cargas de trabajo, consulta Planifica las identidades de las cargas de trabajo.

Además, puedes usar los Controles del servicio de VPC para definir cuotas personalizadas en los proyectos a fin de limitar quién puede iniciar imágenes. Para obtener más información, consulta la sección Protege tu red.

A fin de proporcionar seguridad de infraestructura para el clúster, GKE te permite usar IAM con el control de acceso basado en roles (RBAC) a fin de administrar el acceso a tu clúster y los espacios de nombres.

Aísla los contenedores en una zona de pruebas

Usa GKE Sandbox para implementar aplicaciones multiusuario que necesitan una capa adicional de seguridad y aislamiento del kernel del host. Por ejemplo, usa GKE Sandbox cuando ejecutes código desconocido o que no sea de confianza. GKE Sandbox es una solución de aislamiento de contenedores que proporciona una segunda capa de defensa entre las cargas de trabajo alojadas en contenedores en GKE.

GKE Sandbox se compiló para aplicaciones que tienen requisitos de E/S bajos, pero que tienen un escalamiento alto. Estas cargas de trabajo en contenedores deben mantener su velocidad y rendimiento, pero también es posible que incluyan código no confiable que requiera mayor seguridad. Usa gVisor, una zona de pruebas del entorno de ejecución de contenedores, para proporcionar aislamiento de seguridad adicional entre las aplicaciones y el kernel del host. gVisor proporciona verificaciones de integridad adicionales y limita el alcance del acceso para un servicio. No es un servicio de endurecimiento de contenedores que proteja de amenazas externas. Para obtener más información sobre gVisor, consulta gVisor: Protege GKE y los usuarios sin servidores en el mundo real.

¿Qué sigue?

Obtén más información sobre la seguridad de los contenedores y el procesamiento con los siguientes recursos:

Protege la red

En este documento de Framework de la arquitectura de Google Cloud, se proporcionan prácticas recomendadas para proteger la red.

Extender la red existente para incluir entornos de nube tiene muchas implicaciones de seguridad. Es probable que tu enfoque local para las defensas de varias capas incluya un perímetro distinto entre Internet y la red interna. Es probable que protejas el perímetro mediante firewalls físicos, routers, sistemas de detección de intrusiones, etcétera. Debido a que el límite está definido con claridad, puedes supervisar con facilidad las intrusiones y responder en consecuencia.

Cuando migras a la nube (ya sea por completo o de forma híbrida), vas más allá del perímetro local. En este documento, se describen las formas en que puedes continuar protegiendo los datos y las cargas de trabajo de tu organización en Google Cloud. Como se mencionó en Administra riesgos con controles, la forma en que configuras y proteges tu red de Google Cloud depende de los requisitos de la empresa y el acierto.

En esta sección, suponemos que ya leíste la sección Herramientas de redes de la categoría Diseño del sistema y que ya creaste un diagrama de arquitectura básico de tus componentes de red de Google Cloud Para ver un diagrama de ejemplo, consulta Concentrador y radio.

Implementa redes de confianza cero

Migrar a la nube significa que tu modelo de confianza de red debe cambiar. Debido a que tus usuarios y tus cargas de trabajo ya no están detrás del perímetro local, no puedes usar protecciones perimetrales de la misma manera para crear una red interna confiable. El modelo de seguridad de confianza cero significa que nadie es confiable de manera predeterminada, ya sea que estén dentro o fuera de la red de tu organización. Cuando verificas las solicitudes de acceso, el modelo de seguridad de confianza cero requiere que verifiques la identidad y el contexto del usuario. A diferencia de una VPN, debes cambiar los controles de acceso del perímetro de la red a los usuarios y los dispositivos.

En Google Cloud, puedes usar BeyondCorp Enterprise como tu solución de confianza cero. BeyondCorp Enterprise proporciona protección contra amenazas y datos y controles de acceso adicionales. Si deseas obtener más información para configurarla, consulta Comienza a usar BeyondCorp Enterprise.

Además de BeyondCorp Enterprise, Google Cloud incluye Identity-Aware Proxy (IAP). IAP te permite extender la seguridad de confianza cero a tus aplicaciones dentro de Google Cloud y de forma local. IAP usa políticas de control de acceso para proporcionar autenticación y autorización a los usuarios que acceden a tus aplicaciones y recursos.

Asegure las conexiones a los entornos locales o de múltiples nubes.

Muchas organizaciones tienen cargas de trabajo en entornos de nube y de forma local. Además, para la resiliencia, algunas organizaciones usan soluciones de múltiples nubes. En estos casos, es fundamental proteger la conectividad entre todos los entornos.

Google Cloud incluye lo siguiente: Métodos de acceso privado a VM compatibles con Cloud VPN o Cloud Interconnect, incluidos los siguientes:

Para obtener una comparación entre los productos, consulta Elige un producto de Conectividad de red.

Inhabilita las redes predeterminadas

Cuando creas un proyecto de Google Cloud nuevo, una red VPC de Google Cloud predeterminada con direcciones IP de modo automático y las reglas de firewall prepropagadas se aprovisionan de forma automática. Para las implementaciones de producción, te recomendamos borrar las redes predeterminadas en los proyectos existentes y, luego, inhabilitar la creación de las redes predeterminadas en proyectos nuevos.

Las redes de nube privada virtual te permiten usar cualquier dirección IP interna. Para evitar conflictos de direcciones IP, te recomendamos que primero planifiques la asignación de redes y direcciones IP en tus implementaciones conectadas y en tus proyectos. Un proyecto permite varias redes de VPC, pero, por lo general, se recomienda limitar estas redes a una por proyecto para aplicar el control de acceso de manera efectiva.

Protege el perímetro

En Google Cloud, puedes usar varios métodos para segmentar y proteger el perímetro de nube, incluidos los firewalls y los Controles del servicio de VPC.

Usa la VPC compartida para compilar una implementación de producción que te proporcione una sola red compartida y que aísle las cargas de trabajo en proyectos individuales que pueden administrar diferentes equipos. La VPC compartida proporciona implementación, administración y control centralizados de los recursos de red y seguridad de la red en varios proyectos. La VPC compartida consiste en proyectos host y de servicio que realizan las siguientes funciones:

  • Un proyecto host contiene las redes y los recursos relacionados con la seguridad de la red, como redes de VPC, subredes, reglas de firewall y conectividad híbrida.
  • Un proyecto de servicio se conecta con un proyecto host. Te permite aislar las cargas de trabajo y los usuarios a nivel de proyecto mediante Identity and Access Management (IAM), mientras comparte los recursos de red desde el proyecto host administrado de forma central.

Define políticas y reglas de firewall a nivel de organización, carpeta y red de VPC. Puedes configurar reglas de firewall para permitir o denegar tráfico hacia o desde las instancias de VM. Para ver ejemplos, consulta Ejemplos de políticas de firewall de red globales y regionales y Ejemplos de políticas de firewall jerárquicas. Además de definir reglas según las direcciones IP, los protocolos y los puertos, puedes administrar el tráfico y aplicar las reglas de firewall según la cuenta de servicio que usa una instancia de VM o mediante etiquetas seguras.

Para controlar el movimiento de datos en los servicios de Google y configurar la seguridad perimetral basada en el contexto, considera los Controles del servicio de VPC. Los Controles del servicio de VPC proporcionan una capa adicional de seguridad para los servicios de Google Cloud que es independiente de las políticas y reglas de firewall de IAM y firewall. Por ejemplo, los Controles del servicio de VPC te permiten configurar perímetros entre datos confidenciales y no confidenciales para que puedas aplicar controles que eviten el robo de datos.

Usa las políticas de seguridad de Google Cloud Armor para permitir, denegar, o redireccionar las solicitudes al balanceador de cargas de aplicaciones externo en el perímetro de Google Cloud, lo más cerca posible de la fuente del tráfico entrante. Estas políticas evitan que el tráfico no deseado consuma recursos o ingrese a tu red.

Usa el proxy web seguro para aplicar políticas de acceso detalladas a tu tráfico web de salida y supervisar el acceso a los servicios web que no son de confianza.

Inspecciona el tráfico de red

Puedes usar IDS de Cloud y la duplicación de paquetes para garantizar la seguridad y el cumplimiento de las cargas de trabajo que se ejecutan en Compute Engine y Google Kubernetes Engine (GKE).

Usa el Sistema de detección de intrusiones de Cloud (actualmente en vista previa) para obtener visibilidad del tráfico que entra y sale de tus redes de VPC. En IDS de Cloud, se crea una red de intercambio de tráfico administrada por Google que tiene VM duplicadas. Las tecnologías de protección contra amenazas de Palo Alto Networks duplican e inspeccionan el tráfico. Para obtener más información, consulta Descripción general de IDS de Cloud.

La Duplicación de paquetes clona el tráfico de las instancias de VM especificadas en tu red de VPC y las reenvía para su recopilación, retención y análisis. Después de configurar la Duplicación de paquetes, puedes usar el IDS de Cloud o herramientas de terceros para recopilar e inspeccionar el tráfico de red a gran escala. Inspeccionar el tráfico de red de esta manera ayuda a proporcionar detección de intrusiones y supervisión del rendimiento de la aplicación.

Usa un firewall de aplicación web

Para aplicaciones y servicios web externos, puedes habilitar Google Cloud Armor a fin de proporcionar protección contra la denegación de servicio distribuido (DSD) y capacidades de firewall de aplicación web (WAF). Google Cloud Armor admite las cargas de trabajo de Google Cloud que se exponen mediante el balanceo de cargas de HTTP(S) externo, el balanceo de cargas de proxy TCP o el proxy SSL.

Google Cloud Armor se ofrece en dos niveles de servicio: Standard y Managed Protection Plus. Para aprovechar al máximo las capacidades avanzadas de Google Cloud Armor, debes invertir en Managed Protection Plus en tus cargas de trabajo clave.

Automatiza el aprovisionamiento de infraestructura

La automatización te permite crear una infraestructura inmutable, lo que significa que no se puede cambiar después del aprovisionamiento. Esta medida le brinda a tu equipo de operaciones un estado bueno conocido, una reversión rápida y funciones de solución de problemas. Para la automatización, puedes usar herramientas como Terraform, Jenkins y Cloud Build.

Para ayudarte a compilar un entorno que use la automatización, Google Cloud proporciona una serie de planos de seguridad que, a su vez, se basan en el plano de basees empresariales.. El plano de la base de seguridad proporciona el diseño bien definido de Google para un entorno de aplicación seguro y describe paso a paso cómo configurar e implementar tu propiedad de Google Cloud. Con las instrucciones y las secuencias de comandos que forman parte del plano de base de seguridad, puedes configurar un entorno que cumpla con nuestros lineamientos y prácticas recomendadas de seguridad. Puedes desarrollar ese plano con planos adicionales o diseñar tu propia automatización.

Si deseas obtener más información sobre la automatización, consulta Usa una canalización de CI/CD para flujos de trabajo de procesamiento de datos.

Supervisa tu red

Supervisa tu red y el tráfico mediante telemetría

Los registros de flujo de VPC y los registros de reglas de firewall proporcionan visibilidad casi en tiempo real del tráfico y el uso de firewall en el entorno de Google Cloud. Por ejemplo, el registro de reglas de firewall registra el tráfico desde y hacia las instancias de VM de Compute Engine. Cuando combinas estas herramientas con Cloud Logging y Cloud Monitoring, puedes hacer un seguimiento, alertar y visualizar el tráfico y patrones de acceso para mejorar la seguridad operativa de tu implementación.

Estadísticas de firewall te permite revisar qué reglas de firewall coincidieron con las conexiones entrantes y salientes, y si las conexiones se permitieron o se rechazaron. La función de reglas bloqueadas te ayuda a ajustar la configuración del firewall, ya que te muestra qué reglas nunca se activan porque otra regla siempre se activa primero.

Usa Network Intelligence Center para consultar el rendimiento de tu arquitectura y tu topología de red. Puedes obtener estadísticas detalladas sobre el rendimiento de la red y, luego, optimizar la implementación para eliminar los cuellos de botella en el servicio. Las pruebas de conectividad te proporcionan estadísticas sobre las reglas de firewall y las políticas que se aplican a la ruta de red.

Para obtener más información sobre la supervisión, consulta Implementa controles de registro y detección.

¿Qué sigue?

Obtén más información sobre la seguridad de red con los siguientes recursos:

Implementa la seguridad de los datos

En este documento del Framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para implementar la seguridad de los datos.

Como parte de tu arquitectura de implementación, debes considerar qué datos planeas procesar y almacenar en Google Cloud, y su sensibilidad. Diseña tus controles para ayudar a proteger los datos durante su ciclo de vida, identificar la propiedad y clasificación de los datos y ayudar a protegerlos del uso no autorizado.

Para ver un plano de seguridad que implementa un almacén de datos de BigQuery con las prácticas recomendadas de seguridad descritas en este documento, consulta Protege un almacén de datos de BigQuery que almacena datos confidenciales.

Clasifica tus datos de forma automática

Realiza la clasificación de datos lo antes posible en el ciclo de vida de la administración de datos, idealmente cuando se crean. Por lo general, los esfuerzos de clasificación de datos solo requieren unas pocas categorías, como las siguientes:

  • Públicos: datos aprobados para acceso público.
  • Internos: Datos no sensibles que no se publican al público.
  • Confidenciales: Datos sensibles disponibles para la distribución interna general.
  • Restringidos: Datos altamente sensibles o regulados que requieren distribución restringida.

Usa Sensitive Data Protection para descubrir y clasificar datos en tu entorno de Google Cloud. Sensitive Data Protection tiene compatibilidad integrada para analizar y clasificar datos sensibles en Cloud Storage, BigQuery y Datastore También tiene una API de transmisión para admitir fuentes de datos adicionales y cargas de trabajo personalizadas.

Sensitive Data Protection puede identificar datos sensibles mediante Infotipos integrados. Puede clasificar, enmascarar, asignar tokens y transformar elementos sensibles de forma automática (como datos de PII) para que puedas administrar el riesgo de recopilar, almacenar y usar datos. En otras palabras, puede integrarse a los procesos del ciclo de vida de los datos para garantizar que los datos en cada etapa estén protegidos.

Para obtener más información, consulta Desidentificación y reidentificación de PII en conjuntos de datos a gran escala con Sensitive Data Protection.

Gestiona la administración de datos mediante metadatos

La administración de datos es una combinación de procesos que garantizan que los datos sean seguros, privados y exactos, y que estén disponibles y se puedan usar. Aunque eres responsable de definir una estrategia de administración de datos para tu organización, Google Cloud proporciona herramientas y tecnologías para ayudarte a poner en práctica tu estrategia. Google Cloud también proporciona un framework para la administración de datos (PDF) en la nube.

Usa Data Catalog para encontrar, seleccionar y usar metadatos. para describir tus recursos de datos en la nube. Puedes usar Data Catalog para buscar recursos de datos y, luego, etiquetar los elementos con metadatos. Para ayudar a acelerar tus esfuerzos de clasificación de datos, integra Data Catalog con Sensitive Data Protection a fin de identificar de forma automática los datos confidenciales. Después de etiquetar los datos, puedes usar Google Identity and Access Management (IAM) para restringir los datos que los usuarios pueden consultar o usar a través de las vistas de Data Catalog.

Usa Dataproc Metastore o Hive metastore para administrar metadatos de cargas de trabajo. Data Catalog tiene un conector de Hive que permite que el servicio descubra metadatos dentro de un almacén de metadatos de Hive.

Usa Dataprep by Trifacta para definir y aplicar las reglas de calidad de los datos a través de una consola. Puedes usar Dataprep desde Cloud Data Fusion o Dataprep como servicio independiente.

Protege los datos según la fase de su ciclo de vida y su clasificación

Después de definir los datos en el contexto de su ciclo de vida y clasificarlos según su sensibilidad y riesgo, puedes asignar los controles de seguridad adecuados para protegerlos. Debes asegurarte de que tus controles entreguen protecciones adecuadas, cumplan con los requisitos normativos y reduzcan el riesgo. A medida que migras a la nube, revisa tu estrategia actual y dónde es posible que debas cambiar los procesos actuales.

En la siguiente tabla, se describen tres características de una estrategia de seguridad de datos en la nube.

Característica Descripción
Identificación Comprende la identidad de los usuarios, los recursos y las aplicaciones a medida que crean, modifican, almacenan, usan, comparten y borran datos.

Usa Cloud Identity y IAM para controlar el acceso a los datos. Si tus identidades requieren certificados, considera Certificate Authority Service.

Para obtener más información, consulta Administra la identidad y el acceso.
Límite y acceso Configura los controles de cómo se accede a los datos, quién puede hacerlo y en qué circunstancias. Los límites de acceso a los datos se pueden administrar en estos niveles:

Visibilidad Puedes auditar el uso y crear informes que demuestren cómo se controlan los datos y se accede a ellos. Google Cloud Logging y Transparencia de acceso proporcionan estadísticas sobre las actividades de tus propios administradores de la nube y el personal de Google. Para obtener más información, consulta Supervisa tus datos.

Encripta los datos

De forma predeterminada, Google Cloud encripta los datos de los clientes almacenados en reposo, sin que debas realizar ninguna acción. Además de la encriptación predeterminada, Google Cloud proporciona opciones para la encriptación de sobre y la administración de claves de encriptación. Por ejemplo, los discos persistentes de Compute Engine se encriptan de forma automática, pero puedes proporcionar o administrar tus propias claves.

Debes identificar las soluciones que se adapten mejor a tus requisitos de generación, almacenamiento y rotación de claves, ya sea que elijas las claves para tu almacenamiento, procesamiento o cargas de trabajo de macrodatos.

Google Cloud incluye las siguientes opciones para la encriptación y la administración de claves:

  • Claves de encriptación administradas por el cliente (CMEK). Puedes generar y administrar tus claves de encriptación con Cloud Key Management Service (Cloud KMS). Usa esta opción si tienes ciertos requisitos de administración de claves, como la necesidad de rotar las claves de encriptación con regularidad.
  • Claves de encriptación proporcionadas por el cliente (CSEK) Puedes crear y administrar tus propias claves de encriptación y, luego, proporcionarlas a Google Cloud cuando sea necesario. Usa esta opción si generas tus propias claves mediante el sistema de administración de claves local para usar tu propia clave (BYOK). Si proporcionas tus propias claves mediante CSEK, Google las replica y las pone a disposición de las cargas de trabajo. Sin embargo, la seguridad y la disponibilidad de CSEK son tu responsabilidad porque las claves proporcionadas por el cliente no se almacenan en plantillas de instancias ni en la infraestructura de Google. Si pierdes el acceso a las claves, Google no puede ayudarte a recuperar los datos encriptados. Piensa con cuidado qué claves deseas crear y administrar tú mismo. Puedes usar CSEK solo para la información más sensible. Otra opción es realizar encriptación del cliente en tus datos y, luego, almacenar los datos encriptados en Google Cloud, donde Google vuelve a encriptarlos.
  • Sistema de administración de claves de terceros con Cloud External Key Manager (Cloud EKM). Cloud EKM protege tus datos en reposo mediante claves de encriptación que se almacenan y administran en un sistema de administración de claves de terceros que controlas fuera de la infraestructura de Google. Cuando usas este método, tienes una garantía considerable de que cualquier persona fuera de tu organización no pueda acceder a tus datos. Cloud EKM te permite lograr un modelo de retención de claves seguras (HYOK) para la administración de claves. Para obtener información sobre la compatibilidad, consulta la lista de servicios habilitados de Cloud EKM.

Cloud KMS también te permite encriptar los datos con claves de encriptación respaldadas por software o módulos de seguridad de hardware (HSM) validados en función del nivel 3 del estándar FIPS 140-2. Si usas Cloud KMS, se almacenarán tus claves criptográficas en la región en la que implementaste el recurso. Cloud HSM distribuye tus necesidades de administración de claves en todas las regiones, lo que proporciona redundancia y disponibilidad global de las claves.

Para obtener detalles sobre cómo funciona la encriptación de sobre, consulta Encriptación en reposo en Google Cloud.

Controla el acceso de los administradores de nube a tus datos

Puedes controlar el acceso del personal de ingeniería y Atención al cliente de Google a tu entorno en Google Cloud. La aprobación de acceso te permite aprobar de forma explícita antes de que los empleados de Google accedan a tus datos o recursos en Google Cloud. Este producto complementa la visibilidad proporcionada por la Transparencia de acceso, que genera registros cuando el personal de Google interactúa con tus datos. Estos registros incluyen la ubicación de la oficina y el motivo del acceso.

Si usas estos productos juntos, puedes denegar a Google la capacidad de desencriptar tus datos por cualquier motivo.

Configura la ubicación en la que los datos están almacenados y desde dónde los usuarios pueden acceder a ellos

Puedes controlar las ubicaciones de red desde las que los usuarios pueden acceder a los datos mediante los Controles del servicio de VPC. Este producto te permite limitar el acceso de los usuarios en una región específica. Puedes aplicar esta restricción incluso si el usuario está autorizado de acuerdo con tu política de IAM de Google. Mediante los Controles del servicio de VPC, creas un perímetro de servicio que define los límites virtuales desde los que se puede acceder a un servicio, lo que evita que los datos se transfieran fuera de esos límites.

Para obtener más información, consulta lo siguiente:

Administra secrets con Secret Manager

Secret Manager te permite almacenar todos tus secrets en un lugar centralizado. Los secrets son información de configuración, como contraseñas de bases de datos, claves de API o certificados TLS. Puedes rotar los secretos de forma automática y configurar las aplicaciones para que usen de forma automática la versión más reciente de un secret. Cada interacción con Secret Manager genera un registro de auditoría, por lo que ves cada acceso a cada secret.

Sensitive Data Protection también tiene una categoría de detectores que te ayudan a identificar las credenciales y los secretos en los datos que podrían protegerse con Secret Manager.

Supervisa tus datos

Para ver la actividad del administrador y los registros de uso de claves, usa Registros de auditoría de Cloud. Para ayudar a proteger tus datos, supervisa los registros con Cloud Monitoring a fin de garantizar el uso adecuado de tus claves.

Cloud Logging captura eventos de Google Cloud y te permite agregar fuentes adicionales si es necesario. Puedes segmentar tus registros por región, almacenarlos en buckets e integrar código personalizado para procesar registros. Si deseas ver un ejemplo, consulta Solución personalizada para el análisis de registros automatizado.

También puedes exportar registros a BigQuery para realizar análisis de seguridad y acceso a fin de identificar los cambios no autorizados y el acceso inapropiado a los datos de tu organización.

Security Command Center puede ayudarte a identificar y resolver problemas de acceso no seguro a datos organizacionales sensibles que se almacenan en la nube. A través de una única interfaz de administración, puedes analizar para detectar una amplia variedad de vulnerabilidades y riesgos de seguridad en tu infraestructura de nube. Por ejemplo, puedes supervisar para detectar el robo de datos, analizar los sistemas de almacenamiento en busca de datos confidenciales y detectar qué buckets de Cloud Storage están abiertos a Internet.

¿Qué sigue?

Obtén más información sobre la seguridad de los datos con los siguientes recursos:

Implemente aplicaciones de manera segura

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para implementar aplicaciones de forma segura.

Para implementar aplicaciones seguras, debes tener un ciclo de vida de desarrollo de software bien definido, con verificaciones de seguridad adecuadas durante las etapas de diseño, desarrollo, prueba e implementación. Cuando diseñas una aplicación, recomendamos una arquitectura de sistema en capas que usa frameworks estandarizados para la identidad, la autorización y el control de acceso.

Automatiza las versiones seguras

Sin herramientas automatizadas, puede ser difícil implementar, actualizar y aplicar parches a entornos de aplicaciones complejos para cumplir con los requisitos de seguridad coherentes. Por lo tanto, recomendamos que compiles una canalización de CI/CD para estas tareas, lo que puede resolver muchos de estos problemas. Las canalizaciones automatizadas quitan errores manuales, proporcionan ciclos de reacción de desarrollo estandarizados y habilitan iteraciones rápidas de productos. Por ejemplo, los grupos privados de Cloud Build te permiten implementar una canalización de CI/CD administrada y muy segura para sectores altamente regulados, como las finanzas y la atenión médica.

Puedes usar la automatización para analizar las vulnerabilidades de seguridad cuando se crean artefactos. También puedes definir políticas para diferentes entornos (desarrollo, prueba, producción, etc.) de modo que solo se implementen los artefactos verificados.

Asegúrate de que las implementaciones de la aplicación sigan los procesos aprobados

Si un atacante pone en riesgo tu canalización de CI/CD, toda tu pila puede verse afectada. Para ayudar a proteger la canalización, debes aplicar un proceso de aprobación establecido antes de implementar el código en producción.

Si planeas usar Google Kubernetes Engine (GKE) o GKE Enterprise, puedes establecer estas verificaciones y equilibrios mediante la autorización binaria. La autorización binaria adjunta firmas configurables a las imágenes del contenedor. Estas firmas (también llamadas certificaciones) ayudan a validar la imagen. En la implementación, la autorización binaria usa estas certificaciones para determinar si un proceso se completó antes. Por ejemplo, puedes usar la autorización binaria para realizar las siguientes acciones:

  • Verificar que un sistema de compilación específico o una canalización de integración continua (CI) hayan creado una imagen de contenedor.
  • Validar que una imagen de contenedor cumpla con la política de firma de vulnerabilidades.
  • Verificar que una imagen de contenedor pase los criterios para ascender al siguiente entorno de implementación, por ejemplo, desde el desarrollo hasta el control de calidad

Escanea en busca de vulnerabilidades conocidas antes de la implementación

Te recomendamos que uses herramientas automatizadas que puedan realizar análisis de vulnerabilidades de forma continua en imágenes de contenedor antes de que los contenedores se implementen en la producción.

Usa Artifact Analysis para escanear de forma automática las vulnerabilidades de los contenedores almacenados en Artifact Registry y Container Registry. Este proceso incluye dos tareas: el escaneo y el análisis continuo.

Para comenzar, Artifact Analysis escanea las imágenes nuevas cuando se suben a Artifact Registry o Container Registry. El análisis extrae información sobre los paquetes del sistema en el contenedor.

Artifact Analysis busca vulnerabilidades cuando subes la imagen. Después del análisis inicial, Artifact Analysis supervisa continuamente los metadatos de las imágenes analizadas en Artifact Registry y Container Registry para detectar vulnerabilidades nuevas. Cuando Artifact Analysis recibe información nueva y actualizada sobre vulnerabilidades de la fuente de vulnerabilidades, hace lo siguiente:

  • Actualiza los metadatos de las imágenes analizadas para mantenerlas actualizadas.
  • Crea casos de vulnerabilidades nuevos para las notas nuevas.
  • Borra los casos de vulnerabilidades que ya no son válidos.

Supervisa el código de la aplicación en busca de vulnerabilidades conocidas

Se recomienda usar herramientas automatizadas que puedan supervisar el código de la aplicación de forma constante en busca de vulnerabilidades conocidas, como OWASP Top 10. Para obtener una descripción de los productos y las funciones de Google Cloud que admiten las 10 técnicas principales de mitigación de OWASP, consulta Las 10 opciones principales de mitigación de OWASP.

Usa Web Security Scanner para identificar las vulnerabilidades de seguridad en las aplicaciones web de App Engine, Compute Engine y Google Kubernetes Engine. El scanner Rastrea la aplicación, para lo cual sigue todos los vínculos dentro del alcance de las URL de inicio, y trata de ejecutar la mayor cantidad posible de controladores de eventos y entradas del usuario. Puede analizar y detectar de forma automática las vulnerabilidades comunes, incluidas las secuencias de comandos entre sitios (XSS), la inyección de Flash, el contenido mixto (HTTP en HTTPS) y las bibliotecas desactualizadas o inseguras. Web Security Scanner te brinda una identificación temprana de estos tipos de vulnerabilidades con bajas tasas de falsos positivos.

Controla el movimiento de datos entre perímetros

Para controlar el movimiento de datos en un perímetro, puedes configurar perímetros de seguridad en torno a los recursos de tus servicios administrados por Google. Usa los Controles del servicio de VPC para colocar todos los componentes y servicios en tu canalización de CI/CD (por ejemplo, Container Registry, Artifact Registry, Artifact Analysis y la autorización binaria) dentro de un perímetro de seguridad.

Los Controles del servicio de VPC mejoran tu capacidad de mitigar el riesgo de copia o transferencia de datos no autorizadas (robo de datos) de los servicios administrados por Google. Con los Controles del servicio de VPC, puedes configurar perímetros de seguridad en torno a los recursos de los servicios administrados por Google y controlar el movimiento de datos en los límites perimetrales. Cuando un perímetro de servicio se aplica de manera forzosa, las solicitudes que infringen la política del perímetro se rechazan, como las solicitudes que se realizan a servicios protegidos fuera del perímetro. Cuando un servicio está protegido por un perímetro de aplicación forzosa, los Controles del servicio de VPC garantizan lo siguiente:

  • Un servicio no puede transmitir datos fuera del perímetro. Los servicios protegidos funcionan con normalidad dentro del perímetro, pero no pueden enviar recursos y datos fuera del perímetro. Esta restricción ayuda a evitar que los usuarios maliciosos con información privilegiada que podrían tener acceso a proyectos en el perímetro roben datos.
  • Las solicitudes que provienen del exterior del perímetro al servicio protegido se respetan solo si las solicitudes cumplen con los criterios de los niveles de acceso que se asignaron al perímetro.
  • Los proyectos pueden acceder a ese servicio en otros perímetros mediante puentes perimetrales.

Encripta tus imágenes de contenedor

En Google Cloud, puedes encriptar tus imágenes de contenedor mediante las claves de encriptación administradas por el cliente (CMEK). Las claves CMEK se administran en Cloud Key Management Service (Cloud KMS). Cuando usas CMEK, puedes inhabilitar o destruir la clave para inhabilitar de forma temporal o permanente el acceso a una imagen de contenedor encriptada.

¿Qué sigue?

Obtén más información para proteger la cadena de suministro y la Seguridad para aplicaciones con los siguientes recursos:

Administrar obligaciones de cumplimiento

En este documento del framework de la arquitectura de Google Cloud, se proporcionan prácticas recomendadas para administrar las obligaciones de cumplimiento.

Los requisitos normativos de la nube dependen de una combinación de factores, incluidos los siguientes:

  • Las leyes y normativas que aplican las ubicaciones físicas de tu organización
  • Las leyes y normativas que se aplican a las ubicaciones físicas de tus clientes
  • Los requisitos normativos de tu sector

Estos requisitos determinan muchas de las decisiones que debes tomar sobre qué controles de seguridad habilitar para las cargas de trabajo en Google Cloud.

Un recorrido de cumplimiento típico pasa por tres etapas: evaluación, solución de brechas y supervisión continua. En esta sección, se abordan las prácticas recomendadas que puedes usar durante cada etapa.

Evalúa tus necesidades de cumplimiento

La evaluación del cumplimiento comienza con una revisión exhaustiva de todas las obligaciones normativas y cómo tu empresa las implementa. Para ayudarte con la evaluación de los servicios de Google Cloud, usa el centro de recursos de cumplimiento. En este sitio, se proporcionan detalles sobre lo siguiente:

  • Asistencia de servicio para varias normativas
  • Certificaciones de Google Cloud

Puedes solicitar una entrevista con un especialista en cumplimiento de Google para comprender mejor el ciclo de vida del cumplimiento en Google y cómo se pueden cumplir tus requisitos.

Para obtener más información, consulta Garantiza el cumplimiento en la nube (PDF).

Implementa Assured Workloads

Assured Workloads es la herramienta de Google Cloud que se basa en los controles de Google Cloud para ayudarte a cumplir con las obligaciones de cumplimiento. Assured Workloads te permite hacer lo siguiente:

  • Selecciona tu régimen de cumplimiento. Luego, la herramienta establece de forma automática los controles de acceso del personal de referencia.
  • Establece la ubicación de tus datos con políticas de la organización para que tus datos en reposo y recursos solo permanezcan en esa región.
  • Selecciona la opción de administración de claves (como el período de rotación de claves) que mejor se adapte a tus requisitos de cumplimiento y seguridad.
  • Para ciertos requisitos normativos, como FedRAMP Moderate, selecciona los criterios de acceso del personal de Atención al cliente de Google (por ejemplo, si completaron las verificaciones de antecedentes adecuadas).
  • Asegúrate de que las claves de encriptación administradas por Google cumplan con FIPS-140-2 y cumplan con el cumplimiento de FedRAMP Moderate. Para agregar una capa de control y separación de obligaciones adicionales, puedes usar claves de encriptación administradas por el cliente (CMEK). Para obtener más información sobre las claves, consulta Encripta tus datos.

Revisa los planos de las plantillas y las prácticas recomendadas que se aplican a tu régimen de cumplimiento

Google publicó planos y guías de soluciones que describen las prácticas recomendadas y que proporcionan módulos de Terraform que te permiten implementar un entorno que te ayude a lograr el cumplimiento. En la siguiente tabla, se enumera una selección de planos que abordan la seguridad y la alineación con los requisitos de cumplimiento.

EstándarDescripción
PCI
FedRAMP
HIPAA

Supervisa el cumplimiento

La mayoría de las regulaciones requieren que supervises actividades particulares, incluidos los controles de acceso. Para ayudarte con la supervisión, puedes usar lo siguiente:

  • Transparencia de acceso, que proporciona registros casi en tiempo real cuando los administradores de Google Cloud acceden a tu contenido.
  • Registro de reglas de firewall a fin de registrar las conexiones TCP y UDP dentro de una red de VPC para cualquier regla que crees. Estos registros pueden ser útiles para auditar el acceso a la red o proporcionar una advertencia temprana de que la red se está usando de manera no aprobada.
  • Los registros de flujo de VPC para registrar los flujos de tráfico de red que envían o reciben las instancias de VM.
  • Security Command Center Premium para supervisar el cumplimiento con varios estándares.
  • OSSEC (o cualquier otra herramienta de código abierto) para registrar la actividad de las personas que tienen acceso de administrador a tu entorno.
  • Key Access Justifications para ver los motivos de una solicitud de acceso a las claves.

Automatiza el cumplimiento

Para ayudarte a cumplir con las normativas cambiantes, determina si existen maneras de automatizar las políticas de seguridad mediante la incorporación de estas en tu infraestructura como implementaciones de código. Por ejemplo, considera lo siguiente:

  • Usa planos de seguridad para compilar las políticas de seguridad en las implementaciones de infraestructura.

  • Configurar Security Command Center para alertar cuando se produzcan problemas de incumplimiento Por ejemplo, supervisa si hay problemas, como los usuarios que inhabilitan la verificación en dos pasos o las cuentas de servicio con privilegios excesivos. Para obtener más información, consulta Configura la búsqueda de notificaciones.

  • Configurar la solución automática de notificaciones específicas Para obtener más información, consulta Código de Cloud Functions.

Para obtener más información sobre la automatización de cumplimiento, consulta la solución de Administración de riesgos y cumplimiento como código (RCaC).

¿Qué sigue?

Obtén más información sobre el cumplimiento con los siguientes recursos:

Implementa requisitos de soberanía y residencia de datos

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para implementar requisitos de soberanía y residencia de datos.

Los requisitos de soberanía y residencia de los datos se basan en tus regulaciones regionales y específicas de la industria, y las diferentes organizaciones pueden tener distintos requisitos de soberanía de los datos. Por ejemplo, es posible que tengas los siguientes requisitos:

  • Control sobre todo el acceso a tus datos mediante Google Cloud, incluido qué tipo de personal puede acceder a los datos y desde qué región pueden acceder a ellos.
  • Capacidad de inspeccionar los cambios en la infraestructura y los servicios de nube, que pueden afectar el acceso a los datos o la seguridad de estos. Las estadísticas sobre estos tipos de cambios ayudan a garantizar que Google Cloud no pueda eludir los controles ni mover los datos fuera de la región.
  • Vigencia de las cargas de trabajo durante un tiempo prolongado cuando no puedes recibir actualizaciones de software de Google Cloud.

Administra la soberanía de los datos

La soberanía de los datos te proporciona un mecanismo para evitar que Google acceda a tus datos. Solo apruebas el acceso para los comportamientos del proveedor que aceptas como necesarios.

Por ejemplo, puedes administrar la soberanía de los datos de las siguientes maneras:

Administra tu soberanía operativa

La soberanía operativa te garantiza que el personal de Google no pueda poner en riesgo tus cargas de trabajo.

Por ejemplo, puedes administrar la soberanía operativa de las siguientes maneras:

Administra la soberanía del software

La soberanía del software te brinda garantías de que puedes controlar la disponibilidad de tus cargas de trabajo y ejecutarlas donde lo desees, sin depender de un solo proveedor de servicios en la nube (o estar atado a él). La soberanía del software incluye la capacidad de sobrevivir a los eventos que requieren que cambies con rapidez dónde se implementan las cargas de trabajo y qué nivel de conexión externa está permitido.

Por ejemplo, Google Cloud admite implementaciones híbridas y de múltiples nubes. Además, GKE Enterprise te permite implementar y administrar tus aplicaciones en entornos locales y en la nube.

Controla la residencia de los datos

La residencia de datos describe dónde se almacenan los datos en reposo. Los requisitos de residencia de datos varían según los objetivos de diseño de los sistemas, las preocupaciones normativas de la industria, la ley nacional, las implicaciones fiscales e incluso la cultura.

El control de la residencia de los datos comienza con lo siguiente:

  • Comprender el tipo de datos y su ubicación.
  • Determinar los riesgos que existen para tus datos y qué leyes y regulaciones se aplican.
  • Controlar dónde se encuentran los datos o a dónde se dirigen.

Para cumplir con los requisitos de residencia de datos, Google Cloud te permite controlar dónde se almacenan los datos, cómo se accede a ellos y cómo se procesan. Puedes usar las políticas de ubicación de recursos para restringir en qué lugar se crean los recursos y limitar dónde se replican los datos entre las regiones. Puedes usar la propiedad de ubicación de un recurso para identificar dónde se implementa el servicio y quién lo mantiene.

Para obtener información de compatibilidad, consulta Servicios compatibles con las ubicaciones de los recursos.

¿Qué sigue?

Obtén más información sobre la residencia y la soberanía de los datos con los siguientes recursos:

Implementa requisitos de privacidad

En este documento, el framework de arquitectura de Google Cloud proporciona prácticas recomendadas para implementar requisitos de privacidad.

Las regulaciones de privacidad ayudan a definir cómo puedes obtener, procesar, almacenar y administrar los datos de tus usuarios. Muchos controles de privacidad (por ejemplo, controles para cookies, administración de sesiones y obtención del permiso del usuario) son tu responsabilidad porque eres el propietario de tus datos (incluidos los datos que recibes de tus usuarios).

Google Cloud incluye los siguientes controles que promueven la privacidad:

  • Encriptación predeterminada de todos los datos cuando están en reposo, en tránsito y mientras se procesan.
  • Protege contra el acceso de usuarios con información privilegiada.
  • Compatibilidad con varias regulaciones de privacidad.

Para obtener más información, consulta Compromisos de privacidad de Google Cloud.

Clasifica tus datos confidenciales

Debes definir qué datos son confidenciales y, luego, asegurarte de que estén protegidos de forma correcta. Los datos confidenciales pueden incluir números de tarjetas de crédito, direcciones, números de teléfono y otra información de identificación personal (PII).

Con Sensitive Data Protection, puedes configurar las clasificaciones adecuadas. Luego, puedes etiquetar y asignar tokens a los datos antes de almacenarlos en Google Cloud. Para obtener más información, consulta Clasifica tus datos de manera automática.

Bloquea el acceso a los datos sensibles

Coloca datos sensibles en su propio perímetro de servicio con los Controles del servicio de VPC y configura controles de acceso de Google Identity and Access Management (IAM) para esos datos. Configura la autenticación de varios factores (MFA) para todos los usuarios que requieran acceso a datos sensibles.

Para obtener más información, consulta Controla el movimiento de datos entre perímetros y Configura SSO y MFA.

Supervisa los ataques de suplantación de identidad (phishing)

Asegúrate de que el sistema de correo electrónico esté configurado para proteger contra ataques de suplantación de identidad (phishing), que a menudo se usan para cometer fraudes y usar software malicioso.

Si tu organización usa Gmail, puedes usar la protección avanzada contra la suplantación de identidad (phishing) y el software malicioso. Esta colección de opciones de configuración proporciona controles para poner correos electrónicos en cuarentena, protege contra los tipos anómalos de archivos adjuntos y ayuda a proteger contra los correos electrónicos entrantes de falsificación de identidad. La zona de pruebas de seguridad detecta software malicioso en los adjuntos. Gmail se actualiza de forma continua y automática con las mejoras y protecciones de seguridad más recientes para ayudar a mantener seguro el correo electrónico de tu organización.

Extiende la seguridad de la confianza cero a tu personal híbrido

Un modelo de seguridad de confianza cero significa que no se confía en nadie implícitamente, ya sea que esté dentro o fuera de la red de tu organización. Cuando tus sistemas de IAM verifican las solicitudes de acceso, una postura de seguridad de confianza cero significa que se consideran el contexto y la identidad del usuario (por ejemplo, su dirección IP o ubicación). A diferencia de una VPN, la seguridad de confianza cero cambia los controles de acceso del perímetro de la red a los usuarios y sus dispositivos. La seguridad de confianza cero permite que los usuarios trabajen de manera más segura desde cualquier ubicación. Por ejemplo, los usuarios pueden acceder a los recursos de su organización desde sus laptops o dispositivos móviles mientras están en su casa.

En Google Cloud, puedes configurar BeyondCorp Enterprise y Identity-Aware Proxy (IAP) para habilitar la confianza cero en los recursos de Google Cloud. Si tus usuarios usan Google Chrome y habilitas BeyondCorp Enterprise, puedes integrar la seguridad de confianza cero en los navegadores de los usuarios.

¿Qué sigue?

Obtén más información sobre la seguridad y la privacidad con los siguientes recursos:

Implementa controles de registro y de detección

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para implementar controles de registro y de detección.

Los controles de detección usan telemetría para detectar opciones de configuración incorrectas, vulnerabilidades y actividad potencialmente maliciosa en un entorno de nube. Google Cloud te permite crear controles personalizados de supervisión y detección para tu entorno. En esta sección, se describen estas funciones adicionales y recomendaciones para su uso.

Supervisa el rendimiento de la red

Network Intelligence Center permite ver el rendimiento de la arquitectura y la topología de red. Puedes obtener estadísticas detalladas sobre el rendimiento de la red y, luego, usar esa información para optimizar la implementación mediante la eliminación de los cuellos de botella en los servicios. Las pruebas de conectividad te proporcionan estadísticas sobre las reglas de firewall y las políticas que se aplican a la ruta de red.

Supervisa y evita el robo de datos

El robo de datos es una preocupación clave para las organizaciones. Por lo general, esto ocurre cuando una persona autorizada extrae datos de un sistema seguro y, luego, los comparte con un tercero no autorizado o los transfiere a un sistema no seguro.

Google Cloud proporciona varias funciones y herramientas que te ayudan a detectar y prevenir el robo de datos. Para obtener más información, consulta Evita el robo de datos.

Centraliza la supervisión

Security Command Center proporciona visibilidad de los recursos que tienes en Google Cloud y en su estado de seguridad. Security Command Center te ayuda a prevenir amenazas, detectarlas y responder a ellas. Proporciona un panel centralizado que puedes usar para identificar configuraciones de seguridad incorrectas en máquinas virtuales, redes, aplicaciones y buckets de almacenamiento. Puedes abordar estos problemas antes de que se produzcan daños o pérdidas en el negocio. Las funciones integradas de Security Command Center pueden revelar actividad sospechosa en los registros de seguridad de Cloud Logging o indicar máquinas virtuales comprometidas.

Si quieres responder a las amenazas, sigue las recomendaciones prácticas o exporta los registros a tu sistema SIEM para una investigación más detallada. Para obtener información sobre el uso de un sistema SIEM con Google Cloud, consulta Estadísticas de registros de seguridad en Google Cloud.

Security Command Center también proporciona varios detectores que te ayudan a analizar la seguridad de la infraestructura. Estos detectores incluyen lo siguiente:

Otros servicios de Google Cloud, como los registros de Google Cloud Armor, también proporcionan resultados que se pueden ver en Security Command Center.

Habilita los servicios que necesitas para las cargas de trabajo y, luego, supervisa y analiza los datos importantes. Para obtener más información sobre cómo habilitar el registro en los servicios, consulta la sección Habilita registros en las estadísticas del registro de seguridad en Google Cloud.

Supervisa en busca de amenazas

Event Threat Detection es un servicio administrado opcional de Security Command Center Premium que detecta amenazas en tu transmisión de registros. Mediante Event Threat Detection, puedes detectar amenazas de alto riesgo y costosas, como software malicioso, criptominería, acceso no autorizado a recursos de Google Cloud, ataques DSD y ataques de fuerza bruta a SSH. Con las funciones de la herramienta para sintetizar volúmenes de datos de registro, los equipos de seguridad pueden identificar con rapidez incidentes de alto riesgo y enfocarse en solucionarlos.

Para detectar cuentas de usuario que pueden estar comprometidas en tu organización, usa los registros de acciones sensibles de Cloud Platform a fin de identificar cuándo se realizan acciones sensibles y confirmar que los usuarios válidos realizaron esas acciones con fines válidos. Una acción sensible es una acción, como la adición de una rol con muchos privilegios, que podría ser perjudicial para tu negocio si un actor malicioso realizó la acción. Usa Cloud Logging para ver, supervisar y consultar los registros de acciones sensibles de Cloud Platform. También puedes ver las entradas del registro de acciones sensibles con el Servicio de acciones sensibles, un servicio integrado de Security Command Center Premium.

Chronicle puede almacenar y analizar todos tus datos de seguridad de forma centralizada. Para ayudarte a ver todo el intervalo de un ataque, Chronicle puede asignar registros a un modelo común, enriquecerlos y, luego, vincularlos en cronogramas. Puedes usar Chronicle para crear reglas de detección, configurar indicadores de compromiso (IoC) y realizar actividades de búsqueda de amenazas. Las reglas de detección se escriben en el lenguaje de YARA-L. Para ver reglas de detección de amenazas de muestra en YARA-L, consulta el repositorio de Estadísticas de seguridad de la comunidad (CSA). Además de escribir tus propias reglas, puedes aprovechar las detecciones seleccionadas en Chronicle. Estas detecciones seleccionadas son un conjunto de reglas predefinidas y administradas de YARA-L que pueden ayudarte a identificar amenazas.

Otra opción para centralizar los registros para el análisis de seguridad, la auditoría y la investigación es usar BigQuery. En BigQuery, supervisas las amenazas o configuraciones incorrectas comunes mediante consultas en SQL (como las del repositorio de CSA) para analizar los cambios de permisos, la actividad de aprovisionamiento, el uso de cargas de trabajo, el acceso a los datos y la actividad de red. Para obtener más información sobre las estadísticas de registro de seguridad en BigQuery desde la configuración a través del análisis, consulta Estadísticas de registros de seguridad en Google Cloud.

En el siguiente diagrama, se muestra cómo centralizar la supervisión mediante las funciones integradas de detección de amenazas de Security Command Center y la detección de amenazas que se realiza en BigQuery, Chronicle o una herramienta SIEM de terceros.

Cómo interactúan los diversos recursos y herramientas de estadísticas de seguridad en Google Cloud.

Como se muestra en el diagrama, hay varias fuentes de datos de seguridad que debes supervisar. Estas fuentes de datos incluyen registros de Cloud Logging, cambios de recursos de Cloud Asset Inventory, registros de Google Workspace o eventos de hipervisor o un kernel invitado. En el diagrama, se muestra que puedes usar Security Command Center para supervisar estas fuentes de datos. Esta supervisión se produce de forma automática, siempre que hayas habilitado las funciones y los detectores de amenazas adecuados en Security Command Center. En el diagrama, se muestra que también puedes supervisar las amenazas mediante la exportación de datos de seguridad y los resultados de Security Command Center a una herramienta de estadísticas como BigQuery, Chronicle o una herramienta SIEM de terceros. En tu herramienta de estadísticas, el diagrama muestra que puedes realizar un análisis y una investigación más detallados mediante el uso y la extensión de las consultas y reglas como las disponibles en CSA.

¿Qué sigue?

Obtén más información sobre el registro y la detección con los siguientes recursos:

Framework de arquitectura de Google Cloud: confiabilidad

En esta sección del framework de arquitectura de Google Cloud, se muestra cómo diseñar y operar servicios confiables en una plataforma en la nube. También aprenderás sobre algunos de los productos y las funciones de Google Cloud que admiten la confiabilidad.

El framework de arquitectura describe las prácticas recomendadas, proporciona recomendaciones de implementación y explica algunos de los productos y servicios disponibles. Este framework busca ayudarte a diseñar la implementación de Google Cloud que mejor se adapte a las necesidades de tu empresa.

Para ejecutar un servicio confiable, la arquitectura debe incluir lo siguiente:

  • Objetivos de confiabilidad medibles, con desviaciones que corriges de inmediato
  • Patrones de diseño para la escalabilidad, la alta disponibilidad, la recuperación ante desastres y la administración automatizada de cambios.
  • Componentes que se reparan siempre que sea posible y código que incluye instrumentación para la observabilidad
  • Procedimientos operativos que ejecutan el servicio con un mínimo de trabajo manual y carga cognitiva en los operadores, y que te permiten detectar y mitigar con rapidez las fallas

La confiabilidad es responsabilidad de todos los ingenieros, como los equipos de desarrollo, administración de productos, operaciones y, también, ingeniería de confiabilidad de sitios (SRE). Todos deben ser responsables y comprender los objetivos de confiabilidad de su aplicación, así como los porcentajes de error aceptable y de riesgo. Los equipos deben poder priorizar el trabajo de forma adecuada y aumentar los conflictos de prioridad entre la confiabilidad y el desarrollo de las funciones del producto.

En la categoría de confiabilidad del framework de arquitectura, aprenderás a hacer lo siguiente:

Principios de confiabilidad

En este documento de framework de arquitectura, se explican algunos de los principios básicos para ejecutar servicios confiables en una plataforma en la nube. Estos principios ayudan a crear una comprensión común a medida que lees secciones adicionales del framework de arquitectura que te muestran cómo algunos de los productos y las funciones de Google Cloud admiten servicios confiables.

Terminología clave

Existen varios términos comunes asociados con las prácticas de confiabilidad. Pueden ser conocidos para muchos lectores. Sin embargo, para actualizar, consulta las descripciones detalladas en la página Terminología.

Principios básicos

El enfoque de Google para la confiabilidad se basa en los siguientes principios fundamentales.

La confiabilidad es tu principal característica

A veces, las funciones nuevas de los productos son tu prioridad principal a corto plazo. Sin embargo, la confiabilidad es la función principal del producto a largo plazo, ya que si el producto es demasiado lento o no está disponible durante un período prolongado, los usuarios podrían irse, lo que hace que otras funciones del producto sean irrelevantes.

El usuario define la confiabilidad

Para las cargas de trabajo orientadas al usuario, debes medir la experiencia del usuario. El usuario debe estar satisfecho con el rendimiento de tu servicio. Por ejemplo, consulta la proporción de éxito de las solicitudes de usuario, no solo las métricas del servidor, como el uso de CPU.

Para las cargas de trabajo de transmisión y por lotes, es posible que debas medir los indicadores clave de rendimiento (KPI) de la capacidad de procesamiento de datos, como las filas analizadas por período, en lugar de las métricas del servidor, como el uso del disco. Los KPI de capacidad de procesamiento pueden ayudar a garantizar que un informe diario o trimestral requerido por el usuario finalice a tiempo.

El 100% de la confiabilidad es el objetivo incorrecto

Tus sistemas deben ser lo bastante confiables para que los usuarios estén satisfechos, pero no deben ser demasiado confiables para que la inversión sea injustificada. Define los SLO que establezcan el umbral de confiabilidad que deseas y, luego, usa porcentajes de error aceptable para administrar la tasa de cambio adecuada.

Aplica los principios operativos y de diseño de este framework a un producto solo si el SLO de ese producto o aplicación justifica el costo.

La confiabilidad y la innovación rápida son complementarias

Usa los porcentajes de error aceptable para lograr un equilibrio entre la estabilidad del sistema y la agilidad del desarrollador. La siguiente guía te ayuda a determinar cuándo moverte rápido o lento:

  • Cuando haya un porcentaje de error aceptable disponible, puedes innovar con rapidez y mejorar el producto o agregar funciones del producto.
  • Cuando el porcentaje de error aceptable se reduzca, disminuye la velocidad y enfócate en las funciones de confiabilidad.

Principios operativos y de diseño

Para maximizar la confiabilidad del sistema, se aplican los siguientes principios de diseño y operativos. Cada uno de estos principios se analiza en detalle en el resto de la categoría de confiabilidad del framework de la arquitectura.

Define tus objetivos de confiabilidad

Las prácticas recomendadas que se analizan en esta sección del framework de arquitectura incluyen las siguientes:

  • Elige los SLI adecuados.
  • Establezca los SLO según la experiencia del usuario.
  • Mejore los SLO de manera iterativa.
  • Use SLO internos estrictos.
  • Usa porcentajes de error aceptable para administrar la velocidad de desarrollo.

Para obtener más información, consulta Define tus objetivos de confiabilidad en la categoría de confiabilidad del framework de arquitectura.

Genera observabilidad en su infraestructura y aplicaciones.

En esta sección del framework de arquitectura, se aborda el siguiente principio de diseño:

  • Instrumenta tu código para maximizar la observabilidad.

Para obtener más información, consulta Compila observabilidad en tu infraestructura y aplicaciones en la categoría de confiabilidad del framework de arquitectura.

Diseño para gran escala y alta disponibilidad

En esta sección del framework de arquitectura, se abordan los siguientes principios de diseño:

  • Crea redundancia para obtener una mayor disponibilidad.
  • Replica los datos entre las regiones para la recuperación ante desastres
  • Diseña una arquitectura multirregional para la resiliencia ante las interrupciones regionales.
  • Elimina los cuellos de botella de escalabilidad.
  • Disminuya los niveles de servicio correctamente cuando haya sobrecarga.
  • Evite y mitigue los aumentos repentinos de tráfico.
  • Limpie y valide las entradas.
  • Seguridad ante fallas, de manera que preserve la función del sistema.
  • Diseña las llamadas a la API y los comandos operativos para que puedan reintentarse.
  • Identifica y administra las dependencias del sistema.
  • Minimice las dependencias esenciales.
  • Asegúrate de que todos los cambios puedan revertirse

Si deseas obtener más información, consulta Diseña para el escalamiento y la alta disponibilidad en la categoría de confiabilidad del framework de arquitectura.

Crea herramientas y procesos operativos confiables

En esta sección del framework de arquitectura, se abordan los siguientes principios operativos:

  • Elige buenos nombres para aplicaciones y servicios.
  • Implementa lanzamientos progresivos con procedimientos de pruebas canary.
  • Distribuye el tráfico para las promociones y los lanzamientos programados
  • Automatice el proceso de compilación, prueba e implementación.
  • Defiéndase contra errores del operador.
  • Pruebe los procedimientos de recuperación ante fallas.
  • Realice pruebas de recuperación ante desastres.
  • Practica la ingeniería de caos

Para obtener más información, consulta Crea herramientas y procesos operativos confiables en la categoría de confiabilidad del framework de arquitectura.

Crea alertas eficientes

En esta sección del framework de arquitectura, se abordan los siguientes principios operativos:

  • Optimiza los retrasos de las alertas
  • Alerte sobre los síntomas en lugar de las causas.
  • Alerta sobre valores atípicos, no promedios.

Para obtener más información, consulta Compila alertas eficientes en la categoría de confiabilidad del framework de arquitectura.

Compila un proceso colaborativo de administración de incidentes

En esta sección del framework de arquitectura, se abordan los siguientes principios operativos:

  • Asigna una propiedad clara del servicio
  • Reduce las horas de detección (TTD) con alertas bien ajustadas.
  • Reduce el tiempo de mitigación (TTM) con los planes de administración de incidentes y el entrenamiento.
  • Crea diseños y contenido para el panel para minimizar el TTM.
  • Documenta los procedimientos de diagnóstico y la mitigación para situaciones de interrupciones conocidas.
  • Usa los análisis retrospectivos libres de responsabilidad para obtener información sobre las interrupciones y evitar las recurrencias

Para obtener más información, consulta Compila un proceso de administración de incidentes colaborativo en la categoría de confiabilidad del framework de arquitectura.

¿Qué sigue?

Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la excelencia operativa, la seguridad, la privacidad y el cumplimiento.

Defina sus objetivos de confiabilidad.

En este documento de framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para definir formas adecuadas de medir la experiencia del cliente de tus servicios a fin de que puedas ejecutar servicios confiables. Aprende a iterar en los objetivos de nivel de servicio (SLO) que defines y a usar porcentajes de error aceptable para saber cuándo podría disminuir la confiabilidad si lanzas actualizaciones adicionales.

Elige los SLI adecuados

Es importante elegir los indicadores de nivel de servicio (SLI) adecuados para comprender por completo el rendimiento de tu servicio. Por ejemplo, si tu aplicación tiene una arquitectura multiusuario que es típica de las aplicaciones de SaaS que usan varios clientes independientes, captura los SLI a nivel de usuario. Si tus SLI solo se miden a nivel global, es posible que pierdas problemas críticos en tu aplicación que afecten a un solo cliente importante o a una minoría de ellos. En su lugar, diseña tu aplicación para que incluya un identificador de usuarios en cada solicitud y, luego, propágalo en cada capa de la pila. Este identificador permite que tu sistema de supervisión agregue estadísticas a nivel de usuario en cada capa o microservicio a lo largo de la ruta de la solicitud.

El tipo de servicio que ejecutas también determina qué SLI supervisar, como se muestra en los siguientes ejemplos.

Sistemas de servicio

Los siguientes SLI son típicos en sistemas que entregan datos:

  • La disponibilidad indica la fracción de tiempo en que se puede usar un servicio. A menudo, se define en términos de la fracción de solicitudes con formato correcto que se ejecutan, como en el 99%.
  • La latencia indica la rapidez con la que se puede llegar a un porcentaje determinado de solicitudes. A menudo, se define en términos de un percentil distinto de 50, como “percentil 99 a 300 ms”.
  • La calidad indica qué tan buena es una respuesta determinada. La definición de calidad suele ser específica del servicio, lo que indica en qué medida el contenido de la respuesta a una solicitud difiere del contenido de respuesta ideal. La calidad de respuesta puede ser binaria (buena o mala) o se puede expresar en una escala del 0% al 100%.

Sistemas de procesamiento de datos

Los siguientes SLI son típicos en los sistemas que procesan datos:

  • La cobertura indica la fracción de datos que se procesaron, como el 99.9%.
  • La precisión indica la fracción de datos de salida que se consideran correctos, como el 99.99%.
  • La actualidad indica qué tan recientes son los datos de origen o los datos de salida agregados. Por lo general, cuanto más recientes se actualicen, mejor, como 20 minutos.
  • La capacidad de procesamiento indica cuántos datos se están procesando, como 500 MiB/s o, incluso, 1,000 solicitudes por segundo (RPS).

Sistemas de almacenamiento

Los siguientes SLI son típicos en sistemas que almacenan datos:

  • La durabilidad indica la probabilidad de que se recuperen los datos escritos en el sistema en el futuro, como el 99.9999%. Cualquier incidente relacionado con la pérdida de datos permanente reduce la métrica de durabilidad.
  • La capacidad de procesamiento y la latencia también son SLI comunes para los sistemas de almacenamiento.

Elige los SLI y establece los SLO según la experiencia del usuario.

Uno de los principios fundamentales de esta sección del framework de arquitectura es que el usuario define la confiabilidad. Mide las métricas de confiabilidad lo más cerca posible del usuario, como las siguientes opciones:

Establece tu SLO lo bastante alto como para que casi todos los usuarios estén satisfechos con tu servicio y no más alto que eso. Debido a la conectividad de red o a otros problemas transitorios del cliente, es posible que tus clientes no noten problemas breves de confiabilidad en tu aplicación, lo que te permite reducir el SLO.

Para el tiempo de actividad y otras métricas vitales, intenta un objetivo inferior al 100%, pero cerca de él. Los propietarios del servicio deben evaluar de manera objetiva el nivel mínimo de rendimiento y disponibilidad del servicio que haría felices a la mayoría de los usuarios, no solo establecer objetivos según los niveles contractuales externos.

La velocidad a la que realices cambios afectará la confiabilidad de tu sistema. Sin embargo, la capacidad de realizar cambios pequeños con frecuencia te ayuda a entregar funciones más rápido y con mayor calidad. Lograr objetivos de confiabilidad ajustados a la experiencia del cliente ayuda a definir el ritmo máximo y el alcance de los cambios (velocidad de atributos) que los clientes pueden tolerar.

Si no puedes medir la experiencia del cliente y definir los objetivos en torno a ella, puedes ejecutar un análisis de comparativas de la competencia. Si no existe una competencia comparable, mide la experiencia del cliente, incluso si aún no puedes definir objetivos. Por ejemplo, mide la disponibilidad del sistema o la tasa de transacciones significativas y exitosas para el cliente. Puedes correlacionar estos datos con las métricas empresariales o los KPI, como el volumen de pedidos en venta minorista o el volumen de llamadas y tickets de asistencia al cliente, y su gravedad. Durante un período, puedes usar esos ejercicios de correlación para obtener un umbral razonable de satisfacción del cliente. Este umbral es tu SLO.

Mejora los SLO de forma iterativa

Los SLO no deben configurarse en situaciones. Revisar los SLO de forma trimestral o, al menos, una vez al año y confirmar que continúen reflejando la satisfacción del usuario con precisión y correlacionarse bien con las interrupciones del servicio. Asegúrate de que cubran las necesidades comerciales actuales y los nuevos recorridos críticos de los usuarios. Revisa y aumenta tus SLO según sea necesario después de estas revisiones periódicas.

Usa SLO internos estrictos

Se recomienda tener SLO internos más estrictos que los externos. Dado que el incumplimiento del ANS suelen requerir la emisión de un crédito financiero o los reembolsos del cliente, debes abordar los problemas antes de que tengan un impacto financiero.

Te recomendamos usar estos SLO internos más estrictos con un proceso a posteriori libre de responsabilidades y revisiones de incidentes. Para obtener más información, consulta Compila un proceso de administración de incidentes colaborativo en la categoría de confiabilidad del Centro de arquitectura.

Usa porcentajes de error aceptable para administrar la velocidad de desarrollo

Indican si tu sistema es más o menos confiable de lo necesario en un período de tiempo determinado. Los porcentajes de error aceptables se calculan como 100% – SLO durante un período, como 30 días.

Cuando te queda capacidad en el porcentaje de error aceptable, puedes seguir lanzando mejoras o funciones nuevas con rapidez. Cuando el porcentaje de error aceptable sea cercano a cero, suspende o ralentiza los cambios de servicio e invierte recursos de ingeniería para mejorar las funciones de confiabilidad.

Google Cloud Observability incluye la supervisión de SLO para minimizar el esfuerzo de configurar los SLO y los porcentajes de error aceptable. Los servicios incluyen una interfaz gráfica de usuario que te ayudará a configurar los SLO de forma manual, una API para la configuración programática de los SLO y paneles integrados que hacen un seguimiento de la tasa de gasto del porcentaje de error aceptable. Para obtener más información, consulta cómo crear un SLO.

Recomendaciones

Para aplicar la guía en el framework de arquitectura a tu propio entorno, sigue estas recomendaciones:

  • Define y mide los SLI centrados en el cliente, como la disponibilidad o la latencia del servicio.
  • Define un porcentaje de error aceptable centrado en el cliente que sea más estricto que tu ANS externo. Incluye consecuencias por incumplimientos, como bloqueos de producción.
  • Configura los SLI de latencia para capturar valores atípicos, como el percentil 90 o 99, a fin de detectar las respuestas más lentas.
  • Revisa los SLO una vez al año como mínimo y confirma que se correlacionan bien con las interrupciones del servicio y la satisfacción del usuario.

¿Qué sigue?

Obtén más información para definir tus objetivos de confiabilidad con los siguientes recursos:

Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Define SLOs

Este documento es la primera de dos partes en las que se muestra cómo los equipos que operan servicios en línea pueden comenzar a compilar y adoptar una cultura de ingeniería de confiabilidad de sitios (SRE) mediante objetivos de nivel de servicio (SLO). Un SLO es un nivel objetivo de confiabilidad para un servicio.

En los modelos de software como servicio (SaaS), existe una tensión natural entre la velocidad del desarrollo del producto y la estabilidad operativa. Cuanto más cambies el sistema, más probable será que se interrumpa. Las herramientas de supervisión y observabilidad pueden ayudarte a mantener la confianza en la estabilidad operativa a medida que aumentas la velocidad de desarrollo. Sin embargo, aunque estas herramientas, conocidas también como herramientas de administración del rendimiento de las aplicaciones (APM), son importantes, una de las aplicaciones más importantes de estas herramientas es configurar los SLO.

Si se define de forma correcta, un SLO puede ayudar a los equipos a tomar decisiones operativas basadas en los datos que aumenten la velocidad de desarrollo sin sacrificar la estabilidad. El SLO también puede hacer que los equipos de desarrollo y operaciones compartan un único objeto acordado, lo que puede aliviar la tensión natural que existe entre sus objetivos: crear e iterar productos (desarrollo) y mantener la integridad del sistema (operaciones).

Los SLO se describen en detalle en El libro de SRE y en El libro de actividades de SRE, junto con otras prácticas de SRE. En esta serie, se busca simplificar el proceso de comprensión y desarrollo de los SLO para que puedas adoptarlos con mayor facilidad. Después de leer y comprender estos artículos, podrás encontrar más información en los libros.

En esta serie, verás un procedimiento claro para implementar los SLO en tu organización:

  • En este documento, se revisa qué son los SLO y se explica cómo definirlos para los servicios.
  • En Adopción de SLO, se describen los diferentes tipos de SLO en función de los tipos de cargas de trabajo, cómo medir esos SLO y cómo desarrollar alertas basadas en ellos.

Esta serie está dirigida a profesionales de SRE, equipos de operaciones y DevOps, administradores de sistemas y otros profesionales responsables de la estabilidad y confiabilidad de un servicio en línea. Se supone que comprendes cómo los servicios de Internet se comunican con los navegadores web y los dispositivos móviles, y que tienes conocimientos básicos sobre cómo se implementan y supervisan los servicios web y cómo se solucionan sus problemas.

Los informes State of DevOps identificaron las capacidades que impulsan el rendimiento de la entrega de software. Esta serie te ayudará con las siguientes funciones:

¿Por qué elegir los SLO?

Cuando compilas una cultura de SRE, ¿por qué debes comenzar con los SLO? En resumen, si no defines un nivel de servicio, es difícil medir si tus clientes están satisfechos con el servicio. Incluso si sabes que puedes mejorar el servicio, la falta de un nivel de servicio definido hace que sea difícil determinar dónde y cuánto invertir en las mejoras.

Puede ser tentador desarrollar SLO independientes para cada servicio, ya sea que estén orientados al usuario o no. Por ejemplo, un error común es medir dos o más servicios por separado, por ejemplo, un servicio de frontend y un almacén de datos de backend, cuando el usuario depende de ambos y no conoce la diferencia. Un mejor enfoque es desarrollar SLO basados en el producto (el conjunto de servicios) y enfocarte en las interacciones más importantes que tienen tus usuarios con él.

Por lo tanto, para desarrollar un SLO efectivo, lo mejor es que comprendas las interacciones de los usuarios con el servicio, que se denominan recorridos críticos del usuario (CUJ). Un CUJ considera los objetivos de tus usuarios y cómo usan tus servicios para alcanzarlos. El CUJ se define desde la perspectiva del cliente sin tener en cuenta los límites del servicio. Si se cumple el CUJ, el cliente estará satisfecho, y los clientes satisfechos son una medida clave del éxito de un servicio.

Un aspecto clave para la satisfacción del cliente con respecto a un servicio es la confiabilidad del servicio. No importa qué hace un servicio si no es confiable. Por lo tanto, la confiabilidad es la característica más importante de cualquier servicio. Una métrica común para la confiabilidad es el tiempo de actividad, que significa, por lo general, la cantidad de tiempo en que un sistema está activo. Sin embargo, preferimos usar una métrica más útil y precisa: la disponibilidad. La disponibilidad también responde a la pregunta sobre si un sistema está activo, pero de una manera más precisa que con la medición del tiempo desde que el sistema estuvo inactivo. En los sistemas distribuidos actuales, los servicios pueden estar inactivos de forma parcial, un factor en el que el tiempo de actividad no evalúa bien.

Por lo general, la disponibilidad se describe con número formados por nueve, como el 99.9% disponible (tres nueves) o el 99.99% (cuatro nueves). Medir un SLO de disponibilidad es una de las mejores formas de medir la confiabilidad del sistema.

Además de ayudar a definir el éxito operativo, un SLO puede ayudarte a elegir dónde invertir los recursos. Por ejemplo, los libros de SRE a menudo indican que cada nueve que agregas al diseño puede generar un costo incremental con utilidad marginal. Por lo general, se reconoce que alcanzar el siguiente valor de nueve en disponibilidad cuenta diez veces más que el anterior.

Elige un SLI

Para determinar si se cumple un SLO (es decir, si la condición es correcta), necesitas una medida. Esa medición se denomina indicador de nivel de servicio (SLI). Un SLI mide el nivel de un servicio en particular que entregas a los clientes. Lo ideal sería que el SLI esté vinculado a un CUJ aceptado.

Selecciona las mejores métricas

El primer paso para desarrollar un SLI es elegir la métrica que se medirá, como las solicitudes por segundo, los errores por segundo, la longitud de la cola, la distribución de los códigos de respuesta durante un período determinado o la cantidad de bytes transmitidos.

Estas métricas suelen ser de los siguientes tipos:

  • Contador. Por ejemplo, la cantidad de errores que se generaron hasta un punto de medición determinado. Este tipo de métrica puede aumentar, pero no disminuir.
  • Distribución. Por ejemplo, la cantidad de eventos que propagan un segmento de medición en particular para un período determinado. Puedes medir cuántas solicitudes tardan de 0 a 10 ms en completarse, cuántas tardan de 11 a 30 ms y cuántas de 31 a 100 ms. El resultado es un recuento de cada bucket, por ejemplo, [0-10: 50], [11-30: 220] y [31-100: 1103].
  • Indicador. Por ejemplo, el valor real de una parte medible del sistema (como la longitud de la cola). Este tipo de métrica puede aumentar o disminuir.

Para obtener más información sobre estos tipos, consulta la documentación del proyecto de Prometheus y los tipos de métricas de Cloud Monitoring ValueType y MetricKind.

Una distinción importante sobre los SLI es que no todas las métricas son SLI. De hecho, el libro de trabajo de SRE indica lo siguiente (se agrega énfasis):

“(…) por lo general, recomendamos considerar al SLI como la proporción entre dos números: la cantidad de eventos correctos dividida por la cantidad total de eventos (…)”.

“El SLI oscila entre el 0% y el 100%. El 0% significa que no funciona nada y el 100% significa que no hay errores. Descubrimos que esta escala es intuitiva y que este estilo se presta fácilmente al concepto de porcentaje de error aceptable”.

Muchas empresas de software realizan un seguimiento de cientos o miles de métricas, y solo unas pocas califican como SLI. Aparte de ser una proporción entre los eventos correctos y el total de eventos, ¿qué hace que una métrica califique como un SLI adecuado? Una métrica de SLI adecuada tiene las siguientes características:

  • La métrica se relaciona directamente con la satisfacción del usuario. Por lo general, los usuarios no están satisfechos si un servicio no se comporta como se espera, falla o es lento. Cualquier SLO basado en estas métricas se puede validar mediante la comparación del SLI con otros indicadores de la satisfacción del usuario. Por ejemplo, la cantidad de tickets de reclamos de los clientes, el volumen de llamadas de asistencia, la opinión en las redes sociales o los escalamientos. Si tu métrica no corresponde a estas otras métricas de satisfacción del usuario, es posible que no sea una métrica adecuada para usar como SLI.
  • El deterioro de la métrica se correlaciona con las interrupciones. Una métrica que se ve bien durante una interrupción es una métrica incorrecta para un SLI. Una métrica que no se ve bien durante el funcionamiento normal también es una métrica incorrecta para un SLI.
  • La métrica brinda una buena proporción de la relación señal/ruido. Cualquier métrica que genere una gran cantidad de falsos negativos o falsos positivos no es un SLI adecuado.
  • La métrica escala de forma monótona y lineal con la satisfacción del cliente. A medida que la métrica mejora, la satisfacción del cliente también lo hace.

Considera los gráficos del siguiente diagrama. Se representan las dos métricas que se pueden usar como SLI para un servicio y se muestra su variación con el paso del tiempo. El período en el que un servicio se degrada está resaltado en rojo, y el período en el que un servicio funciona bien está resaltado en azul.

imagen

En el caso del SLI incorrecto, la falta de satisfacción del usuario no corresponde directamente con un evento negativo (como la degradación, la lentitud o una interrupción del servicio). Además, el SLI fluctúa de forma independiente de la satisfacción del usuario. Con el SLI adecuado, se correlaciona el SLI y la satisfacción del usuario, los diferentes niveles de satisfacción son claros y hay muchas menos fluctuaciones irrelevantes.

Selecciona la cantidad correcta de métricas

Por lo general, un solo servicio tiene varios SLI, en especial si el servicio realiza diferentes tipos de trabajo o entrega a diferentes tipos de usuarios. Por ejemplo, separar las solicitudes de lectura de las solicitudes de escritura es una buena idea, ya que estas solicitudes actúan de diferentes maneras. En este caso, es mejor seleccionar las métricas adecuadas para cada servicio.

Por el contrario, muchos servicios realizan tipos de trabajos similares, que se pueden comparar directamente. Por ejemplo, si tienes un mercado en línea, los usuarios pueden ver una página principal, una subcategoría, una lista de los 10 elementos más destacados y una página de detalles, o buscar elementos. En lugar de desarrollar y medir un SLI diferente para cada una de estas acciones, puedes combinarlos en una sola categoría de SLI, por ejemplo, servicios de navegación.

En realidad, las expectativas de un usuario no cambian mucho entre las acciones de una categoría similar. Su satisfacción no depende de la estructura de los datos que exploran, ya sea que los datos deriven de una lista estática de elementos promocionados o del resultado generado de forma dinámica de una búsqueda asistida por aprendizaje automático en un conjunto de datos masivo. Su satisfacción se puede cuantificar mediante una respuesta a esta pregunta: “¿Visualicé una página completa de elementos rápidamente?”.

Lo ideal es que uses la menor cantidad de SLI posible para representar con precisión las tolerancias de un servicio determinado. Por lo general, un servicio debe tener entre dos y seis SLI. Si tienes muy pocos SLI, puedes perder indicadores valiosos. Si tienes demasiados SLI, tu equipo de guardia tiene demasiada información para hacer un seguimiento solo con la utilidad marginal agregada. Recuerda que los SLI deben simplificar la comprensión del estado de la producción y proporcionar una sensación de cobertura.

Elige un SLO

Un SLO se compone de los siguientes valores:

  • Un SLI. Por ejemplo, la proporción entre la cantidad de respuestas con el código HTTP 200 y la cantidad total de respuestas.
  • Una duración. Es el período en el que se mide una métrica. Este período puede basarse en un calendario (por ejemplo, desde el primer día de un mes hasta el primer día del siguiente) o en un período progresivo (por ejemplo, los últimos 30 días).
  • Un objetivo. Por ejemplo, un porcentaje objetivo de eventos correctos sobre el total de eventos (como el 99.9%) que esperas cumplir durante un período determinado.

A medida que desarrollas un SLO, definir la duración y el objetivo puede ser difícil. Una forma de comenzar el proceso es identificar los SLI y representarlos en el tiempo. Si no puedes decidir qué duración y objetivo usar, recuerda que tu SLO no tiene que ser perfecto de inmediato. Es probable que iteres en el SLO para asegurarte de que se alinee con la satisfacción del cliente y cumpla tus necesidades empresariales. Puedes comenzar con dos nueves (99.0%) durante un mes.

A medida que realizas un seguimiento del cumplimiento del SLO durante eventos como implementaciones, interrupciones y patrones de tráfico diarios, puedes obtener estadísticas sobre qué objetivo es adecuado, erróneo o incluso tolerable. Por ejemplo, en un proceso en segundo plano, puedes definir un éxito del 75% como adecuado. Sin embargo, en el caso de las solicitudes esenciales orientadas al usuario, podrías establecer algo más agresivo, como el 99.95%.

Por supuesto, no hay un único SLO que puedes aplicar para cada caso de uso. Los SLO dependen de varios factores:

  • Las expectativas del cliente
  • El tipo de carga de trabajo
  • La infraestructura para la entrega, la ejecución y la supervisión
  • El dominio del problema

En la parte 2 de esta serie, Adopta SLOs, se detallan los SLO independientes del dominio. Los SLO independientes del dominio (como la disponibilidad del servicio) no reemplazan a los indicadores de alto nivel (como los widgets vendidos por minuto). Sin embargo, pueden ayudar a medir si un servicio funciona sin importar el caso de uso empresarial.

Los indicadores independientes del dominio a menudo se pueden reducir a una pregunta. Por ejemplo: “¿El servicio está disponible?” o “¿El servicio tiene la rapidez necesaria?”. La respuesta suele encontrarse en un SLO que tiene en cuenta dos factores: la disponibilidad y la latencia. Puedes describir un SLO de la siguiente manera, en la que X = 99.9% y Y = 800 ms:

El X% de las solicitudes válidas son exitosas y se ejecutan más rápido que Y ms.

Próximos pasos

Adopta SLOs

En este documento, se definen varios objetivos de nivel de servicio (SLO) que son útiles para distintos tipos de cargas de trabajo de servicio comunes. Este documento es la parte 2 de una serie de dos partes. En la parte 1, Define SLOs, se presentan los SLO, se muestra cómo se derivan los SLO de los indicadores de nivel de servicio (SLI) y se describe qué es lo que hace que un SLO sea bueno.

Los informes State of DevOps identificaron las capacidades que impulsan el rendimiento de la entrega de software. Estos dos documentos te ayudarán con las siguientes funciones:

Qué se debe medir

Sin importar el dominio, muchos servicios comparten funciones comunes y pueden usar SLO genéricos. La siguiente discusión sobre los SLO genéricos se organiza por tipo de servicio y proporciona explicaciones detalladas de los SLI que se aplican a cada SLO.

Servicios impulsados por solicitudes

Un servicio impulsado por solicitudes recibe una solicitud de un cliente (otro servicio o usuario), realiza algunos cálculos, envía solicitudes de red a un backend (opcional) y, luego, muestra una respuesta al cliente. Los servicios impulsados por solicitudes se suelen medir mediante los SLI de disponibilidad y latencia.

Disponibilidad como un SLI

El SLI para la disponibilidad indica si el servicio está funcionando. El SLI para la disponibilidad se define de la siguiente manera:

La proporción de solicitudes válidas que se entregan de forma correcta.

Primero tienes que definir qué es válido. Algunas definiciones básicas pueden ser “una longitud que no es cero” o “cumple con un protocolo cliente-servidor”, pero depende del propietario del servicio definir el significado de válido. Un método común para medir la validez es usar un código de respuesta HTTP (o RPC). Por ejemplo, a menudo, los errores HTTP 500 son errores de servidor que se consideran en el SLO, mientras que los errores 400 son errores de cliente que no lo hacen.

Después de decidir qué medir, debes examinar cada código de respuesta que muestra el sistema para asegurarte de que la aplicación use esos códigos de manera correcta y coherente. Cuando uses códigos de error para SLO, es importante preguntar si un código es un indicador preciso de la experiencia de los usuarios del servicio. Por ejemplo, si un usuario intenta ordenar un elemento que está agotado, ¿el sitio falla y muestra un mensaje de error, o sugiere productos similares? Para usarlos con los SLO, los códigos de error deben estar relacionados con las expectativas de los usuarios.

Los desarrolladores pueden hacer un uso inadecuado de los errores. En el caso de que un usuario solicite un producto que esté agotado, un desarrollador puede programar, de manera errónea, que se muestre un error. Sin embargo, el sistema funciona de manera correcta y no presenta errores. El código no debe mostrarse como un error, aunque el usuario no pueda comprar el elemento que desea. Por supuesto, los propietarios de este servicio necesitan saber que un producto está agotado, pero la imposibilidad de realizar una venta no es un error desde la perspectiva del cliente y no debe considerarse en un SLO. Sin embargo, si el servicio no puede conectarse a la base de datos a fin de determinar si el elemento está en stock, es un error que se considera en el porcentaje de error aceptable.

El servicio podría ser más complejo. Por ejemplo, quizás el servicio maneja solicitudes asíncronas o proporciona un proceso de larga duración para los clientes. En estos casos, puedes exponer la disponibilidad de otra manera. Sin embargo, recomendamos que aún representes la disponibilidad como la proporción de solicitudes válidas que se ejecutan de forma correcta. Puedes definir la disponibilidad como la cantidad de minutos que se ejecuta la carga de trabajo de un cliente según se solicite. (A veces, este enfoque se conoce como el método “buenos minutos” para medir la disponibilidad). En el caso de una máquina virtual, podrías medir la disponibilidad en términos de la proporción de minutos después de una solicitud inicial a una VM que esta es accesible a través de SSH.

Latencia como un SLI

El SLI para la latencia (a veces llamado velocidad) indica si el servicio es rápido. El SLI para la latencia se define de manera similar a la disponibilidad:

La proporción de solicitudes válidas que se entregan más rápido que un umbral.

Puedes medir la latencia si calculas la diferencia entre el momento en el que se inicia un temporizador y el momento en el que se detiene para un tipo de solicitud determinado. La clave es la percepción de latencia del usuario. Un error común es ser demasiado preciso para medir la latencia. En realidad, los usuarios no pueden distinguir entre una actualización de 100 milisegundos (ms) y una de 300 ms, y puede que acepten cualquier punto entre 300 ms y 1,000 ms.

En cambio, es una buena idea desarrollar métricas centradas en la actividad que mantengan al usuario enfocado, por ejemplo, en los siguientes procesos:

  • Interactivo: 1,000 ms para el tiempo que un usuario espera un resultado después de hacer clic en un elemento.
  • Escritura: 1,500 ms para cambiar un sistema distribuido subyacente. Si bien esta cantidad de tiempo se considera lenta para un sistema, los usuarios tienden a aceptarla. Recomendamos que identifiques de forma explícita entre escrituras y lecturas en las métricas.
  • Segundo plano: 5,000 ms para una acción que no el usuario no puede visualizar, como una actualización periódica de datos, o bien otras solicitudes asíncronas.

La latencia se mide, por lo general, como una distribución (consulta Elige un SLI en la parte 1 de esta serie). Dada una distribución, puedes medir varios percentiles. Por ejemplo, puedes medir la cantidad de solicitudes que son más lentas que el percentil 99 histórico. En este caso, consideramos que los eventos buenos son aquellos más rápidos que este umbral, que se estableció mediante el análisis de la distribución histórica. También puedes establecer este umbral en función de los requisitos del producto. Incluso puedes configurar varios SLO de latencia, por ejemplo, la latencia típica en comparación con la latencia final.

Recomendamos que no uses la latencia promedio (o mediana) como el SLI. Descubrir que la latencia mediana es demasiado lenta significa que la mitad de los usuarios ya están insatisfechos. En otras palabras, puede que tengas una latencia mala durante días antes de descubrir una amenaza real en el porcentaje de error aceptable a largo plazo. Por lo tanto, te recomendamos que definas el SLO para la latencia final (percentil 95) y la latencia mediana (percentil 50).

En el artículo Metrics That Matter (Métricas que importan) de ACM, Benjamin Trenyor Sloss escribe lo siguiente:

“Una buena regla general […] es que la latencia del percentil 99 no debería ser mayor que el triple o el quíntuple de la latencia mediana”.

Treynor Sloss continúa y dice lo siguiente:

“Pensamos que cada una de las medidas de latencia de los percentiles 50, 95 y 99 de un servicio son valiosas, y lo ideal sería establecer los SLO en torno a cada uno de ellos”.

Un buen modelo a seguir es determinar los umbrales de latencia basados en percentiles históricos y, luego, medir cuántas solicitudes se incluyen en cada bucket. Para obtener más detalles, consulta la sección sobre alertas de latencia que se encuentra más adelante en este documento.

Calidad como un SLI

La calidad es un SLI útil para servicios complejos diseñados a fin de fallar de manera controlada mediante la degradación cuando las dependencias son lentas o no están disponibles. El SLI para la calidad se define de la siguiente manera:

La proporción de solicitudes válidas que se entregan sin degradar el servicio.

Por ejemplo, una página web puede cargar su contenido principal desde un almacén de datos, y cargar elementos auxiliares y opcionales de 100 servicios y almacenes de datos adicionales. Si un servicio opcional está fuera de servicio o es demasiado lento, la página aún se puede renderizar sin los elementos auxiliares. Puedes informar la proporción de solicitudes incorrectas si mides la cantidad de solicitudes que reciben una respuesta degradada (es decir, una respuesta a la que le falta al menos una respuesta del servicio de backend). Incluso podrías hacer un seguimiento de la cantidad de respuestas al usuario a las que les falta una respuesta de un solo backend o de varios backends.

Servicios de procesamiento de datos

Algunos servicios no están compilados para responder a solicitudes de usuarios, sino que consumen datos de una entrada, los procesan y generan un resultado. El rendimiento de estos servicios en pasos intermedios no es tan importante como el resultado final. Con servicios como estos, los SLI más eficaces son actualidad, cobertura, precisión y capacidad de procesamiento, en lugar de latencia o disponibilidad.

Actualidad como un SLI

El SLI para la actualidad se define de la siguiente manera:

La proporción de datos válidos actualizados más recientemente que un umbral.

En los sistemas de procesamiento por lotes, por ejemplo, la actualidad se puede medir como el tiempo transcurrido desde que una ejecución de procesamiento se completó de forma correcta para un resultado determinado. En sistemas de procesamiento más complejos o en tiempo real, puedes realizar un seguimiento de la antigüedad del registro más reciente procesado en una canalización.

Por ejemplo, considera un juego en línea que genere mosaicos de mapas en tiempo real. Es posible que los usuarios no perciban la rapidez con la que se crean los mosaicos de mapas, pero puede que noten cuando faltan los datos de los mapas o no están actualizados.

O bien, considera un sistema que lea registros de un sistema de seguimiento en stock a fin de generar el mensaje "X elementos en stock" para un sitio web de comercio electrónico. Puedes definir el SLI de actualidad de la siguiente manera:

El porcentaje de vistas que usaron información en stock que se actualizó en el último minuto.

También puedes usar una métrica para entregar datos no actualizados a fin de informar al SLI de calidad.

Cobertura como un SLI

El SLI para cobertura se define de la siguiente manera:

La proporción de datos válidos que se procesaron de manera correcta.

Para definir la cobertura, primero debes determinar si aceptas una entrada como válida o la omites. Por ejemplo, si un registro de entrada está dañado o tiene duración cero y no se puede procesar, puedes considerar que el registro no es válido para medir tu sistema.

A continuación, debes contar la cantidad de registros válidos. Puedes realizar este paso con un método count() simple o algún otro método. Este número es el recuento total de registros.

Por último, para generar el SLI de cobertura, debes contar la cantidad de registros que se procesaron de forma correcta y comparar esa cantidad con el recuento de registros válidos totales.

Precisión como un SLI

El SLI de precisión se define de la siguiente manera:

La proporción de datos válidos que generaron el resultado correcto.

En algunos casos, existen métodos para determinar la precisión de un resultado que se pueden usar a fin de validar su procesamiento. Por ejemplo, un sistema que rota o colorea una imagen nunca debe producir una imagen de cero bytes, o una imagen con una longitud o un ancho de cero. Es importante separar esta lógica de validación de la lógica de procesamiento en sí misma.

Un método para medir un SLI de precisión es usar datos de entrada de prueba conocidos, que son datos que tienen un resultado correcto conocido. Los datos de entrada deben ser representativos de los datos del usuario. En otros casos, es posible que se realice una verificación matemática o lógica del resultado, como en el ejemplo anterior de rotación de una imagen. Otro ejemplo puede ser un sistema de facturación que determina si una transacción es válida. Para ello, verifica si la diferencia entre el saldo antes de la transacción y el saldo después de la transacción coincide con el valor de la transacción.

Capacidad de procesamiento como un SLI

El SLI para la capacidad de procesamiento se define de la siguiente manera:

La proporción de tiempo en la que la tasa de procesamiento de datos fue más rápida que un umbral.

En un sistema de procesamiento de datos, la capacidad de procesamiento suele ser más representativa de la satisfacción del usuario que, por ejemplo, una medición de latencia única para una pieza de trabajo determinada. Por ejemplo, si el tamaño de cada entrada varía de manera considerable, puede que no tenga sentido comparar cuánto tiempo tarda cada elemento en completarse si un trabajo avanza a una tasa aceptable.

La cantidad de bytes por segundo es una forma común de medir la cantidad de trabajo que se requiere para procesar datos sin importar el tamaño de un conjunto de datos. Pero cualquier métrica que se escale de forma lineal en relación con el costo de procesamiento puede funcionar.

Puede ser útil particionar los sistemas de procesamiento de datos según las tasas de capacidad de procesamiento esperadas o implementar un sistema de calidad de servicio para garantizar que se manejen las entradas de alta prioridad y que se pongan en cola las entradas de baja prioridad. De cualquier manera, medir la capacidad de procesamiento como se define en esta sección puede ayudarte a determinar si el sistema funciona como se esperaba.

Servicios de ejecución programada

Para los servicios que necesitan realizar una acción en intervalos regulares, como trabajos cron de Kubernetes, puedes medir el sesgo y la duración de la ejecución. El siguiente es un trabajo cron de Kubernetes programado de muestra:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

Sesgo como un SLI

Como un SLI, el sesgo se define de la siguiente manera:

La proporción de ejecuciones que comienzan en un período aceptable en torno a la hora de inicio prevista.

El sesgo mide la diferencia de tiempo entre el momento en el que un trabajo debería comenzar y el momento en el que comienza. Por ejemplo, si el trabajo cron anterior de Kubernetes, que está configurado para iniciarse en el minuto cero de cada hora, comienza tres minutos después de la hora, el sesgo es de tres minutos. Cuando un trabajo se ejecuta antes, tienes un sesgo negativo.

Puedes medir el sesgo como una distribución a lo largo del tiempo, con los rangos aceptables adecuados que definen un buen sesgo. Para determinar el SLI, debes comparar la cantidad de ejecuciones que estaban dentro de un rango adecuado.

Duración de la ejecución como un SLI

Como un SLI, la duración de la ejecución se define de la siguiente manera:

La proporción de ejecuciones que se completan en el período de duración aceptable.

La duración de la ejecución es el tiempo que tarda un trabajo en completarse. Para una ejecución determinada, un modo de falla común consiste en que la duración real supere la duración programada.

Un caso interesante es cómo aplicar este SLI para capturar un trabajo interminable. Debido a que estos trabajos no se completan, debes registrar el tiempo que se emplea en un trabajo determinado en lugar de esperar a que se complete un trabajo. Este enfoque proporciona una distribución precisa del tiempo que lleva completar el trabajo, incluso en los peores casos.

Al igual que con el sesgo, puedes hacer un seguimiento de la duración de la ejecución como una distribución y definir límites inferiores y superiores aceptables para buenos eventos.

Tipos de métricas para otros sistemas

Muchas otras cargas de trabajo tienen sus propias métricas que puedes usar para generar SLI y SLO. Considera los siguientes ejemplos:

  • Sistemas de almacenamiento: durabilidad, capacidad de procesamiento, tiempo hasta el primer byte, disponibilidad de BLOB
  • Multimedia/video: continuidad de reproducción del cliente, tiempo hasta el inicio de la reproducción, finalización de la ejecución por grafos de la transcodificación
  • Videojuegos: tiempo para emparejar a los jugadores activos, tiempo a fin de generar un mapa

Cómo medir

Una vez que sabes qué medir, puedes decidir cómo realizar la medición. Puedes reunir los SLI de diferentes maneras.

Registro del servidor

Método para generar SLI

Procesamiento de registros del servidor de solicitudes o datos procesados

Consideraciones

Ventajas:

  • Los registros existentes se pueden volver a procesar para reabastecer los registros de SLI históricos.
  • Los identificadores de sesión entre servicios pueden reconstruir recorridos del usuario complejos en varios servicios.

Desventajas:

  • Las solicitudes que no llegan al servidor no se registran.
  • Es posible que no se registren las solicitudes que provocan que un servidor falle.
  • El tiempo que tome el procesamiento de registros puede dar como resultado SLI inactivos, que podrían ser datos incorrectos para una respuesta operativa.
  • Escribir el código para procesar registros puede ser una tarea lenta y propensa a errores.

Métodos y herramientas de implementación:

Métricas del servidor de aplicaciones

Método para generar SLI

Exportar métricas de SLI desde el código que entrega solicitudes de usuarios o procesa sus datos.

Consideraciones

Ventaja:

  • Por lo general, agregar métricas nuevas al código es rápido y económico.

Desventajas:

  • Las solicitudes que no llegan a los servidores de aplicaciones no se registran.
  • Es posible que sea difícil realizar el seguimiento de las solicitudes de varios servicios.

Métodos y herramientas de implementación:

Métricas de infraestructura de frontend

Método para generar SLI

Usar métricas de la infraestructura de balanceo de cargas (por ejemplo, el balanceador de cargas de capa 7 global de Google Cloud).

Consideraciones

Ventajas:

  • A menudo, las métricas y los datos históricos ya existen, lo que reduce el esfuerzo de ingeniería necesario para comenzar.
  • Las mediciones se realizan en el punto más cercano al cliente, pero siguen dentro de la infraestructura de entrega.

Desventajas:

  • No es viable para SLI de procesamiento de datos.
  • Solo se puede aproximar el recorrido de los usuarios de varias solicitudes.

Métodos y herramientas de implementación:

Datos o clientes sintéticos

Método para generar SLI

Compilar un cliente que envíe solicitudes fragmentadas a intervalos regulares y valide las respuestas. Para canalizaciones de procesamiento de datos, crear datos de entrada sintéticos identificados como buenos y validar resultados.

Consideraciones

Ventajas:

  • Mide todos los pasos del recorrido de los usuarios de varias solicitudes.
  • El envío de solicitudes desde fuera de la infraestructura captura más de la ruta de solicitud general en el SLI.

Desventajas:

  • Se aproxima la experiencia del usuario con solicitudes sintéticas, que podrían ser engañosas (falsos positivos o falsos negativos).
  • Cubrir todos los casos límite es difícil y puede convertirse en pruebas de integración.
  • Los objetivos de alta confiabilidad requieren un sondeo frecuente para obtener una medición precisa.
  • El tráfico de sondeo puede agotar el tráfico real.

Métodos y herramientas de implementación:

Instrumentación de clientes

Método para generar SLI

Agregar características de observabilidad al cliente con las que el usuario interactúa y volver a registrar eventos en la infraestructura de entrega que hagan un seguimiento de los SLI.

Consideraciones

Ventajas:

  • Proporciona la medición más precisa de la experiencia del usuario.
  • Puede cuantificar la confiabilidad de terceros, por ejemplo, CDN o proveedores de pagos.

Desventajas:

  • La latencia de transferencia y el procesamiento de registros de cliente hace que estos SLI no sean adecuados para activar una respuesta operativa.
  • Las medidas del SLI contendrán una serie de factores muy variables que no siempre podrán controlarse directamente.
  • Compilar instrumentación en el cliente puede implicar muchas tareas de ingeniería.

Métodos y herramientas de implementación:

Elige un método de medición

Lo ideal es que elijas un método de medición que se adapte a la experiencia del servicio de tu cliente y requiera el menor esfuerzo de tu parte. Para lograr esto, es posible que debas usar una combinación de los métodos en las tablas anteriores. A continuación, te sugerimos un enfoque que puedes implementar a lo largo del tiempo, enumerado en orden creciente de esfuerzo:

  1. Usa exportaciones de servidores de aplicaciones y métricas de infraestructura. Por lo general, puedes acceder a estas métricas de inmediato, y proporcionan valor con rapidez. Algunas herramientas de APM incluyen las herramientas integradas de SLO.
  2. Usa instrumentación de cliente. Debido a que, en general, los sistemas heredados no tienen instrumentación de cliente del usuario final integrada, configurar la instrumentación puede requerir una inversión significativa. Sin embargo, si usas un paquete de APM o framework de frontend que proporcione instrumentación de cliente, puedes obtener estadísticas sobre la satisfacción del cliente con rapidez.
  3. Usa procesamiento de registros. Si no puedes implementar exportaciones de servidor o instrumentación de cliente, pero los registros existen, puede que el procesamiento de registros sea la mejor opción. Otro enfoque es combinar el procesamiento de exportaciones y registros a través del uso de exportaciones como fuente inmediata para algunos SLI (como la disponibilidad inmediata) y el procesamiento de registros para indicadores a largo plazo (como las alertas de consumo lento que se analizan más adelante en la sección sobre alertas y SLO).
  4. Implementa pruebas sintéticas. Una vez que comprendas cómo tus clientes usan el servicio, debes probar tu nivel de servicio. Por ejemplo, puedes generar cuentas de prueba con datos identificados como buenos y realizar consultas para obtenerlos. Esta prueba puede ayudar a destacar los modos de falla que no se ven con facilidad, como en el caso de los servicios con poco tráfico.

Define tus objetivos

Una de las mejores formas de establecer objetivos es crear un documento compartido que describa tus SLO y cómo los desarrollas. Tu equipo puede iterar en el documento a medida que implementa y, además, itera en los SLO a lo largo del tiempo.

Recomendamos que los propietarios de empresas, los propietarios de productos y los ejecutivos revisen este documento. Las partes interesadas pueden ofrecer estadísticas sobre las expectativas del servicio y las compensaciones de confiabilidad del producto.

Esta es una plantilla para desarrollar un SLO destinada a los recorridos de usuario críticos (CUJ) más importantes de la empresa:

  1. Elige una especificación de SLI (por ejemplo, disponibilidad o actualidad).
  2. Define cómo implementar la especificación de SLI.
  3. Lee el plan para asegurarte de que los CUJ estén cubiertos.
  4. Establece los SLO según las necesidades de rendimiento anteriores o las necesidades comerciales.

Los CUJs no deben estar restringidos a un solo servicio ni a una organización o un equipo de desarrollo único. Si los usuarios dependen de cientos de microservicios que operan a un 99.5%, pero nadie lleva un registro de la disponibilidad de extremo a extremo, es probable que el cliente no esté satisfecho.

Supongamos que tienes una consulta que depende de cinco servicios que funcionan en secuencia: un balanceador de cargas, un frontend, un mezclador, un backend y una base de datos.

Si cada componente tiene una disponibilidad del 99.5%, la peor disponibilidad posible para el usuario es la siguiente:

99.5% * 99.5% * 99.5% * 99.5% * 99.5% = 97.52%

Esta es la peor disponibilidad posible para el usuario porque el sistema general falla si alguno de los cinco servicios falla. Esto solo ocurriría si todas las capas de la pila siempre deben estar disponibles de inmediato para controlar cada solicitud de usuario, sin factores de resiliencia como reintentos intermedios, cachés o colas. Un sistema con una vinculación tan estrecha entre los servicios constituye un mal diseño y va en contra del modelo de microservicios.

Medir solo el rendimiento en el SLO de un sistema distribuido de esta forma fragmentada (servicio por servicio) no refleja con exactitud la experiencia del cliente y puede dar lugar a una interpretación demasiado sensible.

En cambio, debes medir el rendimiento en función del SLO en el frontend para comprender lo que experimentan los usuarios. Al usuario no le interesa si falla un servicio de componentes que hace que una consulta se vuelva a intentar de manera automática y exitosa, siempre que la consulta del usuario tenga éxito. Si compartiste servicios internos, estos pueden medir por separado el rendimiento en función de sus SLO. Los servicios orientados al usuario actúan como sus clientes. Debes manejar estos SLO separados unos de otros.

Es posible compilar un servicio con alta disponibilidad (por ejemplo, 99.99%) sobre un servicio con menor disponibilidad (por ejemplo, 99.9%) mediante factores de resiliencia como reintentos inteligentes, almacenamiento en caché y puesta en cola.

Como regla general, cualquier persona con conocimiento práctico de las estadísticas debe poder leer y entender el SLO sin la necesidad de comprender el servicio subyacente ni el diseño organizativo.

Hoja de cálculo de ejemplo de SLO

Cuando desarrolles el SLO, recuerda hacer lo siguiente:

  • Asegúrate de que los SLI especifiquen un evento, un criterio de éxito, un lugar para registrar las fallas y los éxitos, y una forma de hacerlo.
  • Define la especificación del SLI en términos de la proporción de eventos que son buenos.
  • Asegúrate de que el SLO especifique un nivel de objetivo y un período para realizar mediciones.
  • Describe las ventajas y desventajas del enfoque para que las partes interesadas comprendan las compensaciones y las sutilezas.

Por ejemplo, considera la siguiente hoja de cálculo de SLO.

CUJ: Carga de la página principal

Tipo de SLI: Latencia

Especificación de SLI: Proporción de solicitudes de páginas principales que se entregan en menos de 100 ms

Implementaciones de SLI:

  • Proporción de solicitudes de páginas principales que se entregan en menos de 100 ms, medida desde la columna de latencia del registro del servidor. (Desventaja: esta medición no considera las solicitudes que no llegan al backend).
  • Proporción de solicitudes de páginas principales que se entregan en menos de 100 ms, medida por los sistemas de sondeo que ejecutan JavaScript en un navegador que se ejecuta en una máquina virtual. (Ventajas y desventajas: esta medición detecta errores cuando las solicitudes no pueden llegar a la red, pero puede que no se detecten problemas que afectan solo a un subconjunto de usuarios).

SLO: El 99% de las solicitudes de página principal en los últimos 28 días se entregaron en menos de 100 ms.

Próximos pasos

Terminología

En este documento, se proporcionan definiciones comunes para los términos relacionados con SLO que se usan en la sección Framework de arquitectura de Google Cloud: Confiabilidad.

  • Nivel de servicio: Es una medición del rendimiento de un servicio determinado en las tareas previstas para el usuario. Puedes describir esta medición en términos de satisfacción del usuario y medirla según varios métodos, en función de lo que el servicio hace y lo que el usuario espera que haga o se le indique que puede hacer.

    Ejemplo: “Un usuario espera que nuestro servicio esté disponible y sea rápido”.

  • Recorrido crítico del usuario (CUJ): Es un conjunto de interacciones que un usuario tiene con un servicio para lograr un único objetivo, como un solo clic o una canalización de varios pasos.

    Ejemplo: “Un usuario hace clic en el botón de confirmación de compra y espera recibir la respuesta de que se procesó el carrito y que se muestre un recibo”.

  • Indicador de nivel de servicio (SLI): Es un indicador de satisfacción de los usuarios que se puede medir de forma cuantitativa para el nivel de servicio. En otras palabras, para medir un nivel de servicio, debes medir un indicador que represente la satisfacción del usuario con ese nivel de servicio, por ejemplo, la disponibilidad de un servicio. Un SLI puede considerarse como una línea en un gráfico que cambia con el tiempo, a medida que el servicio mejora o se degrada. Esto suele ser una proporción de “bueno”/“total” expresado como un porcentaje sin unidades. Si se usan estos porcentajes de manera coherente, los equipos pueden comprender el SLI sin tener un conocimiento profundo de su implementación.

    Ejemplo: “Mide la cantidad de solicitudes correctas en los últimos 10 minutos dividida por la cantidad de solicitudes válidas en los últimos 10 minutos”.

  • Objetivo de nivel de servicio (SLO): Es el nivel que esperas que un servicio alcance la mayor parte del tiempo y con el que se mide un SLI.

    Ejemplo: “Las respuestas de los servicios deben ser más rápidas que 400 milisegundos (ms) para el 95% de todas las solicitudes válidas medidas durante 14 días”.

    Gráfico que muestra la relación entre los SLO y los SLI

  • Acuerdo de Nivel de Servicio (ANS): Es una descripción de lo que debe suceder si no se cumple un SLO. Por lo general, un ANS es un acuerdo legal entre proveedores y clientes y hasta puede contener condiciones de compensación. En discusiones técnicas sobre SRE, este término se suele evitar.

    Ejemplo: “Si el servicio no proporciona una disponibilidad del 99.95% durante un mes calendario, el proveedor de servicios compensará al cliente por cada minuto de incumplimiento”.

  • Porcentaje de error aceptable: Es la cantidad de tiempo o de eventos negativos que puedes tolerar antes de infringir el SLO. Esta medición te indica cuántos errores puede esperar o tolerar tu empresa. El porcentaje de error aceptable es fundamental para tomar decisiones que pueden ser riesgosas.

    Ejemplo: “Si nuestro SLO es del 99.9% de disponibilidad, permitimos que el 0.1% de nuestras solicitudes entreguen errores, ya sea a través de incidentes, accidentes o experimentación”.

SLO y alertas

En este documento de la sección Framework de arquitectura de Google Cloud: confiabilidad, se proporcionan detalles sobre las alertas relacionadas con los SLO.

Un enfoque equivocado para presentar un nuevo sistema de observabilidad como SLO es usar el sistema para reemplazar por completo un sistema anterior. En cambio, deberías usar los SLO como un sistema complementario. Por ejemplo, en lugar de borrar las alertas existentes, te recomendamos que las ejecutes en paralelo con las alertas de SLO que se presentan aquí. Este enfoque te permite descubrir qué alertas heredadas predicen las alertas de SLO, cuáles se activan en paralelo con las alertas de SLO y cuáles no se activan nunca.

Un principio de SRE es alertar en función de los síntomas, no de las causas. Los SLO son, por naturaleza, mediciones de síntomas. A medida que adoptas las alertas de SLO, es posible que la alerta de síntoma se active junto con otras alertas. Si descubres que las alertas heredadas basadas en causas se activan sin SLO o síntomas, estas son buenas candidatas para desactivarlas por completo, convertirlas en alertas de creación de tickets o registrarlas para consultarlas más adelante.

Para obtener más información, consulta SRE Workbook, capítulo 5.

Ritmo de consumo de SLO

La tasa de gasto de un SLO es una medición de la rapidez con la que una interrupción expone a los usuarios a los errores y agota el porcentaje de error aceptable. Cuando mides la tasa de gasto, puedes determinar el tiempo que transcurre hasta que un servicio infrinja el SLO. Las alertas basadas en la tasa de gasto de SLO son un enfoque valioso. Recuerda que el SLO se basa en una duración, que puede ser bastante larga (semanas o incluso meses). Sin embargo, el objetivo es detectar con rapidez una condición que genere una infracción del SLO antes de que esta ocurra.

En la siguiente tabla, se muestra el tiempo que lleva superar un objetivo si el 100% de las solicitudes fallan por un intervalo determinado, siempre que las consultas por segundo (QPS) sean constantes. Por ejemplo, si tienes un SLO del 99.9% medido en un período de 30 días, puedes soportar 43.2 minutos de tiempo de inactividad completo durante ese período. Por ejemplo, ese tiempo de inactividad puede ocurrir de una sola vez o a lo largo de varios incidentes.

Objetivo 90 días 30 días 7 días 1 día
90% 9 días 3 días 16.8 horas 2.4 horas
99% 21.6 horas 7.2 horas 1.7 horas 14.4 minutos
99.9% 2.2 horas 43.2 minutos 10.1 minutos 1.4 minutos
99.99% 13 minutos 4.3 minutos 1 minuto 8.6 segundos
99.999% 1.3 minutos 25.9 segundos 6 segundos 0.9 segundos

En la práctica, no puedes permitir incidentes de inactividad del 100% si quieres alcanzar porcentajes de éxito alto. Sin embargo, muchos sistemas distribuidos pueden fallar o degradar de forma parcial y controlada. Incluso en esos casos, necesitas saber si se necesita una intervención humana, aun en esas fallas parciales, y las alertas de SLO te permiten determinar eso.

Cuándo alertar

Una pregunta importante es cuándo actuar según la tasa de gasto de SLO. Como regla general, si agotas el porcentaje de error aceptable en 24 horas, el momento para llamar a alguien para solucionar un problema es ahora.

Medir la tasa de fallas no siempre es sencillo. Una serie de errores pequeños puede parecer aterradora en el momento, pero puede que se trate de errores de corta duración que tengan un impacto irrelevante en el SLO. Del mismo modo, si un sistema tiene problemas durante mucho tiempo, estos errores pueden generar una infracción del SLO.

Lo ideal es que el equipo reaccione a estas señales para que inviertas casi todo tu porcentaje de error aceptable (pero no lo excedas) durante un período determinado. Si gastas demasiado, infringirás el SLO. Si gastas muy poco, significa que no estás asumiendo los riesgos suficientes o, tal vez, estás desgastando al equipo de guardia.

Necesitas una forma de determinar cuándo un sistema está lo suficientemente dañado como para que una persona deba intervenir. En las siguientes secciones, se analizan algunos enfoques para contestar esa pregunta.

Consumo rápido

En el consumo rápido de SLO, se agota el porcentaje de error aceptable con rapidez y requiere que intervengas para evitar una infracción del SLO.

Supongamos que el servicio funciona con normalidad en 1,000 consultas por segundo (QPS) y quieres mantener una disponibilidad del 99%, medido en un período de siete días. El porcentaje de error aceptable es aproximadamente 6 millones de errores permitidos (a partir de alrededor de 600 millones de solicitudes). Si tienes 24 horas antes de que se agote el porcentaje de error aceptable, por ejemplo, esto te da un límite de 70 errores por segundo, o 252,000 errores en una hora. Estos parámetros se basan en la regla general que establece que los incidentes paginables deben consumir al menos el 1% del porcentaje de error aceptable por trimestre.

Puedes optar por detectar esta tasa de errores antes de que transcurra una hora. Por ejemplo, después de observar 15 minutos de una tasa de 70 errores por segundo, es posible que decidas hablar con el ingeniero de guardia, como se muestra en el siguiente diagrama.

imagen

Lo ideal es que el problema se resuelva antes de agotar una hora del presupuesto de 24 horas. Elegir que se detecte esta tasa en un período menor (por ejemplo, un minuto) puede ser muy propenso a errores. Si el tiempo objetivo para detectar es inferior a 15 minutos, se puede ajustar este número.

Consumo lento

Otro tipo de la tasa de gasto es un consumo lento. Supongamos que se presenta un error que agota tu porcentaje de error aceptable semanal en el día cinco o seis, o el presupuesto mensual en la segunda semana. ¿Cuál es la mejor respuesta?

En este caso, puedes establecer una alerta de consumo de SLO lento que te indique que estás por consumir todo el porcentaje de error aceptable antes de que finalice el período de alerta. Desde luego, esa alerta podría mostrar muchos falsos positivos. Por ejemplo, puede que haya una condición en la que los errores se produzcan de forma breve, pero a una velocidad que consumirían con rapidez el porcentaje de error aceptable. En estos casos, la condición es un falso positivo porque solo dura un tiempo breve y no afecta el porcentaje de error aceptable a largo plazo. Recuerda, el objetivo no es eliminar todas las fuentes de error, sino, permanecer dentro del rango aceptable para no exceder el porcentaje de error aceptable. Debes evitar alertar a una persona para que intervenga en eventos que no constituyen una amenaza real al porcentaje de error aceptable.

Te recomendamos notificar una cola de tickets (en lugar de llamar a alguien o enviar un correo electrónico) para eventos de consumo lento. Los eventos de consumo lento no son emergencias, pero requieren atención humana antes de que caduque el presupuesto. Estas alertas no deben ser correos electrónicos para una lista de equipos, ya que rápidamente se convierten en una molestia. Los tickets deben poder rastrearse, asignarse y transferirse. Los equipos deben desarrollar informes para la carga de tickets, los porcentajes de cierres, la capacidad de acción y los duplicados. Los tickets no prácticos excesivos son un excelente ejemplo de trabajo repetitivo.

Usar alertas de SLO con destreza puede llevar tiempo y depende de la cultura y las expectativas de tu equipo. Recuerda que puedes ajustar las alertas de SLO con el tiempo. También puedes tener varios métodos de alerta, con períodos de alerta variables según tus necesidades.

Alertas de latencia

Además de las alertas de disponibilidad, también puedes recibir alertas de latencia. Con los SLO de latencia, mides el porcentaje de solicitudes que no cumplen con un objetivo de latencia. Con este modelo, puedes usar el mismo modelo de alertas que usas para detectar consumos rápidos o lentos del porcentaje de error aceptable.

Como se mencionó antes sobre los SLO de latencia mediana, la mitad del total de tus solicitudes pueden estar fuera de SLO. En otras palabras, los usuarios pueden notar una latencia baja durante días antes de que puedas detectar el impacto en tu porcentaje de error aceptable a largo plazo. En cambio, los servicios deben definir los objetivos de latencia final y los objetivos de latencia típica. Te sugerimos usar el percentil 90 histórico para definir la típica, y el percentil 99 para la final. Después de establecer estos objetivos, puedes definir los SLO según la cantidad de solicitudes que esperas que lleguen en cada categoría de latencia y cuántas son demasiado lentas. Este enfoque usa el mismo concepto que un porcentaje de error aceptable y se debe tratar de la misma manera. Por lo tanto, podrías terminar con una declaración como “el 90% de las solicitudes se manejará con la latencia típica y un 99.9% con los objetivos de latencia final”. Estos objetivos garantizan que la mayoría de los usuarios experimenten la latencia típica y, también, te permitan hacer un seguimiento de cuántas solicitudes son más lentas que los objetivos de latencia final.

Algunos servicios pueden tener tiempos de ejecución esperados muy variables. Por ejemplo, puede que tengas expectativas de rendimiento muy diferentes para leer desde un sistema de almacén de datos, frente a escribir en él. En lugar de enumerar todas las expectativas posibles, puedes usar depósitos de rendimiento del tiempo de ejecución, como se muestra en las siguientes tablas. Este enfoque revela que estos tipos de solicitudes se identifican y clasifican de forma previa en cada bucket. No debes esperar que se clasifiquen solicitudes en el momento.

Sitio web para el usuario
Bucket Tiempo de ejecución máximo esperado
Lectura 1 segundo
Escritura / actualización 3 segundos
Sistemas de procesamiento de datos
Bucket Tiempo de ejecución máximo esperado
Pequeño 10 segundos
Medio 1 minuto
Grande 5 minutos
Gigante 1 hora
Enorme 8 horas

Si mides el sistema tal como está en la actualidad, podrás comprender cuánto tiempo suelen tardar estas solicitudes en ejecutarse. A modo de ejemplo, considera un sistema para procesar cargas de video. Si el video es demasiado largo, el tiempo de procesamiento debería demorar más tiempo. Podemos usar la duración del video en segundos para categorizar este trabajo en un bucket, como se muestra en la siguiente tabla. En la tabla, se registra la cantidad de solicitudes por bucket y varios percentiles por la distribución del tiempo de ejecución durante el transcurso de una semana.

Duración del video Cantidad de solicitudes medidas en un período de una semana 10% 90% 99.95%
Pequeño 0 - - -
Medio 1.9 millones 864 milisegundos 17 segundos 86 segundos
Grande 25 millones 1.8 segundos 52 segundos 9.6 minutos
Gigante 4.3 millones 2 segundos 43 segundos 23.8 minutos
Enorme 81,000 36 segundos 1.2 minutos 41 minutos

A partir de ese análisis, puedes obtener algunos parámetros para las alertas:

  • fast_typical: Como máximo, el 10% de las solicitudes son más rápidas que esta vez. Si hay demasiadas solicitudes más rápidas que este tiempo, los objetivos podrían ser incorrectos o puede que haya cambiado algo en tu sistema.
  • slow_typical: Como mínimo, el 90% de las solicitudes son más rápidas que esta vez. Este límite impulsa el SLO de latencia principal. Este parámetro indica si la mayoría de las solicitudes son lo suficientemente rápidas.
  • slow_tail: Como mínimo, el 99.95% de las solicitudes son más rápidas que esta vez. Este límite garantiza que no haya demasiadas solicitudes lentas.
  • deadline: El punto en el que se agota el tiempo de espera de una RPC o un procesamiento en segundo plano de usuario y falla (un límite que ya suele estar hard-coded en el sistema) Estas solicitudes no serán lentas, pero fallarán con un error y, en su lugar, se considerarán en el SLO de disponibilidad.

Un lineamiento sobre la definición de depósitos es mantener los valores fast_typical, slow_typical y slow_tail a un orden de magnitud de distancia uno de otro. Este lineamiento garantiza que no tengas un bucket demasiado amplio. Te recomendamos que no intentes evitar la superposición o la brecha entre los depósitos.

Bucket fast_typical slow_typical slow_tail deadline
Pequeño 100 milisegundos 1 segundo 10 segundos 30 segundos
Medio 600 milisegundos 6 segundos 60 segundos (1 minuto) 300 segundos
Grande 3 segundos 30 segundos 300 segundos (5 minutos) 10 minutos
Gigante 30 segundos 6 minutos 60 minutos (1 hora) 3 horas
Enorme 5 minutos 50 minutos 500 minutos (8 horas) 12 horas

Esto da como resultado una regla como api.method: SMALL => [1s, 10s]. En este caso, el sistema de seguimiento de SLO ve una solicitud, determina su bucket (podría analizar el nombre del método o URI y comparar el nombre con una tabla de consulta) y, luego, actualiza las estadísticas según el tiempo de ejecución de esa solicitud. Si esto demora 700 milisegundos, se encuentra dentro del objetivo slow_typical. Si es 3 segundos, está dentro de slow_tail. Si es 22 segundos, supera el valor de slow_tail, pero aún no es un error.

En términos de la satisfacción del usuario, puedes considerar la falta de latencia final como una falta de disponibilidad. (Es decir, la respuesta es tan lenta que debería considerarse como un error). Debido a esto, te sugerimos que uses el mismo porcentaje que usas para la disponibilidad, por ejemplo:

El 99.95% de todas las solicitudes se realizan en 10 segundos.

Tú decides qué considerarás como latencia típica. Algunos equipos de Google consideran que el 90% es un buen objetivo. Esto se relaciona con tu análisis y la forma en la que eliges las duraciones de slow_typical. Por ejemplo:

El 90% de todas las solicitudes se manejan en 1 segundo.

Alertas sugeridas

Dados estos lineamientos, en la siguiente tabla, se incluye un modelo de referencia recomendado de alertas de SLO.

SLO Período de mediciones Tasa de consumo Acción

Disponibilidad, consumo rápido

Latencia típica

Latencia final

Período de 1 hora Menos de 24 horas para la infracción del SLO Llama a alguien

Disponibilidad, consumo lento

Latencia típica, consumo lento

Latencia final, consumo lento

Período de 7 días Más de 24 horas para la infracción del SLO Crea un ticket

Las alertas de SLO son una habilidad que pueden demorar en desarrollarse. Las duraciones en esta sección son sugerencias; puedes ajustarlas según tus propias necesidades y el nivel de precisión. Usar tus alertas para el gasto de porcentaje de error aceptable o el período de medición puede ser útil, o puedes agregar otra capa de alertas entre el consumo rápido y el lento.

Genere observabilidad en su infraestructura y aplicaciones.

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para agregar observabilidad a los servicios, de modo que puedas comprender mejor el rendimiento del servicio y, también, identificar con rapidez los problemas. La observabilidad incluye la supervisión, el registro, el seguimiento, la generación de perfiles, la depuración y sistemas similares.

La supervisión es la base de la jerarquía de confiabilidad del servicio en el manual de SRE de Google. Sin una supervisión adecuada, no puedes saber si una aplicación funciona de forma correcta.

Instrumenta tu código para maximizar la observabilidad

Un sistema bien diseñado tiene como objetivo alcanzar una cantidad adecuada de observabilidad que comience en su fase de desarrollo. No esperes hasta que una aplicación esté en producción antes de comenzar a observarla. Instrumenta tu código y considera la siguiente guía:

  • Para depurar y solucionar problemas de manera eficiente, piensa en qué entradas de registro y seguimiento escribir y en qué métricas supervisar y exportar. Prioriza por los modos de falla más probables o frecuentes del sistema.
  • Audita y reduce la supervisión de forma periódica. Borra los paneles, grafos, alertas, seguimientos y registros sin usar o sin utilidad para eliminar el desorden.

Google Cloud Observability proporciona supervisión en tiempo real, supervisión y registro de múltiples nubes híbridas (como para AWS y Azure), más seguimiento, generación de perfiles y depuración. Google Cloud Observability también puede detectar y supervisar de forma automática los microservicios que se ejecutan en App Engine o en una malla de servicios como Istio.

Si generas muchos datos de aplicación, puedes optimizar la transferencia a gran escala de los registros de eventos de estadísticas con BigQuery. BigQuery también es adecuado para conservar y analizar datos de series temporales de alta cardinalidad desde el framework de supervisión. Este enfoque es útil porque te permite ejecutar consultas arbitrarias a un costo menor en lugar de intentar diseñar la supervisión sin problemas desde el principio, y separa los informes de la supervisión. Puedes crear informes a partir de los datos con Looker Studio o Looker.

Recomendaciones

Para aplicar la guía en el framework de arquitectura a tu propio entorno, sigue estas recomendaciones:

  • Implementa la supervisión temprano, antes de iniciar una migración o antes de implementar una aplicación nueva en un entorno de producción.
  • Distingue entre los problemas de la aplicación y los problemas subyacentes de la nube. Usa la API de Monitoring o cualquier otro producto de Cloud Monitoring y el Panel de estado de Google Cloud.
  • Define una estrategia de observabilidad más allá de la generación de perfiles que incluya el seguimiento, la generación de perfiles y la depuración.
  • Limpia con regularidad los artefactos de observabilidad que no usas o que no proporcionan valor, como las alertas no prácticas.
  • Si generas grandes cantidades de datos de observabilidad, envía eventos de aplicaciones a un sistema de almacén de datos como BigQuery.

¿Qué sigue?

Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la excelencia operativa, la seguridad, la privacidad y el cumplimiento.

Diseño para gran escala y alta disponibilidad

En este documento del framework de arquitectura de Google Cloud, se proporcionan principios de diseño para diseñar tus servicios a fin de que puedan tolerar fallas y escalar en respuesta a la demanda del cliente. Un servicio confiable continúa respondiendo a las solicitudes de los clientes cuando hay una demanda alta en el servicio o cuando hay un evento de mantenimiento. Los siguientes principios y prácticas recomendadas de diseño de confiabilidad deben ser parte de la arquitectura del sistema y el plan de implementación.

Crea redundancia para obtener una mayor disponibilidad

Los sistemas con necesidades con alta confiabilidad no deben tener puntos únicos de fallo, y sus recursos deben replicarse en varios dominios con fallas. Un dominio con fallas es un grupo de recursos que pueden fallar de forma independiente, como una instancia de VM, una zona o una región. Cuando replicaste entre dominios con fallas, obtendrás un nivel de disponibilidad agregado más alto que el de las instancias individuales. Para obtener más información, consulta Regiones y zonas.

Como ejemplo específico de la redundancia que podría ser parte de la arquitectura de tu sistema, para aislar fallas en el registro DNS de zonas individuales, usa nombres de DNS zonales para que las instancias de la misma red accedan entre sí.

Diseña una arquitectura de varias zonas con conmutación por error para alta disponibilidad.

A fin de hacer que tu aplicación sea resiliente a las fallas zonales, puedes diseñarla para usar grupos de recursos distribuidos en varias zonas con replicación de datos, balanceo de cargas y conmutación por error automatizada entre zonas. Ejecuta réplicas zonales de cada capa de la pila de aplicaciones y elimina todas las dependencias de varias zonas en la arquitectura.

Replica los datos entre las regiones para la recuperación ante desastres

Replica datos a una región remota o archívalos para habilitar la recuperación ante desastres en caso de una interrupción regional o pérdida de datos. Cuando se usa la replicación, la recuperación es más rápida porque los sistemas de almacenamiento en la región remota ya tienen datos que están casi actualizados, además de la posible pérdida de una pequeña cantidad de datos debido al retraso de la replicación. Cuando usas el archivado periódico en lugar de la replicación continua, la recuperación ante desastres implica restablecer los datos de las copias de seguridad o los archivos en una región nueva. Por lo general, este procedimiento genera un tiempo de inactividad del servicio más largo que la activación de una réplica de la base de datos actualizada de forma continua y podría implicar más pérdida de datos debido al intervalo entre las operaciones de copia de seguridad consecutiva. Cualquiera que sea el enfoque que se use, toda la pila de la aplicación se debe volver a implementar y, luego, iniciarse en la región nueva, y el servicio no estará disponible mientras esto suceda.

Si deseas obtener un análisis detallado de los conceptos y las técnicas de recuperación ante desastres, consulta Arquitectura de recuperación ante desastres para interrupciones de la infraestructura de nube.

Diseña una arquitectura multirregional para la resiliencia ante las interrupciones regionales.

Si tu servicio necesita ejecutarse de forma continua, incluso en el caso excepcional de que falle una región completa, diséñalo para que use grupos de recursos de procesamiento distribuidos en diferentes regiones. Ejecuta réplicas regionales de cada capa de la pila de aplicaciones.

Usa la replicación de datos entre regiones y la conmutación por error automática cuando una región deje de funcionar. Algunos servicios de Google Cloud tienen variantes multirregionales, como Spanner. Para resistir ante fallas regionales, usa estos servicios multirregión en tu diseño cuando sea posible. Para obtener más información sobre las regiones y la disponibilidad de servicios, consulta Ubicaciones de Google Cloud.

Asegúrate de que no haya dependencias entre regiones para que el impacto de una falla a nivel de región se limite a esa región.

Elimina puntos únicos de fallo regionales, como una base de datos principal de una sola región que puede causar una interrupción global cuando no se puede acceder a ella. Ten en cuenta que las arquitecturas multirregionales suelen costar más, así que ten en cuenta la necesidad empresarial en comparación con el costo antes de adoptar este enfoque.

Si deseas obtener más información para implementar la redundancia en los dominios con fallas, consulta el documento de la encuesta Arquetipos de implementación para aplicaciones en la nube (PDF).

Elimina los cuellos de botella de escalabilidad

Identifica los componentes del sistema que no pueden crecer más allá de los límites de recursos de una sola VM o zona. Algunas aplicaciones escalan de forma vertical, en las que agregas más núcleos de CPU, memoria o ancho de banda de red en una sola instancia de VM para manejar el aumento de carga. Estas aplicaciones tienen límites estrictos en cuanto a su escalabilidad, y debes configurarlas de forma manual para manejar el crecimiento.

Si es posible, rediseña estos componentes para escalar de forma horizontal, como con la fragmentación o la partición entre VM o zonas. Para manejar el crecimiento en el tráfico o el uso, agrega más fragmentos. Usa los tipos de VM estándar que se pueden agregar de forma automática para controlar los aumentos en la carga por fragmento. Para obtener más información, consulta Patrones de apps escalables y resilientes.

Si no puedes rediseñar la aplicación, puedes reemplazar los componentes que administras con los servicios en la nube completamente administrados que están diseñados para escalar de forma horizontal sin necesidad de acciones del usuario.

Disminuye los niveles de servicio correctamente cuando haya sobrecarga

Diseña tus servicios para tolerar la sobrecarga. Los servicios deben detectar la sobrecarga y mostrar respuestas de menor calidad al usuario o dejar de recibir tráfico de forma parcial, no fallar por completo bajo sobrecarga.

Por ejemplo, un servicio puede responder a las solicitudes de los usuarios con páginas web estáticas y, también, inhabilitar de forma temporal el comportamiento dinámico que es más costoso de procesar. Este comportamiento se detalla en el patrón de conmutación por error en caliente de Compute Engine a Cloud Storage. O bien, el servicio puede permitir operaciones de solo lectura e inhabilitar de forma temporal las actualizaciones de datos.

Se debe notificar a los operadores para que corrijan la condición de error cuando se degrada un servicio.

Evita y mitiga los aumentos repentinos de tráfico

No sincronices solicitudes entre clientes. Si demasiados clientes envían tráfico en el mismo instante, se provocarán aumentos repentinos de tráfico que pueden causar errores en cascada.

Implementa estrategias de mitigación de aumentos en el servidor, como la limitación, la cola, la reducción de carga o la interrupción de circuitos, la degradación elegante y la priorización de solicitudes críticas.

Las estrategias de mitigación en el cliente incluyen una limitación del lado del cliente y una retirada exponencial con jitter.

Limpia y valida las entradas

Para evitar entradas erróneas, aleatorias o maliciosas que causen interrupciones del servicio o violaciones a la seguridad, limpia y valida los parámetros de entrada para las API y las herramientas operativas. Por ejemplo, Apigee y Google Cloud Armor pueden ayudar a proteger contra ataques de inserción.

Usa pruebas Fuzz con regularidad, en las que un agente de prueba llama a las API de forma intencional con entradas aleatorias, vacías o demasiado grandes. Realiza estas pruebas en un entorno de pruebas aislado.

Las herramientas operativas deben validar automáticamente los cambios de configuración antes de su lanzamiento y deben rechazarlos si falla la validación.

Seguridad ante fallas, de manera que preserve la función

Si se produce una falla debido a un problema, los componentes del sistema deberían fallar de una manera que permita que todo el sistema siga funcionando. Estos problemas pueden ser un error de software, una entrada o configuración incorrectas, una interrupción de instancia no planificada o un error humano. El proceso de tus servicios ayuda a determinar si debes ser demasiado permisivo o demasiado simple, en lugar de demasiado restrictivo.

Considera las siguientes situaciones de ejemplo y cómo responder a una falla:

  • Por lo general, es mejor que un componente de firewall con una configuración incorrecta o vacía falle y permita que el tráfico de red no autorizado pase por un período corto mientras el operador corrige el error. Este comportamiento mantiene el servicio disponible, en lugar de fallar el cierre y bloquear el 100% del tráfico. El servicio debe confiar en las verificaciones de autenticación y autorización más profundas en la pila de aplicaciones para proteger las áreas sensibles mientras pasa todo el tráfico.
  • Sin embargo, es mejor que un componente del servidor de permisos que controle el acceso a los datos del usuario falle y bloquee todo el acceso. Este comportamiento provoca una interrupción del servicio cuando la configuración está dañada, pero evita el riesgo de una filtración de datos del usuario confidenciales si no se abre.

En ambos casos, la falla debería generar una alerta de prioridad alta para que un operador pueda corregir la condición de error. Los componentes del servicio deben fallar en el caso de errores abiertos, a menos que presenten riesgos extremos para la empresa.

Diseña las llamadas a la API y los comandos operativos para que puedan reintentarse.

Las API y las herramientas operativas deben hacer que las invocaciones sean seguras para el reintento en la medida de lo posible. Un enfoque natural para muchas condiciones de error es reintentar la acción anterior, pero es posible que no sepas si el primer intento se realizó de forma correcta.

La arquitectura del sistema debería realizar acciones idempotentes: si realizas la acción idéntica en un objeto dos o más veces seguidas, debería producir los mismos resultados que una invocación única. Las acciones no idempotentes requieren un código más complejo para evitar la corrupción del estado del sistema.

Identifica y administra dependencias de servicio

Los diseñadores y propietarios de servicios deben mantener una lista completa de dependencias de otros componentes del sistema. El diseño del servicio también debe incluir la recuperación ante fallas de dependencias o una degradación elegante si no se puede realizar la recuperación completa. Ten en cuenta las dependencias de los servicios en la nube que usan tu sistema y las dependencias externas, como las API de servicio de terceros, que reconocen que cada dependencia del sistema tiene una tasa de fallas distinta de cero.

Cuando configures los objetivos de confiabilidad, reconoce que el SLO de un servicio está restringido de forma matemática por los SLO de todas sus dependencias críticas. No puedes ser más confiable que el SLO más bajo de una de las dependencias. Para obtener más información, consulta el cálculo de la disponibilidad del servicio.

Dependencias de inicio

Los servicios se comportan de manera diferente cuando se inician en comparación con su comportamiento de estado estable. Las dependencias de inicio pueden diferir de forma significativa de las dependencias de entorno de ejecución de estado estable.

Por ejemplo, durante el inicio, un servicio puede necesitar cargar información del usuario o de la cuenta de un servicio de metadatos del usuario que rara vez invoca. Cuando muchas réplicas de servicio se reinician después de una falla o mantenimiento de rutina, las réplicas pueden aumentar considerablemente la carga en las dependencias de inicio, en especial cuando las memorias caché están vacías y deben volver a propagarse.

Prueba el inicio del servicio con carga y aprovisiona las dependencias de inicio según corresponda. Considera un diseño para degradar con facilidad mediante el guardado de una copia de los datos que recupera de las dependencias de inicio críticas. Este comportamiento permite que tu servicio se reinicie con datos potencialmente obsoletos, en lugar de no poder iniciarse cuando una dependencia crítica tiene una interrupción. El servicio puede cargar datos nuevos, cuando sea posible, para volver a su funcionamiento normal.

Las dependencias de inicio también son importantes cuando inicias un servicio en un entorno nuevo. Diseña tu pila de aplicaciones con una arquitectura en capas, sin dependencias cíclicas entre capas. Las dependencias cíclicas pueden parecer tolerables porque no bloquean los cambios incrementales en una sola aplicación. Sin embargo, las dependencias cíclicas pueden hacer que sea difícil o imposible reiniciar después de un desastre que elimina toda la pila de servicios.

Minimiza las dependencias críticas

Minimiza la cantidad de dependencias críticas de tu servicio, es decir, otros componentes cuya falla generará inevitablemente interrupciones del servicio. Para que tu servicio sea más resiliente a las fallas o la lentitud en otros componentes de los que depende, ten en cuenta los siguientes principios y técnicas de diseño de ejemplo a fin de convertir dependencias críticas en dependencias no críticas:

  • Aumenta el nivel de redundancia en las dependencias críticas. Agregar más réplicas disminuye la probabilidad de que un componente completo no esté disponible.
  • Usa solicitudes asíncronas en otros servicios en lugar de bloquear una respuesta o usa mensajes de publicación o suscripción para separar las solicitudes de las respuestas.
  • Almacena en caché las respuestas de otros servicios para realizar recuperaciones de la falta de disponibilidad a corto plazo de las dependencias.

A fin de que las fallas de tu servicio sean menos perjudiciales para otros componentes que dependen de él, ten en cuenta los siguientes principios y técnicas de diseño de ejemplo:

  • Usa colas de solicitudes priorizadas y otorga mayor prioridad a las solicitudes en las que un usuario espera una respuesta.
  • Entrega respuestas desde una caché para reducir la latencia y la carga.
  • Seguridad ante fallas, de manera que preserve la función
  • Disminuir fácilmente cuando hay una sobrecarga de tráfico.

Asegúrate de que todos los cambios puedan revertirse

Si no hay una forma bien definida de deshacer ciertos tipos de cambios en un servicio, cambia el diseño del servicio para admitir la reversión. Prueba los procesos de reversión de forma periódica. Las API para cada componente o microservicio deben tener versiones, con retrocompatibilidad de modo que las generaciones anteriores de clientes sigan funcionando de forma correcta a medida que la API evoluciona. Este principio de diseño es esencial para permitir el lanzamiento progresivo de cambios de API, con reversión rápida cuando es necesario.

La reversión puede ser costosa a fin de implementarse en aplicaciones para dispositivos móviles. Firebase Remote Config es un servicio de Google Cloud para facilitar la reversión de funciones.

No puedes revertir los cambios en el esquema de la base de datos con facilidad, por lo que debes ejecutarlos en varias fases. Diseña cada fase para permitir la lectura segura del esquema y actualizar las solicitudes según la última versión de tu aplicación y la anterior. Este enfoque de diseño te permite revertir de forma segura si hay un problema con la versión más reciente.

Recomendaciones

Para aplicar la guía en el framework de arquitectura a tu propio entorno, sigue estas recomendaciones:

  • Implementa una retirada exponencial con aleatorización en la lógica de reintento de error de las aplicaciones cliente.
  • Implementa una arquitectura multirregional con conmutación por error automática para obtener alta disponibilidad.
  • Usa el balanceo de cargas para distribuir las solicitudes de los usuarios en fragmentos y regiones.
  • Diseña la aplicación para que se degrade bajo sobrecarga con facilidad. Entrega respuestas parciales o proporciona funciones limitadas en lugar de fallar por completo.
  • Establecer un proceso basado en datos para la planificación de capacidad y usar pruebas de carga y previsiones del tráfico a fin de determinar cuándo aprovisionar recursos.
  • Establece procedimientos de recuperación ante desastres y pruébalos de forma periódica.

¿Qué sigue?

Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Crea herramientas y procesos operativos confiables

En este documento del framework de arquitectura de Google Cloud, se proporcionan principios operativos para ejecutar el servicio de manera confiable, como implementar actualizaciones, ejecutar servicios en entornos de producción y probar fallas. La arquitectura para la confiabilidad debe abarcar todo el ciclo de vida del servicio, no solo el diseño de software.

Elige buenos nombres para aplicaciones y servicios

Evita usar nombres de código internos en los archivos de configuración de producción, ya que pueden ser confusos, en especial para los empleados más nuevos, lo que podría aumentar el tiempo de mitigación (TTM) para las interrupciones. En la medida de lo posible, elige buenos nombres para todas tus aplicaciones, servicios y recursos críticos del sistema, como VM, clústeres e instancias de bases de datos, sujetos a sus respectivos límites de longitud. Un buen nombre describe el propósito de la entidad. que sea preciso, específico y distintivo, y es significativo para cualquier persona que lo vea. Un buen nombre evita los acrónimos, los nombres internos, las abreviaturas y la terminología potencialmente ofensiva, y no crea una respuesta pública negativa incluso si se publica de forma externa.

Implementa lanzamientos progresivos con pruebas canary

Los cambios globales instantáneos en la configuración o los objetos binarios del servicio son riesgosos por naturaleza. Lanza versiones nuevas de ejecutables y cambios de configuración de forma incremental. Comienza con un permiso pequeño, como unas pocas instancias de VM en una zona, y expande el alcance de manera gradual. Revierte con rapidez si el cambio no funciona como se espera o si afecta de manera negativa a los usuarios en cualquier etapa del lanzamiento Tu objetivo es identificar y abordar los errores cuando solo afectan una pequeña parte del tráfico de usuarios, antes de lanzar el cambio a nivel global.

Configura un sistema de pruebas canary que esté al tanto de los cambios de servicio y realice una comparación A/B de las métricas de los servidores modificados con los servidores restantes. El sistema debe marcar un comportamiento inesperado o anómalo. Si el cambio no tiene el rendimiento que esperas, el sistema de pruebas canary debe detener de forma automática los lanzamientos. Los problemas pueden ser claros, como errores de usuario, o sutiles, como el aumento de uso de CPU o el aumento de memoria.

Es mejor detener y revertir la primera sugerencia de problemas y diagnosticar problemas sin la presión de tiempo de una interrupción. Después de que el cambio pase las pruebas canary, propágalo a alcances más grandes de forma gradual, como una zona completa y, luego, a una segunda zona. Espera tiempo para que el sistema modificado controle volúmenes de tráfico de usuario cada vez más grandes para exponer cualquier error latente.

Para obtener más información, consulta Estrategias de implementación y prueba de aplicaciones.

Distribuye el tráfico para las promociones y los lanzamientos programados

Puedes tener eventos promocionales, como ventas que comienzan en un momento preciso y alentar a muchos usuarios a conectarse al servicio en simultáneo. Si es así, diseña el código del cliente para que distribuya el tráfico en unos segundos. Usa retrasos aleatorios antes de iniciar solicitudes.

También puedes hacer una preparación previa del sistema. Cuando haces una preparación previa del sistema, envías el tráfico del usuario que anticipas con antelación para asegurarte de que funcione como esperas. Este enfoque evita aumentos repentinos de tráfico instantáneos que podrían causar fallas en los servidores a la hora de inicio programada.

Automatiza la compilación, la prueba y la implementación

Elimina el esfuerzo manual de tu proceso de lanzamiento con canalizaciones de integración continua y entrega continua (CI/CD). Realiza implementaciones y pruebas de integración automatizadas. Por ejemplo, crea un proceso moderno de CI/CD con Anthos.

Para obtener más información, consulta integración continua, entrega continua, automatización de pruebas y automatización de implementaciones.

Defiéndase contra errores del operador

Diseña tus herramientas operativas para rechazar configuraciones potencialmente no válidas. Detecta y alerta cuando una versión de configuración esté vacía, sea parcial o esté truncada, esté dañada, sea incorrecta o inesperado de forma lógica, o no se haya recibido dentro del tiempo esperado. Las herramientas también deben rechazar las versiones de configuración que difieren demasiado de la versión anterior.

No permitas cambios o comandos con un alcance demasiado amplio que pueda ser destructivo. Estos comandos amplios pueden ser “Revocar permisos para todos los usuarios”, “Reiniciar todas las VM de esta región” o “Volver a formatear todos los discos de esta zona”. Estos cambios solo deben aplicarse si el operador agrega la función experimental de línea de comandos de anulación de emergencia o ajustes de opciones cuando implementan la configuración.

Las herramientas deben mostrar la amplitud del impacto de los comandos arriesgados, como la cantidad de VM que afectan el cambio, y requerir una confirmación explícita del operador antes de que la herramienta continúe. También puedes usar funciones para bloquear recursos críticos y evitar su eliminación accidental o no autorizada, como los bloqueos de políticas de retención de Cloud Storage.

Prueba la recuperación de errores

Prueba tus procedimientos operativos con regularidad para recuperarte de las fallas en el servicio. Sin pruebas regulares, es posible que los procedimientos no funcionen cuando los necesites si hay una falla real. Los elementos que se deben probar de forma periódica incluyen la conmutación por error regional, la manera de revertir una actualización y de restablecer los datos de las copias de seguridad.

Realiza pruebas de recuperación ante desastres

Al igual que con las pruebas de recuperación ante fallas, no esperes a que ocurra un desastre. Prueba y verifica de forma periódica los procedimientos y procesos de recuperación ante desastres.

Puedes crear una arquitectura de sistema para proporcionar alta disponibilidad (HA). Esta arquitectura no se superpone por completo con la recuperación ante desastres (DR), pero a menudo es necesario tener en cuenta la HA cuando piensas en los valores de los objetivos de tiempo de recuperación (RTO) y de los objetivos de punto de recuperación (RPO). .

La HA te ayuda a alcanzar o superar un nivel acordado de rendimiento operativo, como el tiempo de actividad. Cuando ejecutas cargas de trabajo de producción en Google Cloud, puedes implementar una instancia en espera pasiva o activa en una segunda región. Con esta arquitectura, la aplicación continúa brindando servicio de la región no afectada si hay un desastre en la región principal. Si deseas obtener más información, consulta Arquitectura de recuperación ante desastres para interrupciones de nube.

Practica la ingeniería de caos

Considera el uso de la ingeniería de caos en tus prácticas de prueba. Ingresa fallas reales en diferentes componentes de los sistemas de producción bajo carga en un entorno seguro. Este enfoque ayuda a garantizar que no haya un impacto general en el sistema porque el servicio maneja las fallas de forma correcta en cada nivel.

Las fallas que inyectas en el sistema pueden incluir tareas fallidas, errores y tiempos de espera en RPC, o reducciones en la disponibilidad de recursos. Usa la inserción de errores aleatorios para probar fallas intermitentes (oscilación) en las dependencias del servicio. Estos comportamientos son difíciles de detectar y mitigar en la producción.

La ingeniería del caos garantiza que las consecuencias de esos experimentos se minimicen y contengan. Trata esas pruebas como práctica para las interrupciones reales y usa toda la información recopilada a fin de mejorar la respuesta de la interrupción.

¿Qué sigue?

Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Crea alertas eficientes

En este documento del framework de arquitectura de Google Cloud, se proporcionan principios operativos para crear alertas que te ayudarán a ejecutar servicios confiables. Cuanta más información tengas sobre el rendimiento de tu servicio, más fundamentadas estarán las decisiones cuando haya un problema. Diseña tus alertas para la detección temprana y exacta de todos los problemas del sistema que afectan a los usuarios y minimiza los falsos positivos.

Optimiza el retraso de las alertas

Existe un equilibrio entre las alertas que se envían demasiado pronto que sobrecargan al equipo de operaciones y las alertas que se envían demasiado tarde y causan interrupciones prolongadas en el servicio. Ajusta el retraso de las alertas antes de que el sistema de supervisión notifique a las personas sobre un problema a fin de minimizar el tiempo de detección y maximizar la señal en comparación con el ruido. Usa la tasa de consumo del porcentaje de error aceptable para derivar la configuración de alertas óptima.

Alerta sobre los síntomas en lugar de las causas

Activa alertas según el impacto directo en la experiencia del usuario. El incumplimiento de los SLO globales o por cliente indica un impacto directo. No crees alertas sobre todas las causas raíz posibles de una falla, en especial cuando el impacto se limita a una sola réplica. Un sistema distribuido bien diseñado se recupera sin problemas de las fallas de una sola réplica.

Alertar sobre valores atípicos en lugar de promedios

Cuando supervises la latencia, define los SLO y establece alertas para la latencia del percentil 90, 95 o 99 (elige dos de tres), no para la latencia promedio ni el percentil 50. Los valores buenos de latencia media o mediana pueden ocultar valores demasiado altos en el percentil 90 o superior que causan experiencias muy malas del usuario. Por lo tanto, debes aplicar este principio de alertas sobre valores atípicos cuando supervisas la latencia para cualquier operación crítica, como una interacción solicitud-respuesta con un servidor web, la finalización por lotes en una canalización de procesamiento de datos o una operación de lectura o escritura en un servicio de almacenamiento.

Compila un proceso colaborativo de administración de incidentes

En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para administrar servicios y definir procesos para responder a los incidentes. Los incidentes ocurren en todos los servicios, por lo que necesitas un proceso bien documentado para responder a estos problemas de manera eficiente y mitigarlos.

Descripción general de la administración de incidentes

Será inevitable que, en el futuro, el sistema bien diseñado presente fallas en sus SLO. Ante la ausencia de un SLO, los clientes pueden definir de manera flexible cuál es el nivel de servicio aceptable en función de su experiencia pasada. Los clientes escalan al grupo de asistencia técnica o a un grupo similar, sin importar lo que incluya tu ANS.

Para brindar un servicio adecuado a tus clientes, establece y prueba con regularidad un plan de administración de incidentes. El plan puede ser tan breve como una lista de tareas de una sola página con diez elementos. Este proceso ayuda a tu equipo a reducir el tiempo de detección (TTD) y el tiempo de mitigación (TTM).

Se prefiere TTM a diferencia de TTR, donde la R para reparación o recuperación se suele usar para hacer referencia a una corrección completa en comparación con una mitigación. TTM destaca la mitigación rápida para finalizar con rapidez el impacto en el cliente de una interrupción y, luego, iniciar el proceso, a menudo, mucho más largo, para solucionar el problema por completo.

Un sistema bien diseñado en el que las operaciones sean excelentes aumentará el tiempo entre fallas (TBF). En otras palabras, los principios operativos de la confiabilidad, incluida una buena administración de incidentes, buscan lograr que las fallas sean menos frecuentes.

Para ejecutar servicios confiables, aplica las siguientes prácticas recomendadas en el proceso de administración de incidentes.

Asigna una propiedad clara del servicio

Todos los servicios y sus dependencias críticas deben tener propietarios claros responsables de cumplir con sus SLO. Si hay reorganizaciones o abandono de equipos, el líder debe asegurarse de que la propiedad se transfiera de forma explícita a un equipo nuevo, junto con la documentación y la capacitación, según sea necesario. Los otros equipos deben poder detectar con facilidad a los propietarios de un servicio.

Reduce el tiempo de detección (TTD) con alertas bien ajustadas

Antes de poder reducir el TTD, revisa y, luego, implementa las recomendaciones que figuran en las secciones Agrega observabilidad a la infraestructura y las aplicaciones y Define tus objetivos de confiabilidad de la categoría de confiabilidad del framework de arquitectura. Por ejemplo, puedes distinguir entre los problemas de la aplicación y los problemas subyacentes de la nube.

Un conjunto de SLI bien ajustado alerta a tu equipo en el momento adecuado sin generar una sobrecarga de alertas. Para obtener más información, consulta la sección Crea alertas eficientes de la categoría de confiabilidad del framework de arquitectura o Ajusta tus métricas de SLI: lecciones de CRE.

Reduce el tiempo de mitigación (TTM) con los planes de administración de incidentes y el entrenamiento.

Para reducir el TTM, define un plan de administración de incidentes documentado y bien implementado. Ten datos disponibles sobre los cambios en el entorno. Asegúrate de que los equipos conozcan las mitigaciones genéricas que puedan aplicar con rapidez para minimizar el TTM. Estas técnicas de mitigación incluyen el desvío, la reversión de cambios, el aumento de tamaño de los recursos y la degradación de la calidad del servicio.

Como se explicó en otro documento del pilar de confiabilidad del framework de arquitectura, crea herramientas y procesos operativos confiables para admitir la reversión segura y rápida de cambios.

Crea diseños y contenido para el panel para minimizar el TTM

Organiza la navegación y el diseño del panel de servicio de modo que un operador pueda determinar en un minuto o dos si el servicio y todas sus dependencias críticas están en ejecución. Para identificar con rapidez las posibles causas de los problemas, los operadores deben poder analizar todos los gráficos en el panel para detectar con rapidez los gráficos que cambian de manera significativa en el momento de la alerta.

Es posible que la siguiente lista de gráficos de ejemplo se encuentre en el panel para ayudarte a solucionar problemas. Los encargados de ofrecer respuestas ante incidentes deben poder verlos en una sola vista:

  • Indicadores de nivel de servicio, como solicitudes exitosas divididas por el total de solicitudes válidas
  • Configuración y lanzamientos de objetos binarios
  • Solicitudes por segundo al sistema
  • Respuestas de error por segundo desde el sistema
  • Solicitudes por segundo del sistema a sus dependencias
  • Respuestas de error por segundo al sistema desde sus dependencias

Otros gráficos comunes que ayudan a solucionar problemas son la latencia, la saturación, el tamaño de la solicitud, el tamaño de la respuesta, el costo de la consulta, el uso del conjunto de subprocesos y las métricas de la máquina virtual de Java (JVM) (cuando corresponda). La saturación hace referencia a la capacidad total según algún límite, como el tamaño de la cuota o de la memoria del sistema. El uso del conjunto de subprocesos busca regresiones debido al agotamiento del grupo.

Prueba la ubicación de estos gráficos en algunas situaciones de interrupción para asegurarte de que los gráficos más importantes estén cerca de la parte superior y de que el orden de los gráficos coincida con tu flujo de trabajo de diagnóstico estándar. También puedes aplicar el aprendizaje automático y la detección de anomalías estadísticas para mostrar el subconjunto correcto de estos gráficos.

Documenta los procedimientos de diagnóstico y la mitigación para situaciones de interrupciones conocidas

Escribe guías y vincula las notificaciones de alertas. Si se puede acceder a estos documentos desde las notificaciones de alerta, los operadores pueden obtener con rapidez la información que necesitan para solucionar problemas y mitigar los problemas.

Usa los análisis retrospectivos libres de responsabilidad para obtener información sobre las interrupciones y evitar las recurrencias

Establece una cultura libre de responsabilidades a posteriori y un proceso de revisión de incidentes. Libre de responsabilidades significa que tu equipo evalúa y documenta lo que salió mal de manera objetiva sin necesidad de culpar a nadie.

Los errores son oportunidades de aprendizaje y no un motivo de crítica. Siempre intenta que el sistema sea más resiliente para que pueda recuperarse con rapidez de los errores humanos o, incluso mejor, detectarlos y prevenirlos. Extrae tanto aprendizaje como sea posible de cada proceso postmortem y haz un seguimiento diligente de cada elemento de acción postmortem para hacer que las interrupciones sean menos frecuentes, lo que aumenta el TBF.

Ejemplo de un plan de administración de incidentes

Se detectaron problemas de producción como, por ejemplo, a través de una alerta o una página, o se escalaron:

  • ¿Debo delegar a alguien más?
    • Sí, si tú y tu equipo no pueden resolver el problema.
  • ¿Es un problema de la privacidad o la violación de la seguridad?
    • Si la respuesta es sí, delega la cuestión al equipo de privacidad o seguridad.
  • ¿Este problema es una emergencia o están en riesgo los SLO?
    • Si tienes dudas, trata la situación como si fuera una emergencia.
  • ¿Debo involucrar a más personas?
    • Sí, si afecta a más del X% de los clientes o si toma más de Y minutos en resolverse. Si tienes dudas, siempre debes involucrar a más personas, en especial durante el horario de atención.
  • Define un canal de comunicación principal, como IRC, Hangouts Chat o Slack.
  • Delega funciones definidas con anterioridad, como las siguientes:
    • Comandante de incidentes que es responsable de la coordinación general.
    • Líder de comunicaciones que es responsable de las comunicaciones internas y externas.
    • Líder de operaciones que es responsable de mitigar el problema.
  • Define la finalización del incidente. Es posible que esta decisión se requiera la confirmación de un representante del equipo de asistencia o de otros equipos similares.
  • Colabora en el proceso libre de responsabilidades a posteriori.
  • Asiste a reuniones de revisión de incidentes a posteriori para ofrecerle al personal elementos de acción y debatirlos.

Recomendaciones

Para aplicar la guía en el framework de arquitectura a tu propio entorno, sigue estas recomendaciones:

¿Qué sigue?

Obtén más información sobre cómo compilar un proceso colaborativo de administración de incidentes con los siguientes recursos:

Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.

Framework de la arquitectura de Google Cloud: Guías de confiabilidad de productos

En esta sección del framework de arquitectura, se incluye una guía de prácticas recomendadas específicas del producto para la confiabilidad, la disponibilidad y la coherencia de algunos productos de Google Cloud. En las guías, también se proporcionan recomendaciones a fin de minimizar y recuperarse de las fallas y escalar bien las aplicaciones con carga.

Las guías de confiabilidad de productos se organizan en las siguientes áreas:

Guía de confiabilidad de Compute Engine

Compute Engine es un servicio de procesamiento personalizable que permite a los usuarios crear y ejecutar máquinas virtuales a pedido en la infraestructura de Google.

prácticas recomendadas

Guía de confiabilidad de Cloud Run

Cloud Run es una plataforma de procesamiento administrada adecuada para implementar aplicaciones en contenedores y sin servidores. Cloud Run simplifica la infraestructura para que los usuarios puedan enfocarse en compilar aplicaciones.

prácticas recomendadas

  • Sugerencias generales de Cloud Run: Cómo implementar un servicio de Cloud Run, iniciar contenedores con rapidez, usar variables globales y mejorar la seguridad de los contenedores.
  • Prácticas recomendadas para las pruebas de carga: Cómo realizar pruebas de carga de los servicios de Cloud Run, lo que incluye solucionar problemas de simultaneidad antes de las pruebas de carga, administrar la cantidad máxima de instancias, elegir la mejor región para las pruebas de carga y garantizar que los servicios escalen con las cargas.
  • Escalamiento de instancias: Cómo escalar y limitar las instancias de contenedor y minimizar el tiempo de respuesta, para lo cual se deben mantener algunas instancias inactivas en lugar de detenerlas.
  • Usa una cantidad mínima de instancias: Especifica la cantidad mínima de instancias de contenedor listas para entregar y, cuando se configure una cantidad apropiadamente alta, minimiza el tiempo de respuesta promedio mediante la reducción del número de inicios en frío.
  • Optimiza las aplicaciones de Java para Cloud Run: Comprende las compensaciones de algunas optimizaciones para los servicios de Cloud Run escritos en Java y reduce el tiempo de inicio y el uso de memoria.
  • Optimiza las aplicaciones de Python para Cloud Run: optimiza la imagen del contenedor mediante la mejora de la eficiencia del servidor WSGI y optimiza las aplicaciones mediante la reducción de la cantidad de subprocesos y la ejecución de tareas de inicio en paralelo.

Guía de confiabilidad de Cloud Functions

Cloud Functions es una plataforma escalable, sin servidores y basada en eventos para ayudar a compilar y conectar servicios. Se puede llamar a las funciones de Cloud Functions a través de una solicitud HTTP o se puede activar en función de eventos en segundo plano.

prácticas recomendadas

Guía de confiabilidad de Google Kubernetes Engine

Google Kubernetes Engine (GKE) es un sistema para operar aplicaciones en contenedores en la nube a gran escala. GKE implementa, administra y aprovisiona recursos para tus aplicaciones en contenedores. El entorno de GKE consiste en instancias de Compute Engine agrupadas para formar un clúster.

prácticas recomendadas

  • Prácticas recomendadas para trabajar con contenedores: cómo usar mecanismos de registro, garantizar que los contenedores no tengan estado y sean inmutables, supervisar aplicaciones, y realizar sondeos de funcionamiento y preparación.
  • Prácticas recomendadas para compilar contenedores: Cómo empaquetar una sola aplicación por contenedor, controlar identificadores de procesos (PID), optimizar para la caché de compilación de Docker y compilar imágenes más pequeñas a fin de lograr tiempos de carga y descarga más rápidos.
  • Prácticas recomendadas para las herramientas de redes de Google Kubernetes Engine: Usa clústeres nativos de la VPC para facilitar el escalamiento, planifica las direcciones IP, escala la conectividad del clúster, usa Google Cloud Armor para bloquear ataques de denegación de servicio distribuido (DDoS), implementa el balanceo de cargas nativo del contenedor para lograr una latencia más baja, usa la funcionalidad de verificación de estado de los balanceadores de cargas de aplicaciones externos para lograr una conmutación por error correcta y usa clústeres regionales para aumentar la disponibilidad de las aplicaciones en un clúster.
  • Prepara aplicaciones de Kubernetes basadas en la nube: conoce las prácticas recomendadas para planificar la capacidad de la aplicación, hacer crecer la aplicación de forma horizontal o vertical, establecer límites de recursos relacionados con las solicitudes de recursos de memoria y CPU, y hacer que los contenedores sean más rápidos para iniciar las aplicaciones más rápido. y limitar la interrupción Pod mediante la configuración de un Pod Disruption Budget (PDB). Además, aprende a configurar sondeos de funcionamiento y sondeos de preparación para un inicio ordenado de la aplicación, garantizar cierres no disruptivos e implementar una retirada exponencial en las solicitudes que se reintentaron a fin de evitar aumentos repentinos de tráfico que sobrecarguen tu aplicación.
  • Prácticas recomendadas para la arquitectura multiusuario de GKE: cómo diseñar una arquitectura de clúster multiusuario para alta disponibilidad y confiabilidad, usar la medición de uso de Google Kubernetes Engine (GKE) para las métricas de uso por usuario, proporcionar registros específicos de usuario y proporcionar supervisión específica de usuarios.

Guía de confiabilidad de Cloud Storage

Cloud Storage es un repositorio de objetos duradero y con alta disponibilidad con funciones avanzadas de seguridad y uso compartido. Este servicio se usa para almacenar y acceder a los datos en la infraestructura de Google Cloud.

prácticas recomendadas

  • Prácticas recomendadas para Cloud Storage: Prácticas recomendadas generales para Cloud Storage, que incluyen sugerencias a fin de maximizar la disponibilidad y minimizar la latencia de tus aplicaciones, mejorar la confiabilidad de las operaciones de carga y mejorar el rendimiento de las eliminaciones de datos a gran escala.
  • Lineamientos de distribución de acceso y porcentaje de solicitudes: Cómo minimizar la latencia y las respuestas de error en las operaciones de lectura, escritura y eliminación a tasas de solicitud muy altas, mediante la comprensión de cómo funciona el escalamiento automático de Cloud Storage.

Guía de confiabilidad de Firestore

Firestore es una base de datos de documentos NoSQL que te permite almacenar, sincronizar y consultar datos en tus aplicaciones web y para dispositivos móviles a escala global.

prácticas recomendadas

  • Prácticas recomendadas de Firestore: Cómo seleccionar la ubicación de la base de datos para aumentar la confiabilidad, minimizar los errores de rendimiento en la indexación, mejorar el rendimiento de las operaciones de lectura y escritura, reducir la latencia para las notificaciones de cambios y el diseño para gran escala.

Guía de confiabilidad de Bigtable

Bigtable es una base de datos NoSQL escalable y completamente administrada para grandes cargas de trabajo de análisis y operativas. Está diseñada como una tabla propagada de manera dispersa que puede escalar a miles de millones de filas y miles de columnas, y admite una alta capacidad de procesamiento de lectura y escritura con baja latencia.

prácticas recomendadas

  • Comprender el rendimiento de Bigtable: cómo estimar la capacidad de procesamiento de Bigtable, cómo planificar la capacidad de Bigtable si miras la capacidad de procesamiento y el uso del almacenamiento, cómo la habilitación de la replicación afecta la capacidad de procesamiento de lectura y escritura de manera diferente y cómo Bigtable optimiza los datos con el tiempo.
  • Diseño de esquemas de Bigtable: orientación sobre el diseño de esquemas de Bigtable, incluidos los conceptos de almacén de pares clave-valor, el diseño de claves de fila según las solicitudes de lectura planificadas, el manejo de columnas y filas, y los casos de uso especiales.
  • Descripción general de la replicación en Bigtable: Cómo replicar Bigtable en varias zonas o regiones, comprender las implicaciones de rendimiento de la replicación y cómo Bigtable resuelve conflictos y controla las conmutaciones por error.
  • Acerca de las copias de seguridad de Bigtable: cómo guardar una copia del esquema y los datos de una tabla con las copias de seguridad de Bigtable, que pueden ayudarte a recuperarte de una corrupción de datos a nivel de la aplicación o de errores de operadores, como borrar una tabla por accidente.

Guía de confiabilidad de Cloud SQL

Cloud SQL es un servicio de base de datos relacional completamente administrado para MySQL, PostgreSQL y SQL Server. Cloud SQL se integra con facilidad en las aplicaciones y los servicios de Google Cloud existentes, como Google Kubernetes Engine y BigQuery.

prácticas recomendadas

Guía de confiabilidad de Spanner

Spanner es un servicio distribuido de almacenamiento y administración de bases de datos SQL, con funciones como transacciones globales y escalamiento horizontal con alta disponibilidad y coherencia transaccional.

prácticas recomendadas

  • Copia de seguridad y restablecimiento de Spanner: funciones clave de copia de seguridad y restablecimiento de Spanner, comparación entre copias de seguridad y restablecimiento con importación y exportación, detalles de implementación y cómo controlar el acceso a los recursos de Spanner.
  • Configuraciones regionales y multirregionales: Descripción de los dos tipos de configuraciones de instancias que ofrece Spanner: configuraciones regionales y multirregionales. La descripción incluye las diferencias y los pros y contras entre cada configuración.
  • Ajuste de escala automático de Spanner: Introducción a la herramienta Escalador automático para Spanner (Escalador automático), una herramienta de código abierto que puedes usar como herramienta complementaria de Cloud Spanner. Esta herramienta te permite aumentar o reducir de forma automática la cantidad de nodos o unidades de procesamiento en una o más instancias de Spanner según las métricas de uso de cada una.
  • Acerca de la recuperación de un momento determinado (PITR): Descripción de la recuperación de un momento determinado (PITR) de Spanner, una función que protege contra la eliminación o escritura accidental de los datos de Spanner. Por ejemplo, un operador escribe datos de forma inadvertida o el lanzamiento de una aplicación daña la base de datos. Con la PITR, puedes recuperar tus datos desde un momento determinado en el pasado (hasta siete días) sin problemas.
  • Prácticas recomendadas de Spanner: orientación sobre la carga masiva mediante el lenguaje de manipulación de datos (DML), el diseño de esquemas para evitar hotspots, y prácticas recomendadas de SQL.

Guía de confiabilidad de Filestore

Filestore es un servicio de almacenamiento de archivos administrado destinado a aplicaciones de Google Cloud, con una interfaz de sistema de archivos y un sistema de archivos compartidos para datos. Filestore proporciona almacenamiento conectado a la red (NAS) en línea con escala de petabytes para instancias de Compute Engine y Google Kubernetes Engine.

prácticas recomendadas

  • Rendimiento de Filestore: recomendaciones de configuración de rendimiento y de tipo de máquina de Compute Engine, opciones de activación de NFS para un mejor rendimiento en instancias de VM de cliente de Linux y uso de la herramienta fio para probar el rendimiento. Incluye recomendaciones para mejorar el rendimiento en varios recursos de Google Cloud.

  • Copias de seguridad de Filestore: descripción de las copias de seguridad de Filestore, casos prácticos comunes y prácticas recomendadas para crear y usar copias de seguridad.

  • Instantáneas de Filestore: descripción de las instantáneas de Filestore, casos prácticos comunes y prácticas recomendadas para crear y usar instantáneas.

  • Herramientas de redes de Filestore: requisitos de red y de recursos IP necesarios para usar Filestore.

Guía de confiabilidad de Memorystore

Memorystore es un almacén en memoria completamente administrado que proporciona una versión administrada de dos soluciones de almacenamiento en caché de código abierto: Redis y Memcached. Memorystore es escalable y automatiza las tareas complejas, como el aprovisionamiento, la replicación, la conmutación por error y los parches.

prácticas recomendadas

  • Prácticas recomendadas generales de Redis: Guía para exportar copias de seguridad de bases de datos de Redis (RDB), operaciones de uso intensivo de recursos y operaciones que requieren un reintento de conexión. Además, brinda información sobre el mantenimiento, la administración de memoria y la configuración del conector de Acceso a VPC sin servidores, así como el modo de conexión de acceso a servicios privados, la supervisión y las alertas.
  • Prácticas recomendadas para la administración de memoria de Redis: Conceptos de administración de memoria, como capacidad de la instancia y configuración de Maxmemory, operaciones de exportación, escalamiento y actualización de versión, métricas de administración de memoria y cómo resolver una memoria insuficiente.
  • Retirada exponencial de Redis: Cómo funciona la retirada exponencial, un algoritmo de ejemplo y cómo funcionan la retirada máxima y la cantidad máxima de reintentos.
  • Prácticas recomendadas de Memcached: Cómo diseñar una aplicación para errores de caché, conectarse directamente a las direcciones IP de nodos y el servicio de descubrimiento automático de Memcached. Además, orientación sobre la configuración del parámetro max-item-size, el balanceo de clústeres y el uso de Cloud Monitoring para supervisar las métricas esenciales.
  • Prácticas recomendadas para la administración de memoria de Memcached: Configura la memoria para una instancia de Memcached, configuración de la memoria reservada, cuándo aumentar la memoria reservada y las métricas del uso de memoria.

Guía de confiabilidad de Cloud DNS

Cloud DNS es un sistema de nombres de dominio de latencia baja que te ayuda a registrar, administrar y entregar tus dominios. Cloud DNS escala a una gran cantidad de zonas y Registros de DNS, y se pueden crear y actualizar millones de Registros DNS mediante una interfaz de usuario.

prácticas recomendadas

  • Prácticas recomendadas de Cloud DNS: Obtén información sobre cómo administrar zonas privadas, configurar el reenvío de DNS y crear políticas de servidor DNS. Se incluye orientación sobre el uso de Cloud DNS en un entorno híbrido.

Guía de confiabilidad de Cloud Load Balancing

Cloud Load Balancing es un servicio completamente distribuido, definido por software y administrado para todo su tráfico. Cloud Load Balancing también proporciona ajuste de escala automático sin interrupciones, balanceo de cargas de capa 4 y de capa 7, y compatibilidad con funciones como el balanceo de cargas global IPv6.

prácticas recomendadas

  • Prácticas recomendadas de rendimiento: cómo distribuir la carga entre las instancias de la aplicación para obtener un rendimiento óptimo. Las estrategias incluyen la ubicación de backend en las regiones más cercanas al tráfico, el almacenamiento en caché, la selección del protocolo de regla de reenvío y la configuración de la afinidad de sesión.
  • Uso del balanceo de cargas para aplicaciones con alta disponibilidad: cómo usar Cloud Load Balancing con Compute Engine a fin de proporcionar alta disponibilidad, incluso durante una interrupción zonal.

Guía de confiabilidad de Cloud CDN

Cloud CDN (red de distribución de contenidos) es un servicio que acelera la distribución de contenido por Internet a través de la red perimetral de Google para llevarlo lo más cerca posible al usuario. Cloud CDN ayuda a reducir la latencia, los costos y la carga, lo que facilita el escalamiento de los servicios a los usuarios.

prácticas recomendadas

Guía de confiabilidad de BigQuery

BigQuery es la plataforma de almacén de datos de Google Cloud para almacenar y analizar datos a gran escala.

prácticas recomendadas

  • Introducción a la confiabilidad: prácticas recomendadas sobre confiabilidad e introducción a conceptos como la disponibilidad, la durabilidad y la coherencia de los datos.
  • Disponibilidad y durabilidad: los tipos de dominios con fallas que pueden ocurrir en los centros de datos de Google Cloud, cómo BigQuery proporcionan redundancia de almacenamiento según la ubicación de almacenamiento de datos y por qué los conjuntos de datos entre regiones mejoran la recuperación ante desastres.
  • Prácticas recomendadas para las cargas de trabajo multiusuario en BigQuery: patrones comunes que se usan en las plataformas de datos de varios usuarios. Estos patrones incluyen confiabilidad y aislamiento para los clientes de proveedores de software como servicio (SaaS), cuotas de BigQuery importantes y límites para la planificación de capacidad, usando el Servicio de transferencia de datos de BigQuery a fin de copiar conjuntos de datos relevantes en otra región y mucho más.
  • Uso de vistas materializadas: cómo usar las vistas materializadas de BigQuery para realizar consultas más rápidas a un costo menor, incluidas las consultas de vistas materializadas, la alineación de particiones y el ajuste inteligente (reescritura automática de consultas).

Guía de confiabilidad de Dataflow

Dataflow es un servicio de procesamiento de datos completamente administrado que permite el desarrollo rápido y simplificado de canalizaciones de transmisión de datos mediante bibliotecas de código abierto de Apache Beam. Dataflow minimiza la latencia, el tiempo de procesamiento y el costo mediante el ajuste de escala automático y el procesamiento por lotes.

prácticas recomendadas

Compila canalizaciones de datos listas para la producción mediante Dataflow: una serie de documentos sobre el uso de Dataflow, que incluye la planificación, el desarrollo, la implementación y la supervisión de canalizaciones de Dataflow.

  • Descripción general: Introducción a las canalizaciones de Dataflow.
  • Planificación: medir los SLO, comprender el impacto de las fuentes de datos y los receptores en la escalabilidad y el rendimiento de la canalización, y tener en cuenta la alta disponibilidad, la recuperación ante desastres y el rendimiento de la red cuando se especifican regiones para ejecutar los trabajos de Dataflow
  • Desarrollo y pruebas: Configura entornos de implementación, evita la pérdida de datos mediante colas de mensajes no entregados para el manejo de errores y reduce la latencia y los costos, ya que minimiza las operaciones costosas por elemento. Además, usa el procesamiento por lotes para reducir la sobrecarga del rendimiento sin sobrecargar los servicios externos, la fusión de pasos fusionados de forma inadecuada a fin de que los pasos se separen para un mejor rendimiento y la ejecución de pruebas de extremo a extremo en la producción previa para garantizar que la canalización cumpla con tus SLO y otra producción.
  • Implementación: Integración continua (CI) y, también, implementación continua (CD), con consideraciones especiales para implementar versiones nuevas de canalizaciones de transmisión. Además, un ejemplo de canalización de CI/CD y algunas funciones para optimizar el uso de recursos. Por último, un análisis de la alta disponibilidad, la redundancia geográfica y las prácticas recomendadas para la confiabilidad de las canalizaciones, que incluyen el aislamiento regional, el uso de instantáneas, el manejo de errores de envío de trabajos y la recuperación de errores y las interrupciones que afectan a las canalizaciones en ejecución.
  • Supervisión: Observa los indicadores de nivel de servicio (SLI) que son indicadores importantes del rendimiento de la canalización, y define y mide los objetivos de nivel de servicio (SLO)./

Guía de confiabilidad de Dataproc

Dataproc es un servicio completamente administrado y escalable para ejecutar trabajos de Apache Hadoop y Spark. Con Dataproc, las máquinas virtuales se pueden personalizar y aumentar o disminuir de escala según sea necesario. Dataproc se integra estrechamente en Cloud Storage, BigQuery, Bigtable y otros servicios de Google Cloud.

prácticas recomendadas

  • Modo de alta disponibilidad de Dataproc: compara el modo de alta disponibilidad (HA) de Hadoop con el modo predeterminado que no es de HA en cuanto a nombres de instancia, Apache ZooKeeper, Sistema de archivos distribuidos de Hadoop (HDFS) y Yet Another Resource Negotiator (YARN). Además, cómo crear un clúster de alta disponibilidad.
  • Clústeres con ajuste de escala automático: Cuándo se usa el ajuste de escala automático de Dataproc, cómo crear una política de ajuste de escala automático, uso de varias políticas de múltiples clústeres, prácticas recomendadas de confiabilidad para la configuración del ajuste de escala automático, y métricas y registros.
  • Modo de flexibilidad mejorada de Dataproc (EFM): Ejemplos de uso del modo de flexibilidad mejorada para minimizar los retrasos en el progreso del trabajo, la configuración avanzada como la partición y el paralelismo, y el retiro de servicio ordenado de YARN en clústeres EFM.
  • Retiro de servicio ordenado: Usa el retiro de servicio ordenado para minimizar el impacto de quitar trabajadores de un clúster, cómo usar esta función con trabajadores secundarios y ejemplos de comandos para el retiro de servicio ordenado.
  • Trabajos reiniciables: Con la configuración opcional, puedes establecer trabajos para que se reinicien ante fallas para mitigar los tipos comunes de falla de trabajo, incluidos los problemas de memoria insuficiente y los reinicios inesperados de la máquina virtual de Compute Engine.

Google Cloud Architecture Framework: Optimización de costos

En esta categoría de Google Cloud Architecture Framework, se proporcionan recomendaciones de diseño y se describen las prácticas recomendadas para ayudar a los arquitectos, los desarrolladores, los administradores y otros profesionales de la nube a optimizar el costo de las carga de trabajo en Google Cloud.

Trasladar tus cargas de trabajo de TI a la nube puede ayudarte a innovar a gran escala, entregar funciones más rápido y responder a las necesidades en constante evolución de los clientes. A fin de migrar las cargas de trabajo existentes o implementar aplicaciones compiladas para la nube, necesitas una topología optimizada para la seguridad, la resiliencia, la excelencia operativa, el costo y el rendimiento.

En la categoría de optimización de costos del framework de arquitectura, aprenderás a hacer lo siguiente:

Adopta e implementa FinOps

En este documento de framework de la arquitectura de Google Cloud, se describen las estrategias para ayudarte a considerar el impacto de los costos de tus acciones y decisiones cuando aprovisionas y administras recursos en Google Cloud. Se analiza FinOps, una práctica que combina personas, procesos y tecnología para promover la responsabilidad financiera y la disciplina de optimización de costos en una organización, sin importar su tamaño o antigüedad en la nube.

La orientación de esta sección está destinada a los directores de Tecnología, los directores generales de información y los ejecutivos responsables de controlar los gastos de la organización en la nube. La guía también ayuda a los operadores de nube individuales a comprender y adoptar AdOps.

Cada empleado de la organización puede ayudar a reducir el costo de los recursos en Google Cloud, sin importar el rol (analista, arquitecto, desarrollador o administrador). Es posible que debas explicar a los empleados la necesidad de la responsabilidad colectiva en los equipos que no tuvieron que realizar un seguimiento de los costos de infraestructura.

Un modelo común es para un equipo central de FinOps o un Centro de excelencia para la nube (CCoE) para estandarizar el proceso y optimizar el costo en todas las cargas de trabajo en la nube. En este modelo, se supone que el equipo central tiene el conocimiento y la experiencia necesarios para identificar oportunidades de alto valor para mejorar la eficiencia.

Aunque el control centralizado de costos podría funcionar bien en las etapas iniciales de la adopción de la nube cuando el uso es bajo, no se escala bien cuando la adopción de la nube y el uso aumentan. Es posible que el equipo central tenga dificultades con el escalamiento y que los equipos de proyectos no acepten decisiones que tomaron personas ajenas a sus equipos.

Recomendamos que el equipo central delegue la toma de decisiones para la optimización de recursos a los equipos del proyecto. El equipo central puede impulsar esfuerzos más amplios para fomentar la adopción de FinOps en toda la organización. Para permitir que los equipos de proyectos individuales practiquen FinOps, el equipo central debe estandarizar el proceso, los informes y las herramientas para la optimización de costos. El equipo central debe trabajar en estrecha colaboración con equipos que no estén familiarizados con las prácticas de FinOps y ayudarlos a tener en cuenta el costo en sus procesos de toma de decisiones. El equipo central también debe actuar como un intermediario entre el equipo de finanzas y los equipos de proyectos individuales.

En las siguientes secciones, se describen los principios de diseño que recomendamos que tu equipo central promueva.

Fomenta la responsabilidad individual

Cualquier empleado que cree y use recursos de la nube afecta el uso y el costo de esos recursos. Para que una organización tenga éxito en la implementación de FinOps, el equipo central debe ayudar a los empleados en la transición del costo de visualización como responsabilidad de otra persona y asumir el costo como su propia responsabilidad individual. Con esta transición, los empleados son propietarios y toman decisiones de costos adecuadas para sus cargas de trabajo, equipo y organización. Esta propiedad se extiende a la implementación de acciones de optimización de costos basadas en datos.

Para fomentar la responsabilidad por el costo, el equipo central puede realizar las siguientes acciones:

  • Capacitar a los usuarios sobre las oportunidades y técnicas de optimización de costos.
  • Recompense a los empleados que optimizan los costos y celebre el éxito.
  • Hacer que los costos sean visibles en toda la organización.

Haz visibles los costos

Para que los empleados consideren los costos cuando aprovisionen y administren recursos en la nube, necesitan una vista completa de los datos relevantes, lo más cerca posible del tiempo real. Los datos en los informes y paneles deben mostrar el costo y el impacto empresarial de las decisiones de los miembros del equipo a medida que se producen los impactos relevantes. Los datos de uso y costos de otros equipos pueden servir como modelos de referencia para identificar patrones de implementación eficientes. Estos datos pueden ayudar a promover una comprensión compartida de las mejores formas de usar los servicios en la nube.

Si una organización no fomenta ni promueve el uso compartido de datos de costos, es posible que los empleados pueden negarse a compartir datos. A veces, por motivos comerciales, es posible que una organización no permita el uso compartido de datos sin procesar de costos. Incluso en estos casos, te recomendamos que evites una política predeterminada que restrinja el acceso a la información de costos.

Para que los costos sean visibles en toda la organización, el equipo central puede realizar las siguientes acciones:

  • Usa un método único y bien definido para calcular los costos por completo cargados de los recursos en la nube. Por ejemplo, el método podría considerar la inversión total en la nube ajustada para los descuentos y costos compartidos comprados, como el costo de las bases de datos compartidas.
  • Configurar paneles que les permitan a los empleados ver su gasto en la nube casi en tiempo real.
  • Para motivar a los miembros del equipo a hacerse responsables de sus costos, permita que todos los equipos puedan visualizar la inversión en la nube.

Permite el comportamiento colaborativo

La administración eficaz de costos de los recursos en la nube requiere que los equipos colaboren para mejorar sus procesos técnicos y operativos. Una cultura colaborativa ayuda a los equipos a diseñar patrones de implementación rentables en función de un conjunto coherente de objetivos y factores comerciales.

Para permitir el comportamiento colaborativo, el equipo central puede realizar las siguientes acciones:

  • Crear un proceso de incorporación de cargas de trabajo que ayude a garantizar la rentabilidad en la etapa de diseño a través de revisiones de app similarde de arquitecturas propuestas por otros ingenieros.
  • Crea una base de conocimiento entre equipos de patrones arquitectónicos rentables.

Establece una cultura libre de culpas

Promover una cultura de aprendizaje y crecimiento que haga que sea seguro tomar riesgos, realizar correcciones cuando sea necesario y, también, innovar. Reconocer que los errores, a veces costosos, pueden ocurrir en cualquier etapa del ciclo de vida de la implementación y el diseño de TI, como en cualquier otra parte de la empresa.

En lugar de culpar y avergonzar a las personas que han gastado demasiado o que han provocado gastos, promueve una cultura libre de culpas que ayude a identificar la causa de los excesos de costos y los cálculos incorrectos. En este entorno, es más probable que los miembros del equipo compartan sus vistas y experiencia. Los errores se anonimizan y se comparten en toda la empresa para evitar la recurrencia.

No hay que confundir una cultura libre de culpas con la falta de responsabilidad. Los empleados siguen siendo responsables de las decisiones que toman y del dinero que invierten. Sin embargo, cuando se producen errores, lo importante es la oportunidad de aprendizaje para evitar que se repitan.

Para establecer una cultura libre de culpas, el equipo central puede realizar las siguientes acciones:

  • Ejecutar análisis retrospectivos para los problemas de costos más importantes y enfocarse en la causa raíz sistémica de los problemas, en lugar de las personas involucradas.
  • Celebrar a los miembros del equipo que respondan a los excesos de costos y que compartan lecciones aprendidas. Incentiva a otros miembros del equipo a compartir errores, medidas tomadas y lecciones aprendidas.

Enfócate en el valor empresarial

Si bien las prácticas de FinOps a menudo se centran en la reducción de costos, el enfoque para un equipo central debe estar destinado a permitir que los equipos de proyectos tomen decisiones que maximizan el valor empresarial de sus recursos en la nube. Puede ser tentador tomar decisiones que reduzcan los costos hasta el punto en que se cumplan los niveles de servicio mínimos. Sin embargo, esas decisiones suelen cambiar el costo a otros recursos, pueden generar un costo de mantenimiento más alto y aumentar el costo total de propiedad. Por ejemplo, para reducir los costos, puedes decidir usar máquinas virtuales (VMs) en lugar de un servicio administrado. Sin embargo, una solución basada en VM requiere más esfuerzo de mantenimiento cuando se compara con un servicio administrado, por lo que el servicio administrado puede ofrecer un valor comercial neto más alto.

Las prácticas de FinOps pueden proporcionar a los equipos de proyectos la visibilidad y las estadísticas que necesitan para tomar decisiones arquitectónicas y operativas que maximicen el valor empresarial de los recursos en la nube.

Para ayudar a los empleados a enfocarse en el valor empresarial, el equipo central puede realizar las siguientes acciones:

  • Usar servicios administrados y arquitecturas sin servidores para reducir el costo total de propiedad de tus recursos de procesamiento. Si deseas obtener más información, consulta Elige una plataforma de procesamiento.

  • Correlacionar el uso de la nube con las métricas de valor comercial, como la rentabilidad, la resiliencia, la velocidad de las funciones y la innovación, que impulsan las decisiones de optimización de costos. Si deseas obtener más información sobre las métricas de valor empresarial, consulta el informe de Cloud Finops.

  • Implementar el costo de unidad para todas tus aplicaciones y servicios que se ejecutan en la nube.

¿Qué sigue?

Supervisión y control de los costos

En este documento de framework de arquitectura de Google Cloud, se describen las prácticas recomendadas, las herramientas y las técnicas para ayudarte a hacer un seguimiento y controlar el costo de tus recursos en Google Cloud.

La guía de esta sección está dirigida a usuarios que aprovisionen o administren recursos en la nube.

Áreas de enfoque para la administración de costos

El costo de los recursos en Google Cloud depende de la cantidad de recursos que uses y la tarifa a la que se te factura por ellos.

Para administrar el costo de los recursos en la nube, te recomendamos que te enfoques en las siguientes áreas:

  • Visibilidad de costos
  • Optimización de recursos
  • Optimización de tarifas

Visibilidad de costos

Realiza un seguimiento de cuánto gastas y cómo se facturan los recursos y servicios para que puedas analizar el efecto de los costos en los resultados empresariales. Te recomendamos que sigas el modelo operativo de FinOps, que sugiere las siguientes acciones para que la información de costos sea visible en toda tu organización:

  • Asignar: asigna un propietario para cada elemento de costo.
  • Informe: haz que los datos de costos estén disponibles, sean consumibles y prácticos.
  • Previsión: calcula y realiza un seguimiento de la inversión futura.

Optimización de recursos

Alinea la cantidad y el tamaño de los recursos en la nube según los requisitos de tu carga de trabajo. Siempre que sea posible, considera usar servicios administrados o volver a diseñar tus aplicaciones. Por lo general, los equipos de ingeniería individuales tienen más contexto que el equipo central de FinOps (operaciones financieras) sobre oportunidades y técnicas para optimizar la implementación de recursos. Recomendamos que el equipo de FinOps trabaje con los equipos de ingeniería individuales para identificar las oportunidades de optimización de recursos que se pueden aplicar en toda la organización.

Optimización de tarifas

El equipo de FinOps suele tomar decisiones de optimización de tarifas de forma central. Recomendamos que los equipos de ingeniería individuales trabajen con el equipo central de FinOps para aprovechar los descuentos por reservas, el uso comprometido, las VMs spot, los precios de tasa fija, y el volumen y los descuentos por contratos.

Recomendaciones de diseño

En esta sección, se sugieren enfoques que puedes usar para supervisar y controlar los costos.

Consolida la facturación y la administración de recursos

Para administrar la facturación y los recursos en Google Cloud de manera eficiente, te recomendamos que uses una sola cuenta de facturación para tu organización y que uses mecanismos de devolución del cargo internos para asignar costos. Usa varias cuentas de facturación para conglomerados u organizaciones estructurados de forma flexible con entidades que no se afecten entre sí. Por ejemplo, los revendedores pueden necesitar cuentas distintas para cada cliente. Usar cuentas de facturación distintas también puede ayudarte a cumplir con las normativas impositivas específicas de cada país.

Otra práctica recomendada es mover todos los proyectos que administras a tu organización. Recomendamos usar Resource Manager para compilar una jerarquía de recursos que te ayude a lograr los siguientes objetivos:

  • Establece una jerarquía de propiedad de recursos en función de la relación de cada recurso con su superior inmediato.
  • Controla cómo las políticas de acceso y las etiquetas de política o de recurso de asignación de costos se adjuntan a los recursos en tu organización y cómo estos las heredan.

Además, te recomendamos que asignes el costo de los servicios compartidos de manera proporcional en función del consumo. Revisa y ajusta los parámetros de asignación de costos de forma periódica según los cambios en los objetivos y las prioridades de tu empresa.

Realiza un seguimiento y asigna costos con etiquetas de política o de recurso

Las etiquetas de política y de recurso son dos métodos diferentes que puedes usar para anotar tus recursos de Google Cloud. Las etiquetas proporcionan más capacidades que las etiquetas. Por ejemplo, puedes implementar un control detallado sobre los recursos mediante la creación de políticas de Identity and Access Management (IAM) que sean condicionales según si una etiqueta de política se adjunta a un recurso compatible. Además, todos los recursos secundarios de la jerarquía heredan las etiquetas asociadas con un recurso. Para obtener más información sobre las diferencias entre etiquetas de política y de recurso, consulta Descripción general de las etiquetas de política.

Si compilas un framework nuevo para la asignación y el seguimiento de costos, te recomendamos que uses etiquetas de política.

Para categorizar los datos de costos según el nivel de detalle requerido, establece un esquema de etiquetas de política o de recurso que se adapte al mecanismo de devolución del cargo de tu organización y te ayude a asignar los costos de forma adecuada. Puedes definir etiquetas a nivel de organización o de proyecto. Puedes asignar etiquetas a nivel de proyecto y definir un conjunto de etiquetas que se puedan aplicar de forma predeterminada a todos los proyectos.

Define un proceso para detectar y corregir anomalías de etiquetado y proyectos sin etiquetar. Por ejemplo, desde Cloud Asset Inventory, puedes descargar un inventario (archivo .csv) de todos los recursos en un proyecto y analizar el inventario a fin de identificar recursos. A las que no se les hayan asignado ninguna etiqueta de política o de recurso.

Para realizar un seguimiento del costo de los recursos y servicios compartidos (por ejemplo, almacenes de datos comunes, clústeres de varios usuarios y suscripciones de asistencia), considera usar una etiqueta de política o de recurso especial para identificar proyectos que contengan recursos compartidos.

Configura el control de acceso a la facturación

Para controlar el acceso a la Facturación de Cloud, te recomendamos que asignes el rol de administrador de la cuenta de facturación solo a los usuarios que administran la información de contacto de facturación. Por ejemplo, los empleados de finanzas, contabilidad y operaciones pueden necesitar esta función.

Para evitar un punto único de fallo para la asistencia de facturación, asigna el rol de administrador de la cuenta de facturación a varios usuarios o a un grupo. Solo los usuarios con el rol de administrador de la cuenta de facturación pueden comunicarse con el equipo de asistencia. Para obtener una guía detallada, consulta Ejemplos de control de acceso a la Facturación de Cloud y Funciones importantes.

Establece las siguientes configuraciones para administrar el acceso a la facturación:

  • Para asociar una cuenta de facturación a un proyecto, los miembros necesitan la función de usuario de la cuenta de facturación en la cuenta y la función de administrador de facturación del proyecto en el proyecto.
  • Para permitir que los equipos asocien las cuentas de facturación de manera manual con los proyectos, puedes asignar la función de administrador de facturación del proyecto a nivel de la organización y la función de usuario de la cuenta de facturación en la cuenta. Puedes automatizar la asociación de cuentas de facturación durante la creación del proyecto si asignas las funciones de administrador de facturación del proyecto y usuario de la cuenta de facturación a una cuenta de servicio. Te recomendamos restringir la función de creador de cuentas de facturación o quitar todas las asignaciones de esta función.
  • Para evitar interrupciones causadas por cambios accidentales en el estado de la facturación de un proyecto, puedes bloquear el vínculo entre el proyecto y su cuenta de facturación. Para obtener más información, consulta Protege el vínculo entre un proyecto y su cuenta de facturación.

Configura informes de facturación

Configura informes de facturación a fin de proporcionar datos para las métricas clave a las que debas realizar un seguimiento. Te recomendamos que realices un seguimiento de las siguientes métricas:

  • Tendencias de costos
  • Los que más gastan (por proyecto y por producto)
  • Áreas de gasto irregular
  • Estadísticas clave para toda la organización de la siguiente manera:
    • Detección de anomalías
    • Tendencias en el tiempo
    • Tendencias que ocurren en un patrón establecido (por ejemplo, mes a mes)
    • Comparación de costos y análisis de comparativas entre cargas de trabajo internas y externas
    • Seguimiento de casos empresariales y obtención de valores (por ejemplo, costos de la nube en comparación con el costo de los recursos locales similares)
    • Validación de que las facturas de Google Cloud son precisas y según lo previsto

Personalice y analice informes de costos con la BigQuery Billing Export y visualice los datos de costos mediante Looker Studio. Evalúa la tendencia de los costos reales y cuánto podrías gastar con la herramienta de previsión.

Optimiza el uso y el costo de los recursos

En esta sección, se sugieren prácticas recomendadas para ayudarte a optimizar el uso y el costo de tus recursos en los servicios de Google Cloud.

A fin de evitar gastos excesivos, considera configurar presupuestos y alertas predeterminados con límites altos para todos tus proyectos. Para ayudarte a mantenerte dentro de los presupuestos, te recomendamos que hagas lo siguiente:

  • Configura presupuestos y alertas para los proyectos en los que se necesitan límites de uso absolutos (por ejemplo, proyectos de entrenamiento o de zona de pruebas).

  • Define los presupuestos según los presupuestos financieros a los que necesites realizar un seguimiento. Por ejemplo, si un departamento tiene un presupuesto general en la nube, establece el alcance del presupuesto de Google Cloud para incluir los proyectos específicos a los que debas realizar un seguimiento.

  • Para asegurarte de que los presupuestos se mantengan, delega la responsabilidad de configurar los presupuestos y las alertas a los equipos propietarios de las cargas de trabajo.

Para ayudar a optimizar los costos, también te recomendamos que hagas lo siguiente:

  • Limita el uso de la API en casos en los que tiene un impacto mínimo o nulo sobre la empresa. La limitación puede ser útil para proyectos de zona de pruebas o de entrenamiento, y para proyectos con presupuestos fijos (por ejemplo, estadísticas ad-hoc en BigQuery). La limitación no quita todos los recursos y datos de los proyectos asociados.
  • Usa cuotas para establecer límites estrictos que limiten la implementación de recursos. Las cuotas te ayudan a controlar los costos y evitar el uso malicioso o el uso inadecuado de los recursos. Las cuotas se aplican a nivel de proyecto, por tipo de recurso y ubicación.
  • Consulta e implementa las recomendaciones de optimización de costos en el Centro de recomendaciones.
  • Compra descuentos por compromiso de uso (CUD) para ahorrar dinero en recursos de las cargas de trabajo con necesidades de recursos predecibles.

Herramientas y técnicas

Las características de aprovisionamiento bajo demanda y pago por uso de la nube te ayudan a optimizar los gastos de TI. En esta sección, se describen las herramientas que proporciona Google Cloud y las técnicas que puedes usar para realizar un seguimiento y controlar el costo de los recursos en la nube. Antes de usar estas herramientas y técnicas, revisa los conceptos básicos de la Facturación de Cloud.

Informes de facturación

Google Cloud proporciona informes de facturación dentro de la consola de Google Cloud para ayudarte a ver tu gasto actual y previsto. Los informes de facturación te permiten ver los datos de costos en una sola página, descubrir y analizar tendencias, prever el costo de fin de período y tomar medidas correctivas cuando sea necesario.

Los informes de facturación proporcionan los siguientes datos:

  • Los costos y las tendencias de costos para un período determinado, organizados de la siguiente manera:
    • Por cuenta de facturación
    • Por proyecto
    • Por producto (por ejemplo, Compute Engine)
    • Por SKU (por ejemplo, direcciones IP estáticas)
  • Los costos potenciales si se excluyeron los descuentos o créditos promocionales
  • La inversión prevista

Exportación de datos a BigQuery

Puedes exportar informes de facturación a BigQuery y analizar los costos mediante vistas históricas y detalladas de los datos, incluidos los datos categorizados con etiquetas de política o de recurso. Puedes realizar análisis más avanzados con BigQuery ML. Te recomendamos que habilites la exportación de informes de facturación a BigQuery cuando crees la cuenta de Facturación de Cloud. Tu conjunto de datos de BigQuery contiene datos de facturación desde la fecha en la que configuraste la exportación de la Facturación de Cloud. El conjunto de datos no incluye datos para el período antes de habilitar la exportación.

Para visualizar datos de costos, puedes crear paneles personalizados que se integren con BigQuery (plantillas de ejemplo: Looker, Looker Studio).

Puedes usar etiquetas de política o de recurso como criterios para filtrar los datos de facturación exportados. La cantidad de etiquetas incluidas en la exportación de facturación es limitada. Se conservan hasta 1,000 mapas de etiquetas en un período de una hora. Las etiquetas no aparecen en el PDF o CSV de la factura. Considera anotar recursos mediante el uso de etiquetas de política o de recurso que indiquen la unidad de negocios, la unidad de devolución del cargo interna y otros metadatos relevantes.

Control de acceso a la facturación

Puedes controlar el acceso a la Facturación de Cloud para recursos específicos si defines Identity and Access Management (IAM) para los recursos. Para otorgar o limitar el acceso a la Facturación de Cloud, puedes establecer una política de IAM a nivel de la organización, de la cuenta de facturación o del proyecto.

El control de acceso para la facturación y la administración de recursos sigue el principio de separación de obligaciones. Cada usuario solo tiene los permisos necesarios para su función empresarial. Las funciones de administrador de la organización y administrador de facturación no tienen los mismos permisos.

Puedes establecer permisos relacionados con la facturación a nivel de la cuenta de facturación y a nivel de la organización. Las funciones comunes son administrador de cuentas de facturación, usuario de cuentas de facturación y visualizador de cuentas de facturación.

Te recomendamos que uses la facturación o configures una forma de pago alternativa. Mantén la configuración de contacto y notificación para la facturación y el pago.

Presupuestos, alertas y cuotas

Los presupuestos te ayudan a hacer un seguimiento de los costos reales de Google Cloud con respecto a los gastos planificados. Cuando creas un presupuesto, puedes configurar reglas de alerta para activar notificaciones por correo electrónico cuando el gasto real o previsto superen un límite definido. También puedes usar presupuestos para automatizar las respuestas de control de costos.

Los presupuestos pueden activar alertas para informarte sobre el uso de recursos y las tendencias de costos, y solicitarte que realices acciones de optimización de costos. Sin embargo, los presupuestos no evitan el uso o la facturación de los servicios cuando el costo real alcanza o supera el presupuesto o el límite. Para controlar el costo de forma automática, puedes usar las notificaciones de presupuesto a fin de inhabilitar la Facturación de Cloud de un proyecto de manera programática. También puedes limitar el uso de la API para dejar de generar costos después de un límite de uso definido.

Puedes configurar alertas para cuentas de facturación y proyectos. Configura al menos un presupuesto para una cuenta.

Para evitar el aprovisionamiento de recursos más allá de un nivel predeterminado o limitar el volumen de operaciones específicas, puedes establecer cuotas a nivel de recurso o de API. A continuación, se muestran ejemplos de cómo puedes usar las cuotas:

  • Controla la cantidad de llamadas a la API por segundo.
  • Limita la cantidad de VM creadas.
  • Restringe la cantidad de datos consultados por día en BigQuery.

Los propietarios del proyecto pueden reducir la cantidad de cuota que se puede cobrar por un límite de cuota mediante la API de Service Usage para aplicar anulaciones del consumidor a límites de cuota específicos. Si deseas obtener más información, consulta Crea una anulación de cuota del consumidor.

Mejora de la eficiencia de la carga de trabajo

Recomendamos las siguientes estrategias para que las cargas de trabajo en Google Cloud sean rentables:

  • Mejora la eficiencia del producto para optimizar el uso de los recursos.
  • Reduce la tarifa a la que se te facturan los recursos.
  • Controla y limita el uso y los gastos de los recursos.

Cuando selecciones técnicas de reducción de costos y características de Google Cloud, ten en cuenta el esfuerzo necesario y los ahorros esperados, como se muestra en el siguiente gráfico:

Estrategias de optimización de costos: mapa de ahorro para ahorrar

A continuación, se presenta un resumen de las técnicas que se muestran en el gráfico anterior:

  • Las siguientes técnicas pueden producir grandes ahorros con poco esfuerzo:
    • Descuentos por compromiso de uso
    • Ajuste de escala automático
    • Ranuras de BigQuery
  • Las siguientes técnicas pueden producir ahorros altos con esfuerzo de moderado a alto:
    • VMs Spot
    • Vuelve a diseñar como aplicaciones sin servidores o en contenedores
    • Actualiza tu plataforma para usar servicios administrados
  • Las siguientes técnicas podrían generar ahorros moderados con un esfuerzo moderado:
    • Tipos personalizados de máquinas
    • Administración del ciclo de vida de Cloud Storage
    • Redimensionamiento:
    • Reclamo de recursos inactivos

Las técnicas que se explican en las siguientes secciones pueden ayudarte a mejorar la eficiencia de tus cargas de trabajo.

Refactorización o reestructuración

Puedes lograr ahorros de costos sustanciales si refactorizas o rediseñas la arquitectura de tu carga de trabajo para usar productos de Google Cloud. Por ejemplo, migrar a servicios sin servidores (como Cloud Storage, Cloud Run, BigQuery y Cloud Functions) que admiten la reducción de escala a cero puede ayudar a mejorar la eficiencia. Para evaluar y comparar el costo de estos productos, puedes usar la calculadora de precios.

Redimensionamiento

Esta técnica te ayuda a garantizar que la escala de tu infraestructura coincida con el uso previsto. Esta estrategia es relevante sobre todo para las soluciones de infraestructura como servicio (IaaS), en las que pagas por la infraestructura subyacente. Por ejemplo, implementaste 50 VM, pero estas no se usan por completo, y tú determinas que las cargas de trabajo podrían ejecutarse de forma efectiva en menos VM (o más pequeñas). En este caso, puedes quitar algunas de las VM o cambiar su tamaño. Google Cloud proporciona recomendaciones de redimensionamiento para ayudarte a detectar oportunidades de ahorrar dinero sin afectar el rendimiento mediante el aprovisionamiento de VM más pequeñas. El redimensionamiento requiere menos esfuerzo si se realiza durante la fase de diseño que después de implementar los recursos en la producción.

Ajuste de escala automático

Si los productos que usas admiten el ajuste de escala automático dinámico, considera diseñar las cargas de trabajo para aprovechar el ajuste de escala automático a fin de obtener beneficios de costo y rendimiento. Por ejemplo, para cargas de trabajo de procesamiento intensivo, puedes usar grupos de instancias administrados en Compute Engine o crear contenedores para las aplicaciones e implementarlas en un clúster de Google Kubernetes Engine.

Recomendaciones de Active Assist

Active Assist usa los datos, la inteligencia y el aprendizaje automático para reducir la complejidad de la nube y el esfuerzo administrativo. Active Assist facilita la optimización de la seguridad, el rendimiento y el costo de la topología de la nube. Proporciona recomendaciones inteligentes para optimizar tus costos y uso. Puedes aplicar estas recomendaciones para ahorrar costos de forma inmediata y obtener una mayor eficiencia.

A continuación, se muestran algunos ejemplos de recomendaciones que proporciona Active Assist:

  • Redimensionamiento de recursos de Compute Engine: cambia el tamaño de tus instancias de VM para optimizar el costo y el rendimiento según el uso. Identifica y borra o crea una copia de seguridad de las VM sin usar y los discos persistentes para optimizar el costo de infraestructura.
  • Descuento por compromiso de uso (CUD): Google Cloud analiza el uso histórico, encuentra la cantidad óptima de compromiso para las cargas de trabajo y proporciona recomendaciones fáciles de aplicar y entender a fin de ahorrar costos. Para obtener más información, consulta Recomendador de descuento por compromiso de uso.
  • Proyectos sin supervisión: Descubre proyectos sin supervisión en tu organización y quítalos o reclamalos. Para obtener más información, consulta Recomendador de proyectos sin supervisión.

Para obtener una lista completa, consulta Recomendadores.

¿Qué sigue?

Optimiza los costos: procesamiento, contenedores y computación sin servidores

En este documento del Framework de la arquitectura de Google Cloud, se proporcionan recomendaciones para ayudarte a optimizar el costo de las máquinas virtuales (VM), los contenedores y los recursos sin servidores en Google Cloud.

La orientación de esta sección está dirigida a arquitectos, desarrolladores y administradores responsables de aprovisionar y administrar recursos de procesamiento para las cargas de trabajo en la nube.

Los recursos de procesamiento son la parte más importante de la infraestructura de nube. Cuando migras tus cargas de trabajo a Google Cloud, una primera opción típica es Compute Engine, que te permite aprovisionar y administrar VMs de manera eficiente en la nube. Compute Engine ofrece una amplia gama de tipos de máquinas y está disponible de forma global en todas las regiones de Google Cloud. Los tipos predefinidos y personalizados de máquinas de Compute Engine te permiten aprovisionar VM que ofrecen capacidad de procesamiento similar a la de tu infraestructura local, lo que te permite acelerar el proceso de migración. Compute Engine te brinda la ventaja de precios mediante el pago solo por la infraestructura que usas y proporciona ahorros significativos a medida que usas más recursos de procesamiento con descuentos por uso continuo.

Además de Compute Engine, Google Cloud ofrece contenedores y servicios de procesamiento sin servidores. El enfoque sin servidores puede ser más rentable para servicios nuevos que no siempre se ejecutan (por ejemplo, API, procesamiento de datos y procesamiento de eventos).

Junto con las recomendaciones generales, en este documento se proporciona orientación para ayudarte a optimizar el costo de los recursos de procesamiento cuando utilizas los siguientes productos:

  • Compute Engine
  • Google Kubernetes Engine (GKE)
  • Cloud Run
  • Cloud Functions
  • App Engine

Recomendaciones generales

Las siguientes recomendaciones se aplican a todos los servicios de procesamiento, contenedores y sin servidores de Google Cloud que se analizan en esta sección.

Realiza un seguimiento del uso y el costo

Usa las siguientes herramientas y técnicas para supervisar el uso y el costo de los recursos:

Controla el aprovisionamiento de recursos

Usa las siguientes recomendaciones para controlar la cantidad de recursos aprovisionados en la nube y la ubicación en la que se crean los recursos:

  • Para garantizar que el consumo y el costo de los recursos no excedan la previsión, usa cuotas de recursos.
  • Aprovisiona los recursos en la región de menor costo que cumpla con los requisitos de latencia de tu carga de trabajo. Para controlar dónde se aprovisionan los recursos, puedes usar la restricción de la política de la organización gcp.resourceLocations.

Obtén descuentos por compromiso de uso

Los descuentos por compromiso de uso (CUD) son ideales para cargas de trabajo con necesidades de recursos predecibles. Después de migrar tu carga de trabajo a Google Cloud, busca el modelo de referencia para los recursos necesarios y obtén más descuentos por compromiso de uso. Por ejemplo, compra un compromiso de uno o tres años y obtén un descuento sustancial en los precios de VM de Compute Engine.

Automatiza el seguimiento de costos con etiquetas

Define y asigna etiquetas de manera coherente. Los siguientes son ejemplos de cómo puedes usar etiquetas para automatizar el seguimiento de costos:

  • Para las VM que solo los desarrolladores usan durante las horas hábiles, asigna la etiqueta env: development. Puedes usar Cloud Scheduler para configurar una función de Cloud Functions sin servidores a fin de apagar estas VM después de las horas hábiles y reiniciarlas cuando sea necesario.

  • Para una aplicación que tenga varios servicios de Cloud Run y, también, instancias de Cloud Functions, asigna una etiqueta coherente a todos los recursos de Cloud Run y Cloud Functions. Identifica las áreas de alto costo y toma medidas para reducir el costo.

Personaliza los informes de facturación

Configura tus informes de la Facturación de Cloud mediante la configuración de los filtros necesarios y la agrupación de los datos según sea necesario (por ejemplo, por proyectos, servicios o etiquetas).

Promociona una cultura de ahorro de costos

Capacita a los desarrolladores y los operadores en tu infraestructura de nube. Crea y promueve programas de aprendizaje mediante clases tradicionales o en línea, grupos de discusión, revisiones entre compañeros, programación en pareja y juegos que ahorren costos. Como se muestra en la investigación de DORA de Google, la cultura organizacional es un impulsor clave para mejorar el rendimiento, reducir la repetición del trabajo y el agotamiento, y optimizar los costos. Cuando proporcionas a los empleados visibilidad del costo de sus recursos, los ayudas a alinear sus prioridades y actividades con los objetivos y las limitaciones comerciales.

Compute Engine

En esta sección, se proporciona orientación para ayudarte a optimizar el costo de los recursos de Compute Engine. Además de esta guía, te recomendamos que sigas las recomendaciones generales que se analizaron antes.

Comprende el modelo de facturación

Para obtener más información sobre las opciones de facturación de Compute Engine, consulta Precios.

Analiza el consumo de recursos

Para ayudarte a comprender el consumo de recursos en Compute Engine, exporta datos de uso a BigQuery. Consulta el almacén de datos de BigQuery para analizar las tendencias de uso de CPU virtual (vCPU) de tu proyecto y determinar la cantidad de CPU virtuales que puedes reclamar. Si definiste umbrales para la cantidad de núcleos por proyecto, analiza las tendencias de uso a fin de detectar anomalías y tomar medidas correctivas.

Recupera recursos inactivos

Usa las siguientes recomendaciones para identificar y reclamar VM y discos sin usar, como las VM de proyectos de prueba de concepto a los que se les quitó la prioridad:

  • Usa el recomendador de VM inactivas para identificar las VM inactivas y los discos persistentes en función de las métricas de uso.
  • Antes de borrar recursos, evalúa el impacto potencial de la acción y planifica volver a crear los recursos si es necesario.
  • Antes de borrar una VM, considera tomar una instantánea. Cuando borras una VM, se borran los discos conectados, a menos que hayas seleccionado la opción Conservar disco.
  • Cuando sea posible, considera detener las VM en lugar de borrarlas. Cuando detienes una VM, la instancia se cancela, pero los discos y las direcciones IP se conservan hasta que los desconectes o los borres.

Ajusta la capacidad para que coincida con la demanda

Programe las VMs para que se inicien y se detengan de forma automática. Por ejemplo, si una VM se usa solo ocho horas al día durante cinco días a la semana (es decir, 40 horas en la semana), puedes reducir los costos en un 75% si detienes la VM durante las 128 horas en la semana en las que la VM no se usa.

Ajusta automáticamente la escala de la capacidad de procesamiento según la demanda mediante grupos de instancias administrados. Puedes ajustar la escala de la capacidad automáticamente según los parámetros que son importantes para tu empresa (por ejemplo, el uso de CPU o la capacidad de balanceo de cargas).

Elige los tipos de máquina adecuados

Ajusta el tamaño de las VM para que coincidan con los requisitos de procesamiento de la carga de trabajo mediante el recomendador de tipos de máquinas de VM.

Para cargas de trabajo con requisitos de recursos predecibles, adapta el tipo de máquina a tus necesidades y ahorra dinero con VM personalizadas.

Para las cargas de trabajo de procesamiento por lotes que son tolerantes a errores, considera usar VMs Spot. La computación de alto rendimiento (HPC), los macrodatos, la transcodificación de medios, las canalizaciones de integración continua y entrega continua (CI/CD) y las aplicaciones web sin estado son ejemplos de cargas de trabajo que se pueden implementar en VMs Spot. Para ver un ejemplo de cómo Descartes Labs redujo los costos de análisis mediante VMs interrumpibles (la versión anterior de las VMs Spot) a fin de procesar imágenes satelitales, consulta el caso de éxito de Descartes Labs.

Evalúa las opciones de licencia

Cuando migras cargas de trabajo de terceros a Google Cloud, es posible que puedas reducir los costos si usas licencias adquiridas por el usuario (BYOL). Por ejemplo, para implementar VM de Microsoft Windows Server, en lugar de usar una imagen premium que genere un costo adicional por la licencia de terceros, puedes crear y usar una imagen de BYOL de Windows personalizada. Solo pagas por la infraestructura de VM que usas en Google Cloud. Esta estrategia te ayuda a descubrir el valor de tus inversiones existentes en licencias de terceros.

Si decides usar un enfoque BYOL, te recomendamos que hagas lo siguiente:

  • Aprovisiona la cantidad necesaria de núcleos de CPU de procesamiento sin importar la memoria mediante tipos personalizados de máquinas y limita el costo de las licencias de terceros a la cantidad de núcleos de CPU que necesitas.
  • Reduce la cantidad de CPU virtuales por núcleo de 2 a 1 mediante la inhabilitación de los multiprocesos simultáneos (SMT) y reduce tus costos de licencia en un 50%.

Si tus cargas de trabajo de terceros necesitan hardware dedicado para cumplir con los requisitos de seguridad o cumplimiento, puedes usar tus propias licencias en nodos de usuario único.

Google Kubernetes Engine

En esta sección, se proporciona orientación para ayudarte a optimizar el costo de los recursos de GKE.

Además de las siguientes recomendaciones, consulta las recomendaciones generales que se analizaron antes:

  • Usa GKE Autopilot para permitir que GKE maximice la eficiencia de la infraestructura de tu clúster. No necesitas supervisar el estado de los nodos, controlar la compresión ni calcular la capacidad que necesitan las cargas de trabajo.
  • Ajusta el ajuste de escala automático de GKE mediante el Horizontal Pod Autoscaler (HPA), el escalador automático vertical de pods (VPA) El escalador automático del clúster (CA) o el aprovisionamiento automático de nodos según los requisitos de la carga de trabajo.
  • Para cargas de trabajo por lotes que no son sensibles a la latencia de inicio, usa el perfil de ajuste de escala automático de optimización-utilización para ayudar a mejorar el uso del clúster.
  • Usa el aprovisionamiento automático de nodos para extender el escalador automático del clúster de GKE y crea y borra grupos de nodos de forma eficiente según las especificaciones de pods pendientes sin exceso de aprovisionamiento.
  • Usa grupos de nodos diferentes: un grupo de nodos estáticos para la carga estática y grupos de nodos dinámicos con grupos de ajuste de escala automático de clústeres para las cargas dinámicas.
  • Usa VMs Spot para los grupos de nodos de Kubernetes cuando tus pods sean tolerantes a errores y puedan finalizar sin problemas en menos de 25 segundos. En combinación con el escalador automático de clústeres de GKE, esta estrategia te ayuda a garantizar que el grupo de nodos con VMs de menor costo (en este caso, el grupo de nodos con VMs Spot) escale primero.
  • Elige tipos de máquinas rentables (por ejemplo: E2, N2D) T2D), que proporcionan una relación precio-rendimiento entre un 20% y un 40% más alta.
  • Usa la medición del uso de GKE para analizar los perfiles de uso de los clústeres por espacios de nombres y etiquetas. Identifica el equipo o la aplicación que más gasta, el entorno o el componente que causó aumentos repentinos en el uso o el costo, y el equipo que desperdicia recursos.
  • Usa cuotas de recursos en clústeres de multiusuarios para evitar que cualquier usuario use más de lo que se le asigna de los recursos de clúster.
  • Programa un ajuste de escala automático de los entornos de desarrollo y prueba después de las horas hábiles.
  • Sigue las prácticas recomendadas para ejecutar aplicaciones de Kubernetes con optimización de costos en GKE.

Cloud Run

En esta sección, se proporciona orientación para ayudarte a optimizar el costo de los recursos de Cloud Run.

Además de las siguientes recomendaciones, consulta las recomendaciones generales que se analizaron antes:

  • Ajusta la configuración de simultaneidad (configuración predeterminada: 80) para reducir los costos. Cloud Run determina la cantidad de solicitudes que se enviarán a una instancia según el uso de CPU y memoria. Mediante el aumento de la simultaneidad de las solicitudes, puedes reducir la cantidad de instancias necesarias.
  • Establece un límite para la cantidad de instancias que se pueden implementar.
  • Estima la cantidad de instancias que se requieren mediante la métrica Tiempo de instancia facturable. Por ejemplo, si la métrica muestra 100s/s, se programaron alrededor de 100 instancias. Agrega un búfer del 30% a fin de conservar el rendimiento, es decir, 130 instancias para 100 s/s de tráfico.
  • Para reducir el impacto de los inicios en frío, configura una cantidad mínima de instancias. Cuando estas instancias están inactivas, se facturan a un décimo del precio.
  • Realiza un seguimiento del uso de la CPU y ajusta los límites de la CPU según corresponda.
  • Usa la administración del tráfico para determinar una configuración con un costo óptimo.
  • Considera usar Cloud CDN o Firebase Hosting para entregar elementos estáticos.
  • En el caso de las apps de CloudRun que controlan solicitudes a nivel global, considera implementar la app en varias regiones, puesto que el tráfico de salida entre continentes puede ser costoso. Se recomienda este diseño si usas un balanceador de cargas y una CDN.
  • Reduce los tiempos de inicio de tus instancias, puesto que el tiempo de inicio también es facturable.
  • Compra descuentos por compromiso de uso y ahorra hasta un 17% en los precios según demanda por un compromiso de un año.

Cloud Functions

En esta sección, se proporciona orientación para ayudarte a optimizar el costo de tus recursos de Cloud Functions.

Además de las siguientes recomendaciones, consulta las recomendaciones generales que se analizaron antes:

  • Observa el tiempo de ejecución de tus funciones. Experimenta y compara para diseñar la función más pequeña que aún cumpla con tu umbral de rendimiento requerido.
  • Si tus cargas de trabajo de Cloud Functions se ejecutan de forma constante, considera usar GKE o Compute Engine para manejarlas. Los contenedores o las VM pueden ser opciones de menor costo para las cargas de trabajo que se ejecutan siempre.
  • Limita la cantidad de instancias de función que pueden coexistir.
  • Compara el rendimiento del entorno de ejecución de los lenguajes de programación de Cloud Functions con la carga de trabajo de tu función. Los programas en lenguajes compilados tienen inicios en frío más largos, pero se ejecutan más rápido. Los programas en lenguajes interpretados se ejecutan más lento, pero tienen una sobrecarga de inicio en frío más baja. Las funciones cortas y sencillas que se ejecutan con frecuencia pueden costar menos en un lenguaje interpretado.
  • Borra los archivos temporales escritos en el disco local, que es un sistema de archivos en la memoria. Los archivos temporales consumen memoria que se asigna a tu función y, a veces, persisten entre invocaciones. Si no borras estos archivos, puede producirse un error de memoria insuficiente y activarse un inicio en frío, lo que aumenta el tiempo de ejecución y el costo.

App Engine

En esta sección, se proporciona orientación para ayudarte a optimizar el costo de tus recursos de App Engine.

Además de las siguientes recomendaciones, consulta las recomendaciones generales que se analizaron antes:

  • Establece la cantidad máxima de instancias en función del tráfico y la latencia de las solicitudes. Por lo general, App Engine escala la capacidad según el tráfico que reciben las aplicaciones. Puedes controlar el costo si limitas la cantidad de instancias que App Engine puede crear.
  • A fin de limitar la memoria o la CPU disponible para tu aplicación, configura una clase de instancia. Para aplicaciones con uso intensivo de CPU, asigna más CPU. Prueba algunos parámetros de configuración para determinar el tamaño óptimo.
  • Compara tu carga de trabajo de App Engine en varios lenguajes de programación. Por ejemplo, una carga de trabajo implementada en un lenguaje podría necesitar menos instancias y tener un menor costo para completar tareas a tiempo que la misma carga de trabajo programada en otro lenguaje.
  • Optimiza para tener menos inicios en frío. Cuando sea posible, reduce las tareas de uso intensivo de CPU o de larga duración que se producen en el alcance global. Prueba dividir la tarea en operaciones más pequeñas, que se puedan “cargar de forma diferida” en el contexto de una solicitud.
  • Si esperas tráfico inestable, configura una cantidad mínima de instancias inactivas que estén preparadas de forma previa. Si no esperas tráfico, puedes configurar las instancias inactivas mínimas en cero.
  • Para equilibrar el rendimiento y el costo, ejecuta una prueba A/B mediante la división del tráfico entre dos versiones, cada una con una configuración diferente. Supervisa el rendimiento y el costo de cada versión, realiza ajustes según sea necesario y decide la configuración a la que se debe enviar el tráfico.
  • Configura la simultaneidad de solicitudes y establece un valor máximo de solicitudes simultáneas más alto que la configuración predeterminada. Cuantas más solicitudes maneje simultáneamente cada instancia, más eficiente será el uso de las instancias existentes para entregar tráfico.

¿Qué sigue?

Optimiza el costo: Almacenamiento

En este documento de framework de arquitectura de Google Cloud, se proporcionan recomendaciones para ayudarte a optimizar el uso y el costo de tus recursos de Cloud Storage, Persistent Disk y Filestore.

La guía de esta sección está destinada a los arquitectos y administradores responsables de aprovisionar y administrar el almacenamiento para las cargas de trabajo en la nube.

Cloud Storage

Cuando planifiques Cloud Storage para tus cargas de trabajo, ten en cuenta los requisitos de rendimiento, retención de datos y patrones de acceso.

Clase de almacenamiento

Elige una clase de almacenamiento que se adapte a los requisitos de retención de datos y frecuencia de acceso de tus cargas de trabajo, como se recomienda en la siguiente tabla:

Requisito de almacenamiento Recomendación
Datos a los que se accede con frecuencia (estadísticas de alta capacidad de procesamiento o data lakes, sitios web, videos en streaming y aplicaciones para dispositivos móviles) Standard Storage
Almacenamiento de bajo costo para datos a los que se accede con poca frecuencia que se pueden almacenar durante al menos 30 días (por ejemplo, copias de seguridad y contenido multimedia de cola larga). Nearline Storage
Datos de acceso infrecuente que se pueden almacenar por al menos 90 días (por ejemplo, réplicas de datos para la recuperación ante desastres) Coldline Storage
Almacenamiento de menor costo para datos a los que se accede con poca frecuencia que se pueden almacenar durante al menos 365 días (por ejemplo, archivos legales y normativos). Archive Storage

Location

Selecciona la ubicación para tus buckets según los requisitos de rendimiento, disponibilidad y redundancia de datos.

  • Las regiones se recomiendan cuando la región está cerca de los usuarios finales. Puedes seleccionar una región específica y obtener redundancia garantizada dentro de la región. Las regiones ofrecen almacenamiento rápido, redundante y asequible para los conjuntos de datos a los que los usuarios dentro de un área geográfica particular acceden con frecuencia.
  • Las multirregiones ofrecen alta disponibilidad para los usuarios distribuidos. Sin embargo, el costo de almacenamiento es más alto que el de las regiones. Los buckets multirregionales se recomiendan para los casos de uso de entrega de contenido y las cargas de trabajo de estadísticas de baja gama.
  • Las regiones dobles proporcionan alta disponibilidad y redundancia de datos. Google recomienda buckets de región doble para cargas de trabajo de estadísticas de alto rendimiento y para casos de uso que requieren buckets verdaderos de activo a activo con procesamiento y almacenamiento en varias ubicaciones. Las regiones dobles te permiten elegir dónde se almacenan tus datos, lo que puede ayudarte a cumplir con los requisitos de cumplimiento. Por ejemplo, puedes usar un bucket de región doble para cumplir con los requisitos específicos de la industria relacionados con la distancia física entre las copias de tus datos en la nube.

Políticas de ciclo de vida

Optimiza el costo de almacenamiento de tus objetos en Cloud Storage mediante la definición de políticas de ciclo de vida. Estas políticas te ayudan a ahorrar dinero, ya que cambian automáticamente a una versión inferior la clase de almacenamiento de los objetos específicos o borran los objetos según las condiciones que establezcas.

Configura las políticas de ciclo de vida según la frecuencia con la que se accede a los objetos y el tiempo que necesitas conservarlos. Los siguientes son ejemplos de políticas de ciclo de vida:

  • Política de cambio a una versión inferior: se espera que se acceda a un conjunto de datos con frecuencia, pero durante solo tres meses. Si quieres optimizar el costo de almacenamiento de este conjunto de datos, usa Standard Storage y configura una política de ciclo de vida para cambiar los objetos con más de 90 días de antigüedad a Coldline Storage.
  • Política de eliminación: un conjunto de datos debe conservarse durante 365 días para cumplir con ciertos requisitos legales y se puede borrar después de ese período. Configura una política para borrar cualquier objeto que tenga más de 365 días.

    A fin de ayudarte a garantizar que los datos que se deben conservar durante un período específico (para el cumplimiento legal o normativo) no se borren antes de esa hora y fecha, configura los bloqueos de políticas de retención.

Responsabilidad

Para impulsar la responsabilidad de los cargos operativos, los cargos de red y el costo de recuperación de datos, usa la configuración de Pagos del solicitante cuando corresponda. Con esta configuración, los costos se cobran al departamento o equipo que usa los datos, en lugar de al propietario.

Define y asigna etiquetas de seguimiento de costos de manera coherente para todos tus buckets y objetos. Automatiza el etiquetado cuando sea posible.

Redundancia

Usa las siguientes técnicas para mantener la redundancia de almacenamiento requerida sin duplicación de datos:

  • Para mantener la resiliencia de los datos con una sola fuente de información, usa un bucket de región doble o múltiple en lugar de copias redundantes de datos en diferentes buckets. Los buckets birregionales y multirregionales proporcionan redundancia en todas las regiones. Los datos se replican de forma asíncrona en dos o más ubicaciones y están protegidos contra las interrupciones regionales.
  • Si habilitas el control de versiones de objetos, considera definir políticas de ciclo de vida para quitar la versión más antigua de un objeto a medida que las versiones más recientes se vuelven no actuales. Cada versión no actual de un objeto se cobra a la misma tarifa que su versión publicada.
  • Inhabilita las políticas de control de versiones de objetos cuando ya no sean necesarias.
  • Revisa las políticas de copia de seguridad y retención de instantáneas de forma periódica y ajústalas para evitar copias de seguridad y retención de datos innecesarias.

Persistent Disk

Cada instancia de VM que implementas en Compute Engine tiene un disco de arranque y, de manera opcional, uno o más discos de datos. Cada disco genera un costo en función del tamaño, la región y el tipo de disco aprovisionados. Las instantáneas que tomes de tus discos generan costos según el tamaño de la instantánea.

Usa las siguientes recomendaciones operativas y de diseño para optimizar el costo de los discos persistentes:

  • No sobreasignes el espacio en el disco. No puedes reducir la capacidad del disco después del aprovisionamiento. Comienza con un disco pequeño y aumenta el tamaño cuando sea necesario. Los discos persistentes se facturan por la capacidad aprovisionada, no por los datos almacenados en los discos.
  • Elige un tipo de disco que coincida con las características de rendimiento de tu carga de trabajo. SSD ofrece IOPS y capacidad de procesamiento altos, pero cuesta más que los discos persistentes estándar.

  • Usa los discos persistentes regionales solo cuando la protección de los datos contra interrupciones zonales sea esencial. Los discos persistentes regionales se replican en otra zona dentro de la región, por lo que se genera el doble de costo que los discos zonales equivalentes.

  • Realiza un seguimiento del uso de tus discos persistentes mediante Cloud Monitoring y configura alertas para los discos con uso bajo.

  • Borra los discos que ya no necesitas.

  • Para los discos que contienen datos que podrías necesitar en el futuro, considera archivar los datos en Cloud Storage de bajo costo y, luego, borrarlos.

  • Busca y responde las recomendaciones en el Centro de recomendaciones.

Considera también usar hiperdiscos para el almacenamiento de alto rendimiento y discos efímeros (SSD locales) para el almacenamiento temporal.

Las instantáneas de disco son incrementales de forma predeterminada y se comprimen de forma automática. Considera las siguientes recomendaciones para optimizar el costo de las instantáneas de disco:

  • Cuando sea posible, organiza tus datos en discos persistentes distintos. Luego, puedes elegir crear copias de seguridad de los discos de forma selectiva y reducir el costo de las instantáneas de discos.
  • Cuando creas una instantánea, selecciona una ubicación según tus requisitos de disponibilidad y los costos de red asociados.
  • Si deseas usar una instantánea de disco de arranque para crear varias VM, crea una imagen a partir de la instantánea y, luego, usa la imagen a fin de crear tus VM. Este enfoque te ayuda a evitar cargos de red por los datos que se transfieren entre la ubicación de la instantánea y la ubicación en la que la restableces.
  • Considera configurar una política de retención a fin de minimizar los costos de almacenamiento a largo plazo para las instantáneas de discos.
  • Borra las instantáneas de discos que ya no necesitas. Cada instantánea en una cadena puede depender de los datos almacenados en una instantánea anterior. Por lo tanto, si borras una instantánea, no siempre se borran todos los datos de la instantánea. Para borrar de forma definitiva los datos de las instantáneas, debes borrar todas las instantáneas de la cadena.

Filestore

El costo de una instancia de Filestore depende de su nivel de servicio, la capacidad aprovisionada y la región en la que se aprovisiona la instancia. Las siguientes son recomendaciones operativas y de diseño para optimizar el costo de las instancias de Filestore:

  • Selecciona un nivel de servicio y un tipo de almacenamiento (HDD o SSD) que sea adecuado para tus necesidades de almacenamiento.
  • No asignes más capacidad. Comienza con un tamaño pequeño y auméntalo más tarde cuando sea necesario. La facturación de Filestore se basa en la capacidad aprovisionada, no en los datos almacenados.
  • Cuando sea posible, organiza tus datos en instancias de Filestore diferentes. Luego, puedes optar por crear copias de seguridad de las instancias de forma selectiva y reducir el costo de las copias de seguridad de Filestore.
  • Cuando elijas la región y la zona, considera crear instancias en la misma zona que los clientes. Se te factura por el tráfico de transferencia de datos desde la zona de la instancia de Filestore.
  • Cuando decidas la región en la que deben almacenarse las copias de seguridad de Filestore, considera los cargos por transferencia de datos para almacenar copias de seguridad en una región diferente a la de la instancia de origen.
  • Realiza un seguimiento del uso de tus instancias de Filestore mediante Cloud Monitoring y configura alertas para las instancias con uso bajo.
  • Reducir la escala verticalmente de la capacidad asignada para las instancias de Filestore que tienen un uso bajo. Puedes reducir la capacidad de las instancias, excepto el nivel Básico.

¿Qué sigue?

Optimiza el costo: Bases de datos y analíticas inteligentes

En este documento del framework de arquitectura de Google Cloud, se proporcionan recomendaciones para ayudarte a optimizar el costo de las bases de datos y las cargas de trabajo de analíticas en Google Cloud.

La guía de esta sección está dirigida a arquitectos, desarrolladores y administradores responsables de aprovisionar y administrar las cargas de trabajo de analíticas y bases de datos en la nube.

En esta sección, se incluyen recomendaciones de optimización de costos para los siguientes productos:

Cloud SQL

Cloud SQL es un servicio de base de datos relacional completamente administrado para MySQL, PostgreSQL y SQL Server.

Supervisa el uso

Revisa las métricas en el panel de supervisión y valida que la implementación cumpla con los requisitos de la carga de trabajo.

Optimizar los recursos

Las siguientes son recomendaciones para ayudarte a optimizar tus recursos de Cloud SQL:

  • Diseña una estrategia de alta disponibilidad y recuperación ante desastres que se alinee con tu objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Según tu carga de trabajo, recomendamos lo siguiente:
  • Aprovisionar la base de datos con la capacidad de almacenamiento mínima requerida.
  • Para escalar la capacidad de almacenamiento de forma automática a medida que los datos crecen, habilita la función de aumento de almacenamiento automático.
  • Elige un tipo de almacenamiento, unidades de estado sólido (SSD) o unidades de disco duro (HDD), que sea adecuado para tu caso de uso. El almacenamiento SSD es la elección más eficiente y rentable para la mayoría de los casos de uso. El almacenamiento HDD puede ser adecuado para conjuntos de datos grandes (más de 10 TB) que no sean sensibles a la latencia o a los que se accede con poca frecuencia.

Optimiza las tarifas

Considera adquirir descuentos por compromiso de uso para cargas de trabajo con necesidades de recursos predecibles. Puedes ahorrar el 25% de los precios según demanda con un compromiso de 1 año y el 52% con un compromiso de 3 años.

Spanner

Spanner es una base de datos nativa de la nube, de escalamiento ilimitado y de coherencia sólida que ofrece una disponibilidad de hasta un 99.999%.

Supervisa el uso

Las siguientes son recomendaciones para ayudarte a hacer un seguimiento del uso de tus recursos de Spanner:

  • Supervisa tu implementación y configura el recuento de nodos en función de las recomendaciones de CPU.
  • Configura alertas en tus implementaciones para optimizar los recursos de almacenamiento. A fin de determinar la configuración adecuada, consulta los límites por nodo recomendados.

Optimizar los recursos

Las siguientes son recomendaciones para ayudarte a optimizar tus recursos de Spanner:

  • Ejecuta cargas de trabajo más pequeñas en Spanner a un costo mucho menor mediante el aprovisionamiento de recursos con unidades de procesamiento (PU) en comparación con los nodos; un nodo de Spanner equivale a 1,000 PU.
  • Mejora el rendimiento de la ejecución de consultas mediante el optimizador de consultas.
  • Crea instrucciones de SQL mediante prácticas recomendadas para crear planes de ejecución eficientes.
  • Administra el uso y el rendimiento de las implementaciones de Spanner con la herramienta escalador automático. La herramienta supervisa instancias, agrega o quita nodos de forma automática y te ayuda a garantizar que las instancias permanezcan dentro de los límites de CPU y almacenamiento recomendados.
  • Protege contra escrituras o eliminaciones accidentales mediante la recuperación de un momento determinado (PITR). Las bases de datos con períodos de retención de versiones más largos (en especial, las que reemplazan los datos con frecuencia) usan más recursos del sistema y necesitan más nodos.
  • Revisa tu estrategia de copia de seguridad y elige entre las siguientes opciones:
    • copia de seguridad y restauración
    • Importar y exportar

Optimiza las tarifas

Cuando decidas la ubicación de tus nodos de Spanner, ten en cuenta las diferencias de costos entre las regiones de Google Cloud. Por ejemplo, un nodo que se implementa en la región us-central1 cuesta mucho menos por hora que un nodo en la región southamerica-east1.

Bigtable

Bigtable es un almacenamiento NoSQL nativo de la nube y de columnas anchas para cargas de trabajo a gran escala y de baja latencia.

Supervisa el uso

Las siguientes son recomendaciones para ayudarte a hacer un seguimiento del uso de tus recursos de Bigtable:

  • Analiza las métricas de uso para identificar oportunidades de optimización de los recursos.
  • Identifica hotspots y teclas de acceso rápido en tu clúster de Bigtable con la herramienta de diagnóstico Key Visualizer.

Optimizar los recursos

Las siguientes son recomendaciones para ayudarte a optimizar tus recursos de Bigtable:

  • Para ayudarte a garantizar el uso de CPU y del disco que proporciona un equilibrio entre la latencia y la capacidad de almacenamiento, evalúa y ajusta el recuento de nodos y el tamaño del clúster de Bigtable.
  • Mantén el rendimiento al menor costo posible mediante el escalamiento programático de tu clúster de Bigtable para ajustar el recuento de nodos de forma automática.
  • Evalúa el tipo de almacenamiento más rentable (HDD o SSD) para tu caso de uso, en función de las siguientes consideraciones:

    • El almacenamiento HDD cuesta menos que el SSD, pero tiene un rendimiento menor.
    • El almacenamiento SSD cuesta más que el HDD, pero proporciona un rendimiento más rápido y predecible.

    Los ahorros en los costos que proporciona HDD son mínimos, en relación con el costo de los nodos en el clúster de Bigtable, a menos que almacenes grandes cantidades de datos. El almacenamiento HDD a veces es adecuado para conjuntos de datos grandes (más de 10 TB) que no sean sensibles a la latencia o a los que se accede muy poco.

  • Quita los datos vencidos y obsoletos mediante la recolección de elementos no utilizados.

  • A fin de evitar los hotspots, aplica las prácticas recomendadas para el diseño de claves de filas.

  • Diseña un plan de copia de seguridad rentable que se alinee con tu RPO.

  • A fin de reducir el uso del clúster y disminuir el recuento de nodos, considera agregar una caché de capacidad para las consultas que pueden almacenarse en caché mediante Memorystore.

Lecturas adicionales

BigQuery

BigQuery es un almacén de datos de múltiples nubes sin servidores, rentable y altamente escalable, diseñado para lograr agilidad empresarial.

Supervisa el uso

Las siguientes son recomendaciones para ayudarte a hacer un seguimiento del uso de tus recursos de BigQuery:

  • Visualiza los costos de BigQuery segmentados por proyectos y usuarios. Identifica las consultas más costosas y optimízalas.
  • Analiza el uso de ranuras en proyectos, trabajos y reservas mediante las tablas de metadatos INFORMATION_SCHEMA.

Optimizar los recursos

Las siguientes son recomendaciones para ayudarte a optimizar tus recursos de BigQuery:

Optimiza las tarifas

Las siguientes son recomendaciones para ayudarte a reducir las tarifas de facturación de tus recursos de BigQuery:

  • Evalúa cómo editas los datos y aprovecha los precios de almacenamiento a largo plazo más bajos.
  • Revisa las diferencias entre los precios de tarifa plana y según demanda y elige una opción que se adapte a tus requisitos.
  • Evalúa si puedes usar la carga por lotes en lugar de inserciones de transmisión para tus flujos de trabajo de datos. Usa las inserciones de transmisión si los datos cargados en BigQuery se consumen de inmediato.
  • Para aumentar el rendimiento y reducir el costo de recuperación de datos, usa los resultados de consultas almacenados en caché.

Lecturas adicionales

Dataflow

Dataflow es un servicio sin servidores rápido y rentable para el procesamiento unificado de datos por lotes y de transmisión.

Supervisa el uso

Las siguientes son recomendaciones para ayudarte a hacer un seguimiento del uso de tus recursos de Dataflow:

Optimizar los recursos

Las siguientes son recomendaciones para ayudarte a optimizar tus recursos de Dataflow:

  • Considera usar Dataflow Prime para procesar macrodatos de manera eficiente.
  • Reduce los costos de procesamiento por lotes usando la programación flexible de recursos (FlexRS) para canalizaciones por lotes con ajuste de escala automático. FlexRS usa programación avanzada, Dataflow Shuffle y una combinación de VMs interrumpibles y normales para reducir el costo de las canalizaciones por lotes.
  • Mejora el rendimiento utilizando el servicio de Shuffle en la memoria, en lugar de Persistent Disk y nodos trabajadores.
  • Para obtener un ajuste de escala automático más responsivo y reducir el consumo de recursos, usa Streaming Engine, que quita la ejecución de la canalización de las VMs de trabajador y la traslada hacia el backend del servicio de Dataflow.
  • Si la canalización no necesita acceso desde y hacia Internet y otras redes de Google Cloud, inhabilita las direcciones IP públicas. Inhabilitar el acceso a Internet te ayuda a reducir los costos de red y a mejorar la seguridad de la canalización.
  • Sigue las prácticas recomendadas para la canalización eficiente con Dataflow.

Dataproc

Dataproc es un servicio administrado de Apache Spark y Apache Hadoop para el procesamiento por lotes, las consultas, la transmisión y el aprendizaje automático.

Las siguientes son recomendaciones para ayudarte a optimizar el costo de tus recursos de Dataproc:

¿Qué sigue?

Optimiza el costo: Herramientas de redes

En este documento del framework de arquitectura de Google Cloud, se proporcionan recomendaciones para ayudarte a optimizar el costo de los recursos de red en Google Cloud.

La guía de esta sección está destinada a los arquitectos y administradores responsables de aprovisionar y administrar las herramientas de red para las cargas de trabajo en la nube.

Consideraciones del diseño

Una diferencia fundamental entre las redes locales y las de la nube es el modelo de costos dinámico y basado en el uso en la nube, en comparación con el costo fijo de las redes en los centros de datos tradicionales.

Cuando planificas redes de nube, es fundamental comprender el modelo de precios, que se basa en la dirección del tráfico de la siguiente manera:

  • No se generan cargos por el tráfico entrante a Google Cloud. Los recursos que procesan el tráfico entrante, como Cloud Load Balancing, generan costos.
  • Para el tráfico de transferencia de datos, que incluye el tráfico entre máquinas virtuales (VMs) en Google Cloud y el tráfico de Google Cloud a Internet y a los hosts locales, los precios se basan en los siguientes factores:
    • Si el tráfico usa una dirección IP interna o externa
    • Si el tráfico cruza los límites de la zona o región
    • Si el tráfico sale de Google Cloud
    • La distancia que recorre el tráfico antes de salir de Google Cloud

Cuando dos VMs o recursos de nube dentro de Google Cloud se comunican, el tráfico en cada dirección se designa como transferencia de datos saliente en la transferencia de datos de origen y entrante en el destino y se cobra según corresponda.

Considere los siguientes factores para diseñar redes de nube con un costo óptimo:

  • Ubicación geográfica
  • Diseño de red
  • Opciones de conectividad
  • Niveles de servicio de red
  • Logging

Estos factores se analizan con más detalle en las siguientes secciones.

Ubicación geográfica

Los costos de las herramientas de redes pueden variar según la región de Google Cloud en la que se aprovisionan los recursos. Para analizar el ancho de banda de red entre regiones, puedes usar registros de flujo de VPC y Network Intelligence Center. Para el tráfico que fluye entre las regiones de Google Cloud, el costo puede variar según la ubicación de las regiones, incluso si el tráfico no pasa por Internet.

Además de la región de Google Cloud, considera las zonas en las que se implementan los recursos. Según los requisitos de disponibilidad, es posible que puedas diseñar tus aplicaciones para que se comuniquen sin costo dentro de una zona a través de direcciones IP internas. Cuando consideres una arquitectura de una sola zona, considera los posibles ahorros en costos de herramientas de red con el impacto en la disponibilidad.

Diseño de red

Analiza el diseño de tu red, cómo fluye el tráfico entre tus aplicaciones y usuarios, y el ancho de banda consumido por cada aplicación o usuario. La herramienta Topología de red proporciona una visibilidad completa de tu implementación global de Google Cloud y su interacción con la Internet pública, incluida una vista de la topología de toda la organización y las métricas de rendimiento de red asociadas. Puedes identificar implementaciones ineficientes y tomar las medidas necesarias para optimizar los costos de transferencia de datos intercontinentales y regionales.

Opciones de conectividad

Cuando necesites enviar un gran volumen de datos (TB o PB) con frecuencia desde entornos locales a Google Cloud, considera usar una interconexión dedicada o interconexión de socio. Una conexión dedicada puede ser más económica en comparación con los costos asociados con el uso de la Internet pública o de una VPN.

Usa el Acceso privado a Google cuando sea posible para reducir los costos y mejorar tu postura de seguridad.

Niveles de servicio de red

La infraestructura de red Premium de Google (nivel Premium) se usa de forma predeterminada para todos los servicios. Para los recursos que no necesitan el alto rendimiento y la baja latencia que ofrece el nivel Premium, puedes elegir el nivel Estándar, que cuesta menos.

Cuando elijas un nivel de servicio, ten en cuenta las diferencias entre los niveles y las limitaciones del nivel Estándar. Ajusta la red a las necesidades de tu aplicación y, potencialmente, reduce el costo de red para los servicios que pueden tolerar más latencia y no requieren un ANS.

Logging

Los registros de flujo de VPC, el registro de reglas de firewall y el registro de Cloud NAT te permiten analizar los registros de la red e identificar oportunidades para optimizar los costos.

Para los registros de flujo de VPC y Cloud Load Balancing, también puedes habilitar el muestreo, que puede reducir el volumen de registros escritos en la base de datos. Puedes variar la tasa de muestreo de 1.0 (se conservan todas las entradas de registro) a 0.0 (no se conserva ningún registro). Para solucionar problemas o casos prácticos personalizados, puedes elegir recopilar siempre la telemetría de una red o subred de VPC en particular, o supervisar una instancia de VM o una interfaz virtual específica.

Recomendaciones de diseño

Para optimizar el tráfico de red, recomendamos lo siguiente:

  • Diseña tus soluciones para acercar las aplicaciones a tu base de usuarios. Usa Cloud CDN para reducir el volumen de tráfico y la latencia, y aprovecha los precios más bajos de CDN a fin de entregar contenido al que esperas que muchos usuarios accedan con frecuencia.
  • Evita sincronizar los datos de manera global en regiones distantes del usuario final o que puedan generar costos de red altos. Si una aplicación se usa solo dentro de una región, evita el procesamiento de datos entre regiones.
  • Asegúrate de que la comunicación entre las VM dentro de una zona se enrute a través de sus direcciones IP internas y no de forma externa.
  • Reduce el costo de la transferencia de datos y la latencia del cliente a través de la compresión de los resultados de datos.
  • Para analizar los patrones de gasto y, además, identificar las oportunidades de controlar los costos, observa los flujos de tráfico entrante y saliente para los proyectos críticos con los registros de flujo de VPC.
  • Cuando diseñes tus redes en la nube, considera la compensación entre la alta disponibilidad que ofrece una red distribuida y los ahorros de costos por centralizar el tráfico dentro de una sola zona o región.

Para optimizar el precio que pagas por los servicios de herramientas de redes, te recomendamos lo siguiente:

  • Si la ubicación del servidor no es una restricción, evalúa el costo en diferentes regiones y selecciona la región más rentable. Para el tráfico saliente general, como el contenido que entrega un grupo de servidores web, los precios pueden variar según la región en la que se aprovisionan los servidores.
  • Para reducir el costo de mover grandes volúmenes de datos con frecuencia a la nube, usa una conexión directa entre las redes locales y de Google Cloud. Considera usar una interconexión dedicada o interconexión de socio.
  • Elige un nivel de servicio adecuado para cada entorno, es decir, un nivel Estándar en entornos de desarrollo y prueba, y el nivel Premium en producción.

¿Qué sigue?

Optimiza el costo: Operaciones en la nube

En este documento del framework de arquitectura de Google Cloud, se proporcionan recomendaciones para ayudarte a optimizar el costo de supervisar y administrar tus recursos en Google Cloud.

La guía de esta sección está destinada a los usuarios de la nube responsables de supervisar y controlar el uso y el costo de los recursos de su organización en la nube.

Google Cloud Observability es una colección de servicios administrados que puedes usar para supervisar, solucionar problemas y mejorar el rendimiento de las cargas de trabajo en Google Cloud. Estos servicios incluyen Cloud Monitoring, Cloud Logging, Error Reporting, Cloud Trace y Cloud Profiler. Uno de los beneficios de los servicios administrados en Google Cloud es que los servicios se basan en el uso. Solo pagas por lo que usas y por el volumen de datos, con asignaciones de uso de datos mensuales gratuitas y acceso ilimitado a las métricas y los registros de auditoría de Google Cloud.

Cloud Logging

Las siguientes son recomendaciones para ayudarte a optimizar el costo de tus operaciones de Logging:

Cloud Monitoring

Las siguientes son recomendaciones para ayudarte a optimizar el costo de tus operaciones de Monitoring:

  • Limita la cantidad de etiquetas para optimizar las métricas y el uso de etiquetas. Evita las etiquetas con alta cardinalidad. Por ejemplo, si usas una dirección IP como etiqueta, cada dirección IP tendrá una serie de etiquetas de un solo elemento, lo que generará muchas etiquetas cuando tengas muchas VMs.
  • Reduce el volumen de las métricas detalladas para las aplicaciones que no requieren estas métricas o quita el agente de supervisión, en especial, para entornos no esenciales.
  • Reduce la cantidad de métricas personalizadas que envía tu aplicación para minimizar el volumen de transferencia.

Cloud Trace

Las siguientes son recomendaciones para ayudarte a optimizar el costo de tus operaciones de Trace:

  • Si usas Trace como destino de exportación para tus intervalos de OpenCensus, reduce el volumen de intervalos que se transfieren mediante la función de muestreo en OpenCensus.
  • Limitar el uso de Trace y controlar el costo mediante cuotas. Puedes aplicar cuotas de intervalo mediante la página de cuotas específica de la API en la consola de Google Cloud.

¿Qué sigue?

Framework de la arquitectura de Google Cloud: Optimización del rendimiento

En esta categoría de Framework de la arquitectura de Google Cloud, se describe el proceso de optimización del rendimiento y las prácticas recomendadas para optimizar el rendimiento de las cargas de trabajo en Google Cloud.

La información de este documento está dirigida a arquitectos, desarrolladores y administradores que planifican, diseñan, implementan y administran cargas de trabajo en Google Cloud.

Optimiza el rendimiento de las cargas de trabajo en la nube puede ayudar a tu organización a operar de manera eficiente, mejorar la satisfacción del cliente, aumentar los ingresos y reducir los costos. Por ejemplo, cuando el tiempo de procesamiento de backend de una aplicación disminuye, los usuarios experimentan tiempos de respuesta más rápidos, lo que puede generar una mayor retención de usuarios y más ingresos.

Puede haber compensaciones entre el rendimiento y el costo. Sin embargo, optimizar el rendimiento puede ayudarte a reducir costos. Por ejemplo, el ajuste de escala automático proporciona un rendimiento predecible cuando la carga aumenta, ya que garantiza que los recursos no se sobrecarguen. El ajuste de escala automático también te ayuda a reducir costos durante los períodos de carga baja mediante la eliminación de los recursos que no se usan.

En esta categoría de Framework de la arquitectura, aprenderás a hacer lo siguiente:

Proceso de optimización del rendimiento

En este documento de Framework de la arquitectura de Google Cloud, se proporciona una descripción general del proceso de optimización del rendimiento.

La optimización del rendimiento es un proceso continuo, no una actividad única. En el siguiente diagrama, se muestran las etapas del proceso de optimización del rendimiento:

Proceso de optimización del rendimiento

A continuación, se presenta una descripción general de las etapas del proceso de optimización del rendimiento:

Define los requisitos de rendimiento

Antes de comenzar a diseñar y desarrollar las aplicaciones que deseas implementar o migrar a la nube, determina los requisitos de rendimiento. Define los requisitos de la manera más detallada posible para cada capa de la pila de aplicaciones: balanceo de cargas de frontend, servidores web o de aplicaciones, bases de datos y almacenamiento. Por ejemplo, para la capa de almacenamiento de la pila, decide la capacidad de procesamiento y las operaciones de E/S por segundo (IOPS) que tus aplicaciones necesitan.

Implementa y diseña tus aplicaciones

Diseña tus aplicaciones con patrones de diseño elásticos y escalables que puedan ayudarte a cumplir con los requisitos de rendimiento. Considera los siguientes lineamientos para diseñar aplicaciones que sean elásticas y escalables:

  • Diseña las cargas de trabajo para lograr una ubicación de contenido óptima.
  • Aísla el tráfico de lectura y escritura.
  • Aísla el tráfico estático y dinámico.
  • Implementa el almacenamiento en caché del contenido. Usa cachés de datos para capas internas.
  • Usa servicios administrados y arquitecturas sin servidores

Google Cloud proporciona herramientas de código abierto que puedes usar para comparar el rendimiento de los servicios de Google Cloud con otras plataformas en la nube.

Supervisa y analiza el rendimiento

Después de implementar tus aplicaciones, supervisa el rendimiento de forma continua a través de registros y alertas, analiza los datos y también identifica problemas de rendimiento. A medida que tus aplicaciones crezcan y evolucionen, vuelve a evaluar los requisitos de rendimiento. Es posible que tengas que rediseñar algunas partes de las aplicaciones para mantener o mejorar el rendimiento.

Optimiza el rendimiento

Configura los recursos en la nube para que cumplan con los requisitos de rendimiento actuales según el rendimiento de las aplicaciones y los cambios en los requisitos. Por ejemplo, cambia el tamaño de los recursos o configura el ajuste de escala automático. Cuando configures los recursos, evalúa las oportunidades para usar las funciones y servicios de Google Cloud lanzados hace poco que pueden ayudar a optimizar aún más el rendimiento.

En este punto, el proceso de optimización del rendimiento no termina. Continúa el ciclo de supervisión del rendimiento, reevalúa los requisitos cuando sea necesario y ajusta los recursos de la nube para mantener y mejorar el rendimiento.

¿Qué sigue?

Supervisa y analiza el rendimiento

En este documento del framework de arquitectura de Google Cloud, se describen los servicios de Google Cloud Observability que puedes usar para registrar, supervisar y analizar el rendimiento de las cargas de trabajo.

Supervisa las métricas de rendimiento

Usa Cloud Monitoring para analizar las tendencias de las métricas de rendimiento, analizar los efectos de los experimentos, definir alertas de métricas críticas y realizar análisis retrospectivos.

Registra datos y eventos críticos

Cloud Logging es un servicio de registro integrado que puedes usar para almacenar, analizar, supervisar y configurar alertas de eventos y datos de registro. Cloud Logging puede recopilar registros de los servicios de Google Cloud y otros proveedores de servicios en la nube.

Analiza el rendimiento del código

Un código de bajo rendimiento puede aumentar la latencia de las aplicaciones y el costo de ejecutarlas. Cloud Profiler te ayuda a identificar y abordar problemas de rendimiento a través del análisis continuo del rendimiento de las funciones de uso intensivo de CPU o memoria que usa una aplicación.

Recopila datos de latencia

En pilas de aplicaciones complejas y arquitecturas basadas en microservicios, puede ser difícil evaluar la latencia en la comunicación entre servicios y también identificar los cuellos de botella de rendimiento. Las herramientas de Cloud Trace y OpenTelemetry te ayudan a recopilar datos de latencia de las implementaciones a gran escala. Estas herramientas también te ayudan a analizar los datos de latencia de forma eficiente.

Supervisa el rendimiento de la red

El Panel de rendimiento de Network Intelligence Center te ofrece una vista integral de las métricas de rendimiento de la red de Google y los recursos del proyecto. Estas métricas pueden ayudarte a determinar la causa de los problemas de rendimiento relacionados con la red. Por ejemplo, puedes identificar si un problema de rendimiento es el resultado de un problema en tu proyecto o en la red de Google.

¿Qué sigue?

Optimiza el rendimiento del procesamiento

En este documento de Google Cloud Arquitectura Framework, se proporcionan recomendaciones para ayudarte a optimizar el rendimiento de Compute Engine, Google Kubernetes Engine (GKE) y los recursos sin servidores.

Compute Engine

En esta sección, se proporciona orientación para ayudarte a optimizar el rendimiento de los recursos de Compute Engine.

Recursos con ajuste de escala automático

Los grupos de instancias administrados (MIG) te permiten escalar las apps sin estado implementadas en las VMs de Compute Engine de manera eficiente. El ajuste de escala automático ayuda a que tus apps sigan entregando un rendimiento predecible cuando la carga aumente. En un MIG, se inicia un grupo de VMs de Compute Engine según una plantilla que definas. En la plantilla, debes configurar una política de ajuste de escala automático, que especifica una o más señales que el escalador automático usa para escalar el grupo. Los indicadores de ajuste de escala automático pueden basarse en un programa, como la hora de inicio o la duración, o en métricas de destino, como el uso de CPU promedio. Si quieres obtener más información, consulta Ajuste de escala automático para grupos de instancias.

Inhabilita SMT

Cada CPU virtual que asignas a una VM de Compute Engine se implementa como un solo subproceso de hardware único. De forma predeterminada, dos CPU virtuales comparten un núcleo de CPU física. Esta arquitectura se denomina multisubprocesos simultáneos (SMT).

Para cargas de trabajo que son en gran medida paralelas o que realizan cálculos de punto flotante (como transcodificación, simulaciones de Monte Carlo, análisis de secuencias genéticas y modelado de riesgo financiero), puedes mejorar el rendimiento si inhabilitas SMTP. Para obtener más información, consulta Configura una cantidad de subprocesos por núcleo.

Usa GPU

Para cargas de trabajo como aprendizaje automático y visualización, puedes agregar unidades de procesamiento de gráficos (GPU) a tus VMs. Compute Engine proporciona GPU de NVIDIA en modo de transferencia para que tus VMs tengan control directo sobre las GPU y la memoria asociada. Para cargas de trabajo con alto contenido gráfico, como la visualización en 3D, puedes usar las estaciones de trabajo virtuales de NVIDIA RTX. Después de implementar las cargas de trabajo, supervisa el uso de la GPU y revisa las opciones para optimizar el rendimiento de la GPU.

Usa tipos de máquinas optimizados para procesamiento

Las cargas de trabajo como los videojuegos, la transcodificación de medios y la computación de alto rendimiento (HPC) requieren un rendimiento alto y coherente por núcleo de CPU. Google recomienda que uses tipos de máquinas optimizados para procesamiento para las VMs que ejecutan esas cargas de trabajo. Las VMs optimizadas para procesamiento se compilan en una arquitectura que usa funciones como el acceso a la memoria no uniforme (NUMA) para obtener un rendimiento óptimo y confiable.

Las cargas de trabajo de HPC con acoplamiento alto tienen un conjunto único de requisitos para lograr una eficiencia máxima de rendimiento. Para obtener más información, consulta la siguiente documentación:

Elige el almacenamiento adecuado

Google Cloud ofrece una amplia gama de opciones de almacenamiento para VMs de Compute Engine: discos persistentes, discos de unidad de estado sólido (SSD) locales, Filestore y Cloud Storage. Si deseas obtener recomendaciones de diseño y prácticas recomendadas para optimizar el rendimiento de cada una de estas opciones de almacenamiento, consulta Optimiza el rendimiento del almacenamiento.

Google Kubernetes Engine

En esta sección, se proporciona orientación para ayudarte a optimizar el rendimiento de los recursos de Google Kubernetes Engine (GKE).

Recursos con ajuste de escala automático

Puedes cambiar el tamaño de los grupos de nodos de forma automática en un clúster de GKE para que coincidan con la carga actual a través de la función de escalador automático de clúster. El ajuste de escala automático ayuda a que tus apps sigan entregando un rendimiento predecible cuando la carga aumente. El escalador automático de clúster cambia el tamaño de los grupos de nodos de forma automática en función de las solicitudes de recursos (en lugar del uso real de recursos) de los Pods que se ejecutan en los nodos. Cuando usas el ajuste de escala automático, puede haber un equilibrio entre el rendimiento y el costo. Revisa las prácticas recomendadas para configurar el ajuste de escala automático de clúster de manera eficiente.

Usa VMs C2D

Puedes mejorar el rendimiento de las cargas de trabajo alojadas en contenedores de procesamiento intensivo a través de los tipos de máquinas C2D. Puedes agregar nodos C2D a tus clústeres de GKE si eliges un tipo de máquina C2D en tus grupos de nodos.

Inhabilita SMT

Los multisubprocesos simultáneos (SMT) pueden aumentar la capacidad de procesamiento de la aplicación de manera significativa para las tareas de procesamiento generales y las cargas de trabajo que necesitan una E/S alta. Sin embargo, para las cargas de trabajo en las que ambos núcleos virtuales están vinculados al procesamiento, SMT puede causar un rendimiento incoherente. Si deseas obtener un rendimiento mejor y más predecible, puedes inhabilitar los SMT para tus nodos de GKE si configuras la cantidad de CPU virtuales por núcleo como 1.

Usa GPU

Para cargas de trabajo de procesamiento intensivo, como el reconocimiento de imágenes y la transcodificación de video, puedes acelerar el rendimiento a través de la creación de grupos de nodos que usen GPU. Para obtener más información, consulta Ejecuta GPU.

Usa el balanceo de cargas nativo del contenedor

El balanceo de cargas nativo del contenedor permite que los balanceadores de cargas distribuyan el tráfico de manera directa y uniforme a los Pods. Este enfoque proporciona un mejor rendimiento de la red y una visibilidad mejorada de la latencia entre redes entre el balanceador de cargas y los Pods. Debido a estos beneficios, el balanceo de cargas nativo del contenedor es la solución recomendada para el balanceo de cargas a través de Ingress.

Define una política de posición compacta

Las cargas de trabajo por lotes con acoplamiento alto necesitan una latencia de red baja entre los nodos del grupo de nodos de GKE. Puedes implementar esas cargas de trabajo en grupos de nodos de zona única y asegurarte de que los nodos estén cerca uno de otro a través de la definición de una política de posición compacta. Si deseas obtener más información, consulta Define la posición de compactación para los nodos de GKE.

Servicios de computación sin servidores

En esta sección, se proporciona orientación para ayudarte a optimizar el rendimiento de los servicios de procesamiento sin servidores en Google Cloud: Cloud Run y Cloud Functions. Estos servicios proporcionan funciones de ajuste de escala automático, en las que la infraestructura subyacente controla el escalamiento automáticamente. A través de estos servicios sin servidores, puedes reducir el esfuerzo de escalar los microservicios y funciones y enfocarte en optimizar el rendimiento a nivel de la aplicación.

Para obtener más información, consulta la siguiente documentación:

¿Qué sigue?

Consulta las prácticas recomendadas para optimizar el rendimiento de tus recursos de procesamiento, herramientos de redes, bases de datos y estadísticas:

Optimiza el rendimiento del almacenamiento

En este documento del framework de arquitectura de Google Cloud, se proporcionan recomendaciones para ayudarte a optimizar el costo de los recursos de red en Google Cloud.

Cloud Storage

En esta sección, se proporcionan prácticas recomendadas para ayudarte a optimizar el rendimiento de tus operaciones de Cloud Storage.

Evalúa el rendimiento del bucket

Evalúa el rendimiento de los buckets de Cloud Storage con el comando gsutil perfdiag. Este comando prueba el rendimiento del bucket especificado a través del envío de una serie de solicitudes de lectura y escritura con archivos de diferentes tamaños. Puedes ajustar la prueba para que coincida con el patrón de uso de tus aplicaciones. Usa el informe de diagnóstico que genera el comando para establecer expectativas de rendimiento y también identificar posibles cuellos de botella.

Almacena en caché objetos a los que se accede con frecuencia

Para mejorar la latencia de lectura de los objetos de acceso frecuente que se pueden acceder de forma pública, puedes configurar esos objetos para que se almacenen en caché. Aunque el almacenamiento en caché puede mejorar el rendimiento, el contenido inactivo podría entregarse si una caché tiene la versión anterior de un objeto.

Escala solicitudes de forma eficiente

A medida que aumenta la tasa de solicitudes en un bucket, Cloud Storage aumenta automáticamente la capacidad de E/S para el bucket a través de la distribución de la carga de solicitudes entre varios servidores. Si deseas lograr un rendimiento óptimo cuando se escalan las solicitudes, sigue las prácticas recomendadas para aumentar los porcentajes de solicitudes y distribuir la carga de manera uniforme.

Habilita multiprocesamiento y procesamiento múltiple

Cuando usas gsutil para subir varios archivos pequeños, puedes mejorar el rendimiento de la operación a través de la opción -m. Esta opción permite que la solicitud de carga se implemente como una operación por lotes, paralela (es decir, multiproceso y procesamiento múltiple). Usa esta opción solo cuando realices operaciones en una conexión de red rápida. Si deseas obtener más información, consulta la documentación de la opción -m en Opciones de línea de comandos globales.

Sube archivos grandes como compuestos

Para subir archivos grandes, puedes usar una estrategia llamada cargas compuestas en paralelo. Con esta estrategia, el archivo grande se divide en fragmentos que se suben en paralelo y luego, se recomponen en la nube. Las cargas compuestas en paralelo pueden ser más rápidas que las operaciones de carga normales cuando el ancho de banda de red y la velocidad del disco no son factores limitantes. Sin embargo, esta estrategia tiene algunas implicaciones de costos y limitaciones. Para obtener más información, consulta la sección sobre cargas compuestas paralelas.

Discos persistentes y SSDs locales.

En esta sección, se proporcionan prácticas recomendadas para ayudarte a optimizar el rendimiento de tus discos persistentes y SSD locales conectados a las VMs de Compute Engine.

El rendimiento de los discos persistentes y las SSD locales depende del tipo y tamaño de disco, el tipo de máquina de VM y la cantidad de CPU virtuales. Usa los siguientes lineamientos para administrar el rendimiento de tus discos persistentes y SSD locales:

Filestore

En esta sección, se proporcionan prácticas recomendadas para ayudarte a optimizar el rendimiento de tus instancias de Filestore. Puedes usar Filestore para aprovisionar servidores de archivos del sistema de archivos de red (NFS) por completo administrados para VMs de Compute Engine y clústeres de GKE.

  • Cuando aprovisiones una instancia de Filestore, elige un nivel de servicio que cumpla con los requisitos de rendimiento y capacidad de tu carga de trabajo.
  • Para las VMs de cliente que ejecutan cargas de trabajo dependientes de la caché, usa un tipo de máquina que ayude a optimizar el rendimiento de la red de la instancia de Filestore. Para obtener más información, consulta Tipo de máquina cliente recomendado.
  • Para optimizar el rendimiento de las instancias de Filestore para las VMs de cliente que ejecutan Linux, Google recomienda una configuración de activación específica de NFS. Si deseas obtener más información, consulta Opciones de activación de cliente de Linux.
  • Para minimizar la latencia de red, aprovisiona tus instancias de Filestore en regiones y zonas que estén cerca de donde planeas usar las instancias.
  • Supervisar el rendimiento de las instancias de Filestore y configurar alertas a través de Cloud Monitoring.

¿Qué sigue?

Consulta las prácticas recomendadas para optimizar el rendimiento de tus recursos de procesamiento, herramientos de redes, bases de datos y estadísticas:

Optimiza las Herramientas de redes y el rendimiento de las APIs

En este documento de Framework de la arquitectura de Google Cloud, se proporcionan recomendaciones para ayudarte a optimizar el rendimiento de las APIs y los recursos de red en Google Cloud.

Niveles de servicio de red

Los niveles de servicio de red te permiten optimizar el costo de red y el rendimiento de las cargas de trabajo. Puedes elegir entre los siguientes niveles:

  • El nivel Premium usa la red troncal global de alta confiabilidad de Google para ayudarte a lograr una pérdida de paquetes y una latencia mínima. El tráfico entra y sale de la red de Google en un punto de presencia (PoP) perimetral y global que está cerca de tu usuario final. Recomendamos usar el nivel Premium como nivel predeterminado para obtener un rendimiento óptimo. El nivel Premium admite direcciones IP externas regionales y globales para las VMs y los balanceadores de cargas.
  • El nivel Estándar solo está disponible para los recursos que usan direcciones IP externas regionales. El tráfico ingresa y sale de la red de Google en un PoP perimetral más cercano a la ubicación de Google Cloud en la que se ejecuta tu carga de trabajo. Los precios del nivel Estándar son más bajos que el nivel Premium. El nivel Estándar es adecuado para el tráfico que no es sensible a la pérdida de paquetes y que no tiene requisitos de latencia baja.

Puedes ver la latencia de red para el nivel Estándar y el nivel Premium de cada región de la nube en el panel de rendimiento de Network Intelligence Center.

Marcos jumbo

Las redes de nube privada virtual (VPC) tienen una unidad de transmisión máxima (MTU) predeterminada de 1,460 bytes. Sin embargo, puedes configurar las redes de VPC para que admitan una MTU de hasta 8896 (marcos jumbo).

Con una MTU más alta, la red necesita menos paquetes para enviar la misma cantidad de datos, lo que reduce el ancho de banda que usan los encabezados TCP/IP. Esto da como resultado un ancho de banda efectivo más alto para la red.

Para obtener más información sobre la MTU dentro de la VPC y la MTU máxima de otras conexiones, consulta la página Unidad de transmisión máxima en la documentación de VPC.

Rendimiento de la VM

Las VMs de Compute Engine tienen un ancho de banda de salida máximo que, en parte, depende del tipo de máquina. Un aspecto de elegir un tipo de máquina adecuado es considerar cuánto tráfico esperas que genere la VM.

La página Ancho de banda de red contiene una discusión y una tabla de anchos de banda de red para los tipos de máquina de Compute Engine.

Si los requisitos de ancho de banda entre VM son muy altos, considera usar VMs que admitan redes de nivel 1.

Cloud Load Balancing

En esta sección, se proporcionan prácticas recomendadas para ayudarte a optimizar el rendimiento de las instancias de Cloud Load Balancing.

Implementa aplicaciones cerca de tus usuarios

Aprovisiona los backends de la aplicación cerca de la ubicación en la que esperas que el tráfico de usuarios llegue al balanceador de cargas. Cuanto más cerca estén tus usuarios o aplicaciones cliente de tus servidores de carga de trabajo, menor será la latencia de red entre los usuarios y la carga de trabajo. Para minimizar la latencia en los clientes en diferentes partes del mundo, es posible que debas implementar los backends en varias regiones. Si deseas obtener más información, consulta Prácticas recomendadas para la selección de regiones de Compute Engine.

Elige un tipo de balanceador de cargas adecuad

El tipo de balanceador de cargas que elijas para tu aplicación puede determinar la latencia que experimentan los usuarios. Si deseas obtener información para medir y optimizar la latencia de la aplicación para diferentes tipos de balanceadores de cargas, consulta Optimiza la latencia de las aplicaciones con el balanceo de cargas.

Habilita el almacenamiento en caché

Para acelerar la entrega de contenido, habilita el almacenamiento en caché y Cloud CDN como parte de la configuración predeterminada del balanceador de cargas de HTTP externo. Asegúrate de que los servidores de backend estén configurados para enviar los encabezados de respuesta necesarios para que las respuestas estáticas se almacenen en caché.

Usa HTTP cuando no sea necesario usar HTTPS

Google encripta el tráfico entre los balanceadores de cargas de proxy y backends automáticamente a nivel de paquete. La encriptación a nivel de paquete hace que la encriptación de capa 7 a través de HTTPS entre el balanceador de cargas y los backends sea redundante para la mayoría de los propósitos. Considera usar HTTP en lugar de HTTPS o HTTP/2 para el tráfico entre el balanceador de cargas y los backends. A través de HTTP, también puedes reducir el uso de CPU de las VMs de backend. Sin embargo, cuando el backend es un grupo de extremos de red de Internet (NEG), usa HTTPS o HTTP/2 para el tráfico entre el balanceador de cargas y el backend. Esto ayuda a garantizar que tu tráfico sea seguro en la Internet pública. Para obtener un rendimiento óptimo, recomendamos comparar los patrones de tráfico de tu aplicación.

Network Intelligence Center

Network Intelligence Center de Google Cloud proporciona una vista integral del rendimiento de la red de Google Cloud en todas las regiones. Network Intelligence Center te ayuda a determinar si los problemas de latencia se deben a problemas en tu proyecto o en la red. También puedes usar esta información para seleccionar las regiones y zonas en las que debes implementar tus cargas de trabajo para optimizar el rendimiento de la red.

Usa las siguientes herramientas que proporciona Network Intelligence Center para supervisar y analizar el rendimiento de la red de tus cargas de trabajo en Google Cloud:

  • En el Panel de rendimiento, se muestra la latencia entre las regiones de Google Cloud y entre regiones y ubicaciones individuales en Internet. El Panel de rendimiento puede ayudarte a determinar dónde ubicar las cargas de trabajo para obtener la mejor latencia y determinar cuándo un problema de la aplicación puede deberse a problemas de red subyacentes.

  • En Topología de red, se ofrece una vista visual de tus redes de nube privada virtual (VPC), la conectividad híbrida con tus redes locales y la conectividad a los servicios administrados por Google. La topología de red proporciona métricas operativas en tiempo real que puedes usar para analizar y comprender el rendimiento de la red para identificar patrones de tráfico inusuales.

  • Network Analyzer es una herramienta de supervisión y diagnóstico de configuración automática. Comprueba los parámetros de configuración de la red de VPC para las reglas de firewall, las rutas, las dependencias de configuración y la conectividad de los servicios y las aplicaciones. Ayuda a identificar fallas en la red y proporciona análisis y recomendaciones de la causa raíz. Network Analyzer proporciona estadísticas priorizadas para ayudarte a analizar problemas con la configuración de red, como el alto uso de direcciones IP en una subred.

API de Gateway y Apigee

En esta sección, se proporcionan recomendaciones para ayudarte a optimizar el rendimiento de las APIs que implementas en Google Cloud a través del uso de API Gateway y Apigee.

API Gateway te permite crear y administrar APIs para backends sin servidores de Google Cloud, incluidos Cloud Functions, Cloud Run y App Engine. Estos servicios son servicios administrados y se escalan automáticamente. Sin embargo, a medida que se escalan las aplicaciones que se implementan en estos servicios, es posible que debas aumentar las cuotas y los límites de frecuencia de API Gateway.

Apigee proporciona los siguientes paneles de estadísticas para ayudarte a supervisar el rendimiento de tus APIs administradas:

Si usas la integración de Apigee, ten en cuenta los límites de configuración del sistema cuando compiles y administres las integraciones.

¿Qué sigue?

Consulta las prácticas recomendadas para optimizar el rendimiento de tus recursos de procesamiento, almacenamiento, bases de datos y estadísticas:

Optimiza el rendimiento de la base de datos

En este documento de Framework de la arquitectura de Google Cloud, se proporcionan recomendaciones para ayudarte a optimizar el rendimiento de las bases de datos en Google Cloud.

Cloud SQL

Las siguientes recomendaciones te ayudarán a optimizar el rendimiento de las instancias de Cloud SQL que ejecutan bases de datos de SQL Server, MySQL y PostgreSQL.

Para obtener más información, consulta la siguiente documentación:

Bigtable

En esta sección, se proporcionan recomendaciones para optimizar el rendimiento de tus instancias de Bigtable.

Planifica la capacidad según los requisitos de rendimiento

Puedes usar Bigtable en una amplia gama de aplicaciones, cada una con un objetivo de optimización diferente. Por ejemplo, para los trabajos de procesamiento de datos por lotes, la capacidad de procesamiento puede ser más importante que la latencia. Para un servicio en línea que entrega solicitudes de usuarios, es posible que debas priorizar una latencia más baja por sobre la capacidad de procesamiento. Cuando planifiques la capacidad de los clústeres de Bigtable, ten en cuenta las compensaciones entre la capacidad de procesamiento y la latencia. Si deseas obtener más información, consulta Planifica tu capacidad de Bigtable.

Sigue las prácticas recomendadas para el diseño de esquemas

Las tablas pueden escalar a miles de millones de filas y miles de columnas, lo que te permite almacenar petabytes de datos. Cuando diseñes el esquema para las tablas de Bigtable, ten en cuenta las prácticas recomendadas sobre el diseño del esquema.

Supervisa el rendimiento y realiza ajustes

Supervisa el uso de CPU y de disco de tus instancias, analiza el rendimiento de cada clúster y revisa las recomendaciones de tamaño que se muestran en los gráficos de supervisión.

Spanner

En esta sección, se proporcionan recomendaciones para ayudarte a optimizar el rendimiento de las instancias de Spanner.

Elige una clave primaria que evite un hotspot

Un hotspot es un servidor único que se ve obligado a controlar muchas solicitudes. Cuando elijas la clave primaria de tu base de datos, sigue las prácticas recomendadas de diseño del esquema para evitar un hotspot.

Sigue las prácticas recomendadas para la codificación SQL

El compilador de SQL en Spanner convierte cada instrucción de SQL declarativa que escribes en un plan de ejecución de consultas imperativo. Spanner usa el plan de ejecución para ejecutar la instrucción de SQL. Cuando crees instrucciones de SQL, sigue las prácticas recomendadas de SQL para asegurarte de que Spanner use planes de ejecución que generen un rendimiento óptimo.

Usa opciones de consulta para administrar el optimizador de consultas de SQL

Spanner usa un optimizador de consultas en SQL para transformar las instrucciones de SQL en planes de ejecución eficientes de consultas. El plan de ejecución de consultas que produce el optimizador puede cambiar un poco cuando el optimizador de consultas evoluciona o cuando se actualizan las estadísticas de la base de datos. Puedes minimizar el potencial de regresión de rendimiento cuando el optimizador de consultas o las estadísticas de la base de datos cambian mediante las opciones de consulta.

Visualiza y ajusta la estructura de los planes de ejecución de consultas

Para analizar los problemas de rendimiento de las consultas, puedes visualizar y ajustar la estructura de los planes de ejecución de consultas mediante el visualizador del plan de consultas.

Usa las API de operaciones para administrar operaciones de larga duración

Para ciertas llamadas de método, Spanner crea operaciones de larga duración, lo que puede tardar una cantidad de tiempo considerable en completarse. Por ejemplo, cuando restableces una base de datos, Spanner crea una operación de larga duración para realizar un seguimiento del progreso del restablecimiento. Para ayudarte a supervisar y administrar operaciones de larga duración, Spanner proporciona las APIs de operaciones. Para obtener más información, consulta Administra operaciones de larga duración.

Sigue las prácticas recomendadas para la carga masiva

Spanner admite varias opciones para cargar grandes cantidades de datos de forma masiva. El rendimiento de una operación de carga masiva depende de factores como la partición, la cantidad de solicitudes de escritura y el tamaño de cada solicitud. Para cargar grandes cantidades de datos de forma eficiente, sigue las prácticas recomendadas sobre la carga masiva.

Supervisa y controla el uso de CPU

El uso de CPU de la instancia de Spanner puede afectar las latencias de solicitud. Un servidor de backend sobrecargado puede causar mayores latencias de solicitudes. Spanner proporciona métricas de uso de CPU para ayudarte a investigar el uso alto de CPU. En el caso de aplicaciones sensibles al rendimiento, es posible que debas aumentar el uso de CPU mediante el aumento de la capacidad de procesamiento.

Analiza y resuelve problemas de latencia

Cuando un cliente realiza una llamada de procedimiento remoto a Spanner, las bibliotecas cliente preparan primero la solicitud a la API. Luego, la solicitud pasa por Google Front End y el frontend de la API de Cloud Spanner antes de que llegue a la base de datos de Spanner. Para analizar y resolver problemas de latencia, debes medir y analizar la latencia de cada segmento de la ruta que recorre la solicitud a la API. Para obtener más información, consulta la Guía de latencia de extremo a extremo de Spanner.

Inicia las aplicaciones después de que la base de datos alcanza el estado templado

A medida que crecen las bases de datos de Spanner, se divide el espacio de claves de los datos en divisiones. Cada división es un rango de filas que contiene un subconjunto de la tabla. Para balancear la carga total en la base de datos, Spanner mueve de forma dinámica las divisiones individuales y las asigna a diferentes servidores. Cuando las divisiones se distribuyen en varios servidores, se considera que la base de datos está en un estado caliente. Una base de datos cálida puede maximizar el paralelismo y entregar un rendimiento mejorado. Antes de iniciar las aplicaciones, te recomendamos precargar la base de datos con cargas de datos de prueba.

¿Qué sigue?

Revisa las prácticas recomendadas para optimizar el rendimiento de tus recursos de procesamiento, almacenamiento, herramientas de redes y estadísticas:

Optimiza el rendimiento de las estadísticas

En este documento de Framework de la arquitectura de Google Cloud, se proporcionan recomendaciones para optimizar el rendimiento de las cargas de trabajo analíticas en Google Cloud.

BigQuery

En esta sección, se proporcionan recomendaciones para ayudarte a optimizar el rendimiento de las consultas en BigQuery.

Optimiza el diseño de las consultas

El rendimiento de las consultas depende de factores como la cantidad de bytes que tus consultas y operaciones de lectura leen, y el volumen de datos que se pasan entre las ranuras. Para optimizar el rendimiento de las consultas en BigQuery, aplica las prácticas recomendadas que se describen en la siguiente documentación:

Define y usa vistas materializadas de forma eficiente

Para mejorar el rendimiento de las cargas de trabajo que usan consultas comunes y repetidas, puedes usar vistas materializadas. Existen límites para la cantidad de vistas materializadas que puedes crear. No crees una vista materializada separada para cada permutación de una consulta. En su lugar, define las vistas materializadas que puedes usar para varios patrones de consultas.

Mejora el rendimiento de JOIN

Puedes usar vistas materializadas para reducir el costo y la latencia de una consulta que realiza la agregación sobre un JOIN. Considera un caso en el que combinas una tabla de hechos grande con unas pocas tablas de dimensiones y, luego, realiza una agregación sobre la unión. Puede ser práctico reescribir la consulta para realizar primero la agregación en la tabla de hechos con claves externas como agrupamientos de claves. Luego, combina el resultado con las tablas de dimensiones. Por último, realiza una agregación posterior.

Dataflow

En esta sección, se proporcionan recomendaciones para ayudarte a optimizar el rendimiento de las consultas de tus canalizaciones de Dataflow.

Cuando creas y, luego, implementas canalizaciones, puedes configurar parámetros de ejecución, como el tipo de máquina de Compute Engine que se debe usar para las VMs de trabajador de Dataflow. Para obtener más información, consulta Opciones de canalización.

Después de implementar las canalizaciones, Dataflow administra los recursos de Compute Engine y Cloud Storage que son necesarios para ejecutar los trabajos. Además, las siguientes características de Dataflow ayudan a optimizar el rendimiento de las canalizaciones:

Puedes supervisar el rendimiento de las canalizaciones de Dataflow a través de la interfaz de supervisión basada en la Web o gcloud CLI de Dataflow.

Dataproc

En esta sección, se describen las prácticas recomendadas para optimizar el rendimiento de los clústeres de Dataproc.

Ajustar la escala automática del clúster

Para asegurarte de que los clústeres de Dataproc entreguen un rendimiento predecible, puedes habilitar el ajuste de escala automático. Dataproc usa métricas de memoria de Hadoop YARN y una política de ajuste de escala automático que defines para ajustar de forma automática la cantidad de VMs de trabajador en un clúster. Si deseas obtener más información para usar y configurar el ajuste de escala automático, consulta Clústeres con ajuste de escala automático.

Aprovisiona el almacenamiento adecuado

Elige una opción de almacenamiento adecuada para tu clúster de Dataproc según tus requisitos de rendimiento y costo:

  • Usa Cloud Storage si necesitas un sistema de archivos compatible con Hadoop (HCFS) de bajo costo en el que los trabajos de Hadoop y Spark puedan leer y escribir con cambios mínimos. Los datos almacenados en Cloud Storage son persistentes y otros clúesteres y productos de Dataproc, como BigQuery, pueden acceder a ellos.
  • Si necesitas un sistema de archivos distribuido de Hadoop (HDFS) de baja latencia para tu clúster de Dataproc, usa discos persistentes de Compute Engine conectados a los nodos trabajadores. Los datos almacenados en el almacenamiento HDFS son transitorios, y el costo de almacenamiento es mayor que la alternativa de Cloud Storage.
  • Para obtener la ventaja de rendimiento de los discos persistentes de Compute Engine y los beneficios de costo y durabilidad de Cloud Storage, puedes combinar ambas opciones de almacenamiento. Por ejemplo, puedes almacenar tu conjunto de datos fuente y final en Cloud Storage y aprovisionar capacidad del HDFS limitada para los conjuntos de datos intermedios. Cuando decidas el tamaño y el tipo de los discos para el almacenamiento del HDFS, ten en cuenta las recomendaciones de la sección Discos persistentes y SSD locales.

Reduce la latencia cuando usas Cloud Storage

Para reducir la latencia cuando accedes a los datos almacenados en Cloud Storage, te recomendamos lo siguiente:

  • Crea tu bucket de Cloud Storage en la misma región que el clúster de Dataproc.
  • Inhabilita auto.purge para las tablas administradas por Apache Hive almacenadas en Cloud Storage.
  • Cuando uses Spark SQL, considera crear clústeres de Dataproc con las últimas versiones de imágenes disponibles. Con la versión más reciente, puedes evitar problemas de rendimiento que podrían permanecer en versiones anteriores, como el rendimiento lento de INSERT OVERWRITE en Spark 2.x.
  • Para minimizar la posibilidad de escribir muchos archivos con tamaños diferentes o pequeños en Cloud Storage, puedes configurar los parámetros de Spark SQL spark.sql.shuffle.partitions y spark.default.parallelism. el parámetro de Hadoop mapreduce.job.reduces.

Supervisa y ajusta la carga y la capacidad de almacenamiento

Los discos persistentes conectados a los nodos trabajadores en un clúster de Dataproc contienen datos Shuffle. Para obtener un rendimiento óptimo, los nodos trabajadores necesitan suficiente espacio en el disco. Si los nodos no tienen suficiente espacio en el disco, los nodos se marcan como UNHEALTHY en el registro YARN NodeManager. Si se produce este problema, aumenta el tamaño del disco para los nodos afectados o ejecuta menos trabajos de forma simultánea.

Habilita EFM

Cuando se quitan los nodos trabajadores de un clúster de Dataproc en ejecución, por ejemplo, debido a un escalamiento descendente o de interrupción, es posible que se pierdan los datos aleatorios. Para minimizar los retrasos de trabajo en esas situaciones, te recomendamos que habilites la función Modo de flexibilidad mejorada (EFM) para clústeres que usan VMs interrumpibles o que solo ajuste la escala de forma automática del grupo de trabajadores secundarios.

¿Qué sigue?

Revisa las prácticas recomendadas para optimizar el rendimiento de los recursos de procesamiento, almacenamiento, herramientas de redes y bases de datos:

Novedades del framework de arquitectura

En este documento, se enumeran los cambios significativos en el framework de arquitectura de Google Cloud.

28 de noviembre de 2023

  • Categoría de confiabilidad:
    • Se reorganizó el contenido para mejorar la legibilidad y la coherencia:
    • Define los SLO: Se movió la sección “Terminología” a la página nueva: Terminología.
    • Adopta SLO: Se movió la sección “SLO y alertas” a la página nueva: SLO y alertas.

9 de noviembre de 2023

  • Categoría de diseño del sistema:

8 de septiembre de 2023

  • Categoría de optimización de costos:

    • Se agregó información para usar las etiquetas de asignación y administración de costos.
    • Se actualizó la guía para identificar anomalías de etiquetado.

    Para obtener más información, consulta Supervisa y asigna costos con etiquetas.

28 de agosto de 2023

  • Categoría de diseño del sistema:

23 de agosto de 2023

  • Categoría de optimización de costos:
    • Se agregó información sobre la optimización del uso de recursos de Spanner para cargas de trabajo pequeñas con el uso de unidades de procesamiento en lugar de nodos.

18 de agosto de 2023

9 de agosto de 2023

  • Categoría de confiabilidad:

13 de julio de 2023

  • Diseño de sistema:
  • Optimización de costos:
    • Se agregó información sobre Google Cloud Hyperdisk y los SSD locales en la sección Persistent Disk.

23 de junio de 2023

15 de junio de 2023

30 de marzo de 2023

16 de septiembre de 2022

10 de agosto de 2022

4 de Agosto de 2022

13 de julio de 2022

27 de junio de 2022

13 de junio de 2022

1 de junio de 2022

7 de mayo de 2022

4 de my. de 2022

25 de febrero de 2022

  • Cambios en la categoría de seguridad:

    • Se actualizaron las prácticas recomendadas de cumplimiento para debatir sobre la automatización.

15 de diciembre de 2021

25 de octubre de 2021

7 de octubre de 2021

  • Actualización importante de todas las categorías.


  1. Kat Berenberg y Brad Calder, Arquetipos de implementación para aplicaciones en la nube, Encuestas de computación de ACM, volumen 55, problema 3, artículo n°: 61, pp 1-48