Apache Spark 실시간 모드를 사용한 초고속 이상 탐지

본 포스트에서는 비즈니스 성과에 실질적인 변화를 가져오는 운영 워크로드(사기 탐지, IoT 센서 모니터링, 실시간 개인화, 보안 신호 처리 등 이벤트에 대한 즉각적인 대응이 비즈니스 결과에 결정적인 영향을 미치는 모든 시나리오)를 위한 재사용 가능한 패턴을 구축합니다.

핵심 목표: 이벤트가 의심스럽거나 유효하지 않은 것으로 보이면 즉시 플래그를 지정하고 적절한 다운스트림 작업으로 라우팅하는 것입니다.

이 블로그에서는 Ethereum 블록체인 트랜잭션에 대한 이상 탐지(anomaly detection)를 시연합니다. 우리는 Ethereum 블록체인 데이터를 분석하고 유효하지 않은 패턴이 있는 트랜잭션에 실시간으로 플래그를 지정합니다. 구체적으로 다음과 같은 항목을 탐지합니다.

1. 데이터 품질 위반: Ethereum 프로토콜상 물리적으로 불가능한 gas_used > gas_limit 이 포함된 블록으로, 데이터 손상, 생산자(producer) 버그 또는 스키마 파싱 실패를 나타냅니다.
2. 페이로드 위생(hygiene) 위반: 식별 가능한 PII 또는 자격 증명 패턴(이메일 주소, JWT 토큰, AWS 액세스 키)이 포함된 extra_data 필드로, 데이터 유출 또는 잘못 구성된 생산자를 나타냅니다.

데모에는 Ethereum 데이터를 사용하지만, 이러한 "의심스럽거나 유효하지 않음" 분류는 다음과 같은 다양한 고가치 사용 사례에 적용될 수 있습니다.

• 사기 탐지: 트랜잭션이 이상 패턴을 보임 → 다운스트림 조사 워크플로 트리거
• IoT 모니터링: 센서 측정값이 물리적으로 가능한 범위를 벗어남 → 자동화된 대응 시작
• 보안 운영: 페이로드에 비밀번호 또는 PII 패턴이 포함됨 → 통합 거버넌스를 통해 실시간으로 격리
• 개인화 엔진: 특정 행동 이벤트에 대응하여 즉각적이고 맥락에 맞는 혜택 제공

동일한 탐지 로직이 모든 도메인에 직접 매핑됩니다. 예컨대 예상치 못한 PII가 포함된 금융 거래, 범위를 벗어난 센서 측정값이 있는 IoT 페이로드, 또는 마스킹(redact)되었어야 할 비밀 정보가 포함된 API 이벤트 로그 등이 있습니다. Ethereum 스트림은 이 패턴을 대규모로 시연할 수 있는 깨끗하고 재현 가능한 데이터 세트를 제공합니다.

Spark Real-Time Mode 소개

Real-Time Mode (RTM)는 Apache Spark™ Structured Streaming의 새로운 트리거 유형으로, Apache Flink와 같은 별도의 특화된 엔진 없이도 Spark API에 밀리초 수준의 대기 시간을 제공합니다.

Structured Streaming의 기본 마이크로배치(microbatch) 모드가 승객이 찰 때까지 기다렸다가 출발하는 공항 셔틀버스처럼 작동하는 반면, RTM은 고속 무빙워크처럼 작동하여 각 이벤트가 도착하는 즉시 처리합니다. 이는 세 가지 아키텍처 혁신을 통해 달성됩니다. 바로 지속적인 데이터 흐름(이벤트가 개별 청크 단위가 아니라 도착하는 즉시 처리됨), 파이프라인 스케줄링 (모든 쿼리 단계가 차단 없이 동시에 실행됨), 그리고 스트리밍 셔플(데이터가 디스크를 거치지 않고 메모리에서 태스크 간에 즉시 전달됨)입니다.

RTM은 대기 시간이 비즈니스 성과에 직접적인 영향을 미치는 운영 워크로드(사기 탐지, 실시간 개인화, ML 피처 연산, IoT 모니터링 등)를 위해 특별히 제작되었습니다. 1~2초의 대기 시간을 감당할 수 있는 워크로드의 경우, 기존 마이크로배치가 여전히 더 비용 효율적인 선택입니다.

RTM이 게임 체인저인 이유

1. 초고속: 이제 1초 미만의 대기 시간 달성 가능

Real-Time Mode는 Apache Spark로 가능한 작업을 근본적으로 변화시킵니다. 워크로드 복잡성에 따라 약 5ms에서 300ms에 이르는 엔드투엔드 대기 시간 덕분에, 기존에 특화된 스트림 처리 엔진이 독점하던 영역에 Spark가 진입할 수 있게 되었습니다. 기존 마이크로배치는 1~2초의 대기 시간을 제공하지만, Real-Time Mode는 약 5ms에서 300ms를 달성합니다.
이 아키텍처는 사전 할당된 실행 파이프라인과 비동기 체크포인팅을 통해 이를 구현하며, 기존 마이크로배치 처리를 제약하던 스케줄링 오버헤드를 제거합니다. 밀리초 단위가 중요한 운영 워크로드(사기 탐지, IoT 모니터링, 실시간 혜택 제공 등)에서 이 정도 수준의 성능은 혁신적입니다.

2. 간소화된 스택: 별도의 기술 불필요

많은 조직이 흔히 비용이 많이 드는 오해를 하곤 합니다. "Spark는 실시간 사용 사례에 충분한 성능을 내지 못하므로, 이 하나의 요구사항을 위해 완전히 별도의 스택이 필요하다"는 생각입니다.

1~2초의 대기 시간을 허용하는 워크로드의 경우, Spark 마이크로배치는 우수한 가성비로 데이터를 Delta Lake에 안정적으로 전달합니다. 1초 미만의 응답 시간이 필요한 운영 워크로드의 경우, Real-Time Mode를 사용하면 별도의 기술이 전혀 필요하지 않습니다. 이는 분석 및 운영 워크로드 모두를 위해 단일 Spark 기반 스택으로 통합한 Coinbase, DraftKings, 및 MakeMyTrip 팀을 통해 검증되었습니다.

Real-Time Mode를 사용하면 Spark는 단일 통합 플랫폼 내에서 분석(초 단위) 및 운영(밀리초 단위) 워크로드를 모두 처리할 수 있습니다. 이를 통해 다음과 같은 이점을 얻을 수 있습니다.

• 운영 복잡성 감소: 관리, 모니터링 및 문제 해결을 위한 기술 스택이 하나로 단일화됨
• 교육 오버헤드 감소: 기존 Spark 전문 지식을 실시간 사용 사례에 바로 적용 가능
• 통합 마찰 감소: 서로 다른 스트리밍 엔진 간의 복잡한 데이터 인계가 없음
• 총 소유 비용(TCO) 절감: 통합을 통해 인프라, 라이선스 및 운영 비용이 감소함

3. 개발자 친화적: 코드 재작성 없이 간단한 트리거 변경만으로 가능

아마도 Real-Time Mode의 가장 매력적인 점은 이미 Structured Streaming에 익숙한 개발자에게 매우 간단하다는 것입니다. 이 강력한 기능을 활성화하는 데 복잡한 마이그레이션이나 근본적인 코드 구조 변경이 필요하지 않습니다.

조직은 단순히 트리거 구성을 수정하는 것만으로 밀리초 수준의 대기 시간을 확보할 수 있습니다.

이게 전부입니다. 익숙한 Structured Streaming API, 동일한 체크포인트 관리, 동일한 최소 한 번(at-least-once) 전달 의미 체계(semantics)를 그대로 사용합니다. 단 한 번의 구성 변경만으로 1초 미만의 운영 인텔리전스를 활성화할 수 있습니다.

전달 보장에 대한 참고 사항: Kafka 싱크가 있는 RTM은 최소 한 번(at-least-once) 전달 보장을 제공합니다. 다운스트림 소비자는 멱등성(idempotent) 쓰기 또는 중복 제거 로직을 통해 잠재적인 중복을 처리해야 합니다.

이러한 원활한 통합은 매우 중요한 이점입니다. 팀은 완전히 별개의 기술 스택을 학습, 배포 및 관리하는 데 드는 상당한 오버헤드 없이 운영 워크로드를 프로토타입하고 프로덕션에 적용할 수 있습니다. 이 접근 방식은 새로운 실시간 기능을 도입할 때 수반되는 위험을 줄이면서 혁신을 극적으로 가속화합니다.

Real-Time Mode가 왜 중요한지 알아보았으니, 이제 이 패턴을 실제로 어떻게 구현하는지 살펴보겠습니다. 다음 섹션에서는 이러한 기능을 비즈니스 가치로 전환하는 운영 패턴인 프로덕션 지원 가드레일 파이프라인을 시연합니다.

아키텍처 개요: 운영 가드레일 스트림 구축

들어오는 모든 이벤트는 즉시 평가를 거쳐 다음과 같은 정보가 포함된 강화된(enriched) 다운스트림 이벤트를 생성합니다.

• 결정: ALLOW 대 QUARANTINE
• 이유: 트리거된 플래그에 대한 자세한 설명(데이터 품질 위반, 페이로드 위생 우려 사항 등)

이 운영 패턴은 실시간 의사 결정을 위한 단일 신뢰 원천(single source of truth) 역할을 합니다.

• 이 이벤트를 조사를 위해 격리해야 합니까?
• 다운스트림 시스템이 즉각적으로 반응할 수 있도록 이벤트를 어떻게 강화합니까?

이 데모에서는 Ethereum 블록 데이터를 사용하지만, 이 패턴은 금융 거래, 센서 판독값, 인증 로그, API 호출 등 모든 분야에 보편적으로 적용되며 아키텍처는 동일하게 유지됩니다.

대규모 검증

프로덕션급 솔루션을 제공하겠다는 약속에 걸맞게, 저희는 이 패턴을 대규모로 검증했습니다. 약 2300만 개의 메시지에 해당하는 약 95 GB의 전체 Ethereum 체인을 4개의 파티션에 분산하여 테스트를 위해 Kafka에 로드했습니다.

이벤트 분류를 위한 검증 규칙 정의

저희는 의도적으로 간단하면서도 확실한 신호를 주는 검증 규칙을 구현합니다.

규칙 1: 페이로드 위생 검증

프로덕션 스트림에 있어서는 안 되는 데이터임을 명확히 나타내는 패턴이 있는지 extra_data 필드를 스캔합니다. 코드 예제에서는 기본적인 패턴 감지(이메일 주소, JWT 토큰, AWS 키 형식)를 보여줍니다.

기업은 이를 PII 패턴, 내부 식별자, API 자격 증명 및 유사한 민감한 데이터와 같이 자체 컴플라이언스 요구 사항에 맞는 규칙으로 대체해야 합니다.

핵심 인사이트: 실시간 가드레일은 사후 분석에서 발견되는 것이 아니라, 통합 거버넌스의 일부로서 파이프라인 내에 존재해야 합니다.

규칙 2: 데이터 품질 검증

gas_used > gas_limit

이 조건은 유효한 데이터에서는 절대 발생해서는 안 됩니다. 이 조건이 감지되면 다음과 같은 몇 가지 문제 중 하나가 발생했음을 나타냅니다.

• 전송 중 데이터 손상
• 프로듀서 측의 데이터 생성 오류
• 스키마 파싱 불일치
• 업스트림 시스템 장애

운영 관점에서 볼 때, 이는 다운스트림 시스템에 영향을 미치기 전에 신속하게 대응할 수 있도록 즉시 플래그를 지정해야 하는 대표적인 이상 징후입니다.

검증 로직이 수립되었으므로, 이제 1초 미만의 실행을 가능하게 하는 스트리밍 구성으로 넘어가겠습니다.

실시간 모드: 필수 구성

실시간 모드는 실시간 트리거를 통해 활성화되며 업데이트 모드로 작동합니다. PySpark에서는 간격 매개변수(예: "5 minutes")를 지정합니다.

두 가지 필수 구성 요구 사항:

1. 클러스터 구성: Databricks 문서에 필요한 작업 클러스터 설정 및 RTM 활성화 플래그가 명시되어 있습니다
2. 출력 모드: RTM 트리거와 함께 update 모드를 사용해야 합니다

이 데모에 사용된 구성:

• 런타임: Databricks Runtime 16.4 LTS 이상
• 컴퓨팅: 고정된 워커 수의 전용(단일 사용자) 클러스터(자동 확장 비활성화됨)
• Photon: 비활성화됨(RTM에서 지원되지 않음)
• 워커: 이 워크로드의 경우 워커 4개
• 출력 모드: update(RTM에 필수)

전체 cluster_config.template.json은 함께 제공되는 리포지토리를 참조하세요.

구현: 실시간 가드레일 파이프라인

이 단일 패스 파이프라인은 Kafka와 Spark 실시간 모드 간의 원활한 통합을 보여줍니다.

1. Kafka 소스에 연결
2. 수신되는 JSON 페이로드 파싱
3. 결정 및 사유 계산
4. 보강된 JSON을 다시 Kafka에 쓰기

코드는 여기에서 확인할 수 있습니다.

결과: 대규모 성능

저희는 연속 스트리밍 모드에서 4개의 Kafka 파티션에 분산된 약 2300만 개의 메시지인 Ethereum 블록체인 데이터를 처리하여 실시간 모드 성능을 검증했습니다.

처리량 성능

이 파이프라인은 인상적인 처리량 특성을 보여주었습니다.

• 입력 속도: 초당 65,592개 행
• 처리 속도: 초당 69,713개 행(지속)
• 총 처리된 레코드 수: 약 23,213,628개 메시지
• 클러스터 구성: DBR 16.4 LTS, 워커 4개(i3.xlarge), 전용 단일 사용자 모드, Photon 비활성화됨

지연 시간 메트릭

드라이버 로그는 spark.streaming.madeProgress 이벤트를 통해 상세한 지연 시간 메트릭을 캡처합니다. 실시간 모드는 쿼리가 레코드를 읽은 시점부터 다운스트림 싱크에 쓸 때까지의 시간을 측정하는 processingLatencyMs를 보고합니다.

약 2300만 개의 레코드를 처리하는 이 상태 비저장(stateless) 검증 파이프라인에서 관찰된 결과는 다음과 같습니다.

• P0, P50, P90, P95: 1밀리초(메트릭에서는 0으로 반올림됨) P99: 1밀리초, 처리 속도: 초당 69,713개 행 지속
• processingLatencyMs 이해하기: 이 메트릭은 RTM이 레코드를 읽고 다운스트림 싱크에 쓰는 사이의 시간을 측정합니다. 이는 태스크별로 측정되며 백분위수(P0, P50, P90, P95, P99)와 함께 StreamingQueryProgress의 rtmMetrics.processingLatencyMs 섹션에 보고됩니다. 이와 같은 단일 단계 Kafka-to-Kafka 파이프라인의 경우, 이는 사실상 엔드투엔드 레코드당 지연 시간을 나타냅니다.
• 이것이 의미하는 바: 대부분의 레코드(95번째 백분위수)는 0.5밀리초 미만으로 처리되었으며, 가장 느린 1%조차도 1밀리초 이내에 완료되었습니다. P0~P95에 대해 "0"으로 표시된 값은 0.5ms 미만의 지연 시간(메트릭 시스템에 의해 내림됨)을 나타냅니다.

참고: 이 결과는 상태 비저장 검증 파이프라인에서의 성능을 나타냅니다. 더 복잡한 상태 저장(stateful) 작업(집계, 윈도잉)은 워크로드 복잡성에 따라 약 5ms에서 300ms RTM 범위 내에서 더 높은 지연 시간이 발생할 수 있습니다.

주요 성능 인사이트

• 해석: 모든 레코드의 99%가 1밀리초 미만으로 처리되었으며, 가장 느린 1%만 1밀리초에 도달했습니다. 이는 매우 일관된 저지연 성능을 보여줍니다.
• 처리량: 파이프라인은 약 2300만 개의 레코드를 처리하는 동안 초당 69,713개 행을 유지하여 지속적인 부하 하에서도 안정적인 성능을 입증했습니다.

이러한 메트릭은 실시간 모드가 초당 거의 70,000개 행에 달하는 대용량 스트림을 처리하면서 프로덕션급의 1밀리초 미만 지연 시간(P95 0.5ms, P99 = 1ms)을 제공함을 입증합니다. 이로써 통합 플랫폼과 저지연 요구 사항 간의 전통적인 절충(trade-off) 필요성이 사라집니다.

결론

실시간 모드는 Apache Spark™ Structured Streaming을 스트리밍 데이터에 대한 즉각적인 응답을 요구하는 운영 및 지연 시간에 민감한 애플리케이션과 같은 새로운 클래스의 워크로드로 확장합니다. 팀에서 이미 사용 중인 Spark API에 1초 미만의 지연 시간을 제공함으로써, 가장 시간 임계적인 파이프라인을 위해 별도의 특화된 엔진을 운영할 필요가 없어집니다.

가치 제안은 매우 매력적입니다.

• 하나의 통합 플랫폼에서 분석(초 단위) 및 운영(밀리초 단위) 워크로드를 모두 처리합니다
• 기존 Spark 전문성을 그대로 활용할 수 있어 별도의 전문 지식이 필요하지 않습니다
• 최소한의 마이그레이션 리스크 — 단 한 번의 트리거 구성 변경만으로 실시간 기능을 활성화할 수 있습니다
• 프로덕션에서 검증된 성능 — 수백만 개의 이벤트를 처리하면서 P99 지연 시간 1ms, P95 지연 시간 0.5ms 미만을 달성합니다

사기 감지 파이프라인, 개인화 엔진, ML 기능(feature) 계산 시스템 중 무엇을 구축하든, 실시간 모드는 Spark의 단순성과 광범위한 에코시스템을 유지하면서 애플리케이션이 요구하는 지연 시간을 제공합니다.

시작하기

이 가드레일 파이프라인을 엔드투엔드로 실행하려면 함께 제공되는 리포지토리를 복제하세요. 여기에는 전체 구현, 클러스터 구성 및 배포 가이드가 포함되어 있습니다.

자세히 알아보려면 구성 옵션 및 지원되는 소스/싱크에 대한 실시간 모드 설명서를 검토하거나, 전체 아키텍처 연습을 위해 실시간 모드 기술 심층 분석(Technical Deep Dive)을 시청하세요.

리소스

• 실시간 모드 기술 심층 분석: Apache Spark™에 300밀리초 미만의 스트리밍을 구축한 방법
• Databricks에서 운영 워크로드에 1초 미만의 지연 시간 제공
• Databricks 실시간 모드 문서
• 관련 코드 리포지토리 - 실시간 모드 가드레일 데모 - 종합적인 테스트 제품군, 클러스터 구성 및 배포 가이드를 포함하여 프로덕션 환경에 바로 적용 가능한 구현

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)