{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"C\u00f3mo dejar de preocuparse y comenzar a vivir sin monolitos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"C\u00f3mo
\n
\nA todos nos gustan las historias. Nos gusta, sentados junto al fuego, contar sobre nuestras viejas victorias, batallas o simplemente sobre nuestra experiencia laboral.<\/p>\n

Hoy es un d\u00eda as\u00ed. Y aunque no est\u00e9s junto al fuego, tenemos una historia para ti. Una historia sobre c\u00f3mo comenzamos a trabajar con el almacenamiento en Tarantool.<\/p>\n

Hace mucho tiempo, en nuestra empresa hab\u00eda un par de \u00abmonolitos\u00bb y un \u00fanico \u00abtecho\u00bb que estos monolitos se acercaban lentamente, limitando el vuelo de nuestra empresa, nuestro desarrollo. Y hab\u00eda una comprensi\u00f3n clara: un d\u00eda nos golpear\u00edamos con fuerza contra ese techo.
\n<\/a><\/noindex>
\nAhora mismo, nuestra ideolog\u00eda se basa en la separaci\u00f3n de todo y de todos, desde el hardware hasta la l\u00f3gica empresarial. Como resultado, por ejemplo, tenemos dos centros de datos pr\u00e1cticamente independientes a nivel de red. Pero en aquel entonces, todo era muy diferente.<\/p>\n

Hoy en d\u00eda, hay un mont\u00f3n de herramientas y medios para realizar cambios, como CI\/CD, K8S, etc. En la \u00e9poca \u00abmonol\u00edtica\u00bb, no necesit\u00e1bamos tantas palabras extranjeras. Era suficiente con simplemente corregir la \u00abalmacenista\u00bb en la base de datos.<\/p>\n

Pero el tiempo avanz\u00f3, y la cantidad de solicitudes creci\u00f3 junto con \u00e9l, disparando los RPS a veces m\u00e1s all\u00e1 de nuestras capacidades. Al ingresar al mercado de los pa\u00edses de la CEI, la carga en el procesador de la base de datos del primer monolito no bajaba del 90 %, y los RPS se manten\u00edan en 2400. Y no eran solo peque\u00f1as selecciones, eran grandes solicitudes con un mont\u00f3n de verificaciones y JOINs que pod\u00edan recorrer casi la mitad de los datos en un gran IO.<\/p>\n

Cuando las verdaderas ventas comenzaron a aparecer en \u00abBlack Friday\u00bb, y Wildberries comenz\u00f3 a realizarlas como uno de los primeros en Rusia, la situaci\u00f3n se volvi\u00f3 bastante triste. La carga en esos d\u00edas aumenta tres veces.
\n\u00a1Ah, esos \u00abtiempos monol\u00edticos\u00bb! Estoy seguro de que t\u00fa tambi\u00e9n te has enfrentado a algo as\u00ed, y a\u00fan no puedes entender c\u00f3mo pudo suceder eso contigo.<\/p>\n

No se puede evitar, la moda tambi\u00e9n afecta a las tecnolog\u00edas. Hace unos 5 a\u00f1os, tuvimos que replantear una de esas modas, como el sitio web existente en .NET y MS SQL Server, que guardaba celosamente toda la l\u00f3gica de funcionamiento del propio sitio. Lo guardaba de tal manera que cortar un monolito as\u00ed result\u00f3 ser un placer largo y nada f\u00e1cil.
\nUna peque\u00f1a digresi\u00f3n. <\/p>\n

En diferentes eventos, digo: \u00ab\u00a1si no has descompuesto el monolito, entonces no has crecido!\u00bb Estoy interesado en tu opini\u00f3n al respecto, por favor, comp\u00e1rtela en los comentarios.<\/p>\n

Y estall\u00f3 el trueno<\/h3>\n

\nVolvamos a nuestro \u00abhoguera\u00bb. Para distribuir la carga de la funcionalidad \u00abmonol\u00edtica\u00bb, decidimos dividir el sistema en microservicios basados en tecnolog\u00edas de c\u00f3digo abierto. Porque, como m\u00ednimo, su escalabilidad es m\u00e1s econ\u00f3mica. Y \u00e9ramos 100% conscientes de que habr\u00eda que escalar (y mucho). Ya en ese momento hab\u00edamos logrado acceder a los mercados de pa\u00edses vecinos, y tanto la cantidad de registros como la de pedidos empezaron a crecer a\u00fan m\u00e1s.<\/p>\n

Al analizar los primeros candidatos para salir del monolito hacia los microservicios, entendimos que el 80 % de las escrituras en ellos proven\u00eda en un 99 % de sistemas back office, mientras que las lecturas ven\u00edan de la l\u00ednea del frente. Esto se refer\u00eda en primer lugar a un par de subsistemas importantes para nosotros: datos de usuarios y el sistema de c\u00e1lculo del precio final de los productos basado en la informaci\u00f3n sobre descuentos adicionales para clientes y cupones.<\/p>\n

A modo de par\u00e9ntesis. Ahora es dif\u00edcil de imaginar, pero adem\u00e1s de los subsistemas mencionados, tambi\u00e9n se extrajeron del nuestro monolito cat\u00e1logos de productos, el carrito de usuario, el sistema de b\u00fasqueda de productos, el sistema de filtrado de cat\u00e1logos de productos y varios sistemas de recomendaciones. Para el funcionamiento de cada uno de ellos, existen clases separadas de sistemas especializados, pero en su momento todos viv\u00edan en una sola \u201ccasita\u201d. <\/p>\n

Decidimos extraer los datos sobre nuestros clientes a un sistema de shard. Sin embargo, extraer la funcionalidad para calcular el precio final de los productos requer\u00eda una buena escalabilidad en cuanto a lectura, ya que esta generaba la mayor carga en RPS y era la m\u00e1s dif\u00edcil de implementar para la base de datos (muchos datos estaban involucrados en el proceso de c\u00e1lculos). <\/p>\n

Como resultado, surgi\u00f3 un esquema que se ajusta bien a Tarantool.<\/p>\n

En ese momento, para el funcionamiento de los microservicios se eligieron esquemas de trabajo con varios centros de datos en m\u00e1quinas virtuales y f\u00edsicas. Como se muestra en las ilustraciones, se aplicaron variantes de replicaciones de Tarantool tanto en modo master-master como master-slave. <\/p>\n

\"C\u00f3mo
\nArquitectura. Opci\u00f3n 1. Servicio de usuarios<\/i><\/p>\n

En la actualidad, hay 24 shards, en cada uno de los cuales hay 2 instancias (una en cada DC), todas en modo master-master.<\/p>\n

Sobre la base de datos se encuentran aplicaciones que acceden a las r\u00e9plicas de la base de datos. Las aplicaciones funcionan con Tarantool a trav\u00e9s de nuestra biblioteca personalizada, que implementa la interfaz del controlador Go de Tarantool. Ella ve todas las r\u00e9plicas y puede trabajar con el maestro en lectura y escritura. En esencia, implementa un modelo de conjunto de r\u00e9plicas, al que se le ha a\u00f1adido la l\u00f3gica de selecci\u00f3n de r\u00e9plicas, ejecuci\u00f3n de reintentos, cortacircuitos y l\u00edmite de tasa.<\/p>\n

Adem\u00e1s, existe la posibilidad de configurar la pol\u00edtica de selecci\u00f3n de r\u00e9plicas en el contexto de la partici\u00f3n. Por ejemplo, utilizando round-robin.<\/p>\n

\"C\u00f3mo
\nArquitectura. Opci\u00f3n 2. Servicio de c\u00e1lculo del costo final del producto.<\/i><\/p>\n

Hace varios meses, la mayor parte de las solicitudes para calcular el costo final de los productos se trasladaron a un nuevo servicio, que en principio funciona sin bases de datos, pero hace un tiempo el 100% era procesado por un servicio con Tarantool detr\u00e1s.<\/p>\n

La base de datos del servicio consta de 4 maestros, en los que el sincronizador recopila datos, y cada uno de estos maestros distribuye datos a las r\u00e9plicas de solo lectura a trav\u00e9s de replicaci\u00f3n. Cada maestro tiene aproximadamente 15 de tales r\u00e9plicas.<\/p>\n

Tanto en el primer como en el segundo esquema, en caso de que un centro de datos no est\u00e9 disponible, la aplicaci\u00f3n puede obtener datos desde el segundo.<\/p>\n

Cabe destacar que en Tarantool la replicaci\u00f3n es bastante flexible y se configura en tiempo de ejecuci\u00f3n. En otros sistemas, a veces surg\u00edan dificultades. Por ejemplo, en PostgreSQL, cambiar los par\u00e1metros max_wal_senders y max_replication_slots requiere reiniciar el maestro, lo que en algunos casos puede llevar a la desconexi\u00f3n entre la aplicaci\u00f3n y la base de datos.<\/p>\n

\u00a1Buscar y encontrar\u00e1s!<\/h3>\n

\n\u00bfPor qu\u00e9 no hicimos \"como la gente normal\", sino que elegimos un enfoque at\u00edpico? Depender\u00e1 de lo que se considere normal. Muchos crean cl\u00fasteres de Mongo y los distribuyen entre tres centros de datos geogr\u00e1ficamente dispersos.<\/p>\n

En ese momento ya ten\u00edamos dos proyectos en Redis. El primero era un cach\u00e9, y el segundo representaba un almacenamiento persistente para datos no demasiado cr\u00edticos. Con este \u00faltimo fue bastante complicado, en parte debido a nuestra culpa. A veces, vol\u00famenes bastante grandes estaban en la clave, y de vez en cuando el sitio experimentaba problemas. Usamos este sistema en un modo maestro-esclavo. Y hubo muchos casos en los que algo suced\u00eda con el maestro y la replicaci\u00f3n fallaba. <\/p>\n

Es decir, Redis es bueno para tareas sin estado, no para las que requieren estado. En principio, resolv\u00eda la mayor\u00eda de los problemas, pero solo si se trataba de soluciones clave-valor con un par de \u00edndices. Sin embargo, en ese momento Redis ten\u00eda serias limitaciones en cuanto a persistencia y replicaci\u00f3n. Adem\u00e1s, hubo quejas sobre su rendimiento.<\/p>\n

Consideramos MySQL y PostgreSQL. Pero el primero no encaj\u00f3 bien con nosotros, mientras que el segundo es un producto bastante sofisticado, y construir servicios simples sobre \u00e9l ser\u00eda poco pr\u00e1ctico.
\nProbamos RIAK, Cassandra, e incluso bases de datos gr\u00e1ficas. Todo esto son soluciones bastante nicho, que no eran adecuadas como una herramienta universal para crear servicios.<\/p>\n

En \u00faltima instancia, nos decidimos por Tarantool.<\/p>\n

Nos acercamos a \u00e9l cuando estaba en la versi\u00f3n 1.6. Nos interes\u00f3 la combinaci\u00f3n de funcionalidades key-value y de base de datos relacional. Tiene \u00edndices secundarios, transacciones y espacios, que son como tablas, pero no simples, se puede almacenar en ellas una cantidad variable de columnas. Pero la caracter\u00edstica m\u00e1s destacada de Tarantool fueron los \u00edndices secundarios combinados con la funcionalidad de clave-valor y transacciones.<\/p>\n

Tambi\u00e9n jug\u00f3 un papel importante la comunidad de habla rusa, que estaba dispuesta a ayudar en el chat. Aprovechamos esto activamente y realmente viv\u00edamos en el chat. No se debe olvidar la buena persistencia sin fallos evidentes. Si miramos nuestra historia con Tarantool, tuvimos muchos dolores y contratiempos con la replicaci\u00f3n, \u00a1pero nunca perdimos datos por su culpa!<\/p>\n

La implementaci\u00f3n comenz\u00f3 con dificultades.<\/h3>\n

\nEn ese momento, nuestro stack de desarrollo principal era .NET, para el cual no hab\u00eda un conector para Tarantool. As\u00ed que comenzamos a hacer algo en Go. Tambi\u00e9n funcion\u00f3 bastante bien con Lua. El mayor problema en ese momento era la depuraci\u00f3n: en .NET todo estaba bien, pero luego nos sumergimos en el mundo de Lua embebido, donde no ten\u00edas m\u00e1s que registros y ninguna posibilidad de depurar, lo que result\u00f3 complicado. Adem\u00e1s, la replicaci\u00f3n se romp\u00eda de vez en cuando, tuvimos que profundizar en la arquitectura del motor Tarantool. El chat ayud\u00f3 en esto, y en menor medida la documentaci\u00f3n, a veces consult\u00e1bamos el c\u00f3digo. En ese momento, la documentaci\u00f3n dejaba mucho que desear.<\/p>\n

As\u00ed, durante varios meses, logr\u00e9 adquirir experiencia y obtener resultados satisfactorios trabajando con Tarantool. Documentamos en git los desarrollos de referencia que ayudaron en la creaci\u00f3n de nuevos microservicios. Por ejemplo, cuando surg\u00eda la tarea de crear un nuevo microservicio, el desarrollador consultaba el c\u00f3digo fuente de la soluci\u00f3n de referencia en el repositorio, y la creaci\u00f3n de uno nuevo no tomaba m\u00e1s de una semana. <\/p>\n

Eran tiempos especiales. En aquella \u00e9poca, pod\u00edas acercarte al administrador en la mesa de al lado y pedir: \"Dame una m\u00e1quina virtual\". En unos treinta minutos, ya la ten\u00edas. Te conectabas, instalabas todo y te comenzaban a dirigir tr\u00e1fico hacia ella.<\/p>\n

Hoy en d\u00eda eso ya no es posible: hay que configurar el monitoreo del servicio, la registraci\u00f3n, cubrir la funcionalidad con pruebas, solicitar una m\u00e1quina virtual o hacer la implementaci\u00f3n en Kubernetes, etc. En general, as\u00ed ser\u00e1 mejor, aunque m\u00e1s largo y complicado.<\/p>\n

Divide y conquistar\u00e1s. \u00bfC\u00f3mo est\u00e1n las cosas con Lua?<\/h3>\n

\nHubo una seria dilema: algunos equipos no lograban desplegar cambios de manera confiable en un servicio con mucha l\u00f3gica escrita en Lua. Muchas veces esto resultaba en la inoperatividad del servicio. <\/p>\n

Es decir, los desarrolladores preparan alg\u00fan cambio. Tarantool comienza a hacer la migraci\u00f3n, pero la r\u00e9plica todav\u00eda tiene el c\u00f3digo antiguo; llega alg\u00fan DDL por replicaci\u00f3n, algo m\u00e1s, y el c\u00f3digo simplemente se desmorona porque no se ten\u00eda en cuenta. Como resultado, el procedimiento de actualizaci\u00f3n para los administradores estaba escrito en una hoja A4: detener la replicaci\u00f3n, actualizar esto, reiniciar la replicaci\u00f3n, apagar aqu\u00ed, actualizar all\u00e1. \u00a1Un desastre! <\/p>\n

Al final, ahora intentamos no hacer nada en Lua la mayor\u00eda de las veces. Simplemente a trav\u00e9s de iproto (protocolo binario para interactuar con el servidor), y eso es todo. Tal vez sea una falta de conocimiento por parte de los desarrolladores, pero por este punto de vista el sistema es complicado.<\/p>\n

No siempre seguimos este guion ciegamente. Hoy en d\u00eda no tenemos un blanco y negro: o todo en Lua o todo en Go. Ya entendemos c\u00f3mo se puede combinar para no tener problemas con la migraci\u00f3n en el futuro.<\/p>\n

\u00bfD\u00f3nde se encuentra ahora Tarantool?
\nTarantool se utiliza en el servicio de c\u00e1lculo del precio final de los productos, teniendo en cuenta los cupones de descuento, conocido como \u00abPromodaizer\u00bb. Como mencion\u00e9 anteriormente, actualmente se est\u00e1 desvinculando: lo reemplaza un nuevo servicio de cat\u00e1logo con precios precalculados, pero hace seis meses, todos los c\u00e1lculos se realizaban en \u00abPromodaizer\u00bb. Anteriormente, la mitad de su l\u00f3gica estaba escrita en Lua. Hace dos a\u00f1os, se convirti\u00f3 en un almacenamiento, y la l\u00f3gica fue reescrita en Go, porque la mec\u00e1nica de funcionamiento de los descuentos cambi\u00f3 un poco y al servicio le faltaba rendimiento. <\/p>\n

Uno de los servicios m\u00e1s cr\u00edticos es el perfil de usuario. Es decir, todos los usuarios de Wildberries se almacenan en Tarantool, y son alrededor de 50 millones. Un sistema shardeado por ID de usuario, distribuido en varios centros de datos con un enlace en servicios de Go.
\nEn cuanto a RPS, anteriormente \u00abPromodaizer\u00bb era el l\u00edder, alcanzando hasta 6,000 solicitudes. En alg\u00fan momento ten\u00edamos de 50 a 60 instancias. Ahora, el l\u00edder en RPS son los perfiles de usuarios, aproximadamente bajo 12,000. Este servicio utiliza un sharding personalizado con divisiones por rangos de ID de usuario. El servicio da soporte a m\u00e1s de 20 m\u00e1quinas, pero eso es demasiado, planeamos reducir los recursos dedicados porque suficientes capacidades son proporcionadas por 4-5 m\u00e1quinas.<\/p>\n

El servicio de sesiones es nuestro primer servicio en vshard y Cartridge. La configuraci\u00f3n de vshard y la actualizaci\u00f3n de Cartridge requirieron un esfuerzo considerable, pero al final todo sali\u00f3 bien.<\/p>\n

El servicio para mostrar diferentes banners en el sitio web y en la aplicaci\u00f3n m\u00f3vil fue uno de los primeros en lanzarse en Tarantool. Este servicio es notable por su antig\u00fcedad, tiene alrededor de 6-7 a\u00f1os, sigue funcionando y nunca se ha reiniciado. Se utiliz\u00f3 replicaci\u00f3n master-master. Nunca se ha roto nada.<\/p>\n

Hay un ejemplo de uso de Tarantool para la funcionalidad de directorios r\u00e1pidos en el sistema de almacenes, para verificar r\u00e1pidamente la informaci\u00f3n en ciertos casos. Intentamos usar Redis para esto, pero los datos en memoria ocupaban m\u00e1s espacio que en Tarantool.<\/p>\n

Los servicios de lista de espera, suscripciones de clientes, las populares historias y los productos pendientes tambi\u00e9n funcionan con Tarantool. El \u00faltimo servicio ocupa aproximadamente 120 GB en memoria. Es el servicio m\u00e1s voluminoso de los mencionados. <\/p>\n

Conclusi\u00f3n<\/h3>\n

\nGracias a los \u00edndices secundarios en combinaci\u00f3n con key-value y la transaccionabilidad, Tarantool es ideal para arquitecturas basadas en microservicios. Sin embargo, nos encontramos con dificultades al implementar cambios en los servicios que conten\u00edan una l\u00f3gica extensa en Lua; los servicios a menudo dejaban de funcionar. No logramos superar esto, y con el tiempo llegamos a diferentes combinaciones de Lua y Go: sabemos cu\u00e1ndo es conveniente usar un lenguaje y cu\u00e1ndo el otro.<\/p>\n

Lecturas adicionales sobre el tema<\/b><\/p>\n