Esto es por el ingeniero de software senior de Wiz, Sagi Tsofan.
Artículo destacado en coautoría con Amazon Web Technologies.
En Wiz, todo es cuestión de escala. Nuestra plataforma ingiere metadatos y datos de telemetría de decenas de miles de millones de recursos en la nube todos los días. Nuestros escáneres sin agentes recopilan una gran cantidad de datos que debemos procesar de manera muy eficiente. A medida que la empresa crece, enfrentamos desafíos importantes sobre cómo mantener y escalar de manera eficiente. En este artículo, describimos los desafíos técnicos y las soluciones para usar Amazon ElastiCache, que no solo mejora la eficiencia de nuestro negocio, sino que también aumenta el valor que creamos para nuestros clientes.
Cuando se lanzó Wiz en 2020, nos propusimos ayudar a los equipos de seguridad a reducir el riesgo de la nube. Hemos recorrido un largo camino en un corto período de tiempo, rompiendo récords de financiación, valoración y ARR, convirtiéndonos en la empresa de software como servicio (SaaS) de más rápido crecimiento de la historia y alcanzando el hito de ARR de 100 millones de dólares.
La plataforma Wiz presenta a los clientes una vista actualizada del estado de su entorno de nube. Esto significa que cada cambio, ya sea la creación de un nuevo recurso en la nube, el cambio de un recurso en la nube existente o la eliminación de un recurso en la nube existente, se reflejará en la plataforma Wiz lo más rápido posible.
La siguiente imagen muestra la vista actual de la cuenta en la nube de un cliente en la plataforma Wiz.
Para brindar esta vista a nuestros clientes, implementamos un escáner sin agente que escanea con frecuencia las cuentas en la nube de nuestros clientes. La tarea principal del escáner es catalogar todos los recursos de la nube que ve en la cuenta de la nube del cliente. Se registrará todo, desde instancias de Amazon Elastic Compute Cloud (Amazon EC2) hasta roles de Amazon Identity and Access Management (IAM) y grupos de seguridad de red de Amazon Virtual Private Cloud (Amazon VPC).
Los resultados del análisis se registrarán en el backend de Wiz y todos estos recursos de la nube se incorporarán a través de la canalización de datos. El siguiente diagrama muestra los pasos de este proceso antes de presentar Amazon ElastiCache.
El oleoducto consta de las siguientes etapas:
El servicio de escáner en la nube se activa según una programación e inicia un nuevo escaneo de la cuenta del cliente.
Este escáner enumera todos los recursos de la nube en la cuenta de nube del cliente y luego publica información sobre esos recursos en Amazon Simple Queue Service (Amazon SQS) a través de un tema de Amazon Simple Notification Service (Amazon SNS).
Luego, el programa de ingesta es responsable de consumir estos mensajes de la cola SQS.
Para cada mensaje, se realiza una llamada a procedimiento remoto (RPC) al componente ejecutor con los metadatos de recursos de la nube relevantes.
Es responsabilidad del ejecutor insertar actualizaciones de recursos de la nube en la base de datos compatible con Amazon Aurora PostgreSQL, actualizando todos los metadatos de los recursos de la nube (incluida su última marca de tiempo vista y el ID de ejecución de escaneo actual), que usaremos más adelante para eliminar los recursos de la nube que ya no aparecen en la cuenta del cliente.
desafío
Los desafíos surgen cuando consideramos la cantidad de clientes, proveedores de nube, cuentas, suscripciones, cargas de trabajo y miles de análisis simultáneos que se ejecutan simultáneamente.
La plataforma Wiz ingiere decenas de miles de millones de actualizaciones de recursos en la nube todos los días. Anteriormente, actualizábamos el registro de cada recurso de la nube después de cada análisis, incluso si el recurso no había cambiado desde el último análisis. Hacemos esto porque necesitamos recordar qué recursos deben eliminarse de la base de datos en el paso 5 actualizando los últimos valores de ID vistos y ejecutados en los registros de recursos. Esto supone una gran carga adicional para nuestra base de datos.
Necesitamos considerar una forma más eficiente de calcular qué recursos de la nube deben eliminarse después de cada escaneo y reducir la cantidad de escrituras en la base de datos.
El siguiente gráfico muestra la cantidad total de recursos en la nube insertados por actualizaciones agrupadas por estado. Para este cliente, el 90 % de los recursos de la nube no han cambiado.
Objetivo
En los últimos meses, hemos implementado un cambio para optimizar nuestro canal de ingesta. Nuestro objetivo principal es reducir significativamente la cantidad de escrituras en bases de datos evitando actualizaciones mientras los recursos de la nube permanecen sin cambios. Esto nos ayuda a lograr los siguientes objetivos:
Elimina la presión de la base de datos, lo que mejorará el rendimiento de las consultas y reducirá la latencia de las consultas.
Reduzca el uso de ID de transacciones de PostgreSQL y reduzca la frecuencia de vacío automático para evitar reversiones de ID de transacciones
Reduzca el uso de CPU, lectura, escritura, rendimiento y IO
Dimensione adecuadamente su tipo de instancia de base de datos para optimizar costos
Amazon ElastiCache viene a ayudar
Amazon ElastiCache para Redis es un servicio de tecnología de nube de Amazon totalmente administrado. Es un servicio de almacenamiento en caché en memoria seguro y altamente escalable que admite las aplicaciones más exigentes que requieren tiempos de respuesta inferiores a milisegundos. También proporciona seguridad integrada, respaldo y recuperación, y replicación entre regiones.
Decidimos aprovechar las capacidades integradas de Redis y el soporte nativo del lado del servidor para estructuras de datos para almacenar y calcular los recursos de la nube que deben eliminarse después de cada ejecución del escáner.
Descubrimos que podíamos lograr esto utilizando el modelo de datos Set, que es una colección desordenada de cadenas únicas a las que se pueden agregar o eliminar datos, o comparar con otras colecciones.
Cada vez que el escáner observa un recurso en la nube, agrega (usando el comando SADD) su identificador único a la colección de ejecución de escaneo actual, de modo que cada ejecución de escaneo complete su propia clave de colección, que eventualmente contendrá la ejecución de escaneo actual. Todos los ID de recursos de nube observados. durante el periodo.
Cuando se completa el escáner y se calcula qué recursos de la nube deben eliminarse, lo comparamos (usando el comando SDIFF) con el conjunto anterior de ejecuciones de escaneo. El resultado de esta comparación es un conjunto de ID de recursos en la nube que deben eliminarse de la base de datos. Al utilizar el soporte nativo de ElastiCache para el tipo de datos Set, podemos descargar todo el proceso de comparación desde la base de datos al motor de ElastiCache.
Veamos un ejemplo básico:
Scan 13 publica cinco (nuevos) recursos de la nube en la colección: A, B, C, D y E
Scan 14 publica cuatro recursos en la nube (algunos nuevos, algunos existentes) en colecciones: A, B, G y H
La diferencia entre estos dos escaneos será C, D y E, lo que significa que estos son los recursos de la nube que deben eliminarse de la base de datos porque ya no existen.
Se completará una colección en Redis como se muestra a continuación. En esta publicación, explicamos cómo completar y comparar colecciones usando la CLI de Redis.
> sadd snapshot_scan_run_13 A B C D E
(integer) 5
> sadd snapshot_scan_run_14 A B G H
(integer) 4
> smembers snapshot_scan_run_13
1) "D"
2) "C"
3) "B"
4) "A"
5) "E"
> smembers snapshot_scan_run_14
1) "H"
2) "B"
3) "G"
4) "A"
> sdiff snapshot_scan_run_13 snapshot_scan_run_14
1) "D"
2) "C"
3) "E"Desliza hacia la izquierda para ver más
Necesitamos agregar dos nuevos pasos al proceso de ingesta (que se muestran en rojo en la imagen a continuación):
El escáner completa los ID de recursos de la nube observados en colecciones en ElastiCache
El ejecutor inserta actualizaciones de recursos de la nube en la base de datos solo si identificamos cambios reales en los recursos de la nube desde el último análisis.
El esquema resultante ahora se parece a la siguiente figura.
Una vez que el escáner completa el descubrimiento de la cuenta, envía un mensaje de "listo" a través de Amazon SNS y Amazon SQS. Luego, el ejecutor comienza a calcular la diferencia entre los escaneos usando el comando SDIFF en Redis y luego elimina la ID resultante de la base de datos. La siguiente figura muestra la arquitectura del proceso de eliminación.
resultado
Tan pronto como implementamos todo el cambio en producción, vimos una mejora en la base de datos de inmediato. El uso de CPU y memoria se ha reducido significativamente, lo que nos permite dimensionar adecuadamente nuestras instancias de base de datos.
¡Ahora el 90% de los recursos de la nube se omitirán y no se escribirán en la base de datos en absoluto!
También observamos una reducción correspondiente en IO y costo después de realizar los cambios, como se muestra en el siguiente gráfico del servicio de administración de costos Amazon Cost Explorer.
Desafíos y lecciones aprendidas
Durante este importante cambio de infraestructura, nos enfrentamos a muchos desafíos, la mayoría de los cuales eran problemas de escala.
rebanada lógica
Nuestros escáneres enumeran cientos de millones de recursos de la nube por escaneo. Cada colección de Redis puede contener hasta 4 mil millones de artículos. Sin embargo, ejecutar el comando SDIFF en dos colecciones muy grandes consume mucha CPU y memoria. En nuestro ejemplo, ejecutar SDIFF en una colección con demasiadas entradas provocó que nuestro flujo de trabajo expirara antes de que pudiera completarse la comparación.
Siguiendo una recomendación del equipo de servicio de ElastiCache, decidimos fragmentar lógicamente nuestras colecciones. En lugar de utilizar una colección enorme con cientos de millones de entradas, aprovechamos la naturaleza distribuida de ElastiCache para dividirla en colecciones más pequeñas, cada una de las cuales contiene una parte del ID del recurso de la nube. El equipo de servicio de ElastiCache recomienda que no introduzcamos más de 1,5 millones de entradas en cada colección. Esto proporciona un tiempo de ejecución aceptable para nuestra carga de trabajo.
El proceso de eliminación ahora requiere fusionar varios conjuntos de fragmentos y calcular sus diferencias. El siguiente diagrama muestra la estructura de la colección fragmentada en ElastiCache: dos iteraciones de escaneo, donde cada escaneo fragmenta los ID de recursos de la nube observados en múltiples colecciones.
Ahora, debemos garantizar que siempre comparamos el mismo conjunto de fragmentos y almacenamos cada recurso de la nube en el mismo fragmento. De lo contrario, nuestra comparación daría como resultado resultados de diferenciación corruptos, lo que conduciría a una eliminación innecesaria de recursos de la nube. Hacemos esto calculando de manera determinista un fragmento para cada recurso de la nube.
Modo de clúster habilitado
Dado que escaneamos mucho, también tenemos muchas colecciones, cada una de las cuales contiene millones de elementos. No es posible incluir tanta información en un nodo de ElastiCache porque alcanzaremos el tamaño máximo de memoria muy rápidamente.
Necesitábamos una forma de distribuir la colección entre diferentes fragmentos y poder expandir la memoria de vez en cuando sin cambiar el tipo de clase de instancia de ElastiCache.
Hemos decidido migrar a ElastiCache con el modo de clúster (CME) habilitado, lo que nos permite agregar fácilmente nuevos fragmentos al clúster cuando necesitamos más memoria.
El proceso de migración del "modo de clúster deshabilitado" al "modo de clúster habilitado" incluye el uso de la nueva biblioteca SDK y el etiquetado de claves de caché para controlar la ubicación de los grupos de claves dentro del mismo fragmento.
tubería
Las canalizaciones de Redis se utilizan para mejorar el rendimiento al ejecutar varios comandos a la vez sin esperar una respuesta de cada comando individual.
Empleamos un mecanismo de canalización para almacenar y agrupar comandos durante los análisis que se envían a ElastiCache para reducir los viajes de ida y vuelta entre el cliente y el servidor.
Esto nos permite reducir la cantidad de operaciones realizadas en el clúster de ElastiCache por segundo.
Resumir
Al agregar ElastiCache delante de la base de datos Amazon Aurora PostgreSQL Compatible Edition, mejoramos el rendimiento general de la aplicación, redujimos el estrés en la base de datos, pudimos dimensionar adecuadamente la instancia de la base de datos y ahorramos el TCO mientras escalamos y manejamos más carga de clientes.
Usamos ElastiCache para eliminar las actualizaciones masivas de la base de datos antes de almacenar los resultados finales en una versión de la base de datos compatible con Amazon Aurora PostgreSQL. En el proceso, aprovechamos las fortalezas de cada motor de base de datos. Redis es una gran herramienta para almacenar datos de alta velocidad, mientras que PostgreSQL es mejor para el almacenamiento y análisis a largo plazo.
ElastiCache es un componente clave en nuestro proceso de ingesta. Nos permite escalar significativamente para poder manejar más escaneos e ingesta de recursos en la nube. Al hacer esto, logramos mejorar el rendimiento de la base de datos, reducir los tipos de instancias y reducir los costos generales en un 30 % (incluidos los costos de ElastiCache). Además, hemos reducido aún más los costos utilizando los nodos reservados de ElastiCache.
URL original:
https://aws.amazon.com/blogs/database/how-wiz-used-amazon-elasticache-to-improve-dance-and-reduce-costs/
El autor de este artículo.
Sagi Tsofan es ingeniero de software en el equipo de ingeniería de Wiz y se centra en la infraestructura de productos y las áreas de escalamiento. Tiene más de 15 años de experiencia en la construcción de sistemas distribuidos a gran escala y tiene un profundo conocimiento y una amplia experiencia en el desarrollo y la construcción de soluciones altamente escalables para empresas como Wiz, Wix, XM Cyber e IDF. Cuando no está frente a la pantalla, le gusta jugar tenis, viajar y pasar tiempo con amigos y familiares.
Tim Gustafson es el arquitecto jefe de soluciones de bases de datos en Amazon Cloud Technologies y se centra en el motor de base de datos de código abierto y Aurora. Cuando no ayuda a los clientes con bases de datos en Amazon Website Service, le gusta dedicar tiempo a desarrollar sus propios proyectos en Amazon Website Service.
He oído, haz clic en los 4 botones siguientes
¡No encontrarás errores!
