주요 컨텐츠로 이동

마이크로배치 장벽 깨기: Apache Spark 실시간 모드의 아키텍처

높은 처리량의 ETL 및 초저지연 스트리밍 워크로드를 처리하도록 Spark를 발전시킨 방법

Concurrent-Stages-in-Real-Time-Mode-Decreases-Latency

발행일: 2026년 3월 16일

데이터 엔지니어링Less than a minute

Summary

  • Apache 스트럭처드 스트리밍의 실시간 모드는 높은 처리량의 ETL과 밀리초 지연 시간의 운영 워크로드를 단일 엔진으로 통합합니다.
  • 밀리초 단위의 지연 시간을 제공하는 동시 처리 단계와 논블로킹 연산자를 상세히 설명하며 하이브리드 실행 모델을 자세히 살펴보세요.
  • 이제 고객은 실시간 사기 탐지와 같은 초저지연 시간 애플리케이션에서 100ms 미만의 응답성을 달성할 수 있습니다.

Apache Spark 4.1에서 실시간 모드(RTM)가 출시됨에 따라 이제 구조적 스트리밍은 밀리초 수준의 지연 시간을 제공합니다. 최근 블로그 게시물 에서 RTM이 여러 저지연 특징 엔지니어링 워크로드에서 Flink보다 어떻게 뛰어난 성능을 보이는지 설명했습니다(아래 참조).

이 블로그에서는 Structured Streaming이 처리량이 많은 ETL 워크로드와 초저지연 워크로드를 모두 지원할 수 있게 한 아키텍처 변경 사항에 대해 살펴보겠습니다.

Apache Spark 실시간 Mode 대 Apache Flink
Apache Spark RTM은 특징 엔지니어링 사용 사례에서 Flink보다 빠릅니다.

throughput 대 지연 시간 딜레마

지금까지 스트리밍 엔진을 선택한다는 것은 높은 처리량의 ETL 워크로드를 위해 Apache Spark와 같은 시스템을 선택하거나, 낮은 지연 시간 워크로드를 위해 Apache Flink와 같은 시스템을 선택하는 절충안을 의미했습니다. 이 두 시스템은 매우 다른 시맨틱과 성능 특성을 가지고 있습니다. Structured Streaming의 RTM으로 이러한 상황이 달라집니다. RTM이 도입되면서 Apache Spark는 이제 높은 처리량과 초저지연 사용 사례를 모두 처리할 수 있게 되었습니다. 이는 이제 새로운 학습 곡선 없이 단일 엔진을 선택하고 완전히 다른 두 시스템을 관리하는 것을 피할 수 있다는 것을 의미합니다.

마이크로배치 아키텍처는 높은 처리량을 제공합니다

Spark 구조적 스트리밍은 마이크로배치 아키텍처를 사용합니다. 즉, 스트리밍 시스템이 입력 데이터를 수신하고 데이터 가용성 및 최대 배치 크기 구성에 따라 에포크라는 개별 배치로 나눕니다. Spark 엔진은 project, filter, aggregation과 같은 변환을 통해 비즈니스 로직을 적용합니다. 결과는 연속적인 배치 스트림으로 출력됩니다. 구조적 스트리밍은 이러한 마이크로배치 아키텍처 덕분에 높은 처리량의 처리에 탁월합니다. 여러 레코드가 함께 처리되므로 고정 오버헤드가 상각되고 벡터화된 실행으로 처리량을 더욱 향상시킬 수 있습니다. 이러한 배치는 하드웨어 사용률을 높게 유지하면서 병렬로 실행됩니다. 마이크로배치 모드는 여러 스트림에 걸쳐 작업 슬롯을 동적으로 할당하며, 이는 높은 사용률과 처리량을 달성하는 데 추가적으로 도움이 됩니다. Spark의 기반이 되는 혁신인 계보 기반 내결함성 은 이러한 스트림이 강력한 단 한 번 실행(exactly-once) 보장으로 처리되도록 합니다.  

기존 마이크로배치 실행과 실시간 Mode(RTM) 비교
RTM은 마이크로배치 모드에 비해 비차단 방식으로 데이터를 처리합니다.

기술 가이드 eBook

ETL 시작하기

저지연이라는 바늘귀 꿰기

스트럭처드 스트리밍은 초 단위 ETL 및 수집 워크로드를 처리하는 데 매우 뛰어나지만, 많은 운영 사용 사례에서는 밀리초 수준의 지연 시간을 요구합니다. 금융 거래에서의 사기 탐지, 여행 업계의 실시간 인사이트 또는 커넥티드 차량의 원격 측정 데이터 분석은 모두 고객이 밀리초 단위로 응답을 받아야 하는 사례입니다.

아키텍처 과제: 더 작은 배치가 작동하지 않는 이유

가장 확실한 해결책은 간단해 보일 수 있습니다. 바로 배치를 더 작게 만드는 것이죠. 한 번에 하나의 레코드를 처리하면 실시간 성능을 얻을 수 있습니다. 안타깝게도, 그렇게 간단하지는 않습니다.

Structured Streaming의 각 마이크로배치에는 소량의 데이터를 처리할 때 실행 시간의 대부분을 차지하는 고정 비용이 발생합니다. 시스템은 각 마이크로 배치 실행 전후에 로그 파일을 영구 객체 스토리지에 기록합니다. 그뿐만 아니라 각 상태 저장 쿼리에 대한 상태 업데이트도 마이크로배치가 끝날 때 객체 스토리지에 업로드해야 합니다. 이는 일관성 시맨틱을 보장하기 위한 중요한 단계이지만 실행 시간에 수백 밀리초에서 수 초까지 추가될 수 있습니다. 이러한 지연 시간 중 일부를 숨기더라도 각 배치 계획의 지연 시간, 논리적 및 물리적 계획 오버헤드, 작업 직렬화 및 스케줄링은 줄이기 어렵습니다. 짐작하시겠지만, 배치 크기를 줄이는 것은 금방 한계에 부딪힙니다. 아래 그림은 마이크로배치가 너무 작아지면(가장 왼쪽 막대) 고정된 마이크로배치 처리 비용이 실행의 대부분을 차지하고 종단 간 지연 시간을 증가시키는 것을 보여줍니다.


임계값을 초과하면 더 작은 배치 크기는 고정 오버헤드로 인해 지연 시간을 늘릴 수 있습니다

이것은 우리에게 아키텍처적인 과제를 제시했습니다. 즉, 레코드를 한 번에 하나씩 처리하는 모델(예: Apache Storm 및 Apache Flink)에서 기대하는 낮은 지연 시간을 달성하면서 마이크로배치 아키텍처의 비용 및 내결함성 이점을 유지하는 것입니다. 우리의 핵심 통찰력은 실시간 워크로드를 지원하도록 마이크로배치 아키텍처를 발전시킬 수 있다는 것입니다. 우리는 내결함성을 위한 체크포인팅과 같은 핵심 마이크로배치 아키텍처 기능을 계속해서 많이 사용했습니다. 하지만 데이터가 대기하여 높은 지연 시간을 초래하던 단계를 제거했습니다. 아래에서 이러한 변경 사항에 대해 설명합니다.

솔루션: 하이브리드 실행 모델

Structured Streaming의 지연 시간을 개선한 방법은 다음과 같습니다.

1. 연속 데이터 흐름을 이용한 더 긴 에포크

마이크로배치 모드는 에포크(epoch)라고 불리는 데이터 배치를 처리합니다. 에포크 경계는 시작 및 종료 오프셋을 사용하여 미리 결정됩니다. 대신 실시간 모드는 더 긴 기간의 에포크를 처리하지만 각 에포크 내에서 데이터가 흐르는 방식을 수정합니다. 이제 데이터는 블로킹 없이 다양한 스테이지와 연산자를 통해 지속적으로 스트리밍됩니다. 에포크의 지속 시간이 더 길기 때문에 체크포인팅과 배리어의 오버헤드가 상각됩니다. 에포크 경계에서는 복구 기록 및 작업 재스케줄링을 위해 여전히 배리어를 사용하며, 이는 마이크로 배치 아키텍처를 복원력 있고 효율적으로 만드는 이점을 유지합니다. 저희는 Structured Streaming의 마이크로배치를 본질적으로 체크포인트 간격으로 발전시켰습니다.

2. 동시 처리 단계

Structured Streaming 아키텍처에서는 처리 단계가 순차적으로 실행되어 리듀서가 매퍼가 완료되기를 기다리면서 불필요한 지연이 발생했습니다. 우리는 실시간 모드에서 이러한 단계가 동시에 실행되도록 만들었습니다. 이제 Spark 드라이버는 소스 오프셋을 요청하고 매퍼를 스케줄링하지만, 리듀서는 모든 매퍼가 완료되기를 기다리는 대신 셔플 파일이 사용 가능해지는 즉시 처리를 시작할 수 있습니다. 이러한 변경으로 종단 간 지연 시간이 극적으로 줄어듭니다. 아래의 RTM 그림은 두 단계가 동시에 실행되고, 1단계에서 행이 처리되는 즉시 2단계에서 행 처리를 시작하는 것을 보여줍니다.

실시간 모드의 동�시 스테이지는 전체 지연 시간을 줄입니다
실시간 모드는 지연 시간을 줄이는 동시 스테이지를 사용합니다


3. 논블로킹 연산자

대량 버퍼링을 사용하는 배치 실행용으로 설계된 셔플과 같은 주요 연산자를 재구성했습니다. 배치 모드에서 group-by 집계는 모든 레코드를 버퍼링하고 사전 집계를 수행한 후 마지막에만 결과를 내보냈습니다. 실시간 처리를 위해 버퍼링을 최소화하고 결과를 지속적으로 생성하도록 이러한 연산자를 수정하여 데이터가 불필요한 대기 없이 파이프라인을 통해 흐를 수 있도록 했습니다.
 

요약

지속적인 데이터 흐름을 갖춘 더 긴 지속 시간의 에포크, 동시 처리 스테이지, 논블로킹(non-blocking) 연산자를 사용함으로써 Apache Spark Structured Streaming 엔진을 높은 처리량과 초저지연 스트리밍 사용 사례를 모두 처리할 수 있도록 일반화했습니다. 이 하이브리드 접근 방식을 통해 이제 여러 스트리밍 엔진 중에서 선택할 필요가 없어졌습니다. 사용자는 Apache Spark만 배우면 되며 초저지연 스트리밍 전용의 다른 프레임워크를 배울 필요가 없습니다.

실시간 모드는 이미 Databricks의 프로덕션 환경에서 사용되고 있으며 최첨단 금융 회사부터 여행 사이트에 이르기까지 여러 고객이 사용하고 있습니다. 고객은 각 사용 사례에 대해 밀리초 단위의 지연 시간을 달성할 수 있습니다.

이것이 Spark 기능의 중요한 도약이기는 하지만, 저희는 계속해서 새로운 스트리밍 기능을 추가하고 있습니다. 조직에서 실시간 워크로드를 위한 솔루션을 찾고 있다면 Apache Spark 스트럭처드 스트리밍을 사용해 보세요!

 

기술 리소스 살펴보기

RTM의 기반이 되는 엔지니어링에 대해 더 자세히 알아보려면 당사 주제 전문가들이 진행하는 이 온디맨드 세션 을 시청하세요. 실시간 모드의 설계와 구현을 살펴볼 것입니다.

또는 시작하는 방법에 대한 실시간 Mode 기술 가이드 를 검토하세요. 스트리밍 워크로드에 대한 실시간 처리를 활성화하는 데 필요한 모든 것을 찾을 수 있습니다.

 

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

게시물을 놓치지 마세요

관심 있는 카테고리를 구독하고 최신 게시물을 받은편지함으로 받아보세요