본문 바로가기
Database2026년 5월 16일5분 읽기

Materialize 1.0 — 스트리밍 SQL 프로덕션 도입 가이드

YS
김영삼
조회 84
Materialize 1.0 — 스트리밍 SQL 프로덕션 도입 가이드

핵심 요약

Materialize 1.0 GA 후 첫 분기. 핵심은 incremental view maintenance(IVM) — 일반 SQL의 VIEW가 실시간으로 변경분만 재계산되며 항상 최신 상태를 유지한다. Flink/ksqlDB 대비 SQL 그대로 쓸 수 있다는 점이 가장 크다. 단, 메모리 모델과 비용은 처음에 놀란다.

1. 핵심 개념 — 그냥 SQL인데 실시간

CREATE SOURCE orders
  FROM POSTGRES CONNECTION pg_conn (PUBLICATION 'mz_pub')
  FOR TABLES (orders, order_items);

CREATE SOURCE clicks
  FROM KAFKA CONNECTION kafka_conn (TOPIC 'clicks')
  FORMAT JSON;

CREATE MATERIALIZED VIEW user_revenue AS
SELECT u.id, u.country, SUM(oi.price * oi.qty) AS total
FROM users u
JOIN orders o ON o.user_id = u.id
JOIN order_items oi ON oi.order_id = o.id
WHERE o.created_at > NOW() - INTERVAL '7 days'
GROUP BY u.id, u.country;

이 뷰는 항상 최신. Postgres에서 INSERT가 들어오는 즉시 뷰가 갱신된다. SELECT 시 항상 0에 가까운 응답.

2. Postgres CDC 설정

-- Postgres 측
ALTER SYSTEM SET wal_level = logical;
CREATE PUBLICATION mz_pub FOR TABLE orders, users, order_items;

-- Materialize 측
CREATE CONNECTION pg_conn TO POSTGRES (
  HOST 'pg.internal',
  DATABASE 'prod',
  USER 'mz_repl',
  PASSWORD SECRET pg_pass,
  SSL MODE 'require'
);

주의: 초기 스냅샷이 큰 테이블(수억 행)에선 수 시간 걸린다. 운영 중인 DB의 WAL 슬롯 보관 용량 모니터링 필수.

3. 실측 — 레이턴시와 비용

워크로드처리량p50 lagp99 lag
단순 필터링 뷰180K msg/s12ms48ms
3-way 조인+집계42K msg/s96ms230ms
윈도우 함수+조인18K msg/s210ms520ms

비용: Standard 100cc 클러스터 월 $1,800. 위 워크로드 한 번에 처리. Flink 자체 운영 대비 인건비 빼면 비싸 보이지만 합치면 비슷.

4. Flink와 직접 비교

항목MaterializeFlink
학습곡선SQL만 알면 됨Java/SQL+상태 API
운영 인력0.2명1~2명
월 인프라+라이선스$1,800~$8,000$600~$3,000
복잡 윈도우기본 SQL만매우 유연
State 크기 한계메모리 제약 큼RocksDB로 큼

5. 비용이 폭증하는 패턴

  • 큰 카디널리티 GROUP BY: 사용자별 집계가 수천만이면 메모리 폭증
  • 윈도우 없는 조인: 양쪽 테이블 전체를 메모리에 들고 있어야 함
  • JSON 컬럼 빈번한 unnest: CPU 부담

6. 클러스터 분리 — 비용 통제

CREATE CLUSTER ingest SIZE = '50cc';
CREATE CLUSTER analytics SIZE = '200cc' REPLICATION FACTOR = 2;
CREATE CLUSTER serving SIZE = '25cc';

SET CLUSTER = analytics;
CREATE MATERIALIZED VIEW heavy_agg AS ...;

SET CLUSTER = serving;
CREATE INDEX ON heavy_agg (user_id);

7. 실패 시나리오

  • 스키마 변경: Postgres ALTER TABLE 후 소스 재생성 필요
  • 리허이드레이션: 클러스터 재시작 시 모든 뷰 재계산. 큰 뷰는 15~30분
  • WAL 슬롯 폭증: Materialize가 죽으면 Postgres WAL이 차오름. 알람 필수

8. 도입 결정

  • 좋음: 실시간 대시보드, 사기 탐지 룰, 개인화 점수, CDC 기반 read model
  • 유보: 메모리 제약 큰 워크로드, 복잡한 시간 윈도우 로직
  • 나쁨: 배치 ETL을 굳이 실시간으로 만들고 싶을 때

참고

  • materialize.com/docs
  • github.com/MaterializeInc/materialize

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록