[DATA] Spark 4.1 Real-Time Mode(RTM), Micro-batch보다 빠를까? 구조와 도입 조건

핵심 요약: Apache Spark는 4.1부터 Real-Time Mode(RTM)를 도입해 일부 스트리밍 작업을 지속적으로 처리할 수 있게 됐다. 기존 Micro-batch가 초·분 단위 분석 ETL에 적합하다면, RTM은 밀리초 수준의 지연시간이 중요한 서비스에서 검토할 만한 선택지다. 다만 지원 연산과 입출력 시스템에 제약이 있어 무조건 교체하는 방식은 적절하지 않다.

1. 기존 Spark Streaming은 무엇이 문제였을까?

Structured Streaming의 기본 실행 모델은 Micro-batch다. Kafka 등에 쌓이는 이벤트를 작은 배치로 나눠 읽고, 각 배치에 대한 처리 계획을 실행한다. 대용량 ETL에 효율적이지만 배치 시작과 종료에 따른 오버헤드가 존재한다.

예를 들어 광고 클릭 로그를 1분마다 집계해 데이터 마트에 적재한다면 충분히 실용적이다. 반면 결제 이상 거래를 이벤트 발생 직후 판단해야 한다면 이 지연시간이 부담될 수 있다.

실무 해석: 여기서 문제는 Spark가 느리다는 것이 아니라 작업의 지연시간 목표가 서로 다르다는 점이다.

2. RTM은 어떻게 달라졌을까?

Apache Spark 공식 문서는 Micro-batch를 분석용 스트리밍, RTM을 저지연 운영용 스트리밍에 적합한 모델로 구분한다. RTM은 이벤트가 도착하는 동안 처리 파이프라인이 계속 실행되도록 설계됐다. 일부 Stateless 처리에서 한 자릿수 밀리초 지연시간을 달성할 수 있다고 설명하지만, 이는 모든 워크로드의 보장값이 아니다. [공식 소개]

항목	Micro-batch	Real-Time Mode
실행 모델	작은 배치 반복	연속 처리
주요 사용처	ETL, 마트 집계	즉시 판단·알림
지연시간 목표	주로 초~분	초 미만 지향
확인할 사항	배치 간격·처리량	지원 API·비용·지연시간

3. 실행 흐름 비교

Micro-batch: Kafka → 일정 구간의 레코드 묶음 → Spark 배치 처리 → Sink

RTM: Kafka → 지속 실행 중인 Spark 처리 파이프라인 → Sink

RTM에서도 체크포인트와 실행 경계가 사라지는 것은 아니다. 중요한 것은 개별 레코드의 전달이 매 Micro-batch 완료를 기다리는 구조와 달라진다는 점이다.

4. 설정 예시: Trigger만 바꾸면 될까?

다음은 Apache Spark 공식 문서의 Scala API 형태를 바탕으로 단순화한 예시다. 직접 실행한 성능 테스트 결과는 아니다.

Micro-batch 예시

df.writeStream
  .format("kafka")
  .option("kafka.bootstrap.servers", "localhost:9092")
  .option("topic", "output-topic")
  .trigger(Trigger.ProcessingTime("1 second"))
  .start()

RTM 예시

df.writeStream
  .format("kafka")
  .option("kafka.bootstrap.servers", "localhost:9092")
  .option("topic", "output-topic")
  .outputMode("update")
  .trigger(Trigger.RealTime("5 minutes"))
  .start()

RealTime("5 minutes")는 데이터를 5분 동안 모았다가 처리한다는 뜻이 아니다. RTM의 실행 구간을 지정하는 값이며, 그동안 데이터는 연속 처리된다. 또한 RTM은 update 출력 모드와 지원되는 Source·Operator·Sink 조합을 요구한다. 모든 기존 스트리밍 코드가 Trigger 교체만으로 동작하는 것은 아니다. [공식 설명]

5. 실제 데이터 엔지니어링에서 어디에 적용할까?

사례 A. 광고 성과 집계

클릭·주문 이벤트를 수집해 5분 또는 1시간 단위로 집계하고 DW에 반영한다. 수 초 또는 수 분 지연을 허용할 수 있다면 Micro-batch가 운영 비용 면에서 더 합리적일 수 있다.

사례 B. 이상 거래 탐지

Kafka에 들어온 이벤트를 파싱·필터링해 즉시 후속 시스템으로 전달한다. 낮은 지연시간이 핵심이라면 RTM의 후보 작업이 된다. 다만 복잡한 상태 기반 집계, 외부 API 호출, 저장소 쓰기까지 포함한 전체 지연시간은 별도로 측정해야 한다.

6. 도입 전에 확인할 체크리스트

• 실제 SLA가 100ms인지, 1초인지, 1분인지 먼저 정할 것
• 사용하는 Spark 버전에서 Source·Operator·Sink가 RTM을 지원하는지 확인할 것
• Kafka 수신부터 Sink 반영까지 End-to-End Latency를 측정할 것
• 동일 입력량에서 처리량, CPU·메모리, 운영 비용을 Micro-batch와 비교할 것
• 장애 재시작과 체크포인트 복구 동작을 검증할 것

테스트 상태 및 한계: 이 글은 공식 문서를 정리한 기술 분석이며, 별도 클러스터에서의 벤치마크는 진행하지 않았다. 실제 지연시간과 지원 범위는 Spark 버전, 코드, 데이터 소스, 환경에 따라 달라진다.

7. 결론

RTM의 핵심은 Spark 하나로 분석용 ETL과 저지연 이벤트 처리의 선택지를 넓혔다는 것이다. 그러나 기존 Micro-batch를 무조건 RTM으로 전환할 이유는 없다. 요구 지연시간·지원 기능·리소스 비용을 측정하고 선택하는 것이 실무적으로 중요하다.

---

원문 및 참고 자료

• Apache Spark — Structured Streaming 소개
• Apache Spark — Real-Time Mode 개발 문서 (In-progress 문서, 버전별 지원 범위 확인 필요)

작성: 2026-10-26 | 기준: Apache Spark 공식 문서 | 최종 수정: 2026-10-26