Apache Spark Structured Streaming: 실시간 모드(RTM)를 통한 밀리초 단위 지연 시간 구현

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

핵심 요약

기존 스트리밍 엔진은 고처리량(Spark)과 저지연(Flink) 사이에서 하나를 선택해야 하는 트레이드오프가 존재했다. Apache Spark 4.1에 도입된 실시간 모드(RTM)는 마이크로배치 아키텍처를 진화시켜 데이터가 차단 없이 흐르도록 설계함으로써 이 문제를 해결했다. RTM은 긴 에포크 기간 내에서 연속적인 데이터 흐름과 병렬 처리 스테이지를 활용하여 100ms 미만의 지연 시간을 달성한다. 이를 통해 사용자는 단일 엔진으로 복잡한 ETL부터 실시간 사기 탐지까지 모든 스트리밍 요구사항을 충족할 수 있다.

배경

Apache Spark Structured Streaming 기본 지식, 마이크로배치 및 스트림 처리 아키텍처에 대한 이해, ETL 및 실시간 데이터 처리 개념

대상 독자

실시간 데이터 파이프라인을 설계하고 운영하는 데이터 엔지니어 및 MLOps 전문가

의미 / 영향

Spark가 저지연 영역에서 Flink의 강력한 대안으로 부상함에 따라 데이터 아키텍처의 단순화가 가속화될 것이다. 기업들은 더 이상 처리량과 지연 시간 사이에서 엔진을 고민할 필요 없이 단일 플랫폼에서 모든 스트리밍 유즈케이스를 구현할 수 있게 된다.

섹션별 상세

기존 마이크로배치 아키텍처는 배치를 작게 줄이는 것만으로는 밀리초 단위 지연 시간을 달성하기 어렵다. 로그 파일 기록, 상태 업데이트 업로드, 스케줄링 및 직렬화와 같은 고정 오버헤드가 데이터 처리 시간보다 커지기 때문에 특정 임계값 이하에서는 오히려 지연 시간이 증가한다.

배치 크기에 따른 지연 시간 변화를 보여주는 바 차트 — Chart배치 크기를 극단적으로 줄였을 때(2,500 rows) 고정 오버헤드로 인해 오히려 지연 시간이 증가하는 현상을 보여준다. 이는 단순히 배치 크기를 줄이는 것만으로는 실시간 성능을 달성할 수 없다는 아키텍처적 한계를 뒷받침한다.

실시간 모드(RTM)는 에포크(Epoch) 기간을 늘리되 에포크 내부에서 데이터가 차단 없이 흐르도록 수정했다. 이를 통해 체크포인팅과 배리어 오버헤드를 여러 데이터에 걸쳐 분산시키면서도 마이크로배치 아키텍처의 복구 탄력성과 효율성을 유지한다.

기존 마이크로배치 실행 모델과 실시간 모드(RTM)의 실행 흐름 비교 다이어그램 — Diagram기존 방식은 에포크마다 계획 수립과 실행이 반복되는 반면, RTM은 더 긴 에포크 내에서 데이터가 중단 없이 연속적으로 흐르는 구조를 시각적으로 보여준다. 이는 RTM이 어떻게 고정 오버헤드를 줄이는지 설명하는 핵심 자료이다.

병렬 처리 스테이지(Concurrent Processing Stages)를 도입하여 스테이지 간 대기 시간을 제거했다. 기존에는 리듀서가 모든 맵퍼의 종료를 기다려야 했으나, RTM에서는 셔플 파일이 준비되는 즉시 다음 스테이지가 처리를 시작하여 엔드 투 엔드 지연 시간을 획기적으로 단축한다.

실시간 모드에서의 병렬 스테이지 처리 구조 다이어그램 — DiagramSource에서 Sink까지 데이터가 흐를 때 Concurrent Stage 1과 2가 스트리밍 셔플을 통해 동시에 실행되는 모습을 보여준다. 이전 스테이지가 완전히 끝나기를 기다리지 않고 데이터를 즉시 전달하여 지연 시간을 줄이는 메커니즘을 설명한다.

셔플과 같은 주요 연산자를 비차단형(Non-blocking)으로 재설계했다. 배치 모드에서 Group-by aggregation은 모든 레코드를 버퍼링한 후 결과를 출력하지만, RTM에서는 버퍼링을 최소화하고 결과를 지속적으로 생성하여 파이프라인 전체에 데이터가 끊김 없이 흐르게 한다.

성능 벤치마크 결과 Spark RTM은 기능 엔지니어링(Feature Engineering) 워크로드에서 Flink 대비 최대 92% 낮은 지연 시간을 기록했다. 이는 Spark가 고처리량 배치 처리뿐만 아니라 초저지연 운영 워크로드에서도 우수한 성능을 발휘함을 입증한다.

Spark RTM과 Apache Flink의 p99 지연 시간 비교 차트 — ChartFeature Enrichment, Calculation, Encoding 등 주요 기능 엔지니어링 작업에서 Spark RTM이 Flink보다 최대 92% 낮은 지연 시간을 보임을 수치로 증명한다. 특히 상태 저장 연산(Stateful Join/Aggregation)에서 Spark RTM의 우위가 두드러진다.

실무 Takeaway

실시간 사기 탐지나 금융 거래 분석처럼 100ms 미만의 응답성이 필요한 시스템에 Spark Structured Streaming RTM을 도입하여 성능을 최적화할 수 있다.
배치 크기를 무리하게 줄이기보다 RTM의 하이브리드 실행 모델을 활용하여 고정 오버헤드를 관리하고 처리량과 지연 시간의 균형을 잡는 것이 중요하다.
단일 Spark 엔진으로 ETL과 실시간 처리를 통합함으로써 다중 프레임워크 운영에 따른 학습 곡선과 인프라 관리 복잡도를 제거할 수 있다.

언급된 리소스

API DocsReal-Time Mode Technical Guide

DemoEngineering behind RTM On-demand Session