Apache Spark と Amazon EMR を使用した Threat Stack のデータ パイプラインの最適化

Threat Stack は 1 日あたり数百億のイベントを収集し、顧客が環境を理解し、望ましくないアクティビティを特定し、セキュリティ体制を強化するのに役立ちます。 このデータは、さまざまなオペレーティング システム、コンテナー、クラウド プロバイダー API、およびその他のソースから派生します。 これらすべてのデータを効率的に処理すればするほど、顧客に提供できる価値は高まります。

この記事では、Threat Stack のデータ パイプラインの導入前と導入後の状況について説明します。これにより、プラットフォームの安定性が向上し、運用効率も向上しました。

データプラットフォームの運用

Threat Stack には、高いスループットでデータを処理し、セキュリティの脅威をほぼリアルタイムで検出できる、スケーラブルで堅牢なバックエンド システムがあります。 この詳細なセキュリティ データ ストリームをサポートするために、Threat Stack プラットフォームは多くの特殊なマイクロサービスに分割されています。 このアーキテクチャにより、顧客ベースの拡大に合わせてデータ パイプライン インフラストラクチャを簡単に水平方向に拡張できるようになり、専用サービス間でさまざまなデータ処理責任を分割することで問題のトラブルシューティングが簡素化されます。

Threat Stack エンジニアリング チームは通常、プラットフォームの非効率性や潜在的なスケーラビリティの問題が顧客の問題になる前に、それらを先取りして解決します。 さらに、エンジニアリング チームのメンバーが夜中に呼び出された場合、問題を特定し、拡張計画を提案し、修復を実施します。 システムの中断は大きな人的コストと機会コストを伴い、顧客への追加価値をもたらす新しいプロジェクトからチームを遠ざけてしまいます。 Threat Stack では、システムの健全性と人間への影響との相関関係を真剣に受け止め、エンジニアリング チームの健全性と生産性を維持するために最善を尽くしています。

当社の最新の投資分野の 1 つは、Threat Stack Data Platform です。これにより、顧客と社内ユーザーは、レポート、分析、機械学習などの新しい魅力的な方法でセキュリティ テレメトリを活用できるようになります。

データ プラットフォームは、ストレージ レイヤーと、保存されたデータを取り込んで処理し、消費してさまざまな分析を実行し、データ ポータビリティ機能を有効にする多数のサービスで構成されています。 Threat Stack Data Portability を使用すると、お客様は当社のプラットフォームから豊富なセキュリティテレメトリをエクスポートし、SIEM 用の Splunk、データウェアハウス用の Amazon Redshift、ディープアーカイブ用の Amazon S3 Glacier などの独自のシステムに読み込むことができます。 このデータの一部は、SOC に 24 時間 365 日常駐する Cloud SecOps Program℠ のセキュリティ アナリストが顧客の環境を監視し、疑わしいアクティビティ パターンを特定するためにも使用されます。

この投稿では、データ プラットフォームのデータ ポータビリティの側面に焦点を当てます。 データ ポータビリティは、データ プラットフォームからデータを取得して処理し、組織と時間ごとにデータを分割する多数のサービスによって実行されます。 送信先の S3 バケットでは、データは日付と組織識別子によって整理されます。

データ プラットフォームとそれが実現する機能の利用が増えるにつれ、脅威スタック データの移植性をサポートするためにバックエンドの一部を再設計する必要がありました。 私たちの仕事のやり方とサポートしている機能について少し理解できたので、プラットフォームの前後の状態を見てみましょう。

Spark 以前の脅威スタック

以前の処理アプリケーションでは、バッチ処理とストリーム処理のステートフル計算用の RAM 依存型分散処理エンジンであるApache Flink を使用していました。 Flink が選ばれたのは、ストリーミング データとテレメトリの集約のためにプラットフォームの他の部分をすでに稼働させていたためです。 新しい機能をサポートするために、Apache Kafka トピックを消費し、イベントを分割して S3 に書き出す単一のジョブを実行する新しい Flink クラスターを構築しました。 最終的に、クラスターは 100 を超える Flink タスク マネージャーにまで成長し、大量の手動メンテナンスが必要になりました。 私たちがサポートする処理の規模をご理解いただくために、Threat Stack のプラットフォームは 1 秒あたり 50 万件のイベントを処理します。 バックエンドのすべてのサービスがこのペースをサポートする必要があります。

Apache Flink 上で実行されている取り込みクラスターは、ステージの並列処理設定の調整、均等にバランスのとれたワークロードを実現するためのイベント データのソルティング、およびさまざまなインフラストラクチャ インスタンス サイズの実験を複数回実行しました。 残念ながら、クラスターは、私たちのチームにとって運用コストがますます高くなり、エンジニアとクラウド プロバイダーの請求の両方に負担がかかるようになった段階に達しました。

時間が経つにつれて、私たちはいくつかのアンチパターンに気づき始めました。そのうちの 1 つは、ワーカーの障害が連鎖的に発生することでした。 1 つのワーカーのリソースが不足すると、最終的に応答しなくなり、残りのノードが Apache Kafka トピックからのメッセージをさらに処理することになります。 その後、ノードは 1 つずつリソース不足に陥りました。 システムに冗長性を設計しましたが、連鎖的な障害イベントによりパフォーマンスに悪影響が及び、待機中の担当者による手動介入が必要になりました。

余談ですが、Apache YARN はクラスター リソースの管理に使用されていないことに注意してください。 Apache YARN はクラスター ワーカーの連鎖障害を解決しますが、コストとサービスの効率に関する懸念の解決には役立ちません。 この取り込みサービスに起因するプラットフォーム安定性インシデントの数は、1 か月あたりの総サービス イベントの最大 30% を占めました。

課題のもう 1 つの側面は、データ取り込みサービスをサポートするインフラストラクチャの実行に関連するコストでした。 この 1 つのサービスが、クラウド プロバイダーの月額請求額の約 25% を占めていました。 また、夜間に人々が目覚めたり、通常の業務を遂行する能力が低下したりするなど、人間にも大きな影響がありました。 サービスによって発生するメンテナンスと中断の量を考慮して、交換が必要となり、適時性、拡張性、費用対効果、安定性を目指す必要がありました。

FlinkからSparkへの移行

私たちは要件に戻り、顧客の S3 バケットに送信する準備として、組織ごとに分割された生のイベント データを時間のチャンクに書き込む機能を求めました。 Apache Flink のステートフル処理品質は必要ありませんでした。必要なのはシンプルな ETL パイプラインだけでした。 当社のエンジニアリング チームは、すでにアーキテクチャの他の領域でApache Sparkを試用しており、有望な結果が得られています。

私たちは、ビジネスロジックを Apache Flink からAmazon EMR上で実行される Apache Spark に移植することにしました。 この切り替えにより、より適切にサポートされ、より広く採用されている業界標準ツールを使用できるようになりました。 EMR では、無料のコミュニティ サポート実装の代わりに、AWS が提供する Hadoop S3 コネクタの使用を開始しました。 社内で独自の Apache Flink クラスターを実行する代わりに、マネージド サービスである EMR に切り替えることで、古いパイプラインを実行し続けることに伴う運用上の複雑さのほとんどが解消されました。 さらに、新しい ETL パイプラインはステートレスであり、古いパイプラインで障害が検出されない原因となっていたチェックポイントや中間書き込みに依存しません。 さらに、新しいパイプラインは、事前に定義された短い間隔で個別のジョブを実行し、部分的な失敗があった場合はバッチ全体を完全に再試行します。 これまでのストリーミング データの処理方法と比較すると、お客様にとって処理は依然としてタイムリーですが、Spark マイクロバッチ処理によって耐久性も向上しています。