Otra arquitectura de clúster de procesamiento de imágenes en la nube
Nota del editor: Intercambio de arquitectura de alta disponibilidad y difusión de artículos con significado típico en el campo de la arquitectura Este artículo es compartido por Huang Huipan en el grupo de arquitectura de alta disponibilidad. Indique que es de la cuenta pública del marco de alta disponibilidad "ArchNotes".
Huang Huipan, CTO de la nube nuevamente. Comenzó a trabajar en el desarrollo web en 2001; fundó yo2.cn (plataforma de blogs de WordPress) en 2006; se unió a YouPaiyun en 2010 y comenzó a construir la primera generación de almacenamiento en la nube y servicios CDN en la nube. Anteriormente se dedicaba al trabajo de front-end, back-end y del lado del servidor, actualmente se dedica principalmente al trabajo de arquitectura técnica.
Los servicios de procesamiento en la nube de Another Shooting Cloud incluyen servicios de procesamiento de imágenes, audio y video. El sistema de procesamiento de imágenes procesa más de 3.000 imágenes por segundo y procesa alrededor de 100 millones de imágenes al día. Los servicios de procesamiento de imágenes se dirigen a los clientes principalmente en dos categorías: comercio electrónico y socialización de imágenes. También son grandes consumidores con necesidades de procesamiento de imágenes. Otros tipos de clientes tienen menos demanda de procesamiento de imágenes.
Elija una arquitectura de sistema adecuada para el escenario empresarial
Hoy no hablaremos de productos específicos, solo de la arquitectura del sistema.Muchas personas están preocupadas por el rendimiento de elegir GraphicsMagick, ImageMagick o codificación suave o codificación dura en el campo del procesamiento de imágenes. Estos programas tienen sus propias ventajas y desventajas y deben seleccionarse de acuerdo con los escenarios comerciales.
Dado que Paiyun es un servicio de procesamiento de nube pública, requiere una amplia gama de escenarios de uso y funciones de dibujo. Marca de agua, difuminado, adición de efectos especiales, etc., por lo que la codificación suave es la única opción.
Para las empresas que solo requieren la función de miniatura, debe estar codificada con alto rendimiento.
Tome otra escala y arquitectura de clúster de procesamiento de imágenes en la nube
Tamaño del grupo de procesamiento de imágenes
30 servidores con 24 núcleos y 48 G de memoria equivalen a 30 * (24-1) = 690 núcleos de potencia de procesamiento.
Este es nuestro sistema de monitoreo de ojo de perro, que monitorea indicadores clave como QPS y el tiempo de procesamiento promedio para cada subservicio de la plataforma. La figura anterior son las estadísticas de QPS del grupo de mapeo, y la capacidad de procesamiento y el rendimiento son muy estables.
Estructura actual
Se implementan 8 conjuntos de nginx en el front-end para el equilibrio de carga de la capa 7. LVS no se usa para el equilibrio de carga de la capa 4. Como no hay cuello de botella en nginx en este escenario, simplemente usamos el método de sondeo de IP y realizamos tolerancia a fallas en el código comercial. .
Configure el upstream de 30 GmServers en Nginx. Entre ellos, 28 son GmServers comunes y los otros 2 son BigGmServers. Este es un rol muy especial, ¿por qué?
Debido a que brindamos servicios de nube pública, no sabemos qué imágenes envían los clientes. Hay varias imágenes GIF, incluso docenas de megabytes. Sin embargo, la proporción de estos gráficos es muy pequeña, muy por debajo del 1%. Entonces, solo implementamos 2 BigGmServers para hacer esta parte de las tareas de procesamiento.
GmServer de desarrollo propio
Las características estratégicas más importantes de GmServer son:
El servidor solo procesa tareas dentro del número de núcleos de CPU al mismo tiempo. Si excede el número, devuelve 502, deje que nginx realice un procesamiento tolerante a fallas y seleccione el siguiente servidor de procesamiento.
Esta estrategia arquitectónica es mucho más importante que qué biblioteca de procesamiento de imágenes elegir.
Porque cuando el número de simultaneidad excede la capacidad de procesamiento de la CPU, el rendimiento general de procesamiento disminuye más severamente. Todos se están apropiando de la CPU. Como resultado, no todos lo están haciendo bien.
GmServer está desarrollado en base a Linux + epoll + GraphicsMagick, que puede procesar imágenes en toda la memoria dentro de un rango controlable, sin E / S de disco.
Para GraphicsMagick en sí, todavía hay mucha lógica de procesamiento que usará la E / S del disco local, colocamos esta parte en / dev / shm.
El servidor tiene una memoria de 48G y solo 23 tareas simultáneas, por lo que definitivamente es suficiente. El procesamiento se basa completamente en la memoria, lo que puede evitar la pérdida de E / S del disco y lograr el mayor rendimiento.
Otro gran problema es corregir el ERROR de GraphicsMagick y agregar nuevas funciones. Debido a que es una nube pública, las imágenes recibidas son variadas, y algunas incluso faltan o están "pervertidas" en gifs comprimidos, que GraphicsMagick puede no reconocer y procesar.
Contamos con personas dedicadas que han estado luchando por esto durante mucho tiempo, y estas correcciones de ERRORES generalmente se envían al funcionario de GraphicsMagick para algunas contribuciones a la comunidad de código abierto.
Por ejemplo, el más importante es la compatibilidad con el formato WebP, que nuestros ingenieros enviaron a GraphicsMagick.
He estado usando GraphicsMagick durante 6 a 7 años y he acumulado mucha tecnología y experiencia en esta área. Si encuentra una imagen especial que no se puede procesar durante el uso, puede contactarnos por correo electrónico para ver si puede ser compatible con: [email protected].
Lógica de programación de tareas detallada
Tarea de procesamiento de imagen a (imagen normal)
Uno de los ocho nginx se selecciona aleatoriamente y luego nginx asigna aleatoriamente la tarea a un GmServer y se completa el procesamiento.
Tarea de procesamiento de imágenes b (imagen grande o GIF grande)
Uno de los ocho nginx se selecciona aleatoriamente y luego nginx asigna aleatoriamente la tarea a un GmServer y devuelve 413 después de procesar un tiempo de espera de 5 segundos. Luego, nginx asigna tareas a BigGmServer.
Este tiempo de espera de 5 segundos es un valor de experiencia muy especial. Se necesitan decenas de milisegundos para procesar imágenes pequeñas y solo 100 milisegundos para una resolución de 2k, por lo que las imágenes de más de 5 segundos son particularmente anormales.
Para garantizar el servicio de procesamiento de la mayoría de las imágenes ordinarias, enviamos esta imagen anormal a BigGmServer para su procesamiento. El tiempo de espera de la tarea configurado por BigGmServer es de 60 segundos.
¿Por qué lanzarlo a BigGmServer? Imagínese el grupo de procesamiento normal, ¿qué pasará si está lleno de imágenes anormales?
Debido a que el balanceo de carga de 7 capas de nginx también es tolerante a fallas, una imagen pervertida no se puede procesar y se probarán otras máquinas. Después de un tiempo, todo el clúster estará ocupado por esta imagen pervertida, por lo que debemos clasificar las tareas para su procesamiento.
(Diagrama esquemático de las tareas a, b, c)
Tarea de procesamiento de imagen c (imagen normal)
Aquí hay una hipótesis: nuestro GmServer solo puede hacer 2 tareas concurrentes (de lo contrario, tengo que dibujar 24 para dibujar), es decir, GmServer no recibirá más tareas en el estado actual. La nueva tarea c devolverá 502, deje que nginx vuelva a seleccionar un GmServer para manejar la tarea. Incluso si el clúster se atraviesa en 20 ms, generalmente se puede procesar el siguiente salto.
Análisis de las ventajas y desventajas de la arquitectura actual
Por lo general, revise el QPS procesado cada semana y preste atención a la proporción de códigos de error que se escupen. Puede determinar con precisión si el clúster está sobrecargado y ampliar la capacidad con anticipación.
Ventajas de la arquitectura actual
El servicio es estable y el negocio no se verá totalmente afectado cuando se sobrecargue.
La arquitectura es simple y universal.
La arquitectura actual es insuficiente
La expansión dinámica no es amigable, porque la arquitectura es demasiado simple, y la complejidad de implementación de la expansión dinámica es mayor porque necesita estar vinculada con nginx. Para hacer esto, necesita configurar el descubrimiento automático y la configuración dinámica de nginx en sentido ascendente, etc. (Por supuesto, esta pieza es fácil de hacer con nginx + Lua).
Docker es muy popular recientemente y también estamos prestando atención a esta tecnología. Después de un análisis completo, planeamos construir una nueva arquitectura para combinar nuestro procesamiento de imágenes y procesamiento de audio y video. Los dos grupos independientes originales se mezclan para mejorar la utilización de recursos.
Nueva dirección arquitectónica en el futuro
En su lugar, Nginx utiliza el ServiceServer desarrollado por él mismo, que implementa la cola de tareas en función de las colas de mensajes. El GmServer anterior se convirtió a GmWorker, que se conectó activamente a la cola de mensajes para procesar tareas.
Las ventajas de esta arquitectura son: Worker es liviano y es fácil realizar una expansión dinámica, porque el servidor no necesita configurar la información del Worker, y el Worker declara proactivamente la identidad y reclama las tareas al servidor cuando se inicia. A continuación, es muy conveniente cooperar con la expansión dinámica de Docker.
Un punto importante aquí es
- ServiceServer puede admitir clústeres de imágenes, procesamiento de audio y video e incluso tareas de solicitud web ordinarias.
- Los trabajadores pueden desplegarse de forma mixta.
- Worker no necesita supervisar el servicio y se puede expandir fácilmente con Docker.
Si desea tomar un atajo, puede considerar la versión nginx Plus del equilibrio de carga de Capa 7 para admitir la función de cola, que también puede lograr este efecto. Pero también existe la mayor desventaja: $ 1900 / independiente / año. Por supuesto, esta solución nginx, al realizar la expansión horizontal de la ventana acoplable, aún no puede escapar del enlace y el descubrimiento automático con nginx.
Pozo encontrado en operación
El clúster en sí nunca ha encontrado grandes problemas, solo algunos pequeños errores lógicos. Sin embargo, en el servicio, existen problemas de invalidación de caché y fallas comerciales, que deben degradarse automáticamente y protegerse adecuadamente.
Primero consulte nuestra estructura de servicio
Diseño de alta disponibilidad cuando falla la caché
Cuando un disco en la caché del centro de datos se daña o falla un servidor, la mayor parte de la caché dejará de ser válida, lo que resultará en un aumento en la cantidad de solicitudes que entran en el servicio de mapas varias veces. El servicio de mapas no puede soportar una presión tan grande, por lo que permitimos que los usuarios reciban 503 códigos de error.
Tenga en cuenta que este código de error debe configurarse con un tiempo de invalidación de caché de al menos 1 minuto para evitar solicitudes de actualización repetidas por parte de los usuarios. Si no establece un tiempo para que el cliente almacene en caché, el código de error 503 no tiene sentido.
El almacenamiento en caché de CDN generalmente no es un problema, ya que es una arquitectura de nodo de caché múltiple distribuida, la cantidad de servidores es demasiado grande, incluso si el disco está roto o el impacto causado por la falla de la máquina es pequeño, no se preocupe.
Diferentes aislamientos de inquilinos y diseño de alta disponibilidad
Pero la otra cosa de la que preocuparse es la solicitud "maliciosa". La malicia mencionada aquí está entre comillas dobles, porque no es el *** real, puede ser causado por un pequeño cambio en el cliente. Por ejemplo, si modifica la configuración de un número de versión en miniatura, esta operación hará que todos los cachés de miniaturas de la versión anterior dejen de ser válidos y el servicio de dibujo debe procesarse nuevamente.
Si es un cliente pequeño, está bien, pero si es un cliente grande como Huahuawang, el problema es muy serio. Normalmente, la capacidad de procesamiento de imágenes de Petal.com ha representado más del 50% del clúster. El repentino aumento de la capacidad de procesamiento en varias docenas de veces afectará definitivamente al servicio de mapas. ¡Un cliente afecta a toda la plataforma!
Por esta razón, hemos agregado un sistema de control de picos específico del cliente a nginx para evitar esta situación y afectar a toda la plataforma.
Optimización y diseño para escenarios específicos
El uso del número de versión en miniatura realmente aporta una gran comodidad a la empresa. Puede cambiar a diferentes formatos de miniatura según las necesidades de la empresa en cualquier momento, y entrará en vigor inmediatamente después de hacer clic con el mouse.
Pero esto también tiene un precio, que es el impacto mencionado anteriormente. Este problema no se puede resolver a la perfección, ya sea que el clúster de dibujos se puede expandir para poder manejarlo sin caché, o puede aceptar errores 503 en algunas imágenes cuando está ocupado.
Sin embargo, tomaremos en consideración el costo y, obviamente, no podemos proporcionar la capacidad máxima de procesamiento, por lo que está obligado a aceptar una cierta cantidad de error. Pero esto también se puede evitar en la medida de lo posible. Por ejemplo, cuando el lado de la aplicación desea cambiar la versión en miniatura, se puede considerar calentar durante un período de tiempo por adelantado, y la escala de grises se puede cambiar para que este pico se pueda equilibrar.
Problemas de seguridad de los servicios en línea de imágenes
Además, algunos proveedores de nube sin experiencia también brindan servicios de mapas en línea, que son más convenientes. Por ejemplo, http://a.com/b.jpg?w=100 puede configurar libremente el tamaño de miniatura deseado a través de los parámetros. Imagínese cuál será el efecto si alguien combina maliciosamente los parámetros de la URL para cepillar su grupo de dibujos.
Como se mencionó anteriormente, si los clientes tienen necesidades similares, es mejor controlar automáticamente la ocupación de recursos por clientes individuales. Solo proporcionamos la función de dibujar a través de parámetros de URL el año pasado. Se recomienda que sea más considerado al crear dicho servicio.
Q & A
-
Hay 8 nginx implementados en el extremo frontal para el equilibrio de carga de 7 capas, y LVS no se usa para el equilibrio de carga de 4 capas aquí. ¿Por qué está tan diseñado?
Huang Huipan: Este no es un problema de rendimiento, es solo una cuestión de desarrollar algunas líneas más de código u operar y mantener una administración LVS más. Estamos en el código comercial, {s1 .... s8} seleccionado al azar. LVS desempeña principalmente el papel de equilibrio de carga, pero en este escenario, la presión de nginx en sí es pequeña y no hay cuello de botella. Por lo tanto, simplemente usamos el método de sondeo de IP y realizamos tolerancia a fallas en el código comercial. -
¿Cuál es la base de datos utilizada para el almacenamiento de imágenes en el back-end?
Huang Huipan: Estamos almacenados en la nube. Se recomienda utilizar la base de datos de clave / valor. -
¿Ha considerado utilizar GPU para el procesamiento de imágenes en el futuro?
Huang Huipan: Como se mencionó anteriormente, nuestros requisitos comerciales son relativamente complejos. El uso de GPU aumentará en gran medida nuestra dificultad e inversión en I + D. El escenario actual con CPU es el más adecuado para nosotros. -
¿Puede comparar brevemente las ventajas y desventajas de GraphicsMagick e ImageMagick?
Huang Huipan: Como puede comprender, gm es una biblioteca básica de im, e im ha realizado una mejor encapsulación funcional en gm. Con un caparazón en capas, el rendimiento es el mejor en gm. -
¿El servicio de imágenes de PAIYun proporciona servicio de OCR?
Huang Huipan: No existe tal plan por el momento. - La arquitectura antigua distingue el tráfico y los servicios según el negocio, que gana en estabilidad. La nueva arquitectura se mezcla y encaja en los negocios. ¿Existe control de flujo y potencia entre sí? ¿El aumento repentino del tráfico de un determinado tipo tendrá un impacto en otro tipo de negocios, o cómo asegurar la estabilidad de cada tipo de negocio?
Huang Huipan: Depende de cómo desarrollemos la parte trabajadora. Cada uno de nuestros Trabajadores estará bloqueado en 1 núcleo de CPU al inicio y no afectará a otros Trabajadores;
Además, hemos tenido en cuenta las ponderaciones de las tareas mencionadas anteriormente y las emergencias de empresas individuales. Primero, se divide en 2 tipos de tareas, 1. Tareas sincrónicas (como procesamiento de imágenes) 2. Tareas asincrónicas. Damos prioridad a las tareas de sincronización e implementamos restricciones de recursos globales para cada cliente individual.
- Nuestro sistema procesa imágenes a través de parámetros, y el lado comercial puede usar enlaces directamente, lo que conduce a la lógica de procesamiento de imágenes en todo momento ¿Cuáles son las soluciones de optimización?
Huang Huipan: Para sus propios servicios internos, puede considerar aumentar las restricciones, como los permisos y la frecuencia de acceso de IP. Si es un proveedor de servicios en la nube, puede consultar mi plan arriba.
Amigos del grupo: puedes encriptar los parámetros e ingresar la marca de tiempo, por un lado, puedes autenticar y verificar el período de validez de la solicitud.
Huang Huipan: Buena idea. De hecho, todavía recomiendo usar el número de versión en miniatura.
Qunyou: ¿Las imágenes procesadas se almacenarán en el disco?
Huang Huipan: Las imágenes procesadas no se guardan en el disco. Pero hay 2 niveles de caché arriba.
- Como se mencionó anteriormente, cuando nginx solicita gm_server, ¿se puede usar el grupo de conexiones en lugar de la práctica mencionada anteriormente?
Huang Huipan: El uso de la agrupación de conexiones provocará una carga desequilibrada. La pérdida de atravesar la piscina es pequeña. Además, si considera la agrupación de conexiones, puede ser mejor utilizar el nuevo modelo de arquitectura anterior, ponerlo en la cola de mensajes y consumirlo por Worker.
9: ¿Está el juicio de tiempo de espera en nginx? A pesar de que se devuelve el código de error, ¿la conversión gm aún está en curso o consumirá recursos?
Huang Huipan: El juicio de tiempo de espera lo realiza gmserver, que es multiproceso y se mata a sí mismo directamente. Si usa nginx para hacerlo, definitivamente enfrentará el problema que dijo, por lo que es necesario desarrollar este gmserver usted mismo.
Este artículo fue planeado por Deng Qiming, poster Tang Duanrong, presentador Liu Yun, editor Hao Yaqi, You Qian y revisor Tim Yang. Si desea discutir más arquitectura de procesamiento de imágenes, siga la cuenta oficial para conocer las oportunidades de unirse al grupo. Indique que es de la cuenta oficial de WeChat del marco de alta disponibilidad "ArchNotes" e incluya el siguiente código QR.
Arquitectura de alta disponibilidad
Cambiando la forma en que se construye Internet
Mantenga presionado el código QR para suscribirse a la cuenta oficial de `` Arquitectura de alta disponibilidad ''