MySQL ‐ Operational‐Level System Design

실시간 변동 데이터 처리를 위한 스트리밍 데이터 처리 기법

1. Data Collection — 데이터가 발생하는 곳

• Web/App Server : 사용자가 앱에서 클릭·검색·결제 → 서버가 "클릭 이벤트" 발생한다.
• IoT Device: 센서가 온도·위치 값을 계속 측정해서 발생한다.
• Database CDC : DB에 주문이 INSERT되면 그 변경을 감지해 이벤트가 발생(CDC = Change Data Capture, "DB 바뀐 것 실시간 감지")한다.

2. Stream Storage — 일단 큐에 모임(Kafka)

• 발생한 이벤트를 곧바로 처리하지 않고 메시지 큐(Kafka)에 잠깐 쌓는다.
  • 완충(버퍼) : 갑자기 트래픽이 폭주해도 큐가 받아내고, 뒷단은 자기 속도로 소비할 수 있다.
  • 분리(디커플링) : 데이터 만드는 쪽과 처리하는 쪽이 서로 몰라도 됨 → 독립적으로 확장·교체 가능하다.
  • 여러 소비자 : 같은 이벤트를 여러 시스템이 나눠 읽을 수 있다.

3. Stream Processing — 실시간으로 가공(Flink)

• 스트림 프로세서가 큐에서 이벤트를 도착하는 즉시 꺼내서 계산한다.
• 데이터가 오는 순간 바로 처리해서 지연이 초 단위이다.

4. Data Serving — 결과를 여러 곳에서 사용

• 가공한 결과를 필요한 곳으로 팬아웃(fan-out)한다.

즉, 여러 소스에서 끊임없이 발생한 데이터를 Kafka에 모아 완충하고 스트림 프로세서가 즉시 가공해서 대시보드·알림·ML·DW 등 여러 곳에 실시간으로 공급하는 구조를 만들 수 있다.

수천억대 데이터 처리를 위한 초대용량 배치 처리 방법

• 기존 배치는 스케줄러가 하나의 INSERT ... SELECT를 던지고, 스캔·그룹핑·집계·저장을 전부 운영 MySQL이 처리하는 구조다.
• 데이터가 수천만 건일 때는 버티지만, 수억 ~ 수천억 건으로 늘면 세 갈래로 무너진다.
  • 처리 시간 증가 : 단일 스레드·단일 노드로 전 구간을 순차 스캔·집계 → 데이터가 커질수록 배치 윈도우를 초과한다.
  • DB 부하 → 서비스 영향 : 대량 스캔이 버퍼풀·I/O·CPU를 점유해 같은 DB를 쓰는 실서비스 응답이 함께 느려진다.
  • 장애 대응의 어려움 : 한 트랜잭션으로 8시간 돌다 실패하면 처음부터. 재시작·부분복구·멱등성 보장이 어렵다.

해결 개념 - 연산을 DB 밖으로 위임한다

• DB에게 집계를 시키지 말고, 데이터만 병렬로 꺼내와 밖에서 나눠 계산한다.
• Spark가 이 문제에 주는 두 가지 실질 이점이 있다.
  • 계산 위임 — GROUP BY·SUM 같은 무거운 연산을 MySQL이 아니라 Spark 클러스터가 수행한다.
  • 병렬 데이터 로딩 — 하나의 큰 테이블을 order_id 범위로 쪼개 여러 Executor가 동시에 나눠 읽는다. 순차 스캔이 병렬 스캔으로 바뀐다.

1. 병렬 읽기용 뷰 정의

• MySQL의 orders를 partitionColumn 기준으로 쪼개 여러 Executor가 동시에 읽도록 임시 뷰를 만든다.
• numPartitions만큼의 범위 쿼리가 병렬로 나간다.

CREATE OR REPLACE TEMPORARY VIEW orders_view
USING "jdbc" OPTIONS (
  url             "jdbc:mysql://mysql-server:3306/service_db",
  dbtable         "orders",
  partitionColumn "order_id",   -- 나눌 기준 (숫자·PK 권장)
  lowerBound      "1",          -- 최소값
  upperBound      "100000000",  -- 최대값
  numPartitions   "100"         -- 100개로 분할 → 병렬 읽기
);
-- Executor 1  : WHERE order_id >= 1        AND order_id < 1000000
-- Executor 2  : WHERE order_id >= 1000000  AND order_id < 2000000
-- Executor 100: WHERE order_id >= 99000000 AND order_id <= 100000000

2. 집계는 Spark 엔진이 수행한다.

• 이 쿼리는 더 이상 MySQL이 아니라 Spark 엔진이 인메모리로 실행한다.
• WHERE created_at 조건은 Predicate Pushdown으로 읽기 단계에서 DB에 밀어넣어 스캔량을 줄이고, GROUP BY는 노드 간 셔플링을 거쳐 집계된다.

CREATE OR REPLACE TEMPORARY VIEW daily_summary AS
SELECT product_id,
       SUM(sale_price * quantity) AS total_amount,
       COUNT(*)                    AS total_count
FROM orders_view
WHERE created_at >= '2024-05-20 00:00:00'
  AND created_at <  '2024-05-21 00:00:00'   -- ← Predicate Pushdown
GROUP BY product_id;                        -- ← Shuffle 발생

3. 결과를 분석 DB에 저장한다.

• 집계 결과는 운영 DB가 아닌 별도의 분석용 DB에 적재해 서비스와 격리한다.

INSERT INTO analytics_db.daily_product_sales
SELECT * FROM daily_summary;

실시간 데이터 동기화를 위한 디자인 설계 패턴

견고한 비동기 작업을 위한 MySQL 작업 큐 활용법

MySQL - NoSQL을 결합한 시스템 아키텍처 설계