- Los ingenieros de sistemas distribuidos muchas veces aprenden a través de las cicatrices que dejan los errores en producción
- Este texto fue escrito para evitar que los nuevos ingenieros pasen por esas mismas cicatrices
Los sistemas distribuidos fallan con frecuencia
- A diferencia de otras áreas de la ingeniería de software, los sistemas distribuidos tienen una alta probabilidad de fallar. En especial, tienen una alta probabilidad de fallas parciales.
- Los ingenieros de sistemas que no han trabajado en computación distribuida suelen proponer ideas como "solo hay que enviar la escritura a dos sistemas" o "basta con reintentar la escritura hasta que tenga éxito"
- Los sistemas en red fallan con más frecuencia que una sola máquina, y además esas fallas tienden a ser parciales
- Una de las escrituras puede tener éxito y la otra puede fallar, así que ¿cómo se obtiene ahora una vista consistente de los datos? Este tipo de falla parcial es mucho más difícil de razonar
- Pueden ocurrir problemas como que un switch se caiga, que el líder "desaparezca" por culpa del garbage collection, o que una escritura en socket parezca haber funcionado cuando en realidad falló. Leer desde memoria local es mucho más confiable que leer a través de varios switches
- Hay que "diseñar para la falla"
Escribir sistemas distribuidos robustos cuesta más
- Para construir una solución distribuida robusta se necesita más costo que para una solución de una sola máquina.
- Las máquinas virtuales y las tecnologías cloud abaratan la ingeniería de sistemas distribuidos, pero aun así siguen requiriendo mucho costo.
- Las simulaciones son útiles, pero no pueden resolver todos los problemas que aparecen en un entorno distribuido real.
Los sistemas distribuidos robustos de código abierto son poco comunes
- El costo de operar muchas máquinas durante largos períodos representa una carga para la comunidad open source.
- Quienes escriben código open source como hobby no suelen contar con los recursos financieros para explorar o resolver muchos de los problemas de los sistemas distribuidos.
- Algunos problemas los resuelven ingenieros dentro de empresas, pero sus prioridades no siempre coinciden.
La coordinación es muy difícil. Hay que evitarla siempre que sea posible
- La clave de la escalabilidad horizontal es la independencia. Hay que minimizar la comunicación y el consenso entre máquinas.
- Cada vez que dos máquinas tienen que ponerse de acuerdo sobre algo, la implementación del servicio se vuelve más difícil.
- El algoritmo Paxos es extremadamente difícil de implementar.
Si el problema cabe en memoria, probablemente sea trivial
- Para un ingeniero de sistemas distribuidos, un problema limitado a una sola máquina se considera fácil.
- Cuando los datos están a varios switches de distancia, procesarlos rápido se vuelve más difícil.
La "lentitud" es el problema más difícil
- La "lentitud" puede significar que uno o más de los sistemas involucrados en atender una solicitud del usuario están lentos.
- Las fallas parciales no aparecen en los gráficos, y hasta que no se vuelven evidentes es difícil conseguir los recursos necesarios para resolver el problema.
Hay que implementar backpressure en todo el sistema
- El backpressure significa señalizar fallas desde el sistema proveedor hacia el sistema solicitante, y cómo el sistema solicitante maneja esas fallas.
- Sin un mecanismo de backpressure, es mucho más probable que ocurran fallas en cascada o pérdida involuntaria de mensajes.
Hay que encontrar formas de estar parcialmente disponibles
- Se refiere a la capacidad de devolver algunos resultados incluso cuando una parte del sistema falla.
- Por ejemplo, si un sistema de búsqueda no logra recuperar todos los documentos dentro de cierto tiempo, devuelve los resultados recopilados hasta ese momento.
Las métricas son la única forma de hacer el trabajo
- Exponer métricas es la única forma de entender cómo funciona realmente un sistema.
- Los archivos de log son útiles, pero a menudo mienten. Los logs de éxito no suelen registrarse porque en la mayoría de los casos serían redundantes.
Hay que usar percentiles, no promedios
- Los percentiles son más precisos y más útiles que los promedios. Los promedios a menudo llevan a tomar malas decisiones.
Hay que aprender a estimar capacidad
- Es importante saber cuántas máquinas se necesitan para realizar un trabajo.
- Por ejemplo, con frecuencia hay que hacer cálculos rápidos sobre papel, como estimar cuántos IDs de tuits pueden almacenarse en memoria.
Los feature flags son la forma de hacer rollout de infraestructura
- Los feature flags son una forma común de hacer rollout de nuevas funcionalidades en un sistema.
- Usarlos permite ganar confianza en el proyecto y reducir el costo del fracaso.
Hay que elegir con cuidado el espacio de IDs
- El espacio de IDs de un sistema da forma a la estructura del propio sistema.
- Por ejemplo, el ID de un tuit en la API de Twitter es un simple número de 64 bits, sin conexión con otros datos.
Hay que aprovechar la localidad de los datos
- Mantener el procesamiento y el caché de los datos cerca del almacenamiento persistente es más eficiente.
- La red sufre más fallas y latencia que una desreferenciación de puntero y
fread(3).
Reescribir datos cacheados en el almacenamiento persistente es mala idea
- Este problema aparece en muchos sistemas. En especial, suele verse en sistemas diseñados por personas con poca experiencia en sistemas distribuidos.
Las computadoras pueden hacer más de lo que crees
- Circula mucha información incorrecta sobre la capacidad de las computadoras, especialmente entre profesionales con menos experiencia.
- Un servidor web moderno puede procesar miles de solicitudes en unos pocos cientos de milisegundos.
Hay que usar el teorema CAP para criticar sistemas
- El teorema CAP no sirve para construir sistemas. Sin embargo, es útil para criticar diseños de sistemas distribuidos.
Hay que extraer servicios
- Aquí, los servicios se refieren a sistemas distribuidos que contienen lógica de más alto nivel que un sistema de almacenamiento.
- Extraer servicios permite desplegar más rápido y más fácilmente que crear librerías.
Resumen de GN⁺
- La ingeniería de sistemas distribuidos es distinta de otras áreas de la ingeniería de software por su alta probabilidad de falla y por las fallas parciales.
- Escribir sistemas distribuidos robustos cuesta más y son poco comunes dentro de la comunidad open source.
- Es importante entender e implementar conceptos como coordinación, localidad de datos, backpressure y disponibilidad parcial.
- El uso de métricas y percentiles, feature flags y una buena elección del espacio de IDs puede mejorar la eficiencia y estabilidad del sistema.
- Conviene usar el teorema CAP para criticar sistemas y extraer servicios cuando sea necesario.
1 comentarios
Comentarios en Hacker News
El principio CALM (Consistency as Logical Monotonicity) es más fácil de entender y es un resultado más fundamental que CAP
La entrega exactamente una vez es imposible; hay que elegir entre entrega como máximo una vez o al menos una vez
Es un buen artículo. Aunque fue escrito hace 8 años, todavía tiene mucho contenido vigente
Enlaces a discusiones anteriores:
Me gusta la explicación práctica y realista. No hay palabras de moda como "microservicios"
Cuando trabajaba en Lookout, Jeff Hodges presentó este ensayo
Tengo experiencia trabajando con el autor de este texto
Muchas cosas han cambiado desde 2013