Apache Spark와 Amazon EMR을 사용하여 Threat Stack의 데이터 파이프라인 최적화

Threat Stack은 매일 수천억 개의 이벤트를 수집하여 고객이 환경 상황을 이해하고, 바람직하지 않은 활동을 식별하고, 보안 태세를 강화하는 데 도움을 줍니다. 이러한 데이터는 다양한 운영 체제, 컨테이너, 클라우드 공급자 API 및 기타 소스에서 추출됩니다. 우리가 이 모든 데이터를 더 효율적으로 처리할수록, 우리는 고객에게 더 많은 가치를 제공할 수 있습니다.

이 게시물에서는 Threat Stack의 데이터 파이프라인의 이전과 이후 상태에 대한 몇 가지 맥락을 제공합니다. 이를 통해 플랫폼의 안정성을 높이고 운영 효율성을 개선할 수 있었습니다.

데이터 플랫폼 운영

Threat Stack은 높은 처리량으로 데이터를 처리하는 확장 가능하고 강력한 백엔드 시스템을 갖추고 있어 보안 위협을 거의 실시간으로 감지할 수 있습니다. 이러한 세부적인 보안 데이터 스트림을 지원하기 위해 Threat Stack 플랫폼은 여러 개의 특수 마이크로서비스로 세분화됩니다. 이 아키텍처는 고객 기반의 성장에 따라 데이터 파이프라인 인프라를 쉽게 수평적으로 확장할 수 있게 해주고, 전담 서비스 전반에 걸쳐 다양한 데이터 처리 책임을 세분화함으로써 문제 해결을 간소화합니다.

위협 스택 엔지니어링 팀은 일반적으로 플랫폼 비효율성이나 잠재적인 확장성 문제가 고객에게 심각한 문제가 되기 전에 미리 해결합니다. 게다가 엔지니어링 팀 멤버가 한밤중에 호출을 받으면 우리는 문제를 파악하고, 확장 계획을 제안하고, 수정 조치를 실행합니다. 시스템 중단은 상당한 인적, 기회적 비용을 초래하며, 이로 인해 팀은 추가적인 고객 가치를 제공하는 새로운 프로젝트로부터 이탈하게 됩니다. Threat Stack에서는 시스템 상태와 인간에게 미치는 영향의 상관관계를 심각하게 여기고 있으며, 엔지니어링 팀의 건강과 생산성을 유지하기 위해 최선을 다하고 있습니다.

우리의 가장 최근 투자 분야 중 하나는 Threat Stack Data Platform입니다. 이는 고객과 내부 사용자가 보고, 분석, 머신 러닝과 같은 흥미로운 새로운 방식으로 보안 원격 측정을 활용할 수 있도록 해줍니다.

데이터 플랫폼은 저장 계층과 저장된 데이터를 수집, 처리, 소비하여 다양한 분석을 수행하고 데이터 이동성 기능을 활성화하는 여러 서비스로 구성됩니다. Threat Stack Data Portability를 이용하면 고객은 당사 플랫폼에서 풍부한 보안 원격 측정 데이터를 내보내어 SIEM용 Splunk, 데이터 웨어하우징용 Amazon Redshift, 심층적 보관용 Amazon S3 Glacier와 같은 자체 시스템에 로드할 수 있습니다. 이러한 데이터 중 일부는 24시간 SOC를 운영하는 Cloud SecOps Program℠의 보안 분석가가 고객 환경을 모니터링하고 의심스러운 활동 패턴을 식별하는 데에도 사용됩니다.

이 게시물의 목적을 위해 데이터 플랫폼의 데이터 이동성 측면에 대해 자세히 살펴보겠습니다. 데이터 이동성은 데이터 플랫폼에서 데이터를 검색하고 처리하여 조직 및 시간별로 분할하는 여러 서비스에 의해 운영됩니다. 대상 S3 버킷에서 데이터는 날짜와 조직 식별자별로 구성됩니다.

데이터 플랫폼과 이를 통해 제공되는 기능의 활용도가 높아짐에 따라, 우리는 Threat Stack 데이터 이동성을 지원하기 위해 백엔드 일부를 재설계해야 했습니다. 이제 우리의 작업 방식과 지원하는 기능에 대해 조금 알았으니 플랫폼의 작업 전후 상태를 살펴보겠습니다.

Spark 전 위협 스택

이전 버전의 처리 애플리케이션에서는 일괄 처리 및 스트림 처리를 위한 상태 계산을 위한 RAM 종속 분산 처리 엔진인 Apache Flink를 사용했습니다. Flink가 선택 된 이유는 이미 스트리밍 데이터와 원격 측정 집계를 위한 플랫폼의 다른 부분을 구동하고 있었기 때문입니다. 새로운 기능을 지원하기 위해 Apache Kafka 토픽을 사용하고 이벤트를 분할한 다음 이를 S3에 쓰는 단일 작업을 실행하는 새로운 Flink 클러스터를 구축했습니다. 결국 클러스터는 100개가 넘는 Flink 작업 관리자로 커졌고 상당한 수동 유지 관리가 필요했습니다. Threat Stack의 플랫폼은 초당 50만 개의 이벤트를 처리하는데, 이는 Threat Stack에서 지원하는 처리 규모를 알려드리는 것입니다. 백엔드의 모든 서비스는 이 속도를 지원해야 합니다.

Apache Flink에서 실행되는 수집 클러스터는 스테이지 병렬 처리 설정, 균등하게 균형 잡힌 작업 부하를 달성하기 위한 이벤트 데이터 솔팅, 그리고 다양한 인프라 인스턴스 크기 실험에 대한 여러 차례의 조정을 거쳤습니다. 안타깝게도 클러스터는 우리 팀의 운영 비용이 점점 더 높아지는 지경에 이르렀고, 엔지니어와 클라우드 서비스 제공업체 비용 모두에 큰 타격을 주었습니다.

시간이 지나면서 우리는 몇 가지 반패턴을 발견하기 시작했는데, 그 중 하나가 근로자 실패의 연쇄 반응이었습니다. 단일 작업자가 리소스에 굶주리면 결국 응답하지 않게 되고, 이로 인해 나머지 노드가 Apache Kafka 토픽에서 더 많은 메시지를 처리해야 합니다. 그러자 노드 하나하나가 리소스에 굶주리게 되었습니다. 시스템에 중복성을 설계했지만, 연쇄적인 실패 이벤트가 성능에 부정적인 영향을 미쳤으며 대기 중인 사람의 수동 개입이 필요했습니다.

참고로, Apache YARN은 클러스터 리소스를 관리하는 데 사용되지 않았다는 점에 유의하세요. Apache YARN을 적용하면 클러스터 워커의 연쇄적 실패 문제는 해결되지만, 비용과 서비스 효율성 문제를 해결하는 데는 도움이 되지 않습니다. 이 수집 서비스에 기인한 플랫폼 안정성 사고 수는 월별 총 서비스 이벤트의 최대 30%를 차지했습니다.

문제의 다른 측면은 데이터 수집 서비스를 지원하는 인프라를 운영하는 데 드는 비용이었습니다. 이 서비스 하나가 클라우드 공급업체의 월별 청구서에서 약 25%를 차지했습니다. 또한 인간에게도 큰 영향을 미쳐, 사람들이 밤에 깨어나 일상 업무를 수행할 수 있는 능력을 감소시켰습니다. 서비스로 인해 유지 관리와 중단이 잦아 교체가 필요했고, 적시성, 확장성, 비용 효율성, 안정성을 목표로 삼았습니다.

Flink에서 Spark로 이동

우리는 고객의 S3 버킷으로 전송하기 위해 조직별로 분할된 원시 이벤트 데이터를 시간 단위로 작성할 수 있는 기능이라는 요구 사항으로 돌아갔습니다. 우리에게는 Apache Flink의 상태 처리 기능은 필요하지 않았고, 간단한 ETL 파이프라인만 필요했습니다. 저희 엔지니어링 팀은 이미 아키텍처의 다른 영역에서 Apache Spark를 실험했으며 유망한 결과를 확인했습니다.

우리는 Apache Flink의 비즈니스 로직을 Amazon EMR 에서 실행되는 Apache Spark로 이식하기로 결정했습니다. 이 전환을 통해 더 나은 지원을 받고 더 널리 채택된 산업 표준 도구를 사용할 수 있게 되었습니다. EMR을 통해 우리는 무료 커뮤니티 지원 구현 대신 AWS에서 제공하는 Hadoop S3 커넥터를 사용하기 시작했습니다. 자체 Apache Flink 클러스터를 운영하는 대신 관리형 서비스인 EMR로 전환함으로써 기존 파이프라인을 운영하는 데 따른 운영상의 복잡성을 대부분 제거할 수 있었습니다. 더욱이 새로운 ETL 파이프라인은 상태 비저장이며, 이전 파이프라인에서 장애가 감지되지 않았던 체크포인팅이나 중간 쓰기에 의존하지 않습니다. 또한, 새로운 파이프라인은 짧고 미리 정의된 간격으로 개별 작업을 실행하고, 부분적인 실패가 발생하면 전체 배치를 완전히 다시 시도합니다. 이전에 스트리밍 데이터를 처리했던 방식과 비교해도, 처리 속도는 여전히 고객에게 적절하지만, 이제는 Spark 마이크로 배치 처리가 제공하는 추가적인 내구성을 갖추고 있습니다.