Artem Denisov ( , )
Badoo és el lloc de cites més gran del món. Actualment tenim uns 330 milions d'usuaris registrats a tot el món. Però el que és molt més important en el context de la nostra conversa d'avui és que emmagatzemem uns 3 petabytes de fotos d'usuari. Cada dia, els nostres usuaris pengen uns 3,5 milions de fotos noves i la càrrega de lectura és d'aproximadament 80 mil peticions per segon. Això és molt per al nostre backend, i de vegades hi ha dificultats amb això.
Parlaré del disseny d'aquest sistema, que emmagatzema i envia fotos en general, i ho miraré des del punt de vista d'un desenvolupador. Hi haurà una breu retrospectiva de com es va desenvolupar, on explicaré les principals fites, però només parlaré amb més detall de les solucions que estem utilitzant actualment.
Ara comencem.
Com he dit, serà una retrospectiva, i per començar-la en algun lloc, prenem l'exemple més habitual.
Tenim una tasca comuna, hem d'acceptar, emmagatzemar i enviar fotos dels usuaris. En aquesta forma, la tasca és general, podem utilitzar qualsevol cosa:
- emmagatzematge al núvol modern,
- una solució en caixa, de la qual també n'hi ha moltes ara;
- Podem configurar diverses màquines al nostre centre de dades i posar-hi discs durs grans i emmagatzemar-hi fotos.
Badoo històricament, tant ara com aleshores (en el moment en què estava en la seva infància) viu als seus propis servidors, dins dels nostres propis DC. Per tant, aquesta opció era òptima per a nosaltres.
Acabem de prendre diverses màquines, les vam anomenar "fotos" i vam obtenir un clúster que emmagatzema fotos. Però sembla que falta alguna cosa. Perquè tot això funcioni, hem de determinar d'alguna manera en quina màquina emmagatzemarem quines fotos. I aquí tampoc no cal obrir Amèrica.
Afegim un camp al nostre emmagatzematge amb informació sobre els usuaris. Aquesta serà la clau de fragmentació. En el nostre cas, l'hem anomenat place_id, i aquest identificador de lloc apunta al lloc on s'emmagatzemen les fotos de l'usuari. Fem mapes.
En la primera etapa, fins i tot es pot fer manualment: diem que una foto d'aquest usuari amb aquest lloc arribarà a aquest servidor. Gràcies a aquest mapa, sempre sabem quan un usuari puja una foto, on guardar-la i sabem des d'on donar-la.
Aquest és un esquema absolutament trivial, però té avantatges força importants. La primera és que és senzill, com he dit, i la segona és que amb aquest enfocament podem escalar fàcilment horitzontalment simplement lliurant cotxes nous i afegint-los al mapa. No cal que facis res més.
Així ens va ser durant un temps.
Això va ser cap al 2009. Van lliurar cotxes, van lliurar...
I en algun moment vam començar a notar que aquest esquema té certs inconvenients. Quins són els inconvenients?
En primer lloc, l'aforament és limitat. No podem col·locar tants discs durs en un servidor físic com voldríem. I això s'ha convertit en un cert problema amb el temps i amb el creixement del conjunt de dades.
I segon. Aquesta és una configuració atípica de les màquines, ja que aquestes màquines són difícils de reutilitzar en alguns altres clústers, és a dir, són força específiques; haurien de ser febles en rendiment, però al mateix temps amb un disc dur gran.
Això va ser tot per al 2009, però, en principi, aquests requisits encara són vigents avui dia. Tenim una retrospectiva, així que l'any 2009 tot va anar completament malament amb això.
I l'últim punt és el preu.
El preu era molt elevat en aquell moment i calia buscar alternatives. Aquells. necessitàvem utilitzar millor tant l'espai dels centres de dades com els servidors físics on es troba tot això. I els nostres enginyers de sistemes van començar un gran estudi en què van revisar un munt d'opcions diferents. També van analitzar sistemes de fitxers agrupats com PolyCeph i Luster. Hi va haver problemes de rendiment i un funcionament força difícil. Es van negar. Vam intentar muntar tot el conjunt de dades mitjançant NFS a cada cotxe per tal d'escalar-lo d'alguna manera. La lectura també va anar malament, vam provar diferents solucions de diferents venedors.
I al final, ens vam decidir utilitzar l'anomenada Xarxa d'Àrea d'emmagatzematge.
Es tracta de grans SHD dissenyats específicament per emmagatzemar grans quantitats de dades. Són prestatgeries amb discs que es munten a les màquines finals de sortida òptica. Això. tenim algun tipus de conjunt de màquines, força petites, i aquests SHD, que són transparents a la nostra lògica d'enviament, és a dir. perquè el nostre nginx o qualsevol altra persona serveixi sol·licituds d'aquestes fotos.
Aquesta decisió va tenir avantatges evidents. Això és SHD. Està dirigit a emmagatzemar fotografies. Això surt més barat que simplement equipar les màquines amb discs durs.
Segon plus.
Això és que la capacitat s'ha fet molt més gran, és a dir. podem acomodar molt més emmagatzematge en un volum molt més petit.
Però també hi havia desavantatges que van sorgir amb força rapidesa. A mesura que augmentava el nombre d'usuaris i la càrrega d'aquest sistema, van començar a sorgir problemes de rendiment. I el problema aquí és força evident: qualsevol SHD dissenyat per emmagatzemar moltes fotos en un volum petit, per regla general, pateix una lectura intensiva. Això és realment cert per a qualsevol emmagatzematge al núvol o qualsevol altra cosa. Ara no tenim un emmagatzematge ideal que sigui infinitament escalable, hi podríeu introduir qualsevol cosa i toleraria molt bé les lectures. Sobretot lectures casuals.
Com passa amb les nostres fotos, perquè les fotos es demanen de manera inconsistent, i això afectarà molt el seu rendiment.
Fins i tot segons les xifres actuals, si arribem a més de 500 RPS per a fotos en una màquina a la qual està connectat l'emmagatzematge, els problemes ja comencen. I va ser prou dolent per a nosaltres, perquè el nombre d'usuaris està creixent, les coses només empitjoraran. Això s'ha d'optimitzar d'alguna manera.
Per optimitzar, vam decidir en aquell moment, òbviament, mirar el perfil de càrrega: què està passant, en general, què cal optimitzar.
I aquí tot juga a les nostres mans.
Ja ho vaig dir a la primera diapositiva: tenim 80 mil sol·licituds de lectura per segon amb només 3,5 milions de càrregues al dia. És a dir, es tracta d'una diferència de tres ordres de magnitud. És evident que cal optimitzar la lectura i pràcticament queda clar com.
Hi ha un petit punt més. Les característiques del servei són tals que una persona es registra, penja una foto, després comença a mirar activament altres persones, com elles, i es mostra activament a altres persones. Llavors troba parella o no troba parella, depèn de com li surti, i deixa d'utilitzar el servei durant un temps. En aquest moment, quan l'utilitza, les seves fotos són molt calentes: són demanades, molta gent les veu. Tan bon punt deixa de fer-ho, ràpidament abandona la seva exposició a altres persones com abans, i les seves fotos gairebé mai no es demanen.
Aquells. Tenim un conjunt de dades calent molt petit. Però al mateix temps hi ha moltes peticions per a ell. I una solució completament òbvia aquí és afegir una memòria cau.
Una memòria cau amb LRU solucionarà tots els nostres problemes. Què estem fent?
Afegim un altre de relativament petit davant del nostre gran clúster amb emmagatzematge, que s'anomena fotocachés. Això és essencialment només un servidor intermediari de memòria cau.
Com funciona des de dins? Aquí teniu el nostre usuari, aquí teniu l'emmagatzematge. Tot és igual que abans. Què hi afegim entremig?
És només una màquina amb un disc local físic, que és ràpid. Això és amb un SSD, per exemple. I algun tipus de memòria cau local s'emmagatzema en aquest disc.
Quin aspecte té? L'usuari envia una sol·licitud de foto. NGINX el cerca primer a la memòria cau local. Si no, simplement proxy_pass al nostre emmagatzematge, descarregueu la foto des d'allà i doneu-la a l'usuari.
Però aquest és molt banal i no està clar què passa a dins. Funciona una cosa així.
La memòria cau es divideix lògicament en tres capes. Quan dic "tres capes", això no vol dir que hi hagi algun tipus de sistema complex. No, aquests són condicionalment només tres directoris del sistema de fitxers:
- Aquest és un buffer on van les fotos que s'acaben de baixar d'un servidor intermediari.
- Aquesta és una memòria cau activa que emmagatzema les fotos sol·licitades de manera activa.
- I una memòria cau freda, on les fotos s'expulsen gradualment de la memòria cau calenta quan hi arriben menys sol·licituds.
Perquè això funcioni, hem de gestionar d'alguna manera aquesta memòria cau, hem de reordenar les fotos que hi ha, etc. Aquest és també un procés molt primitiu.
Nginx simplement escriu al RAMDisk access.log per a cada sol·licitud, en la qual indica el camí a la foto que ha servit actualment (camí relatiu, és clar) i quina partició es va servir. Aquells. pot dir "foto 1" i després una memòria intermèdia, una memòria cau calenta, una memòria cau freda o un proxy.
En funció d'això, hem de decidir d'alguna manera què fer amb la foto.
Tenim un petit dimoni en funcionament a cada màquina que llegeix constantment aquest registre i emmagatzema estadístiques sobre l'ús de determinades fotografies a la seva memòria.
Simplement hi recull, guarda els comptadors i periòdicament fa el següent. Mou les fotos sol·licitades activament, per a les quals hi ha moltes sol·licituds, a la memòria cau calenta, sigui on siguin.
Les fotos que es demanen poques vegades i que s'han sol·licitat amb menys freqüència s'expulsen gradualment de la memòria cau calenta a la més freda.
I quan ens quedem sense espai a la memòria cau, simplement comencem a suprimir-ho tot de la memòria cau freda indiscriminadament. I, per cert, això funciona bé.
Per tal que la foto es desi immediatament quan l'enviem a la memòria intermèdia, utilitzem la directiva proxy_store i la memòria intermèdia també és un RAMDisk, és a dir. per a l'usuari funciona molt ràpidament. Això es refereix als elements interns del propi servidor de memòria cau.
La pregunta restant és com distribuir les sol·licituds entre aquests servidors.
Suposem que hi ha un clúster de vint màquines d'emmagatzematge i tres servidors de memòria cau (així va passar).
Hem de determinar d'alguna manera quines sol·licituds són per a quines fotos i on les aconseguim.
L'opció més habitual és Round Robin. O fer-ho per accident?
Això, òbviament, té una sèrie de desavantatges perquè en aquesta situació faríem servir la memòria cau de manera molt ineficient. Les sol·licituds arribaran a algunes màquines aleatòries: aquí es va guardar a la memòria cau, però a la següent ja no hi és. I si tot això funciona, serà molt dolent. Fins i tot amb un petit nombre de màquines al clúster.
Hem de determinar d'alguna manera sense ambigüitats quin servidor aterrar quina sol·licitud.
Hi ha una manera banal. Agafem el hash de l'URL o el hash de la nostra clau de fragmentació, que es troba a l'URL, i el dividim pel nombre de servidors. Treballarà? Voluntat.
Aquells. Tenim una sol·licitud del 2%, per exemple, per a alguns "example_url" sempre arribarà al servidor amb l'índex "XNUMX", i la memòria cau s'eliminarà de la millor manera possible.
Però hi ha un problema amb la redistribució en aquest esquema. Redistribució: vull dir canviar el nombre de servidors.
Suposem que el nostre clúster de memòria cau ja no pot fer front i decidim afegir una altra màquina.
Afegim.
Ara tot és divisible no per tres, sinó per quatre. Així, gairebé totes les claus que teníem, gairebé tots els URL viuen ara en altres servidors. Tota la memòria cau es va invalidar només per un moment. Totes les sol·licituds van recaure en el nostre clúster d'emmagatzematge, es va tornar malament, fallava el servei i els usuaris estaven insatisfets. No vull fer això.
Aquesta opció tampoc ens convé.
Això. que hauriem de fer? D'alguna manera hem de fer un ús eficient de la memòria cau, aconseguir la mateixa sol·licitud al mateix servidor una vegada i una altra, però ser resistents a la redistribució. I hi ha una solució així, no és tan complicada. S'anomena hashing coherent.
Quin aspecte té?
Agafem alguna funció de la clau de fragmentació i repartim tots els seus valors al cercle. Aquells. al punt 0, convergeixen els seus valors mínim i màxim. A continuació, col·loquem tots els nostres servidors al mateix cercle aproximadament d'aquesta manera:
Cada servidor està definit per un punt, i el sector que hi va en el sentit de les agulles del rellotge, en conseqüència, és servit per aquest host. Quan ens arriben les peticions, de seguida veiem que, per exemple, la sol·licitud A -hi té un hash- i és atesa pel servidor 2. Sol·licitud B - pel servidor 3. I així successivament.
Què passa en aquesta situació durant la reestructuració?
No invalidem tota la memòria cau, com abans, i no desplacem totes les tecles, sinó que desplacem cada sector una distància curta perquè, relativament parlant, el nostre sisè servidor, que volem afegir, encaixi a l'espai lliure, i l'afegim allà.
Per descomptat, en aquesta situació les claus també es mouen. Però es mouen molt més febles que abans. I veiem que les nostres dues primeres claus es van mantenir als seus servidors i el servidor de memòria cau només va canviar per a l'última clau. Això funciona de manera bastant eficient i, si afegiu nous amfitrions de manera incremental, aquí no hi ha cap gran problema. Afegiu i afegiu una mica a la vegada, espereu fins que la memòria cau es torni a omplir i tot funcioni bé.
L'única qüestió segueix sent amb les denegacions. Suposem que algun tipus de cotxe està fora de servei.
I realment no voldríem regenerar aquest mapa en aquest moment, invalidar part de la memòria cau, etc., si, per exemple, la màquina s'ha reiniciat i necessitem d'alguna manera les sol·licituds de servei. Simplement conservem una memòria cau de fotos de seguretat a cada lloc, que actua com a reemplaçament de qualsevol màquina que estigui actualment inactiva. I si de sobte un dels nostres servidors no està disponible, el trànsit hi va. Naturalment, no hi tenim cap memòria cau, és a dir. fa fred, però almenys es processen les sol·licituds dels usuaris. Si aquest és un interval curt, llavors ho experimentem amb tota calma. Només hi ha més càrrega d'emmagatzematge. Si aquest interval és llarg, ja podem prendre una decisió: eliminar aquest servidor del mapa o no, o potser substituir-lo per un altre.
Es tracta del sistema de memòria cau. Vegem els resultats.
Sembla que aquí no hi ha res complicat. Però aquest mètode de gestió de la memòria cau ens va donar un percentatge de trucs d'aproximadament el 98%. Aquells. D'aquestes 80 mil peticions per segon, només 1600 arriben a l'emmagatzematge, i això és una càrrega totalment normal, ho suporten amb calma, sempre tenim reserva.
Hem col·locat aquests servidors a tres dels nostres DC i hem rebut tres punts de presència: Praga, Miami i Hong Kong.
Això. estan més o menys localitzats a cadascun dels nostres mercats objectiu.
I com a bon avantatge, tenim aquest servidor intermediari de memòria cau, en el qual la CPU està realment inactiva, perquè no és tan necessari per oferir contingut. I allà, utilitzant NGINX+ Lua, vam implementar molta lògica utilitària.
Per exemple, podem experimentar amb webp o jpeg progressiu (són formats moderns efectius), veure com afecta el trànsit, prendre algunes decisions, habilitar-lo per a determinats països, etc.; fer un canvi de mida dinàmic o retallar fotos sobre la marxa.
Aquest és un bon cas d'ús quan, per exemple, tens una aplicació mòbil que mostra fotos i l'aplicació mòbil no vol malgastar la CPU del client en demanar una foto gran i després canviar-la a una mida determinada per introduir-la. la vista. Simplement podem especificar de forma dinàmica alguns paràmetres a l'URL condicional UPort i la memòria cau de la foto canviarà la mida de la foto. Per regla general, seleccionarà la mida que tenim físicament al disc, el més propera possible a la sol·licitada, i la rebaixarà en coordenades concretes.
Per cert, hem posat a disposició del públic enregistraments de vídeo dels últims cinc anys de la conferència de desenvolupadors de sistemes d'alta càrrega. . Mira, aprèn, comparteix i subscriu-te .
També hi podem afegir molta lògica de producte. Per exemple, podem afegir diferents filigranes mitjançant paràmetres d'URL, podem desenfocar, desenfocar o pixelar fotos. És quan volem mostrar una foto d'una persona, però no volem mostrar la seva cara, això funciona bé, tot està implementat aquí.
Què hem aconseguit? Tenim tres punts de presència, una bona taxa de trucs i, al mateix temps, no tenim CPU inactiva en aquestes màquines. Ara ha esdevingut, és clar, més important que abans. Hem de donar-nos cotxes més forts, però val la pena.
Es tracta de la devolució de les fotografies. Aquí tot és clar i evident. Crec que no vaig descobrir Amèrica, gairebé qualsevol CDN funciona d'aquesta manera.
I, molt probablement, un oient sofisticat podria tenir una pregunta: per què no canviar-ho tot a CDN? Seria més o menys el mateix que tots els CDN moderns poden fer-ho. I hi ha una sèrie de motius.
El primer són les fotografies.
Aquest és un dels punts clau de la nostra infraestructura, i necessitem el màxim control possible. Si es tracta d'algun tipus de solució d'un proveïdor extern i no teniu cap poder sobre això, us serà bastant difícil viure-hi quan tingueu un conjunt de dades gran i quan tingueu un flux molt gran. de les peticions dels usuaris.
Permeteu-me que us posi un exemple. Ara, amb la nostra infraestructura, podem, per exemple, en cas d'alguns problemes o cops subterranis, anar a la màquina i embolicar-nos, relativament parlant. Podem afegir la col·lecció d'algunes mètriques que només necessitem, podem experimentar d'alguna manera, veure com això afecta els gràfics, etc. Ara s'estan recopilant moltes estadístiques sobre aquest clúster de memòria cau. I periòdicament ho mirem i dediquem una llarga estona a explorar algunes anomalies. Si fos del costat de la CDN, seria molt més difícil de controlar. O, per exemple, si es produeix algun tipus d'accident, sabem què ha passat, sabem com conviure-hi i com superar-lo. Aquesta és la primera conclusió.
La segona conclusió també és bastant històrica, perquè el sistema s'ha desenvolupat durant molt de temps i hi havia molts requisits empresarials diferents en diferents etapes, i no sempre encaixen en el concepte CDN.
I el punt que es desprèn de l'anterior és
Això es deu al fet que a les memòria cau de fotos tenim molta lògica específica, que no sempre es pot afegir a petició. És poc probable que qualsevol CDN us afegeixi algunes coses personalitzades a la vostra sol·licitud. Per exemple, xifrar URL si no voleu que el client pugui canviar alguna cosa. Voleu canviar l'URL del servidor i xifrar-lo, i després enviar aquí alguns paràmetres dinàmics.
Quina conclusió suggereix això? En el nostre cas, CDN no és una bona alternativa.
I en el vostre cas, si teniu algun requisit empresarial específic, podeu implementar fàcilment el que us vaig mostrar. I això funcionarà perfectament amb un perfil de càrrega similar.
Però si teniu algun tipus de solució general i la tasca no és molt específica, podeu prendre una CDN amb tota seguretat. O si el temps i els recursos són més importants per a tu que el control.
I els CDN moderns tenen gairebé tot el que us he explicat ara. Amb l'excepció d'algunes característiques més o menys.
Es tracta de regalar fotos.
Ara avancem una mica en la nostra retrospectiva i parlem d'emmagatzematge.
El 2013 estava passant.
Es van afegir servidors de memòria cau, els problemes de rendiment van desaparèixer. Tot està bé. El conjunt de dades està creixent. A partir del 2013, teníem uns 80 servidors connectats a l'emmagatzematge i uns 40 de memòria cau a cada DC. Això són 560 terabytes de dades a cada DC, és a dir. aproximadament un petabyte en total.
I amb el creixement del conjunt de dades, els costos operatius van començar a augmentar significativament. Què va significar això?
En aquest diagrama que es dibuixa -amb una SAN, amb màquines i memòria cau connectades- hi ha molts punts de fallada. Si abans ja havíem tractat la fallada dels servidors de la memòria cau, tot era més o menys previsible i comprensible, però pel que fa a l'emmagatzematge tot era molt pitjor.
En primer lloc, la pròpia xarxa d'àrea d'emmagatzematge (SAN), que pot fallar.
En segon lloc, es connecta mitjançant òptica a les màquines finals. Pot haver-hi problemes amb les targetes òptiques i les bugies.
Per descomptat, no n'hi ha tants com amb la pròpia SAN, però, tanmateix, també són punts de fracàs.
El següent és la pròpia màquina, que està connectada a l'emmagatzematge. També pot fallar.
En total, tenim tres punts de fracàs.
A més, a més dels punts de fallada, hi ha un fort manteniment del propi emmagatzematge.
Aquest és un sistema complex de diversos components i els enginyers de sistemes poden tenir dificultats per treballar-hi.
I l'últim punt, el més important. Si es produeix una fallada en qualsevol d'aquests tres punts, tenim una probabilitat diferent de zero de perdre les dades de l'usuari perquè el sistema de fitxers es pot bloquejar.
Suposem que el nostre sistema de fitxers està trencat. En primer lloc, la seva recuperació triga molt de temps: pot trigar una setmana amb una gran quantitat de dades. I en segon lloc, al final el més probable és que acabem amb un munt d'arxius incomprensibles que caldrà combinar d'alguna manera en fotos d'usuari. I correm el risc de perdre dades. El risc és bastant alt. I com més sovint es produeixen aquestes situacions, i com més problemes sorgeixen en tota aquesta cadena, més gran és aquest risc.
Alguna cosa s'havia de fer al respecte. I vam decidir que només cal fer una còpia de seguretat de les dades. Aquesta és realment una solució òbvia i bona. Què hem fet?
Així es veia el nostre servidor quan abans estava connectat a l'emmagatzematge. Aquesta és una secció principal, només és un dispositiu de bloc que en realitat representa un suport per a l'emmagatzematge remot mitjançant òptica.
Acabem d'afegir una segona secció.
Vam col·locar un segon emmagatzematge al costat (afortunadament, no és tan car en termes de diners) i l'hem anomenat partició de còpia de seguretat. També està connectat mitjançant òptica i es troba a la mateixa màquina. Però hem de sincronitzar d'alguna manera les dades entre ells.
Aquí simplement fem una cua asíncrona a prop.
No està gaire ocupada. Sabem que no tenim prou registres. Una cua és només una taula a MySQL en què s'escriuen línies com "cal fer una còpia de seguretat d'aquesta foto". Amb qualsevol canvi o càrrega, copiem des de la partició principal a la còpia de seguretat mitjançant un treballador asíncron o només algun tipus de treball en segon pla.
I així sempre tenim dues seccions coherents. Fins i tot si una part d'aquest sistema falla, sempre podem canviar la partició principal amb una còpia de seguretat i tot continuarà funcionant.
Però per això, la càrrega de lectura augmenta molt, perquè... a més dels clients que llegeixen de la secció principal, perquè primer miren la foto allà (allà és més recent), i després la busquen a la còpia de seguretat, si no l'han trobat (però NGINX només ho fa), el nostre sistema també és una còpia de seguretat més que ara llegeix des de la partició principal. No és que això fos un coll d'ampolla, però no volia augmentar la càrrega, bàsicament, així.
I vam afegir un tercer disc, que és un petit SSD, i l'hem anomenat buffer.
Com funciona ara.
L'usuari penja una foto a la memòria intermèdia i després es llança un esdeveniment a la cua que indica que s'ha de copiar en dues seccions. Es copia i la foto viu a la memòria intermèdia durant un temps (per exemple, un dia) i només després es purga d'allà. Això millora molt l'experiència de l'usuari, perquè l'usuari puja una foto, per regla general, les sol·licituds comencen a seguir immediatament, o ell mateix ha actualitzat la pàgina i l'ha actualitzat. Però tot depèn de l'aplicació que faci la càrrega.
O, per exemple, altres persones a les quals va començar a mostrar-se immediatament envien peticions després d'aquesta foto. Encara no està a la memòria cau, la primera sol·licitud es produeix molt ràpidament. Bàsicament el mateix que d'una memòria cau de fotos. L'emmagatzematge lent no està implicat en això. I quan un dia després es purga, ja està en memòria cau a la nostra capa d'emmagatzematge a la memòria cau o, molt probablement, ja no ho necessita ningú. Aquells. L'experiència de l'usuari aquí ha crescut molt bé a causa de manipulacions tan senzilles.
Bé, i el més important: vam deixar de perdre dades.
Diguem que ens hem aturat potencialment perdre dades, perquè realment no les hem perdut. Però hi havia perill. Veiem que aquesta solució és, per descomptat, bona, però és una mica com suavitzar els símptomes del problema, en lloc de resoldre'l completament. I alguns problemes continuen aquí.
En primer lloc, es tracta d'un punt de fallada en la forma del propi host físic sobre el qual funciona tota aquesta maquinària;
En segon lloc, encara hi ha problemes amb les SAN, el seu elevat manteniment, etc. No era que fos un factor crític, però volia intentar viure d'alguna manera sense ell.
I vam fer la tercera versió (de fet, la segona de fet): la versió de reserva. Com es veia?
Això és el que era -
Els nostres principals problemes són el fet que aquest és un host físic.
En primer lloc, estem eliminant les SAN perquè volem experimentar, només volem provar els discs durs locals.
Això ja és el 2014-2015, i en aquell moment la situació amb els discs i la seva capacitat en un host va ser molt millor. Vam decidir per què no provar-ho.
I després simplement prenem la nostra partició de còpia de seguretat i la transferim físicament a una màquina independent.
Així, obtenim aquest diagrama. Tenim dos cotxes que emmagatzemen els mateixos conjunts de dades. Es fan còpies de seguretat entre si completament i sincronitzen les dades a la xarxa mitjançant una cua asíncrona al mateix MySQL.
Per què això funciona bé és perquè tenim pocs registres. Aquells. si l'escriptura fos comparable a la lectura, potser tindríem algun tipus de sobrecàrrega i problemes de xarxa. Hi ha poca escriptura, molta lectura; aquest mètode funciona bé, és a dir. Poques vegades copiem fotos entre aquests dos servidors.
Com funciona això, si mireu una mica més en detall.
Carrega. L'equilibrador simplement selecciona amfitrions aleatòries amb un parell i s'hi carrega. Al mateix temps, naturalment fa controls de salut i s'assegura que el cotxe no caigui. Aquells. només penja fotos a un servidor en directe i després, a través d'una cua asíncrona, es copia tot al seu veí. Amb la càrrega tot és extremadament senzill.
La tasca és una mica més difícil.
Lua ens va ajudar aquí, perquè pot ser difícil fer aquesta lògica a vanilla NGINX. Primer fem una petició al primer servidor, mirem si la foto hi és, perquè potencialment es podria pujar, per exemple, a un veí, però encara no ha arribat aquí. Si hi ha la foto, està bé. El donem immediatament al client i, possiblement, el desem a la memòria cau.
Si no hi és, simplement fem una petició al nostre veí i tenim la garantia de rebre-la des d'allà.
Això. de nou podem dir: hi pot haver problemes amb el rendiment, perquè hi ha constants viatges d'anada i tornada: la foto s'ha penjat, no és aquí, estem fent dues peticions en lloc d'una, això hauria de funcionar lentament.
En la nostra situació, això no funciona lentament.
Recopilem un munt de mètriques en aquest sistema i la taxa intel·ligent condicional d'aquest mecanisme és d'aproximadament el 95%. Aquells. El retard d'aquesta còpia de seguretat és petit, i per això estem gairebé garantits, després de pujar la foto, la farem la primera vegada i no haurem d'anar enlloc dues vegades.
Aleshores, què més tenim que és realment genial?
Anteriorment, teníem la partició de còpia de seguretat principal i les llegim seqüencialment. Aquells. Sempre hem cercat primer a la principal i després a la còpia de seguretat. Va ser un moviment.
Ara fem servir la lectura de dues màquines alhora. Distribuïm les sol·licituds mitjançant Round Robin. En un petit percentatge de casos fem dues peticions. Però, en general, ara tenim el doble d'estoc de lectura que abans. I la càrrega es va reduir molt tant a les màquines d'enviament com directament a les màquines d'emmagatzematge, que també teníem en aquell moment.
Pel que fa a la tolerància a errors. De fet, per això hem lluitat principalment. Amb tolerància a errors, aquí tot va sortir genial.
Un cotxe s'avaria.
Cap problema! Un enginyer de sistemes potser ni tan sols es desperta a la nit, esperarà fins al matí, no passarà res dolent.
Si fins i tot si aquesta màquina falla, la cua està fora de servei, tampoc no hi ha problemes, el registre simplement s'acumularà primer a la màquina viva, i després s'afegirà a la cua i després al cotxe que es farà. entrar en funcionament al cap d'un temps.
El mateix amb el manteniment. Simplement apaguem una de les màquines, la traiem manualment de totes les piscines, deixa de rebre trànsit, fem algun tipus de manteniment, editem alguna cosa, després la tornem al servei i aquesta còpia de seguretat es posa al dia amb força rapidesa. Aquells. al dia, el temps d'inactivitat d'un cotxe s'aconsegueix en un parell de minuts. Això és realment molt poc. Amb tolerància a errors, torno a dir, aquí tot és genial.
Quines conclusions es poden extreure d'aquest esquema de redundància?
Tenim tolerància a falles.
Fàcil d'usar. Com que les màquines tenen discs durs locals, això és molt més convenient des d'un punt de vista operatiu per als enginyers que hi treballen.
Vam rebre un doble subsidi de lectura.
Aquest és un bon avantatge a més de la tolerància a errors.
Però també hi ha problemes. Ara tenim un desenvolupament molt més complex d'algunes característiques relacionades amb això, perquè el sistema s'ha convertit finalment al 100% en coherència.
Hem de pensar, per exemple, en algun treball de fons, constantment: "En quin servidor estem executant ara?", "Hi ha realment una foto actual aquí?" etc. Això, per descomptat, està tot embolicat, i per al programador que escriu la lògica empresarial, és transparent. Però, tanmateix, aquesta gran capa complexa ha aparegut. Però estem disposats a aguantar això a canvi de les llaminadures que en vam rebre.
I aquí torna a sorgir algun conflicte.
Vaig dir al principi que emmagatzemar-ho tot als discs durs locals és dolent. I ara dic que ens ha agradat.
Sí, efectivament, amb el temps la situació ha canviat molt, i ara aquest enfocament té molts avantatges. En primer lloc, tenim un funcionament molt més senzill.
En segon lloc, és més productiu, perquè no tenim aquests controladors automàtics ni connexions a prestatgeries de discs.
Hi ha una gran quantitat de maquinària allà, i aquests són només uns quants discos que es munten aquí a la màquina en una incursió.
Però també hi ha desavantatges.
Això és aproximadament 1,5 vegades més car que utilitzar SAN fins i tot als preus actuals. Per tant, vam decidir no convertir amb valentia tot el nostre gran clúster en cotxes amb discs durs locals i vam decidir deixar una solució híbrida.
La meitat de les nostres màquines funcionen amb discs durs (bé, no la meitat, probablement el 30%). I la resta són cotxes antics que abans tenien el règim de primera reserva. Simplement els vam tornar a muntar, ja que no necessitàvem dades noves ni res més, simplement vam moure els muntatges d'un host físic a dos.
I ara tenim un gran fons de lectura, i l'hem ampliat. Si abans muntàvem un emmagatzematge en una màquina, ara en muntem quatre, per exemple, en un parell. I funciona bé.
Fem un breu resum del que hem aconseguit, per què hem lluitat i si hem tingut èxit.
Resultats de
Tenim usuaris, fins a 33 milions.
Tenim tres punts de presència: Praga, Miami, Hong Kong.
Contenen una capa de memòria cau, que consta de cotxes amb discs locals ràpids (SSD), sobre els quals s'executen maquinària senzilla de NGINX, els seus dimonis access.log i Python, que processen tot això i gestionen la memòria cau.
Si ho desitges, estàs en el teu projecte, si les fotos no són tan crítiques per a tu com ho són per a nosaltres, o si el control de la compensació versus la velocitat de desenvolupament i els costos dels recursos és en l'altra direcció per a tu, pots substituir-les amb seguretat. amb un CDN, els CDN moderns ho fan bé.
A continuació ve la capa d'emmagatzematge, en la qual tenim grups de parells de màquines que fan una còpia de seguretat entre si, els fitxers es copien de manera asíncrona d'un a un altre sempre que canvien.
A més, algunes d'aquestes màquines funcionen amb discs durs locals.
Algunes d'aquestes màquines estan connectades a SAN.
I, d'una banda, és més còmode d'utilitzar i una mica més productiu, de l'altra, és convenient pel que fa a la densitat de col·locació i el preu per gigabyte.
Aquesta és una breu visió general de l'arquitectura del que hem aconseguit i de com es va desenvolupar tot.
Uns quants consells més del capità, molt senzills.
En primer lloc, si de sobte decideixes que necessites millorar-ho amb urgència tot a la teva infraestructura fotogràfica, mesura primer, perquè potser no cal millorar res.
Permeteu-me que us posi un exemple. Tenim un grup de màquines que envia fotos des d'arxius adjunts als xats, i l'esquema hi funciona des del 2009, i ningú no ho pateix. Tothom està bé, a tothom li agrada tot.
Per mesurar, primer pengeu un munt de mètriques, mireu-les i, després, decidiu amb què no esteu satisfet i què cal millorar. Per mesurar-ho, tenim una eina genial anomenada Pinba.
Us permet recopilar estadístiques molt detallades de NGINX per a cada sol·licitud i codis de resposta, i la distribució de temps, el que vulgueu. Té enllaços a tot tipus de sistemes d'anàlisi diferents i, a continuació, podeu mirar-ho tot molt bé.
Primer ho vam mesurar, després ho vam millorar.
Més lluny. Optimitzem la lectura amb memòria cau, l'escriptura amb fragments, però aquest és un punt obvi.
Més lluny. Si ara comenceu a crear el vostre sistema, és molt millor fer fotos com a fitxers immutables. Perquè immediatament perds tota una classe de problemes amb la invalidació de la memòria cau, amb com la lògica hauria de trobar la versió correcta de la foto, etc.
Suposem que n'heu penjat un centenar, que després l'heu girat, que sigui un fitxer físicament diferent. Aquells. no cal pensar: ara estalviaré una mica d'espai, l'escriuré al mateix fitxer, canviaré la versió. Això sempre no funciona bé i causa molts mals de cap més tard.
Següent punt. Sobre el canvi de mida sobre la marxa.
Anteriorment, quan els usuaris penjaven una foto, de seguida vam retallar un munt de mides per a totes les ocasions, per a diferents clients, i totes estaven al disc. Ara ho hem abandonat.
Només hem deixat tres mides principals: petita, mitjana i gran. Simplement reduïm la resta de la mida que hi ha darrere de la que ens va demanar a Uport, simplement fem la reducció i la donem a l'usuari.
La CPU de la capa d'emmagatzematge en memòria cau aquí resulta molt més barata que si regeneraríem constantment aquestes mides a cada emmagatzematge. Suposem que volem afegir-ne un de nou, això trigarà un mes: executeu un script a tot arreu que faria tot això de manera ordenada, sense destruir el clúster. Aquells. Si tens l'oportunitat de triar ara, és millor fer el mínim de mides físiques possibles, però perquè almenys una mica de distribució sigui, per exemple, tres. I tota la resta es pot canviar de mida sobre la marxa mitjançant mòduls ja fets. Tot és molt fàcil i accessible ara.
I la còpia de seguretat asíncrona incremental és bona.
Com ha demostrat la nostra pràctica, aquest esquema funciona molt bé amb la còpia retardada dels fitxers modificats.
El darrer punt també és evident. Si ara la vostra infraestructura no té aquests problemes, però hi ha alguna cosa que es pot trencar, definitivament es trencarà quan sigui una mica més. Per tant, és millor pensar-hi amb antelació i no tenir problemes amb això. Això és tot el que volia dir.
Contactes
»
»
Aquest informe és la transcripció d'una de les millors ponències de la conferència de desenvolupadors de sistemes d'alta càrrega . Queda menys d'un mes per a la conferència HighLoad++ 2017.
Ja el tenim llest , ara s'està formant activament el calendari.
Aquest any continuem explorant el tema de les arquitectures i l'escala:
- / Igor Vasiliev
- / Dmitri Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
També fem servir alguns d'aquests materials en el nostre curs de formació en línia sobre el desenvolupament de sistemes d'alta càrrega és una cadena de cartes, articles, materials, vídeos especialment seleccionats. El nostre llibre de text ja conté més de 30 materials únics. Connecta't!
Font: www.habr.com
