Optimización del flujo de datos de Threat Stack con Apache Spark y Amazon EMR

Threat Stack recopila decenas de miles de millones de eventos por día, lo que ayuda a los clientes a comprender su entorno, identificar actividades no deseadas y mejorar su postura de seguridad. Estos datos provienen de diferentes sistemas operativos, contenedores, API de proveedor de nube y otras fuentes. Cuanto más eficientemente procesemos todos estos datos, más valor podremos ofrecer a los clientes.

En esta publicación, proporciono algo de contexto sobre el estado antes y después del flujo de datos de Threat Stack, lo que nos permitió aumentar la estabilidad de nuestra plataforma y mejorar nuestra eficiencia operativa.

Operación de la plataforma de datos

Threat Stack cuenta con sistemas back-end escalables y robustos que manejan datos con alto rendimiento para permitir la detección de amenazas de seguridad en tiempo casi real. Para respaldar este flujo detallado de datos de seguridad, la plataforma Threat Stack se divide en muchos microservicios especializados. Esta arquitectura permite un escalamiento horizontal sencillo de nuestra infraestructura de canalización de datos a medida que nuestra base de clientes crece y simplifica la resolución de problemas al segmentar diferentes responsabilidades de procesamiento de datos en servicios dedicados.

El equipo de ingeniería de Threat Stack generalmente se anticipa a las ineficiencias de la plataforma o a los posibles problemas de escalabilidad antes de que se conviertan en un problema para el cliente. Además, si un miembro del equipo de ingeniería recibe una llamada en mitad de la noche, identificamos el problema, proponemos un plan para ampliarlo e implementamos una solución. Las interrupciones del sistema tienen un costo humano y de oportunidad significativo, y desvían a los equipos de nuevos proyectos que brindan valor adicional al cliente. En Threat Stack, tomamos muy en serio la salud del sistema y su correlación con el impacto humano, y hacemos todo lo posible para mantener a nuestro equipo de ingeniería saludable y productivo.

Una de nuestras áreas de inversión más recientes ha sido la Threat Stack Data Platform, que permite a los clientes y usuarios internos aprovechar la telemetría de seguridad en formas nuevas y emocionantes, como informes, análisis y aprendizaje automático.

La plataforma de datos consta de una capa de almacenamiento y una serie de servicios que ingieren, procesan y consumen los datos almacenados para impulsar diversos análisis y habilitar nuestra función de portabilidad de datos . Con Threat Stack Data Portability, los clientes pueden exportar telemetría de seguridad completa desde nuestra plataforma y cargarla en sus propios sistemas como Splunk para SIEM, Amazon Redshift para almacenamiento de datos o Amazon S3 Glacier para archivado profundo. Algunos de estos datos también permiten a los analistas de seguridad de nuestro Programa Cloud SecOps℠, que trabajan en nuestro SOC las 24 horas del día, los 7 días de la semana, monitorear los entornos de los clientes e identificar patrones de actividad sospechosa.

Para los fines de esta publicación, nos centraremos en el aspecto de portabilidad de datos de la plataforma de datos. La portabilidad de datos es operada por una serie de servicios que recuperan y procesan datos de la plataforma de datos para dividirlos por organización y tiempo. En el bucket S3 de destino, los datos se organizan por fecha y un identificador de organización.

Con el uso cada vez mayor de la Plataforma de datos y las características que potencia, necesitábamos rediseñar partes de nuestro back-end para soportar la Portabilidad de Datos de la Pila de Amenazas. Ahora que ya sabes un poco sobre cómo trabajamos y las funciones que admitimos, veamos el estado de la plataforma antes y después.

Pila de amenazas antes de Spark

La iteración anterior de aplicações de procesamiento utilizó Apache Flink , que es un motor de procesamiento distribuido dependiente de RAM para cálculos con estado para procesamiento por lotes y procesamiento de flujo. Se eligió Flink porque ya impulsaba otras partes de la plataforma para la transmisión de datos y la agregación de telemetría. Para respaldar la nueva característica, creamos un nuevo clúster Flink que ejecutaba un solo trabajo, que consumiría un tema de Apache Kafka, dividiría los eventos y los escribiría en S3. Con el tiempo, el clúster creció hasta tener más de cien administradores de tareas Flink y requirió un mantenimiento manual significativo. Para darle una idea de la escala del procesamiento que admitimos, la plataforma de Threat Stack maneja medio millón de eventos por segundo. Todos los servicios de nuestro back-end deben soportar este ritmo.

El clúster de ingesta que se ejecuta en Apache Flink se sometió a varias rondas de ajustes en las configuraciones de paralelismo de etapas, salazón de datos de eventos para lograr una carga de trabajo equilibrada de manera uniforme y varios experimentos de tamaño de instancias de infraestructura. Lamentablemente, el clúster llegó a un punto en el que se volvió cada vez más costoso para nuestro equipo operarlo, lo que afectó tanto a nuestros ingenieros como a nuestra factura del proveedor de la nube.

Con el tiempo, comenzamos a notar algunos antipatrones, uno de los cuales eran las fallas en cascada de los trabajadores. Cuando un solo trabajador se quedaba sin recursos, terminaba dejando de responder, lo que provocaba que el resto de los nodos procesaran más mensajes del tema de Apache Kafka. Los nodos luego fueron quedando sin recursos, uno a uno. Si bien diseñamos redundancias en el sistema, los eventos de falla en cascada afectaron negativamente el rendimiento y requirieron la intervención manual de las personas de guardia.

Aparte de esto, debo señalar que Apache YARN no se utilizó para administrar los recursos del clúster. Apache YARN habría resuelto el problema de las fallas en cascada en los trabajadores del clúster, pero no habría ayudado con las preocupaciones sobre costos y eficiencia del servicio. La cantidad de incidentes de estabilidad de la plataforma que se atribuyeron a este servicio de ingesta representó hasta el 30 % del total de eventos de servicio por mes.

El otro lado del desafío fue el costo asociado con el funcionamiento de la infraestructura para soportar el servicio de ingesta de datos. Este servicio representó aproximadamente el 25% de nuestra factura mensual del proveedor de la nube. También tuvo un gran impacto humano, despertando a las personas por la noche y disminuyendo su capacidad para realizar su trabajo habitual. Debido a la cantidad de mantenimiento e interrupciones causadas por el servicio, era hora de un reemplazo y apuntar a la puntualidad, escalabilidad, rentabilidad y estabilidad.

Pasando de Flink a Spark

Regresamos a los requisitos, que eran la capacidad de escribir datos de eventos sin procesar particionados por organización en bloques de tiempo en preparación para el envío a los buckets S3 de los clientes. No necesitábamos las cualidades de procesamiento con estado de Apache Flink, solo necesitábamos una canalización ETL simple. Nuestro equipo de ingeniería ya ha experimentado con Apache Spark en otras áreas de nuestra arquitectura y ha visto resultados prometedores.

Decidimos portar la lógica empresarial de Apache Flink a Apache Spark, que se ejecuta en Amazon EMR . Este cambio nos permitió utilizar herramientas estándar de la industria con mejor soporte y más ampliamente adoptadas. Con EMR, comenzamos a utilizar el conector Hadoop S3 proporcionado por AWS en lugar de la implementación gratuita respaldada por la comunidad. El cambio a un servicio administrado, EMR, en lugar de ejecutar nuestro propio clúster Apache Flink internamente, eliminó la mayor parte de la complejidad operativa que implicaba mantener en funcionamiento el antiguo pipeline. Además, el nuevo pipeline ETL no tiene estado y no depende de puntos de control ni de escrituras intermedias que provocaban que los fallos no se detectaran en el pipeline anterior. Además, el nuevo pipeline ejecuta trabajos discretos a intervalos cortos y predefinidos, y vuelve a intentar lotes enteros en caso de cualquier falla parcial. En comparación con cómo trabajamos anteriormente con la transmisión de datos, el procesamiento sigue siendo oportuno para nuestros clientes, pero ahora con la durabilidad adicional que brinda el procesamiento de microlotes de Spark.