ITPE Momentum

출처 : http://www.hardcopyworld.com/gnuboard5/bbs/board.php?bo_table=lecture_rpi&wr_id=60

 

홈 오토메이션과 센서 네트웍 관련 자료들을 찾다보니 MQTT 프로토콜이 자주 등장하더군요. 좀 더 세부적으로 살펴보니 여러모로 유용한 것 같아 자료들을 정리해 봤습니다. 실제 테스트도 가능하도록 예제도 첨부했습니다.

MQTT(MQ Telemetry Transport)는 아두이노나 라즈베리파이 같은 임베디드 장치간 통신을 위한 가벼운 메시징 프로토콜입니다. TCP/IP 기반으로 대역폭이 작은 네트워크에서 동작할 수 있도록 설계된 프로토콜입니다. 쉽게 얘기해서 임베디드 장치들을 위한 트위터라고 볼 수 있습니다.

MQTT 자체는 메시지를 어떻게 보낼 것인지를 정의하는 규약일 뿐입니다. 따라서 실제 MQTT 트위터를 동작시키기 위해서는 서버 역할을 해주는 장치(프로그램)가 필요한데 이를 MQTT 브로커(Broker)라고 합니다. MQTT 브로커는 각종 장치들(MQTT Client)이 보내주는 메시지를 수집하고 이걸 다시 필요한 장치들에게 전송해주는 중계서버 역할을 합니다.

MQTT 클라이언트는 브로커에게 메시지를 전달하고 필요한 메시지를 받기만 하면 되고 MQTT 프로토콜의 구조도 간단하기 때문에 처리능력이 낮은 임베디드 장치에 잘 어울립니다. 메시지는 트위터처럼 140자 제한이 없으므로 긴 메시지나 JSON 포맷 또는 파일도 전송이 가능합니다. 이런 특징들 때문에 MQTT 프로토콜은 센서 네트웍을 구성하는데 유용한 도구로 관심을 받고 있습니다.

 

 

MQTT 동작 구조 (PUB/SUB)

 

트위터 서비스의 동작구조를 떠올려보세요. 트위터에서 사용자는 다른 사용자를 follow 할 수 있습니다. 그럼 다른 사용자가 생성하는 메시지(트윗)를 받아볼 수 있죠. 그리고 스스로 메시지를 생성할 수도 있습니다. 그럼 자신을 follow하는 사용자에게 메시지가 전달되죠.

MQTT도 거의 유사한 동작구조를 갖습니다. MQTT 시스템에 참여하는 MQTT 클라이언트는 메시지 발행(publish, 트윗에 해당), 메시지 구독(subscribe, follow에 해당) 두 가지 동작을 할 수 있습니다. MQTT 클라이언트가 메시지를 특정 채널(Topic, 토픽)에 발행하면 이 채널을 구독한 모든 클라이언트에게 메시지가 전달되는 겁니다. 중간에서 메시지를 수집, 재분해 하는 작업은 MQTT 브로커가 담당합니다.

 

 

 

토픽

 

메시지를 발행/구독(pub/sub) 하는 행위는 채널 단위로 일어납니다. 이를 MQTT에서는 토픽(Topic)이라고 합니다. 토픽은 슬래시(/)로 구분된 계층구조를 갖습니다.

메시지를 구독/발행 할 때 여러개의 토픽을 한번에 지정할 수 있도록 wild card 문자를 지원합니다. [+] 문자는 단 1개의(1 레벨) 토픽을 임의의 토픽으로 대체하는 와일드카드 문자입니다.

반면 [#] 문자는 여러 레벨의 토픽을 대체할 수 있습니다. [myhome/#] 처럼 사용하면 myhome 의 하위 토픽들 모두를 지칭하게 됩니다. [#] 문자는 토픽 문자열 끝에만 사용할 수 있으며 하위 토픽 모두를 지칭합니다. (2단계 이상 하위 토픽도 포함)

[$] 문자로 시작하는 토픽은 시스템에 의해 사용되는 특수한 토픽을 의미합니다. 이 토픽들은 [#] 문자열로 지정해도 포함되지 않는 토픽이 됩니다. 주로 [$SYS/] 로 시작하는 토픽들이 브로커의 내부 메시지를 위해 사용됩니다. (이에 대한 명확한 표준은 없는 상태인듯)

토픽 구조를 구성할 때 몇 가지 주의할 점이 있습니다.

• 최상위 토픽이 [/] 문자로 시작하지 않도록 합니다. [/home/sensor/humid] 이렇게 사용할 수는 있지만 최상위 토픽이 이름이 없는 토픽이 되므로 사용하지 않는 것을 권장합니다.
• 토픽 이름에 공백을 사용하지 않습니다.
• 토픽 이름은 ASCII 문자만 사용합니다. (임베디드 장치와의 호환성을 위해 주의)
• [#] 를 이용해서 토픽 전체를 구독하지 않도록 합니다. 오버헤드가 심할 경우 브로커/클라이언트 프로세스가 중단될 수 있습니다.

 

 

QOS (QUALITY OF SERVICE)

 

MQTT는 시스템에 참여하는 장치들의 처리 능력, 네트워크 대역폭, 메시지 오버헤드 등 주변상황에 맞게 시스템이 동작할 수 있도록 3단계 QoS(Quality of Service) 를 제공합니다.

• 0 : 메시지는 한번만 전달하며, 전달여부를 확인하지 않는다. Fire and Forget 타입이다.
• 1 : 메시지는 반드시 한번 이상 전달된다. 하지만 메시지의 핸드셰이킹 과정을 엄밀하게 추적하지 않기 때문에, 중복전송될 수도 있다.
• 2 : 메시지는 한번만 전달된다. 메시지의 핸드셰이킹 과정을 추적한다. 높은 품질을 보장하지만 성능의 희생이 따른다.

0에 가까울수록 메시지 처리에 대한 부하가 적은 대신 메시지 손실 위험이 높아집니다. 2에 가까울수록 메시지 손실 위험은 줄어들지만 메시지 처리 부하가 급격히 늘어납니다.

(보통 0~1 정도의 QoS를 사용하면서 메시지 손실등의 위험은 상위 어플리케이션 차원에서 관리하도록 하는듯 합니다.)

 

 

MQTT 브로커

 

MQTT 시스템의 핵심 서버 역할을 하며,  여기에 메시지가 수집되고 다시 재분배 됩니다. 다양한 MQTT 브로커 프로그램들이 개발되어 있는데 ActiveMQ, Apollo, IBM Message Sight, JoramMQ, Mosquitto, RabbitMQ, Solace Message Routers 등이 자주 사용됩니다. 아래 링크에 MQTT 브로커의 특징을 비교한 자료가 있습니다.

• https://github.com/mqtt/mqtt.github.io/wiki/server-support

여기서는 Mosquitto 브로커를 사용할 것입니다. Mosquitto는 MQTT의 기본 기능을 충실히 지원하는 가벼운 MQTT 브로커 프로그램입니다. Mosquitto 클라이언트 프로그램도 있으므로 여러대의 PC를 이용해서 테스트를 할 수 있습니다.

 

 

MQTT 동작 테스트

 

홈 오토메이션이나 센서 네트워크를 구성하기에는 라즈베리파이같은 손바닥 PC가 제격입니다. 여기서는 MQTT 동작 테스트를 위해 PC와 라즈베리파이에 Mosquitto MQTT 클라이언트, 브로커를 설치할 것입니다.

라즈베리파이에 Mosquitto 브로커를 설치하는 작업부터 시작합니다. Mosquitto 는 apt-get 명령어를 통해 간단히 설치할 수도 있지만 업데이트가 되지 않는 문제점이 보고되고 있습니다. 아래 순서로 설치하길 권장합니다. (최신 소스코드를 다운로드 받아 설치하실땐 링크를 참고하세요.)

• wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
• sudo apt-key add mosquitto-repo.gpg.key
• cd /etc/apt/sources.list.d/
• sudo wget http://repo.mosquitto.org/debian/mosquitto-wheezy.list
• sudo apt-get install mosquitto

설치가 완료되면 브로커는 1883 포트를 사용하게 됩니다.

 

이제 PC와 모바일 폰에 MQTT 클라이언트를 설치해서 연동을 해보겠습니다. PC(Windows, Linux, OS X)에서는 MQTT.fx 클라이언트를 설치하면 됩니다. 아래 링크에서 프로그램을 받을 수 있습니다.

• http://mqttfx.jfx4ee.org/

MQTT.fx 클라이언트는 윈도우 64비트만 지원합니다. 이 문제 때문에 설치가 안된다면 크롬 브라우저의 확장 앱으로 설치해서 사용하는 방법도 있습니다. 크롬 브라우저에서 아래 링크를 통해 설치할 수 있습니다.

• https://chrome.google.com/webstore/detail/mqtt-client-tcp-and-ws/kaajoficamnjijhkeomgfljpicifbkaf/related?hl=ko

모바일 폰에서는 앱 스토어에서 MQTT로 검색하시면 됩니다. 다양한 클라이언트가 등록되어 있는데 대부분 비슷하므로 아무거나 사용하셔도 됩니다. 유명한 MQTT 클라이언트들은 링크에서 확인하실 수 있습니다.

 

설정 방법은 간단합니다. 아래 항목들만 정확히 설정해 주면 됩니다.

• MQTT 브로커 URL : MQTT 브로커를 설치한 서버의 URL 입니다.
• Port : 앞서 설치한 Mosquitto 브로커는 기본 1883 포트를 사용합니다.
• Username / Password : 지금은 설정하지 않아도 됩니다.

테스트를 위해 클라이언트에서 subscribe 버튼을 누르고 토픽에 messagebox를 입력합니다. 그럼 messagebox 토픽이 생성되고 구독이 됩니다. PC, 모바일 등 모든 장치에서 같은 작업을 해줍니다.

이제 PC, 모바일에서 publish 를 합니다. 이때 토픽은 messagebox로 선택합니다. 그럼 입력한 메시지가 브로커로 전달되고 messagebox 토픽을 구독하는 다른 장치들에도 전달되어야 합니다. 제대로 동작하는지 확인해보세요.

 

MQTT 브로커를 설치한 라즈베리파이에 MQTT 클라이언트를 설치해서 확인할 수도 있습니다.

• apt-get install mosquitto-clients

아래 명령으로 메시지 발행(pub)을 할 수 있습니다. 다른 기기에도 메시지가 보여야겠죠.

• mosquitto_pub -d -t messagebox -m "sent from RPi server"

특정 토픽을 구독(sub) 할 수 있습니다. 이 경우 특정 토픽에 메시지가 도착 할 때마다 표시됩니다. Ctrl+c 를 눌러 멈추기 전까지는 메시지 표시하는 상태로 유지됩니다.

• mosquitto_sub -d -t messagebox

 

 

MQTT - IOT 장치 만들기

 

앞선 MQTT 테스트는 단순한 메시지를 공유하는 일종의 채팅 예제였습니다. 여기서 메시지 내용만 원하는대로 바꿔서 사용하면 센서 네트웍, 홈 오토메이션에도 MQTT가 메시지 전송 프로토콜로 활용될 수 있음을 알 수 있습니다. 여기서는 IoT 장치를 직접 만들기 위해서 마이크로 컨트롤러에 MQTT를 이식하고 메시지를 전달하는 예제를 만들어 보겠습니다.

예제 장치를 만들기 위해 아래와 같은 모듈들이 필요합니다.

• ESP8266 - NodeMCU (ESP12E 기반) 보드
• DHT22 (온습도 측정용 센서)
• I2C 128x64 OLED (옵션, 현재 상태와 송수신 메시지 표시용, 반드시 SSD1306 드라이버 칩을 사용한 모듈 필요)

ESP8266 - NodeMCU (ESP12E 기반) 보드

가성비와 활용성 면에서 최고의 평가를 받는 ESP8266 WiFi 모듈을 마이크로 컨트롤러로 사용합니다. 여기서는 모듈에 올라갈 펌웨어 작성을 위해서 Sming 개발환경을 사용할 예정인데, ESP8266 Arduino IDE로 작성하는 것도 가능합니다.

먼저 모듈들을 연결을 해줘야겠죠. ESP8266과 DHT22은 아래 순서로 연결합니다.

• ESP8266 --> DHT22
• 3V --> VCC
• GND --> GND
• D5(GPIO14) --> DAT

ESP8266 에 OLED 디스플레이도 연결합니다.

• ESP8266 --> OLED
• 3V --> VCC
• GND --> GND
• D3(GPIO0) --> SCL
• D4(GPIO2) --> SDA

 

모듈 연결이 끝나면 ESP8266에 올라갈 펌웨어를 만들어야 합니다. Eclipse 기반 Sming 개발환경을 구축하면 MQTT client 예제 파일도 같이 설치됩니다. 이걸 수정해서 DHT22 센서로 온습도를 측정하고 MQTT broker로 전송하도록 만들었습니다. 아래 링크에서 소스코드를 구하실 수 있습니다.

• GitHub 링크 : MQTT Client

소스에서 몇 가지를 수정해줘야 합니다. 공유기 ID(SSID)와 PASSWORD, 센서값을 전송할 간격, 토픽의 이름(여기서는 messagebox  토픽 사용) 입니다.

...... #ifndef WIFI_SSID 	#define WIFI_SSID "your_ssid" // Put you SSID and Password here 	#define WIFI_PWD "your_password" #endif ...... MqttClient mqtt("your_mqtt_server.com", 1883, onMessageReceived); ...... 	mqtt.publish("your_topic", message); // or publishWithQoS ...... 	mqtt.subscribe("your_topic"); ......

 

소스가 수정되면 컴파일을 하고, 생성된 펌웨어를 MSP8266 모듈에 올려 구동하면 정해진 시간 간격마다 MQTT 메시지를 전송합니다. PC, Mobile 폰에서 messagebox 토픽에 해당 메시지가 들어오는지 확인하면 되겠죠.

그리고 반대로 PC, Mobile 폰에서 messagebox 토픽에 메시지를 생성(publish)하면 ESP8266 모듈의 디스플레이에 표시되어야 합니다.

메시지가 정상적으로 표시된다면 기본적인 수준의 IoT 장치가 완성된 것입니다!! 이걸 응용하면 IoT 장치를 인터넷 서비스와 연동하는데 사용할 수 있습니다.

 

 

 

 

HOME-ASSISTANT 홈 오토메이션 서버와 연동

 

MQTT 프로토콜은 단순히 메시지/데이터를 전송하는데 사용되는 규약일 뿐입니다. 대신 MQTT broker/client, 라이브러리를 통해 송수신된 데이터를 처리하는 도구를 풍부하게 제공합니다. MQTT로 전송하는 메시지가 무엇인가는 전혀 관여하지 않습니다. 전송되는 데이터 자체를 어떻게 처리할 것인가는 서비스 개발자의 몫입니다.

따라서 센서 네트웍, 홈 오토메이션에 MQTT 를 사용하더라도 전달되는 데이터를 어떤 형식으로 보낼 것인지는 직접 정의해야 합니다. 이런 작업을 직접 다 하기에는 고려해야 할 점도 많고 구현도 힘들기 때문에 오픈소스로 표준화/공개된 솔루션을 사용할 수 있습니다. 여기서는 Home-assistant 라는 홈 오토메이션 솔루션을 이용해 우리가 만든 IoT 장치를 연동해 보도록 하겠습니다.

홈 어시스턴트 서버를 설치하고 설정하는 방법은 아래 링크에서 다루고 있습니다.

• Home-Assistant 설치와 활용

 

앞서 ESP8266 보드로 만든 장치를 다시 이용하도록 하겠습니다. 대신 소스코드에 약간의 수정이 필요합니다.

void publishMessage() { 	...... 	// Make JSON data 	String message = "{\"temp\":"; 	message += th.temp; 	message += ", \"humi\":"; 	message += th.humid; 	message += "}";  	// publish message 	Serial.println("Let's publish message now!"); 	mqtt.publish("home/thirdroom/temp_humi", message, true); // retained message 	...... }

앞서와 다른 점은 데이터를 보낼 때 JSON 형식으로 보낸다는 겁니다. 예를 들어 온도 23.11', 습도 68.35%를 보낼 때 아래처럼 보냅니다.

{"temp": 23.11, "humi": 68.35}

그리고 이 데이터는 [home/thirdroom/temp_humi] 토픽으로 전송합니다. 마지막에 true 파라미터가 붙은건 마지막 데이터를 저장했다가 새로 구독(subscribe)하는 기기가 있으면 보내주기 위한 retained message 기능입니다.

홈 어시스턴트 서버에서는 [home/thirdroom/temp_humi] 토픽을 구독하면서 새로운 업데이트가 생겼을 때 JSON 데이터를 파싱하면 됩니다. 홈 어시스턴트 설정파일인 [configuration.yaml] 파일에서 아래와 같이 설정해주면 됩니다.

sensor 3:   platform: mqtt   state_topic: "home/thirdroom/temp_humi"   name: "Thirdroom Humidity"   qos: 0   unit_of_measurement: "%"   value_template: '{{ value_json.humi }}'  sensor 4:   platform: mqtt   state_topic: "home/thirdroom/temp_humi"   name: "Thirdroom Temperature"   qos: 0   unit_of_measurement: "°C"   value_template: '{{ value_json.temp }}'

[home/thirdroom/temp_humi] 토픽을 구독하면서 데이터가 도착하면 humi, temp 변수를 찾아 그 안에 할당된 값을 추출합니다. 정상적으로 동작하면 홈 어시스턴트 웹 페이지에서 아래처럼 보이게 됩니다.

 

 

OPENHAB 홈 오토메이션 서버와 연동

 

openHAB 도 홈 어시스턴트와 같은 컨셉을 가진 홈 오토메이션 서버입니다. 아래에 설명하는 과정은 openHAB 홈 오토메이션 서버에 MQTT 브로커를 연동해서 센서값을 보여주는 방법입니다. 여기서는 이미 openHAB이 설치된 리눅스 서버가 있다는 가정하에 진행하겠습니다. 라즈베리파이에 openHAB 서버 설치는 링크의 내용을 참고하세요.

• 라즈베리파이에 openHAB 설치하기

 

openHAB 서버가 MQTT 브로커와 연결되기 위해서는 전용 add-on 을 설치해야 합니다.

• sudo apt-get install openhab-addon-binding-mqtt
• sudo chown -R openhab:openhab /usr/share/openhab

openHAB 설정 파일을 수정해줍니다.

• sudo nano /usr/share/openhab/configurations/openhab.cfg

아래 내용을 추가

mqtt:broker.url=tcp://localhost:1883 mqtt:broker.clientId=openhab

openHAB 재실행

• sudo service openhab restart

 

MQTT 로 들어온 메시지가 연결될 Number item 추가 작업

(이하 내용 작성 중...)

참고 링크

 

 

 

 

참고자료

• MQTT Essential
• MQTT standard (official)
• MQTT.fx : JavaFX based MQTT Client
• Paho : open-source client implementations of MQTT / MQTT-SN
• MQTT Tutorial (한글판)
• MQTT 소개 및 활용, MTQQ Server(Broker) List
• Mosquitto MQTT on Raspberry Pi

아두이노와 Ethernet 모듈을 이용한 센서 장치 만들기

• 아두이노용 MQTT 클라이언트 라이브러리 (pub/sub 지원)
• 아두이노, Ethernet 모듈을 이용한 MQTT 클라이언트 예제 스케치

 

초기 인터넷의 주요 개발 목적은 원격 호스트들 사이의 안전한 네트워크 연결을 제공하는 것이었다. 그러므로 현재와 같은 멀티미디어 데이터 전송 증가로 인한 잦은 네트워크 병목현상, 취약한 보안으로 인한 심각한 침해 사고, 호스트의 빈번한 이동으로 인한 비효율성과 같은 다양한 문제점들과 그 해결 방안을 고려하지 않았다 [1] . 특히, 다양한 스마트 IT 융복합 서비스의 증가는 이와 같은 문제점들을 더욱 심화시킬 수 있으며, 인터넷의 기존 문제점들은 IT 융복합 서비스의 저변확대를 방해하는 주요 요인이 될 수 있다. 그러므로 이와 같은 문제들을 해결하고 인터넷을 통하여 다양한 데이터 및 정보를 보다 효과적으로 지원하기 위한 미래 인터넷 기술 연구가 여러 방향으로 진행되고 있다 [2 - 4] . 특히, 미래 인터넷 기술 중 하나인 정보 중심의 네트워킹 기술(Information Centric Networking, ICN)은 데이터 소스에게 집중되는 데이터 요청 메시지를 효율적으로 분산 처리하기 위하여 멀티미디어 프락시 시스템(Multimedia Proxy System)이나 네트워크 기기 (Network Node)에 데이터를 임시 저장한 후, 데이터 소스를 대신하여 이들 기기들이 데이터 요청 메시지를 직접 처리하는 기술을 제공하고 있다.

ICN 기술 중 하나인 데이터 이름 기반 네트워킹(Named-Data Networking, NDN)은 데이터의 계층화된 고유 이름에 기반 한 패킷 전송과 네트워크 기기에 데이터 임시 저장 기능(Caching)을 구현하여 효과적으로 데이터를 전송할 수 있도록 설계되었다 [3 , 4] . 기본적으로 네트워크 노드에 저장된 데이터를 이용하여 네트워크의 효율성을 높이고 있기 때문에 캐싱되는 데이터의 종류와 데이터를 캐싱하는 네트워크 노드의 네트워크 토폴로지 상에서 위치가 NDN의 성능에 매우 큰 영향을 미친다.

본 논문에서는 데이터의 이용 빈도를 기반으로 데이터 캐싱 노드를 선택/운영하는 NDN 데이터 캐싱 기법들을 살펴보고, 캐싱 기법의 성능 개선을 위하여 네트워크 토폴로지 상에서의 노드별 캐싱 이용률을 관찰하고, 관찰 결과를 토대로 개선된 NDN 캐싱 기법을 제안한다.

인터넷의 성능 향상을 위하여 제안된 NDN은 다음과 같은 특징을 갖고 있다:

(1) 데이터의 고유 이름 기반의 패킷 포워딩

(2) 중간 네트워크 노드에서의 데이터 캐싱 및 포워딩

(3) 전자 서명 기반의 데이터 인증

또한, 이와 같은 특징을 구현하기 위하여 NDN은 다음과 같은 추가적인 요소들을 정의 한다:

(1) FIB (Fowarding Information Base) 테이블: 데이터 요청 메시지(Interest)에 포함되어 있는 데이터 이름/식별자를 기반으로 해당 Interest를 포워딩 할 전송 인터페이스 (Face)를 결정할 때 필요한 정보를 제공한다.

2) PIT (Pending Interest Table): 응답 메시지(Data) 수신 시, 해당 Data를 사용자들에게 전송하기 위하여, 수신된 Interest와 incoming Face 정보를 기록/관리한다.

(3) 네트워크 캐쉬 (Content Store, CS): 수신된 Data를 임시 저장한다.

(4) 데이터 서명 및 검증: 전송되는 Data는 각각 처음 Data를 생성한 생성자(Publisher)의 전자 서명을 포함하고 있으며, 수신자는 이 전자 서명 값을 이용하여 Publisher와 데이터 위/변조 여부를 확인한다.

Fig. 1 은 NDN의 Interest와 Data 처리 절차를 설명한다.

PPT Slide

Lager Image

(1) 수신 노드의 인터페이스 (예를 들어, Face 0)로 Interest를 수신한다.

(2) Interest에 해당하는 Data를 CS에 저장하고 있는지 여부를 확인한다. 만약 해당 Data를 저장하고 있다면, 저장하고 있는 Data를 Face 0를 통하여 전송한 후, Interest 처리를 완료한다.

(3) Interest에 해당하는 entry가 PIT에 이미 존재하는지 확인하다. 만약 대응되는 entry가 PIT에 존재한다면, 해당 entry에 Interest의 유입 Face (Face 0)를 추가한 후, Interest 처리를 완료한다.

(4) FIB 테이블을 참조하여, Interest를 포워딩할 Face (예를 들어, Face 2)를 선택한다.

(5) PIT에 Interest를 위한 새로운 entry를 추가한다.

(6) 4단계에서 선택된 Face로 Interest를 전송한 후, Interest 처리 절차를 완료한다.

(7) 이 후, 노드의 인터페이스 (Face 2)로 Data를 수신한다.

(8) 수신 된 Data에 해당하는 entry가 PIT에 존재하는지 확인한다. 만약 해당 entry가 PIT에 존재하지 않는다면, 수신된 Data를 폐기한 후, 처리 절차를 종료한다.

(9) Data를 CS에 저장한다.

(10) 단계 8에서 검색된 entry에 기록되어 있는 Face들로 Data를 전송한 후, 해당 entry를 PIT에서 삭제한다.

기본적인 NDN은 전송되는 모든 데이터를 전송 경로상의 모든 네트워크 노드에 저장한 후, 이를 이용하여 네트워크 성능을 향상시킬 수 있음을 보여주고 있다. 그러나 전송되는 모든 데이터를 캐싱할 경우, 각 노드마다 데이터 캐싱을 위해 대용량의 CS를 운영해야 한다. 또한, 이와 같은 대용량의 CS 운영은 저장 공간에 대한 오버해드 뿐만 아니라, Interest를 수신할 때마다 저장된 많은 수의 데이터를 매번 검색해야 하기 때문에 전체적인 응답 시간을 지연시킬 수 있다. 그러므로 전송되는 모든 데이터를 모든 노드가 저장하는 것은 매우 비효율적이다. 이와 같은 문제를 해결하기 위하여 데이터의 이용 빈도에 따라 캐싱 노드를 선택/운영하는 다양한 기법들이 다음과 같이 제안되었다 [5 - 9] .

(1) LCD: 임의의 노드가 저장하고 있는 데이터에 대한 Interest를 수신하여, 해당 데이터를 전송하는 경우, 해당 데이터의 전송 경로 위에 있는 노드들 중에서 첫 번째로 데이터를 수신한 노드만 해당 데이터를 캐싱 한다. 즉, 전송 경로 위에 있는 나머지 노드들은 데이터를 캐싱 하지 않고 전송만한다.그림 2 -(A)는 LCD의 운영 방법을 설명한다. 데이터를 저장하고 있는 Source가 Interest를 수신하면, Interest의 전송경로의 반대 방향을 따라 Data가 전송될 때, Source와 직접 연결된 A-Node만 Data를 캐싱 한다. 이 후, 해당 데이터를 요청하는 Interest를 A-Node가 수신하면, Data 전송 경로 위에 있는 노드 중에서 ANode와 직접 연결된 B-Node만 Data를 캐싱 한다. 이와 같은 캐싱 정책을 구현할 때, 데이터의 요청 빈도에 따라 데이터를 캐싱 하는 노드의 수를 점진적으로 증가시킬 수 있으며, 요청 빈도가 높은 데이터의 경우 사용자가 포함된 네트워크 (Edge Network)의 노드에 캐싱 된다.

PPT Slide

Lager Image

(2) MCD: LCD는 데이터를 캐싱하는 노드의 수를 점진적으로 늘려간다. 그러나 Interest 전송 경로의 제일 앞단에 위치한 노드에 데이터가 캐싱되어 있는 경우, 전송 경로 상에서 해당 노드보다 뒤에 위치한 노드들에 캐싱된 데이터는 사용되지 않는다. 즉, 사용되지 않는 불필요한 데이터 캐싱이 발생하게 된다. 이와 같은 문제를 해결하기 위해서 MCD는 데이터의 이용 빈도에 따라 데이터를 캐싱하는 노드를 사용자의 Edge Network 방향으로 점진적으로 이동시킨다. 즉, 데이터 소스가 아닌 중간 노드의 경우, CS에 저장된 데이터를 전송한 후, CS에서 해당 데이터를 삭제한다. Fig. 2 -(B)는 MCD의 운영 방법을 설명한다. A-Node가 캐싱하고 있는 데이터에 대한 Interest를 수신하여 대응되는 Data를 전송하면, 전송 경로사에서 A-Node와 직접 연결된 B-Node만 Data를 캐싱 한다. 이 때, A-Node는 Data를 전송한 후, CS에서 해당 Data를 삭제한다. MCD를 적용할 경우, Interest 전송 경로 위에 있는 노드들 중에서 데이터를 캐싱하고 있는 노드는 한 개뿐이다. 그러나 A-Node에서 데이터가 삭제된 후, 다른 경로를 통하여 A-Node가 삭제된 데이터에 대한 Interest를 수신하면, A-Node는 이를 처리할 수 없기 때문에 Interest를 데이터 소스에게 전송해야 한다. 이러한 경우, 네트워크 성능 저하를 초래할 수 있다.

(3) WAVE: NDN은 파일(File)을 일정 크기 이하의 여러 segment로 단편화 한 후, 각각의 segment를 단일 데이터로 간주하여 처리한다. LCD와 MCD는 이렇게 단편화된 데이터 단위로 캐싱을 운영한다. 즉, LCD와 MCD는 개별 데이터의 이용 빈도에 따라 해당 데이터의 캐싱을 결정한다. 반면에, WAVE는 파일의 이용 빈도를 이용하여 캐싱을 결정한다. 특히, WAVE는 데이터 캐싱 단위를 파일의 요청 빈도에 따라 지수 승으로 증가 시킨다. 예를 들어 Fig. 2 -(C)에서와 같이, 파일에 대한 첫 번째 요청 Interest들을 수신하며, 해당 파일의 첫 번째 segment의 Data가 캐싱 되기 시작하고, 해당 파일에 대한 두 번째 요청 Interest들이 수신되면, 두 번째 segment와 세 번째 segment의 Data들이 캐싱 되기 시작하며, 세 번째 요청에는 네 번째부터 일곱 번째 segment의 Data들이 캐싱 되기 시작한다. 이와 같은 캐싱을 통해서 WAVE는 LCD와 같이 점진적으로 데이터를 사용자의 Edge Network에 캐싱 하지만, WAVE는 이용 빈도에 따라 캐싱 증가 속도를 지수 승으로 증가 시킬 수 있다.

이와 같은 기법들의 공통적인 특징은 데이터의 이용 빈도가 높을수록 사용자의 Edge Network의 노드에 데이터를 캐싱하고, 해당 데이터에 대한 Interest를 사용자의 Edge Network 안에서 응답 처리되게 함으로써, Core Network에서 교환되는 패킷의 수를 효과적으로 줄일 수 있을 것으로 예상했다. 또한, 전송되는 데이터를 모두 캐싱하는 것이 아니라, 이용 빈도에 따라 캐싱되는 노드의 수를 증가시키기 때문에, 데이터 캐싱을 위한 노드의 저장 공간을 보다 효율적으로 유지/관리할 수 있을 것으로 기대되었다.

그러나 이와 같은 결과를 얻기 위해서는 사용자가 요청한 데이터가 사용자의 Edge Network에 캐싱되어 있어야 한다. 즉, 해당 데이터의 이용 빈도가 매우 높은 데이터의 경우에만 이와 같은 성능 구현이 가능하다. 실제로 2015년 Youtube의 이용 통계 자료에 의하면, 10억 명 이상의 이용자가 지난 1년 동안 Youtube를 통해 비디오를 시청했으며, 매일 평균 40 억 개의 비디오가 시청되고 있으며, 가장 높은 누적 시청 회수는 2억 5천회 이상의 시청 기록을 갖고 있다. 그러나 9개의 주요 카테고리 별 누적 평균 시청회수를 분석할 때, 가장 많은 평균 이용 회수 기록을 갖는 카테고리는 Entertainment로 평균 9,816건의 시청을, 가장 적은 카테고리는 People and Blogs로 2,354건의 평균 시청 회수를 기록하고 있다 [10 - 13] . 즉, 누적 평균을 고려할 때 대부분의 데이터들이 일만 건 이하의 시청 기록을 갖고 있다. 이는 데이터당 평균 0.001%의 이용자들만이 시청한다는 것을 의미한다. 그러므로 사용자의 Edge Network에 데이터가 캐싱 되는 경우는 전체 데이터 이용 건수를 고려할 때 매우 적을 수 있다. Fig. 3 은 이와 같은 분석을 바탕으로 계층적으로 구성된 네트워크 도메인의 각 Level에 캐싱된 데이터의 이용 빈도를 조사한 결과이다. 계층적 네트워크 구조의 Root에 해당하는 Core Network Node에 데이터가 저장될수록 데이터의 이용 빈도가 높고, Leaf Node에 해당하는 Edge Network Node에 데이터가 저장될수록 데이터 이용 빈도가 낮게 조사된다. 그러므로 이와 같은 각각의 노드별 데이터 이용 빈도를 고려하여 NDN 데이터 캐싱 기법을 개선할 필요가 있다.

PPT Slide

Lager Image

네크워크 노드에 캐싱된 데이터의 이용 빈도를 높이기 위하여 다음과 같은 두 가지 원칙을 기준으로 데이터 캐싱을 운영하는 방안을 제안 한다:

(1) 네트워크 성능 개선: 사용자가 생성한 Interest의 전송 경로 위에 있는 노드들 중에서, 많은 Interest들이 공통적으로 경유하는 노드에 데이터를 캐싱 한다.

(2) 저장 공간의 효율적 운영: 데이터의 이용 빈도에 따라 데이터 캐싱 영역을 점진적으로 확장한다.

이와 같은 데이터 캐싱 운영 기준에 따라 NDN 데이터 캐싱을 개선하기 위하여 네트워크 토폴로지 구성과 캐싱 프로세스를 다음과 같이 제안한다.

많은 수의 노드들을 네트워크로 연결하고, 이들 노드들 사이의 전송 효율성을 높이기 위하여 네트워크 도메인에 포함된 노드들을 계층적으로 구성하는 것이 일반적이다. 또한, NDN은 Domain Name Server와 같은 Resolution Server를 이용하지 않고 Interet/Data를 전송하기 위하여 데이터의 유일한 식별자인 데이터 이름을 계층화하여 운영한다.

본 논문에서는 NDN의 계층화된 데이터 이름과 네트워크 도메인의 계층을 연계하여 운영하는 방안을 제안한다. 즉, Fig. 4 처럼, 명명된 계층화된 네트워크 도메인(Named-Network Doamin Hierarchy)을 다음과 같이 운영한다.

PPT Slide

Lager Image

(1) 각각의 네트워크 도메인 (CU-HD과 CS_HD)은 Border Gateway를 Root Node로 하고, 계층화된 서브 도메인마다 Gateway를 운영한다. 또한, 이들 도메인(서브도메인)/사용자 호스트는 계층화된 도메인/호스트 식별자를 각각 갖고 있으며, 도메인/서브도메인의 Gateway 관리자는 도메인/서브도메인 식별자를 해당 Gateway에 설정되고, 사용자는 사용자 호스트에 호스트 식별자를 설정한다.

(2) 데이터의 유일한 식별자는 이들 계층화된 호스트 식별자를 이용하여 생성한다. 예를 들어 데이터 소스의 호스트가 연결된 네트워크의 계층의 도메인/서브도메인의 식별자를 구성하는 요소가 Root Node로부터 각각 'dn1', 'dn2', 'dn3' 라하고, 해당 호스트의 식별자 요소를 ‘sou'라고 한다면, 해당 호스트의 네트워크 계층 식별자는 ’dn1/dn2/dn3/son‘이 된다. 이 때 해당 호스트에서 생성/배포하는 데이터의 이름은 ’dn1/dn2/dn3/son’을 데이터 이름 접두어(Content Name Prefixs)로 사용한다.

Fig. 4 에서와 같이, 계층화된 도메인 식별자를 기반으로 데이터를 점진적으로 캐싱 하기 위하여, 본 논문에서는 기존 Data 구성 형식에 Caching Flag Bit (CFB)를 추가한다. Interest를 수신한 노드가 해당 Interest에 의해 요청된 데이터를 CS에 캐싱 하고 있다면, 다음과 같은 절차를 따라 Interest를 처리 한다:

(1) PIT 검사를 수행한다. 수행 절차는 기본적인 NDN 수행 절차와 동일하다.

(2) CS 검사를 수행한다. 수행 절차는 기본적인 NDN 수행 절차와 동일하다. 가정에 따라 해당 노드의 CS에는 대응하는 데이터가 저장되어 있다.

(3) CS에 저장되어 있는 데이터의 CFB를 True로 설정한 후, 해당 Interest의 유입 Face를 통하여 전송한다.

(4) PIT에서 해당 Interest에 대응하는 entry를 삭제한 후, Interest 처리 절차를 종료한다.

Data를 수신한 노드는 다음과 같은 절차를 따라 수신된 Data를 처리한다.

(1) PIT 검사를 수행한다. 수행 절차는 기본적인 NDN 수행 절차와 동일하다.

(2) 수신된 Data의 CFB를 확인한다. CFB가 False이면, 수신된 Data를 CS에 저장하지 않는다.

(3) CFB가 True이면, 다음과 같은 두 가지 경우에만 해당 Data를 CS에 저장한다.

① 수신 노드의 네트워크 계층 이름이 Data의 데이터 계층 이름의 prefix에 포함된 경우. 즉, 수신 노드가 데이터 소스의 네트워크 도메인의 Root Node와 데이터 소스 사이의 전송 경로 위에 존재하는 Gateway인 경우.

② 수신 노드가 네트워크 도메인의 Root Node인 경우. 즉, 수신 노드가 Core Network 망을 구성하는 노드인 경우.

(4) 수신된 Data의 CFB를 False로 수정한다.

(5) Data를 PIT에 기록된 관련 entry의 Face들을 통해서 전송한다. 이 때, 어떤 경우에든지 Data의 CFB는 항상 False이다.

(6) PIT에서 해당 entry를 삭제한 후, Data 처리 절차를 종료한다.

제안된 데이터 캐싱 기법의 성능 평가를 위하여 NDN, LCD 그리고 제안된 DNbC의 성능을 비교 평가한다. 이를 위하여, 본 논문에서는 랜덤하게 선택된 사용자들이 생성된 데이터를 랜덤하게 요청하는 시뮬레이션을 구현하여 그 결과를 관찰하였다. 시뮬레이션은 Fig. 5 와 같이 5개의 서로 다른 Network Domain으로 구성된 Core Network 망을 가정하고 있으며, 각각의 Network Domain은 다음과 같이 계층적으로 구성하였다.

PPT Slide

Lager Image

(1) Root Node는 5개의 Sub-domain들을 Child로 갖으며, Leaf Node를 제외한 나머지 노드들은 각각 4개의 Sub-domain들을 Child로 갖는다.

(2) Leaf node는 사용자 기기로 간주하며, Interest의 최초 생성자는 Leaf node로 한정한다.

(3) 각각의 노드는 Interest 전송을 위한 FIB 테이블을 구성/관리한다고 가정한다.

네트워크를 구성하는 각각의 노드들의 환경 설정은 다음과 같다:

(1) 네트워크를 통해 접근 가능한 데이터는 16,000 개이며, 랜덤하게 선택된 노드들에서 생성한다. 또한, 이들 데이터는 동일한 이용 빈도를 갖는다.

(2) 각각의 노드는 1000개의 데이터를 동시에 저장할 수 있는 CS를 운영한다.

(3) 캐싱된 데이터의 생명주기(Lifetime)는 모든 노드에서 50초로 설정한다.

(4) 랜덤하게 선택된 Leaf Node에서, 16,000개의 데이터 중 하나를 랜덤하게 선택하여 요청한다.

(5) 평균 응답률은 96.7%로 설정한다.

Fig. 6 은 시뮬레이션 과정 중에서 각각의 노드에 캐싱된 데이터의 평균 개수의 총합을 나타낸다. LCD와 DNbC는 데이터의 요청 빈도에 따라서 해당 데이터의 캐싱 노드의 수를 점진적으로 늘려나가기 때문에 모든 노드에 데이터를 캐싱 하는 NDN에 비하여 효율적으로 네트워크 캐쉬를 운영할 수 있다. 그림 6 에서와 같이 NDN에 비해 20% 정도의 캐쉬 만으로도 서비스 운영이 가능하다. 또한, DNbC의 경우, 점진적으로 캐싱 되는 노드를 Core Network으로 한정시켜 운영하기 때문에, 사용자의 Edge Network에 추가적으로 캐싱되는 경우는 데이터 소스가 포함된 네트워크 도메인으로 한정된다. 그러므로 LCD에 비해 30% 정도의 추가 절감 효과를 기대할 수 있다.

PPT Slide

Lager Image

Fig. 7 은 NDN, LCD, DNbC의 Interest 전송량을 비교 분석한 결과를 나타낸다. 최대 100,000개의 Interest가 랜덤하게 선택된 데이터를 요청하기 위하여 생성/전송될 때, 네트워크 노드에서 해당 Interest들을 포워딩한 수를 누적하여 측정하였다: NDN과 비교할 때 LCD와 DNbC는 2% 정도의 Interest 전송량이 증가한다. 그러나 LCD와 DNbC만을 비교할 때, 오히려 0.2% 정도 감소하는 것으로 나타났다. 이는 데이터 이용 빈도와 오차를 고려할 때 무시할만한 수치이지만, 데이터를 사용자의 Edge Network에까지 캐싱하는 것에 비해, Core Network에까지 캐싱하는 것이 전송 효율에 큰 영향을 미치지 않음을 알 수 있다.

PPT Slide

Lager Image

또한, 내부 도메인과 Core Network을 구성하는 Border Gateway로 캐싱 구간을 이중화 하여 제한함으로써, Interest가 집중되는 영역을 분산시키는 NDN의 장점을 그대로 유지시키면서도 네트워크와 스토리지의 오버해드를 개선할 수 있다.

NDN은 네트워크 노드에 캐싱된 데이터를 활용하여 네트워크의 효율성을 높이기 위해 제안되었다. 그러므로 어떤 데이터를 어느 위치에 캐싱하여 운영할지를 결정하는 것이 무엇보다 중요하다. 지금까지 발표된 대부분의 연구들은 사용자 노드가 위치한 Edge Network에 데이터를 캐싱하는 방안들이 대부분을 차지하고 있다. 이는 Interest를 사용자의 Edge Network내에서 응답 처리되게 함으로써 Core Network으로 유입되는 Interest/Data의 수를 줄일 수 있을 것으로 예상했기 때문이다. 그러나 본 논문에서는 이와 같은 연구 결과는 일부 인기 데이터에 대해서만 도출이 가능하고, 대부분의 데이터는 일부 Edge Network에만 캐싱 되기 때문에, 해당 Interest들이 여전히 Core Network로 유입될 수 있음을 지적하였다.

이와 같은 문제들을 해결하기 위하여 본 논문은 기존의 데이터 요청 빈도에 따른 점진적으로 데이터 캐싱 범위를 확대하던 기존의 기술에 노드의 접근 빈도를 추가적으로 감안하여 데이터 캐싱 여부를 결정하도록 제안한다.

본 논문의 제안을 시뮬레이션을 통해 관찰한 결과 기존 캐싱 기법과 비교할 때 유사한 네트워크 효율성을 나타내면서도 스토리지 효율성을 개선할 수 있음을 알 수 있다. 또한, 내부 도메인과 Core Network을 구성하는 Border Gateway로 캐싱 구간을 이중화하여 제한함으로써, Interest가 집중되는 영역을 분산시키는 NDN의 장점을 그대로 유지시키면서도 네트워크와 스토리지의 오버해드를 개선할 수 있다. 그러므로 네트워크 캐쉬의 효율적인 운영을 통하여 점차 다양해지고 있는 스마트 IT 융복합 서비스의 안정적인 구현이 가능할 것으로 기대된다.

김 대 엽

1997년 3월∼2000년 2월 고려대학교 대학원 수학과 이학박사

1997년 9월∼2000년 3월 ㈜텔리맨 CAS팀 연구원

2000년 4월∼2002년 8월 시큐아이닷컴 정보보호연구소 차장

2002년 9월∼2012년 2월 삼성전자 종합기술원 전문연구원

2012년 3월∼현재 수원대학교 정보보호학과 조교수

2016년 1월∼현재 수원대학교부설 IT연구소 소장

관심분야 : 보안프로토콜, 네트워크/시스템 보안, 콘텐츠 보안, 미래 인터넷 보안