Google PCD: Rendimiento, escalabilidad e ingeniería de resiliencia — Guía de estudio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Developer — 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

La ingeniería de rendimiento, escalabilidad y resiliencia en Google Cloud se centra en mantener un servicio de baja latencia y rentable bajo una carga variable, a la vez que tolera fallos sin violar los SLO. El diseño debe alinear las señales de autoescalado con las características de la carga de trabajo, ubicar los datos y la computación para minimizar la latencia de cola (tail latency), e implementar controles de sobrecarga, reintentos y conmutación por error (failover) para evitar fallos en cascada. Esta sección detalla los patrones, controles y concesiones que son importantes para los desarrolladores de aplicaciones en las capas de computación, redes y datos.

Escalado y distribución de la carga

Escalado horizontal frente a vertical

El escalado horizontal añade instancias o pods para aumentar la capacidad y la resiliencia. Es preferible para servicios sin estado (stateless) y cuando se necesita una elasticidad rápida. Utiliza Managed Instance Groups (MIGs), revisiones de Cloud Run o Deployments de GKE.
El escalado vertical aumenta el tamaño de la máquina. Es útil para cargas de trabajo monohilo (single-threaded) o limitadas por memoria, o para reducir la coordinación entre nodos, pero ofrece un margen de crecimiento limitado y tiempos de reinicio más largos.
Concurrencia: Ajusta la concurrencia de solicitudes para que coincida con los perfiles limitados por CPU (CPU-bound) frente a los limitados por E/S (I/O-bound). Cloud Run admite concurrencia por revisión; los pods de GKE pueden atender múltiples solicitudes si tu entorno de ejecución no es bloqueante; para un aislamiento estricto, establece la concurrencia en 1.

Señales de autoescalado y capacidad precalentada (warm capacity)

El autoescalado de MIG admite la utilización de CPU, la utilización del balanceo de carga y métricas personalizadas a través de Cloud Monitoring. Para tráfico en ráfagas (bursty), basa el escalado en métricas de solicitud (rps, profundidad de la cola) en lugar de en la CPU.
El Horizontal Pod Autoscaler (HPA) de GKE puede escalar en función de la CPU, la memoria o métricas personalizadas/externas (p. ej., la longitud de la cola de Pub/Sub). Utiliza el Vertical Pod Autoscaler (VPA) para el ajuste de tamaño (right-sizing), pero evita las actualizaciones en vivo del VPA en los frontends que escalan rápidamente para prevenir la rotación excesiva (churn).
Cloud Run escala en función de la carga de solicitudes concurrentes y, opcionalmente, de métricas personalizadas. Evita los arranques en frío (cold starts) manteniendo capacidad precalentada: configura un número mínimo de instancias, mantén baja la concurrencia inactiva y precalienta mediante pings de salud sintéticos si es necesario.
El autoescalado predictivo en los MIG y la configuración de min replicas en un Deployment/Revisión ayudan a enmascarar la latencia de aprovisionamiento durante los picos diurnos.

Balanceo de carga, distribución de tráfico global, comprobaciones de estado y conmutación por error (failover)

Utiliza el Application Load Balancer externo global para obtener una VIP anycast mundial, HTTP/2 y HTTP/3, y terminación en el borde (edge) con Cloud CDN. Los backends pueden ser grupos de instancias, NEG zonales/regionales, NEG sin servidor (serverless) (Cloud Run/Functions) o GKE Ingress.
Las comprobaciones de estado desvían el tráfico de los backends en mal estado. Asegúrate de que tus puntos finales (endpoints) de salud validen las dependencias de forma restringida (p. ej., el proceso y los recursos locales críticos) para evitar fallos circulares durante interrupciones de servicios dependientes (downstream).
Las listas de permitidos (allowlists) del firewall deben permitir los verificadores de estado. Si las comprobaciones al puerto 80 fallan, permite los rangos de Google: gcloud compute firewall-rules create allow-lb –network load-balancer –allow tcp –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
Conmutación por error (Failover): Configura servicios de backend primarios y de respaldo, o políticas de tráfico que dirijan el tráfico a regiones alternativas en caso de fallo de la comprobación de estado. Para la conmutación por error a nivel de DNS, utiliza políticas de Cloud DNS con comprobaciones de estado para puntos finales que no son HTTP.

Latencia y Eficiencia

Presupuestos de latencia

Asigna un presupuesto de latencia de extremo a extremo por nivel (cliente, borde, aplicación, datos). Monitoriza p95/p99, no los promedios. Utiliza Cloud Trace para encontrar contribuyentes entre servicios y bloqueos de cabecera de línea (head-of-line blocking). Aplica plazos (deadlines) a las RPC para que la cancelación ascendente (upstream) libere capacidad.

Uso de caché y CDN

Cachés por capas: caché del cliente/navegador, caché en el borde de la CDN (Cloud CDN) y cachés regionales/en memoria (Memorystore o en proceso). Elige las claves de caché y las cabeceras Vary con cuidado. Establece los TTL basándote en la frescura de los datos y el riesgo de obsolescencia; considera el caché negativo para los 404 cuando sea seguro.
Sirve los activos estáticos desde Cloud Storage detrás de Cloud CDN para reducir la carga en el origen y la latencia de cola. Utiliza URL/cabeceras firmadas para un acceso controlado.

Reutilización de conexiones

Prefiere HTTP/2 o gRPC para la multiplexación y la compresión de cabeceras. Habilita los keep-alives y el agrupamiento de conexiones (connection pooling) para reducir la sobrecarga del handshake. Vigila el agotamiento de puertos NAT; ajusta los grupos de conexiones del cliente y los tiempos de espera de inactividad (idle timeouts), y dimensiona los puertos de Cloud NAT por VM si corresponde.

Eficiencia de la carga útil (payload)

Utiliza codificaciones binarias (p. ej., protobuf) y comprime las cargas útiles de texto (gzip/brotli) por encima de un umbral de tamaño. Diseña los campos de solicitud/respuesta cuidadosamente; pagina, filtra en el lado del servidor y evita la obtención excesiva de datos (over-fetching). Usa ETags y solicitudes condicionales (If-None-Match) para evitar transferencias redundantes. Para Cloud Storage, utiliza precondiciones de generación y lecturas Range para contenido parcial.

Patrones de sobrecarga y resiliencia

Limitación de velocidad, contrapresión, encolamiento y procesamiento por lotes

Aplica límites de velocidad en el borde (edge) (Cloud Armor para limitación de velocidad basada en IP/geolocalización/servicio) y en la capa de API (cuotas de Apigee, tokens por cliente de API). Implementa algoritmos de token bucket o leaky bucket del lado del servidor para una distribución equitativa.
Contrapresión (Backpressure): No sobrepases la capacidad de los sistemas de destino (downstreams). Usa colas (Pub/Sub para entrega de eventos de tipo at-least-once; Cloud Tasks para límites de velocidad por cola y por destino con programación y reintentos). Propaga los códigos 429 Too Many Requests o 503 con la cabecera Retry-After para rechazar a los clientes.
El procesamiento por lotes (batching) puede aumentar el rendimiento (throughput) y reducir la sobrecarga por llamada (p. ej., mutaciones por lotes a bases de datos o confirmaciones [acks] por lotes en Pub/Sub), intercambiando una mayor latencia por eficiencia. Ajusta el tamaño del lote y el tiempo de espera máximo.

Protección contra sobrecargas

Aplica tiempos de espera (timeouts) y plazos (deadlines) a cada RPC. Usa circuit breakers (interruptores de circuito) para dejar de enviar trabajo a dependencias que fallan y habilitar mecanismos de fallback rápidos. Implementa la descarga de carga (load shedding) basada en la profundidad de la cola, el uso de CPU o el incumplimiento del SLO de latencia para proteger la funcionalidad principal.

Reintentos resilientes, retroceso exponencial (exponential backoff), fluctuación (jitter), idempotencia y manejo de duplicados

Reintenta solo cuando sea seguro: tiempos de espera de red, códigos 5xx o códigos documentados como reintentables (p. ej., Cloud Storage 429/5xx). Nunca reintentes con códigos 4xx como 400/401/403 a menos que se especifique.
Usa retroceso exponencial truncado (truncated exponential backoff) con fluctuación (jitter) para evitar reintentos sincronizados. Prefiere la fluctuación completa (full jitter). Ejemplo:

undefined

Asegura la idempotencia. Usa claves de idempotencia (p. ej., un ID de operación único) y operaciones de tipo upsert/escrituras condicionales para tolerar duplicados. Para Pub/Sub, elimina duplicados usando el messageId o claves de aplicación; diseña los manejadores (handlers) para que sean seguros ante una entrega de tipo at-least-once. Para escrituras en Cloud Storage, usa precondiciones de coincidencia de generación (generation-match) para evitar sobrescrituras.

Calentamiento de recursos inactivos (ramp-up)

Algunos servicios aplican límites adaptativos. Para Cloud Storage, aumenta gradualmente la tasa de solicitudes en buckets previamente inactivos para reducir los errores transitorios 429/5xx durante picos repentinos. Limita la velocidad de los productores y calienta los buckets con tráfico controlado antes de aplicar la carga completa.

Alta disponibilidad, datos, DR y pruebas

Multizona, regional, multirregional; activo-activo vs. activo-pasivo

Despliega entre dominios de fallo. Usa MIGs regionales o clústeres de GKE regionales para la tolerancia a fallos de zona. Para servicios globales, usa múltiples regiones con el balanceador de carga global.
Activo-activo reduce el RTO y la latencia, pero exige datos sin conflictos y una gestión cuidadosa de la consistencia. Activo-pasivo simplifica la semántica de escritura, pero incurre en un RTO más alto y en una posible capacidad en frío.

RTO, RPO, copias de seguridad, restauración y pruebas de recuperación ante desastres

Define el RTO (tiempo para recuperar el servicio) y el RPO (pérdida de datos tolerable) por cada carga de trabajo. Asigna a las capacidades de la plataforma:
- Cloud Spanner: multirregional con cinco 9s de disponibilidad y replicación síncrona para un RPO cercano a cero.
- Cloud SQL: Alta disponibilidad dentro de una región; usa réplicas entre regiones para DR, habilita PITR y valida los runbooks de failover y failback.
- Firestore y Bigtable ofrecen opciones regionales y multirregionales; elige para cumplir con el RTO/RPO.
- Los buckets de Cloud Storage de doble o multirregión proporcionan georredundancia; verifica los procedimientos de restauración y la reemisión de URL firmadas.
Prueba el DR: Ejecuta simulacros de failover regularmente. Valida las copias de seguridad restaurándolas en un entorno aislado, ensaya el failover de DNS/tráfico y mide el RTO/RPO real.

Rendimiento de bases de datos y almacenamiento, diseño de índices, hot keys y contención

Cloud Spanner: Evita las claves primarias que aumentan monotónicamente y que causan hotspots. Usa tablas intercaladas (interleaved) para la localidad, índices secundarios para los patrones de lectura y transacciones limitadas (bounded) para reducir los conflictos de bloqueo. Dimensiona los nodos para QPS y almacenamiento; mantén al menos tres nodos para el quórum de producción y el margen de crecimiento (headroom).
Cloud SQL: Analiza las consultas, añade índices de cobertura (covering indexes), evita transacciones largas y usa pools de conexiones. Ajusta la configuración de InnoDB o Postgres con criterio; escala las réplicas de lectura para cargas de trabajo con mucha lectura.
Bigtable: Diseña las claves de fila (row keys) para distribuir la carga de manera uniforme (salting o inversión de campos). Usa el enrutamiento multiclúster para alta disponibilidad entre regiones si está disponible.
Firestore: Usa índices compuestos para consultas de múltiples campos; ten cuidado con el hotspotting cuando muchas escrituras apuntan a la misma ruta de documento.
Cloud Storage: Consistencia fuerte de lectura tras escritura para objetos nuevos; usa cargas paralelas y fragmentación (chunking) para el rendimiento (throughput). Aumenta el tráfico gradualmente en buckets inactivos; prefiere el borde de la CDN para lecturas frecuentes (hot reads). Para muchas VM que necesitan el mismo conjunto de datos grande de solo lectura, adjunta un disco persistente en modo de solo lectura a múltiples instancias para un acceso local rápido a bajo costo.

Pruebas de carga, experimentos de caos, inyección de fallos y planificación de capacidad

Pruebas de carga: Simula formas de tráfico y distribuciones de datos realistas. Precalienta las cachés y los autoscalers; prueba la latencia p95/p99 bajo carga y durante eventos de escalado. Refleja una pequeña fracción del tráfico en vivo a pilas en la sombra (shadow stacks) para validar el comportamiento con la complejidad de producción.
Caos e inyección de fallos: Mata pods/VMs, acordona una zona, inyecta latencia/errores en la malla de servicios (service mesh) (p. ej., Envoy/Istio) para observar el radio de impacto (blast radius) y la resiliencia. Verifica que los circuit breakers y los reintentos se comporten como se espera.
Planificación de capacidad: Pronostica usando la demanda histórica y los eventos planificados. Mantén un margen de crecimiento (headroom) para fallos N+1 y rebalanceo. Alinea los periodos de enfriamiento (cooldowns) y las tasas máximas del autoscaler con los picos esperados; preaprovisiona durante los picos predecibles.

Compromisos de disponibilidad entre servicios gestionados y arquitecturas personalizadas

Cómputo: Cloud Run ofrece un escalado a cero rápido y una baja sobrecarga operativa, pero tiene arranques en frío (cold starts) y limitaciones de concurrencia de solicitudes. GKE proporciona un control detallado y portabilidad a un costo operativo mayor. Las VM de Compute Engine proporcionan el máximo control con la mayor carga operativa.
Datos: Cloud Spanner proporciona consistencia global y alta disponibilidad a un costo mayor y con mayor rigor de esquema. Cloud SQL se ajusta a los RDBMS tradicionales con operaciones más simples, pero con HA/escalabilidad limitadas. Bigtable sobresale en el almacenamiento de clave-valor/series temporales a escala masiva y con baja latencia. Firestore proporciona esquemas flexibles con consistencia fuerte y opciones globales.
Redes: Los balanceadores de carga globales y Cloud CDN son altamente disponibles y operan en el borde de Google; los proxies autogestionados (DIY) ofrecen personalización, pero crean riesgos operativos y de fallo.
Prefiere los servicios gestionados para una mayor disponibilidad base y resistencia a DDoS, pero ten en cuenta las cuotas, los arranques en frío y la semántica específica del servicio en tu diseño.

Escenario de problema práctico

NimbusMart, una empresa global de comercio electrónico, necesita una API de catálogo de productos de baja latencia con cinco 9s de disponibilidad y una latencia de lectura minimizada para usuarios en Norteamérica, Europa y Asia-Pacífico. Las escrituras deben ser globalmente consistentes. El tráfico tiene picos durante las ventas relámpago (flash sales), y los incidentes históricos incluyen reintentos en cascada y sobrecarga del origen.

Enfoque:

Aprovisiona una instancia multirregional de Cloud Spanner usando nam-asia-eur1 con al menos tres nodos.

Justificación: Ofrece lecturas/escrituras globalmente consistentes con cinco 9s de disponibilidad y ubica las réplicas cerca de los usuarios para reducir la latencia de lectura. Un mínimo de tres nodos proporciona robustez de quórum y margen de crecimiento (headroom) para el rebalanceo.

Implementa una capa de API sin estado (stateless) en múltiples regiones detrás del Application Load Balancer externo global.

Justificación: La VIP de Anycast y el enrutamiento global reducen el establecimiento de la conexión y dirigen a los usuarios a la región saludable más cercana. Los servicios sin estado facilitan el escalado horizontal y el failover.

Configura las comprobaciones de estado (health checks) y las reglas de firewall para la accesibilidad del balanceador de carga.

Justificación: Las comprobaciones de estado evitan el enrutamiento a backends no saludables. Permite los rangos de IP de las comprobaciones de estado de Google para que estas tengan éxito:

undefined

Implementa el autoescalado basado en métricas de solicitud con capacidad precalentada (warm capacity).

Justificación: Escala los MIGs o el HPA de GKE basándose en QPS/latencia en lugar de CPU para reaccionar al tráfico de las ventas relámpago. Mantén un número mínimo de réplicas por región para evitar arranques en frío y habilita el autoescalado predictivo antes de eventos conocidos.

Añade Cloud CDN para los medios estáticos de los productos almacenados en Cloud Storage.

Justificación: El almacenamiento en caché en el borde (edge caching) descarga el origen, reduce la latencia de cola (tail latency) y mitiga la amplificación de ráfagas en las capas de aplicación y almacenamiento. Usa URL firmadas y claves de caché/TTLs apropiados.

Aplica protección contra sobrecargas y limitación de velocidad (rate limiting) en el borde y en el servicio.

Justificación: Configura límites de velocidad en Cloud Armor para absorber picos abusivos. En el servicio, usa límites de tipo token-bucket por cliente y descarta las solicitudes de baja prioridad cuando los SLO de latencia se vean amenazados. Aplica plazos (deadlines) a cada llamada descendente.

Usa reintentos resilientes con truncated exponential backoff y full jitter; asegura la idempotencia con ID de operación.

Justificación: Evita estampidas (thundering herds) y escrituras duplicadas durante fallos parciales. Las claves de idempotencia aseguran reintentos seguros; para operaciones de almacenamiento, usa precondiciones condicionales.

Introduce una cola de escritura para suavizar ráfagas (burst smoothing) y para la asincronía donde sea aceptable.

Justificación: Pub/Sub amortigua los picos repentinos de escrituras no críticas (p. ej., eventos de analítica), desacoplando a los productores de Spanner y protegiendo las rutas de escritura primarias de la sobrecarga.

Define SLOs y presupuestos de latencia; instrumenta el trazado (tracing) y los dashboards.

Justificación: Los presupuestos por nivel guían la optimización. Los SLO de Cloud Monitoring con presupuestos de error (error budgets) y Cloud Trace revelan los contribuyentes interregionales y de la capa de datos a la latencia p99.

Establece runbooks de DR y prueba el failover.

Justificación: Con Cloud Spanner multirregional y cómputo multirregional, practica simulacros de evacuación de región. Verifica el RTO con cronogramas de drenaje y aumento de tráfico, y valida que los autoscalers y la CDN se comporten correctamente durante el failover.

Este diseño satisface los objetivos de disponibilidad global y baja latencia al alinear la topología de cómputo y datos, aplicar controles de sobrecarga y usar servicios gestionados que proporcionan escalabilidad y resiliencia probadas.

← Observabilidad · Todos los dominios · Pruebas →

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