He estado viendo esta charla publicada hace unos días en InfoQ en la que el CTO de BetFair.com comenta como fue evolucionando su sistema de gestión de transacciones y como construyeron un motor capaz de funcionar tanto para apuestas deportivas como para mercados financieros.
El contenido de la charla es bastante interesante, aunque la charla en sí no es nada amena, así que no sabría si recomendárosla. Creo que sólo si os gusta el tema.
Uno de los comentarios interesantes de la charla es que parece que Oracle les comentó que BetFair puede ser una de las cinco aplicaciones más "calientes" del mundo en cuanto a contención de recursos.
En su caso el problema no es tanto la escalabilidad sino más bien el mantener el rendimiento del servidor durante determinadas ventanas de tiempo. En su web normalmente la mayoría de usuarios se concentran únicamente en torno a determinados eventos 'live'. Una vez que esos eventos terminan, los usuarios se mueven a otro evento. Un ejemplo es una carrera de caballos. La carrera empieza, se va sucediendo, termina y los usuarios se mueven a la siguiente carrera.
Todo esto los deja con que el problema pasa a ser un problema de optimización. ¿Cómo conseguir que el sistema se mantenga ejecutándose con un buen rendimiento de manera continua?
La gestión del riesgo y gestión de apuestas es mucho más sencilla ya que se puede dividir en clientes o cuentas, lo que permite fácilmente particionar y procesar en paralelo. La actividad de cada cuenta en estos sistemas suele ser pequeña, es decir, ningún usuario está ahí sentado en su ordenador ejecutando 50.000 apuestas por segundo.
La vista de mercado es read-only lo que les permite una serie de optimizaciones. El multi-casting es común para enviar el estado de las apuestas a diferentes clientes. Eso funciona para sus clientes de escritorio pero en la web tienen problemas. Ahora mismo utilizan polling. Están intentando migrar a una aproximación basada en streaming y comet pero todavía no estaba acabado.
En cuanto a la transaccionalidad, ahí es donde las cosas se tornan complejas. El objetivo de BetFair era pasar de las 500 TPS a las 50000 TPS. Para ello mantuvieron diferentes rondas de entrevistas con equipos y empresas clave, como puedan ser las compañías que desarrollan los mercados de valor por ejemplo. Pero aparentemente ninguna solución se ajustaba exactamente al modelo de BetFair. Les propusieron una especie de competición para conseguir el motor más rápido (asumo que o bien les pagaron o bien compartiron la propiedad intelectual), y BetFair salió ganando.
Todo el modelo de transaccionalidad se basa en el control programático de las transacciones, lo que muchas veces les obliga a compensar transacciones cuando hay que hacer algún rollback; en el uso de mensajería; y finalmente en el mantener enormes registros de auditoría con todas las operaciones. De modo que si algún servidor o algún agente se cae, puedan replicar todas las acciones que había pendientes.
Respecto a la alta disponibilidad, su reto era que si se caia un agente, tener otro listo para continuar sirviendo peticiones. Básicamente una estrategia activo/pasivo. Sólo uno está ejecutando el mercado en un momento dado, pero si algo falla, el segundo tomará el relevo. Evaluaron numerosas posibilidades (relatadas en la charla), pero al final se quedaron con el log tailing, que básicamente viene siendo que el agente pasivo lee los logs del activo y va replicando todas sus acciones.
Ya al final de la charla dedican unos quince minutos a hablar de como evolucionaron de BetFair a TradeFair y los retos que eso suponía. Partían de su motor, FlyWheel, capaz de ejecutar decenas de miles de transacciones por segundo, pero que sin embargo tenía unos niveles de latencia altos y no consistentes, algo no aceptable para los mercados financieros. Ese fue básicamente su principal reto. Entre las soluciones pues básicamente el intentar evitar la escritura a disco, controlar la recolección de basura y la instanciación de objetos, y también regular sus tasas de transferencia (throttling throughput).
