El Teorema CAP es un principio fundamental en el diseño de sistemas distribuidos que implica que, en presencia de una partición de la red, un sistema debe elegir entre mantener la consistencia o el 100% de disponibilidad. En 2017, Google presentó Spanner para Google Cloud, una base de datos global SQL que desafiaba el teorema CAP: Spanner puede ofrecer consistencia y disponibilidad frente a particiones de red, a pesar de estar altamente distribuido a nivel global. ¿Cómo es esto posible? En este blog explicamos el teorema CAP y su relación con Spanner.
Entendiendo el teorema CAP
El Teorema CAP establece que, en un sistema distribuido, es imposible garantizar simultáneamente estas tres siguientes propiedades:
- Consistencia (Consistency): Todos los nodos del sistema tienen la misma vista de los datos, la más reciente, en cualquier momento dado.
- Disponibilidad (Availability): El 100% de las solicitudes de un cliente recibe una respuesta, tanto para lecturas como escrituras.
- Tolerancia a particiones (Partition Tolerance): El sistema sigue funcionando incluso si hay una partición en la red que impide la comunicación entre algunos o todos los nodos.
El teorema CAP implica que un sistema distribuido, como una base de datos, puede cumplir con dos de las tres propiedades a la vez, pero no con las tres simultáneamente. Esto significa que los diseñadores de sistemas distribuidos deben elegir dos de las características y sacrificar la tercera, según la necesidad o objetivo de cada sistema. Según el Teorema CAP, en presencia de una partición de la red, un sistema debe elegir entre consistencia y disponibilidad. Por lo tanto, esto nos deja con dos posibilidades:
- CP: Frente a una partición de red, el sistema es consistente, por lo que algunas peticiones de lecturas o escrituras fallará. Este es el modelo que implementa MongoDB.
- AP: Frente a una partición de red, el sistema atiende el 100% de las peticiones de lectura y escritura, pero puede devolver datos antiguos que no están actualizados. En este caso, al restaurar la partición de red, se deberán aplicar mecanismos para hacer que el sistema recupere su consistencia. Este es el modelo que implementa Cassandra.
Qué garantías tiene Spanner: ¿consistencia o disponibilidad?
Spanner sostiene que es tanto consistente como altamente disponible pese a ser un sistema distribuido a nivel global, haciéndolo un sistema CA. Entonces, ¿Spanner no contempla particiones de red? En un sistema distribuido, las particiones siempre pueden ocurrir, incluso a la escala de la nube de Google. La respuesta es que, en realidad, Spanner sí tolera particiones, en las que se prioriza la consistencia sobre la disponibilidad, lo que lo convierte técnicamente en un sistema CP.
¿Cómo puede Spanner entonces ser altamente disponible? La cuestión aquí es que, el teorema CAP contempla un 100% de disponibilidad. Aunque ningún sistema garantiza una disponibilidad del 100%, en la práctica, Spanner ofrece una disponibilidad tan alta que la mayoría de los usuarios no deben preocuparse de la disponibilidad. Spanner anuncia que alcanza más de cinco nueves de disponibilidad (99.999% de disponibilidad, menos de una falla en 100.000).
La trampa: evitar las particiones de red
La alta disponibilidad de Spanner se debe a la red global privada de Google y las mejoras operativas que mitigan o hasta llegan a evitar las particiones. Google controla completamente su red cloud privada, en vez de utilizar una wide are network “descontrolada” como internet, y asegura redundancia de caminos de red entre los centros de datos. De hecho, el riesgo principal no es un hecho físico, como la caída de un operador de red, sinó las actualizaciones de software que puedan contener fallos que rompan múltiples caminos simultáneamente, un riesgo que Google trabaja constantemente para prevenir y mitigar.
Aún así, Spanner tolera particiones implementando un complejo sistema de coordinación entre los nodos de la base de datos. Spanner utiliza two-phase commit (2PC) y bloqueo estricto de dos fases para asegurar la consistencia. Aunque 2PC impide la disponibilidad total, pero Spanner lo mitiga utilizando grupos Paxos, que permiten que cada miembro sea altamente disponible. Esto puede resultar en que algunos usuarios queden sin acceso, pero la mayoría de los servicios multi-región seguirán siendo operativos. Además, Spanner utiliza TrueTime, un sistema de sincronización global de tiempo que contribuye significativamente a garantizar las transacciones multi-regiones en situaciones de fallos de red. Spanner también soporta “snapshots”, que son consistentes y no requieren bloqueos.
En resumen, Spanner puede ser visto como dos tipos de sistema, según el teorema CAP: CP + A, pero no al 100%; o bien CA + P cercana a cero.
Fuentes:
https://cloud.google.com/blog/products/databases/inside-cloud-spanner-and-the-cap-theorem
https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45855.pdf
Leave a Reply