Elasticsearch s'enfronta a moltes persones. Però què passa quan el voleu utilitzar per emmagatzemar registres "en un volum especialment gran"? Sí, i sobreviure sense dolor a la fallada de qualsevol dels diversos centres de dades? Quin tipus d'arquitectura s'ha de fer i amb quines trampes us trobareu?
A Odnoklassniki vam decidir resoldre el problema de la gestió de registres amb l'ajuda d'elasticsearch, i ara compartim la nostra experiència amb Habr: tant sobre arquitectura com sobre esculls.
Sóc Pyotr Zaitsev, treballo com a administrador del sistema a Odnoklassniki. Abans d'això, també va ser administrador, va treballar amb Manticore Search, Sphinx search, Elasticsearch. Potser si apareix una altra cerca..., probablement també treballaré amb ella. També participo en diversos projectes de codi obert de manera voluntària.
Quan vaig arribar a Odnoklassniki, vaig dir temeràriament a l'entrevista que podia treballar amb Elasticsearch. Després d'acostumar-me i fer algunes tasques senzilles, em van presentar una gran tasca per reformar el sistema de gestió de registres que existia en aquell moment.
Requisits
Els requisits per al sistema es van formular de la següent manera:
- Se suposava que Graylog s'havia d'utilitzar com a interfície. Com que l'empresa ja tenia experiència utilitzant aquest producte, els programadors i provadors ho sabien, els resultava familiar i convenient.
- Volum de dades: de mitjana 50-80 mil missatges per segon, però si alguna cosa es trenca, el trànsit no està limitat per res, pot ser de 2-3 milions de línies per segon
- Després d'haver discutit amb els clients els requisits per a la velocitat de processament de les consultes de cerca, ens vam adonar que un patró típic per utilitzar aquest sistema és el següent: la gent busca els registres de les seves aplicacions durant els dos darrers dies i no volen esperar més d'un segon per un resultat per a una consulta formulada.
- Els administradors van insistir que el sistema s'escalava fàcilment si cal, sense requerir que entenguessin profundament com funciona.
- De manera que l'única tasca de manteniment que necessitaven aquests sistemes periòdicament era canviar algun tipus de maquinari.
- A més, Odnoklassniki té una gran tradició tècnica: qualsevol servei que engeguem ha de sobreviure a una fallada del centre de dades (sobtada, no planificada i absolutament en qualsevol moment).
L'últim requisit en la implementació d'aquest projecte ens va ser donat amb el major vessament de sang, del qual parlaré amb més detall.
dimecres
Treballem en quatre centres de dades, mentre que els nodes de dades d'Elasticsearch només es poden localitzar en tres (per diverses raons no tècniques).
En aquests quatre centres de dades hi ha aproximadament 18 mil fonts diferents de registres: peces de ferro, contenidors, màquines virtuals.
Una característica important: el clúster es llança en contenidors no en màquines físiques, sinó encès . Els contenidors tenen garantits 2 nuclis similars a 2.0 Ghz v4 amb la possibilitat de reciclar la resta de nuclis si estan inactius.
En altres paraules:
Topologia
La visió general de la solució la vaig veure inicialment de la següent manera:
- 3-4 VIP es troben darrere del registre A del domini Graylog, aquesta és l'adreça a la qual s'envien els registres.
- cada VIP és un equilibrador LVS.
- Després d'això, els registres van a la bateria de Graylog, algunes de les dades van en format GELF, altres en format syslog.
- Després, tot això s'escriu en grans lots a la bateria des dels coordinadors d'Elasticsearch.
- I ells, al seu torn, envien peticions d'escriptura i lectura als nodes de dades pertinents.
Terminologia
Potser no tothom entén la terminologia en detall, així que m'agradaria detenir-hi una mica.
Hi ha diversos tipus de nodes a Elasticsearch: mestre, coordinador, node de dades. Hi ha altres dos tipus per a diferents transformacions de registres i la connexió de diferents clústers entre si, però només hem utilitzat els que s'enumeren.
Mestre
Fa ping a tots els nodes presents al clúster, manté un mapa de clúster actualitzat i el distribueix entre nodes, processa la lògica d'esdeveniments i fa diversos tipus de neteja a tot el clúster.
Coordinador
Realitza una única tasca: rep les peticions dels clients per llegir o escriure i encamina aquest trànsit. En cas que hi hagi una sol·licitud d'escriptura, el més probable és que pregunti al mestre quin fragment de l'índex rellevant la col·loqui i redirigeixi la sol·licitud més enllà.
node de dades
Emmagatzema dades, realitza consultes de cerca i operacions sobre els fragments que s'hi troben, arribant de fora.
graylog
És com si fossin Kibana amb Logstash a la pila ELK. Graylog combina tant la interfície d'usuari com la canalització de processament de registres. Sota el capó, Graylog executa Kafka i Zookeeper, que proporcionen connectivitat a Graylog com a clúster. Graylog pot emmagatzemar els registres a la memòria cau (Kafka) en cas que Elasticsearch no estigui disponible i repeteixi les sol·licituds de lectura i escriptura sense èxit, agrupa i marca els registres d'acord amb les regles especificades. Igual que Logstash, Graylog té la funcionalitat de modificar cadenes abans d'escriure a Elasticsearch.
A més, Graylog té un servei de descoberta integrat que permet, en funció d'un node Elasticsearch disponible, obtenir tot el mapa de clúster i filtrar-lo per una etiqueta específica, que permet enviar sol·licituds a contenidors específics.
Visualment es veu així:
Aquesta és una captura de pantalla d'una instància específica. Aquí construïm un histograma basat en la consulta de cerca i mostrem línies rellevants.
Índexs
Tornant a l'arquitectura del sistema, m'agradaria detenir-me amb més detall sobre com hem construït el model d'índex perquè tot funcioni correctament.
Al diagrama anterior, aquest és el nivell més baix: nodes de dades d'Elasticsearch.
Un índex és una gran entitat virtual formada per fragments d'Elasticsearch. Per si mateix, cadascun dels fragments no és més que un índex Lucene. I cada índex Lucene, al seu torn, consta d'un o més segments.
A l'hora de dissenyar, vam pensar que per complir els requisits de velocitat de lectura en una gran quantitat de dades, hem d'"untar" aquestes dades de manera uniforme entre els nodes de dades.
Això va donar lloc al fet que el nombre de fragments per índex (amb rèpliques) hauria de ser estrictament igual al nombre de nodes de dades. En primer lloc, per tal d'assegurar un factor de replicació de dos (és a dir, podem perdre la meitat del clúster). I, en segon lloc, per processar les sol·licituds de lectura i escriptura en almenys la meitat del clúster.
Al principi vam determinar el temps d'emmagatzematge en 30 dies.
La distribució dels fragments es pot representar gràficament de la següent manera:
Tot el rectangle gris fosc és l'índex. El quadrat vermell esquerre que hi ha és el fragment primari, el primer de l'índex. I el quadrat blau és un fragment de rèplica. Es troben en diferents centres de dades.
Quan afegim un altre fragment, va al tercer centre de dades. I, al final, obtenim una estructura que ofereix la possibilitat de perdre un DC sense perdre la consistència de les dades:
Rotació de l'índex, és a dir. creant un índex nou i eliminant el més antic, el vam fer igual a 48 hores (segons el patró d'ús de l'índex: les últimes 48 hores es cerquen amb més freqüència).
Aquest interval de rotació de l'índex es deu als motius següents:
Quan una sol·licitud de cerca arriba a un node de dades específic, aleshores, des del punt de vista del rendiment, és més rendible quan es consulta un fragment si la seva mida és comparable a la mida del maluc del node. Això us permet mantenir la part "calenta" de l'índex al munt i accedir-hi ràpidament. Quan hi ha moltes "parts calentes", la velocitat de cerca de l'índex es degrada.
Quan un node comença a executar una consulta de cerca en un fragment, assigna un nombre de fils igual al nombre de nuclis hiperprocés de la màquina física. Si la consulta de cerca afecta un gran nombre de fragments, el nombre de fils creix proporcionalment. Això té un efecte negatiu en la velocitat de cerca i afecta negativament la indexació de dades noves.
Per proporcionar la latència de cerca necessària, vam decidir utilitzar un SSD. Per processar les sol·licituds ràpidament, les màquines que allotjaven aquests contenidors havien de tenir almenys 56 nuclis. El número 56 es tria com a valor condicionalment suficient que determina el nombre de fils que generarà Elasticsearch durant el funcionament. A Elasitcsearch, molts paràmetres de l'agrupació de fils depenen directament del nombre de nuclis disponibles, que al seu torn afecta directament el nombre necessari de nodes del clúster segons el principi "menys nuclis - més nodes".
Com a resultat, hem aconseguit que, de mitjana, un fragment pesa uns 20 gigabytes i hi ha 1 fragments per 360 índex. En conseqüència, si els girem cada 48 hores, en tenim 15. Cada índex conté dades durant 2 dies.
Esquemes per escriure i llegir dades
Vegem com es registren les dades en aquest sistema.
Suposem que arriba alguna sol·licitud de Graylog al coordinador. Per exemple, volem indexar entre 2 i 3 mil files.
El coordinador, després d'haver rebut una sol·licitud de Graylog, pregunta al mestre: "A la sol·licitud d'indexació, vam especificar específicament l'índex, però no es va especificar en quin fragment escriure això".
El mestre respon: "Escriu aquesta informació al fragment número 71", després s'envia directament al node de dades rellevant, on es troba el fragment primari número 71.
Després d'això, el registre de transaccions es replica a replica-shard, que ja es troba en un altre centre de dades.
Arriba una sol·licitud de cerca de Graylog al coordinador. El coordinador el redirigeix per índex, mentre que Elasticsearch distribueix les sol·licituds entre primary-shard i replica-shard d'acord amb el principi round-robin.
Els nodes de la quantitat de 180 responen de manera desigual i, mentre responen, el coordinador acumula informació que els nodes de dades més ràpids ja hi han "escupit". Després d'això, quan ha arribat tota la informació o s'ha arribat a un temps d'espera a la sol·licitud, ho dóna tot directament al client.
Tot aquest sistema, de mitjana, compleix les sol·licituds de cerca de les últimes 48 hores en 300-400 ms, excloent les sol·licituds amb el comodí principal.
Flowers amb Elasticsearch: Configuració de Java
Perquè tot funcionés de la manera que volíem originalment, vam passar molt de temps depurant una gran varietat de coses del clúster.
La primera part dels problemes descoberts estava relacionada amb com Java està preconfigurat a Elasticsearch per defecte.
El primer problema
Hem vist un nombre molt gran d'informes que tenim a nivell de Lucene, quan s'executen treballs en segon pla, les fusions de segments de Lucene fallen. Al mateix temps, als registres quedava clar que es tractava d'un error OutOfMemoryError. Des de la telemetria, vam veure que el maluc estava lliure, i no estava clar per què aquesta operació estava caient.
Va resultar que les fusions d'índex de Lucene es produeixen fora del maluc. I els contenidors estan molt limitats pel que fa als recursos consumits. Només el munt encaixava en aquests recursos (el valor de heap.size era aproximadament igual a la memòria RAM) i algunes operacions fora del munt van caure amb un error d'assignació de memòria si per algun motiu no encaixaven en aquells ~ 500 MB que quedaven abans del límit. .
La solució va ser bastant trivial: es va augmentar la quantitat de memòria RAM disponible per al contenidor, després de la qual cosa es van oblidar que teníem aquests problemes.
Problema dos
4-5 dies després del llançament del clúster, ens vam adonar que els nodes de dades comencen a caure periòdicament del clúster i entrar-hi després de 10-20 segons.
Quan van pujar per esbrinar-ho, va resultar que aquesta memòria molt fora del munt a Elasticsearch pràcticament no està controlada de cap manera. Quan vam donar més memòria al contenidor, vam tenir l'oportunitat d'omplir grups de memòria intermèdia directa amb informació diversa, i només es va esborrar després que Elasticsearch iniciés el GC explícit.
En alguns casos, aquesta operació va trigar força i durant aquest temps el clúster va aconseguir marcar aquest node com a ja llançat. Aquest tema està ben descrit. .
La solució va ser la següent: vam limitar la capacitat de Java d'utilitzar la major part de la memòria fora del munt per a aquestes operacions. El vam limitar a 16 gigabytes (-XX:MaxDirectMemorySize=16g), assegurant-nos que el GC explícit es cridava molt més sovint i funcionava molt més ràpid, deixant així de desestabilitzar el clúster.
Problema tres
Si creieu que els problemes amb els "nodes que surten del clúster en el moment més inesperat" s'han acabat, us equivoqueu.
Quan vam configurar el treball amb índexs, vam optar per mmapfs per tal de fer-ho en fragments frescos amb alta segmentació. Aquest va ser un error bastant greu, perquè quan s'utilitza mmapfs, el fitxer s'assigna a la memòria RAM i després treballem amb el fitxer assignat. Per això, resulta que quan el GC intenta aturar els fils de l'aplicació, anem al safepoint durant molt de temps i, de camí cap a ell, l'aplicació deixa de respondre a les peticions de l'assistent sobre si està activa. . En conseqüència, el mestre creu que el node ja no està present al nostre clúster. Després d'això, després de 5-10 segons, el col·lector d'escombraries funciona, el node cobra vida, torna a entrar al clúster i comença a inicialitzar els fragments. Tot això s'assemblava molt a “la producció que mereixíem” i no era apte per a res seriós.
Per desfer-se d'aquest comportament, primer vam canviar als niofs estàndard i després, quan vam migrar de les cinquenes versions d'Elastic a les sisenas, vam provar els hybridfs, on aquest problema no es va reproduir. Podeu llegir més informació sobre els tipus d'emmagatzematge .
Problema quatre
Després hi va haver un altre problema molt entretingut que vam tractar durant molt de temps. La vam agafar durant 2-3 mesos, perquè el seu patró era absolutament incomprensible.
De vegades, els nostres coordinadors anaven al Full GC, normalment en algun lloc de la tarda, i mai tornaven d'allà. Al mateix temps, en registrar el retard del GC, semblava així: tot ens va bé, bé, bé, i després una vegada, i tot està molt malament.
Al principi, pensàvem que tenim un usuari malvat que llança algun tipus de sol·licitud que deixa fora del mode de treball el coordinador. Vam registrar sol·licituds durant molt de temps, intentant esbrinar què estava passant.
Com a resultat, va resultar que en el moment en què un usuari llança una gran sol·licitud i arriba a un coordinador d'Elasticsearch específic, alguns nodes responen més temps que altres.
I mentre el coordinador està esperant la resposta de tots els nodes, acumula en ell mateix els resultats enviats des dels nodes que ja han respost. Per al GC, això significa que el nostre patró d'ús del maluc està canviant molt ràpidament. I el GC que vam fer servir no va poder fer front a aquesta tasca.
L'única solució que hem trobat per canviar el comportament del clúster en aquesta situació és migrar a JDK13 i utilitzar el col·lector d'escombraries de Shenandoah. Això va solucionar el problema, els nostres coordinadors van deixar de caure.
Aquí és on van acabar els problemes amb Java i van començar els problemes amb l'ample de banda.
"Baies" amb Elasticsearch: rendiment
Els problemes de rendiment fan que el nostre clúster sigui estable, però en el punt àlgid del nombre de documents indexats i en el moment de les maniobres, el rendiment és insuficient.
El primer símptoma que em vaig trobar: durant algun tipus d'"explosions" en producció, quan es generen de forma brusca un nombre molt gran de registres, sovint parpelleja un error d'indexació es_rejected_execution a Graylog.
Això es va deure al fet que thread_pool.write.queue en un node de dades fins que Elasticsearch sigui capaç de processar la sol·licitud d'índex i llençar la informació al fragment del disc, per defecte només pot emmagatzemar a la memòria cau 200 peticions. I en es parla molt poc d'aquest paràmetre. Només s'indica el nombre límit de fils i la mida predeterminada.
Per descomptat, vam anar a torçar aquest valor i vam descobrir el següent: específicament a la nostra configuració, fins a 300 sol·licituds s'emmagatzemen a la memòria cau força bé, i un valor més gran està ple del fet que tornem a volar a Full GC.
A més, com que es tracta de lots de missatges que arriben dins d'una única sol·licitud, també va ser necessari ajustar Graylog perquè escrigués no sovint i en lots petits, sinó en lots enormes o un cop cada 3 segons si el lot encara no està ple. . En aquest cas, resulta que la informació que escrivim a Elasticsearch està disponible no al cap de dos segons, sinó al cap de cinc (cosa que ens convé força), sinó el nombre de retraçaments que s'han de fer per impulsar un gran paquet d'informació. disminueix.
Això és especialment important en aquells moments en què alguna cosa s'ha estavellat en algun lloc i s'informa furiós sobre això, per no que s'efectuï completament el correu brossa Elàstic i, després d'un temps, els nodes de Graylog que no funcionen a causa dels buffers obstruïts.
A més, quan teníem aquestes explosions en producció, vam rebre queixes de programadors i provadors: en el moment en què realment necessiten aquests registres, se'ls envien molt lentament.
Van començar a entendre. D'una banda, estava clar que tant les consultes de cerca com les d'indexació es processen, de fet, a les mateixes màquines físiques, i d'una manera o altra, hi haurà certs inconvenients.
Però això es podria eludir parcialment a causa del fet que a les sisena versions d'Elasticsearch va aparèixer un algorisme que permet distribuir les sol·licituds entre nodes de dades rellevants no segons el principi de round-robin aleatori (el contenidor que indexa i conté el fragment primari). pot estar molt ocupat, no hi haurà manera de respondre ràpidament), sinó dirigir aquesta sol·licitud a un contenidor menys carregat amb fragment de rèplica, que respondrà molt més ràpidament. En altres paraules, vam acabar amb use_adaptive_replica_selection: true.
La imatge de lectura comença a semblar així:
La transició a aquest algorisme ens va permetre millorar notablement el temps de consulta en aquells moments en què teníem un gran flux de registres per escriure.
Finalment, el principal problema va ser l'eliminació indolora del centre de dades.
El que volíem del clúster immediatament després de la pèrdua de comunicació amb un DC:
- Si tenim el mestre actual al centre de dades caigut, serà reelegit i es traslladarà com a paper a un altre node d'un altre DC.
- El mestre expulsarà ràpidament tots els nodes inaccessibles del clúster.
- A partir de la resta, entendrà: al centre de dades perdut teníem tals o tals fragments primaris, promourà ràpidament fragments de rèpliques complementàries a la resta de centres de dades i continuarem indexant dades.
- Com a resultat d'això, l'ample de banda del clúster per escriure i llegir es degradarà sense problemes, però, en general, tot funcionarà, encara que sigui lent, però constant.
Com va resultar, volíem una cosa com això:
I va obtenir el següent:
Com ha passat?
En el moment de la caiguda del centre de dades, el mestre es va convertir en el coll d'ampolla per a nosaltres.
Per què?
El cas és que el mestre té un TaskBatcher encarregat de distribuir determinades tasques i esdeveniments al clúster. Qualsevol sortida de node, qualsevol promoció d'un fragment des de la rèplica fins a la principal, qualsevol tasca per crear algun tipus de fragment en algun lloc; tot això primer arriba a TaskBatcher, on es processa seqüencialment i en un sol fil.
En el moment de la retirada d'un centre de dades, va resultar que tots els nodes de dades dels centres de dades supervivents consideraven el seu deure informar al mestre "hem perdut tals o tals fragments i tals o tals nodes de dades".
Al mateix temps, els nodes de dades supervivents van enviar tota aquesta informació al mestre actual i van intentar esperar la confirmació que l'havia acceptat. No s'esperaven això, ja que el mestre rebia tasques més ràpid del que tenia temps per respondre. Els nodes van repetir les peticions per temps d'espera, i el mestre en aquell moment ni tan sols va intentar respondre-les, sinó que estava completament absorbit en la tasca d'ordenar les sol·licituds per prioritat.
A la forma del terminal, va resultar que els nodes de dades van enviar correu brossa al mestre fins al punt que va entrar al GC complet. Després d'això, el paper del mestre es va traslladar a algun node següent, li va passar absolutament el mateix i, com a resultat, el clúster es va trencar completament.
Vam fer mesures, i abans de la versió 6.4.0, on es va arreglar, ens va bastar amb retirar al mateix temps només 10 de 360 nodes de dades per posar completament el clúster.
Semblava una cosa així:
Després de la versió 6.4.0, on es va solucionar aquest error estrany, els nodes de dades van deixar de matar el mestre. Però no el va fer més intel·ligent. És a dir: quan sortim 2, 3 o 10 (qualsevol nombre que no sigui un) nodes de dades, el mestre rep un primer missatge que diu que el node A ha marxat i intenta dir-li al node B, al node C i al node D.
I de moment, això només es pot solucionar establint un temps d'espera per als intents d'explicar alguna cosa a algú, igual a uns 20-30 segons, i controlar així la velocitat de retirada del centre de dades del clúster.
En principi, això s'ajusta als requisits que es van establir originalment per al producte final en el marc del projecte, però des del punt de vista de la "ciència pura" això és un error. Que, per cert, va ser solucionat amb èxit pels desenvolupadors a la versió 7.2.
A més, quan va sortir un determinat node de dades, va resultar que difondre informació sobre la seva sortida era més important que dir-li a tot el clúster que tenia tal o tal fragment primari (per tal de promoure un fragment de rèplica en un altre centre de dades). a primària, i en podien escriure informació).
Per tant, quan tot ja s'ha apagat, els nodes de dades publicats no es marquen immediatament com a obsolets. En conseqüència, ens veiem obligats a esperar fins que s'acabin el temps d'espera de tots els pings abans que s'alliberin els nodes de dades, i només després d'això, el nostre clúster comença a parlar del fet que allà, allà i allà cal continuar gravant informació. Podeu llegir més sobre això .
Com a resultat, l'operació de retirada del centre de dades avui ens porta uns 5 minuts en hora punta. Per a un colós tan gran i maldestre, aquest és un resultat força bo.
Com a resultat, vam arribar a la següent solució:
- Tenim 360 nodes de dades amb discs de 700 gigabytes.
- 60 coordinadors per encaminar el trànsit en aquests mateixos nodes de dades.
- 40 mestres que hem deixat com una mena de llegat de l'època de les versions anteriors a la 6.4.0 - per sobreviure a la retirada del centre de dades, estàvem preparats mentalment per perdre diverses màquines per tal de garantir un quòrum de mestres fins i tot en el pitjor escenari
- Qualsevol intent de combinar rols en un contenidor amb nosaltres es basava en el fet que tard o d'hora el node es va trencar sota càrrega.
- Tot el clúster utilitza heap.size igual a 31 gigabytes: tots els intents de reduir la mida van portar al fet que les consultes de cerca pesades amb un comodí principal mataven alguns nodes o mataven un interruptor de circuit al mateix Elasticsearch.
- A més, per garantir el rendiment de la cerca, vam intentar mantenir el nombre d'objectes del clúster el més petit possible per tal de processar el mínim d'esdeveniments possible al coll d'ampolla que vam tenir a l'assistent.
Una darrera cosa sobre el seguiment
Perquè tot això funcioni com s'ha previst, fem un seguiment del següent:
- Cada node de dades informa al nostre núvol que existeix, i hi ha tals o tals fragments. Quan apaguem alguna cosa en algun lloc, el clúster informa al cap de 2-3 segons que al centre A hem extingit el node 2, 3 i 4; això vol dir que en altres centres de dades no podem extingir aquests nodes amb només un fragment.
- Coneixent el comportament del mestre, mirem molt atentament el nombre de tasques pendents. Perquè fins i tot una tasca pendent, si no s'esgota a temps, teòricament, en alguna situació d'emergència, pot esdevenir el motiu pel qual, per exemple, la promoció d'un fragment de rèplica a la primària no ens funcioni, cosa que s'aturarà. indexació.
- També mirem molt bé els retards de la recollida d'escombraries, perquè amb això ja hem tingut grans dificultats a l'hora d'optimitzar.
- Rebuigs de fil per entendre amb antelació on és el "coll d'ampolla".
- Bé, mètriques estàndard com heap, RAM i E/S.
A l'hora de supervisar la creació, assegureu-vos de tenir en compte les característiques del grup de fils a Elasticsearch. descriu la configuració i els valors predeterminats per a la cerca, la indexació, però és completament silenciós sobre thread_pool.management. Aquests fils processen, en particular, sol·licituds com _cat/shards i altres similars que són còmodes d'utilitzar en escriure monitoratge. Com més gran és el clúster, més sol·licituds d'aquest tipus s'executen per unitat de temps, i l'esmentat thread_pool.management no només no es presenta a la documentació oficial, sinó que també està limitat per defecte a 5 fils, que s'utilitza molt ràpidament, després del qual el seguiment deixa de funcionar correctament.
El que vull dir en conclusió: ho hem aconseguit! Hem aconseguit oferir als nostres programadors i desenvolupadors una eina que és capaç de proporcionar informació ràpida i fiable sobre el que està passant en producció en gairebé qualsevol situació.
Sí, va resultar bastant difícil, però, tanmateix, vam aconseguir encaixar la nostra llista de desitjos als productes existents, que, al mateix temps, no havien de ser pegats i reescrits per nosaltres mateixos.
Font: www.habr.com