대규모 사물인터넷 에뮬레이션 테스트베드의 구현

Ⅰ. 서 론

임베디드 장치 및 다양한 네트워크의 발전으로 장치와 장치가 연결되어 새로운 서비스가 출시되고 있는데 센서와 같은 소형 장치들이 이질적인 네트워크에 연결되어 상호 통신하는 이른바 M2M(Machine-to-Machine)이 대표적이다[1]. 특히 사물인터넷은 인터넷 프로토콜을 적용하여 이질적인 장치들을 연결하여 범용서비스를 제공하는 스마트 시티, 홈 네트워크, 빌딩 정보 시스템 등에서 필수 서비스로 활용되고 있다[2].

사물인터넷의 장치들은 대부분 임베디드 형태로서 컴퓨팅 파워, 메모리, 그리고 배터리 등의 자원이 제한적이므로 서비스 설계시 경량 구조를 유지하면서도 확장성, 신뢰성, 보안성, 접근성 등의 요구사항을 만족해야 한다. 특히 스마트시티와 같은 대규모 서비스의 경우 확장성과 접근성은 핵심 고려사항인데 REST(Representational State Transfer)모델은 센서가 제공하는 서비스와 자원의 유일한 표현이 가능하여 사물인터넷과 같은 제한된 환경에서 적용되기 수월하므로 센서 장치들은 웹의 일부로 적용될 수 있다[3][4].

특히 OMA SpecWorks의 LWM2M(Lightweight Machine to Machine)은 사물인터넷 장치에 포함된 오브젝트, 자원을 관리하는 CoAP(Constrained Application Protocol) 기반 관리 서비스 프로토콜이다. 또한 기존 셀룰러 사업자 네트워크 및 사물 인터넷을 포함하는 다양한 네트워크에서 수십억 개의 장치를 지원하는 서비스 계층에서의 관리 모델의 제공에 초점을 맞춘 무선 산업 전반의 간소화된 사양이다[5].

이 LightweightM2M을 구체적으로 살펴보면 M2M 장치의 원격 관리 및 관련 서비스 활성화를 위해 설계되었는데 REST를 기반으로 한 최신 아키텍처 디자인을 특징으로 하고 확장 가능한 리소스 및 데이터 모델을 정의하며 CoAP 기반의 효율적인 보안 데이터 전송 표준을 기반으로 한다. 특히 IPSO(Internet Protocol for Smart Objects) Alliance는 LWM2M 오브젝트를 기반으로 다수의 범용 오브젝트들을 정의하고 있는데 이는 다양한 센서나 액추에이터의 범용 타입을 표현하고 있어 사물인터넷 디바이스의 추상화 및 확장에 중요한 역할을 하고 있다[6].

본 논문과 같이 대규모의 사물인터넷 서비스에서는 다양한 자료의 센싱, 액추에이션, 제어 그리고 서비스 로직들 간의 상호 독립성은 서비스 플랫폼의 확장성, 접근성을 위한 핵심 요구사항이다. 한편 이 요구사항들을 만족하기 위해서 실제 센서를 배치하고 네트워크를 구축하여 서버를 통해 서비스하는 것은 시간과 비용 측면에서 효율적이지 못한 것은 당연하며 구축하는 동안 각종 장치의 노후화는 피할 수 없다.

따라서 본 논문에서는 대규모 사물인터넷 플랫폼의 상기 요구사항과 실 구축시의 문제점을 해결하기 위해 LWM2M 기반으로 사물인터넷 에뮬레이션 테스트베드를 구축하여 확장성과 접근성 검증을 하고자한다.

구현된 테스트베드는 실제 환경은 아니지만 장치관리 서버의 경우 실제 서비스가 가능하고 각종 장치 애플리케이션의 경우 IPSO 규약에 따라 개발되어 실제 임베디드 장치에 탑재되는 프로토콜 스택과 동일하므로 실제 장치처럼 운영된다. 즉 구현된 오브젝트들은 실제 장치에서와 동일한 코드, 프로토콜, 패킷 페이로드를 사용하므로 서버 입장에서는 실제 장치의 요구와 동일하므로 노드의 동작에 대한 실제와 동일한 다양한 시나리오를 수행할 수 있다.

그리고 구현된 LWM2M 서버 및 클라이언트는 도커 컨테이너 형태로 동작하는데 이는 실제 서비스를 고려하면 이질적인 하드웨어 및 운영체제 상에서 서비스 동작 환경의 빈번한 변경 없이 즉각 수행이 가능하므로 운영의 효율성과 확장성에 유리할 것이고 특히 대규모 서비스의 경우 가상화 환경 도입시 도커 컨테이너는 자원의 활용성 측면에서도 개선된 서비스 환경을 제공할 수 있다.

논문의 구성은 다음과 같다. 2장에서는 LWM2M, CoAP, 도커, 그리고 사물인터넷 관련 기존 연구들을 소개한다. 3장에서는 본 연구에서 제안하고 있는 LWM2M 기반의 사물인터넷 에뮬레이션 플랫폼을 제안하고 4장에서는 유스케이스 기반으로 시뮬레이션을 수행하여 제안 플랫폼의 확장성, 접근성을 검증하고 5장에서 결론을 맺는다.

Ⅱ. 관련 연구

LWM2M이 기반으로 하는 CoAP는 임베디드 장치와 같이 제한된 자원과 네트워크 환경에서 상호작용을 위해 설계된 경량 RESTful 웹 전송 프로토콜으로서 저 수준의 오버헤드, 멀티캐스트 지원, 그리고 내장된 자원 탐색 등 사물인터넷에 특화된 특성을 적용하기 위해 HTTP를 재설계한 것이다[7].

CoAP를 기반으로 하는 LWM2M의 경우 oneM2M 표준으로서 DTLS 기반의 보안, 표준 오브젝트 모델, 그리고 다양한 디바이스 지원을 특징으로 하는데 또 다른 표준인 OMA-DM, TR-069 대비 상이한 특성으로는 CoAP/UDP 전송 프로토콜을 사용하며 표준 오브젝트 모델로 응용 데이터를 지원하며 Binary/JSON 형태의 페이로드를 가진다.

LWM2M 기반의 시스템은 서버와 클라이언트 모델로서 클라이언트는 디바이스 상에서 동작하는 소프트웨어이며 서버는 부팅 시 서버정보, 보안키 획득 등의 과정을 수행하는 부트스트랩 서버와 클라이언트 등록, 디바이스 관리 및 서비스 인터페이스, 그리고 정보보고를 지원하는 서버로 이원화되어 있다.

본 연구에서는 LWM2M 서버, 부트스트랩 서버, 그리고 클라이언트를 도커 기반의 이미지로 생성하여 사물인터넷 에뮬레이션 테스트베드를 구축하고 있는데 도커 컨테이너는 하드웨어 및 운영체제 독립형 가상화를 가능하게 하는 소프트웨어 기술이다[8]. 본 연구에서 도커 컨테이너를 도입하는 이유는 이질적인 하드웨어 및 운영체제 환경에서 도커 엔진만 존재한다면 사물인터넷 플랫폼을 재구축할 필요 없이 즉시 운영 가능하고 확장성 검증이 수월하기 때문이다. 특히 도커의 경우 기존 클라우드 플랫폼에서 하드웨어 가상화, 운영체제 가상화 등은 자원 사용량이 높고 환경 구축이 복잡한 반면 도커의 경우 기존 플랫폼에서 도커만 설치되면 즉시 가상화 서비스를 수행할 수 있으므로 본 연구의 목적을 달성할 수 있는 최적의 환경이다.

클라우드와 그리드와 같은 상이한 시스템의 자원 관리를 위한 다수의 시뮬레이션 환경이 제안되어 왔는데 먼저 SimIoT의 경우 실시간 및 동적 사용자 관리를 위한 툴킷으로 가상 머신 관리, 실시간 메시징, 그리고 디바이스 관리 기능을 제공하는데 이질적인 장치는 지원하지 않는다[9]. IoT Inspector 의 경우 크라우드 소싱으로 개별 가정의 사물인터넷 유스케이스를 수집하고 분석하는 도구로서 본 연구와는 목적이 상이하고 Bot-IoT의 경우 시뮬레이션 기반으로서 네트워크 침입에 대한 분석과 대처를 위해 실제 환경에서 패킷을 수집하고 이를 통해 데이터 셋을 구축하여 머신 러닝을 통해 비정상적인 트래픽을 구분하는 데 그 목적이 있다[10]. IoT-LAB의 경우 소규모 무선 센서 장치간의 상호작용과 이질적 네트워크 환경에서 에뮬레이션 기반의 사물인터넷 테스트베드로서 실제 장치에서 동작하며 다양한 모빌리티 환경에서 사용자의 응용 서비스를 실제 구축하기 전에 테스트 할 수 있는 점에서 본 논문과 유사하나 본 논문은 확장성과 접근성, 그리고 디바이스 관리에 중점을 두고 있는 점에서 지향점이 상이하다[11].

Ⅲ. 대규모 사물인터넷 테스트베드의 설계 및 구현

본 논문은 대규모 사물인터넷 환경을 위해 표준 인터넷 프로토콜 기반으로 각 장치들의 상호 작용을 제공하고 서버 부하 실험을 통한 확장성, 그리고 접근성을 효율적으로 제공하는 사물인터넷 테스트베드를 제안하는 것이다.

먼저 본 논문에서 구현한 테스트베드의 구조는 그림 1에서 보듯이 하드웨어, 운영체제, 도커 엔진, 그리고 LWM2M CoAP 컨테이너로 구성된다. 하드웨어는 인텔 제온 2.1GHz 2 CPU, 64GB 램으로 대규모 사물인터넷 에뮬레이션이 가능하며 운영체제는 우분투 20.x VM으로서 도커 엔진 20.10.6 버전을 설치하였다. 도커 엔진위에 세 종류의 CoAP 노드들이 도커 컨테이너로서 동작하는데 각 컨테이너는 openjdk:17-alpine 기반의 도커 이미지들로서 먼저 클라이언트 관리 서비스를 제공하는 LWM2M 서버 컨테이너, 클라이언트 부트스트래핑, 생성 및 삭제 기능을 담당하는 LWM2M 부트스트랩 서버 컨테이너, 그리고 각종 장치 기능을 에뮬레이션하는 LWM2M 클라이언트 컨테이너들이 서버 컨테이너와 상호작용하면서 사물인터넷 서비스를 제공한다.

Fig. 1.

Testbed structure

그림 1의 서버 및 부트스트랩 컨테이너 이미지는 자바 기반의 LWM2M 공개 소스로서 이클립스 프로젝트인 Leshan 라이버러리 기반으로 구현되었으며 클라이언트 컨테이너 이미지 역시 자바로 LWM2M 스펙 1.x을 준수하여 작성되었다. 본 테스트베드는 가상 장치의 구현으로 장치간의 상호작용, 확장성, 그리고 접근성을 제공하는 플랫폼을 구축하는 것이므로 OMA에서 지원하는 사물인터넷 환경에서 널리 사용되는 Leshan을 사용하였다. Leshan 라이버러리의 경우 CoAP, DTLS, LWM2M, 그리고 IPSO 오브젝트를 지원하며 표 1에서 보듯이 bootstrap, registration, device management & service, information report 등의 기능을 충실히 제공한다.

Table 1.

Main interfaces of testbed

그림 1의 클라이언트 컨테이너 이미지는 LWM2M 클라이언트로 동작하며 IPSO 모델에 기반한 CoAP, LWM2M 프로토콜을 지원한다. 따라서 장치 생성과 서버와의 인터페이스를 제공하는데 실제 장치와 거의 동일하게 동작한다.

클라이언트의 부트스트래핑은 서버 및 클라이언트 측에서 모두 할 수 있는데 Leshan 라이버러리의 경우 서버 측에서만 지원하는데 본 구현에서는 클라이언트 측에서도 할 수 있도록 구현하였다. 이는 부트스트래핑의 핵심 연산중의 하나로서 클라이언트의 오브젝트 인스턴스를 생성, 삭제할 수 있는 것이다. 또한 클라이언트 장치간의 상호작용을 위해 서버를 거치지 않고 장치 및 게이트웨이 노드에 직접 제어 로직을 구현하였는데 이는 단일 응용에 소속된 오브젝트들의 경우 유스케이스의 공통 목적 달성에 용이하다.

Ⅳ. 성능 평가

이번 장에서는 본 논문에서 제안한 테스트베드의 성능 평가 환경과 결과를 제시한다. 대규모 사물인터넷을 적용하기에 적합한 응용인 스마트 시티의 공공 가로등은 교통과 행인의 빈도에 따라 적절한 밝기를 자동 제어하여 전력을 감소시킬 수 있어 그림 2에서 보듯이 테스트베드의 클라이언트 응용으로 선정하였다.

Fig. 2.

LWM2M client model(smart streetlight)

그림 3은 LWM2M 클라이언트인 스마트 가로등의 시퀀스 다이어그램으로서 게이트웨이, 조도센서, 움직임 감지센서, 위치센서, 그리고 가로등 제어기 등이 LWM2M 서버에 등록이 되면 REST 메시지를 통해 상호작용한다.

Fig. 3.

Sequence diagram of smart lighting

게이트웨이는 그림 3의 시퀀스 다이어그램에서 보듯이 조도와 움직임 감지센서로부터 게이트웨이가 관리하는 가로등 주변의 밝기와 교통량 또는 행인의 빈도를 주기적으로 감시하여 가로등 점등과 밝기 정도를 결정한다. 또한 게이트웨이는 서버에 점등시간과 디밍(Dimming)을 보고하여 다양한 사물인터넷 응용서비스에 관련 정보를 제공할 수 있다. 따라서 본 클라이언트 모델에서는 게이트웨이 노드가 조도센서, 움직임 감지센서, 가로등 제어기와의 상호작용으로 자율적으로 가로등의 점등과 밝기를 제어한다.

공공 가로등의 실험 변수는 참고문헌 [12]의 ETSI 기술 문서와 참고문헌 [13]의 교통 데이터거래소를 참고하여 표 2와 같이 설정하였다. 실험 시간은 하루 내에서 발생 가능한 최대값을 반영하여 한 시간으로 설정하였다.

Table 2.

Main parameters of experiment

실험 변수에서 센싱 주기는 실험 시간 1시간을 감안하여 3초마다 실시하고 교통량, 행인은 포아송 분포로 도착하는데 참고문헌[13]의 데이터는 5분 단위이고 가로등 위치에 따라 매우 다양하여 실험에서도 5분 주기로 람다(λ) 10을 최대치로 랜덤하게 발생시켜 람다가 9~10이면 디밍의 최대값을 100%, 7~8이면 80%, 5~6이면 60%, 3~4이면 40%, 그리고 2이하이면 최소값 20%로 설정하였다.

본 실험을 통해 클라이언트 수에 비례한 기동지연(Activation delay), 동시실행 가능한 클라이언트의 최대 수, 그리고 클라이언트 수에 따른 시스템 부하를 분석하여 테스트베드의 확장성과 접근성을 제시하고자 하는데 사실상 그림 2의 모델이 주어진 시스템 환경에서 가능한 많은 클라이언트, 즉 도커 컨테이너를 안정적으로 실행하는 것이다.

첫 번째 실험은 기동지연으로 하나의 도커 컨테이너 즉, 클라이언트는 조도, 물체감지, 가로등제어, 그리고 위치 센서 등 4개의 디바이스로 구성되는데 이들 장치들이 서버에 등록되고 최초의 동작을 시작할 때까지의 지연시간을 의미한다. 그림 4는 1~300개의 클라이언트(디바이스 4~1,200개)가 1, 3개의 가상머신에서의 기동지연을 측정한 것이다.

Fig. 4.

Activation delay over clients

백그라운드에서 동작하는 컨테이너의 수가 증가할수록 기동지연도 증가하는데 이것은 각 장치를 서버에 부트스트래핑하는 과정에 따른 오버헤드로서 3개의 가상머신에서는 5ms에서 200ms까지 증가하는 것으로 조사되었는데 가상머신의 수가 증가할수록 기동지연은 감소할 것으로 보인다.

반면 1개의 VM에서는 130개의 클라이언트까지는 안정적이고 그 이상이 되면 최대 1,800ms까지 급격히 증가하고 등락이 심한데 이를 통해 한 개의 VM에서 안정적으로 서비스 가능한 장치의 임계치를 결정할 수 있고 본 연구와 같은 대규모 환경에서는 다수의 VM 또는 서버가 요구됨을 확인할 수 있다.

그림 5는 동시실행 가능한 클라이언트의 수로서 3개의 VM에서 100, 300, 700 clients가 백그라운드에서 동시에 시작되고 서버 모니터링 도구인 glances로 한 시간 동안 사용자 CPU 사용률을 측정한 것이다. 각 클라이언트의 조도센서, 움직임 감지 센서는 게이트웨이로 센싱값을 주기적으로 보내고 게이트웨이는 서버에 자신의 상태를 보내는데 조도가 특정 임계를 초과하면 혼잡의 정도에 따라 가로등의 밝기를 조정한다. 100, 300개의 경우 평균 부하가 각각 5, 10% 이하로 안정적으로 운영되나 700개의 경우 15% 이상의 평균 부하를 보여주고 있는데 특히 35% 까지의 피크 부하를 나타내고 있는 점을 고려하여 운영 가능한 클라이언트의 한계를 결정할 수 있을 것으로 판단된다.

Fig. 5.

CPU usage over one hour

그림 6은 클라이언트 수에 따른 시스템의 부하를 나타낸다. 통상적으로 시스템 부하가 1분 평균 0.7 이하이면(그림 6에서 0.7을 100%로 환산함) 적절한 부하로 간주되는데 100% 이하이면 마감시간을 충족하고 그 이상이면 지연이 발생함을 의미한다. 따라서 100% 이하의 경우 각 디바이스의 요구가 적합한 시간 내에 처리될 수 있는데 100, 300 클라이언트의 경우 대부분 60% 미만으로 마감시간이 보장되나 700 클라이언트는 실험 결과 마감시간 미스가 103회(총 3600샘플) 발생하였다. 이는 약 2.8% 로서 사물인터넷이 실시간 응용이 아니므로 허용 가능한 수치로 판단된다.

Fig. 6.

System load(%)

상기의 세 가지 실험을 통해 본 논문에서 구성한 실험 환경에서는 3개의 VM에서 약간의 마감시간 미스를 허용한다면 최대 700개의 클라이언트가 서비스 가능함을 알 수 있다. 따라서 주어진 하드웨어 및 소프트웨어 환경에서 최대 서비스 가능한 클라이언트의 수를 제시할 수 있는 것은 본 연구의 목적인 테스트베드의 확장성과 접근성 결정의 근거로 판단된다.

Ⅴ. 결 론

본 논문에서는 LWM2M 기반의 대규모 사물인터넷을 위한 에뮬레이션 테스트베드를 제시하였는데 구현된 테스트베드는 LWM2M 서버, 부트스트랩 서버, LWM2M 동작을 수행하는 디바이스, 그리고 이를 위한 도커 컨테이너 환경 등으로 구성된다.

제시된 테스트베드는 LWM2M 프로토콜을 통해 장치의 부트스트래핑, 등록/해제, 자원의 입출력, JSON/TLV 등의 데이터 포맷 지원, 그리고 장치간의 통신 등을 제공하여 실제 환경과 동일한 유스케이스를 제공할 수 있다. 또한 도커 컨테이너로 구현되어 이질적인 환경에서도 즉각 실행할 수 있고 기동 지연, CPU 사용률, 그리고 시스템 부하 측정을 통해 확장성과 접근성을 결정할 수 있다.

References

• A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, "Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications", IEEE Communications Surveys and Tutorials. Vol. 17, No. 4, pp. 2347-2376, Oct. 2015. [https://doi.org/10.1109/COMST.2015.2444095]
• J. Holler and V. Tsiatsis, "From Machine-to-Machine to the Internet of Things: Introduction to a New Age of Intelligence", UK: Elsevier, pp. 100-113, Apr. 2014.
• H. Tschofenig, J. Arkko, D. thaler, and D. McPherson, "Architectural Considerations in Smart Object Networking", IETF RFC 7452, Mar. 2015. [https://doi.org/10.17487/rfc7452]
• A. Keranen and M. Kovatsch, "RESTful Design for Internet of Things Systems", https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-rest-iot-06, . [accessed: May 05, 2021]
• Open Mobile Alliance, "Lightweight Machine-to-Machine Technical Specification V1.0 Approved", http://www.openmobilealliance.org/, . [accessed: Jan. 10. 2021]
• IPSO Alliance, https://www.ipso-alliance.org/, . [accessed: Jan. 10. 2021]
• Z. Shelby, K. Hartke, and C. Bormann, "Constrained Application Protocol (CoAP)", IETF RFC 7252, https://datatracker.ietf.org/doc/html/rfc7252, . [accessed: Jan. 19. 2021]
• R. Morabito, J. Kjallman, and M. Komu, "Hypervisors vs. lightweight virtualization: a performance comparison", IEEE International Conference on Cloud Engineering, Tempe, AZ, USA, pp. 386-393, Mar. 2015. [https://doi.org/10.1109/IC2E.2015.74]
• S. Sotiriadis, N. Bessis, E. Asimakoopulou, and N. Mustafee, "Towards Simulating the Internet of Things", 28th International Conference on Advanced Information Networking and Applications Workshops, Victoria, BC, Canada, pp. 444-448, May 2014. [https://doi.org/10.1109/WAINA.2014.74]
• Bot-IoT Dataset, http://https://arxiv.org/abs/1811.00701, . [accessed: Mar. 06, 2021]
• FIT IoT-LAB, http://www.iot-lab.info, . [accessed: Mar. 09, 2021]
• ETSI TR 103 055, http://www.etsi.org, . [accessed: Mar. 09, 2021]
• Ttraffic data exchange, https://www.bigdata-transportation.kr/, . [accessed: Mar. 09, 2021]