[DEVOCEAN 테크세미나] IMDG 기반 Smart Factory 아키텍쳐링 연구 사례

세미나 링크

https://devocean.sk.com/vlog/view.do?id=428&vcode=A03 

In-Memory Data Grid 기반  Smart Factory 아키텍처링 연구 사례

 

용어 정리

1. Database vs Data Grid

Data Grid는 Database와 어떻게 다를까요? Data Grid의 경우 여러 data source를 통합한 view를 제공합니다. 여러 형식 (RDB, NoSQL, HDFS)에 저장된 데이터를 통합해 관리할 수 있습니다. 보통 많은 양의 데이터를 분석해야 할 때 사용하기 때문에, 이 과정에서 Distributed System(분산 시스템)을 활용합니다.

 

2. In-memory의 장점

 이 테크세미나의 주제는 In-Memory Data Grid (IMDG)의 활용입니다. 세미나에서 소개한 Hazelcast는 대표적인 IMDG 플랫폼입니다. 보통 우리는 데이터베이스에서 데이터를 디스크에 저장한다고 배웁니다. 하지만 메모리 계층 구조를 보면 알 수 있듯이, 메모리에 저장하면 디스크에 저장하는 것보다 빠른 데이터 처리가 가능합니다. (물론 비용이 더 비싸지긴 하지만...)

(Query Cost에서 Disk Seek, Disk Transfer 계산했던 학부 DB 안녕~) 

 

3. Distributed System과 Partition

분산시스템(Distributed System)은 뭘까요? 노드(컴퓨터)를 여러 대 활용해 데이터를 저장하는 방식이라고 생각하면 됩니다. 이런 자원들을 활용해, 분산시스템에서 데이터베이스는, 1. 큰 테이블 하나를 여러 노드에 나누어(partitioning) 저장하기도 하고, 2. 복제 테이블(replica table)을 만들어 다른 방식으로 노드들에 저장하기도 합니다.

1번의 목적은 Load Balancing(각 노드의 트래픽을 균등하게 배포해 최적화) 때문입니다. 특히 Hazelcast는 hash 기반 partitioning을 default로 설정해 데이터를 균등하게 분포합니다.

2번의 목적은 여러 노드들 중 하나가 어떤 사유로 사용할 수 없게 될 때도 정상적으로 쿼리가 동작할 수 있게 하기위함입니다.

예를 들어, Hazelcast 사용자가 2개의 노드를 생성해 record가 100인 table을 노드1에 1~50 / 노드2에 51~100로 partition하면 1번 목표를 달성할 수 있습니다.

또, 2번 목표를 위해 replica table을 만들 때 노드1에 1~50(source) & 51~100(replica) / 노드2에 51~100(source) & 1~50(replica) 로 설정할 수 있습니다.

 

4. Data Lake, Data Warehouse, Data Mart

셋 다 데이터를 저장하는 repository이나, storage 구조와 규모에 따라 차이가 있습니다.

Data Lake는 원시 데이터를 cost가 낮은 storage에 전부 저장하는 repository입니다. Amazon S3가 그 예시입니다.

Data Warehouse는 RDBMS와 같이 데이터를 처리해 저장한다는 점에서 Data Lake와 차이가 있습니다.

Data Mart는 데이터를 목적에 따라 소규모로 쪼개 저장한다는 점에서 Data Warehouse와 차이가 있습니다.

참고: https://aws.amazon.com/ko/compare/the-difference-between-a-data-warehouse-data-lake-and-data-mart/

 

5. ETL(Extract-Transform-Loading), CDC(Change Data Capture)

Source system(출발)과 Target system(도착)이 있다고 합시다. Source에서 여러 종류(RDB, NoSQL, File...)의 데이터를 받아서, Target(세미나에서는 Data Lakehouse (cost가 낮은 Data Lake의 이점, 정형화된 데이터를 갖는 Data Warehouse의 이점을 모두 가짐))에서 이를 활용합니다. 활용할 수 있는 데이터가 되기 위해서는 ETL 과정이 필요합니다.

Source에서 Extract(추출) 후, 데이터를 Transform(변환)한 후, Target에 Loading(적재)하는 순서입니다. 여기서, 한 번 Source에서 Target으로 가져왔다해서 끝이 아닙니다. Source의 데이터가 계속 변화하기 때문에, 주기적으로 ETL을 해줘야 합니다. 하지만 (빅데이터 시대에서) 주기적으로 모든 데이터를 옮기는 것은 너무 오래 걸리기 때문에, CDC를 활용합니다.

CDC는 그 이름처럼 바뀐 데이터의 정보만을 활용합니다. SQL로 예를 들면, 데이터가 바뀌는 SQL 연산들(insert, update, delete)의 로그를 만들어 Target으로 보냅니다. 바뀐 데이터를 쌓아뒀다가 한 번에 보낼 필요 없이, 거의 실시간으로 Source와 Target이 동기화되기 때문에 CDC를 활용합니다.

---

여기까지 General한 내용이었고, 이제 세미나 Specific한 내용들(SK hynix's CXL memory, Data Hub+IMDG)입니다.

 

SK Hynix's CXL memory

하드웨어에 대해 잘 몰라서 퍼포먼스 예측이 안되지만, 소개한 장점으로는

- Local DRAM에 Memory bandwidth, capacity 동시 확장

- Scale-out 없이 메모리 확장 가능

이 있습니다.

 

Data Hub의 IMDG 적용 PoC

Data Hub는 Source와 Target 간의 실시간 데이터 공유 플랫폼입니다.

그 중 Integration 단계에서 CDC&Event Pipeline을 활용해 실시간 데이터 공유가 가능하고, Delivery Pipeline에는 3가지(h-STREAM, h-CONNECT, Pub/Sub)를 소개하셨습니다.

또, 기존의 SK Hynix의 Data Hub에서 Hazelcast를 적용한 PoC도 소개해주셨습니다. Data Hub는 Hazelcast가 갖고 있는 feature와 유사하나, CDC Pipeline이 없고 주요 기능(Sub Query, Scalar Query)의 미지원이 단점입니다.

---

 

소프트웨어와 하드웨어는 함께 발전한다는 것을 특히 인공지능, 데이터베이스를 공부하며 느끼고 있습니다. 이 세미나도 마찬가지였습니다. 좋은 Tech 세미나 기획해주신 DEVOCEAN 감사합니다!