IoT/ M2M 서비스 사례 및 구축 기술 ⑥ - Special Report

IoT/M2M 환경을 위한 미들웨어 서버 플랫폼

앞서 이야기한 디바이스와 게이트웨이에서 네트워크를 통하여 데이터 센터로 보내게 되면 미들웨어를 통하여 데이터센터의 처리가 시작된다. 이러한 IoT/M2M 서비스 환경의 운영 시스템의 기준은 사람의 라이프 사이클이 아닌 디바이스기기 혹은 기계의 라이프 사이클에 따라서 시스템이 디자인 되어야 한다. 센서기기 혹은 게이트웨이 기기는 배터리 에너지가 지속적으로 공급되고 고장이 나지 않는 한 365일 24시간 계속해서 동작하는 시스템 환경이다. 특히 IoT/M2M기술을 적용하여 사람의 오감(혹은 육감)으로 인지하지 못하는 능력으로 확장하고 이를 생명과 연관된 경우 이를 위한 365일 24시간 쉬지 않고 대응이 가능한 시스템 기술은 필수적이다. 서비스들 간의 연계가 사람의 역할을 최소한 적용하게 만들면서, 사람은 그 시스템에 대한 모니터링과 조력자의 역할만을 수행 하도록 시스템을 구성하는 것이 요구 된다.

(1) IoT/M2M 플랫폼 구축 시 고려사항

1) 무정지 시스템: 센서디바이스, 예를 들어, 스마트미터링기기의 경우에는 24시간, 지속적으로 데이터를 서버로전송하는 시스템이다. 이런 경우는 결코 시스템이 중단 되어서는 안되는 환경이다. 하지만 내부의 서비스와 서버기능 자체의 업그레이드가 필요할 수가 있다. 이런 경우 시스템을 중단하지 않고 시스템 업그레이드와 동시에 바로 서비스가 될 수 있는 시스템 구조가 필요하다.

2) 빠른 응답시간: M2M 비즈니스 모델은 의료기기 센서시스템이나 응급구조를 위한 감시 시스템처럼 빠른 응답 시간이 필요한 경우가 있다. 이를 위해 수초 이내에 감지가 가능한 빠른 시스템이 필요하다.

3) 시스템 고가용성: HA구성은 기존의 서비스 환경에서도 많이 사용하는 시스템이다. 하지만 M2M의 경우 장애시 연동되고 있는 영향을 받는 기기의 수와 시스템의 정지 시간에 따라 문제의 파급효과가 커질 가능성이 높은 시스템이다. 아무리 잘 구성되어 있는 시스템이라도 장애가 나지 않는 경우는 잘 없다. 장애가 발생 하였을 경우 이를 위한 장애대처를 위해 빠르게 다른 시스템으로 대응할 수 있는 시스템 구성을 고려해야 한다.

4) 다양한 서비스의 효율적인 조합: M2M 비즈니스는 센서로부터 받은 데이터를 통하여 분석하고 이를 다양한 서비스에 연동시키는 것이 필요하다. 차량과 관련된 텔레매틱스 서비스 시스템의 경우 차량에 대한 장애 센서에 문제되는 감지가 일어났을 경우 즉시 텔레매틱스 사내 대응팀, 외부 응급구조체계, 보험회사와 같은 다양한 서비스가 연계되어 이를 처리하는 시스템을 구성할 수 있다. 이를 위한 복합 서비스 연계 기술이 필요하다. 또한 최 근접 주유소 혹은 전기 충전소 알림과 같은 신규서비스가 개발이 되었을 경우 경쟁회사보다 빠르게 서비스를 출시 할 수 있어야 한다.

5) 가벼운 서버 사이드 플랫폼: M2M의 아키텍처는 기존의 고성능 PC(휴대폰)와 초고성능 서버로만 이루어 지는 것이 아닌 다양한 하드웨어 성능을 가지는 시스템이 참가할 수 있다. 간단한 성능의 라즈베리파이로 만든 시스템이나 그 보다 조금 더 나은 성능의 비글과 같은 경량의 기기를 통한 시스템이 참가할 수도 있다. 이런 시스템에 기존의 무거운 미들웨어를 올리는 것은 쉽지 않은 일이다. 특히 게이트웨이와 같은 통합된 소형 기기를 위한 시스템은 그에 맞는 경량의 미들웨어 기술이 적용되어야 할 필요가 있다.

6) 빠른 서비스의 패턴의 확인 및 대응 시스템 구축: 몇 백만 몇 천만 개의 센서가 보내는 수많은 데이터의 이유는 저장 후 통계를 위한 데이터도 있지만, 지진 상황 확인, 구급과 같은 정상적인 상태에서 이상 상태로의 변화에 실시간으로 대처하기 위한 목적인 경우가 있을 수 있다. 이를 위한 시스템 상에서의 실시간 변화 패턴 확인 및 대응 시스템 구축은 M2M을 적용하는 가장 근본적인 시스템이다.

7) 대량 요청 처리: Nike Fuelband의 경우 현재 1,000만개 이상이 팔린, 상식적으로 이러한 서비스가 지속적으로 늘어나게 되면 시스템이 느려지게 되어 있음, 하지만 소비자는 기기의 증가와 관계없이 서비스 받는 시스템은 항상 만족할만한 반응 속도를 기대한다. 제품이 잘 팔려서 베스트 셀러가 되어 요청이 빠르게 늘어나고 대량으로 되었을 때 이를 적극적으로 대응할 수 있는 기술이 필요하다.

8) 대용량 로그의 실시간 분석: 위에서 예를 든 Fuelband가 응급구조 기능을 더하게 되었다고 하고, 현재 이 기기가1000만개의 기기가 1KByte의 메시지데이터를 매10초마다 전달한다고 한다면, 100만Kbyte (1GB)의 데이터가 1초당 서버로 쏟아지게 되어 있다. 응급구조기능은 이러한 대량으로 들어오는 데이터 사이에서 단 하나
의 긴급메시지나 상태변화를 감지할 수 있어야 한다. 이는 기존과 같이 데이터를 관계형DB에 저장하고, 분석하
기에는 쉽지 않은 구조이다. 이를 위한 대용량 로그의
실시간 분석 기술이 적용될 필요가 있다.

9) 통합 시스템 및 서비스 거버넌스: M2M 환경은 센서, 게이트웨이, 미들웨어 및 내/외부 서비스가 복합적으로 돌아가는 서비스이다. 시스템의 목적도 단순한 통계 저장도 있을 것이고 응급구조와 같은 시급을 다투는 서비스도 있다. 하지만, 많은 운영환경이 효율을 위해서 적은 인원이 대응할 수 밖에 없는 구조이고, 이를 위한 통합적인 인프라와 서비스의 모니터링 체계를 구성할 수 있는 시스템이 필요하다.

10) 보안: 보안이 상대적으로 가벼운 운동 기록 저장 사례도 있을 것이지만, 특히 M2M의 도입에서 많이 우려하는 부분이 CCTV나 의료정보와 같은 보안 및 사생활 보호가 중요하다. 이를 위한 각 시스템 간의 보안 체계 및 감시 시스템을 구성하는 것은 M2M 플랫폼의 가장 기본기능이다.

이러한 M2M 플랫폼에서 요구되는 서버 기술은 대부분 현재의 시스템 구성에서 미들웨어 부분에서 대응이 가능하다. 이에 해당하는 미들웨어 기술을 소개하고자 한다. 애플리케이션서버, SOA아키텍처, 메모리 그리드, 이벤트 처리 프로세싱, 서버/인프라 모니터링 관련한 미들웨어 서버기술을 적용하여 이러한 요구 사항을 복합적으로 대응이 가능하다.

(2) 애플리케이션 서버
애플리케이션 서버는 분산 네트워크 내의 컴퓨터 내에서 응용프로그램에 비즈니스 로직을 제공하는 애플리케이션을 구동하기 위한 서버 프로그램이다. IoT/M2M과 관련된 각각의 애플리케이션은 기기인증, 데이터 수집, 계산로직처리, 장애확인, 공통 통신 프로토콜, UI애플리케이션 등이 있다. 이러한 애플리케이션들은 데이터베이스 연동, 성능 확장, 보안, 로그저장, 버전 업데이트, 데이터의 저장시 무결성 보장 등 공통적 요구되는 기능이 존대한다. 애플리케이션서버는 이러한 다양한 애플리케이션이 요구되는 공통 기능들을 애플리케이션 서버 내에 통합하고 공동으로 사용할 수 있는 기반을 제공하면서, 안정적으로 동작할 수 있는 기본 바탕을 제공하는 미들웨어 기술이다. 이러한 애플리케이션서버로는 오픈소스로는 톰캣(Tomcat), 레드햇의 제이보스(Jboss)시리즈가 있고 상용소프트웨어로는 IBM의 웹스피어(WebSphere), Oracle의 웹로직(Weblogic)과 같은 애플리케이션서버가 있다.

먼저 IoT/M2M을 구성하는 가장 기본적인 환경은 그림의 가운데에 보이는 다양한 애플리케이션 기능들이 필요하다. ID/Device 관리, 인증, 인터페이스 등M2M 플랫폼을 위한 다양한 애플리케이션이 존재하고 있다. 다양한 기기들이 24시간 365일 데이터를 서버로 쏟아내고 있다. 서비스의 상황에 따라 이러한 다양한 서비스들 안정적으로 서비스하기 위해서 각각의 애플리케이션을 서버에 설치하고 그 기능 각각을 업데이트하고, 발생한 자료를 데이터베이스에 저장하고, 인스턴스를 구하는 공통된 부분을 애플리케이션서버를 통하여 기능을 구성 할 수 있다.
추가하는 것은 정말 쉽지 않다. 이를 위해 애플리케이션이 요구하는 공통된 부분을 애플리케이션서버를 통하여 기능을 구성 할 수 있다.

또한 지속적으로 변화하는 애플리케이션과 서버 자체의 기능 업데이트를 위하여 애플리케이션서버가 가지고 있는 서버시스템의 연속 업그레이드 기능을 사용하여 무정지 업그레이드 기능을 사용할 수 있다. 무정지 업그레이드는 하나의 서버는 지속적으로 서비스를 독립적으로 제공하면서 다른 업그레이드 할 서버를 업데이트한 후 다시 서비스를 업데이트 완료된 서버로 요청을 변경하고, 나머지 서버들을 업데이트 하는 기능이다. 이를 위해 특히 상용 애플리케이션 서버는 웹 콘솔에서 조작을 할 수 있도록 제공한다. 이 웹 콘솔을 통하여 직관적으로 컨트롤이 가능하다. 그리고 데이터센터로 들어온 데이터의 데이터베이스의 저장을 위한 기능을 애플리케이션서버가 제공하는 트랜잭션 프로세스로 위임하여 데이터 저장을 대신하고 이에 대한 데이터 무결성을 보장 할 수 있다.

또한 디바이스에서의 데이터센터로의 접속 요청이 두 배 세배로 늘어갈 때 빠른 서비스 대응을 위한 시스템 구성이 필요하다. 이를 위해서 실시간으로 요청이 이루어 지고 있는 상황에서 수동으로 서버 증설을 한다면 상당한 혼돈을 일으킬 수 있다. 이러한 혼돈을 없애기 위해 애플리케이션서버 자체의 서버 증설 프로세스를 통하여 체계적으로 안정적으로 대응을 위한 서버를 증설 할 수 있게 된다. 이러한 시스템 증설 확장 통해서 고가용성을 확보한 시스템의 구성이 가능하고, 대응하는 서버가 하나로 동작이 될 수 있도록 하는 서버 클러스터링의 구축이 가능하다. 이를 통하여 안정과 효율을 동시에 얻을 수 있다. 또한 애플리케이션서버에서 제공하는 모니터링 시스템을 통하여 전체 시스템에 대한 모니터링 기능의 수행이 가능하다.

(3) 경량 애플리케이션 서버
WebSphere와 Weblogic과 같은 애플리케이션서버는 주로 대형 서버에 적용되는 기술이다. IoT/M2M환경에서는 게이트웨이와 같은 기기를 위한 경량의 스펙을 가진 애플리케이션서버가 필요하다. 게이트웨이는 단순한 센서의 기능을 생각보다 많은 기능들을 수행을 하기 때문에 애플리케이션서버기반에서 관리하는 것이 효율적이다. 게이트웨이구조를 형성하면 이는 일종의 전방 배치된 분산용 경량서버를 배치한다고라고 할 수 있습니다. 이 게이트웨이는 데이터의 수신, 앞 단에서의 패턴 분석, 임시 데이터의 기기 내 저장 등의 기능을수행한다.

당연히, 애플리케이션 업데이트, 기기 업데이트 등 각각의 공통된 기능이 요구된다. 이를 위해서 오라클은 기존의 오픈소스를 통하여 키워온 글래스피쉬(GlassFish)라는 경량 애플리케이션서버를 제공한다. 이는 비글보드와 같은 작은 스펙에서도 동작하며, 엔터프라이즈 급의 스펙을 가진 제품입니다. 작은 스펙의 서버를 구축할 시 고려해 볼만한 애플리케이션서버 이다. 특히 게이트웨이를 구축한다면, 글래스피쉬를 고려해 볼만하다. 특히나 원격 모니터링 기능과, 원격 업그레이드 기능은 전방 배치된 게이트웨이에서 아주 효율적으로 사용 할 수 있다.

<반도체네트워크>