스마트 홈 Io t 서비스를 위한 분산 데이터베이스 설계 및 구현

1. 스마트 홈 IoT를 위한 분산형 데이터베이스 아키텍처 설계
조성수 김태경 정회운 한용구 유인태
경희대학교 컴퓨터공학과
nexusz99@gmail.com, myoji1224@gmail.com, un4255@gmail.com, ykhan@khu.ac.kr, itryoo@khu.ac.kr
Design of the Distributed Database Architecture for Smart Home IoT
Seong-Soo Cho, Tae-Kyung Kim, Hoi-Un Jeong, Yong-Koo Han, In-Tae Ryoo
요 약
IoT는 무수히 많은 사물들이 네트워크로 연결되어 폭발적인 데이터를 발생시킨다. 따라서 이와 같은
IoT 데이터들은 중앙식 보다는 분산형 데이터베이스 아키텍처가 적합하다. 최근 IBM과 삼성은 ADEPT
플랫폼을 만들어 비 중앙식 IoT의 컨셉을 제시하였으나, 상세 구현 방안과 탈 중앙화를 위한 분산 데이
터베이스의 구체적인 구성 방법은 기술되지 않았다. 본 논문에서는 스마트 홈 서비스를 타겟 애플리케이
션으로 하여, ADEPT의 비 중앙식 IoT 플랫폼을 위한 분산형 데이터베이스 아키텍처를 설계 및 구현한
다. 이로써 IoT를 위한 분산 데이터베이스의 구현 시 발생할 수 있는 이슈들과 구현 방안을 제시한다.
1. 서 론
최근 인터넷, 클라우드, 센서네트워크의 발전으로
IoT(Internet of Things) 기술이 주목 받고 있으며, 관련
업체들에 의해 상용화 단계에 접어들었다. IoT는 사물에
센서를 부착해 실시간으로 데이터를 인터넷으로 주고받
는 기술로서, 인터넷에 연결되는 사물들의 개수와 이들
로부터 발생하는 폭발적인 데이터 양을 고려하면 효과
적인 데이터베이스 아키텍처가 수반되어야 한다.
IoT 환경에서 무수한 사물들이 생성하는 대용량의 데
이터를 관리하기 위해서는 중앙식보다는 분산형 데이터
베이스 아키텍처가 적합하다. 2015년 IBM은 Device
Democracy 보고서[1]를 통해 수 많은 기기의 요청과
데이터를 처리할 미래의 IoT 모습을 제안하였고, 삼성
과 함께 ADEPT(Autonomous Decentralized Peer-To-
Peer Telemetry) 플랫폼을 만들어 비 중앙식 IoT의 컨
셉을 제시하였다.
그러나 ADEPT 문서에는 플랫폼을 구현하기 위한 아
키텍처의 간단한 로지컬 뷰(Logical View)만 소개되어
있고, 상세 구현 방안과 탈 중앙화를 위한 방안으로 분
산 데이터베이스를 어떻게 구성할 것인지에 대해서는
기술되어 있지 않다.
본 논문에서는 스마트 홈 서비스를 타겟 애플리케이
션으로 하여, ADEPT의 비 중앙식 IoT 플랫폼을 위한
분산형 데이터베이스 아키텍처를 설계 및 구현한다. 이
로써 IoT를 위한 분산 데이터베이스의 구현 시 발생할
수 있는 이슈들을 제시하고 구현 방안을 토의한다.
2. 관 련 연 구
ADEPT[2]는 2015년 IBM 과 삼성이 공동으로
개발한 비 중앙식 IoT 플랫폼이다. ADEPT는 탈
중앙화를 위해 기기 간 p2p 네트워크와 기기간 거래를
저장 및 검증하기 위해 블록체인을 도입하였고,
Telehash[5]와 Ethereum[6]을 각각 사용하여
구현하였다. ADEPT의 아키텍처는 Light Peer, Standard
Peer, Peer Exchange로 3가지로 분류하여 설계하였다.
각 Peer마다 Data Layer가 존재하며, 이를 통해
데이터를 로컬과 분산 DB에 저장한다.
RethinkDB[3]는 실시간 웹 애플리케이션을 위해
만들어진 JSON 데이터베이스이다. 이 데이터베이스는
데이터의 변화를 위해 상태를 Polling하던, 전통적인
데이터베이스 아키텍처를 사용하지 않고, 실시간으로
어플리케이션에 업데이트된 쿼리의 결과를 푸시해 줄
수 있는 아키텍처를 적용하였다.
BigChainDB[4]는 분산 데이터베이스에 블록체인
기능을 추가한 데이터베이스로써, 블록체인을
데이터베이스처럼 쓸 수 있게 해주는 것이 가장 큰
특징이다. 비트코인(BitCoin)과 같은 블록체인은 모든
노드가 모두 동일한 블록체인 전체를 가지고 있어야
하지만, BigChainDB는 노드와 블록체인을 저장하는
공간을 분리시킴으로써 대용량의 블록체인을
효율적으로 관리할 수 있는 장점이 있다.
3. 스마트 홈 IoT 서비스를 위한 분산형 데이터베이스
아키텍처 설계
3.1 스마트 홈 IoT 서비스의 구성요소와 데이터
본 절에서는 스마트 홈 IoT 서비스를 이루는
구성요소와 데이터에 대해 정의한다. 스마트 홈 IoT
서비스는 ‘서비스 사업자’, ‘협력 업체’, ‘가정’의 요소로
구성된다. 서비스 사업자는 서비스를 제공하는 자로서,
서비스를 위한 기본 인프라를 구축할 의무를 갖는다.
협력 업체는 가정에 설치된 기기들에 대한 유지보수와
소모품 지원을 위해 서비스 사업자와 협력관계를 맺은
업체이다. 가정은 서비스를 받는 사용자이다.
표 1은 위에서 설명한 구성 요소들이 생산하고,
이용하는 필수 데이터 및 이들에 대한 설명이다. 스마트
홈 IoT 서비스에서의 사물은 서비스 사업자가 생산한

2. 홈 IoT 기기(Device)로서, ‘세탁기’, ‘냉장고’, ‘전등’,
‘보일러’, ‘홈 게이트웨이’ 등이 속한다. 규칙(Rule)은 각
기기들이 특정 조건에서 수행해야 할 작업을 기술한
내용이다. 세탁기에 대한 규칙의 예시로 ‘세제통에
세제가 30% 미만으로 남아있다면, 세제 판매 업체에
세제 구매 요청을 보낸다’를 들 수 있다. 규칙 데이터
스키마는 ‘{‘critria_value’: ‘30’, ‘action’: ‘order’, ‘item’:
‘detergent’}’의 json 형식을 가진다. ‘Transaction’은
규칙에 의해, 혹은 사용자가 직접 협력 업체에 서비스
요청을 한 거래 내역을 기록하는 데이터이다. 예로 ‘A
사용자가 B업체에게 세탁기의 세제 구매를 요청’ 이
있다. Transaction 데이터 스키마는 ‘{‘from’: ‘a’, ‘to’:
‘store’, ‘msg’: ‘order’}’ 의 json 형식을 가진다. ‘City
List’는 뒤에서 설명할 City Area의 정보이며, ‘City
Area’를 구분하는 기준과, 홈 게이트웨이가 City
Area에 참가하기 위한 분산 관리자 정보를 가지고 있다.
표 1 스마트 홈 IoT 서비스 필수 데이터
데이터 종류 설명 중앙성
Device List
서비스에 등록된 모든 Device
정보
상
Default Rule IoT 기기에 기본으로 적용될 Rule 상
City List 각 도시 영역의 정보 상
3
rd
party 협력업체에 대한 정보 중
Transaction 기기 <-> 협력업체 간 거래 내역 중
Device Data IoT 기기에서 발생한 데이터 하
Custom
Rule
사용자가 임의로 설정한 Rule 하
3.2 분산 가능성에 따른 데이터 분류와 영역 분할
3.1절에서 정의한 데이터를 저장하기 위해 클라우드
혹은 IDC에 데이터베이스 서버를 구축하여
서비스하는 중앙형 플랫폼을 구축한다. 중앙형
플랫폼은 장애 발생시, 서비스 전체가 장애로
이어진다. 스마트 홈 IoT 서비스의 경우, 서비스
장애는 사용자 경험에 매우 나쁜 영향을 끼치고
경우에 따라 사용자에게 큰 피해를 가져다 줄 수도
있다. 따라서 중앙에 장애가 발생해도 서비스가
가능한 분산 데이터베이스가 필요하고, 이를 구축하기
위해 데이터의 분산 가능성 여부를 중앙성을 기준으로
표 1의 3열과 같이 분류한다.
중앙성은 보안 강도와 분산 가능성을 기준으로 세
단계로 구분한다. 유출되면 안 되는 중요한 데이터는
‘상’, 유출되어도 서비스에 큰 위협이 되지 않는 데이
터는 ‘하’ 그리고 분산할 필요는 없지만 분산하게 되면
중앙 데이터베이스에 가해지는 부담을 줄일 수 있어
분산을 권장하는 데이터는 ‘중’으로 하였다. 중앙성에
따라 데이터 분산을 위해 스마트 홈 서비스의 데이터
베이스 인프라를 ‘Service Provider Area’와 ‘City
Area’ 2가지 영역으로 나누었고, 그림 1과 같은 구조
를 갖는다.
그림 1. 스마트 홈 서비스 데이터베이스 인프라 영역
‘Service Provider Area’는 중앙성 ‘상’ 데이터들을
저장하는 영역이다. 이 영역은 ‘클라우드’ 혹은 ‘IDC’
에 사업자가 구축한 분산 데이터베이스로써, 일반적인
RDB와 NoSQL의 클러스터 기능을 이용하여 구축한다.
‘City Area’는 중앙성 ‘중’, ’하’ 데이터를 저장하는 영
역으로, ‘서울’, ‘부산’ 과 같은 도시 별로 영역을 구축
할 수 있다. 이 영역은 사업자가 초기 서비스를 위해
구축한 데이터베이스 인프라와 가정에 설치되는 홈 게
이트웨이의 로컬 DB를 이용하여 구축한 분산 데이터
베이스이다.
3.3 City Area의 분산 데이터베이스
‘City Area’ 는 분산을 권장하는 중앙성 ‘중’, ‘하’ 데
이터를 저장하는 영역으로, 가정 내 홈 게이트웨이의
지역 DB를 활용함으로써 사업자가 구축한 데이터베이
스의 구축 비용과 부하를 감소시키는 것이 핵심 기능
이다.
‘City Area’의 분산 데이터베이스는 사업자가 구축한
데이터베이스 서버와 홈 게이트웨이를 동시에 활용한
다. 따라서, 분산 데이터베이스를 이루는 노드의 수가
상당하며, 노드 간의 데이터 동기화를 빠르게 할 필요
가 있다. 본 논문에서는 이런 요구를 충족시키기 위해
실시간 푸시 아키텍처를 이용하여 데이터를 동기화하
는 RethinkDB를 이용하여 분산 데이터베이스(이하 클
러스터)를 구축하였다.
‘City Area’에 저장되는 데이터 중 ‘Transaction’은
블록체인 기술을 이용하여 관리된다. 거래의 검증을
중앙 서버가 아닌, 영역의 모든 홈 게이트웨이의 ‘블록
체인 노드’가 블록체인을 통해 검증한다. 블록체인을
관리하기 위해 RethinkDB를 블록체인 저장소로 활용
하는 BigchainDB를 사용하였다. BigchainDB을 사용하
면, 모든 블록체인 노드가 대용량의 블록체인을 가질
필요가 없어, 홈 게이트웨이의 저장공간을 효율적으로
사용할 수 있다.
3.4 City Area RethinkDB 클러스터 구축 정책
‘City Area’의 모든 홈 게이트웨이가 클러스터의 노
드로 활용되는 것은 아니다. ‘분산 관리자(Distribution
Manager)’의 정책에 의해 RethinkDB 클러스터에 참

3. 가할 홈 게이트웨이를 선정하고 관리한다. 분산 관리
자는 Area의 Uptime 이 20일 이상 지속되고, Local
DB의 가용 용량의 증가 추세가 다른 gateway 보다
낮은 홈 게이트웨이를 추출하여, 클러스터에 포함시킨
다. 이로써 데이터들이 홈 게이트웨이 Local DB로 분
산되기 시작하여, 사업자가 구축한 데이터베이스에 가
해지는 부하가 분산된다. 또한 분산 관리자는 선정되
었던 홈 게이트웨이 가 일정 기간 이상 offline 상태일
경우, 해당 홈 게이트웨이를 클러스터 에서 제외시킨
다.
4. 응용 시나리오
본 장에서는 3장에서 설계한 내용을 바탕으로 실제 스
마트 홈 IoT 서비스에서 분산 데이터베이스를 이용하는
시나리오를 제시한다.
4.1 홈 게이트웨이 설치 및 클러스터 모니터링
시나리오에서는 사업자가 ‘경기도’, ‘강원도’ 와 같이
‘도’를 기준으로 City Area를 구축한다. 그림 2는 사용
자가 홈 게이트웨이를 설치하고, City Area 에 홈 게이
트웨이를 배치시키는 과정을 설명한다. 사용자가 홈
게이트웨이가 설치된 장소의 주소를 입력하면, City
List에서 주소에 있는 ‘도’의 City Area의 분산 관리자
정보를 받아온다. 그리고 분산 관리자로부터
RethinkDB 클러스터 정보를 받아, ‘City Area’의 분
산 데이터베이스를 이용할 준비를 한다. 서비스 사업
자는 그림 3과 같은 City Area 분산 데이터베이스 대
시보드를 통해 클러스터 현황을 확인할 수 있다.
그림 2. 홈 게이트웨이 설치 과정
그림 3 City Area 분산 데이터베이스 대시보드
4.2 세탁기의 능동적 세제 주문
그림 4은 세탁기가 ‘세제통에 세제가 30% 미만으로
남아있다면, 세제 판매 업체에 세제 구매 요청을 보낸
다’ 라는 Rule에 의해 능동적으로 세제 주문을 하는
과정을 설명한다. 세탁기는 직접 인터넷에 연결될 수
없고, 홈 게이트웨이와 블루투스로 연결하여 홈 서비
스에 참가한다. 세탁기가 홈 게이트웨이에 세제 구매
요청을 보내면, City Area의 RethinkDB 클러스터에서
협력 업체 정보를 가져온다. 여기서 주목해야 할 점은
클러스터의 노드 중 하나인 철수 집의 홈 게이트웨이
를 통해 정보를 가져온다는 점이다. 그리고 세제 판매
업체와의 거래 내역(Transaction)은 영희 집 홈 게이
트웨이를 통해 블록체인에 저장한다. 각 가정의 홈 게
이트웨이에 데이터가 분산되었고, 이를 직접 서비스하
기 때문에 사업자 데이터베이스 노드가 장애를 일으켜
도 서비스는 장애를 일으키지 않는다.
그림 4. 세탁기 능동적 세제 주문
5. 결론 및 향후 계획
본 논문에서는 ADEPT의 비 중앙식 IoT 플랫폼을 위
한 분산형 데이터베이스 아키텍처를 설계 및 구현하였
다. 제안하는 아키텍처는 중앙 데이터베이스의 구축 비
용과 부담을 감소시키고, 장애 발생 시에도 원활한 서비
스를 가능하게 한다. 클러스터에서 빠른 데이터 동기화
를 위해 RethinkDB를 사용하였고, 거래 내역을 중앙 서
버의 인증이 필요 없는 블록체인을 사용하여 저장하였
다. 향후에는 분산 데이터베이스에 저장된 데이터 분석
플랫폼과 다양한 서비스 또한 비 중앙식으로 제공할 수
있는 플랫폼을 개발하여, 미래 IoT를 위한 비 중앙형
IoT 플랫폼을 완성시켜 나갈 계획이다.
"본 연구는 미래창조과학부 및 정보통신기술진흥센터
(IITP)에서 지원하는 서울어코드활성화지원사업의 연구
결과로 수행되었음" (R0613-16-1203)
6. 참 고 문 헌
[1] IBM, Device Democracy, 2015. 1
[2] IBM ADEPT – Pre Publication Draft,
https://www.scribd.com/doc/252917347/IBM-
ADEPT-Practictioner-Perspective-Pre-Publication-
Draft-7-Jan-2015
[3] RethinkDB, http://rethinkdb.com
[4] BigchainDB, https://www.bigchaindb.com
[5] Telehash, http://telehash.org
[6] Ethereum, https://www.ethereum.org