2.4.1 키-값(Key-Value) 기반의 글로벌 데이터 공간(Global Data Space) 추상화

버전 알림: 본 문서는 Zenoh 1.0.0 (및 1.0.0-rc 분기) 코어 아키텍처 규격을 기준으로 작성되었다.

이기종 시스템이 융합된 거대한 엔터프라이즈 환경에서, 프론트엔드 개발자부터 엣지(Edge) 펌웨어 코더에 이르기까지 모든 인력의 숨통을 조이는 가장 큰 시스템 구축의 벽은, 분산된 데이터들이 ’저장소(Storage)’의 언어와 ’네트워크 통신망(Network Stream)’의 언어로 제각기 다른 프로토콜의 족쇄에 묶여 있다는 사실이다. 낡은 패러다임 아래에서 엣지 단말 A의 데이터를 B가 획득하려면, B는 특정 브로커에 접속하거나 중앙 DB 엔드포인트 URL을 알아내어 복잡한 SQL 쿼리 혹은 REST API를 던지는 끔찍한 절차를 감내해야만 했다.

Zenoh(제노) 아키텍처는 이 지독하게 이질적인 파티셔닝(Partitioning Codebase) 딜레마를 완전히 해체하고, 전 세계에 흩어진 수백만 개의 라우터, 센서, 데이터베이스, 심지어 허공에 날아다니는 라이브 트래픽(In Motion Stream)까지 모조리 단 하나의 추상화된 단일 메모리 블록 지대처럼 모델링해 버렸다. 본 절에서는, 네트워크와 스토리지의 경계를 완전히 지워버린 전 지구적 혁명의 산물, ‘글로벌 데이터 공간(Global Data Space)’ 추상화 모델과 그 치명적 효율성의 근원인 키-값(Key-Value) 메커니즘을 파헤친다.

1. 노드(Node) 주소 체계 파괴와 범용 해시테이블(Universal Hashtable) 스키마의 각성

데이터 객체들의 저장된 물리 서버가 지구 어디에 위치하든 상관없이(Location Transparency), 마치 한 대의 거대한 컴퓨터 안에서 동작하는 Python의 딕셔너리(Dictionary)나 고속 인메모리 레디스(Redis)의 키-값 스토어를 접근하는 듯한 완벽한 착각(Illusion)을 개발자에게 선사하는 것, 이것이 글로벌 데이터 공간 아키텍처의 절대 목표이다.

모든 팩트 기반 데이터(Payload Bytes)는 오직 고유한 URI 스타일의 문자열 명판(Key String Identifier, 예: /company/robot/engine/temp)이라는 유일무이한 열쇠(Key)에 1:1로 결속(Binding)된다. 개발자는 애플리케이션 코드를 짤 때 소켓을 뚫어 타겟의 192.168.x.x 주소를 검색할 필요가 영원히 소멸된다(No Host-centric Socket Coding). 그저 zenoh.get("/company/robot/engine/temp") 함수 하나를 네트워크 허공에 투척하는 순간, 뒷단의 C/Rust 기반 Zenoh 미들웨어 데몬이 광역 통신망과 로컬 스카우팅망을 동시에 미친 듯이 뒤져서 그 문자열 키(Key)를 쥐고 있는 퍼블리셔(Publisher) 단말이나 인-네트워크(In-network) 스토리지 플러그인 라우터를 적중시켜 찾아내어 그 값(Value) 덤프를 되돌려 준다.

전 세계 인터넷 인프라가, 수조 개의 레코드가 담긴 단 하나의 글로벌 NoSQL 해시맵(Universal HashMap Key-Value Storage) 데이터베이스로 둔갑해 버린 극강의 프로그래밍 환각 지대(Mental Model Overlay)야말로 글로벌 데이터 공간의 심장부이다.

2. In-Motion과 At-Rest의 병합, 시간의 차원을 흡수하는 단일 파이프라인(Unified Space Strategy)

과거 시스템은 살아 움직이는 실시간 통신 스트림 이벤트 대역(In-Motion Publisher/Subscriber)과 디스크에 얼어붙은 과거의 로그 타임시리즈(Timeseries At-Rest Database Query)를 두 개의 다른 라이브러리 엔진으로 취급했다. 하지만 거대한 “글로벌 데이터 공간(GDS)“의 논리적 영토 내에서는 이 둘의 구분이 무의미한 촌극이 된다.

어떤 엣지 단말이 /drone/gps/altitude라는 키(Key)로 실시간 고도를 초당 백 번씩 허공에 푸시(Put/Publish)한다고 치자. 누군가 같은 공간(Space)에 그 키를 서브스크라이브(Subscribe) 걸어뒀다면 이 푸시들은 데이터버스 통로를 타고 스트림 이벤트로 즉시 배달될 것이다. 이 과정은 평범한 Pub/Sub의 영역이다.

그러나 이 놀라운 추상 공간 위에서, 다른 관제 서버가 덜컥 get("/drone/gps/altitude")라는 쿼리(Query Pull) 함수를 그 똑같은 키(Key)를 향해 찔러본다고 상상해 보라. 이 순간, 엣지 터미널의 실시간 라이브 단말기(Publisher)는 그 질문에 응답해 자신의 현재 라이브 GPS 고도를 한 번 스냅샷(Value) 찍어 되돌려 줄 수도 있고(RPC Like Live Query), 주변에 매복해 있던 포그(Fog) 라우터가 자기가 잠시 1초 전 버퍼링해 두었던 과거 데이터를 던져줄 수도 있으며(In-network Cache Query), 아예 멀리 있는 몽고DB(MongoDB) 백엔드 플러그인이 자기가 오랫동안 저장해 둔 로그 시계열 배열 단위 통짜 덩어리를 응답으로 뱉어낼 수도(Database Query) 있다. 시간(Time)의 과거와 현재, 혹은 저장 매체가 RAM인지 하드디스크인지, 실시간 센서인지에 대한 그 모든 물리적 팩트 요소(Siloed Mechanism)가 오직 /drone/gps/altitude라는 단 하나의 가상의 데이터 공간 주소 공간망 안으로 수렴하며 모조리 뒤섞여 버리는 마법. 시간과 물리 매체가 디커플링(Decoupling of Time and Storage Media)된 이 통합 세계. 바로 이것이 글로벌 데이터 스페이스라는 단어에 수여된 진정한 기술적 영예이다.

3. 선언적 토폴로지 통합 지휘소: 물리 파편을 글로벌 단일 뷰(Single Virtual View)로 압착

제조 대기업이 전 세계 30개국의 수천 개 팩토리에 독립적인 로컬 네트워크 데이터베이스 브로커망들을 짜 놓았다고 치자. 낡은 IT 부서는 이 30개의 파편화된 실시간 센서망과 공장 내 DB들을 백미러식(Retrospective)으로 취합하기 위해 30개의 연결 커넥터용 데이터 파이프라인(Data Pipeline Adapter)을 따로 파야 할 것이다. 이로 인한 유지 관리 병목 지연(Maintenance Lag Operation)은 끔찍하다.

하지만 Zenoh 데몬이 이 30개 파편 망의 길목 라우터에 플러그인 되는 순간, 30개의 파티셔닝된 물리적 국가 데이터 센터 스택들은 가상의(Virtual) 단일한 네임스페이스 트레이서 뿌리 식별자 /company/global/ 공간 밑으로 쥐도 새도 모르게 병합(Merged GDS Unified View Map) 종속되어 버린다. 뉴욕에 앉아있는 최고 데이터 경영자(CDO)의 대시보드 애플리케이션 프론트엔드 엔진은 get("/company/global/factory/*/robot/status") 라는 단 한 줄의 와일드카드(Wildcard) 패턴 쿼리를 전역 글로벌 공간 허공에 단발로 던질 뿐이다.

이 단 하나의 마법 주문(Single Request Hook)은 제노 통신 백본 계층(FIB Routing Magic Layer)에서 수십 가닥의 쿼리로 다중 복제 분쇄(Fan-out Fragmentation Routing)되어 30개국 라우터와 말단 디바이스를 동시에 타격하고, 실시간 현재 값과 과거 DB 캐시 덤프 값들을 긁어모은다(Execute Search Mapping on Disconnected Continents Array). 그리고 그 수십만 개의 응답 조각 덩어리들을 제노 코어 라우팅 엔진이 역방향으로 취합하여(Aggregated Generator Response Stream), 뉴욕 본사 랩탑 한 대 앞에는 마치 내 컴퓨터 안에 단 하나 있던 거대 SQLite 1개 데이터 테이블을 뒤진 것처럼 정돈된 결과물이 순식간에 동기화 결합 도착한다. 이것이 파편화된 분산 물리 시스템의 붕괴를 극복한 Zenoh GDS, 그 우아함의 절대적 증거이다.