실시간 처리 기술

이 문서는 선행 지식 섹션의 일부입니다.

​

왜 실시간 처리가 필요한가요?

​

실시간 처리의 핵심 구성 요소

​

Apache Kafka

​

개념

💡 Apache Kafka 는 LinkedIn에서 개발한 분산 이벤트 스트리밍 플랫폼 입니다. 초당 수백만 건의 이벤트를 안정적으로 수집하고, 여러 소비자에게 전달할 수 있습니다. 현재 전 세계 Fortune 500 기업의 80% 이상이 사용하고 있습니다.

​

핵심 개념

​

Kafka의 특징

​

관련 솔루션

​

스트림 처리 엔진

​

Apache Spark Structured Streaming

💡 Spark Structured Streaming 은 Apache Spark의 스트리밍 모듈로, 마이크로 배치(Micro-Batch) 방식으로 스트리밍 데이터를 처리합니다. 배치 코드와 동일한 DataFrame API를 사용할 수 있어서, 배치→스트리밍 전환이 매우 쉽습니다.

# Kafka에서 주문 이벤트를 실시간으로 읽어서 Delta 테이블에 저장
df = (spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "broker:9092")
    .option("subscribe", "orders")
    .load()
)

# JSON 파싱 및 변환
from pyspark.sql.functions import from_json, col
schema = "order_id LONG, customer_id LONG, amount DOUBLE, ts TIMESTAMP"

orders = (df
    .select(from_json(col("value").cast("string"), schema).alias("data"))
    .select("data.*")
)

# Delta Lake에 스트리밍으로 저장
(orders.writeStream
    .format("delta")
    .outputMode("append")
    .option("checkpointLocation", "/checkpoints/orders")
    .toTable("catalog.schema.streaming_orders")
)

​

Apache Flink

💡 Apache Flink 는 진정한 이벤트 단위(Event-at-a-time) 스트리밍 처리 엔진입니다. 이벤트가 도착하는 즉시 하나씩 처리하므로, Spark의 마이크로 배치보다 더 낮은 지연 시간(밀리초 수준)을 달성할 수 있습니다.

​

Spark Streaming vs Flink 비교

💡 체크포인트(Checkpoint)란? 스트리밍 처리의 현재 진행 상태(어디까지 읽었고, 어떤 집계 값을 가지고 있는지)를 주기적으로 저장하는 것입니다. 장애가 발생하면 마지막 체크포인트부터 재시작하여 데이터 유실 없이 처리를 이어갈 수 있습니다.

​

이벤트 드리븐 아키텍처 (EDA)

​

개념

💡 이벤트 드리븐 아키텍처(Event-Driven Architecture, EDA) 란 시스템의 구성 요소들이 이벤트 를 중심으로 통신하는 아키텍처 패턴입니다. A 서비스에서 발생한 이벤트를 Kafka 같은 메시지 큐에 발행하면, 관심 있는 다른 서비스들이 이를 구독하여 처리합니다.

​

EDA의 장점

​

Databricks에서의 실시간 처리

​

Kafka를 직접 운영해본 경험 — ZooKeeper의 고통

​

ZooKeeper 관리의 고통

🆕 KRaft 모드 (2024~): Kafka 3.3 이후부터 ZooKeeper 없이도 동작하는 KRaft(Kafka Raft) 모드가 도입되었습니다. Kafka 4.0부터는 ZooKeeper가 완전히 제거될 예정입니다. 새로 구축하는 경우 KRaft를 사용하시는 것을 권장합니다.

​

파티션 리밸런싱의 악몽

💡 현업에서는 이렇게 합니다: 파티션 수는 “현재 필요한 수의 23배”로 넉넉하게 설정합니다. 나중에 늘리는 것은 가능하지만, 줄이는 것은 토픽을 재생성해야 하므로 매우 번거롭습니다. 일반적으로 토픽당 파티션 612개로 시작하고, Consumer 수에 맞춰 조정합니다.

​

Kafka 비용의 현실

💡 이것을 안 하면…: Kafka 모니터링을 설정하지 않으면, Consumer Lag(소비 지연)이 쌓이고 있는지 알 수 없습니다. 어느 날 갑자기 “실시간 대시보드가 3시간 전 데이터를 보여주고 있다”는 보고를 받게 됩니다. 최소한 Consumer Lag, Broker Disk Usage, ISR Shrink 이 세 가지는 반드시 모니터링하세요.

​

”실시간이 필요하다고 생각했는데, 마이크로배치로 충분했던 경우”

​

진짜 실시간(밀리초) vs 니어 실시간(초분) vs 마이크로배치(분시간)

💡 현업에서는 이렇게 합니다: 고객이 “실시간”이라고 말할 때, 실제로 의미하는 것은 대부분 “1시간 전 데이터가 아니라 5분 전 데이터를 보고 싶다”입니다. 이 정도의 요구사항은 Spark Structured Streaming의 마이크로배치(수 초~수 분 간격)로 충분히 충족됩니다. 진짜 밀리초 수준의 실시간이 필요한 경우는 전체 워크로드의 5% 미만입니다.

​

Databricks Structured Streaming과의 연결

Kafka → Spark Structured Streaming → Delta Lake (Bronze → Silver → Gold)
                                        ↓
                              SQL Warehouse → AI/BI Dashboard

# Databricks에서 Kafka → Delta Lake 실시간 파이프라인 (간단 버전)
(spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "broker:9092")
    .option("subscribe", "orders")
    .option("startingOffsets", "latest")
    .load()
    .selectExpr("CAST(value AS STRING) as json_str")
    .writeStream
    .format("delta")
    .option("checkpointLocation", "/checkpoints/orders_bronze")
    .outputMode("append")
    .toTable("catalog.schema.orders_bronze")
)

-- SDP에서는 SQL만으로 스트리밍 테이블을 정의할 수 있습니다
CREATE STREAMING TABLE orders_bronze
AS SELECT * FROM STREAM read_kafka(
    bootstrapServers => 'broker:9092',
    subscribe => 'orders'
);

CREATE STREAMING TABLE orders_silver
AS SELECT
    from_json(value, 'order_id LONG, customer_id LONG, amount DOUBLE') AS parsed
FROM STREAM orders_bronze;

💡 현업에서의 판단 기준: “마이크로배치로 충분한 워크로드에 Flink를 도입하면, 시스템 복잡성만 증가하고 ROI가 나오지 않습니다.” Databricks를 이미 사용 중이라면, Structured Streaming부터 시작하고, 정말 밀리초 수준의 지연이 필요한 워크로드만 Flink로 분리하는 것이 현실적입니다.

​

실시간 처리 아키텍처 패턴

​

Lambda 아키텍처

💡 Lambda 아키텍처 는 배치 레이어 와 스피드 레이어(실시간)를 분리하여, 각각의 장점을 활용하는 아키텍처입니다. 배치는 정확성을, 스피드는 속도를 담당합니다.

​

Kappa 아키텍처

💡 Kappa 아키텍처 는 모든 데이터를 스트리밍으로만 처리 하는 아키텍처입니다. 배치 처리가 필요하면, 과거 이벤트를 Kafka에서 다시 읽어서(재처리) 스트리밍 파이프라인으로 처리합니다.

​

Delta 아키텍처 (Databricks 권장)

​

아키텍처 선택 가이드

💡 현업에서는 이렇게 합니다: “어떤 아키텍처를 선택할지” 고민하기보다, “Databricks + Delta Lake를 쓴다면 Delta 아키텍처가 자동으로 따라온다”고 생각하시면 됩니다. Structured Streaming으로 실시간 데이터를 Delta에 쓰고, 같은 테이블을 배치 잡으로도 읽고 쓸 수 있으므로, 별도의 아키텍처 설계가 크게 필요하지 않습니다.

​

실시간 처리 도입 시 체크리스트

💡 현업에서는 이렇게 합니다: 실시간 처리를 처음 도입할 때는, 전체 파이프라인을 한 번에 실시간으로 전환하지 마세요. 가장 비즈니스 임팩트가 큰 하나의 파이프라인을 먼저 실시간으로 전환하고, 안정화된 후에 점진적으로 확대하는 것이 현실적입니다.

​

정리

​

참고 링크

• Apache Kafka Official
• Apache Flink Official
• Databricks: Structured Streaming
• Confluent: Kafka 101
• Databricks Blog: Streaming