Artem Denisov ( , )
Badoo es el sitio de citas más grande del mundo. Actualmente tenemos alrededor de 330 millones de usuarios registrados en todo el mundo. Pero lo que es mucho más importante en el contexto de nuestra conversación de hoy es que almacenamos alrededor de 3 petabytes de fotografías de usuarios. Cada día, nuestros usuarios suben alrededor de 3,5 millones de fotos nuevas y la carga de lectura es de aproximadamente 80 mil solicitudes por segundo. Esto es bastante para nuestro backend y, a veces, surgen dificultades con esto.
Hablaré del diseño de este sistema, que almacena y envía fotografías en general, y lo miraré desde el punto de vista de un desarrollador. Habrá una breve retrospectiva de cómo se desarrolló, donde describiré los principales hitos, pero solo hablaré con más detalle sobre las soluciones que estamos utilizando actualmente.
Ahora comencemos.
Como dije, esta será una retrospectiva y, para comenzar por algún lado, tomemos el ejemplo más común.
Tenemos una tarea común, necesitamos aceptar, almacenar y enviar fotos de usuarios. De esta forma, la tarea es general, podemos usar cualquier cosa:
- almacenamiento en la nube moderno,
- una solución en caja, de la que ahora también hay muchas;
- Podemos configurar varias máquinas en nuestro centro de datos, colocarles discos duros grandes y almacenar fotografías allí.
Históricamente, Badoo, tanto ahora como entonces (en el momento en que estaba apenas en su infancia), vive en sus propios servidores, dentro de nuestros propios DC. Por tanto, esta opción era óptima para nosotros.
Simplemente tomamos varias máquinas, las llamamos "fotos" y obtuvimos un grupo que almacena fotografías. Pero parece que falta algo. Para que todo esto funcione, debemos determinar de alguna manera en qué máquina almacenaremos qué fotos. Y aquí tampoco hay necesidad de abrir Estados Unidos.
Agregamos algún campo a nuestro almacenamiento con información sobre los usuarios. Esta será la clave de fragmentación. En nuestro caso, lo llamamos place_id y este ID de lugar apunta al lugar donde se almacenan las fotos de los usuarios. Hacemos mapas.
En la primera etapa, esto se puede hacer incluso manualmente: decimos que una foto de este usuario con ese lugar aterrizará en dicho servidor. Gracias a este mapa siempre sabemos cuando un usuario sube una foto, dónde guardarla y sabemos desde dónde regalarla.
Este es un esquema absolutamente trivial, pero tiene ventajas bastante significativas. La primera es que es simple, como dije, y la segunda es que con este enfoque podemos escalar horizontalmente fácilmente simplemente entregando autos nuevos y agregándolos al mapa. No necesitas hacer nada más.
Así fue para nosotros durante algún tiempo.
Esto fue alrededor de 2009. Entregaron autos, entregaron...
Y en algún momento empezamos a notar que este esquema tiene ciertas desventajas. ¿Cuales son las desventajas?
En primer lugar, el aforo es limitado. No podemos meter tantos discos duros en un servidor físico como nos gustaría. Y esto se ha convertido en un cierto problema con el tiempo y con el crecimiento del conjunto de datos.
Y segundo. Esta es una configuración atípica de máquinas, ya que dichas máquinas son difíciles de reutilizar en otros grupos; son bastante específicas, es decir. deberían tener un rendimiento débil, pero al mismo tiempo tener un disco duro grande.
Todo esto fue en 2009, pero, en principio, estos requisitos siguen siendo vigentes hoy. Tenemos una retrospectiva, así que en 2009 todo fue completamente malo con esto.
Y el último punto es el precio.
El precio era muy elevado en ese momento y necesitábamos buscar algunas alternativas. Aquellos. Necesitábamos de alguna manera utilizar mejor tanto el espacio en los centros de datos como los servidores físicos en los que se encuentra todo esto. Y nuestros ingenieros de sistemas comenzaron un gran estudio en el que revisaron un montón de opciones diferentes. También analizaron sistemas de archivos agrupados como PolyCeph y Lustre. Hubo problemas de rendimiento y un funcionamiento bastante difícil. Ellos rechazaron. Intentamos montar todo el conjunto de datos a través de NFS en cada automóvil para ampliarlo de alguna manera. La lectura también fue mala, probamos diferentes soluciones de diferentes proveedores.
Y al final nos decidimos por utilizar la llamada Red de Área de Almacenamiento.
Se trata de SHD de gran tamaño que están diseñados específicamente para almacenar grandes cantidades de datos. Son estanterías con discos que se montan en las máquinas de salida óptica final. Eso. Tenemos una especie de grupo de máquinas, bastante pequeño, y estos SHD, que son transparentes a nuestra lógica de envío, es decir. para que nuestro nginx o cualquier otra persona atienda solicitudes de estas fotos.
Esta decisión tenía ventajas obvias. Esto es DHS. Está destinado a almacenar fotografías. Esto resulta más económico que simplemente equipar las máquinas con discos duros.
Segunda ventaja.
Esto es que la capacidad se ha vuelto mucho mayor, es decir. Podemos acomodar mucho más almacenamiento en un volumen mucho más pequeño.
Pero también hubo desventajas que surgieron con bastante rapidez. A medida que crecía el número de usuarios y la carga de este sistema, empezaron a surgir problemas de rendimiento. Y el problema aquí es bastante obvio: cualquier SHD diseñado para almacenar muchas fotografías en un volumen pequeño, por regla general, sufre una lectura intensiva. En realidad, esto es cierto para cualquier almacenamiento en la nube o cualquier otra cosa. Ahora no tenemos un almacenamiento ideal que sea infinitamente escalable, se podría meter cualquier cosa en él y toleraría muy bien las lecturas. Lecturas especialmente casuales.
Como es el caso de nuestras fotos, porque las fotos se solicitan de forma inconsistente y esto afectará mucho a su rendimiento.
Incluso según las cifras actuales, si conseguimos más de 500 RPS para fotos en una máquina a la que está conectado el almacenamiento, los problemas ya empiezan. Y ya fue bastante malo para nosotros, porque el número de usuarios está creciendo y las cosas sólo van a empeorar. Esto debe optimizarse de alguna manera.
Para optimizar, decidimos en ese momento, obviamente, mirar el perfil de carga: qué está sucediendo, en general, qué es necesario optimizar.
Y aquí todo juega a nuestro favor.
Ya lo dije en la primera diapositiva: tenemos 80 mil solicitudes de lectura por segundo con solo 3,5 millones de cargas por día. Es decir, se trata de una diferencia de tres órdenes de magnitud. Es obvio que es necesario optimizar la lectura y está prácticamente claro cómo.
Hay un pequeño punto más. Los detalles del servicio son tales que una persona se registra, carga una foto, luego comienza a mirar activamente a otras personas, como ellos, y se la muestra activamente a otras personas. Luego encuentra pareja o no encuentra pareja, depende de cómo resulte, y deja de usar el servicio por un tiempo. En este momento, cuando lo usa, sus fotos son muy populares: tienen demanda, mucha gente las ve. Tan pronto como deja de hacer esto, rápidamente deja de estar tan expuesto a otras personas como antes, y sus fotos casi nunca son solicitadas.
Aquellos. Tenemos un conjunto de datos muy pequeño. Pero al mismo tiempo hay muchas peticiones para él. Y una solución completamente obvia aquí es agregar un caché.
Un caché con LRU solucionará todos nuestros problemas. ¿Que estamos haciendo?
Agregamos otro relativamente pequeño frente a nuestro gran clúster con almacenamiento, que se llama photocaches. Básicamente, esto es solo un proxy de almacenamiento en caché.
¿Cómo funciona desde dentro? Aquí está nuestro usuario, aquí está el almacenamiento. Todo es igual que antes. ¿Qué añadimos en el medio?
Es solo una máquina con un disco local físico, que es rápido. Esto ocurre, por ejemplo, con un SSD. Y en este disco se almacena algún tipo de caché local.
Cómo se ve? El usuario envía una solicitud de fotografía. NGINX lo busca primero en el caché local. De lo contrario, simplemente pase proxy_pass a nuestro almacenamiento, descargue la foto desde allí y entréguesela al usuario.
Pero éste es muy banal y no está claro qué sucede en su interior. Funciona algo como esto.
El caché se divide lógicamente en tres capas. Cuando digo "tres capas", no significa que exista algún tipo de sistema complejo. No, estos son condicionalmente solo tres directorios en el sistema de archivos:
- Este es un búfer donde van las fotos recién descargadas desde un proxy.
- Se trata de un caché activo que almacena las fotografías solicitadas actualmente de forma activa.
- Y un caché frío, donde las fotos se eliminan gradualmente del caché activo cuando les llegan menos solicitudes.
Para que esto funcione, necesitamos administrar de alguna manera este caché, necesitamos reorganizar las fotos que contiene, etc. Este también es un proceso muy primitivo.
Nginx simplemente escribe en RAMDisk access.log para cada solicitud, en el que indica la ruta a la foto que ha servido actualmente (ruta relativa, por supuesto), y en qué partición se sirvió. Aquellos. puede decir "foto 1" y luego un búfer, un caché activo, un caché frío o un proxy.
Dependiendo de esto, debemos decidir de alguna manera qué hacer con la foto.
Tenemos un pequeño demonio ejecutándose en cada máquina que lee constantemente este registro y almacena estadísticas sobre el uso de determinadas fotografías en su memoria.
Simplemente recolecta allí, guarda los contadores y periódicamente hace lo siguiente. Mueve las fotos solicitadas activamente, para las cuales hay muchas solicitudes, al caché activo, dondequiera que estén.
Las fotos que se solicitan con poca frecuencia y que se solicitan con menos frecuencia se eliminan gradualmente del caché activo al caché frío.
Y cuando nos quedamos sin espacio en el caché, simplemente comenzamos a borrar todo del caché frío de forma indiscriminada. Y por cierto, esto funciona bien.
Para que la foto se guarde inmediatamente al enviarla al búfer, usamos la directiva proxy_store y el búfer también es un disco RAM, es decir. para el usuario funciona muy rápidamente. Esto se refiere a los componentes internos del propio servidor de caché.
La pregunta restante es cómo distribuir las solicitudes entre estos servidores.
Digamos que hay un grupo de veinte máquinas de almacenamiento y tres servidores de caché (así sucedió).
Necesitamos determinar de alguna manera qué solicitudes son para qué fotos y dónde enviarlas.
La opción más común es el Round Robin. ¿O hacerlo por accidente?
Obviamente, esto tiene una serie de desventajas porque estaríamos usando el caché de manera muy ineficiente en tal situación. Las solicitudes llegarán a algunas máquinas aleatorias: aquí estaba almacenada en caché, pero en la siguiente ya no está. Y si todo esto funciona, será muy malo. Incluso con una pequeña cantidad de máquinas en el clúster.
Necesitamos determinar de alguna manera sin ambigüedades a qué servidor enviar cada solicitud.
Hay una manera banal. Tomamos el hash de la URL o el hash de nuestra clave de fragmentación, que está en la URL, y lo dividimos por la cantidad de servidores. ¿Trabajará? Voluntad.
Aquellos. Tenemos una solicitud del 2%, por ejemplo, para algún "example_url" siempre llegará al servidor con el índice "XNUMX" y el caché se eliminará constantemente de la mejor manera posible.
Pero existe un problema con la fragmentación en un esquema de este tipo. Resharding: me refiero a cambiar la cantidad de servidores.
Supongamos que nuestro clúster de almacenamiento en caché ya no puede soportarlo y decidimos agregar otra máquina.
Agreguemos.
Ahora todo es divisible no por tres, sino por cuatro. Por lo tanto, casi todas las claves que solíamos tener, casi todas las URL, ahora viven en otros servidores. Todo el caché quedó invalidado simplemente por un momento. Todas las solicitudes recayeron en nuestro clúster de almacenamiento, falló, falló el servicio y hubo usuarios insatisfechos. No quiero hacer eso.
Esta opción tampoco nos conviene.
Eso. ¿Qué debemos hacer? De alguna manera debemos hacer un uso eficiente del caché, enviar la misma solicitud al mismo servidor una y otra vez, pero ser resistentes a la fragmentación. Y existe esa solución, no es tan complicada. Se llama hash consistente.
¿Cómo se ve?
Tomamos alguna función de la clave de fragmentación y distribuimos todos sus valores en el círculo. Aquellos. en el punto 0, sus valores mínimo y máximo convergen. A continuación, colocamos todos nuestros servidores en el mismo círculo aproximadamente de esta manera:
Cada servidor está definido por un punto y, en consecuencia, el sector que va hacia él en el sentido de las agujas del reloj es atendido por este host. Cuando nos llegan solicitudes, inmediatamente vemos que, por ejemplo, la solicitud A (tiene un hash allí) y es atendida por el servidor 2. Solicitud B - por el servidor 3. Y así sucesivamente.
¿Qué sucede en esta situación durante la reconstrucción?
No invalidamos todo el caché, como antes, y no cambiamos todas las claves, pero cambiamos cada sector una pequeña distancia para que, relativamente hablando, nuestro sexto servidor, que queremos agregar, quepa en el espacio libre, y ahí lo agregamos.
Por supuesto, en tal situación las llaves también se mueven. Pero salen mucho más débiles que antes. Y vemos que nuestras dos primeras claves permanecieron en sus servidores y el servidor de caché cambió solo para la última clave. Esto funciona de manera bastante eficiente y si agrega nuevos hosts de manera incremental, entonces no hay gran problema aquí. Agregas y agregas poco a poco, esperas hasta que el caché se llene nuevamente y todo funcione bien.
La única pregunta sigue siendo las negativas. Supongamos que algún tipo de automóvil está averiado.
Y realmente no querríamos regenerar este mapa en este momento, invalidar parte del caché, etc., si, por ejemplo, la máquina se reiniciara y de alguna manera necesitamos atender las solicitudes. Simplemente mantenemos un caché de fotos de respaldo en cada sitio, que actúa como reemplazo de cualquier máquina que esté actualmente fuera de servicio. Y si de repente uno de nuestros servidores deja de estar disponible, el tráfico se dirige allí. Naturalmente, no tenemos ningún caché allí, es decir. Hace frío, pero al menos se están procesando las solicitudes de los usuarios. Si se trata de un intervalo corto, lo vivimos con total tranquilidad. Simplemente hay más carga en el almacenamiento. Si este intervalo es largo, entonces ya podemos tomar una decisión: eliminar este servidor del mapa o no, o quizás reemplazarlo por otro.
Se trata del sistema de almacenamiento en caché. Veamos los resultados.
Parecería que aquí no hay nada complicado. Pero este método de gestión del caché nos dio una tasa de trucos de aproximadamente el 98%. Aquellos. De estas 80 mil solicitudes por segundo, solo 1600 llegan al almacenamiento, y esta es una carga completamente normal, la soportan tranquilamente, siempre tenemos reserva.
Colocamos estos servidores en tres de nuestros centros de datos y obtuvimos tres puntos de presencia: Praga, Miami y Hong Kong.
Eso. están ubicados más o menos localmente en cada uno de nuestros mercados objetivo.
Y como beneficio adicional, tenemos este proxy de almacenamiento en caché, en el que la CPU está realmente inactiva, porque no es tan necesaria para servir contenido. Y allí, usando NGINX+ Lua, implementamos mucha lógica utilitaria.
Por ejemplo, podemos experimentar con webp o jpeg progresivo (son formatos modernos y eficaces), ver cómo afecta al tráfico, tomar algunas decisiones, habilitarlo para determinados países, etc.; Realice cambios de tamaño dinámicos o recorte fotografías sobre la marcha.
Este es un buen caso de uso cuando, por ejemplo, tienes una aplicación móvil que muestra fotos y la aplicación móvil no quiere desperdiciar la CPU del cliente solicitando una foto grande y luego cambiando su tamaño a un tamaño determinado para poder insertarla en la vista. Simplemente podemos especificar dinámicamente algunos parámetros en la URL condicional de UPort y el caché de fotos cambiará el tamaño de la foto. Como regla general, seleccionará el tamaño que tenemos físicamente en el disco, lo más cercano posible al solicitado, y lo venderá a la baja en unas coordenadas concretas.
Por cierto, hemos puesto a disposición del público grabaciones de vídeo de los últimos cinco años de la conferencia de desarrolladores de sistemas de alta carga. . Mira, aprende, comparte y suscríbete .
También podemos agregar mucha lógica de producto allí. Por ejemplo, podemos agregar diferentes marcas de agua usando parámetros de URL, podemos difuminar, desenfocar o pixelar fotografías. Aquí es cuando queremos mostrar una foto de una persona, pero no queremos mostrar su rostro, esto funciona bien, todo está implementado aquí.
¿Qué obtuvimos? Obtuvimos tres puntos de presencia, una buena tasa de trucos y, al mismo tiempo, no tenemos CPU inactiva en estas máquinas. Por supuesto, ahora se ha vuelto más importante que antes. Necesitamos conseguir coches más potentes, pero merece la pena.
Se trata de la devolución de fotografías. Todo aquí es bastante claro y obvio. Creo que no descubrí América, casi cualquier CDN funciona así.
Y, muy probablemente, un oyente sofisticado podría tener una pregunta: ¿por qué no cambiar todo a CDN? Sería más o menos lo mismo; todas las CDN modernas pueden hacer esto. Y hay varias razones.
El primero son las fotografías.
Este es uno de los puntos clave de nuestra infraestructura y necesitamos el mayor control posible sobre él. Si se trata de algún tipo de solución de un proveedor externo y usted no tiene ningún poder sobre ella, le resultará bastante difícil vivir con ella cuando tenga un gran conjunto de datos y un flujo muy grande. de las solicitudes de los usuarios.
Dejame darte un ejemplo. Ahora, con nuestra infraestructura, podemos, por ejemplo, en caso de problemas o golpes subterráneos, ir a la máquina y trastear allí, relativamente hablando. Podemos agregar la colección de algunas métricas que solo necesitamos, podemos experimentar de alguna manera, ver cómo esto afecta los gráficos, etc. Ahora se están recopilando muchas estadísticas sobre este clúster de almacenamiento en caché. Y lo observamos periódicamente y dedicamos mucho tiempo a explorar algunas anomalías. Si estuviera del lado de CDN, sería mucho más difícil de controlar. O, por ejemplo, si ocurre algún tipo de accidente, sabemos qué pasó, sabemos cómo vivir con ello y cómo superarlo. Ésta es la primera conclusión.
La segunda conclusión también es bastante histórica, porque el sistema se ha estado desarrollando durante mucho tiempo y había muchos requisitos comerciales diferentes en diferentes etapas, y no siempre encajan en el concepto de CDN.
Y el punto que se sigue del anterior es
Esto se debe a que en los cachés de fotografías tenemos mucha lógica específica, que no siempre se puede agregar a pedido. Es poco probable que cualquier CDN le agregue algunas cosas personalizadas a su solicitud. Por ejemplo, cifrar las URL si no desea que el cliente pueda cambiar algo. ¿Quiere cambiar la URL en el servidor y cifrarla y luego enviar algunos parámetros dinámicos aquí?
¿Qué conclusión sugiere esto? En nuestro caso, CDN no es una muy buena alternativa.
Y en su caso, si tiene algún requisito comercial específico, puede implementar fácilmente lo que le mostré usted mismo. Y esto funcionará perfectamente con un perfil de carga similar.
Pero si tiene algún tipo de solución general y la tarea no es muy específica, puede tomar una CDN con total seguridad. O si el tiempo y los recursos son más importantes para usted que el control.
Y las CDN modernas tienen casi todo lo que les hablé ahora. Con la excepción de más o menos algunas características.
Se trata de regalar fotografías.
Avancemos ahora un poco en nuestra retrospectiva y hablemos del almacenamiento.
2013 estaba pasando.
Se agregaron servidores de caché y los problemas de rendimiento desaparecieron. Todo esta bien. El conjunto de datos está creciendo. En 2013, teníamos alrededor de 80 servidores conectados al almacenamiento y alrededor de 40 de almacenamiento en caché en cada DC. Se trata de 560 terabytes de datos en cada DC, es decir. alrededor de un petabyte en total.
Y con el crecimiento del conjunto de datos, los costos operativos comenzaron a aumentar significativamente. ¿Qué significó esto?
En este diagrama que se dibuja (con una SAN, con máquinas y cachés conectados a ella) hay muchos puntos de falla. Si ya nos habíamos enfrentado antes al fallo de los servidores de caché, todo era más o menos predecible y comprensible, pero por el lado del almacenamiento todo fue mucho peor.
En primer lugar, la propia red de área de almacenamiento (SAN), que puede fallar.
En segundo lugar, se conecta ópticamente con las máquinas finales. Puede haber problemas con las tarjetas ópticas y las bujías.
Por supuesto, no hay tantos como con el propio SAN, pero, sin embargo, estos también son puntos de falla.
La siguiente es la propia máquina, que está conectada al almacenamiento. También puede fallar.
En total, tenemos tres puntos de fallo.
Además de los puntos de fallo, existe un intenso mantenimiento del propio almacenamiento.
Se trata de un sistema complejo de múltiples componentes y los ingenieros de sistemas pueden tener dificultades para trabajar con él.
Y el último punto, el más importante. Si ocurre una falla en cualquiera de estos tres puntos, tenemos una probabilidad distinta de cero de perder datos del usuario porque el sistema de archivos puede fallar.
Digamos que nuestro sistema de archivos está roto. En primer lugar, su recuperación lleva mucho tiempo: puede llevar una semana con una gran cantidad de datos. Y en segundo lugar, al final lo más probable es que terminemos con un montón de archivos incomprensibles que de alguna manera deberán combinarse en fotografías de usuario. Y corremos el riesgo de perder datos. El riesgo es bastante alto. Y cuanto más a menudo ocurren estas situaciones y más problemas surgen en toda esta cadena, mayor es el riesgo.
Había que hacer algo al respecto. Y decidimos que solo necesitamos hacer una copia de seguridad de los datos. En realidad, esta es una solución obvia y buena. ¿Qué hemos hecho?
Así es como se veía nuestro servidor cuando estaba conectado al almacenamiento antes. Esta es una sección principal, es solo un dispositivo de bloque que en realidad representa un soporte para almacenamiento remoto a través de óptica.
Acabamos de agregar una segunda sección.
Colocamos un segundo almacenamiento al lado (afortunadamente, no es tan caro en términos de dinero) y lo llamamos partición de respaldo. También se conecta mediante fibra óptica y se ubica en la misma máquina. Pero necesitamos sincronizar de alguna manera los datos entre ellos.
Aquí simplemente creamos una cola asincrónica cercana.
Ella no está muy ocupada. Sabemos que no tenemos suficientes registros. Una cola es simplemente una tabla en MySQL en la que se escriben líneas como “necesitas hacer una copia de seguridad de esta foto”. Con cualquier cambio o carga, copiamos desde la partición principal a la copia de seguridad usando un trabajador asíncrono o simplemente algún tipo de trabajador en segundo plano.
Y así siempre tenemos dos secciones consistentes. Incluso si una parte de este sistema falla, siempre podemos cambiar la partición principal con una copia de seguridad y todo seguirá funcionando.
Pero debido a esto, la carga de lectura aumenta mucho, porque... además de los clientes que leen desde la sección principal, porque primero miran la foto allí (es más reciente allí), y luego la buscan en la copia de seguridad, si no la han encontrado (pero NGINX simplemente hace esto), nuestro sistema también es una copia de seguridad adicional que ahora lee desde la partición principal. No es que esto fuera un cuello de botella, pero no quería aumentar la carga, esencialmente, así sin más.
Y agregamos un tercer disco, que es un SSD pequeño, y lo llamamos búfer.
Cómo funciona ahora.
El usuario carga una foto en el búfer y luego se lanza un evento a la cola que indica que debe copiarse en dos secciones. Se copia y la foto permanece en el búfer durante algún tiempo (digamos, un día), y sólo entonces se elimina de allí. Esto mejora enormemente la experiencia del usuario, porque el usuario carga una foto, por regla general, las solicitudes comienzan a seguir inmediatamente o él mismo actualiza la página y la actualiza. Pero todo depende de la aplicación que realiza la carga.
O, por ejemplo, otras personas a las que empezó a mostrarse envían solicitudes inmediatamente después de esta foto. Todavía no está en la memoria caché; la primera solicitud se produce muy rápidamente. Básicamente lo mismo que un caché de fotografías. El almacenamiento lento no tiene nada que ver con esto. Y cuando un día después se elimina, ya está almacenado en caché en nuestra capa de almacenamiento en caché o, lo más probable, ya nadie lo necesita. Aquellos. La experiencia del usuario aquí ha mejorado mucho gracias a manipulaciones tan simples.
Bueno, y lo más importante: dejamos de perder datos.
Digamos que paramos potencialmente Perdemos datos, porque realmente no los perdimos. Pero había peligro. Vemos que esta solución es, por supuesto, buena, pero es un poco como suavizar los síntomas del problema, en lugar de solucionarlo por completo. Y aquí persisten algunos problemas.
En primer lugar, se trata de un punto de fallo en la forma del propio anfitrión físico sobre el que funciona toda esta maquinaria; no ha desaparecido.
En segundo lugar, todavía existen problemas con las SAN, su intenso mantenimiento, etc. No es que fuera un factor crítico, pero quería intentar vivir sin él de alguna manera.
E hicimos la tercera versión (de hecho, la segunda): la versión de reserva. ¿Cómo se veía?
Esto es lo que era -
Nuestros principales problemas son el hecho de que se trata de un host físico.
En primer lugar, estamos eliminando las SAN porque queremos experimentar, queremos probar solo discos duros locales.
Esto ya es 2014-2015, y en ese momento la situación con los discos y su capacidad en un host mejoró mucho. Decidimos por qué no intentarlo.
Y luego simplemente tomamos nuestra partición de respaldo y la transferimos físicamente a una máquina separada.
Así, obtenemos este diagrama. Tenemos dos autos que almacenan los mismos conjuntos de datos. Se respaldan completamente entre sí y sincronizan los datos a través de la red a través de una cola asíncrona en el mismo MySQL.
La razón por la que esto funciona bien es porque tenemos pocos registros. Aquellos. Si la escritura fuera comparable a la lectura, tal vez tendríamos algún tipo de sobrecarga y problemas en la red. Se escribe poco, se lee mucho; este método funciona bien, es decir. Rara vez copiamos fotos entre estos dos servidores.
¿Cómo funciona esto, si miras un poco más en detalle?
Subir. El equilibrador simplemente selecciona hosts aleatorios con un par y los carga. Al mismo tiempo, naturalmente hace controles de salud y se asegura de que el coche no se caiga. Aquellos. sube fotos solo a un servidor en vivo y luego, a través de una cola asincrónica, se copia todo a su vecino. Con la subida todo es extremadamente sencillo.
La tarea es un poco más difícil.
Lua nos ayudó aquí, porque puede ser difícil hacer esa lógica en NGINX básico. Primero hacemos una solicitud al primer servidor, vemos si la foto está allí, porque potencialmente podría cargarse, por ejemplo, a un vecino, pero aún no ha llegado aquí. Si la foto está ahí, está bien. Se lo entregamos inmediatamente al cliente y, posiblemente, lo almacenamos en caché.
Si no está allí, simplemente hacemos una solicitud a nuestro vecino y tenemos la garantía de recibirlo desde allí.
Eso. Nuevamente podemos decir: puede haber problemas con el rendimiento, porque hay constantes ida y vuelta: la foto se cargó, no está aquí, estamos haciendo dos solicitudes en lugar de una, esto debería funcionar lentamente.
En nuestra situación, esto no funciona lentamente.
Recopilamos un montón de métricas sobre este sistema, y la tasa inteligente condicional de dicho mecanismo es de aproximadamente el 95%. Aquellos. El retraso de esta copia de seguridad es pequeño, y debido a esto tenemos casi la garantía de que, una vez cargada la foto, la tomaremos la primera vez y no tendremos que ir a ningún lado dos veces.
Entonces, ¿qué más tenemos que sea realmente genial?
Anteriormente, teníamos la partición de respaldo principal y leíamos de ellas secuencialmente. Aquellos. Siempre buscábamos primero en el principal y luego en el de respaldo. Fue un movimiento.
Ahora utilizamos la lectura desde dos máquinas a la vez. Distribuimos solicitudes mediante Round Robin. En un pequeño porcentaje de los casos hacemos dos solicitudes. Pero en general, ahora tenemos el doble de stock de lectura que antes. Y la carga se redujo mucho tanto en las máquinas de envío como directamente en las máquinas de almacenamiento, que también teníamos en ese momento.
En cuanto a la tolerancia a fallos. En realidad, esto es por lo que luchamos principalmente. Con tolerancia a fallos, aquí todo salió genial.
Un coche se avería.
¡Ningún problema! Es posible que un ingeniero de sistemas ni siquiera se despierte por la noche, esperará hasta la mañana y no sucederá nada malo.
Si incluso si esta máquina falla, la cola está fuera de servicio, tampoco hay problemas, el registro simplemente se acumulará primero en la máquina viva, y luego se agregará a la cola, y luego al automóvil que entrar en funcionamiento después de algún tiempo.
Lo mismo con el mantenimiento. Simplemente apagamos una de las máquinas, la sacamos manualmente de todos los grupos, deja de recibir tráfico, hacemos algún tipo de mantenimiento, editamos algo, luego la volvemos a poner en servicio y esta copia de seguridad se pone al día con bastante rapidez. Aquellos. por día, el tiempo de inactividad de un automóvil se recupera en un par de minutos. Esto es realmente muy poco. Con tolerancia a fallos, repito, aquí todo está bien.
¿Qué conclusiones se pueden sacar de este plan de despidos?
Tenemos tolerancia a fallas.
Fácil de usar. Dado que las máquinas tienen discos duros locales, esto es mucho más conveniente desde el punto de vista operativo para los ingenieros que trabajan con ellas.
Recibimos una asignación de lectura doble.
Esta es una muy buena ventaja además de la tolerancia a fallos.
Pero también hay problemas. Ahora tenemos un desarrollo mucho más complejo de algunas características relacionadas con esto, porque el sistema eventualmente se ha vuelto 100% consistente.
Debemos, digamos, en algún trabajo en segundo plano, pensar constantemente: "¿En qué servidor estamos ejecutando ahora?", "¿Hay realmente una foto actual aquí?" etc. Esto, por supuesto, está todo envuelto, y para el programador que escribe lógica de negocios, es transparente. Pero, sin embargo, ha aparecido esta gran capa compleja. Pero estamos dispuestos a aguantar esto a cambio de los beneficios que recibimos de ello.
Y aquí nuevamente surge algún conflicto.
Dije al principio que almacenar todo en discos duros locales es malo. Y ahora digo que nos gustó.
Sí, de hecho, con el tiempo la situación ha cambiado mucho y ahora este enfoque tiene muchas ventajas. En primer lugar, obtenemos una operación mucho más sencilla.
En segundo lugar, es más productivo porque no tenemos estos controladores automáticos ni conexiones a estantes de discos.
Hay una gran cantidad de maquinaria allí, y estos son solo unos pocos discos que se ensamblan aquí en la máquina en una placa.
Pero hay desventajas.
Esto es aproximadamente 1,5 veces más caro que utilizar SAN, incluso a los precios actuales. Por lo tanto, decidimos no convertir todo nuestro gran grupo en automóviles con discos duros locales y decidimos dejar una solución híbrida.
La mitad de nuestras máquinas funcionan con discos duros (bueno, no la mitad, probablemente el 30 por ciento). Y el resto son coches antiguos que antiguamente tenían el primer esquema de reserva. Simplemente los volvimos a montar, ya que no necesitábamos nuevos datos ni nada más, simplemente movimos los montajes de un host físico a dos.
Y ahora tenemos un gran stock de lectura y lo ampliamos. Si antes montamos un almacenamiento en una máquina, ahora montamos cuatro, por ejemplo, en un par. Y funciona bien.
Hagamos un breve resumen de lo que logramos, por qué luchamos y si lo logramos.
resultados
Tenemos usuarios: hasta 33 millones.
Tenemos tres puntos de presencia: Praga, Miami y Hong Kong.
Contienen una capa de almacenamiento en caché, que consta de automóviles con discos locales rápidos (SSD), en los que se ejecuta maquinaria simple de NGINX, su access.log y los demonios Python, que procesan todo esto y administran el caché.
Si lo desea, está en su proyecto, si las fotos no son tan críticas para usted como lo son para nosotros, o si el equilibrio entre el control y la velocidad de desarrollo y los costos de recursos va en la otra dirección para usted, entonces puede reemplazarlas de manera segura. Con una CDN, las CDN modernas funcionan bien.
Luego viene la capa de almacenamiento, en la que tenemos grupos de pares de máquinas que se respaldan entre sí, los archivos se copian de forma asíncrona de uno a otro cada vez que cambian.
Además, algunas de estas máquinas funcionan con discos duros locales.
Algunas de estas máquinas están conectadas a SAN.
Y, por un lado, es más cómodo de usar y un poco más productivo, por otro lado, es conveniente en cuanto a densidad de colocación y precio por gigabyte.
Esta es una breve descripción de la arquitectura de lo que obtuvimos y cómo se desarrolló todo.
Unos cuantos consejos más del capitán, muy sencillos.
Primero, si de repente decide que necesita mejorar urgentemente todo en su infraestructura fotográfica, mida primero, porque tal vez no sea necesario mejorar nada.
Dejame darte un ejemplo. Tenemos un grupo de máquinas que envían fotos desde archivos adjuntos en chats, y el esquema ha estado funcionando allí desde 2009 y nadie sufre por ello. Todos están bien, a todos les gusta todo.
Para medir, primero cuelgue un montón de métricas, mírelas y luego decida con qué no está satisfecho y qué necesita mejorar. Para medir esto, tenemos una herramienta genial llamada Pinba.
Le permite recopilar estadísticas muy detalladas de NGINX para cada solicitud y códigos de respuesta, y distribución de tiempos, lo que desee. Tiene enlaces a todo tipo de sistemas de análisis diferentes, y luego puedes verlo todo maravillosamente.
Primero lo medimos, luego lo mejoramos.
Más. Optimizamos la lectura con caché y la escritura con fragmentación, pero este es un punto obvio.
Más. Si recién está comenzando a construir su sistema, entonces es mucho mejor crear fotografías como archivos inmutables. Porque inmediatamente se pierde toda una clase de problemas con la invalidación del caché, con cómo la lógica debería encontrar la versión correcta de la foto, etc.
Digamos que subiste cien, luego los giraste y lo convertiste en un archivo físicamente diferente. Aquellos. No hay necesidad de pensar: ahora ahorraré un poco de espacio, lo escribiré en el mismo archivo y cambiaré la versión. Esto no siempre funciona bien y causa muchos dolores de cabeza más adelante.
Siguiente punto. Acerca de cambiar el tamaño sobre la marcha.
Anteriormente, cuando los usuarios subían una foto, inmediatamente recortábamos un montón de tamaños para todas las ocasiones, para diferentes clientes, y todos estaban en el disco. Ahora hemos abandonado esto.
Dejamos solo tres tamaños principales: pequeño, mediano y grande. Simplemente reducimos todo lo demás del tamaño que está detrás del que nos solicitaron en Uport, simplemente hacemos la reducción y se lo damos al usuario.
La CPU de la capa de caché aquí resulta mucho más barata que si regeneramos constantemente estos tamaños en cada almacenamiento. Digamos que queremos agregar uno nuevo, esto tomará un mes: ejecute un script en todas partes que haga todo esto de manera ordenada, sin destruir el clúster. Aquellos. Si tiene la oportunidad de elegir ahora, es mejor hacer la menor cantidad de tamaños físicos posible, pero de modo que al menos una cierta distribución sea, digamos, tres. Y todo lo demás se puede cambiar de tamaño simplemente sobre la marcha utilizando módulos ya preparados. Todo es muy fácil y accesible ahora.
Y la copia de seguridad incremental asíncrona es buena.
Como ha demostrado nuestra práctica, este esquema funciona muy bien con la copia retrasada de archivos modificados.
El último punto también es obvio. Si su infraestructura no tiene tales problemas ahora, pero hay algo que puede romperse, definitivamente se romperá cuando crezca un poco más. Por lo tanto, es mejor pensar en esto con anticipación y no tener problemas con ello. Eso es todo lo que quería decir.
contactos
»
»
Este informe es una transcripción de uno de los mejores discursos en la conferencia de desarrolladores de sistemas de alta carga. . Queda menos de un mes para la conferencia HighLoad++ 2017.
Ya lo tenemos listo , el cronograma ahora se está formando activamente.
Este año continuamos explorando el tema de las arquitecturas y el escalado:
- / Ígor Vasiliev
- / Dmitri Egorov
- / Anatoli Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Felipe Delgado
También utilizamos algunos de estos materiales en nuestro curso de capacitación en línea sobre el desarrollo de sistemas de alta carga. es una cadena de cartas, artículos, materiales y videos especialmente seleccionados. Nuestro libro de texto ya contiene más de 30 materiales únicos. ¡Conectar!
Fuente: habr.com