Prefacio
El componente de búsqueda de usuarios y la plataforma de gestión de registros son una parte importante del servicio push. ElasticSearch (ES para abreviar), como motor de búsqueda distribuido de código abierto, puede cumplir mejor con los requisitos anteriores. Después de muchos años de iteración en el uso de ES, empujo ha acumulado una rica experiencia, especialmente cuando la cantidad de datos sigue aumentando, cómo administrar el clúster, mantener la estabilidad del clúster y optimizar el rendimiento del clúster, hemos realizado muchas prácticas.
Este artículo describirá la evolución de la arquitectura ElasticSearch a partir de tres partes: los desafíos de los grandes clústeres, cómo GProxy admite múltiples clústeres y las condiciones operativas actuales.
Autor | Xiaoyao, director de I + D de la plataforma Itweet e ingeniero sénior de Java Nanyang
01
Descripción general del servicio Push ES
El escenario empresarial de un push usando ES es principalmente agregar, eliminar, modificar y almacenar información de usuario y almacenamiento de registros. Es uno de los servicios centrales que soportan el push, y sus características son:
● Actualización rápida de datos: es necesario actualizar el retrato del usuario y otra información en tiempo real
● Condiciones de consulta complicadas: admite múltiples dimensiones para complementar y complementar, y buscar condiciones combinadas.
● Gran cantidad de datos de consulta: una tarea de envío puede necesitar consultar decenas de millones de datos.
Hay tres razones principales por las que elegimos ES:
● Proporciona un índice casi en tiempo real, el más corto puede buscar el documento escrito en 1 segundo.
● Puede admitir consultas con condiciones complejas y cumplir con nuestras diversas condiciones de búsqueda.
● Las funciones distribuidas pueden cumplir mejor los requisitos de expansión horizontal y alta disponibilidad.
Además, el funcionario del SE y la comunidad son muy activos, y hay muchos productos ecológicos alrededor, y los problemas encontrados básicamente se pueden resolver bien.
02
Desafíos de los grandes clústeres
Evolución del clúster de empuje individual
La figura anterior muestra el proceso de impulsar la evolución del clúster de ES. Una inserción usó ES antes. Al principio, comenzó a usar la versión 0.20.x. En ese momento, el clúster era pequeño. Más tarde, para desplazarse por los resultados de la consulta sin fuente, se separó la fuente de índice y se actualizó a la versión 0.90.x. Luego, el lanzamiento oficial de la versión 1.2.0 que no admite la función de consulta de fuente, llevamos a cabo la fusión de clústeres. Posteriormente, para poder utilizar algunas de las nuevas funciones oficiales, actualizamos a las versiones 1.4.xy 1.5.x.
En este punto, el tamaño del clúster ya es muy grande, es inconveniente actualizar la versión una vez y las nuevas características posteriores no son muy atractivas para nosotros, por lo que no hemos actualizado durante mucho tiempo, saltándonos la versión oficial 2.x. Sin embargo, debido a la gran escala del clúster, comenzaron a aparecer muchos problemas difíciles de resolver. Era necesario dividirlo y actualizarlo, y la versión oficial también se actualizó a la versión 5.x. No admite la actualización de 1.xa 5.x, por lo que consideramos usar la puerta de enlace de datos. Para resolver las dificultades de actualización y reinicio, el clúster también ha evolucionado a la última versión de la arquitectura anterior.
Problemas con grandes grupos
Los grupos grandes también traen muchos problemas. Los siguientes son algunos de los problemas relativamente difíciles que encontramos durante el uso.
● El primer problema es que la memoria JVM tiende a permanecer alta.
La memoria ES ocupa varias partes: memoria de segmento, caché de filtro, caché de datos de campo, cola masiva, búfer de indexación y búfer de estado del clúster. La memoria de segmento crecerá con el crecimiento de los archivos de segmento y no se puede evitar el uso de memoria de un clúster grande.
La caché de filtro y la caché de datos de campo no se utilizan en muchos escenarios, por lo que las deshabilitamos mediante la configuración de parámetros. Bulk Queue y Indexing Buffer son relativamente fijos, la memoria no continuará creciendo y no es necesario ajustar los parámetros. El búfer de estado del clúster era un problema complicado en ese momento. La forma en que configuramos la asignación fue configurar el archivo default_mapping.json en el directorio de configuración. Este archivo coincidiría con todos los documentos escritos y realizaría un análisis de formato. Después del procesamiento de ES, estará en la memoria. Se almacena en caché una copia de ParserContext. A medida que aumenta el número de tipos, esta parte del uso de memoria aumentará hasta que se agote. Si el nuevo tipo no está indexado, no aumentará.
Cuando hubo un problema de memoria alta, analizamos su archivo de volcado, como se muestra en la figura siguiente, y descubrimos que fue causado por la ocupación de ParserContext. En ese momento, no había una buena manera de resolverlo por completo, y la única forma de borrar el ParserContext reiniciando era liberarlo temporalmente durante un período de tiempo. Sin embargo, con la escritura continua de documentos, esta parte del uso de memoria aumentará nuevamente.
● El segundo problema son los fragmentos de gran tamaño y los segmentos de gran tamaño.
De forma predeterminada, usamos docid como base del enrutamiento y hash de documentos a diferentes fragmentos a través del algoritmo hash. De esta forma, el tamaño de los fragmentos es relativamente uniforme cuando el número de documentos es pequeño, pero cuando el número de documentos aumenta hasta cierto punto, el espacio de tamaño de los fragmentos aumentará. Cuando el tamaño promedio de cada rebanada es de 100 g, la brecha puede alcanzar hasta 20 g. En este momento, el número de segmentos que alcanzan el límite de umbral de segmento máximo también es muy grande, lo que lleva a una fusión de segmentos que consume mucho tiempo.
● El tercer problema es la E / S de disco alta.
A menudo utilizamos el desplazamiento para consultar documentos. Los archivos de segmentos grandes reducirán la eficiencia de la búsqueda en el disco de archivos. Además, la mayor parte de la memoria de la máquina está ocupada por la JVM del nodo ES, lo que dificulta que el sistema de archivos utilice la memoria para almacenar en caché las páginas del archivo de segmentos. Esto hace que la consulta de desplazamiento lea directamente el archivo de disco y el IO esté lleno. Desde el punto de vista de la monitorización, el IO del clúster está básicamente lleno en todo momento.
Además, existen muchos peligros ocultos.
El primero es el cuello de botella de la expansión. El número predeterminado de fragmentos en el clúster era originalmente suficiente. Sin embargo, después de varias expansiones, el número de instancias es igual al número de fragmentos. Después de expandir las instancias, el clúster no asignará fragmentos a otros nuevos. Ejemplo. En segundo lugar, el espacio en disco de la máquina original es gradualmente insuficiente. La marca de agua predeterminada de ES es del 85%, y los fragmentos comenzarán a saltar aleatoriamente después de alcanzarla y es difícil de recuperar.
Entonces es difícil de ajustar. El reinicio y la recuperación son muy lentos. Si actualiza y reconstruye, el índice también es muy lento.
Finalmente, la robustez del clúster también se verá afectada. A medida que aumenta la cantidad de documentos, la presión aumentará y es más probable que ocurran fallas. Después de que una instancia falla, la presión se distribuirá a otros nodos y la empresa tendrá percepción.
03
Solución de GProxy
Para los problemas descritos anteriormente, esperamos encontrar una solución que pueda proporcionar las siguientes funciones:
1. Puede actualizar sin problemas la versión del clúster sin afectar el uso comercial durante la actualización
2. Al dividir los clústeres grandes en clústeres pequeños, el negocio se divide y se reduce la presión sobre los clústeres.
3. Proporcione múltiples copias de seguridad en caliente de IDC de los datos del clúster y brinde soporte de capa de datos para múltiples actividades en diferentes lugares
Sin embargo, en la arquitectura anterior, los servicios empresariales acceden directamente al clúster de ES y el acoplamiento es severo, lo que dificulta el cumplimiento de estos requisitos. Por lo tanto, elegimos una arquitectura basada en proxy para aislar los clústeres de almacenamiento y los clústeres de servicios empresariales agregando un proxy de capa intermedia para brindar soporte para una operación y mantenimiento más flexible de los clústeres de almacenamiento.
La imagen de arriba es la arquitectura general de GProxy, que es una arquitectura de tres niveles:
● La capa superior es la capa empresarial, que solo necesita interactuar con el proxy y realizar el descubrimiento de servicios del proxy a través de etcd.
● En el medio está la capa GProxy, que proporciona el reenvío de solicitudes y la administración de clústeres.
● En la parte inferior hay varios clústeres de ES
GProxy contiene varios componentes:
● etcd: una base de datos de almacenamiento de metainformación de alta disponibilidad, que incluye reglas de enrutamiento, información de clúster, direcciones de servicios proxy, tareas de migración, etc.
● SDK: amplía el SDK nativo de ES y encapsula funciones como el descubrimiento de servicios de proxy y fusiona a través de su mecanismo de rastreo.
● Proxy es un servicio de proxy liviano, es muy conveniente expandirlo, puede registrar su dirección en etcd después del inicio
● El tablero es el servicio de administración de todo el clúster y proporciona una interfaz web para facilitar la administración y el monitoreo del clúster por parte del personal de operación y mantenimiento.
● El servicio de migración proporciona funciones de migración entre diferentes clústeres.
Reglas de enrutamiento y descubrimiento de servicios
Con la arquitectura general anterior, hay dos problemas más que resolver:
1. ¿Cómo descubre el servicio empresarial el proxy, es decir, el problema de descubrimiento del servicio?
2. A qué clúster reenvía el proxy la solicitud, es decir, el problema de enrutamiento
Descubrimiento de servicios
etcd es una base de datos distribuida de clave-valor de alta disponibilidad e interactúa a través de http api, que es fácil de operar, por lo que elegimos etcd para realizar el descubrimiento de servicios y el almacenamiento de metadatos.
Proxy es un servicio sin estado. Una vez que se completa el inicio y la inicialización, registra su dirección en etcd. A través del mecanismo de arrendamiento de etcd, el sistema puede monitorear el estado de supervivencia del proxy. Cuando el servicio de proxy es anormal y el contrato de arrendamiento no se puede renovar con regularidad, etcd lo eliminará para evitar que afecte las solicitudes comerciales normales.
El sdk proporcionado por ElasticSearch reserva la interfaz del rastreador y el sdk puede obtener la dirección de back-end a través de la interfaz del rastreador. Hemos implementado la interfaz sniffer, que obtiene regularmente la lista de proxy de etcd, y monitorea el servicio en línea y fuera de línea a través del mecanismo de vigilancia de etcd, y actualiza la lista de conexiones internas a tiempo. El lado empresarial aún puede usar el SDK nativo de la forma original, sin demasiadas modificaciones, solo inyecte los rastreadores en el SDK.
Reglas de enrutamiento
En un escenario empresarial push push, los datos necesarios para cada aplicación push pueden considerarse como un todo, por lo que elegimos enrutar la solicitud de acuerdo con las dimensiones de la aplicación, y los datos necesarios para cada aplicación push se almacenan en un clúster.
La información de enrutamiento se almacena en etcd, y el formato es appid-> clusterName tal correspondencia. Si no existe tal correspondencia, el proxy asignará el appid a un clúster predeterminado.
Cuando se inicia el proxy, extraerá la última tabla de enrutamiento y supervisará los cambios de la tabla de enrutamiento a través del mecanismo de vigilancia de etcd.
El cambio de la relación de enrutamiento se realiza a través de la operación de migración La siguiente es una introducción al proceso de migración.
Proceso de migración
Cada aplicación pertenece a un clúster. Cuando la carga del clúster no está equilibrada, el administrador puede utilizar el servicio de migración para migrar datos entre los clústeres según la dimensión de la aplicación.
El proceso de migración consta de dos pasos: sincronización de datos y modificación de las reglas de enrutamiento. La sincronización de datos necesita sincronizar dos piezas de datos: datos completos y datos incrementales.
1. Los datos completos se exportan a través de la API de desplazamiento de ElasticSearch
2. Debido a que ElasticSearch no proporciona una forma de obtener datos incrementales (similar al protocolo binlog de mysql para lograr la adquisición de datos incrementales), utilizamos la escritura doble de proxy para lograr la adquisición de datos incrementales.
El servicio de migración es responsable de la sincronización de datos y notifica al tablero una vez que se completa la sincronización de datos, y el tablero actualiza la relación de enrutamiento de etcd. El proxy obtiene la nueva relación de enrutamiento a través del mecanismo de vigilancia y actualiza la tabla de enrutamiento interna. En este momento, la nueva solicitud de la aplicación se enrutará al nuevo clúster.
Respaldo en caliente de múltiples datos IDC
En el escenario empresarial real de un push, el push es un servicio de nivel empresarial, que requiere una alta disponibilidad de servicio. En un push, hay varias salas de computadoras para proporcionar servicios externos y cada aplicación pertenece a una sala de computadoras. Para hacer frente a las fallas a nivel de la sala de computadoras, necesitamos realizar una copia de seguridad de datos en caliente de múltiples IDC para que, después de que falle la sala de computadoras, la solicitud del cliente se pueda enrutar a la sala de computadoras que no presenta fallas, para no afectar el uso normal de los clientes.
Usamos las dimensiones del clúster para la copia de seguridad en caliente de datos, y los datos de cada clúster se respaldarán en otra sala de computadoras. Después de recibir la solicitud, el proxy escribe los datos incrementales en el MQ en tiempo real de acuerdo con la información de espera activa del clúster, y el servicio al consumidor en otra sala de computadoras consume continuamente los datos incrementales del MQ y los escribe en el clúster correspondiente. El servicio de panel es responsable de controlar el estado de todas las tareas de copia de seguridad en caliente de IDC.
actuación
Después de introducir una capa intermedia, inevitablemente se producirá una cierta pérdida de rendimiento. La razón por la que elegimos el desarrollo GO es para minimizar la pérdida tanto como sea posible. Los resultados finales de rendimiento son los siguientes:
Como puede verse en la figura anterior, QPS se reduce en aproximadamente un 10%, y el retraso promedio es aproximadamente igual a la suma del retraso promedio de la llamada ES y el propio proxy. Aunque hay una degradación del rendimiento del 10%, brinda capacidades de operación y mantenimiento más flexibles.
Operacion corriente
Después de que el servicio GProxy se puso en línea, la actualización de la versión ES (de 1.5 a 6.4) se completó con éxito y el clúster grande original se dividió en varios clústeres pequeños. Todo el proceso de actualización y división es insensible al lado comercial, y la función de reversión sin pérdidas proporcionada por GProxy puede hacer que la operación sea más segura (la migración de datos debe ser muy cautelosa).
Con el apoyo de GProxy, las operaciones diarias de operación y mantenimiento de ES de DBA, como la optimización de parámetros y el equilibrio de presión entre clústeres, se vuelven más convenientes.
Conclusión
Mediante el uso del lenguaje Go, la empresa desarrolló de forma independiente Gproxy, resolvió con éxito los problemas existentes en el gran clúster ElasticSearch y brindó servicios de almacenamiento de datos estables y confiables para la empresa de nivel superior. Además, GeTui continuará puliendo su propia tecnología, continuará explorando en el campo de la búsqueda y el almacenamiento de datos, continuará expandiendo los escenarios de aplicación de ElasticSearch y compartirá las últimas prácticas sobre cómo garantizar una alta disponibilidad de almacenamiento de datos con los desarrolladores.