Encuentro sumamente interesante el artículo que escribe Randy Shoup sobre cuáles son las mejores prácticas de escalabilidad que aplican en eBay. Para ellos, escalar es realmente una necesidad, ya que sirven 2.000 millones de páginas diarias.
Particionar por funciones
Es decir, desacoplar funcionalidades. Separan las funcionalidades (venta, búsqueda, etc.) en pooles, de manera que cada pool puede escalar independientemente de los demás. Tienen 16.000 servidores de aplicaciones en 220 pooles. Asimismo, tienen 1.000 bases de datos en 400 máquinas.
Dividir horizontalmente
Los servidores de aplicaciones no guardan información del estado y utilizan balanceadores, con lo que el crecimiento horizontal es trivial. Si necesitan más recursos, simplemente añaden un nuevo servidor de aplicaciones.
En el caso de las bases de datos, lo que hacen es dividir según la clave por la que se accede al dato. Por ejemplo, los usuarios los tienen en 20 bases de datos. La base de datos en la que se almacena un usuario dependerá de su identificador. Para calcular dónde se almacenará un dato utilizan la función módulo, rangos de identificadores, tablas de consulta, etc.
Evitar las transacciones distribuidas
Al particionar, la operaciones habituales de actualización requerirán actualizar más de un tipo de recurso. La forma ortodoxa de implementar esto es mediante una transacción distribuida y un commit en dos fases para asegurar la integridad. Pues bien, el rendimiento y la latencia se ven seriamente afectados por este coste de coordinación. Según el teorema CAP, de las tres propiedades deseadas en un sistema distribuido, es decir, consistencia (C), disponibilidad (A) y particionado (P), hay que elegir sólo dos. En eBay, debido al alto tráfico, eligen P, para poder escalar, y A, ya que deben prestar su servicio 7×24. Para asegurar la integridad emplean técnicas de recuperación asíncronas.
Integrar asíncronamente los recursos
Si el recurso A llama al recurso B síncronamente, entonces si escalo A tengo que escalar B. Además, si B está caído, A fallará también. Por esto, es mejor que A y B se integren asíncronamente, por ejemplo, con una cola o con un proceso batch.
Procesar asíncronamente
Habrá parte del procesado de datos que pueda convertirse en procesado asíncrono. De esta manera, reduciremos la latencia del procesado que deba ser síncrono. Asimismo, podemos reducir los costes, ya que el dimensionado del procesado síncrono hay que hacerlo siempre para el pico de carga.
Virtualizar en todos los niveles
El sistema operativo realiza una abstracción del hardware, la correspondencia entre los objetos y las tablas realiza una abstracción de la base de datos, los balanceadores de carga y las IP virtuales realizan una abstracción de la infraestructura de red.
En eBay las aplicaciones interaccionan con una representación lógica de la base de datos En el momento de acceder a un dato se calcula cuál es la instancia física a la que hay que acceder según cierta configuración. Si fuera necesario, se podría cambiar dicha correspondencia entre el modelo lógico y la implementación física sin tener que cambiar el código.
Cachear apropiadamente
La estrategia de caching deberá ser planificada cuidadosamente y deberá tener en cuenta aspectos como el coste y la disponibilidad.
![[Valid RSS]](/wp-content/themes/javiervidal/images/valid-rss.png "Validate my RSS feed")