Administración de operaciones

El mecanismo de sincronización horaria interna de AWS - Amazon Time Sync Service y el diseño de smearing de segundos intercalares

Explicamos el mecanismo de Amazon Time Sync Service operado de forma independiente por AWS, la fuente de tiempo de alta precisión con GPS y relojes atómicos, la decisión de diseño de absorber los segundos intercalares mediante smearing y la importancia de la sincronización horaria en sistemas distribuidos.

約 8 分で読めます

Por qué la sincronización horaria es importante en la nube

En los sistemas distribuidos, la sincronización horaria precisa es más importante de lo que se imagina. Los registros de CloudTrail, las métricas de CloudWatch, las escrituras condicionales de DynamoDB, el versionado de objetos de S3 y la verificación de validez de certificados TLS son ejemplos de que prácticamente todos los servicios de AWS dependen de un tiempo preciso. Si el reloj se desfasa, la cronología de los registros se desordena y la investigación de incidentes se vuelve difícil. La verificación de validez de certificados TLS puede funcionar incorrectamente, juzgando como inválido un certificado que es válido. La autenticación Kerberos (Active Directory) rechaza la autenticación si la diferencia horaria entre cliente y servidor supera los 5 minutos. En bases de datos distribuidas, el desfase horario afecta directamente la consistencia de los datos. La razón por la que la base de datos Spanner de Google proporciona la API TrueTime usando relojes atómicos y GPS es para garantizar la consistencia de las transacciones distribuidas mediante la precisión del tiempo. AWS también ofrece su propia solución para este desafío: Amazon Time Sync Service.

Mecanismo de Amazon Time Sync Service

Amazon Time Sync Service es una fuente de tiempo de alta precisión ubicada en cada región de AWS. Desde las instancias EC2 se puede acceder al servidor NTP (Network Time Protocol) a través de la dirección link-local 169.254.169.123. Esta dirección, al igual que la 169.254.169.254 del servicio de metadatos, es link-local, no depende de la configuración de red y está disponible inmediatamente después del inicio de la instancia. La fuente de tiempo del Time Sync Service son antenas GPS y relojes atómicos (rubidio o cesio) ubicados en cada región. Los satélites GPS llevan relojes atómicos y proporcionan información horaria con precisión de nanosegundos. AWS coteja la información horaria del GPS con los relojes atómicos locales para mantener un tiempo preciso incluso si la señal GPS se interrumpe temporalmente. La latencia desde las instancias EC2 hasta el Time Sync Service es del orden de microsegundos, siendo órdenes de magnitud más precisa que los servidores NTP públicos de Internet (pool.ntp.org, etc.). Con los servidores NTP públicos la precisión se limita a milisegundos, mientras que con el Time Sync Service se obtiene precisión de microsegundos.

Smearing de segundos intercalares - Un diseño que no crea las 23:59:60

El segundo intercalar es un mecanismo que inserta 1 segundo en UTC (Tiempo Universal Coordinado) para compensar las variaciones en la velocidad de rotación de la Tierra. Cuando se inserta un segundo intercalar, después de las 23:59:59 aparece las 23:59:60, un tiempo que normalmente no existe. Estas 23:59:60 son un valor inesperado para muchos programas y han causado múltiples incidentes a gran escala en el pasado. En el segundo intercalar de 2012, un error en el kernel de Linux causó fallos en servicios como Reddit, Mozilla y Yelp. Amazon Time Sync Service procesa los segundos intercalares mediante "smearing". Distribuye uniformemente 1 segundo a lo largo de las 12 horas antes y después del segundo intercalar, ajustando el tiempo gradualmente. Es decir, el tiempo 23:59:60 nunca aparece; en su lugar, el ajuste de 1 segundo se realiza a lo largo de 24 horas. Cada segundo se alarga aproximadamente 11.6 microsegundos, pero esta diferencia es insignificante para la mayoría de las aplicaciones. El servidor NTP de Google también adopta un smearing similar, pero como el método de smearing (lineal, onda coseno, etc.) difiere, mezclar servidores NTP con diferentes métodos de smearing puede causar inconsistencias horarias. En entornos AWS se recomienda usar exclusivamente el Time Sync Service.

ClockBound - Visualización de la incertidumbre del tiempo

ClockBound, publicado como código abierto por AWS en 2021, es un daemon que proporciona el "rango de incertidumbre" del tiempo actual. El tiempo sincronizado por NTP contiene errores debidos a la latencia de red y la deriva del reloj. ClockBound calcula los límites superior e inferior de este error y proporciona la información de que "el tiempo verdadero actual está en el rango de X ± Y microsegundos". Esta información puede usarse para el ordenamiento de transacciones en bases de datos distribuidas. Si la diferencia de timestamps entre dos eventos está dentro del rango de incertidumbre, no se puede determinar cuál ocurrió primero. Si excede el rango de incertidumbre, se puede determinar el orden. Es un concepto similar a la API TrueTime de Google Spanner, pero ClockBound es de código abierto y puede usarse en entornos fuera de AWS. Los servicios gestionados de AWS como DynamoDB y Aurora están diseñados internamente considerando este tipo de incertidumbre temporal, pero cuando los usuarios construyen sus propios sistemas distribuidos, pueden prevenir inconsistencias de datos causadas por el tiempo aprovechando ClockBound.

Problemas reales causados por fallos en la sincronización horaria

Los problemas de sincronización horaria tienen síntomas difíciles de identificar y causas difíciles de determinar. Presentamos algunos patrones de problemas que ocurren en la práctica. Primero, el fallo de verificación de certificados TLS. Si el reloj de la instancia se adelanta al futuro, un certificado aún válido se juzga como "expirado". Si se atrasa al pasado, se juzga como "aún no ha entrado en su período de validez". Cuando las comunicaciones HTTPS comienzan a fallar repentinamente, el desfase horario puede ser la causa. Segundo, el fallo de autenticación de la API de AWS. La firma SigV4 incluye un timestamp, y si la diferencia entre el timestamp de la solicitud y el tiempo del servidor de AWS supera los 5 minutos, la solicitud es rechazada. Tercero, el desorden cronológico de los registros. Al agregar registros de múltiples instancias, los registros de instancias con desfase horario no se ordenan cronológicamente, dificultando la investigación de incidentes. Como medida, configure chrony (cliente NTP) en todas las instancias EC2 y use Amazon Time Sync Service (169.254.169.123) como única fuente de tiempo. En Amazon Linux 2 y posteriores viene configurado por defecto. Para aprender sistemáticamente sobre sincronización horaria y diseño de sistemas distribuidos, los libros especializados (Amazon) son una buena referencia.

Servicios relacionados

Amazon CloudWatchUn servicio que proporciona monitoreo, gestión de logs y alarmas para recursos AWS y aplicacionesAWS CloudTrailUn servicio que registra y monitorea la actividad de API en cuentas AWS

Artículos relacionados

La cultura de excelencia operativa de AWS - Calidad operativa respaldada por GameDay, Wheel of Fortune y Ops as CodeExplicamos las prácticas de GameDay (simulación de fallos), Wheel of Fortune (inyección aleatoria de fallos) y Ops as Code que AWS implementa organizacionalmente para elevar la calidad operativa, comparándolas con los enfoques operativos de Azure y GCP.Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasadoA partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.Por qué DynamoDB garantiza milisegundos de un dígito - Estructura interna del particionamiento y el router de solicitudesExplicamos el mecanismo por el cual DynamoDB mantiene latencia de milisegundos de un dígito independientemente de la escala, desde la arquitectura de 3 capas: algoritmo de particionamiento, router de solicitudes y nodos de almacenamiento.

Más sobre este tema

Centralización de registros de auditoría SaaS con AWS AppFabric - Estandarización OCSF e integración con Security LakeExplicamos la recopilación de registros de auditoría de aplicaciones SaaS con AppFabric, la estandarización al formato OCSF y la construcción de pipelines de análisis.Implementación de Feature Flags con AWS AppConfig - Despliegue seguro de configuración y rollbackDespliega cambios de configuración de forma independiente al código mediante estrategias Linear y Exponential. Garantiza la seguridad con rollback automático activado por alarmas de CloudWatch.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo usando AWS Well-Architected Tool. Presenta la evaluación basada en 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizados.Diseño y operación de logs de auditoría - Registro completo de actividad API con CloudTrailExplica las técnicas de diseño de logs de auditoría con AWS CloudTrail, el registro de actividad API, el almacenamiento a largo plazo en S3 y la respuesta de cumplimiento mediante integración con Config.Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasadoA partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.El diseño de tags determina las operaciones - Curiosidades y reglas de nomenclatura prácticas de la estrategia de tags de recursos AWSExplicamos por qué los tags de recursos AWS no son simples etiquetas sino la base de la asignación de costos, control de acceso y automatización, las reglas de nomenclatura de claves de tags, cómo usar el límite de 50 tags y la gobernanza mediante políticas de tags.Por qué existen las cuotas de servicio de AWS - Diseño multitenant que protege la infraestructura compartidaExplicamos que las cuotas de servicio de AWS (antes límites de servicio) no son simples restricciones sino un diseño para proteger a otros clientes en un entorno multitenant, desde el problema del vecino ruidoso, la diferencia entre límites soft y hard, y el trasfondo de las solicitudes de aumento.Gestion centralizada de backups con AWS Backup - Planes de backup y proteccion cross-regionGestione backups de EC2, RDS, DynamoDB y mas bajo una politica unificada. Cubre la proteccion WORM con Vault Lock y la automatizacion de pruebas de restauracion.

Artículos y servicios similares

Principios de sistemas distribuidos aprendidos de las interrupciones de AWS - Arquitecturas transformadas por grandes incidentesUsando como material los informes de incidentes publicados por AWS, como la interrupción de S3 (2017), la interrupción de Kinesis (2020) y la particularidad de us-east-1, explicamos principios de diseño como Shuffle Sharding, Static Stability y Cell-based Architecture.Automatización de la gestión de certificados SSL/TLS con AWS Certificate Manager - Desde la emisión hasta la rotaciónExplicamos la emisión gratuita de certificados públicos con ACM, la validación DNS, la renovación automática y el despliegue en ALB y CloudFront.Amazon DynamoDBServicio de base de datos NoSQL completamente administrado que garantiza latencia de milisegundos y escala automáticamente ante cualquier volumen de tráficoGestión de certificados y HTTPS - Operaciones automatizadas de certificados TLS con AWS Certificate ManagerAprenda sobre la emisión de certificados TLS/SSL, renovación automática y despliegue usando AWS Certificate Manager (ACM). Cubre la integración con CloudFront, ALB y API Gateway, validación DNS y uso de Private CA.La filosofía Two-Pizza Team y la separación de servicios - Por qué AWS mantiene la calidad en más de 200 serviciosExaminamos cómo el Two-Pizza Team, fundamento del diseño organizacional de AWS, contribuye a la independencia y calidad de los servicios, comparándolo con el enfoque de integración de Azure y la estructura organizacional de GCP.