[Azure] 혼자 다 하던 MSSQL, 나눠서 하는 ADX

ADX가 빠른 3가지 이유

Azure Data Explorer(ADX)는 대규모 로그·시계열 데이터를 수초 만에 분석할 수 있는 서비스이다.
수억 ~ 수조 행 데이터를 이렇게 빠르게 처리할 수 있는 이유는 크게 3가지이다.

핵심	설명
분산 처리	데이터를 여러 컴퓨터(노드)에 나눠 저장하고, 동시에 처리
열(Column) 기반 저장	필요한 컬럼만 읽어서 I/O 최소화
자동 압축	같은 타입의 데이터가 모여있어 압축률이 높고, 읽는 양이 줄어듦

💡 비유
MSSQL은 혼자서 시험지 100장을 채점하는 선생님이고, ADX는 선생님 4명이 25장씩 나눠서 동시에 채점하는 구조이다!

 

 

ADX 클러스터 구조

ADX의 내부는 계층 구조로 되어있다.
가장 바깥이 클러스터, 그 안에 노드, 데이터베이스, 테이블, 그리고 물리적 저장 단위인 Extent가 있다.

개념	비유	설명
클러스터 (Cluster)	🏢 학교 건물 전체	ADX 서비스의 최상위 단위. 여러 노드의 묶음
노드 (Node)	🏫 교실 하나	실제 연산을 수행하는 컴퓨터 1대
데이터베이스	📚 과목	클러스터 안에서 논리적으로 데이터를 나누는 단위
테이블	📖 교과서	실제 데이터가 저장되는 단위
Extent (샤드)	📄 교과서의 챕터	테이블 데이터의 물리적 조각. 각 노드에 분산 저장

 

 

Extent - ADX의 핵심 저장 단위

Extent는 ADX에서 데이터가 실제로 저장되는 물리적 조각이다.
하나의 테이블은 수십~수만 개의 Extent로 나뉘어 여러 노드에 분산 저장된다.

💡 비유
도서관에 책이 1만 권이 있을 때, 한 서가에 1만 권을 다 꽂으면 찾기 힘들다.
대신 100권씩 묶어서 100개 서가에 분산해놓으면 여러 사서가 동시에 찾을 수 있다!

Extent 분배 구조

KQL 쿼리 실행 시 병렬 처리

 

 

열(Column) 기반 저장

MSSQL과 ADX는 데이터를 저장하는 방식이 근본적으로 다르다.
이 차이가 집계 쿼리 속도에 직접적인 영향을 준다.

💡 비유
행 기반은 학생 성적표를 학생별로 정리한 것이고, 열 기반은 과목별로 정리한 것이다.
"수학 전체 평균"을 구하려면 과목별 정리(열 기반)이 훨씬 빠르다!

구분	행 기반 (MSSQL)	열 기반 (ADX)
특정 컬럼 집계	모든 컬럼을 읽어야 함 (느림)	해당 컬럼만 읽음 (빠름)
한 행 전체 조회	한 번에 읽음 (빠름)	여러 컬럼을 합쳐야 함
UPDATE / DELETE	자유로움	거의 불가
압축 효율	보통	같은 타입이 모여있어 압축률 높음

 

 

핫 캐시 vs 콜드 스토리지

ADX는 데이터를 두 계층으로 나눠서 저장한다.
자주 조회하는 최근 데이터는 빠른 곳에, 오래된 데이터는 저렴한 곳에 보관하는 구조이다.

💡 비유
핫 캐시는 책상 위에 올려둔 서류 - 바로 꺼내 볼 수 있다.
콜드 스토리지는 창고에 보관한 서류 - 찾으러 가야 하지만 공간은 훨씬 넓고 저렴하다!

정책 설정 방법

// 핫 캐시 기간 설정 (최근 30일만 핫 캐시에 보관)
.alter table ServerMetrics policy caching hot = 30d

// 보존 기간 설정 (365일 이후 데이터는 자동 삭제)
.alter table ServerMetrics policy retention softdelete = 365d

구분	핫 캐시	콜드 스토리지
저장 위치	노드의 SSD / 메모리	Azure Blob Storage
조회 속도	🔥 초고속	❄️ 느림 (그래도 조회 가능)
비용	비쌈 (노드 자원 사용)	저렴 (Blob 요금만)
용도	최근 데이터 (자주 조회)	과거 데이터 (가끔 조회)

 

 

Ingestion - 데이터가 ADX에 들어가는 방법

💡 비유
공장(ADX)에 원재료(데이터)를 넣는 방법이다.
대형 트럭으로 한꺼번에 배달(배치)할 수도 있고, 컨베이어 벨트로 실시간 투입(스트리밍)할 수도 있다.

방식	비유	특징	용도
배치 Ingedtion	🚛 대형 트럭 배달	데이터를 모아서 한꺼번에 적재. 약간의 지연 (수 분)	대부분의 로그 데이터
스트리밍 Ingestion	🏭 컨베이어 벨트	발생 즉시 적재. 거의 실시간	실시간 모니터링 / 알림

✅ 참고
배치 Ingestion이 기본이고 대부분의 경우에 충분하다.
스트리밍은 "1초라도 빨리 봐야 하는" 실시간 대시보드 같은 곳에 사용한다.

 

 

Extent의 생애주기

Extent는 단순히 만들어지고 끝나는게 아니다.
생성 → 병합 → 이동 → 삭제까지 생애주기가 있다.

💡 비유
Extent는 택배 상자이다.
처음에 작은 상자로 들어오는데, ADX가 자동으로 작은 상자들을 큰 상자로 합치고, 오래된 상자는 창고로 보내고, 기한 지난 건 폐기한다.

왜 병합(Merge)가 중요한가?

💡 비유
편의점에서 물건 찾을 때, 작은 상자 10개를 뒤지는 것보다 큰 상자 3개에서 찾는 게 빠르다.
그래서 ADX가 자동으로 정리해주는 거다!

 

 

쿼리 실행 과정과 Extent Pruning

KQL 쿼리를 날렸을 때 ADX 내부에서 벌어지는 일을 상세하게 보자.

Extent Pruning - 쿼리 성능의 핵심!

각 Extent에는 "이 Extent에 저장된 데이터의 시간 범위" 같은 메타데이터가 기록되어 있다.
ADX는 이 정보를 보고 쿼리와 관련 없는 Extent를 아예 읽지 않는다.

💡 비유
도서관에서 "이번 주에 들어온 책"을 찾을 때, 전체 서가를 다 뒤지는 게 아니라 "신간 코너"만 보는 것과 같다.

💡KQL에서 where Time > 조건을 가장 먼저 거는 것이 성능 최적화의 1순위!

-- 좋은 패턴 - Time 필터가 위에 있음 (Pruning 가능)
ServerMetrics
| where Time > ago(1d)
| where DeviceId == "SRV-01"
| summarize avg(CPU) by bin(Time, 1h)


-- 나쁜 패턴 - Time 필터 없이 전체 스캔
ServerMetrics
| where DeviceId == "SRV-01"
| summarize avg(CPU) by bin(Time, 1h)

 

 

파티셔닝 정책 (Data Partitioning)

기본적으로 ADX는 Ingestion 시간순으로 Extent를 생성한다.
하지만 특정 컬럼 기준으로 자주 조회한다면, 해당 컬럼 기준으로 Extent를 나눌 수 있다.

종류	용도	설명
Hash	고유 ID 기준 조회가 많을 때	DeviceId, UserId 등으로 균등 분배
UniformRange	시간/숫자 범위 조회가 많을 때	날짜 범위, 숫자 구간 기준 분배

⚠️ 주의
파티셔닝은 아무 때나 쓰면 안된다!
데이터가 수십억 행 이상이고, 특정 컬럼 필터 쿼리가 매우 자주 사용될 때만 효과적이다.
데이터가 크지 않거나 기본 Pruning으로 충분히 빠르다면 오히려 불필요한 오버헤드만 생긴다.

💡 비유
파티셔닝은 도서관의 서가를 장르별로 분류하는 것이다.
장르별 검색이 잦으면 효과적이지만, 이미 서가가 작으면 분류하는 비용이 더 클 수도 있다!

 

 

Materialized View (구체화된 뷰)

자주 쓰는 집계 결과를 미리 계산해서 저장해두는 기능이다.

💡 비유
매일 아침 출근해서 "어제 서버별 평균 CPU"를 확인한다고 치자.
매번 원본 데이터를 처음부터 계산하는 게 일반 쿼리라면, 미리 계산해서 요약본을 만들어두는 게 Materialized View이다.

// Materialized View 생성
.create materialized-view ServerMetricsHourly on table ServerMetrics
{
    ServerMetrics
    | summarize avg(CPU), max(Memory) by DeviceId, bin(Time, 1h)
}

구분	일반 쿼리	MATERIALIZED VIEW
실행 방식	매번 원본부터 집계	미리 집계된 결과 조회
속도	데이터 많으면 느림	항상 빠름
데이터 최신성	항상 최신	거의 실시간 (약간의 지연 가능)
추가 비용	없음	저장 공간 + 연산 비용

 

 

장애 대응 - 복제 (Replication)

노드 하나가 죽으면 데이터가 날아갈까?
아니다! ADX는 Extent를 여러 노드에 복제해서 보관한다.

Extent 복제 구조

노드 2가 장애 → 노드 4에 Ext 2 복제본이 있으니까 → 사용자는 장애를 느끼지 못한다!

설정	기본값	설명
Extent 복제 수	2	원본 1 + 복제본 1 = 항상 2 곳에 저장
노드 장애 시	자동 failover	복제본이 있는 노드가 대신 처리
노드 복구 후	자동 재균형	데이터가 다시 고르게 분배됨

💡 비유
중요한 서류를 원본 + 복사본 두 곳에 보관하는 것이다.
한 사무실에 불이 나도 다른 사무실에 복사본이 있으니까 업무가 멈추지 않는다!

 

 

MSSQL vs ADX 최종 비교

관점	MSSQL	ADX
아키텍처	단일 서버 (Scale-Up)	분산 클러스터 (Scale-Out)
저장 방식	행(Row) 기반	열(Column) 기반
데이터 단위	페이지 (8KB)	Extent (수백MB ~ 수GB)
확장 벙법	서버 사양 업그레이드	노드 추가
쿼리 언어	SQL	KQL
데이터 수정	✅ CRUD 모두 가능	❌ 거의 추가(Append)만
정확한 용도	서비스 운영 DB, 트랜잭션	로그 분석, 시계열 데이터
데이터 규모	수천만 ~ 수억 행	수십억 ~ 수조 행

 

 

References

주제	문서	링크
ADX 개요	Azure Data Explorer 소개	https://learn.microsoft.com/ko-kr/azure/data-explorer/data-explorer-overview
Extent (샤드)	Extents(데이터 샤드) 개요	https://learn.microsoft.com/ko-kr/kusto/management/extents-overview?view=microsoft-fabric
캐싱 정책	캐시 정책 (핫/콜드 캐시)	https://learn.microsoft.com/ko-kr/kusto/management/cache-policy?view=microsoft-fabric
보존 정책	보존 정책 (Retention)	https://learn.microsoft.com/ko-kr/kusto/management/retention-policy?view=microsoft-fabric
Ingestion 개요	데이터 수집 (Ingestion) 개요	https://learn.microsoft.com/ko-kr/azure/data-explorer/ingest-data-overview
파티셔닝 정책	데이터 파티셔닝 정책	https://learn.microsoft.com/ko-kr/kusto/management/partitioning-policy?view=microsoft-fabric
Materialized View	구체화된 뷰 (Materialized View)	https://learn.microsoft.com/ko-kr/kusto/management/materialized-views/materialized-view-overview?view=microsoft-fabric
Extent Merge 정책	병합 정책 (Merge policy)	https://learn.microsoft.com/ko-kr/kusto/management/merge-policy?view=microsoft-fabric