En esta serie ya hemos hablado de las cachés, del particionado, y hoy vamos a hablar de las tablas hash.

Las tablas hash no son más que estructuras de almacenamiento clave-valor. La clave se suele establecer usando el hash de un objeto y por eso se llaman tablas hash. El hash de un objeto es un código de texto que identifica al objeto más o menos inequivocamente, y suele existir un método por defecto en la clase base de muchos lenguajes de programación orientados a objetos: por ejemplo con el método hashCode de Object en Java o con el GetHashCode de Object en C#; aunque habitualmente toca reescribirlo. Pero no quiero liaros, que en realidad para dónde vamos nos importa poco si usamos el hash del request, el nombre del usuario o cualquier otra cosa como clave.

Sí, es una introducción sencilla pero ¿cómo va a ser una tabla clave-valor un patrón cloud? Las tablas clave-valor se usan en multitud de sitios, y la Nube™ no iba a ser menos. Hay muchos sistemas de almacenamiento NoSQL que son en lo básico sistemas de clave-valor, pero también es algo que se puede usar en el reparto de cargas de trabajo, que es el problema principal que nos estamos encontrando con nuestro Infinitext.

En el caso más básico cuando se recibe una llamada, se puede tener una tabla hash en la máquina que indique a dónde hay que reenviarla, decirle a la máquina en cuestión que ejecute el trabajo y cuando acabe mandar la respuesta al cliente.

Pero recordemos el problema que teníamos y veamos como aplicar las tablas hash en nuestro caso concreto:

¡Efectivamente! No llegas a palmar pasta (menos mal) pero no estás haciendo nada de dinero. Resulta que los malditos usuarios no distribuyen sus nombres de un modo uniforme, así que algunos servidores están mucho más cargados que otros. Para mantener esta estructura tendrías que hacer que las particiones fuesen uniformes y no ves manera de como hacerlo con los simples scripts que te permite hacer el gateway de la Nube™ ¿ahora qué?

Bien, el problema es claro. Necesitas que el trabajo, las ordenes de los usuarios, se distribuyan de un modo no estático, no te vale eso de «los de la A en el servidor 1, los de la B en el servidor 2,…».

Por tanto, aplicando lo que hemos visto, añades un nuevo servidor con la lógica necesaria para que a medida que van llegando peticiones de nuevos usuarios les asigne el servidor que menos usuarios asignados tiene. De este modo el usuario Alejandro puede estar en el servidor 1 junto con Juan, y Alex en el servidor 3.

Una vez que lo has programado todo, haces que cada vez que el gateway reciba una llamada primero le pregunte a esa máquina a dónde manda la petición. Son peticiones muy cortas las que le hace el gateway a esta máquina que lo maneja todo en memoria, por lo que las llamadas apenas tardan un poquito más.

Además, aprovechas para mitigar un problema que ya habías detectado, pero que casi no pasaba. De vez en cuando un servidor se peta sin que aparentemente el tráfico que le mandas sea el problema. Intuyes que es algo del sistema operativo sobre el que corre todo, pero no te vas a preocupar ni meter en fregados. Cuando un servidor se traba deja de recibir llamadas durante un rato, hasta que acaba de procesar la última de las llamadas que tenía y entonces ya vuelve todo a funcionar.

Desde tu controlador que tiene la tabla hash haces pings periódicos a los servidores, cuando uno deja de recibir los ping le dices a la Nube™ que levante un clon. Cuando el servidor vuelve a recibir el ping le mandas a la Nube™ que lo apague.

Es perfecto, todo vuelve a rular y ahora está a prueba de cualquier fallo ¿de cualquiera? Repasando las analíticas ves que aunque no ha habido quejas, hay momentos en los que todo parece dejar de funcionar, es cuestión de un segundo pero te da rabia porque pensabas que lo tenías todo controlado. Repasas todo una y otra vez, nada por ningún sitio, no sabes que pasa, pero sin embargo en las métricas está claro: picos que llegan al cero como si fuesen caídas de tensión.

De repente, una madrugada te despiertas sobresaltado y lo visualizas: el bug de la Nube™ afecta también al servidor que tienes con la tabla hash. Todo se para porque todo pasa por él, y gracias a que el procesado de las peticiones que recibe es muy corto, es cosa de un instante… ¿y ahora qué? ¿cómo lo solucionas? Aquí no te vale meter más servidores, necesitas que sólo haya una tabla hash.

Post By Javi López (27 Posts)

Arquitecto/desarrollador, creativo, buscador de nuevas soluciones y modelos de negocio, crítico constructivo y ex muchas cosas

Website: → JaviLopezG

Connect

cloud, nube, Patrones, tablas hash