Optimisation du pipeline de données de Threat Stack avec Apache Spark et Amazon EMR

Threat Stack collecte des dizaines de milliards d'événements par jour, ce qui aide les clients à comprendre leur environnement, à identifier les activités indésirables et à améliorer leur posture de sécurité. Ces données proviennent de différents systèmes d’exploitation, conteneurs, API de fournisseurs de cloud et d’autres sources. Plus nous traitons efficacement toutes ces données, plus nous pouvons offrir de valeur aux clients.

Dans cet article, je fournis un peu de contexte sur l’état avant et après du pipeline de données de Threat Stack, ce qui nous a permis d’augmenter la stabilité de notre plateforme et d’améliorer notre efficacité opérationnelle.

Exploitation de la plateforme de données

Threat Stack dispose de systèmes back-end évolutifs et robustes qui gèrent les données à haut débit pour permettre la détection en temps quasi réel des menaces de sécurité. Pour prendre en charge ce flux détaillé de données de sécurité, la plateforme Threat Stack est divisée en de nombreux microservices spécialisés. Cette architecture permet une mise à l'échelle horizontale facile de notre infrastructure de pipeline de données à mesure que notre base de clients augmente et simplifie la résolution des problèmes en segmentant différentes responsabilités de traitement de données sur des services dédiés.

L'équipe d'ingénierie Threat Stack anticipe généralement les inefficacités de la plateforme ou les problèmes potentiels d'évolutivité avant qu'ils ne deviennent un problème rencontré par le client. De plus, si un membre de l’équipe d’ingénierie est appelé au milieu de la nuit, nous identifions le problème, proposons un plan d’adaptation et mettons en œuvre une solution. Les interruptions du système ont un coût humain et d’opportunité important, détournant les équipes de nouveaux projets qui offrent une valeur ajoutée au client. Chez Threat Stack, nous prenons au sérieux la santé du système et sa corrélation avec l'impact humain, et faisons de notre mieux pour maintenir notre équipe d'ingénieurs en bonne santé et productive.

L’un de nos domaines d’investissement les plus récents est la plateforme de données Threat Stack, qui permet aux clients et aux utilisateurs internes d’exploiter la télémétrie de sécurité de nouvelles manières intéressantes, telles que le reporting, l’analyse et l’apprentissage automatique.

La plateforme de données se compose d'une couche de stockage et d'un certain nombre de services qui ingèrent, traitent et consomment les données stockées pour alimenter diverses analyses et activer notre fonction de portabilité des données . Grâce à la portabilité des données Threat Stack, les clients peuvent exporter une télémétrie de sécurité riche depuis notre plateforme et la charger dans leurs propres systèmes comme Splunk pour SIEM, Amazon Redshift pour l'entreposage de données ou Amazon S3 Glacier pour l'archivage en profondeur. Certaines de ces données permettent également aux analystes de sécurité de notre programme Cloud SecOps℠ qui travaillent au sein de notre SOC 24h/24 et 7j/7 pour surveiller les environnements des clients et identifier les modèles d'activité suspects.

Dans le cadre de cet article, nous nous concentrerons sur l’aspect portabilité des données de la plateforme de données. La portabilité des données est assurée par un certain nombre de services qui récupèrent et traitent les données de la plateforme de données pour les partitionner par organisation et par temps. Dans le bucket S3 de destination, les données sont organisées par date et par identifiant d’organisation.

Avec l’utilisation croissante de la plate-forme de données et des fonctionnalités qu’elle alimente, nous avons dû repenser certaines parties de notre back-end pour prendre en charge la portabilité des données de Threat Stack. Maintenant que vous en savez un peu plus sur notre façon de travailler et sur les fonctionnalités que nous prenons en charge, examinons l’état de la plateforme avant et après.

Pile de menaces avant Spark

L'itération précédente des applications de traitement utilisait Apache Flink , un moteur de traitement distribué dépendant de la RAM pour les calculs avec état pour le traitement par lots et le traitement par flux. Flink a été choisi car il alimentait déjà d’autres parties de la plateforme pour le streaming de données et l’agrégation de télémétrie. Pour prendre en charge la nouvelle fonctionnalité, nous avons créé un nouveau cluster Flink qui exécutait une seule tâche, qui consommerait une rubrique Apache Kafka, partitionnerait les événements et les écrirait sur S3. Finalement, le cluster s'est développé jusqu'à plus d'une centaine de gestionnaires de tâches Flink et a nécessité une maintenance manuelle importante. Pour vous donner une idée de l’ampleur du traitement que nous prenons en charge, la plateforme Threat Stack gère un demi-million d’événements par seconde. Tous les services de notre back-end doivent prendre en charge ce rythme.

Le cluster d'ingestion exécuté sur Apache Flink a subi plusieurs cycles de réglage des paramètres de parallélisme des étapes, de salage des données d'événements pour obtenir une charge de travail uniformément équilibrée et diverses expérimentations de taille d'instance d'infrastructure. Malheureusement, le cluster a atteint un point où son fonctionnement est devenu de plus en plus coûteux pour notre équipe, ce qui a eu des répercussions sur nos ingénieurs et sur la facture de notre fournisseur de cloud.

Au fil du temps, nous avons commencé à remarquer certains anti-modèles, dont l’un était les échecs en cascade des travailleurs. Lorsqu'un seul travailleur manquait de ressources, il finissait par ne plus répondre, ce qui obligeait le reste des nœuds à traiter davantage de messages de la rubrique Apache Kafka. Les nœuds se sont alors retrouvés à court de ressources, les uns après les autres. Bien que nous ayons conçu des redondances dans le système, les événements de défaillance en cascade ont eu un impact négatif sur les performances et ont nécessité une intervention manuelle des personnes de garde.

En passant, je dois noter qu’Apache YARN n’était pas utilisé pour gérer les ressources du cluster. Apache YARN aurait résolu le problème des pannes en cascade dans les clusters de travail, mais cela n'aurait pas aidé à résoudre les problèmes de coût et d'efficacité des services. Le nombre d’incidents de stabilité de la plateforme attribués à ce service d’ingestion représentait jusqu’à 30 % du total des événements de service par mois.

L’autre face du défi était le coût associé à l’exploitation de l’infrastructure nécessaire pour prendre en charge le service d’ingestion de données. Ce seul service représentait environ 25 % de la facture mensuelle de notre fournisseur de cloud. Elle a également eu un impact humain important, réveillant les individus la nuit et diminuant leur capacité à effectuer leur travail habituel. En raison de la quantité de maintenance et d'interruptions causées par le service, il était temps de procéder à un remplacement et de viser la rapidité, l'évolutivité, la rentabilité et la stabilité.

Passer de Flink à Spark

Nous sommes revenus aux exigences, qui étaient la capacité d'écrire des données d'événements brutes partitionnées par organisation en blocs de temps en vue de leur envoi vers les buckets S3 des clients. Nous n’avions pas besoin des qualités de traitement avec état d’Apache Flink, nous avions juste besoin d’un simple pipeline ETL. Notre équipe d’ingénieurs a déjà expérimenté Apache Spark dans d’autres domaines de notre architecture et a constaté des résultats prometteurs.

Nous avons décidé de porter la logique métier d'Apache Flink vers Apache Spark, exécuté sur Amazon EMR . Ce changement nous a permis d’utiliser des outils standards de l’industrie mieux pris en charge et plus largement adoptés. Avec EMR, nous avons commencé à utiliser le connecteur Hadoop S3 fourni par AWS au lieu de l'implémentation gratuite prise en charge par la communauté. Le passage à un service géré, EMR, au lieu d’exécuter notre propre cluster Apache Flink en interne, a éliminé la majeure partie de la complexité opérationnelle liée au maintien de l’ancien pipeline. De plus, le nouveau pipeline ETL est sans état et ne repose pas sur des points de contrôle ou des écritures intermédiaires qui entraînaient des échecs non détectés dans l'ancien pipeline. De plus, le nouveau pipeline exécute des tâches discrètes à des intervalles courts et prédéfinis, et réessaye complètement des lots entiers en raison d'une défaillance partielle. Par rapport à la façon dont nous travaillions auparavant avec les données en streaming, le traitement est toujours rapide pour nos clients, mais désormais avec la durabilité supplémentaire qu'offre le traitement par micro-lots Spark.