Google PCA: Costo, Rendimiento y Diseño de Nube Sostenible — Guía de estudio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Architect — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

El costo, el rendimiento y el diseño sostenible de la nube son disciplinas que se optimizan conjuntamente. Crear arquitecturas eficientes en Google Cloud requiere observabilidad financiera, capacidad elástica que siga la demanda, rigor en el ciclo de vida de los datos, ubicación y almacenamiento en caché informados para las redes, y medición continua. Esta sección explica los patrones de diseño y operativos que reducen el desperdicio sin sacrificar la fiabilidad, la seguridad o el rendimiento, y destaca los modos de fallo y las compensaciones para evitar sorpresas costosas.

Arquitectura de costos y responsabilidad financiera

Establece controles financieros como parte de la base de tu plataforma.

Análisis y asignación de la facturación
- Exporta los datos de facturación a BigQuery para un análisis de gastos consultable y casi en tiempo real por proyecto, servicio, SKU y etiqueta. Particiona por día para consultas escalables y establece controles de acceso al conjunto de datos para las partes interesadas de finanzas e ingeniería.
- Usa presupuestos con umbrales de alerta para evitar desviaciones en los gastos. Enruta las alertas de presupuesto a Pub/Sub y automatiza las respuestas (por ejemplo, pausando cargas de trabajo no críticas). Ten en cuenta que las alertas no son transaccionales y pueden tener retrasos en los informes; no confíes en ellas como el único control para trabajos fuera de control.
Etiquetas, tags y atribución de costos
- Estandariza las etiquetas para toda la organización (cost_center, env, owner, app) y exígelas en el momento del aprovisionamiento con plantillas de despliegue o política como código.
- Prefiere los tags jerárquicos y la estructura de carpetas/proyectos para reflejar los modelos de contracargo (chargeback) o reparto de costos (showback). Usa tanto etiquetas (a nivel de recurso) como tags (ámbito de política y facturación) para lograr una asignación precisa.
Barreras de protección presupuestaria y detección de anomalías
- Configura presupuestos por proyecto y por portafolio; establece múltiples umbrales (por ejemplo, 50, 80, 100 por ciento) y alertas “pronosticadas” para una acción proactiva.
- Usa las estadísticas de Recommender (VM inactivas, discos no adjuntos, IPs, compromisos no utilizados) para eliminar el desperdicio continuamente.
Ejemplos prácticos
- Aplicar etiquetas en la creación:

undefined

Consulta la exportación de facturación en busca de gastos sin etiquetar para hacer cumplir la conformidad mediante verificaciones de CI/CD.

Modos de fallo comunes y compensaciones:

Las etiquetas inconsistentes rompen la asignación de costos; exígelas con políticas de organización y validación en los pipelines.
La facturación centralizada sin presupuestos por equipo dificulta la rendición de cuentas; crea presupuestos a nivel de equipo o producto.
El retraso en las alertas de presupuesto significa que los picos rápidos pueden sobrepasarlo; implementa límites y cuotas donde sea posible.

Eficiencia y rendimiento del cómputo

Ajusta los recursos a los perfiles de la carga de trabajo; automatiza la elasticidad; reserva o descuenta la carga base estable.

Ajuste de tamaño correcto (rightsizing) y tipos de máquina personalizados
- Analiza continuamente la utilización de CPU, memoria, IOPS de disco y red para un ajuste de tamaño correcto. Usa tipos de máquina personalizados para ajustar la vCPU y la memoria a las necesidades reales de la aplicación y evitar pagar por memoria inactiva.
- Presta atención al margen de maniobra (headroom): apunta a un 60–75 por ciento de CPU sostenida y asegura un margen de memoria suficiente para la recolección de basura (GC) o los picos. Un ajuste de tamaño demasiado agresivo aumenta el riesgo de estrangulamiento (throttling) o errores de falta de memoria (OOMs).
Autoescalado y programación del ciclo de vida
- Usa el autoescalado de grupos de instancias administrados basado en señales relevantes (CPU, capacidad del balanceador de carga o profundidad de cola personalizada). Configura períodos de calentamiento (warmup) y controles de reducción de escala (scale-in) para evitar la oscilación (thrash).
- Para entornos que no operan 24/7, programa el inicio/parada de VMs, grupos de nodos de GKE o instancias mínimas de Cloud Run para evitar el gasto en recursos inactivos. Un primer paso simple es usar Cloud Scheduler para activar un trabajo de Cloud Run que detenga las instancias de desarrollo por la noche.
Instrumentos de descuento
- Descuentos por uso confirmado (Committed-use discounts): comprométete de 1 a 3 años para el uso de estado estable elegible para compromisos. Equilibra el tamaño del compromiso con el uso histórico y las previsiones del negocio; comprometerse en exceso desperdicia dinero.
- Spot VMs: ideales para cargas de trabajo tolerantes a fallos, por lotes o distribuidas. Pueden ser reclamadas en cualquier momento; implementa puntos de control (checkpointing) y grupos de múltiples instancias con alternativas bajo demanda.
  - Ejemplo:

undefined

Reservas de capacidad: reserva capacidad zonal o regional para flotas críticas para mitigar fallos de escalado ascendente durante escaseces regionales.
- Ejemplo:

undefined

Métricas de utilización y ajuste del rendimiento
- Instrumenta con Cloud Monitoring, Profiler y Trace. Mide la latencia p50/p95, el tiempo de CPU robado (CPU steal), el tiempo de GC y los retrasos en las colas. Optimiza las rutas de código críticas (hot code paths) antes de escalar horizontalmente.
- Fija las cargas de trabajo sensibles al rendimiento en regiones y zonas con plataformas de CPU adecuadas y considera discos persistentes de alto rendimiento o Hyperdisk donde sea necesario.

Modos de fallo y compensaciones:

El autoescalado sin límites puede exceder las cuotas y los objetivos de costo; aumenta las cuotas previamente, establece un máximo de réplicas y usa el autoescalado predictivo para los picos conocidos.
Las Spot VMs pueden causar una rotación parcial de la flota (partial-fleet churn); diversifica las zonas e implementa ganchos de terminación gradual (graceful termination hooks).
Comprometerse en exceso con CUDs o las reservas infrautilizadas crean costos hundidos; revisa los compromisos trimestralmente.

Costo-Rendimiento de Almacenamiento, Bases de Datos y Analítica

Elija clases de almacenamiento y modelos de capacidad de bases de datos que reflejen los patrones de acceso, la retención y los SLO de rendimiento.

Clases de almacenamiento y políticas de ciclo de vida
- Use Standard para datos de acceso frecuente (hot), Nearline para acceso mensual, Coldline para acceso trimestral y Archive para acceso poco frecuente a largo plazo. Mantenga los datos y la computación en la misma región para evitar la salida de datos (egress).
- Aplique la gestión del ciclo de vida para transferir o eliminar objetos automáticamente. Tenga en cuenta las duraciones mínimas de almacenamiento y los cargos por recuperación; las transiciones prematuras de clase pueden costar más de lo que ahorran.
- Ejemplo de política de ciclo de vida (eliminar objetos con más de 90 días):

undefined

- gsutil lifecycle set lifecycle.json gs://my-backups

Transferencia y archivado de datos
- El acceso entre regiones a menudo incurre en costos de salida de datos; coubique a los productores y consumidores. Use Private Google Access y VPC-SC para un acceso seguro y consciente de los costos a las API de Google. Para archivos a largo plazo, evite la recuperación frecuente desde Archive para prevenir altos cargos por recuperación.
Dimensionamiento y rendimiento de bases de datos
- Relacional: dimensione para el conjunto de trabajo residente en memoria, IOPS y réplicas de lectura. Habilite el aumento automático del almacenamiento y monitoree el retraso de la replicación; escale verticalmente o fragmente horizontalmente cuando el retraso amenace los RPO/RTO.
- NoSQL/series temporales: use Bigtable para una ingesta de alto rendimiento y baja latencia con un diseño adecuado de la clave de fila para evitar hotspots.
Controles de costos y modelos de capacidad de BigQuery
- Bajo demanda (por TB escaneado): rápido para empezar, riesgo de picos de costo. Reservas basadas en capacidad: gasto predecible, control sobre la concurrencia y el rendimiento (throughput). Los compromisos Flex absorben picos a corto plazo.
- Optimice las consultas con particionamiento y clustering; exija filtros de partición para evitar escaneos de tabla completa:
  - bq update –require_partition_filter=true myds.mytable
- Establezca un máximo de bytes facturados por trabajo para limitar el gasto:
  - bq query –use_legacy_sql=false –maximum_bytes_billed=100000000000 ‘SELECT …’
- Use vistas materializadas, caché de resultados, agregaciones aproximadas y evite SELECT * en producción. Mantenga el almacenamiento y la computación en la misma región.

Modos de fallo y compensaciones:

Mover objetos de acceso frecuente a Coldline/Archive genera costos de recuperación y cargos por eliminación anticipada.
BigQuery bajo demanda sin controles puede incurrir en costos descontrolados por escaneos sin filtrar; imponga un máximo de bytes facturados y filtros de partición.
La sobrefragmentación (oversharding) de las bases de datos aumenta la complejidad operativa; realice benchmarks antes de dividir.

Redes, rendimiento, cuotas y diseño sostenible

El movimiento de datos y el diseño de la concurrencia influyen considerablemente en el coste y el rendimiento; las decisiones de sostenibilidad refinan aún más la ubicación y la programación.

Salida de red (egress), tráfico entre regiones, CDN y almacenamiento en caché
- Minimizar los saltos entre regiones; replicar los datos solo donde la proximidad al usuario o el cumplimiento normativo lo exijan. Usar Cloud CDN para descargar contenido estático y dinámico almacenable en caché; ajustar las claves de caché, los TTL y las URL firmadas para obtener altas tasas de acierto.
- Almacenar en caché cerca de los clientes (CDN), en el borde de su VPC (proxy caché) y dentro de los servicios (cachés en memoria como Memorystore). Tenga cuidado con los datos obsoletos y las tormentas de invalidación; defina encabezados cache-control explícitos.
Medición del rendimiento, pruebas de carga y escalado
- Establecer SLO y medirlos con Cloud Monitoring, Uptime checks, Cloud Trace y Profiler. Hacer seguimiento de la latencia p95/p99 y las señales de saturación.
- Realizar pruebas de carga con datos realistas y think time (tiempo de reflexión). Organizar las pruebas por fases para evitar activar límites de tasa globales; solicitar aumentos de cuota temporales.
- Escalar el rendimiento usando réplicas horizontales, colas fragmentadas (sharded), temas particionados y autoescaladores impulsados por métricas de backlog (trabajo pendiente). Preferir canalizaciones asíncronas siempre que sea posible.
Cuotas, concurrencia, límites de tasa y contrapresión (backpressure)
- Hacer un inventario de las cuotas por servicio por región; aplicar un retroceso exponencial del lado del cliente con jitter (variación aleatoria) para las respuestas 429/5xx. Implementar control de admisión y contrapresión basada en colas para proteger las dependencias.
- Ajustar el control de flujo de Pub/Sub (máximo de mensajes/bytes pendientes), el procesamiento por lotes y el paralelismo. En Cloud Run y GKE, ajustar la concurrencia para que coincida con la CPU y la memoria, evitando la inflación de la latencia de cola.
Diseño consciente de la sostenibilidad
- Preferir servicios serverless y gestionados con alta utilización. Elegir regiones con mayores porcentajes de energía libre de carbono cuando la latencia y el cumplimiento normativo lo permitan.
- Programar trabajos por lotes y flexibles durante ventanas de bajas emisiones de carbono; usar los informes de Carbon Footprint para hacer un seguimiento del impacto.
- Usar tipos de máquina de alta eficiencia energética y considerar el cómputo basado en ARM donde sea compatible para mejorar el rendimiento por vatio.
Gobernanza que equilibra fiabilidad, seguridad, rendimiento y coste
- Definir barreras de protección arquitectónicas (guardrails): etiquetas obligatorias, alertas de presupuesto, políticas de organización (por ejemplo, restringir IP externas), presupuestos de errores/SLO y SLO de costes.
- Realizar revisiones periódicas de coste-rendimiento con los equipos de ingeniería, seguridad y finanzas. Integrar Recommender y paneles personalizados; construir manuales de operaciones (runbooks) para la remediación.
- Equilibrar las concesiones explícitamente: multirregional frente a regional (durabilidad y latencia frente a coste y salida de datos), capas de cifrado e inspección (seguridad frente a CPU y latencia) y autoescalado agresivo (rendimiento frente a cuota y riesgo de gasto).

Modos de fallo y concesiones típicos:

Los análisis multirregionales sobre un conjunto de datos de una sola región generan una salida de datos sostenida; replicar o reubicar el cómputo.
Una mala configuración de la CDN produce bajas tasas de acierto; supervisar la tasa de acierto de la caché y la salida de datos del origen para validar los ahorros.
La falta de contrapresión durante interrupciones parciales amplifica el fallo; implementar interruptores de circuito (circuit breakers) y reducir la carga de forma controlada.

Escenario de un problema práctico

Acme Learn, una empresa de educación en línea, experimenta picos nocturnos impredecibles durante eventos en vivo. Los costes aumentan bruscamente debido a consultas de BigQuery entre regiones, picos de autoescalado y salida de datos de activos estáticos. La dirección también quiere reducir el impacto de carbono sin degradar la experiencia del usuario.

Enfoque:

Consolidar la visibilidad de la facturación y aplicar la asignación de costes
- Crear una exportación de facturación a BigQuery y paneles segmentados por producto, entorno y región usando etiquetas y tags estandarizados en plantillas de despliegue.
- Justificación: La visibilidad casi en tiempo real vincula el gasto con los equipos responsables, permitiendo la responsabilidad presupuestaria. Las etiquetas potencian los contracargos (chargeback) granulares y la detección de anomalías.
Rediseñar la arquitectura de análisis para coubicar el cómputo y el almacenamiento
- Mover los conjuntos de datos de análisis de eventos y las consultas programadas a la misma región que los procesadores de flujos de datos. Para BigQuery, cambiar los equipos de alto volumen de un modelo bajo demanda a reservas de capacidad dimensionadas para la concurrencia máxima con un pequeño búfer flexible.
- Justificación: La coubicación elimina la salida de datos entre regiones. BigQuery basado en capacidad estabiliza los costes bajo carga mientras preserva el rendimiento.
Optimizar la entrega de contenido con almacenamiento en caché en el borde (edge)
- Servir los activos de lecciones estáticos y semidinámicos con Cloud CDN, estableciendo encabezados cache-control explícitos y URL firmadas para el contenido prémium. Ajustar los TTL según la mutabilidad del contenido.
- Justificación: Las altas tasas de acierto en caché desvían el tráfico de los orígenes al borde, reduciendo la salida de datos y el cómputo en el origen, a la vez que mejoran la latencia durante los picos.
Reforzar el autoescalado y las reservas para eventos en vivo
- Añadir un grupo de instancias gestionado regional para el nivel de la API con objetivos del autoescalador tanto en CPU como en el backlog de solicitudes. Crear una pequeña reserva de capacidad zonal para garantizar un margen para picos de tráfico durante los eventos. Habilitar el autoescalado predictivo antes de las sesiones programadas.
- Justificación: El autoescalado de doble señal reacciona tanto a la utilización como a la demanda, mientras que las reservas y el calentamiento predictivo evitan la latencia de arranque en frío y los déficits de capacidad.
Aplicar una mezcla de cómputo: carga base con compromisos, picos con Spot
- Comprar compromisos de 1 año para las cargas de trabajo base de API y procesamiento de datos. Configurar trabajos por lotes de transcodificación y enriquecimiento en Spot VMs con puntos de control (checkpointing) y grupos de instancias multizona.
- Justificación: Los compromisos reducen el coste del estado estacionario; las Spot VMs proporcionan elasticidad de bajo coste para trabajo interrumpible sin arriesgar el tráfico de los usuarios.
Instituir un ciclo de vida de almacenamiento y una ubicación regional
- Mantener los metadatos y miniaturas de cursos de acceso frecuente (hot) en Standard regional, cerca del cómputo de servicio. Hacer la transición de registros y flujos de clics (clickstreams) sin procesar a Nearline después de 30 días y eliminarlos después de 180 días. Para los archivos de cumplimiento normativo, usar Archive con SLA de recuperación documentados.
- Justificación: Alinea la clase de almacenamiento con los patrones de acceso, reduciendo el coste continuo y respetando la retención.
Poner barreras de protección al uso de BigQuery
- Exigir filtros de partición en tablas grandes y establecer valores predeterminados a nivel de proyecto para el máximo de bytes facturados por trabajo. Introducir vistas materializadas para agregados comunes y patrones de ingesta particionada.
- Justificación: Evita escaneos completos accidentales, estabiliza el gasto y acelera las consultas frecuentes.
Diseñar para el rendimiento con contrapresión y cuotas
- Integrar Cloud Tasks para flujos de trabajo con límite de tasa y configurar suscriptores de Pub/Sub con control de flujo. Implementar un retroceso exponencial con jitter para las API de terceros y establecer límites máximos de concurrencia por servicio en Cloud Run.
- Justificación: Controla la demanda para respetar las cuotas, protege las dependencias durante picos de carga y evita fallos en cascada.
Integrar la sostenibilidad en las operaciones
- Preferir servicios serverless cuando sea factible, seleccionar regiones con mayor energía libre de carbono para los análisis y programar trabajos por lotes no urgentes durante ventanas de bajas emisiones de carbono. Hacer seguimiento de las emisiones con Carbon Footprint e incluirlas en las revisiones trimestrales.
- Justificación: Mejora el rendimiento por vatio y reduce el impacto de carbono con mínimas concesiones de cara al usuario.
Gobernar continuamente

Crear presupuestos y alertas por producto, imponer el uso de etiquetas mediante políticas y establecer revisiones mensuales de coste-rendimiento-SLO. Automatizar la limpieza de recursos inactivos y discos no adjuntos basada en Recommender.
Justificación: La gobernanza continua mantiene los logros, previene regresiones y equilibra la fiabilidad, la seguridad, el rendimiento y el coste a lo largo del tiempo.

Este diseño reduce la salida de datos, estabiliza el coste de los análisis, garantiza un rendimiento predecible durante los eventos en vivo y promueve los objetivos de sostenibilidad sin comprometer la experiencia del usuario.

← DevOps · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →