Optimierung der Datenpipeline von Threat Stack mit Apache Spark und Amazon EMR

Threat Stack erfasst täglich zig Milliarden Ereignisse und hilft Kunden so dabei, ihre Umgebung zu verstehen, unerwünschte Aktivitäten zu identifizieren und ihre Sicherheitslage zu verbessern. Diese Daten stammen aus verschiedenen Betriebssystemen, Containern, APIs von Cloud-Anbietern und anderen Quellen. Je effizienter wir all diese Daten verarbeiten, desto mehr Mehrwert können wir unseren Kunden bieten.

In diesem Beitrag gebe ich einige Hintergrundinformationen zum Vorher- und Nachher-Zustand der Datenpipeline von Threat Stack, die es uns ermöglichte, die Stabilität unserer Plattform zu erhöhen und unsere Betriebseffizienz zu verbessern.

Betrieb der Datenplattform

Threat Stack verfügt über skalierbare und robuste Back-End-Systeme, die Daten mit hohem Durchsatz verarbeiten und so eine nahezu Echtzeiterkennung von Sicherheitsbedrohungen ermöglichen. Um diesen detaillierten Strom an Sicherheitsdaten zu unterstützen, ist die Threat Stack-Plattform in viele spezialisierte Mikroservices unterteilt. Diese Architektur ermöglicht eine einfache horizontale Skalierung unserer Daten-Pipelining-Infrastruktur bei wachsendem Kundenstamm und vereinfacht die Fehlerbehebung durch die Segmentierung verschiedener Datenverarbeitungsverantwortlichkeiten auf dedizierte Dienste.

Das Threat Stack-Entwicklungsteam erkennt in der Regel Ineffizienzen der Plattform oder potenzielle Skalierbarkeitsprobleme, bevor diese zu einem Problem für den Kunden werden. Wenn darüber hinaus ein Mitglied des Engineering-Teams mitten in der Nacht angepiept wird , identifizieren wir das Problem, schlagen einen Plan zur Skalierung vor und implementieren eine Abhilfe. Systemunterbrechungen verursachen erhebliche Personal- und Opportunitätskosten und halten Teams von neuen Projekten ab, die zusätzlichen Kundennutzen schaffen. Bei Threat Stack nehmen wir die Systemintegrität und ihren Zusammenhang mit menschlichen Einflüssen ernst und tun unser Bestes, um die Gesundheit und Produktivität unseres Engineering-Teams zu gewährleisten.

Einer unserer neuesten Investitionsbereiche ist die Threat Stack Data Platform, die es Kunden und internen Benutzern ermöglicht, Sicherheitstelemetrie auf spannende neue Weise zu nutzen, beispielsweise für Reporting, Analysen und maschinelles Lernen.

Die Datenplattform besteht aus einer Speicherschicht und einer Reihe von Diensten, die die gespeicherten Daten aufnehmen, verarbeiten und nutzen, um verschiedene Analysen durchzuführen und unsere Datenportabilitätsfunktion zu aktivieren. Mit Threat Stack Data Portability können Kunden umfangreiche Sicherheitstelemetriedaten von unserer Plattform exportieren und in ihre eigenen Systeme laden, beispielsweise Splunk für SIEM, Amazon Redshift für Data Warehousing oder Amazon S3 Glacier für Deep Archiving. Einige dieser Daten ermöglichen es auch den Sicherheitsanalysten in unserem Cloud SecOps Program℠, die unser SOC rund um die Uhr besetzen, Kundenumgebungen zu überwachen und verdächtige Aktivitätsmuster zu erkennen.

Für die Zwecke dieses Beitrags konzentrieren wir uns näher auf den Aspekt der Datenportabilität der Datenplattform. Die Datenportabilität wird von einer Reihe von Diensten betrieben, die Daten von der Datenplattform abrufen und verarbeiten, um sie nach Organisation und Zeit zu partitionieren. Im Ziel-S3-Bucket werden die Daten nach Datum und einer Organisationskennung organisiert.

Angesichts der zunehmenden Nutzung der Datenplattform und der von ihr bereitgestellten Funktionen mussten wir Teile unseres Back-Ends neu gestalten, um die Datenportabilität des Threat Stack zu unterstützen. Nachdem Sie nun ein wenig über unsere Arbeitsweise und die von uns unterstützten Funktionen wissen, schauen wir uns den Zustand der Plattform vorher und nachher an.

Bedrohungsstapel vor Spark

Die vorherige Iteration der Verarbeitungsanwendungen verwendete Apache Flink , eine RAM-abhängige verteilte Verarbeitungs-Engine für zustandsbehaftete Berechnungen für die Stapelverarbeitung und Stream-Verarbeitung. Die Wahl fiel auf Flink, da es bereits andere Teile der Plattform für die Aggregation von Streaming-Daten und Telemetriedaten unterstützte. Zur Unterstützung der neuen Funktion haben wir einen neuen Flink-Cluster erstellt, der einen einzelnen Job ausführte, der ein Apache Kafka-Thema verwendete, die Ereignisse partitionierte und diese in S3 schrieb. Schließlich wuchs der Cluster auf über hundert Flink Task Manager an und erforderte einen erheblichen manuellen Wartungsaufwand. Um Ihnen eine Vorstellung vom Umfang der von uns unterstützten Verarbeitung zu geben: Die Plattform von Threat Stack verarbeitet eine halbe Million Ereignisse pro Sekunde. Alle Dienste in unserem Back-End müssen dieses Tempo unterstützen.

Der auf Apache Flink ausgeführte Ingestion-Cluster durchlief mehrere Optimierungsrunden hinsichtlich der Einstellungen für die Phasenparallelität, der Ereignisdaten-Salting-Funktion zur Erzielung einer gleichmäßig verteilten Arbeitslast und verschiedener Experimente mit der Größe verschiedener Infrastrukturinstanzen. Leider erreichte der Cluster einen Punkt, an dem der Betrieb für unser Team zunehmend teurer wurde, was sowohl unsere Ingenieure als auch die Rechnung unseres Cloud-Anbieters belastete.

Mit der Zeit fielen uns einige Antimuster auf, eines davon waren kaskadierende Worker-Fehler. Wenn einem einzelnen Worker die Ressourcen fehlten, reagierte er irgendwann nicht mehr, was dazu führte, dass die übrigen Knoten weitere Nachrichten vom Apache Kafka-Thema verarbeiten mussten. Dann gingen den Knoten nach und nach die Ressourcen aus. Obwohl wir Redundanzen in das System eingebaut hatten, beeinträchtigten kaskadierende Fehlerereignisse die Leistung und machten manuelle Eingriffe von diensthabenden Personen erforderlich.

Nebenbei bemerkt möchte ich darauf hinweisen, dass Apache YARN nicht zur Verwaltung von Clusterressourcen verwendet wurde. Apache YARN hätte die kaskadierenden Fehler in Cluster-Workern gelöst, aber bei Kosten- und Serviceeffizienzproblemen nicht geholfen. Die Anzahl der Vorfälle bezüglich der Plattformstabilität, die diesem Aufnahmedienst zugeschrieben wurden, machte bis zu 30 % aller Serviceereignisse pro Monat aus.

Die andere Seite der Herausforderung waren die Kosten, die mit dem Betrieb der Infrastruktur zur Unterstützung des Datenaufnahmedienstes verbunden waren. Dieser eine Dienst machte ungefähr 25 % unserer monatlichen Rechnung beim Cloud-Anbieter aus. Auch die Menschen waren stark betroffen: Manche Menschen wachten nachts auf und waren nur noch eingeschränkt in der Lage, ihrer normalen Arbeit nachzugehen. Aufgrund des Wartungsaufwands und der Unterbrechungen, die der Dienst verursachte, war es Zeit für einen Ersatz, wobei Aktualität, Skalierbarkeit, Kosteneffizienz und Stabilität im Vordergrund standen.

Umstellung von Flink auf Spark

Wir gingen zurück zu den Anforderungen, nämlich der Möglichkeit, partitionierte Rohereignisdaten nach Organisation in Zeitblöcke zu schreiben, um sie für den Versand an die S3-Buckets der Kunden vorzubereiten. Wir brauchten nicht die zustandsbehafteten Verarbeitungsqualitäten von Apache Flink, sondern lediglich eine einfache ETL-Pipeline. Unser Entwicklungsteam hat bereits in anderen Bereichen unserer Architektur mit Apache Spark experimentiert und vielversprechende Ergebnisse gesehen.

Wir haben beschlossen, die Geschäftslogik von Apache Flink auf Apache Spark zu portieren, das auf Amazon EMR ausgeführt wird. Durch diese Umstellung konnten wir besser unterstützte und weiter verbreitete Industriestandard-Tools verwenden. Mit EMR haben wir begonnen, den von AWS bereitgestellten Hadoop S3-Connector anstelle der kostenlosen, von der Community unterstützten Implementierung zu verwenden. Durch die Umstellung auf einen verwalteten Dienst, EMR, anstatt unseren eigenen Apache Flink-Cluster intern zu betreiben, wurde der Großteil der betrieblichen Komplexität eliminiert, die mit der Aufrechterhaltung des Betriebs der alten Pipeline verbunden war. Darüber hinaus ist die neue ETL-Pipeline zustandslos und verlässt sich nicht auf Checkpoints oder zwischengeschaltete Schreibvorgänge, die in der alten Pipeline dazu führten, dass Fehler unentdeckt blieben. Darüber hinaus führt die neue Pipeline diskrete Jobs in kurzen, vordefinierten Intervallen aus und wiederholt bei teilweisen Fehlern ganze Stapel vollständig. Im Vergleich zu unserer früheren Arbeitsweise mit Streaming-Daten erfolgt die Verarbeitung für unsere Kunden immer noch zeitnah, jetzt jedoch mit der zusätzlichen Haltbarkeit, die die Spark-Mikro-Batch-Verarbeitung bietet.