Published 2022. 9. 4. 18:15

Snowflake 가 준비하고 있는 새로운 패러다임. Unistore

금번 snowflake에서 주관한 Data cloud world tour에 참가했다가 인상 깊은 세션을 보게 되어 해당 세션 내용을 기록한다.

unistore는 snowflake와 adobe 가 함께 개발 중인 idea로 작성하는 현재는 priviate test 가 진행 중이며 한국에는 2023년 상반기 beta , GA는 2023년 후반기에 예정되어 있다.

현재까지 일궈낸 성과는 아래와 같다고 한다.

분석 워크로드에 대한 고성능을 유지
높은 동시성(100 ~ 1000 QPS)과 응답 시간(50~100ms)
GDPR 규정 준수 지원
시스템의 확장성과 손쉬운 관리 및 사용기능 제공

현세대 데이터 베이스 운영 전략과 문제

대부분의 회사는 자사 서비스와 데이터의 특징과 환경에 맞게 cloud 환경을 사용하거나 On-premise 환경을 구축하지만 OLTP를 위한 database (이하 Transactional DB)와 OLAP를 위한 database (이하 Analytical DB)를 따로 운영하고 있다는 공통점이 있다. OLTP와 OLAP에 대한 개념을 간단히 정리하면 아래와 같다.

OLTP
- OnLine Transactional Processing
- 데이터가 “건” 단위로 들어오는 것으로 이해하면 쉬움
- key값을 기준으로 millisecond 단위로 database에 (특히) Insert, Update, Delete 작업이 발생
- 데이터의 무결성 보장이 굉장히 중요함
- Row database 가 유리함
OLAP
- OnLine Analytical Processing
- 대용량 데이터를 한 번에 처리하는 것을 목표로 하며 굉장히 복잡하고 많은 집계가 포함되는 Select 작업 처리가 중요함
- 데이터의 처리보다 조회(분석)가 중요하기 때문에 처리 속도의 중요성이 상대적으로 떨어짐
- Column database 가 유리함
- 일반적으로 OLAP는 Transactional DB의 데이터를 batch job으로 ETL 한 DW(Analytical DB)에서 이뤄지기 때문에 기본적으로 무결하다는 것을 전제하고 진행됨

이렇게 두 데이터 처리방식의 특징과 목적이 명확히 다르기 때문에 그에 맞는 DB를 선택하여 운용하게 되는 것인데, Transactional DB와 Analytical DB를 별도로 운영하면서 생기는 문제는 다음과 같다.

시스템 운영 및 관리의 어려움
- 운영 관리 영역이 분리되며 자연스럽게 데이터 사일로가 생성되는 문제가 있음
- 일관된 보안/정책 관리 유지가 어렵고 거버넌스 관리가 어려워짐
대용량 데이터 통신의 지연 및 정합성 이슈
- 서로 다른 시스템 간의 데이터 이동에서 필연적으로 발생되는 복잡도의 증가
- 양 데이터베이스 간의 최신화 격차(이로 인해 실시간 분석이 불가능하다)
신규 기능 개발의 복잡도 증가
- 사업 운영에 따른 새로운 기능/서비스/데이터의 추가로 인해 시스템은 갈수록 복잡해지며 이로 인해 신규 기능의 개발과 데이터 활용 난이도가 점점 증가함

Snowflake의 제안 : Unistore

Unistore 소개

Transactional Data와 Analytical Data를 하나의 단일 플랫폼(데이터베이스)에서
함께 사용하고자 하는 가장 현대적인 방식

사실 말은 굉장히 쉬운데 이런 환경이 등장하지 않았던 것은 앞서 언급했듯 OLTP를 위한 환경과 OLAP를 위한 환경의 특성이 너무나도 상이해서 쉽게 섞일 수 없기 때문이다. snowflake에서는 unistore를 통해 이를 해결하고자 하며 아래와 같은 이점을 취할 수 있다고 소개한다.

Transactional Workloads를 직접 연결하여 엔터프라이즈 앱을 개발하고 데이터를 수집 및 활용 가능하게 함
Transactional data를 즉시 분석할 수 있도록 하여 “실시간 분석”이 가능하도록 함
시스템 전반의 아키텍처를 극히 단순화할 수 있으며 데이터의 이동 흐름을 제거하기 때문에 확장성과 거버넌스 관리 등 많은 부분에서 이점을 가져갈 수 있음

snowflake 가 이러한 기술 구현의 근거로 드는 것은 자사의 Optimizer이다.

우리가 SQL 수행 명령(Execution order)을 내리면 DB는 입력된 SQL을 가장 빠르고 효율적으로 수행할 최적(최저비용)의 처리경로(Execution Plan)를 생성하는데, 이러한 역할을 수행하는 DBMS 내부의 핵심 엔진을 Optimizer 라 부른다.

Optimizer는 크게 Rule based , Cost based가 있고, 최근에는 Self learning의 방식이 포함된 DBMS가 많다. 평가 요소는 여러 액세스 방법(full scan or index scan), 다양한 조인 방법(hash join, loop join etc)과 조인 순서 및 가능한 변환 등을 검사하여 평가한다.

Rule based
- 평가요소를 통해 이미 정해진 규칙을 따라 plan을 선정함
- 정해진 규칙을 따르기 때문에 Heuristic optimizer라고도 한다
Cost based
- 각 계획과 실행 단계에 점수를 부여하여 최종합이 가장 낮은 plan을 선정함
- 대부분의 DBMS 가 이러한 방법을 사용하고 있음
Self learning
- 앞선 모든 방법은 결국 “예상되는 비용”이 기반인데, 실제 기록과 예상 기록의 차이를 기반으로 optimizer 스스로 지속적으로 보정해 성능을 강화하는 방식

이미 알려져 있듯이 snowflake는 Column database를 제공하고 있다. 실제 데이터는 OLTP 과정을 거치며 row 단위로 저장하지만 이를 background에서 변환하여 사용자에게는 column DB 형태로 제공하고 있다고 한다. (쿼리를 날리는 유저 입장에서는 row 단위로 저장된 DB가 background 가 된다.)

unistore 개념이 적용된다면 snowflake 는 요청된 SQL을 분석하여 optimizer 가 어떤 작업인지 판단하고, 어떤 처리 방식이 효과적이기 때문에 어디서 데이터를 조회하고 처리해야 최적의 결과를 얻을 수 있는지 선정할 수 있다고 한다.

즉, OLTP 성 요청이라면 row base로 저장된 state에, OLAP성 요청이라면 column base로 저장된 state에 요청한다는 것! 물론 이 모든 것은 snowflake의 시스템 안에서 수행되기 때문에 사용자는 알아서 잘 수행된 쿼리의 결과만 확인하면 된다.

Hybrid table

Unistore를 구현하기 위한 snowflake에서 제안하는 새로운 형태의 테이블

Create HYBRID TABLE CustomerTable (
    customer_id int primary key,
    name varchar(256),
    ...
)

기능을 구현하는데 필요한 구문이 기존 DDL, DML과 동일하다는 것이 굉장히 인상적이다.

이러한 Hybrid table의 핵심 기능은 아래 5가지 항목이 있다.

PK 존재
- 각 테이블은 Primary key를 갖기 때문에 기존 PK를 통해 table을 관리 및 검증하던 방식을 그대로 가져갈 수 있음
FK 존재
- 테이블 간의 관계성을 지속적으로 유지하여 잘못된 수정을 방지할 수 있음
참조 무결성
- 데이터 적재 전 데이터의 유효성을 검증함
Secondary indexes의 존재
- 성능 향상을 위해 PK 이외의 index를 활용할 수 있음
Join free
- 다른 Hybrid table 뿐 아니라 기존에 snowflake에서 제공하는 DW table 과의 Join 도 지원함

감상

optimizer 가 sql 요청을 보고 OLTP 작업인지 OLAP 작업인지 확인하여 데이터를 관리(정확히는 관리하는 것은 아니지만 어디서 데이터를 꺼내올지, 업데이트할 지 결정한다는 측면에서) 한다는 것이 가능한게 놀라웠다. 다만 처음엔 완전히 새로운 개념과 구조의 DB 를 상상했는데 실제로는 두개의 DB를 같이 두고 선택적으로 골라 쓰는 느낌에 가까워 보여서 조금은 아쉽다. 물론 서버리스로 제공되니 사용자 입장에서는 두 기능을 모두 잘 소화하는 새로운 개념의 DB인 것은 맞는 것 같고 이러한 아이디어를 실제로 구현해냈다는 것 자체가 참 대단한 것 같다.

실제로 적용하게 된다면 데이터 분석가/과학자 입장에서는 기존 환경의 변화의 체감 없이 실시간 데이터 분석과 모델의 개발 및 서빙이 가능할 것이며 이를 통해 현재보다 다양한 가치의 창출이 가능할 것이다.

엔지니어 입장에서는 시스템 아키텍처를 획기적으로 줄여 운영 관리를 더욱 효율적으로 할 수 있어 긍정적이다. (물론 초기 아키텍쳐 재구축 작업은 다소 불편하겠지만) unistore 개념 자체가 기존과 완전히 다른 방법으로 제어하는 것이 아니기 때문에 러닝 커브가 크지는 않을 것 같다.