Artem Denisov ( , )
Badoo é o sitio de citas máis grande do mundo. Actualmente temos uns 330 millóns de usuarios rexistrados en todo o mundo. Pero o que é moito máis importante no contexto da nosa conversa de hoxe é que almacenamos uns 3 petabytes de fotos dos usuarios. Cada día, os nosos usuarios cargan preto de 3,5 millóns de fotos novas e a carga de lectura é de aproximadamente 80 mil solicitudes por segundo. Isto é moito para o noso backend, e ás veces hai dificultades con isto.
Falarei do deseño deste sistema, que almacena e envía fotos en xeral, e mirarei dende o punto de vista dun desenvolvedor. Farase unha breve retrospectiva de como se desenvolveu, onde esbozarei os principais fitos, pero só falarei con máis detalle das solucións que estamos a utilizar actualmente.
Agora imos comezar.
Como dixen, esta será unha retrospectiva e, para comezala nalgún lugar, poñamos o exemplo máis común.
Temos unha tarefa común, necesitamos aceptar, almacenar e enviar fotos dos usuarios. Neste formulario, a tarefa é xeral, podemos usar calquera cousa:
- almacenamento en nube moderno,
- unha solución en caixa, da que tamén hai moito agora;
- Podemos configurar varias máquinas no noso centro de datos e poñer nelas grandes discos duros e almacenar alí fotos.
Badoo historicamente - tanto agora como entón (no momento en que estaba na súa infancia) - vive nos seus propios servidores, dentro dos nosos propios DC. Polo tanto, esta opción era óptima para nós.
Acabamos de coller varias máquinas, chamámolas "fotos" e obtivemos un clúster que almacena fotos. Pero parece que falta algo. Para que todo isto funcione, necesitamos determinar dalgún xeito en que máquina almacenaremos que fotos. E aquí tampouco hai que abrir América.
Engadimos algún campo ao noso almacenamento con información sobre os usuarios. Esta será a clave de fragmentación. No noso caso, chamámoslle place_id, e este identificador de lugar apunta ao lugar onde se almacenan as fotos dos usuarios. Facemos mapas.
Na primeira fase, incluso pódese facer manualmente: dicimos que unha foto deste usuario con tal lugar aterrará nun servidor deste tipo. Grazas a este mapa, sempre sabemos cando un usuario carga unha foto, onde gardala e de onde entregala.
Este é un esquema absolutamente trivial, pero ten vantaxes bastante importantes. O primeiro é que é sinxelo, como dixen, e o segundo é que con este enfoque podemos escalar facilmente horizontalmente simplemente entregando novos coches e engadíndoos ao mapa. Non necesitas facer nada máis.
Así nos foi durante algún tempo.
Isto foi ao redor de 2009. Entregaron coches, entregaron...
E nalgún momento comezamos a notar que este esquema ten certas desvantaxes. Cales son as desvantaxes?
En primeiro lugar, hai un aforo limitado. Non podemos colocar tantos discos duros nun servidor físico como nos gustaría. E isto converteuse nun certo problema co paso do tempo e co crecemento do conxunto de datos.
E segundo. Esta é unha configuración atípica das máquinas, xa que estas máquinas son difíciles de reutilizar noutros clusters; son bastante específicas, é dicir. deberían ser débiles no seu rendemento, pero ao mesmo tempo cun disco duro grande.
Isto foi todo para 2009, pero, en principio, estes requisitos seguen sendo relevantes na actualidade. Temos unha retrospectiva, así que en 2009 todo foi completamente mal con isto.
E o último punto é o prezo.
O prezo era moi elevado nese momento, e necesitabamos buscar algunhas alternativas. Eses. necesitabamos utilizar mellor tanto o espazo nos centros de datos como os servidores físicos nos que se atopa todo isto. E os nosos enxeñeiros de sistemas comezaron un gran estudo no que revisaron unha morea de opcións diferentes. Tamén analizaron sistemas de ficheiros agrupados como PolyCeph e Luster. Houbo problemas de rendemento e un funcionamento bastante difícil. Eles negáronse. Tentamos montar todo o conxunto de datos a través de NFS en cada coche para escalalo dalgún xeito. A lectura tamén foi mal, probamos diferentes solucións de diferentes provedores.
E ao final, decidimos utilizar a chamada Rede de Área de Almacenamento.
Estes son grandes SHD que están deseñados especificamente para almacenar grandes cantidades de datos. Son estantes con discos que se montan nas máquinas de saída óptica final. Iso. temos algún tipo de grupo de máquinas, bastante pequenas, e estes SHD, que son transparentes para a nosa lóxica de envío, é dicir. para que o noso nginx ou calquera outra persoa sirva solicitudes destas fotos.
Esta decisión tivo vantaxes obvias. Este é SHD. Está destinado a almacenar fotos. Isto resulta máis barato que simplemente equipar máquinas con discos duros.
Segundo plus.
Isto é que a capacidade se fixo moito maior, é dicir. podemos acomodar moito máis almacenamento nun volume moito menor.
Pero tamén houbo desvantaxes que xurdiron con bastante rapidez. A medida que creceu o número de usuarios e a carga deste sistema, comezaron a xurdir problemas de rendemento. E o problema aquí é bastante obvio: calquera SHD deseñado para almacenar moitas fotos nun volume pequeno, por regra xeral, sofre unha lectura intensiva. Isto é realmente certo para calquera almacenamento na nube ou calquera outra cousa. Agora non temos un almacenamento ideal que sexa infinitamente escalable, podes meter calquera cousa nel e toleraría moi ben as lecturas. Especialmente lecturas casuales.
Como é o caso das nosas fotos, porque as fotos son solicitadas de forma inconsistente, e isto afectará moito ao seu rendemento.
Mesmo segundo as cifras de hoxe, se chegamos nalgún lugar a máis de 500 RPS para fotos nunha máquina á que está conectado o almacenamento, os problemas xa comezan. E foi bastante malo para nós, porque o número de usuarios está crecendo, as cousas só van a empeorar. Isto debe ser optimizado dalgún xeito.
Para optimizar, decidimos nese momento, obviamente, mirar o perfil de carga: o que, en xeral, está a suceder, o que hai que optimizar.
E aquí todo xoga nas nosas mans.
Xa o dixen na primeira diapositiva: temos 80 mil solicitudes de lectura por segundo con só 3,5 millóns de subidas ao día. É dicir, trátase dunha diferenza de tres ordes de magnitude. É obvio que hai que optimizar a lectura e está practicamente claro como.
Hai un pequeno punto máis. As características específicas do servizo son tales que unha persoa rexístrase, carga unha foto, despois comeza a mirar activamente a outras persoas, como elas, e móstranse activamente a outras persoas. Entón atopa un compañeiro ou non atopa un compañeiro, depende de como resulte, e deixa de usar o servizo por un tempo. Neste momento, cando o usa, as súas fotos son moi quentes: son demandadas, moita xente as ve. Axiña que deixa de facelo, axiña deixa de estar tan exposto a outras persoas como antes, e as súas fotos case nunca son solicitadas.
Eses. Temos un conxunto de datos moi pequeno. Pero ao mesmo tempo hai moitas peticións para el. E unha solución completamente obvia aquí é engadir unha caché.
Unha caché con LRU resolverá todos os nosos problemas. Que estamos facendo?
Engadimos outro relativamente pequeno diante do noso gran clúster con almacenamento, que se chama photocaché. Este é esencialmente só un proxy de caché.
Como funciona dende dentro? Aquí está o noso usuario, aquí está o almacenamento. Todo é igual que antes. Que engadimos no medio?
É só unha máquina cun disco local físico, que é rápido. Isto é cun SSD, por exemplo. E algún tipo de caché local almacénase neste disco.
Que aspecto ten? O usuario envía unha solicitude de foto. NGINX búscao primeiro na caché local. Se non, simplemente pasa por proxy_pass ao noso almacenamento, descarga a foto desde alí e entrégalla ao usuario.
Pero este é moi banal e non está claro o que está a pasar dentro. Funciona algo así.
A caché divídese loxicamente en tres capas. Cando digo "tres capas", isto non significa que haxa algún tipo de sistema complexo. Non, estes son condicionalmente só tres directorios do sistema de ficheiros:
- Este é un búfer no que van as fotos que se acaban de descargar dun proxy.
- Esta é unha caché activa que almacena as fotos solicitadas activamente.
- E unha caché fría, onde as fotos vanse eliminando gradualmente da caché quente cando chegan menos solicitudes.
Para que isto funcione, necesitamos xestionar esta caché dalgún xeito, necesitamos reorganizar as fotos nel, etc. Este tamén é un proceso moi primitivo.
Nginx simplemente escribe no RAMDisk access.log para cada solicitude, na que indica o camiño á foto que serviu actualmente (ruta relativa, por suposto) e a que partición se serviu. Eses. pode dicir "foto 1" e despois un búfer, ou unha caché quente, ou unha caché fría ou un proxy.
Dependendo diso, temos que decidir dalgún xeito que facer coa foto.
Temos un pequeno daemon en execución en cada máquina que le constantemente este rexistro e almacena na súa memoria estatísticas sobre o uso de determinadas fotografías.
Simplemente recolle alí, garda os contadores e fai periodicamente o seguinte. Traslada as fotos solicitadas activamente, para as que hai moitas solicitudes, ao caché quente, onde queira que estean.
As fotos que se solicitan raramente e que se solicitaron con menos frecuencia vanse eliminando gradualmente da caché quente á fría.
E cando quedamos sen espazo na caché, simplemente comezamos a eliminar todo da caché fría indistintamente. E por certo, isto funciona ben.
Para que a foto se garde inmediatamente ao enviarla por proxy ao búfer, usamos a directiva proxy_store e o búfer tamén é un RAMDisk, é dicir. para o usuario funciona moi rápido. Isto refírese aos elementos internos do propio servidor de caché.
A pregunta restante é como distribuír as solicitudes entre estes servidores.
Digamos que hai un clúster de vinte máquinas de almacenamento e tres servidores de caché (así pasou).
Necesitamos determinar dalgún xeito cales son as solicitudes para que fotos e onde desembarcalas.
A opción máis común é Round Robin. Ou facelo por accidente?
Isto obviamente ten unha serie de desvantaxes porque estaríamos usando a caché de forma moi ineficiente nunha situación así. As solicitudes aterrarán nalgunhas máquinas aleatorias: aquí estaba almacenada na caché, pero na seguinte xa non está. E se todo isto funciona, será moi malo. Incluso cun pequeno número de máquinas no clúster.
Necesitamos determinar de xeito inequívoco que servidor desembarcar que solicitude.
Hai un xeito banal. Collemos o hash do URL ou o hash da nosa clave de fragmentación, que está no URL, e dividilo polo número de servidores. Funcionará? Will.
Eses. Temos unha solicitude do 2%, por exemplo, para algún "example_url" sempre aterrará no servidor co índice "XNUMX" e a caché eliminarase constantemente da mellor maneira posible.
Pero hai un problema coa reestructuración neste esquema. Repartición: refírome a cambiar o número de servidores.
Supoñamos que o noso clúster de caché xa non pode facer fronte e decidimos engadir outra máquina.
Engadimos.
Agora todo é divisible non por tres, senón por catro. Así, case todas as claves que antes tiñamos, case todas as URL viven agora noutros servidores. O caché completo foi invalidado simplemente por un momento. Todas as solicitudes recaeron no noso clúster de almacenamento, quedou mal, fallo no servizo e usuarios insatisfeitos. Non quero facer iso.
Esta opción tampouco nos convén.
Iso. que debemos facer? Dalgunha maneira debemos facer un uso eficiente da caché, conseguir a mesma solicitude no mesmo servidor unha e outra vez, pero ser resistentes á redistribución. E hai tal solución, non é tan complicada. Chámase hashing consistente.
Que aspecto ten?
Tomamos algunha función da clave de fragmentación e repartimos todos os seus valores no círculo. Eses. no punto 0 conflúen os seus valores mínimo e máximo. A continuación, colocamos todos os nosos servidores no mesmo círculo aproximadamente deste xeito:
Cada servidor está definido por un punto e, en consecuencia, o sector que vai no sentido das agullas do reloxo é servido por este host. Cando nos chegan as solicitudes, inmediatamente vemos que, por exemplo, a solicitude A -ten un hash alí- e é atendida polo servidor 2. Solicitude B - polo servidor 3. E así por diante.
Que ocorre nesta situación durante o reharding?
Non invalidamos toda a caché, como antes, e non movemos todas as teclas, senón que movemos cada sector unha pequena distancia para que, relativamente falando, o noso sexto servidor, que queremos engadir, encaixe no espazo libre, e engadímolo alí.
Por suposto, en tal situación as chaves tamén se moven. Pero saen moito máis débiles que antes. E vemos que as nosas dúas primeiras claves permaneceron nos seus servidores e o servidor de caché só cambiou a última clave. Isto funciona de forma bastante eficiente e, se engades novos anfitrións de forma incremental, non hai ningún gran problema aquí. Engádese e engádese un pouco á vez, agarda ata que a caché estea chea de novo e todo funcione ben.
A única cuestión segue sendo as negativas. Supoñamos que algún tipo de coche está fóra de servizo.
E realmente non queremos rexenerar este mapa neste momento, invalidar parte da caché, etc., se, por exemplo, se reiniciou a máquina e necesitamos dalgún xeito facer solicitudes de servizo. Simplemente conservamos unha caché de fotos de copia de seguridade en cada sitio, que actúa como substituto de calquera máquina que estea actualmente sen funcionar. E se de súpeto un dos nosos servidores non está dispoñible, o tráfico vai aí. Por suposto, non temos ningún caché alí, é dicir. fai frío, pero polo menos estase procesando as solicitudes dos usuarios. Se este é un intervalo curto, entón experimentámolo con total tranquilidade. Só hai máis carga no almacenamento. Se este intervalo é longo, xa podemos tomar unha decisión: eliminar este servidor do mapa ou non ou substituílo por outro.
Trátase do sistema de caché. Vexamos os resultados.
Parece que aquí non hai nada complicado. Pero este método de xestionar a caché deunos unha taxa de trucos de preto do 98%. Eses. Desas 80 mil solicitudes por segundo, só 1600 chegan ao almacenamento, e esta é unha carga completamente normal, soportan con calma, sempre temos reserva.
Colocamos estes servidores en tres dos nosos DC e recibimos tres puntos de presenza: Praga, Miami e Hong Kong.
Iso. localízanse máis ou menos localmente en cada un dos nosos mercados obxectivo.
E como un bo extra, temos este proxy de caché, no que a CPU está realmente inactiva, porque non é tan necesario para servir contido. E alí, usando NGINX + Lua, implementamos moita lóxica utilitaria.
Por exemplo, podemos experimentar con webp ou jpeg progresivo (son formatos modernos eficaces), ver como afecta ao tráfico, tomar algunhas decisións, habilitalo para determinados países, etc.; fai un redimensionamento dinámico ou recorta fotos sobre a marcha.
Este é un bo caso de uso cando, por exemplo, tes unha aplicación móbil que mostra fotos e a aplicación móbil non quere desperdiciar a CPU do cliente solicitando unha foto grande e despois redimensionándoa a un determinado tamaño para empurrala o punto de vista. Podemos simplemente especificar de forma dinámica algúns parámetros no URL condicional de UPort e a caché de fotos cambiará o tamaño da propia foto. Por regra xeral, seleccionará o tamaño que teñamos fisicamente no disco, o máis parecido posible ao solicitado, e vendelo en coordenadas concretas.
Por certo, puxemos a disposición do público as gravacións de vídeo dos últimos cinco anos da conferencia de desenvolvedores de sistemas de alta carga . Mira, aprende, comparte e subscríbete .
Tamén podemos engadir moita lóxica de produto alí. Por exemplo, podemos engadir diferentes marcas de auga mediante parámetros URL, podemos desenfocar, difuminar ou pixelar fotos. Isto é cando queremos mostrar unha foto dunha persoa, pero non queremos mostrar a súa cara, isto funciona ben, está todo implementado aquí.
Que conseguimos? Temos tres puntos de presenza, unha boa taxa de trucos e, ao mesmo tempo, non temos CPU inactiva nestas máquinas. Agora volveuse, por suposto, máis importante que antes. Necesitamos darnos coches máis fortes, pero paga a pena.
Trátase da devolución de fotografías. Aquí todo é bastante claro e obvio. Creo que non descubrín América, case calquera CDN funciona deste xeito.
E, moi probablemente, un oínte sofisticado pode ter unha pregunta: por que non cambia todo a CDN? Sería case o mesmo; todos os CDN modernos poden facelo. E hai unha serie de razóns.
O primeiro son as fotografías.
Este é un dos puntos clave da nosa infraestrutura, e necesitamos o maior control posible sobre ela. Se este é algún tipo de solución dun provedor de terceiros e non tes poder sobre ela, será bastante difícil vivir con ela cando tes un gran conxunto de datos e cando tes un fluxo moi grande. de solicitudes dos usuarios.
Déixame un exemplo. Agora, coa nosa infraestrutura, podemos, por exemplo, en caso de algún problema ou golpes subterráneos, ir á máquina e meterse por alí, relativamente falando. Podemos engadir a colección dalgunhas métricas que só necesitamos, podemos experimentar dalgún xeito, ver como isto afecta aos gráficos, etc. Agora estanse recompilando moitas estatísticas sobre este clúster de caché. E periódicamente mirámolo e pasamos moito tempo explorando algunhas anomalías. Se fose do lado da CDN, sería moito máis difícil de controlar. Ou, por exemplo, se se produce algún tipo de accidente, sabemos o que pasou, sabemos como convivir con el e como superalo. Esta é a primeira conclusión.
A segunda conclusión tamén é bastante histórica, porque o sistema estivo desenvolvendo durante moito tempo e había moitos requisitos comerciais diferentes en diferentes etapas, e non sempre encaixan no concepto CDN.
E o punto que segue do anterior é
Isto débese a que nos cachés de fotos temos moita lóxica específica, que non sempre se pode engadir previa solicitude. É pouco probable que calquera CDN che engada algunhas cousas personalizadas cando o solicites. Por exemplo, cifrar URL se non queres que o cliente poida cambiar algo. Queres cambiar o URL do servidor e cifralo e, a continuación, enviar algúns parámetros dinámicos aquí.
Que conclusión suxire isto? No noso caso, a CDN non é unha alternativa moi boa.
E no teu caso, se tes algún requisito comercial específico, podes implementar facilmente o que che mostrei. E isto funcionará perfectamente cun perfil de carga similar.
Pero se tes algún tipo de solución xeral e a tarefa non é moi específica, podes tomar un CDN con total seguridade. Ou se o tempo e os recursos son máis importantes para ti que o control.
E as CDN modernas teñen case todo o que che contei agora. Coa excepción de máis ou menos algunhas características.
Trátase de regalar fotos.
Avancemos agora un pouco na nosa retrospectiva e falemos de almacenamento.
2013 estaba pasando.
Engadíronse servidores de caché, os problemas de rendemento desapareceron. Todo está ben. O conxunto de datos está crecendo. A partir de 2013, tiñamos uns 80 servidores conectados ao almacenamento e uns 40 de almacenamento en caché en cada DC. Trátase de 560 terabytes de datos en cada DC, é dicir. aproximadamente un petabyte en total.
E co crecemento do conxunto de datos, os custos operativos comezaron a aumentar significativamente. Que significaba isto?
Neste diagrama que se debuxa -cunha SAN, con máquinas e cachés conectados a ela- hai moitos puntos de fallo. Se xa nos ocuparamos do fallo dos servidores de caché, todo era máis ou menos previsible e comprensible, pero no lado do almacenamento todo era moito peor.
En primeiro lugar, a propia rede de área de almacenamento (SAN), que pode fallar.
En segundo lugar, está conectado mediante óptica ás máquinas finais. Pode haber problemas coas tarxetas ópticas e as bujías.
Por suposto, non hai tantos como o propio SAN, pero, con todo, tamén son puntos de falla.
A continuación está a propia máquina, que está conectada ao almacenamento. Tamén pode fallar.
En total, temos tres puntos de fracaso.
Ademais, ademais dos puntos de fallo, hai un gran mantemento do propio almacenamento.
Este é un sistema complexo de varios compoñentes e os enxeñeiros de sistemas poden ter dificultades para traballar con el.
E o último, o máis importante. Se se produce un fallo nalgún destes tres puntos, temos unha posibilidade distinta de cero de perder os datos do usuario porque o sistema de ficheiros pode fallar.
Digamos que o noso sistema de ficheiros está roto. En primeiro lugar, a súa recuperación leva moito tempo; pode levar unha semana cunha gran cantidade de datos. E en segundo lugar, ao final o máis probable é que acabemos cunha morea de ficheiros incomprensibles que haberá que combinar dalgún xeito nas fotos dos usuarios. E corremos o risco de perder datos. O risco é bastante alto. E canto máis frecuentemente se produzan este tipo de situacións, e cantos máis problemas xurdan en toda esta cadea, maior é o risco.
Había que facer algo respecto diso. E decidimos que só necesitamos facer unha copia de seguridade dos datos. Esta é en realidade unha solución obvia e boa. Que fixemos?
Este é o aspecto do noso servidor cando antes estaba conectado ao almacenamento. Esta é unha sección principal, é só un dispositivo de bloque que en realidade representa un soporte para almacenamento remoto mediante óptica.
Acabamos de engadir unha segunda sección.
Colocamos un segundo almacenamento ao seu carón (afortunadamente, non é tan caro en termos de diñeiro) e chamámoslle unha partición de copia de seguridade. Tamén está conectado mediante óptica e está situado na mesma máquina. Pero necesitamos sincronizar dalgún xeito os datos entre eles.
Aquí simplemente facemos unha cola asíncrona preto.
Non está moi ocupada. Sabemos que non temos suficientes rexistros. Unha cola é só unha táboa en MySQL na que se escriben liñas como "necesitas facer unha copia de seguridade desta foto". Con calquera cambio ou carga, copiamos desde a partición principal a unha copia de seguranza usando un traballador asíncrono ou só algún tipo de traballador en segundo plano.
E así sempre temos dúas seccións consistentes. Aínda que falle unha parte deste sistema, sempre podemos cambiar a partición principal cunha copia de seguridade e todo seguirá funcionando.
Pero por iso, a carga lectora aumenta moito, porque... ademais dos clientes que len desde a sección principal, porque primeiro miran a foto alí (aí é máis recente), e despois buscan na copia de seguridade, se non a atoparon (pero NGINX só fai isto), o noso sistema tamén é unha copia de seguridade máis que agora le desde a partición principal. Non é que isto fose un pescozo de botella, pero non quería aumentar a carga, esencialmente, así.
E engadimos un terceiro disco, que é un pequeno SSD, e chamámoslle un búfer.
Como funciona agora.
O usuario carga unha foto no búfer e, a continuación, lánzase un evento á cola indicando que é necesario copiala en dúas seccións. Cópiase e a foto vive no búfer durante algún tempo (por exemplo, un día) e só despois bótase de alí. Isto mellora moito a experiencia do usuario, porque o usuario carga unha foto, como regra xeral, as solicitudes inmediatamente comezan a seguir, ou el mesmo actualizou a páxina e actualizouno. Pero todo depende da aplicación que faga a carga.
Ou, por exemplo, outras persoas ás que comezou a mostrarse envían solicitudes inmediatamente despois desta foto. Aínda non está na caché; a primeira solicitude ocorre moi rapidamente. Esencialmente o mesmo que desde unha caché de fotos. O almacenamento lento non está implicado en todo. E cando un día despois se purga, xa está almacenado na nosa capa de caché ou, moi probablemente, xa ninguén o necesita. Eses. A experiencia do usuario aquí creceu moi ben debido a manipulacións tan sinxelas.
Ben, e o máis importante: deixamos de perder datos.
Digamos que paramos potencialmente perder datos, porque realmente non os perdemos. Pero había perigo. Vemos que esta solución é, por suposto, boa, pero é un pouco como suavizar os síntomas do problema, en lugar de solucionalo por completo. E algúns problemas seguen aquí.
En primeiro lugar, este é un punto de falla na forma do propio host físico no que se executa toda esta maquinaria; non desapareceu.
En segundo lugar, aínda hai problemas coas SAN, o seu pesado mantemento, etc. Non era que fose un factor crítico, pero quería tentar vivir sen el.
E fixemos a terceira versión (de feito, a segunda de feito): a versión de reserva. Que aspecto tiña?
Isto é o que era -
Os nosos principais problemas son o feito de que este é un anfitrión físico.
En primeiro lugar, estamos eliminando SAN porque queremos experimentar, queremos probar só discos duros locais.
Isto xa é 2014-2015, e nese momento a situación cos discos e a súa capacidade nun servidor foi moito mellor. Decidimos por que non probalo.
E entón simplemente tomamos a nosa partición de copia de seguridade e transferímola fisicamente a unha máquina separada.
Así, obtemos este diagrama. Temos dous coches que almacenan os mesmos conxuntos de datos. Realizan copias de seguridade entre si completamente e sincronizan os datos na rede mediante unha cola asíncrona no mesmo MySQL.
Por que isto funciona ben é porque temos poucos rexistros. Eses. se escribir fose comparable á lectura, quizais teriamos algún tipo de sobrecarga de rede e problemas. Hai pouca escritura, moita lectura; este método funciona ben, é dicir. Raramente copiamos fotos entre estes dous servidores.
Como funciona isto, se miras un pouco máis en detalle.
Cargar. O equilibrador simplemente selecciona hosts aleatorios cun par e cárgao nel. Ao mesmo tempo, naturalmente fai controis de saúde e asegúrase de que o coche non se caia. Eses. carga fotos só a un servidor en directo e despois, a través dunha fila asíncrona, cópiase todo ao seu veciño. Coa carga todo é moi sinxelo.
A tarefa é un pouco máis difícil.
Lua axudounos aquí, porque pode ser difícil facer tal lóxica en NGINX de vainilla. Primeiro facemos unha solicitude ao primeiro servidor, miramos se a foto está alí, porque potencialmente podería subirse, por exemplo, a un veciño, pero aínda non chegou aquí. Se a foto está aí, é bo. Dámosllo inmediatamente ao cliente e, posiblemente, cachéo.
Se non está alí, simplemente facemos unha solicitude ao noso veciño e temos a garantía de recibilo dende alí.
Iso. de novo podemos dicir: pode haber problemas co rendemento, porque hai constantes viaxes de ida e volta: a foto foi cargada, non está aquí, estamos facendo dúas solicitudes en lugar dunha, esta debería funcionar lentamente.
Na nosa situación, isto non funciona lentamente.
Recollemos unha morea de métricas neste sistema e a taxa intelixente condicional deste mecanismo é de aproximadamente o 95%. Eses. O atraso desta copia de seguridade é pequeno, e debido a iso temos case garantido, despois de cargar a foto, sacarémola a primeira vez e non teremos que ir dúas veces a ningún sitio.
Entón, que máis temos que sexa realmente xenial?
Anteriormente, tiñamos a partición de copia de seguridade principal e lemos delas secuencialmente. Eses. Sempre buscamos primeiro no principal e despois na copia de seguridade. Foi un movemento.
Agora utilizamos a lectura de dúas máquinas á vez. Distribuímos solicitudes usando Round Robin. Nunha pequena porcentaxe de casos facemos dúas solicitudes. Pero en xeral, agora temos o dobre de lecturas que antes. E a carga reduciuse moito tanto nas máquinas de envío como directamente nas máquinas de almacenamento, que tamén tiñamos naquel momento.
En canto á tolerancia a fallos. En realidade, é polo que loitamos principalmente. Con tolerancia ás fallas, todo resultou xenial aquí.
Un coche avaria.
Sen problema! Un enxeñeiro de sistemas pode nin sequera espertar pola noite, esperará ata a mañá, non pasará nada malo.
Se aínda que esta máquina falla, a cola está fóra de servizo, tampouco hai problemas, o rexistro simplemente acumularase primeiro na máquina viva, e despois engadirase á cola e despois ao coche que entrar en funcionamento despois dun tempo.
O mesmo co mantemento. Simplemente apagamos unha das máquinas, sacámola manualmente de todas as piscinas, deixa de recibir tráfico, facemos algún tipo de mantemento, editamos algo, despois devolvémola en servizo e esta copia de seguridade ponse ao día con bastante rapidez. Eses. por día, o tempo de inactividade dun coche alcanza nun par de minutos. Isto é realmente moi pouco. Con tolerancia ás fallas, digo de novo, aquí todo está ben.
Que conclusións se poden extraer deste esquema de redundancia?
Temos tolerancia ás fallas.
Doado de usar. Dado que as máquinas teñen discos duros locais, isto é moito máis cómodo desde o punto de vista operativo para os enxeñeiros que traballan con el.
Recibimos unha dobre axuda de lectura.
Este é un extra moi bo ademais da tolerancia a fallos.
Pero tamén hai problemas. Agora temos un desenvolvemento moito máis complexo dalgunhas funcións relacionadas con isto, porque o sistema finalmente volveuse coherente ao 100%.
Debemos, digamos, nalgún traballo en segundo plano, pensar constantemente: "¿En que servidor estamos executando agora?", "Hai realmente unha foto actual aquí?" etc. Isto, por suposto, está todo rematado, e para o programador que escribe a lóxica empresarial, é transparente. Pero, con todo, apareceu esta gran capa complexa. Pero estamos preparados para soportar isto a cambio das golosinas que recibimos del.
E aquí de novo xorde algún conflito.
Dixen ao principio que almacenar todo nos discos duros locais é malo. E agora digo que nos gustou.
Si, efectivamente, co paso do tempo a situación cambiou moito, e agora este enfoque ten moitas vantaxes. En primeiro lugar, temos unha operación moito máis sinxela.
En segundo lugar, é máis produtivo, porque non temos estes controladores automáticos nin conexións a estantes de discos.
Hai unha gran cantidade de maquinaria alí, e estes son só algúns discos que se ensamblan aquí na máquina nun ataque.
Pero tamén hai desvantaxes.
Isto é aproximadamente 1,5 veces máis caro que usar SAN, mesmo aos prezos actuais. Por iso, decidimos non converter con audacia todo o noso gran clúster en coches con discos duros locais e decidimos deixar unha solución híbrida.
A metade das nosas máquinas funcionan con discos duros (ben, non a metade, probablemente o 30 por cento). E o resto son coches antigos que antes tiñan o esquema de primeira reserva. Simplemente os montamos, xa que non necesitabamos novos datos nin nada máis, simplemente movemos os soportes dun host físico a dous.
E agora temos un gran stock de lectura, e ampliámolo. Se antes montabamos un almacenamento nunha máquina, agora montamos catro, por exemplo, nun par. E funciona ben.
Fagamos un breve resumo do que logramos, polo que loitamos e se o logramos.
Resultados de
Temos usuarios, ata 33 millóns.
Temos tres puntos de presenza: Praga, Miami, Hong Kong.
Conteñen unha capa de caché, que consiste en coches con discos locais rápidos (SSD), nos que se executan maquinaria sinxela de NGINX, os seus daemons access.log e Python, que procesan todo isto e xestionan a caché.
Se o desexas, estás no teu proxecto, se as fotos non son tan importantes para ti como o son para nós, ou se o control da compensación fronte á velocidade de desenvolvemento e os custos dos recursos vai na outra dirección para ti, podes substituílas con seguridade. cun CDN, os CDN modernos fano ben.
A continuación vén a capa de almacenamento, na que temos grupos de pares de máquinas que se realizan unha copia de seguridade, os ficheiros cópianse de forma asíncrona dunha a outra sempre que cambian.
Ademais, algunhas destas máquinas funcionan con discos duros locais.
Algunhas destas máquinas están conectadas a SAN.
E, por un lado, é máis cómodo de usar e un pouco máis produtivo, por outro, é conveniente en canto a densidade de colocación e prezo por gigabyte.
Esta é unha breve visión xeral da arquitectura do que obtivemos e de como se desenvolveu todo.
Uns cantos consellos máis do capitán, moi sinxelos.
En primeiro lugar, se de súpeto decides que necesitas mellorar con urxencia todo a túa infraestrutura fotográfica, mide primeiro, porque quizais non hai que mellorar nada.
Déixame un exemplo. Temos un grupo de máquinas que envían fotos desde anexos nos chats, e o esquema leva funcionando alí desde 2009 e ninguén o padece. Todo o mundo está ben, a todos gústalles todo.
Para medir, primeiro colga unha morea de métricas, míraas e despois decide con que non estás satisfeito e que hai que mellorar. Para medilo, temos unha ferramenta xenial chamada Pinba.
Permítelle recoller estatísticas moi detalladas de NGINX para cada solicitude e códigos de resposta, e distribución de tempos, o que queira. Ten conexións a todo tipo de sistemas de análise diferentes, e entón podes miralo todo moi ben.
Primeiro medimolo, despois mellorámolo.
Ademais. Optimizamos a lectura con caché, a escritura con fragmentos, pero este é un punto obvio.
Ademais. Se estás comezando a construír o teu sistema, é moito mellor facer fotos como ficheiros inmutables. Porque perde inmediatamente toda unha clase de problemas coa invalidación da caché, como a lóxica debería atopar a versión correcta da foto, etc.
Digamos que cargaches cen, despois xiraches e fai que fose un ficheiro fisicamente diferente. Eses. non hai que pensar: agora aforrarei un pouco de espazo, escribirei no mesmo ficheiro, cambiarei a versión. Isto sempre non funciona ben e provoca moitos dores de cabeza despois.
Seguinte punto. Sobre o cambio de tamaño sobre a marcha.
Anteriormente, cando os usuarios cargaban unha foto, inmediatamente recortabamos un montón de tamaños para todas as ocasións, para diferentes clientes, e estaban todos no disco. Agora abandonamos isto.
Deixamos só tres tamaños principais: pequeno, mediano e grande. Simplemente reducimos todo o resto do tamaño que hai detrás do que se nos pediu en Uport, simplemente facemos a redución e dámosllo ao usuario.
A CPU da capa de caché aquí resulta ser moito máis barata que se rexenerásemos constantemente estes tamaños en cada almacenamento. Digamos que queremos engadir un novo, isto levará un mes: executa un script en todas partes que faría todo isto de forma ordenada, sen destruír o clúster. Eses. Se tes a oportunidade de elixir agora, é mellor facer o menor número de tamaños físicos posibles, pero para que polo menos algunha distribución sexa, por exemplo, de tres. E todo o demais pódese cambiar de tamaño sobre a marcha usando módulos preparados. Agora é todo moi sinxelo e accesible.
E a copia de seguridade asíncrona incremental é boa.
Como demostrou a nosa práctica, este esquema funciona moi ben coa copia atrasada dos ficheiros modificados.
O último punto tamén é obvio. Se a túa infraestrutura non ten estes problemas agora, pero hai algo que pode romper, definitivamente romperase cando se faga un pouco máis. Polo tanto, é mellor pensar niso con antelación e non experimentar problemas con el. Iso é todo o que quería dicir.
contactos
»
»
Este informe é a transcrición dunha das mellores intervencións da conferencia de desenvolvedores de sistemas de alta carga . Queda menos dun mes para a conferencia HighLoad++ 2017.
Xa o temos listo , o horario estase agora a formar activamente.
Este ano seguimos explorando o tema das arquitecturas e a escala:
- / Igor Vasiliev
- / Dmitri Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Tamén usamos algúns destes materiais no noso curso de formación en liña sobre o desenvolvemento de sistemas de alta carga é unha cadea de cartas, artigos, materiais, vídeos especialmente seleccionados. O noso libro de texto xa contén máis de 30 materiais únicos. Conectar!
Fonte: www.habr.com